品質保証に関する提言（その４：工数見積もりの意義について）

ソフトウェア開発における最大の問題の一つは、詳細な作業の工数が見積もれないことである。
現実には、事前調査に３週間、外部設計に５週間、詳細設計に１０週間、コーディングに2週間、テストに５週間などという形で予定が立てられる。
実際に「設計作業」と言っても、操作画面の構成を検討し、ファイルのレイアウト、メッセージのフォーマットなどを仕様の形にまとめる作業も入っているし、タスク分割、あるいは分割の根拠となる資料を作成する作業や、タスクの構造図を書くという作業もある。このような作業の中には、３０分や１時間で終わるものもある。
一方、「コーディング作業」でいえば、コンパイルオプションを決める作業や“コーディングベカラズ集”のようなものを作る作業も必要である。
チームのメンバーによっては、コーディングやテストの仕方、ツールの操作方法などに関してトレーニングを受ける必要もある。
こういった具体的な作業が必要であるにも拘らず、実際には大雑把に「設計に何ヵ月」という形でしか把握されていない。
こうなる理由は、このことについて考え続けていないからであり、考え続ける時間が確保できていないからである。

『プロジェクトが予定より１年も遅れるのはなぜなのか。それは１日の遅れが積み重なるからである。』
これは「ソフトウェア開発の神話」（「人月の神話」）の著者である、フレッド・ブルックスの言葉。

現実の混乱は、まさに、この言葉に集約されていると言える。現実は「１日の遅れ」を見ることはできない。
一体、今日は何を仕上げることになっていたのか、あるいは今週は何と何が終わっていなければならなかったのか、が見えない。
当人も、“何となく遅れているな．．．”というのは「感じ」られても、具体的に何が遅れているのか分からない。

「１日の遅れ」を認識するためには、どうしても「１日の予定」が必要なのである。

以下に、このように工数が読めない、あるいは工数が見積もれないことから、どのような問題が起きるかということについて考えて見る。

■今の作業がいつ終わるか分からない
その主な理由は、計画時に予想されていない作業が「その場になって」発生するのと、作業そのものは想定されていても、見積もった時間より多く掛かってしまうことである。
計画時に予想されていない作業が湧きだしてくるのは、作業を具体的にブレークダウンしていないから当然である。
また、一般にこの種のスケジュールが立てられるときには、ある程度の危険率が掛けられる。
危険率を掛けるのは、その時点で計画の甘さを感じているからであり、何かが湧き出してくることを予感している。
多くはスケジュールの中盤から後半にかけて、作業が行き詰まる形で出てくるため、結局、“危険率が必要であった”の神話が成立することになる。
実際の作業に入ったら、当初の予定を延ばす要因が次々と涌き出す。
しかもそれらの「遅れ」は、ほとんどが“自分の所業”ではない。
従って、この「遅れ」を回復するための動機は存在せず、遅れを主張することになる。
『予定外の作業が入ったのだから仕方ない』と。

見積もれない理由の多くは、それは前回のプロジェクト（今、遅れながら進行中のプロジェクト）の計画段階で詳細な工数を見積もらなかったことによって作業が遅れ、次のプロジェクトの開始時期に重なったことによって、次回も細かく見積もるための時間が確保できないまま、結局前回と同じ状態に突入する。
そしてこの問題は“マルチジョブ”が出来ないかぎり解決しない可能性がある。

■目前の業務以外のことに時間を割けない
実は先の問題よりもはるかに影響は大きく、広範囲に及ぶものであり、原因と結果が錯覚されている部分でもあるだけに、質の悪いものでもある。
たとえば心理面で、関係者はプロジェクトの進捗状況を隠そうとする意識が働く。
具体的な作業や、その工数、成果物などを明らかにしていないため、“今、やっている作業”に自信がないことなどが作用しているものと思われる。
工数が見えていないため、当然、自分にとって“余計”な作業を、ことごとく排除しようとする。
その結果、自分のスキルアップのために１日１時間も「勉強」に当てることができない。
他の人が書いた数枚の文書に“目を通す”ような作業も、当人にとっては『雑用』に見えてしまう。
或いはメールを読むことも『雑用』になるかもしれない。
組織において作業の見直しに取り懸かると、必ず、この種の「雑用」が槍玉に上げられる。
したがって、“優先順位を考えて作業をしよう”というスローガンも、彼にとって優先順位の高い作業は、コンカレント性にあるのではなく、自分の分担する作業にあるから、組織として何も変わることはない。

