|
●連載・プロジェクト管理のつぼ●
第二回 「開発作業計画」と「進捗管理」
プロジェクト管理委員会
（promgt@bolero.plala.or.jp）
■進捗管理
ソフトウェア開発のプロセス管理の目的とするところは、ソフトウェアの品質の向上、コスト管理の徹底、納期の遵守にある。進捗管理はこれらの目的を達成するための作業であり、一にも二にも実態把握が基本となる。
（１）実態を把握する
開発プロジェクトの進捗管理の対象とするものは第一に「成果物」であり、その作業は完成度を把握することである。ウォーターフォール型のシステム開発では成果物が判りやすいように、開発工程が明示的に分かれているので実際は工程内の成果物の進捗で完成度を把握することになる。また、併せて「問題の解決状況」を管理することも、進捗管理の重要な作業である。
開発委託先からの作業進捗の報告として、成果物の完成度ではなく作業のアクティビティ（別の言葉で言うといかに一生懸命働いたか）が報告されることがある。努力のアピールとして受け入れることも必要であるが、主題は成果物の完成度と問題の解決状況であることを認識した上で、メインテーマが疎かにされる場合は放置せず、速やかに是正を指示しなければならない。
成果物の進捗に関する問題（回復しない進捗遅れ、品質劣化等）は必ず発生する。問題が発生した場合、原因究明の一つのやり方として、「リソースのアサイン実態を疑ってみる」がある。開発体制どおりにリソースが割り当てられていない（他の仕事と兼務している）、適任とはいえない人が従事している等の問題点が見つかる場合がある。発注者側からの問題是正に向けての申し入れに対して、受注者は開発コストの増大を押さえるためリソースの変更や追加投入をギリギリまで遅らせる傾向がある。また、楽観的なマネージャーの場合、何とかなるという判断で放置することがある。異常に気付いたら、第一報は「巧遅より拙速」[１]の原則に則り、開発責任者に報告・相談したり、委託先の開発責任者に率直に伝え実態把握に努めることが重要である。自社の部下の場合は本人から事情を聴取し、作業方法の改善等を指導する。直らない場合はジョブアサインを変更することも視野に入れた管理が必要となる。
実態把握の方法、コツは、第一回でご紹介した「ファクトの把握」「is/is notでの確認」等を参考にして頂ければと思う。
（２）数値で管理する
工程の終了判断や計画の修正は進捗管理業務の結果として実行されることになるが、いずれも「何が/をどのくらい」という状況把握や判断が伴う。そして経営層への報告や、第三者へ新たなリソースの手当てを要請する際にも「どのくらい」ということに関して客観性、再現性の高い尺度を用いる必要があるので、できる限り数値で表現する方法を計画時点から用意することがポイントとなる。試験の進捗などは、試験項目数など作業で直接取り扱える指標が使われるが、設計やマニュアルの進捗などはドキュメントのページ数だけでは進捗（完成度）の指標にならないことがある。その場合は「代用指標」や「マイルストン」を使って表現する。
例えば、設計ドキュメントが成果物と定義できるケースでは、執筆段階ではページ数で管理し、その後レビュー等のマイルストン（イベント）を経るごとに完成に近づくというモデルを設定し、数値の進捗率に変換する。どのようなマイルストンを設定するかが進捗判断の重要なポイントになるので、プロセス資産、過去の作業記録、経験者の意見を踏まえてマイルストンを決める。ドキュメントの完成度に着目した例を下記に示す。
・執筆完了：50％（ここの内部進捗はページ数で管理）
・チーム内レビュー完了：60％（レビュー（第１回））
・関連部門合同レビュー完了：70％（レビュー（第２回））
・ユーザーレビュー完了：80％（ここまでに２回のレビューを済ませてあること）
・ユーザーコメント抽出完了：90％
・ユーザーコメント反映完了：100％
なお、管理対象のドキュメントが複数ある場合は、ドキュメントごとに上記例のウェイトをつけて総合進捗を表現する。
マイルストンに対応する進捗率の表現は、発注者側と受注者側で到達レベルの解釈が異なる場合がある（一般的には、受注者側が甘くなるようである）。作業計画を作成する時点で両者で協議し、後日解釈の狂いを生じないように「合意」しておくことが重要である。さらに「完了の証」を何にするかも定義が必要である。
また、前記例での進捗率に関し、ドキュメント類の完成度（成果物の出来具合）は表現できるが、成果物の進捗に必要なリソースの量の管理にはそのままでは使えないことがあるので注意が必要だ。試験のような実行すべき項目や工数が予め計画できている作業は、成果物とリソース消費の関係を比較的リニアな相関で判断できるが、設計のような創造的作業では成果物の進捗とリソースの所要量は一致しにくい。設計作業のようなプロセスではリソースの固有能力、絶対的作業時間（工数ではない）などを管理すべきリソースの要素として押えておく必要がある。
（３）問題と課題の管理を行なう
システム開発を行なっていると必ずといっていいほど、期待したくないこと（問題）が出てくる。通常の問題（目標と現状とのギャップ）に関しては、取り組むべき課題を明らかにして対策を実行してゆく。
「問題」や「課題」は一般的に使われる当たり前の用語のためか、よくよく内容を確認してみると人によって定義が異なっていたり、表現方法に違いがあったりする。これが原因で、意思疎通のために予想外に手間取ることがある。行き違いを防止するためのコツを下記に紹介する。プロジェクトの開始時に意識を合わせておくことで後に発生する手間を省くことが出来る。
①問題と課題は表現方法を明確に分ける
問題：目標と現状とのギャップについて否定的な言い回しで表現する。
下記に例を示す。
例1 ：・・・・ができていない。
例2 ：・・・が遅れている。 |
課題：課題とは一般的には「解決を求められている問題」である。しかし、実際の開発作業ではこれを一歩進めて、「解決を求められている問題とその解決策について、目的を付加し、具体的、能動的に表現したもの」と定義する方が良い。本節（２）の「数値で管理する」でもご紹介したように、プロジェクトメンバー全員で、その問題の内容、解決状況、進捗状況を客観性・再現性の高い尺度を用いて共有することができるからである。また、よりよい別の解決策を第三者から得ることも可能となり、よい結果を生むことが多いと考える。
下記に課題の表現例とよくない例を示す。
例：○○を達成するために
○○を行う。
よくない例１ ：△△の変更。
△△の実施（理由：目的が記述されていない）。
よくない例２ ：△△を改善する
（理由：具体的に何をするのか不明確）
よくない例３ ：△△の問題を
解決する（理由：問題の裏返し表現になっている） |
②課題には主語と期限をつけ、宿題として管理する
課題は確実に実行されなければならない。そのためには課題を設定した時点で、誰が、いつまでにということを同時に規定し、実行計画の確実性を担保する。課題を設定したら内容記述には前記の表現を用い、実施主体と期限、結果等が記述できる
課題管理表を作成し、定期報告の中で宿題として管理する。
③大きすぎる問題はエスカレーションする
問題が大きくてどのように取り扱ったら良いか考えあぐねることがある。このようなときは、第一報は「巧遅より拙速」[１]の原則に則り遠慮せず上位のマネージャーや開発責任者に問題を報告し、取り扱い方法に関するアドバイスや指示を受ける。
④申し送りは、丸投げしてはいけない
ある工程で達成が困難な課題は、次の工程での解決に委ねざるを得ない場合（申し送り）がある。ここで注意しなければならないことに、工程が変わることによって「実施主体や実施環境が変わる」場合の申し送り事項の管理がある。
例えば、システム試験→総合運転試験（開発委託先→開発発注元）、総合運転試験→実運用（開発発注元→運用部門）などの局面で大きな変化が生じる。ケースにもよるが、このような場合、課題自身が申し送られると、受けた側でその課題を実質的に実行することが困難な場合がある。課題を次工程に申し送る場合は、次工程の責任者に受け入れてもらうように、以下の点に関して十分吟味しなければならない。
・設定した課題はそのままでよいか。
・課題を分解して部分的に前工程の責任者が実施すべきことは何か。
安易に次工程へ課題を丸投げすることは厳禁である。
■おわりに
「プロジェクト管理のツボ」第二回では開発作業計画の作成時及び進捗管理に関し、重要と思われる事項についてご紹介した。ソフトウェア開発やシステム開発には、プログラムコードや設計書等以外に多くのドキュメントが存在する。本稿でも、計画策定時の書面化等の必要性について述べた。一方では、書面化による管理工数の増大、書面化は本当に必要かというご意見があるのも事実である。開発作業は、どのような開発手法をとるにせよ、協調的な問題解決作業であり、書面化の本質は協調作業を進める上で必要な情報の整理・知識化とその意識付けであると考える。極端に述べると、情報化できればそれでOKと考える。情報不足、誤解・認識不足による問題発生リスクを最小限にするために、Web上であれ、社内データベース上であれ、紙の上であれ、開発作業に必要な情報を目に見える形にすることが重要であると考える。次回は、この協調作業を進める上で重要なコミュニケーションと品質管理について述べさせて頂く予定である。
参考文献
[ 1]佐々淳行、危機管理のノウハウPart 1,2,3、PHP文庫（1984） |
