プロジェクトの監視と制御
List
「進捗管理」という言葉を勧めない理由
CMMでは「進捗管理」という表現が使われていたのに、CMMIでは「進捗管理」という言葉が消えていることに気付いていると思われます。もちろん、原書での表現が少し変わっていることもあるのでしょうが、それ以上に、日本の現場で行われている「進捗管理」とCMMで求められている「こと」が違っているために、「進捗管理」という訳をあてるのをためらったものと思われます。
CMMでは、プロジェクト計画書の中に見積りやスケジュール、課題管理、リスク管理などの「基準」があって、その基準に沿って作業が進められますが、実際に事前に想定した通りに作業が進むとは限りません。そこで、事前に想定した「基準」と比べてみて、予定よりも進んでいるのか遅れているのか判断するのです。この行為は、「基準」となるものが用意されていなければできませんし、その「基準」もある程度実行可能な、そして達成可能なレベルであることが必要です。
最初から、空絵事を書いた「基準」では結果を照合することもできません。
これに対して、日本の組織で行われている「進捗管理」では何をやっているでしょうか。私が見てきたかぎりでは、「状況」を確認しているだけであって、最初から「追跡」に耐えるような「基準」と呼べるものはありません。第一、「プロジェクト計画書」なんて本気で書いている組織はどれだけあるでしょう。CMMに取り組んでいるという組織であっても、「計画書」を“能動”で書いているリーダーはいるでしょうか。だからそのような組織でも「遅れ気味です」という報告が、何の躊躇もなく出てくるし、それが受け入れられるのです。これは、CMMでいうところの「Tracking」でも「Monitering 」でもありません。それが、“日本的進捗管理”なのです。
CMMで「Tracking and Oversight」を「進捗管理」と訳したことで、多くの現場では、「Tracking and Oversight」＝「進捗管理」と“誤解”したかも知れません。でもそれは間違いです。日本で一般的に行われている「進捗管理」は「Tracking and Oversight」とは異なるものです。でも、長らく日本的「進捗管理」に首まで浸ってきた人達は、「進捗管理」と聞いただけで身体が反応してしまう危険がありますので注意が必要です。できれば、しばらくは「進捗管理」という言葉を使わない方がよいかもしれません。
なお、CMMIでは、「Monitering and Contorol」を「進捗管理」とは訳していません。そのまま「監視と制御」と訳しています。これは、一つの「見識」と評価したいところです。
補足） CMMでは、Tracking and Oversight
CMMIでは、Monitering and Contorol
追跡するのはサイズと生産性
多くのソフトウェア開発の現場では、作業の追跡は「工数」しか追跡していません。いや、「日程」かもしれません。予定した日に仕上がるかどうかだけが問われているのです。せめて「工数」ぐらいは追跡して欲しいところです。「工数」は、そこで生み出される成果物の「サイズ」と、そのサイズを生み出す「生産性」から算出されます。したがって「工数」を追跡しようとすれば、その元になる「サイズ」と「生産性」にも目が向くのですが、残念ながら、多くの場合、「日程」と「スケジュール」しか追跡されていません。
「サイズ」や「生産性」を“追跡”する意味は、それらが見積もった対象だからです。そして、事前に見積もった「サイズ」や「生産性」に対して、実際の作業ではどうだったかを追跡するわけです。それらが予定通りだったのか、それともサイズが想定よりも２０％多かったのか。あるいは、生産性が３０％低かったのか。もちろん、サイズや生産性が事前の想定よりも悪ければ工数は多くかかってしまうため、日程も延びてしまうでしょう。でも、サイズも生産性も想定通りであっても、日程が予定通りに仕上がらないこともあります。
そして、今日の作業でサイズや生産性が想定と違ったとき、問題は今日の作業だけでは済まないことです。「サイズ」が想定よりも２０％多いということは、この先の成果物の中に、今日の“多さ”が反映するものがあるはずですし、「生産性」が当初の想定に届かないということは、この先にある同じような作業で想定している生産性も狂う可能性がありますので、今から対応策を講じることができるのです。
これに対して、今日の「工数」が想定よりも２０％余分にかかったからといって、この先の作業にどのように影響するかは、必ずしも見えてきません。その時点でわかるのは、“遅れている”ということであり、この先の作業も“遅れるのだろうな”という感触だけです。どの作業にどれだけのリソースを追加投入すればよいのか、具体的には見えてきません。この意味からも、追跡するのは「サイズ」と「生産性」なのです。
でも、その「サイズ」や「生産性」を追跡している人達はどれくらいいるでしょうか。
工数しか表示されないスケジュールツールの不思議
一般に使われている「スケジュール・ツール」に疑問を感じたことはありませんか？
個々の作業名に対して、それにかかる予定工数、開始予定日、終了予定日などが表示され、カレンダー上に予定工数に見合う長さの「バー」が表示されます。いわゆる「ガント・チャート」式のスケジュールです。たとえば、予定工数が「１０日」の場合、休日を外して実質で１０日の長さの「バー」が、開始予定日のところから表示されます。ツールによっては、作業は階層化して表現できますので、作業の進行に合わせて作業を分解するときには便利です。そうして、実際の作業を進めていく中で、工数のバーの色が変わっていきます。これも分かりやすいですね。「１０日」と見積もった作業を１日取りかかったとき、このバーは、１／１０だけ色が変わるのです。２日目には、色が変わるバーの長さが２／１０に広がります。
これって、おかしいと思いませんか？
「ガント・チャート」しか表現されないことが問題ではありません。このツールは、いわゆる作業の「進捗」を見えるようにするツールのはずです。どこまで作業が進んだかをみるためのツールです。でもそこで表示されているのは、予定した工数がどれだけ過ぎたかであって、どれだけ作業が捗ったか、言い換えれば、どれだけ成果物を生み出したかは表現されていません。作業がどれだけ捗ったかを表示するのであれば、その作業で生み出すソースコードの行数がを６０００行と見積もっていて、今日までのところで実際に生産できた行数を元にして「進捗率」などを表示するべきなのです。工数は“消化”するものであって“達成”するものではありません。作業の遅早に関わらず、平等に「１日」は過ぎていくのです。こんなもので“進捗”が判断できるはずはありません。にもかかわらず、多くのスケジュール・ツールは、「工数」しか出てきません。それらのツールでは、消化した日数だけ色が変わっているのです。このバーは作業の“達成”を表しているものではなく、消化した日数の「比率」を表しているだけなのです。
もし、作業の“達成”を表そうとすれば、「サイズ」見積りに対して、それだけ達成したかを表す必要があります。そして、その作業が捗っているのか遅れているのかを見ようとすれば、従来の工数のバーの下に「サイズのバー」を出せば一目瞭然です。サイズのバーの長さを、工数のバーの長さに合わせることで、予定通りに進捗しているときは、２本のバーは同じピッチで色が変わるのです。もし、サイズのバーの色の変わりかたが工数のバーよりも遅いときは、作業が遅れていることを意味します。
この時、そこで見積もられているサイズや工数の見積りの精度がいい加減だと、２本のバーの“ずれ”の精度も低くなってしまうのですが、「３段見積り」（「３段見積りの方法」を参照）によって、直前まで再見積りを行っている場合は、これらの見積りの精度も高くいますので、２本のバーの変色の進み具合がズレている状況は、作業の進み具合をそのまま表現してくれるのことになります。
このようなスケジュール・ツールがあれば、週に１回集まって“進捗”を確認する必要はなくなります。個々のメンバーの“進捗”の状況は、翌日には２本のバーが変色する形で表現されますので、リーダーは問題の担当者のところに行って、状況を確認すればよいのです。メンバーがきちんと結果のデータを入力すれば良いだけです。そして、リーダーが担当者と話しをしてその場で対応方法を指示できるのであれば、そこで済ませばよいのです。作業の進捗状況を確認するために集まる必要はないのです。
残念ながら、マイクロソフトの「MS Project」にはこのような機能はありません。他に、現在市販されているスケジュール・ツールで、２本のバーが表示されるツールはないと思います。わずかに、作業の項目のところに、数字でサイズに対する「達成率」を表示しているツールがありますが、折角なら２本のバーで表示して欲しいものです。
“フィードフォワード”こそ進捗管理の真髄
いわゆる「進捗」を管理する目的は、今日の作業結果から、この先に予定している作業に対する“情報”を獲得し、その情報によって見積りやスケジュールを調整することにあります。その結果、２ヶ月先の作業に新たなリソースが必要になるかもしれませんが、それが２ヶ月前に見えることで対応方法を考えることができるのす。
直前になって、日程の遅れが表面化した場合、リソースの確保も含めて、納期の達成を実現するための適切な対応方法が選択できないことが生じます。急遽、リソースを確保したとしても、そのような間際になってから調達したのでは「助っ人」にはなりません。新たに参加する「助っ人」に作業内容を教える時間もないし、かと言って、そのままでは納期に間に合いません。
彼らは、この時点でそのような助っ人が入ることを想定していません。全部、自分たちで設計し、自分たちで実装しテストすることを前提として作業を進めてきたのです。実装段階で助っ人が参加することが分かっていれば、いくつかのモジュールで助っ人が担当しやすいように、適当な成果物を残しながら作業を進めることができたのですが、現実にはそのような成果物を作りながら作業を進めていません。
これが、プロジェクトの終盤にリソースを追加することがタブーとなっている背景なのです。かといって、助っ人を受け入れなければ、遅れることが分かっていながら何もしなかったと非難されますので、結局は、助っ人を受け入れるのですが、効果が上がることはありません。つまり、このような進めかたでは、選択肢はないのです。
でも、２ヶ月前に、実装工程で２人の応援を入れる必要があると分かって、それが承認されたのであれば、今から行う作業の中で２人の助っ人に実装を分担してもらうモジュール（の範囲）を決めて、彼らが作業をしやすいように、表現内容を調整した適切な成果物を残すようにプロセスとスケジュールを変更することができます。この場合、プロジェクトの終盤にリソースを投入してもプロジェクトは崩れません。つまり、「タブー」は破ることができるのです。
このように、今日の作業の結果からこの先の作業の影響を見極めるたり調整したりすること、すなわち「フィードフォワード」を働かせることこそが、進捗を管理する最大の狙いでもあるのです。「フィードフォワード」が働かない状態では、進捗を管理しているとは言えないのです。それでは、ただの結果の確認であり、状況の把握に過ぎないのです。
「フィードフォワード」を機能させるためには、そこで生み出される成果物がサイズによって連鎖していることが条件になります。もとより、「設計する」ということは、複雑に絡み合った要求（仕様）から、「分割と階層化」を繰り返して最後は単純な「関数」レベルの集合に展開していくことです。また、そこで実施される設計のプロセスは「変換プロセス」ですので、入力物に含まれている情報が「変換プロセス」を介して、分割されてより細かな情報の集まりとなって出力の成果物に展開されることを意味します。分割の際には、何らかの「分割係数」というものが作用します。この「係数」は、計測を繰り返している中で、ある程度の範囲で把握することができます。その結果、成果物は「変換プロセス」を経てサイズで連鎖していると言えるのです。
ただし、成果物がサイズによる合理的な連鎖を実現するためには、その前に、ＰＦＤを使って成果物とプロセスの合理的な連鎖を実現することが前提になります。つまり、ＰＦＤによってプロセスと成果物の合理的な連鎖が構築されている状況において、サイズによる成果物の連鎖が確保できるのです。そうして成果物がサイズによって連鎖している状態が実現している状況であれば、「フィードフォワード」が可能になるのです。
作業の「進捗」を適切に管理するためには、これらのことが前提となるのですが、このための工数は、現実に行われている無駄な作業に使われている時間を充てることができます。いや、それで余るはずです。