今回は「工程進捗の実態把握」をテーマに取り上げる。進捗管理の基本は、いかに実態を正しく把握するかだ。
 |
ソフトは第三者の目に見えにくいし、その中身が複雑かつあいまいであることから、工程進捗の実態把握が難しい。どうしても担当者の定性的、主観的な報告を受け入れがちだが、あらかじめ決めた進捗基準に基づいて、無理をしてでも定量的に報告させるべきだ。
もちろん、定量的な報告に頼るだけでは正しい実態の把握はできず、複雑な実態を体で感じることも、実のある管理のために必要である。だが、「大体できた」「ほぼ順調な推移」「相当危い」「予断を許さない」といった感覚的であいまいな報告は、客観的、定量的表現の上にコメントとして付加されてこそ生きてくるのであり、追加コメントで正式な報告を代替されては困る。
進捗度の質的評価は別途レビュー工程を設定し、経験や能力のある識者によるこまめなレビュー・プロセスを通じて実施すべきである。
 |
ソフトは、複数の設計者が担当し、各部分はその完成まで設計者個人の管理に任されることが多く、その進捗度は各設計者の判断に基づく報告に頼らざるを得ない面がある。
したがって、「できた」と称するソフトがチーム全体で管理する完成ライブラリに登録されるまでは、各設計者の担当ソフトが完成したとは見なさないという最低限のルールが大事である。そしてライブラリに登録されたソフトを第三者が使ってテストし、その結果問題がないと判断できてこそ本当の完成と見なせるのだ。
また第三者が出来具合をちょっと “味見”をするためにも、早めに共通ライブラリに登録させる必要がある。
 |
設計のような極めて知的要素の強い仕事は、きちんとできたかどうかを判定するのは極めて困難だ。担当者が「できた」と言ったから「できた」とは、とても考えられず、どうしても第三者の判定が求められる。それだけに、レビューという工程は是非とも必要だ。
しかも設計が完成したと担当者が言ってからレビューするのでは、多くの場合、ドキュメント量が多すぎて中身の濃いレビューはできかねる。「大体できた」という段階から何回かに分けて、あまり時間をかけずにレビューしたほうが、レビュー効果がでやすい。２時間を超すようなレビューは注意力が散漫になってしまうからである。
レビューしなければ設計が完成したと言えないように、工程ごとに何と何がそろったら完成したことになるか、完成条件をあらかじめ定義しておくべきだ。一部ができても、完成条件を満たさなければ、その工程は仮終了と考えるべきであろう。
 |
ソフトはハードのように設計と製造の分離がうまくできない。したがって、一般に設計からデバッグまで同一の設計者が担当することが多いので、結合試験を実施するまで各設計の出来具合を客観的に把握しにくい欠点がある。なんとか第三者の客観的評価ができる環境を無理にでも作る必要がある。
その解決手段の1つが、設計のなかに独立テスト部隊を編成し、単体テストが終わらない段階から無理やり中間成果物を集めて結合し、大体の出来具合を味見することである。予想外の不具合が早めに見付かれば、対策を取りやすく、致命的失敗から救われる。
ワインバーグの法則と呼ばれるものに、「開発者は自分が作成したコードのテスト担当者としてふさわしくない」というものがある。出来具合の評価は極力第三者に委ねることが肝要だ。