■仕様書ウォークスルーのドキュメントを、事前に読む事も出来ない
ウォークスルーの直前に１０分ぐらいでお茶を濁す程度にページをめくって、その場をやり過ごせた経験があるでしょう。
同じ理由で、メンバー相互のコード・ウォークスルーも出来ない。
それが、ソフトウェアの品質を確保する効果的な方法であることを理解していても、とても時間的に関わることは出来ない。
当然、今回の変更要求の仕様を「事前」に検討する時間もない。
実際にプロジェクトがスタートする前に、リーダークラスの人が事前に検討を終えていなければ、プロジェクトがスタートした後で、チーム内でコンカレントに作業が出来なくなる。
よく、メンバーの若手が、プロジェクトの初期の段階に、やることがなくてぶらぶらしている風景を目にすることがあるが、その殆どは、このような状況に陥っているものと予想される。
逆に、十分に検討しないまま仕事を分割して、各担当に割り振ってしまうのも、そうしなければ、メンバーが遊んでしまう、という理由も存在している。
当然、その結果として、具体的な設計に入ってから問題点が各所で表面化することになるし、もちろん、プロジェクトの後半に、彼らは地獄を味わうことになる．

■プロジェクトの進捗に対して、さらに効果的な進め方を検討することが出来ない
具体的な作業が明らかになっていないために、チーム内での作業の交換ができない。
一人でやる仕事なら、作業の順序はそれ程大きな意味を持たないが、チームで行うときには、比較的小さな単位で具体的な作業アイテムが明らかになっていて、その順序を制御することで、メンバー間の作業の待ち状態を避けることが出来る。
また幾つかの作業を事前に肩代わりしてあげることも出来る。
少々のトラブルがあっても、それが早い段階であればチームのメンバーがカバーして、遅れを表面化しないで済ませることも出来る。

作業展開は３日を限度に、工数を読む、ということは、作業の進捗を管理するために欠かすことができない。
「設計作業に１０週間」などと大雑把にしか把握していない以上、今日現在で作業が遅れているのかどうかを判断することは出来ない。

１日で終わる作業や数日で終わる作業などを中心に、長くても３日を限度として詳細な作業アイテムを把握することで、「予定より遅れたのか、予定より早く終わったのか」が見える。
作業が遅れたことが判明したとしても、残り１週間の時点ではなく、今はまだ設計作業に入って１週間目。
３週間のコーディング作業も、３週間かけて１つのモジュールをコーディングするようなことはない。

このようにして遅れを発見し、その原因を検討することで、この後、作業の把握状態の善し悪しを再検討してもよいし、遅れの原因が、単に担当者が風邪を引いて休んでしまったことにあるのなら、その後の作業をチームで吸収する方法を考えてもよい。

【チームが効果を増幅させる】
たとえば、５人それぞれの人に一つの仕事を割り当てるのと、５人で構成される１つのチームに５つの仕事を割り当てるのとでは全く違う。というより、違えることが出来る。
作業を細かく、且つ具体的に把握し、詳細に工数を読むことによって、チームとしての工数の合計を大幅に減らすことも可能になる。
勿論、プロジェクトの種類が、ある程度類似している事が条件となるが。
そして、このようなチームには、メンバー間の技術交流やスキルの向上という「おまけ」もついてくる。

逆に、工数を読まなかったチームでは、数年経ってもメンバーのスキルが変わらないということもしばしば見られる。

このようなことから、“工数を読む”ということを脇に追いやったままでは、その組織が抱える多くの問題を、何一つ改善することも叶わない。

明らかに、改善しなければならない項目がいくつか提起され、それに取り懸かっても、結局は「時間がとれない」という“事実”の前に、すごすごと『改善の旗印』を降ろさざるを得ないことになる。

このようなことからも、詳細な計画を立てることは、プロセスのレベルを改善するための第一歩である。