プロジェクト計画の立案
●プロジェクト計画の立案
ＰＦＤを忘れている
CMMの中に書かれているプロジェクト計画書に「ライフサイクルモデルの選択」と言う項目がありますが、この意味が掴めない人が多いようです。
私に、
「ウォーターフォール」とか「UP」とかを決めることが何の意味を持つのか、わからない
と聞いてきます。
これは、プロセスと成果物の連鎖を図で表す習慣がないことが原因かと思われます。今回のプロジェクトの要求に対して、どのようなプロセス（と成果物の連鎖）で対応するつもりか、ということが問われているのです。ライフサイクルモデルを明らかにすることで、プロセスの基本的な形が決ってきます。今回の要求は実現に不安があるものはないということであれば、「ウォーターフォール・モデル」を選ぶでしょうし、実現に不安のある機能が幾つかみえているのであれば、最初から「インクリメンタル・モデル」や「スパイラル・モデル」を選ぶかも知れません。
こうして、ライフサイクル・モデルを選択することで、たとえば、組織標準が用意されていれば、それぞれのライフサイクル・モデルから標準プロセスを選択します。そのあとは、プロジェクトのプロセスモデルにするためにプロセスを調整することになります。たとえば、要求されている機能について他社製品を調査するプロセスを追加したり、技術的な解決方法を探すために、論文誌を集めて調査するプロセスを追加したり、別の製品やシステムで実現している機能を移植できるか調査するようなプロセスを追加するかも知れません。それでも、基本は、最初に選択した「ライフサイクル・モデル」なのです。
場合によっては要求を仕様化する中で、あるいは仕様化した後で必要なプロセスが見えてくることがあるり、その時点でプロセスを調整することになりますが、一般には、ライフサイクル・モデルが変わるような大きなことは起きません。ただ、仕様の項目数が予想よりもだいぶ多かったり、実現性に不安のある機能が予想を超えて含まれていることが分かったりしたばあい、当初の「ウォーターフォール」の予定を、急遽「インクリメンタル・モデル」に変更することが考えられます。もちろん、プロセスが変わりますので、スケジュールも変わります。
計画書の段階でプロセスの基本的な形が見えたことで、ここで選ばれようとしているプロセスが適切なものかどうかを関係者が判断できるようになるので、要求されていることに対して選択の間違いが見えます。プロセスのレベルで言えば、基本的な選択をミスしていなければ、あとは、個別のプロセスの問題なので、大きな狂いは生じにくいのです。実際に、ＰＦＤを使って書かれていれば、そこで選択されたライフサイクル・モデルに対して追加されているプロセスが見えますし、気になれば、個々のプロセスの定義を見れば判断できます。ただ、計画書の中でライフサイクル・モデルが選択されていても、ＰＦＤのような「図」がなく、単にプロセスの定義書しかない状態では、適否を判断することは難しくなります。
ところが、日本のソフトウェア開発の現場では、このＰＦＤのような「図」でプロジェクトの標準プロセスを定義していることは稀なようです。もしかすると、ほとんど書かれていないのかも知れません。私のクライアントでＣＭＭのアセスメント（今はアプレイザルと呼ぶようになっている）が行われた際に、アメリカから呼ばれたアセッサーは、私がコンサルティングの中で取り入れた「ＰＦＤ」によるプロセスの定義はすんなりと受け入れられたのですが、別のクライアントで日本人のアセッサーの時は、この「ＰＦＤ」が、当初引っ掛かってしまいました。この違いは、ソフトウェアの開発現場で日常的にＰＦＤ（のような図）が使われているかどうかの違いのようです。
欧米では、プロセスの定義に「ＤＦＤ」を使っています。ＤＦＤは構造化分析の中で現場のプロセスを調査したり、分析する際にも使用しますので、日常的にプロセスを表現する道具として使われているのです。その様子は、ＣＭＭの中でも見ることができます。ＣＭＭ「CMU/SEI-TR-25」の７０ページ（O-52）に挿入されている図に、ＤＦＤによってプロセスが定義されている様子が表現されています。しかもこの図に対する説明は、どこにもありません。つまり、この図については説明する必要はないほど「常識」のものだということです。残念ながら、CMMIには、このような図が挟まれていませんので、いきなりCMMIを参考にしたときは、この種の「図」を目にすることはありません。
（「ＰＦＤ」は、私がＤＦＤをヒントにして使いやすくアレンジしたものです。表記のルールについては、「http://homepage3.nifty.com/koha_hp/process/PFDform2.pdf」をご覧下さい。）
仮説の段階でサイズを見積もりと「間に合わないモンスター」の関係
ＣＭＭの考え方が行き渡る中で、サイズ見積りの必要性あるいは重要性については、現場の人たちに理解されるようになったと思います。しかしながら、それが要求仕様書を作成した後では効果が失われることには、あまり気がついていないのではないでしょうか。
「なぜ、要求仕様を書く前に見積もらないの？」と尋ねると、
「仕様が分からない状態では見積もれないじゃないですか」という返事が返ってきます。この場合、要求仕様書を作成するプロセスが見積もる対象から外れてしまいます。つまり、要求仕様書を作成するプロセスの工数は見積りの「埒外」に置かれているわけです。つまり、要求仕様書は“やってみなければわからない”という状態になっているのです。本来なら、事前に仕様の項目数を見積もって必要工数を割りだしたところで、仕様化の作業に３人充てて対応するところを、仕様化前にサイズ見積りを省いたために２人しか充てていません。その結果、必要以上に日程（工数ではなく、カレンダー上の日程）を消費してしまうのです。
そして残された日程の中では、そこで書かれた要求仕様書に盛り込まれた仕様を実現できる見通しが立たない状態になっていることが多いのです。そのような状態で、まともなスケジュールは立てられません。その前に、この先のプロセスで生成される成果物のサイズやそれに掛かる工数を見積もることが白々しくなってくるはずです。少なくとも、サイズ見積りは残された工数とマッチしませんので、見積もること自体がおかしなことになってしまいます。そして工数は、残された日程に合うように配分されたものにしかなりません。
本来なら、その時点で確保されている人数などのリソースでは対応できないのです。でも、そのことを言っても、「最初の約束だから」という返事が返ってくるだけで、取りあってもらえません。たしかに、最初に「納期」などの約束をして要求の仕様化に取り掛かったのです。要求仕様をまとめたところで、「これだけ多いのでは、当初の納期に間に合わない」と言っても、最初に仕様の項目数を見積もっていませんので、言い訳にしか聞こえないでしょうし、場合によっては料金を釣り上げるためのクレームに受け取られてしまいます。
このように、サイズ見積りをするなら、最初の要求仕様の項目数から見積もる必要があるのですが、この段階では、せいぜい要求の項目数が見えている程度です。それも、比較的粗い状態、あるいは上位レベルの要求が見えている程度で、ほとんどすべての見積りが「仮説」に基づいた見積りになります。そこで、この段階での見積りを「仮説見積り」と呼んでいるのです。
そして最初に仮説の段階でのサイズに基づく見積りを省いたことで、「間に合わないモンスター」に襲われ、それ以降、ことごとくソースコードを生成する作業以外の作業を省こうとします。仕様化のサイズ見積りはもちろんですが、途中での実績値による再見積りやスケジュールの追跡、作業項目の細分化、といった作業はことごとく省かれます。場合によっては、必要な成果物も省かれたり、内容が不足したりします。私のコンサルティングの予定もキャンセルされます。それは迫り来る期限に対して「間に合わないモンスター」が囁くからです。
「そんなことしていて間に合うの？」
「さっさとソースコードを書かないと間に合わないよ！」と残念ながら、これらのプロセスを省けば省くほど、手戻り作業が増えてしまいます。必要なプロセスを省いているのですから当然です。でも、すでにこの「モンスター」に取り憑かれた状態では、その判断はできません。こうして、期限をとっくに過ぎているにも関わらず、いつまでも噴出するバグに追われるのです。ようやく出荷したと思ったら、市場トラブルの連絡が入ってきて打ちのめされるのです。
このように「間に合わないモンスター」に取り憑かれるのも、最初の仮説の段階でサイズに基づいた見積りを省くことに起因しているのです。
３段見積りの方法
サイズや工数を見積もる際に勧めたいことは、それぞれの成果物やプロセスに対して
初期見積り
再見積り
実績
の３段階構成のフォームを用意することです。例えば、「要求仕様書」という成果物のサイズ見積りの場合、
「要求項目数」に対して、
初期見積り
再見積り
実績
の３つの欄を設けます。
さらに、仕様の項目数に対しても同じように
初期見積り
再見積り
実績
の３つの欄を設けます。
「操作画面要求仕様書」や「クラス仕様書」「ソースコード」「テストケース」などに対しても、同じように３つの欄を設けます。これらの成果物を生み出すプロセスの工数も、これと同じように、
初期見積り
再見積り
実績
の３つの欄を設けます。
もちろん、「工数」ですので、対応する成果物で見積もった「サイズ」のデータに「生産性」データを使って算出しますが、サイズも工数も、
初期見積り
再見積り
実績
の３つの欄を使うことをお勧めします。少し大きな仕掛けになりますが、気にすることはありません。「初期見積り」は、その字の通り、最初の「仮説」の段階で見積もった値で、この値はその後、変更されることはありません。というよりも触ってはいけないのです。「再見積り」の欄には、最初は「初期見積り」の値が入りますが、その後は、その作業に取りかかるまでは何度でも書き直して構いません。サイズや工数の見積り値を変化させる“何か”に気付いたのであれば前日でも書き直して下さい。自分で“何か”に気付くことが大事なのです。
ある機能の要求を仕様化しているときに、計測データを画面に表示する部分は以外と細かな制約や表示上の配慮が必要なことに気付いたのであれば、同じような表示が求められている他の機能の仕様項目数を調整すればよいのです。このとき、彼は、ある種の計測データの表示には、どのような仕様が必要か見えましたので、次回の初期見積りには、今回の経験が活かされるはずですし、今回の「データ」も残されていますので、これを見て確認することもできます。
この結果、「再見積り」と「実績」の数字は、原理的には同じかそれに近い状態になるはずです。でも、実際には、そう簡単な話しでありません。実際の作業に取りかかったところで、今まで“見えていなかったこと”が見えるのです。直前まで再見積りしていなければ、“見えていなかったこと”は一杯あるために気にならないのですが、直前まで再見積りしている場合は、事前に見えたことは再見積りに反映していますので、“見えていなかったこと”に遭遇するとしても僅かです。そのため、“見えていなかったこと”が「再見積り」の値と「実績」の値に現れてくれるのです。あとで、数字の差から“見えていなかったこと”を思い出すこともできるのです。
“見えていなかったこと”が特定できることで学習も進みますし、「再見積り」の値と「実績」の値の乖離をチェックする意味も出てきます。特に、コーディングのプロセスの場合、この「再見積り」の値と「実績」の値に一定以上の乖離が認められる部分には、高い確率でミスが潜り込んでいるのです。一通りコードを書いてテストを行い、次のテストの段階に引き渡した後で、この「再見積り」の値と「実績」の値に一定以上の乖離が見られる箇所をチェックしなおします。まだテスト中ですので間に合います。人に見つけられる前に自分で見つけるのです。そうでないと本当の意味で「学習」になりません。
また、「再見積り」した時点でスケジュールなども調整（実際には微調整）されていますので、「再見積り」の値と「実績」の値が近くなるような状態での見積りやスケジュールは「追跡」しやすいのです。実際の値とあまりにもかけ離れた見積り値でスケジュールが立てられているような状態では、作業結果を「基準」と照合しようとしても、あまりにも食い違っているためにそこから何の情報も引き出すことはできません。
見積りのスキルは、ある意味では「総合的なスキル」です。私がこの世界に入ったころ、先輩の人に「見積りができて一人前だよ」と言われたことは、今でも忘れていません。見積りのスキルを確実に身に付けることがデスマーチに陥らない一つの条件でもあります。「３段見積り」で見積りのスキルを磨いてください。