タグ

開発と仕事に関するbasiのブックマーク (10)

  • 納期が迫ってるプロジェクトにおけるOJTの効果って? - smellman's Broken Diary

    今のプロジェクトでは新人がOJTとしてプログラムの一部を組んでいます。 これは良くある話なんですが、気になる点が一つ。納期近すぎじゃね? 新人とはいいつつも、一人は学校でJavaやってましたよ(おっと、Javaスクールの話をする訳じゃないですよ)と前に人から直接聞いていたので、たぶんそこから即戦力として投入されているのかもしれない。 ただ、納期が近いプロジェクトに投入されていて余裕があるのかなというのが疑問点。だって、毎日9時とか今日なんて10時まで残って仕事をしているんですよ。新人がやるべき事なんでしょうか? 別に新人だから甘やかすべきとかそういう話ではなくて、彼等に学習する余裕ってあるんでしょうか?一年目というのは多くの事を吸収する大事な時期のはずなのに、当に学んでいるのでしょうか? 実際今日帰りに一緒だった同じプロジェクトの新人に聞いてみたら、日々の業務をこなす事に精一杯で何をや

    納期が迫ってるプロジェクトにおけるOJTの効果って? - smellman's Broken Diary
  • 学生が作ったもの,はてなが学んだこと

    この記事は日経ソフトウエア2009年2月号(2008年12月24日発売)に掲載した,特別レポート「はてなインターン日記(下)」(著者:伊藤直也氏)の再掲です。再掲にあたって一部編集していますが,記述内容は執筆当時の情報に基づいています。 この特別レポートは,筆者が勤務するはてなが,大学生や大学院生の方を対象に開催した「はてなサマーインターン2008」のまとめです。就職を少し先に控えた学生の皆さんが,はてなの京都オフィスで,4週間にわたって技術的なトレーニングや,実際のアプリケーション開発を体験します。期間は4週間です。 2009年6月12日に掲載した上編では,前半の2週間,はてなスタッフが講師となって,はてなでの開発に必要な知識の講義と,それを確認する課題の様子を書きました。最終回の今回は,後半の2週間。インターン生がはてなの開発現場に所属して,はてなのシステムに何らかの機能を追加します。

    学生が作ったもの,はてなが学んだこと
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • システム開発の入門者から中級者にステップアップするための10のティップス - builder by ZDNet Japan

    ある読者との電子メールのやり取りの中で出てきた話である。彼は、開発者向けのブログや記事、雑誌の内容が2種類に分類できるということを述べていた。その2種類とは入門者向けのもの("Hello World"に代表されるもの)とエキスパート向けのもの(MSDN Magazineのようなもの)である。 これはなかなか鋭いポイントを突いている。開発者が入門レベルから中級レベルにステップアップするうえで役立てることのできる情報がほとんどないのだ。以下は、こういったステップアップを実現するための10のティップスである。 #1:新たなプログラミング言語を学習する 新たなプログラミング言語を学習することは、それがどのような言語であったとしても、より優れた開発者になるための近道となるのである(このことは、あなたが既に多くのプログラミング言語を修得していたとしても成立することである)。言語を選択する際には、あなた

    システム開発の入門者から中級者にステップアップするための10のティップス - builder by ZDNet Japan
  • ゲームプログラマだけどなにか質問ある?

    1 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:05:18.46 ID:H67nJ+Kz0 答えれる範囲で答えます 3 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:06:11.23 ID:F7f5GAvH0 年収は? >>3 400万くらいかな 4 名前:VIPの帝王 ◆koxjyhajbE :2009/01/01(木) 19:06:31.93 ID:ijQ2eBqp0 やっぱブラックなの? >>4 他の業界をしらんからなんとも言えんが、 α、β付近になると終電帰りがデフォになる。泊まりはそれほどない。 残業代はなし。これはブラックなのかな? 5 名前:以下、名無しにかわりましてVIPがお送りします:2009/01/01(木) 19:06:35.75 ID:+TELd9IE0 DirectXとOpenG

  • あなたのテスト、単なる動作確認になっていませんか?

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    あなたのテスト、単なる動作確認になっていませんか?
  • デスマーチ突入時の打開術 : LINE Corporation ディレクターブログ

    こんにちは。livedoor のディレクター・菊地です。今回は、聞いただけで身が震える「デスマーチ」について書きます。「デスマーチ」状態でディレクターがやるべきこと、ディレクターがやっちゃいけない禁忌(タブー)について触れてみたいと思います。 ■「デスマーチ」とは? この言葉を広めたエドワード・ヨードン(Edward Yourdon)氏は、著書「Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects」(1997年)の中で、デスマーチ・プロジェクトの定義として次の項目を挙げている。 1. 与えられた期間が、常識的な期間の半分以下である 2. エンジニアが通常必要な人数の半分以下である 3. 予算やその他のリソースが必要分に対して半分である 4. 機能や性能な

    デスマーチ突入時の打開術 : LINE Corporation ディレクターブログ
  • どうしてプログラマに・・・プログラムが書けないのか?

    Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が「Fizz

  • プログラマの権利宣言

    Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の

  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • 1