自然体PMのススメ：進捗管理（3/n）実体に則せばうまくいく

前回は進捗管理は無駄の排除をすることだ、と書きました。また管理方法が拙いと無駄が無駄を生むという例として、プロジェクト開始時の注意点についても触れました。今回は、進捗管理作業の中でスケジュールを引く時の陥りやすい問題について取り上げます。

前回、スケジュールを引くことを仕事ではないと書きましたが、通常、管理書類は最終成果物には含まれません。そして、「スケジュールを引く」とか「進捗を報告する」のような作業はWBS上には現れず、工数の確保もされていません。そのため、管理作業工数は作業の効率化で得られるものと考えなくてはいけません。管理書類もワークファイルと割り切ってしまうことが大事です。

スケジュール管理から無駄を省くには、管理業務と開発業務が離れていくような事態を防ぎ、実体を正確に把握する多角的な視点を持つことがコツです。

いつ間にやら引かれている、できそうもない線

何ができ何をするかを決めるには、非常に多くの要因を考慮する必要があります。可能なことを考えているつもりでも、いつも間にやらあり得ない線を引いているのがスケジュールの怖いところです。

よくある原因の１つは後ろから線を引くことです。C/Oが10/1だから、その前のシステムテストに10日間、導入はその前3日…と引いていくと、なんと開発が1ヶ月半しかない！余裕があると思ったらとんでもない！なんてことがあります。当然開発は無茶なスケジュールがたてられ、立てたその日から守れません。

プロジェクトに多数の組織が関わっていたりすると、マスタースケジュールを細かく引くことになったりします。そして、まだ３月の時点でありながら、「ユーザー登録の統合テストは10/2-10/3でユーザーレビューが10/4、ユーザーレビュー反映が10/5」といったスケジュールが出てきたりします。

このように、物理的にできそうも無いとか、予言のような話はスケジュールを引くだけ無駄です。開発スタッフは、このようなスケジュールを見ても何も得ることはできないので、配られた時以外に見る事はないでしょう。簡単に思えることでも、うまくいかないのがシステム開発です。ましてや実感の湧かない計画に意味を見出すことはできません。できたらいいな線、できなきゃいけない線、引かなきゃいけない線などは、開発メンバーにとって無意味であり、混乱の元になります。

見えないものは書かない。常に、見えるものだけ、見える程度書く

個々の作業の見通しは一様ではなく、対象によって見える程度は差があります。現在仕掛かっているプログラムであれば、後何日で終わるかは、まだ始めていないものよりも正確に予測できます。

時間軸で考えれば、今週→来週→3週間後…と遠くなるに従って、大雑把で不確実になるはずです。今週の作業は「A01.html～D08.htmlのフォームのバリデーション処理の実装とUT」となりますが、来週は「入退会処理の実装」、3週間後は「結合テスト」といった具合です。つまり、時間的に近いほど正確な作業項目や完了日を正確に予想することができます。実効性の高いスケジュールを組めば効率のよい開発に繋がるので、常に近いスケジュールを詳細に保守することが、効率的な開発には必要です。

作業項目にも目を向けると、設計や要件定義時には「○○を明確化する」みたいな項目が並びがちです。曖昧な作業が並びすぎる場合には要注意です。要件が不明確である問題は、時間をかけて作業すれば解決するものではありません。このような作業項目では何をしたらよいのか、はっきりしません。進捗は常に定量的に捉えるべきで、計測して数値化できる作業に落とします。計測できる形で書いたものが、見えている範囲と言えます。

スケジュールは見えないものを無理やり記入する必要はありません。作業項目の粒度、担当者、作業所要時間といったスケジュール項目について、時間軸や経験値などで見える程度に書きます。例として、12/1 C/Oプロジェクトで、ITを何日間で誰が実施するかは、設計中には不明です。この場合には、ITという作業項目を作り、「11/10-11/25：IT」くらいに書きます。この時日付に根拠はありませんが、その程度の認識でOKです。開発を進めて３つのインターフェースになれば、ITという項目が３つに分割されます。テストデータのボリュームが予測できるようになれば、作業時間も予想し易くなり、各インターフェースの完了実績が上がってくれば、担当者や実施時期も明確にできます。このように時の経過に従って詳細度と確度が上がってくるので、常に見えるものを反映するようにします。

窮屈にならず、油断せず、実体に則した対応を冷静にする

短いスパンのプロジェクトでよくあるのが、先にも書いた後ろから逆算したスケジュールです。５週間のプロジェクトで、本番設定や検収などで２週間、開発側のITで１週間、残りの２週間が開発期間になったります。要件定義も設計も曖昧な状況なので、開発できるところから始めることになります。しかし、どんなに短くても要件定義・設計→開発→テストという工程とその比率は大きく変わりません。どんなに短くても予算が小さくても、顧客にとっては大事なシステムであり、妥協は無く、開始後の変更要件は必ずあります。できるところから始めるリスクは、非常に大きいと言えます。元々短いプロジェクトでは、窮屈なスケジュールを組むことで、失敗のリスクが更に大きくなってしまいます。

今度は長いスパンのプロジェクトでありがちな話です。検討・調査・教育・トライアルなどの開発に直結しない、定量化できない項目が並んでいたり、小さな機能に随分と工数を裂いてあるスケジュールがあります。潤沢なコストと余裕の日程があると考えがちですが、基本的に楽なプロジェクトは無いことを思い出さないといけません。余裕のスケジュールを引くのではなく、後々必ず来るであろう大きな要件に備えて、見えるものを見極めて小さく迅速に始めて、後々の追加に耐えられるようにしておくべきです。余裕があるときに無駄にコストを消費して、最終的にはコスト不足に陥るプロジェクトは少なくありません。

現実離れしたスケジュールを書いても、何の役にも立ちません。基本に従ってプロジェクト実体に沿って、できることが書いてあるからこそ、生きてきます。今、自分に何が分かるかを冷静に見つめて、最後まで見通せていなくても、今日から少し先までを、真正面からぐらつかずに見通そうと努力すれば、良いスケジュール管理ができるでしょう。

次回以降の予定

今回までは進捗管理のうち主にスケジュール作成を話の中心にしてきました。次回は実績管理に焦点を当てていきます。実績を予定に対して評価するという、一般に取られている方法では、システム開発はうまくいかないことに触れ、その解決についても記します。

そのうまくいかない方法で、多くのシステム開発の現場が苦しんでいるのではないかと思っています。示す解決方法が全て解決することはないでしょうが、少しでもどこかで役に立てばよいのですが。