『Joel on Software』やさしいソフトウェアスケジュール

Joel on Software

Joel on Software

やさしいソフトウェアスケジュール

大多数の人はスケジュールを作らない

なぜスケジュールを作らないのか?

  1. 作るのに骨が折れる

  2. 誰もスケジュールなんて信じていないからw

正確なスケジュールを作る方法

1. 単純に保つ

スケジュールのフォーマットは暗記して置けるくらい単純にすること。
7列のカラムが例として取り上げられている。

機能 タスク 優先度 当初見積 現在見積 経過時間 残り時間
スペルチェッカー メニューアイテム追加 1 12 8 8 0
スペルチェッカー メニューダイアログ 1 8 12 8 4

2. コードのスケジュールが立てられるのは、それを書くプログラマだけ

それぞれの機能はいくつかのタスクからなる スケジュールづくりの最も重要な部分、タスクのリストを作ること。

マネジメントがスケジュールを書いてそれをプログラマに渡しているようなプロジェクトは失敗する運命にある。

その機能を実装するためにどんなステップが必要になるのか見積もることができるのはプログラマだけだから。

3. タスクの粒度を細かくする

面倒くさがって(「文法ミス修正機能を実装する」といった)大きな塊のタスクを選択した場合、何をすることになるのかを実際には考えていないだろう。そして、何をすることになるのかを考えないなら、それにどれくらいの時間がかかるのかもわからない。

タスクは日単位ではなく時間単位でつくるべき。

  1. 細かい粒度でタスクつくると、どんなステップ(関数foo()を書く、~ファイルを読み込む、データを加工するなど)をたどるのか考え、容易に見積もることができるはず。

  2. 細かい粒度でタスクをつくると、あなたがその機能をデザインすること(プログラムがどう機能するのか具体的に考えることp52)、その機能を細部まで明確にするように強いられる。大きな塊のタスク(インターネット統合みたいな機能)をブレークダウン(分解・分析)しないで、スケジュールを割り当てたら失敗する。
    この2つを実践すると不確定要素を取り除くことができる。

4. 当初の見積もりと現在の見積もりを記録しておく

多くのプログラマは、物事にどれくらい時間がかかるか推測する方法を全然分かっていない。

当初の見積もりよりも時間が多くかかったなら、必要なだけ現在見積をアップデートしていい。これが自分の誤りから学び、タスクの正しい見積もり方を学ぶ最良の方法。こうしてスケジュールをアップデートする限りスケジュールは機能するし、あなたは学び1年もするとスケジュールの見積をうまくできるようになる!

5. スケジュールにデバッグの時間を入れる

デバッグ作業を見積もるのが一番難しい。
プログラマは、修正できるバグがある限りは、決して新しいコードに取りかかるべきではない。

  1. コードを書いたのと同じ日にバグを直すほうが簡単だから。
  2. どの時点でも未解決のバグが1つか2つしかないなら、製品がいつリリースできるか見積もるのは簡単。バグが多いと今後のスケジュールの見積が不能になる。

6. スケジュールにバッファを入れる

考慮すべき重要なバッファ
1. 当初の見積よりも長くかかるタスクのためのバッファ 2. やらなければならないとは知らなかったタスクのためのバッファ

後者はたいてい、マネジメントが実装することが極めて重要で、次のリリースまで伸ばすことができないと決定したことによって発生する。

7. マネージャにプログラマの見積を減らさせない

私は、スケジュールより遅れているときは、落ち込んで絶望的になり、やる気がなくなる。スケジュールより進んでいるときには、元気よく生産的だ。

マネージャが見積もりを減らそうとするなら、スケジュールにマネージャが入力できる見積欄を作って自由に記入させる。そしてプロジェクトが完了したときにどっちの見積が現実に近かったのかを確認する。 こんなことできるとは思えないがw

  • どうしてマネージャはプログラマに見積を減らさせるのか

マネージャは3ヶ月でできるだろうと思っているが実際には9ヶ月かかる機能のリストを作り上げる。プログラムを作るときに、すべてのステップについて考慮、つまりデザインしなければ3n時間かかることがn時間に見えてしまう。そしてプログラマがスケジュールを立てると3n時間かかるとわかる、という現実に直面する。

  • マネージャのやり方

人をたくさん雇ってスピード感をあげようと考える。実際には新しく雇った人は、軌道に乗るまで50%程度の効率でしか働かない。そして彼らに教える人の効率は下がる。20%ばかり多くのコードは手に入るかもしれないが、デバッグ時間は2倍になる。

8. その機能は本当に必要か

スケジュールを正確に保つ思わぬ副産物、それは機能を削るように強いられること。

  • なぜそれが良いのか?

たとえば、2つの機能があり、一つは本当に有用で重要な機能、もう一つはコードを書くのが簡単で、役にも立たなければマーケティングにも寄与しないものだとする。 スケジュールを作らなければ、プログラマは簡単に作れる機能に最初に手を付ける。そして前者の機能は時間がないので手がつけられなくなり削るはめになる。 しかし、きちんとスケジュールを作れば何を削らなければいけないのかを考え、本当に必要な機能を残し、不必要な機能を削ることになる。


最近、機能を追加したり、変更するときに上の人に工数どれくらいかかると言われて答えることができなかった。プロジェクトの開始当初は、これくらいかかるかなぁとだいたい答えることができたのだが、プロジェクトが終盤になってプログラムが複雑になると考慮すべき事項が多くなってきてもはや見積もりが取れなくなくなって正直困っていた。タスクを分解して小さなステップを考え、時間単位に分割すれば工数を見積もることは可能かもしれない。今回のプロジェクトはそもそもスケジュールが最初から崩壊していたわけで、、、次回以降ははじめからきちんとプログラムをデザイン、すなわちスポルスキがいうには「プログラムがどう機能するのか詳細に具体的に考えること」をするように自分に強いて、スケジュールを細かい粒度で作るべきだと思う。さもなければ今回のプロジェクトの二の舞になるだろう。設計をきちんとすることができるのかという課題はあるが。