ソフトウェア開発における最大の問題の一つは、詳細な作業の工数が読まれないことです。現実には、事前調査に１週間、外部設計に５週間、詳細設計に１０週間、コーディングに２週間、テストに３週間などという形で予定が立てられることが殆どです。
もちろん、表向きはこのように簡単に表現されていても、詳細な工数の裏付けがあって、それを集約した結果であれば構わないのですが、現実には成熟レベル１のプロセスでは、詳細な工数見積もりが為されることは殆どなく、単純なガンチャートに上に挙げたような項目が書かれているだけということになります。
実際に「設計作業」と言っても、操作画面の構成を検討したり、ファイルのレイアウト、メッセージのフォーマットなどを仕様の形にまとめる作業も入っているでしょうし、タスク分割、あるいは分割の根拠となる資料を作成する作業や、手法によって求められるダイアグラムを書くという作業もあるでしょう。タスクの構造図を書くという作業もあります。更に言えば、設計書の形式（様式）を決めるという「作業」も考えられます。このような作業の中には、３０分や１時間で終わるものもあるでしょう。時には関係者に声を掛けて促すだけで済むこともあるでしょう。ほんの２０分で済む作業も、適切なタイミングで為されなかったために、その場になって１週間の遅延となることも考えられるのです。
一方、「コーディング作業」でいえば、コンパイル・オプションを決めたり、チームで共通するheader
file を、何時までに、誰が用意するという作業もあります。コンパイル・オプションといっても、コンパイラのマニュアルを見るだけでは決められないかも知れません。初めて使うコンパイラの場合など、開発環境に因っては実際に使ってみたり、“コーディングべからず集”のようなものを作る作業も必要かも知れません。当然、１日の作業では済まないでしょう。これを最初に見積らなければ、その場になって、確実に数日の遅れが発生します。それだけではなく、何人かの人が、この作業の終了を待つ事になるかも知れません。そうなれば、全体で数日の遅れでは済まなくなります。
チームのメンバーによっては、コーディングやテストの仕方、ツールの操作方法などに関してトレーニングを受ける必要があるかも知れません。
こういった具体的な作業が必要であるにも拘らず、そして、ちょと本気になって考えれば考えられるにも拘らず、実際には大雑把に「設計に何ヵ月」という形でしか把握されないのです。こうなる理由は、このことについて考え続けていないからであり、それはとりもなおさず、考え続ける時間が確保でき（てい）ないからです。
外部のソフト会社が請け負う場合には、当然具体的な工数が見積もられることになります。そうでなければ、契約は成り立ちませんし、利益も出ないでしょう。それでも、詳細な工数を見積もれないソフト会社が少なくないのが現実です。このようなソフト会社も“考え続ける時間がない”という点で、同じ問題を抱えているものと思われます。そして、このように“考え続ける時間がない”のは、実は、今取り懸かっているプロジェクトの作業の工数を読まなかったことに起因しているのです。
『プロジェクトが予定より１年も遅れるのはなぜなのか。．．．．それは１日の遅れが積み重なるからである。』これは「ソフトウェア開発の神話」（新版では「人月の神話」）の著者である、フレッド・ブルックスの有名な言葉です。現実の混乱は、まさに、この言葉に集約されていると言えます。そして、残念ながら、現実は「１日の遅れ」を見ることはできません。一体、今日は何を仕上げることになっていたのか、あるいは今週は何と何が終わっていなければならなかったのか、が見えないのです。当人も、“何となく遅れているな．．．”というのは「感じ」られても、具体的に何が遅れているのか分からないのです。ですから、敢えて自分から申し出ることはありません。「１日の遅れ」を認識するためには、どうしても「１日の予定」が必要なのです。
以下に、このように工数が読めない、あるいは工数が読まれないことから、どのような問題が起きるかということについて詳しく考えて見ます。
先ず、工数が読まれていない以上、当然のことに今の作業がいつ終わるか分かりません。その主な理由は、計画時に予想されていない作業が「その場になって」発生するのと、作業そのものは想定されていても、見積もった時間より多く掛かってしまうことです。
計画時に予想されていない作業が湧きだしてくるのは、作業を具体的にブレークダウンしていないのですから当然です。また、一般にこの種のスケジュールが立てられるときには、ある程度の危険率が掛けられるものですが、その「予備」として隠しておいた時間は現実には何の役にも立つことなく、無残にもローラーの下敷きとなってしまいます。
危険率を掛けるのは、その時点で計画の甘さを感じているからであり、何かが湧き出してくることを予感しているのです。しかがって、その場になって、予定通り（？）不測の作業が湧きだしてきます。しかも、多くはスケジュールの中盤から後半にかけて、作業が行き詰まる形で出てくるため、結局、“危険率が必要であった”の神話が永久に成立することになります。皮肉なことです。
特にチームで行動する場合、他の人の作業と連携する作業が多く発生します。お互いに作業の順序を見せることなく、調整もされていないと、あちこちで「待ち状態」が発生し、作業がコンカレントに進行しません。“どうしてこんな作業に１週間もかかるの？”ということがしばしば起きます。関係者は遊んでいたわけではありませんが、身動きがとれなかったのです。また、詳細な作業の種類を見せていないことから、誰が、何時、どんなリソースが必要なのか分からず、開発機器等の必要なリソースの調達が遅れ、ここでも待ち状態が発生することになります。このように、実際の作業に入ったら、当初の予定を延ばす要因が次々と涌き出してきます。しかもそれらの「遅れ」は、ほとんど全て“自分の所為”ではないのです。従って、この「遅れ」を回復するための動機は存在せず、堂々！と遅れを主張することになるのです。『予定外の作業が入ったのだから仕方ない』と。
関係者全員が、この開発作業が初めてなら仕方がない部分もあるとしても、通常、関係者の多くは何度か体験した作業をするのですが、それでも詳細な工数を見積もろうとしないために、毎回、同じ事態に陥るのです。もっとも、そのような人達も、“本当は詳細に見積もりたい”と言う気持ちは持っていますし、その気持ちは決して弱いものではありません。でも見積もれないのです。見積もれない理由があるのです。それは前回のプロジェクト（今、遅れながら進行中のプロジェクト）の計画段階で詳細な工数を見積もらなかったことによって（予定通りに）作業が遅れ、次のプロジェクトの開始時期に重なったことによって、次回も細かく見積もるための時間が確保できないまま、結局前回と同じ状態に突入するのです。現実は、このサイクルから抜け出せなくなっているのです。そｈしてこの問題は「マルチ・ジョブ」が出来ないかぎりか、解決しない可能性があります。
多くのソフトウェア開発現場で、作業の見直しが行われることがあっても、この部分に手を付けられることは殆どありません。おそらく、工数を見積れないという問題は、“原因”ではなく、他の何かが悪くて、その“結果”の症状（影響）と考えられている為でしょう。
工数を見積もらなかったことによるもう一つの影響として、目の前の業務以外のことに時間を割けなくなることが挙げられます。残念ながらこの問題は現場ではほとんど意識されていないようですが、実は先の問題よりもはるかに影響は大きく、広範囲に及ぶものであり、原因と結果が錯覚されている部分でもあるだけに、質の悪いものでもあります。
たとえば心理面で、関係者はプロジェクトの進捗状況を隠そうとする意識が働きます。具体的な作業や、その工数、成果物などを明らかにしていないため、“今、やっている作業”に自信がないことなどが作用しているものと思われます。中には、最初からスケジュール通りに進まないことが分かっている？ために、そのときになって“精一杯に努力した”ということで免罪符を得ようとします。これは多くの場合、本人も何となく逃げ腰の気持ちは意識されることはあっても、“免罪符”については、プロジェクトの初期の頃には明確には意識されていないかも知れません。
それでも、プロジェクトの半ばに入って、予定通りに終わらないことが見えてくると、はっきりと意識するようになり、ますます“がんばる”のです。時には、プロジェクトの予定を立てる段階で、既に「言い訳」のフレーズ、例えば、“脇目も振らず、休日も返上して頑張ってきました。予定通りに終わらなかったのは、もともと無理なスケジュールだったんです”というフレーズが意識されている事もあります。
工数が見えていないため、当然、自分にとって“余計”な作業を、ことごとく排除しようとします。その結果、自分のスキルアップのために１日１時間も「勉強」に当てることができません。１日中画面に向き合っていても効率が上がらないことを知っているのに、スケジュールの遅れが判明したとき、違う“事”をやっていては困る、という意識が働いているため、画面の前から離れることが出来ないのです。
他の人が書いた数枚の文書に“目を通す”ような作業も、当人にとっては『雑用』に見えることでしう。或いはメールを読むことも『雑用』になるかもしれません。その人に関係のない文書が回ってくることは殆どないものですが、この段階に入れば、もはやそんな「道理」は彼には通用しません。組織において作業の見直しに取り懸かると、必ず、この種の「雑用」が槍玉に上げられます。したがって、“優先順位を考えて作業をしよう”というスローガンも、彼にとって優先順位の高い作業は、コンカレント性にあるのではなく、自分の分担する作業にあるのですから、組織として何も変わることはありません。
そしてもっと厄介なことに、自分が当面の作業以外のことに手を付け（られ）ない以上、当然、部下の「勉強」も認めないという態度に出ます。そうして彼は部下を１日中画面の前に張り付けることになります。（自分にとって）訳の分からない「絵」を書く時間があれば、さっさとコーディングしろ、と言うことになります。
影響は、これだけに止まらず、研修会や社内の勉強会にも参加できないし、させないという事になります。また、操作を覚える時間を確保できないため、新しいＣＡＳＥツールを使ってみることもできません。そのツールが目の前にあって、空いていても手を付けられないのです。最近のこの種のツールは、殆どが「手法」を背景に持っているため、ツールを使うためには、事前にその「手法」をある程度以上理解していなければなりません。そんな勉強時間を取っていないものですから、このようなツールをすぐに操作することは出来ません。挙げ句の果てに“最新のツールかもしれないが、私のやって欲しいことまで、やってくれる訳ではない”という文句を盾に、「元の家」に住み続けようとします。その結果、いつまでも彼、及び彼のチームは、「慣れた」方法で作業をするしかないのです。
「４フィートの空き缶の塔を作るのに、１０個の空のビール缶があればすむ。ではその１００倍の大きさの空き缶の塔を作るには、１００倍の空き缶が有れば出来るか」という問い掛けに、即座に『否』と答えることが出来ても、実際には、（実績のある）４フィートの塔を建てる方法で、その１００倍の塔を建てようとしているのです。
この他、自分の作業の工数が見積もられていないために、明日の３時から開かれる仕様書ウォークスルーのために配られたドキュメントを、事前に読む事も出来ないでしょう。その「作業」は１時間で終わるものであっても、習慣的に自分の作業以外の作業（？）を割り込ませることが出来なくなっている可能性があります。また、これまで何度もウォークスルーの直前に１０分ぐらいでお茶を濁す程度にページをめくって、その場をやり過ごせた経験が、きっと今度もそうさせるでしょうし、次回もそうするでしょう。人はどんなことであっても「成功体験」を忘れる（捨てる）ことは容易ではありません。
同じ理由で、メンバー相互のコード・ウォークスルーも出来ないでしょう。それが、ソフトウェアの品質を確保する効果的な方法であることを理解していても、仕様書ウォークスルーのドキュメントを読む時間の数倍の時間を提供しなければならないことが見えている以上、とても関わることは出来ないでしょう。
当然、今回の変更要求の仕様を「事前」に検討する時間もありません。実際にプロジェクトがスタートする前に、リーダークラスの人が事前に検討を終えていなければ、プロジェクトがスタートした後で、チーム内でコンカレントに作業が出来なくなります。よく、メンバーの若手が、プロジェクトの初期の段階に、やることがなくてぶらぶらしている風景を目にすることがありますが、その殆どは、このような状況に陥っているものと予想されます。逆に、十分に検討しないまま仕事を分割して、各担当に割り振ってしまうのも、そうしなければ、メンバーが遊んでしまう、という理由も存在しています。当然、その結果として、具体的な設計に入ってから問題点が各所で表面化することになるでしょうし、もちろん、プロジェクトの後半に、彼らは地獄を味わうのですが．．．
詳細な工数を読まないことでもっと問題なのは、プロジェクトの進捗に対して、さらに効果的な進め方を検討することが出来ないことです。具体的な作業が明らかになっていないために、チーム内での作業の交換ができません。一人でやる仕事なら、作業の順序はそれ程大きな意味を持たないかも知れませんが、チームで行うときには、比較的小さな単位で具体的な作業アイテムが明らかになっていて、その順序を制御することで、メンバー間の作業の待ち状態を避けることが出来ます。また幾つかの作業を事前に肩代わりしてあげることも出来ます。少々のトラブルがあっても、それが早い段階であればチームのメンバーがカバーして、遅れを表面化しないで済ませることも出来ます。
しかしながら、現実はこのような形で具体的な工数を明らかにしていないため、ここに並べたことは、全て無縁なこととならざるを得ないのです。また、組織上はチームを構成していても、作業上の連携や、相互の援助が行なわれないために、実態は芝木を束ねたようなものになりがちですでし、チームとして融合していないため、スケジュールが逼迫したときに作業を肩代わりすろことなど望むべくもない、ということも考えられます。
工数を読む、ということは、作業の進捗を管理するために欠かすことができません。先に挙げたように「設計作業に１０週間」などと大雑把にしか把握していない以上、今日現在で作業が遅れているのかどうかを判断することは出来ません。その材料がないのです。１日で終わる作業や数日で終わる作業などを中心に、長くても３日を限度として詳細な作業アイテムを把握することで、「予定より遅れたのか、予定より早く終わったのか」が見えます。作業が遅れたことが判明したとしても、残り１週間の時点ではなく、今はまだ設計作業に入って１週間目なのです。
３週間のコーディング作業も、３週間かけて１つのモジュールをコーディングするようなことはありません。この前の設計作業で、例えば９３個のモジュールが明らかになっているとすれば、１週目はこのグループの２６個、２週目は次の３３個、３週目は残りの３４個というように割り振ることが出来るはずです。更に言えば、１週目の２６個のモジュールも１日単位で、取り組みの順序を予定することで、もっと早く作業の進捗が見えるはずです。
このようにして遅れを発見し、その原因を検討することで、この後の作業の把握状態の善し悪しを再検討してもよいでしょうし、遅れの原因が、単に担当者が風邪を引いて休んでしまったことにあるのなら、その後の作業をチームで吸収する方法を考えてもよいでしょう。例えば来週に予定されている作業を、別の人が代わってあげるとか、違う方法で実現することを考えたりして、遅れを吸収してしまえばよいのです。これが出来るのも、細かく作業が見えているからです。
それに「一人」で解決できることは殆どありません。「チーム」だからこそ幾つかの解決方法が手に入るのです。
たとえば、５人それぞれの人に一つの仕事を割り当てるのと、５人で構成される１つのチームに５つの仕事を割り当てるのとでは全く違います。というより、違えることが出来るのです。もっとも、現実は、チームとして機能していないため、同じことになってしまうことが殆どでしょうが、作業を細かく、且つ具体的に把握し、詳細に工数を読むことによって、チームとしての工数の合計を大幅に減らすことも可能になります。勿論、プロジェクトの種類が、ある程度類似している事が条件となりますが。
そして、このようなチームには、メンバー間の技術交流やスキルの向上という「おまけ」もついてくるでしょう。逆に、工数を読まなかったチーム（？）では、数年経ってもメンバーのスキルが変わらないということもしばしば見られます。
このようなことから、“工数を読む”ということを脇に追いやったままでは、その組織が抱える多くの問題を、何一つ改善することも叶わないでしょう。明らかに、改善しなければならない項目がいくつか提起され、それに取り懸かっても、結局は「時間がとれない」という“事実”の前に、すごすごと『改善の旗印』を降ろさざるを得ないことになるのです。
このようなことからも、詳細な計画を立てることは、プロセスのレベルを改善するための第一歩であることは疑いのないことと考えます。