シス開発：システム開発に必要な技術の概要 |
何かを開発するプロジェクトは、工事のプロジェクトとは根本的に異なる。工事なら、誰かがミスをしない限り順調に作業が進む。ところが開発では、予定どおり進まないことが多い。技術的な問題が発生して一部の作業が長引いたり、後工程で設計の欠点が見付かって前工程からやり直したり、予想外の状況が発生しやすいからだ。途中でいろいろな問題が発生すると、最初の日程どおりには進みにくい。したがって、プロジェクトが失敗しないように、いろいろと工夫する必要がある。
開発におけるプロジェクト管理は、基本的には次のような考え方で進める。まずは、必要な作業をできるだけ細かく洗い出す。よく使われるのは、３段の階層で作業を規定する方法だ。たとえば、フェーズ、アクティビティ、タスクという名前を付ける。第１レベルのフェーズは、プロジェクト全体を時間軸に沿って分割したもので、作業の大きな区切りを表す。「調査分析」、「概要設計」、「基本設計」．．．「サブシステムのテスト」、「総合テスト」、「試験運用」などのようなものだ。どのように分けるかは、採用する開発手法によって異なる。共通しているのは、最初のほうに分析や概要設計があり、最後のほうにテストや本番運用が来る点だ。第２レベルのアクティビティは、フェーズ内で発生する作業のグループ分けと考えてよい。「総合テスト」のフェーズであれば、「テスト方法の概略を決定」とか「テスト環境の準備」のように、プロジェクト・リーダーが管理しやすい単位で区分けする。もっとも細かな単位が第３レベルのタスクで、個々の作業を表す。アクティビティごとにタスクを洗い出すので、すべてのタスクはどれかのアクティビティに属する。
作業の進み具合はタスクの単位で管理する。各タスクごとに費やした時間を報告させ、終了したかどうかも記録する。アクティビティに含まれるタスクがすべて終了すればアクティビティも終了するので、アクティビティ単位の管理もできる。それぞれの作業の期日（終了予定日）は、基本的にアクティビティごとに設定し、タスクではごく一部だけに設定する。非常に簡単に説明だが、このような方法で管理する。手作業では面倒なので、プロジェクト管理用のソフトを用いるのが一般的だ。ただし、クリティカルパスを求める機能などは使わない。ソフトウェアの開発では、設計やテストを決められた順序で行うだけなので、各フェーズで作業が日程どおり終わるように頑張るしかないからだ。
さて、本当に重要なのは、作業の区分け方法ではない。前述のような管理方法を用いながら、プロジェクトが成功するような工夫を加えることこそ、プロジェクト管理の重要な目的である。以下に、代表的な目的を５つ紹介する。
プロジェクト管理の最大の目的は、起こりそうな問題をできるだけ回避することである。たとえば、技術的に未解決の部分があって、それがシステムの成否を大きく左右するなら、できるだけ早目に解決方法を見付けなければならない。この種の重要な作業は、他よりも優先して実行すべきだ。プロジェクト管理のアクティビティとして、より前のフェーズに挿入し、最適な担当者を割り当てる。また、どんな問題が発生するかを検討する打合せも、プロジェクトの作業として登録する。最初の時点だけでない。後の段階でも検討できるように、プロジェクトの途中の何カ所かにも入れておく。ここでも適切な人を担当者に指名する。スケジュール上で作業を明示すれば、解決方法を求めたり検討することは必ず実施されるし、適切な時期（たいていは早い時期）に行われる。このように、リスクを回避するための作業をスケジュールに含めることは、プロジェクト管理の大切な目的の１つである。
洗い出した全部の作業に対し、誰が実施するのかを割り当てる。担当が明確に決まれば、その人が責任を持って実施する可能性が高いからだ。加えて、できるだけ早目に日程を公表することも大切である。参加メンバー各人には複数のタスクが割り当てられ、かなり事前に示されることで、より自由に予定を組むことが出来る。アクティビティごとに期日を決め、それに間に合う限り、どのような順序で作業しても構わない。誰かと関係する仕事だけは、相手と相談しながら作業を進める。
設計でもテストでも、その内容を何かに記述しなければ終わったとは言えない。多くのタスクでは、その中で何を作るのかを明示する。企画書や設計書などの書類、プログラム、テスト用データなど、作るべき成果物の具体的な名前を指定する。各タスクの担当者は、そのタスクに割り当てられた成果物を作成することが、第一の目的となる。
代表的な書類に関しては記述方法を決め、それを説明した文書を用意するべきである。また、できるだけ簡単に作れるような工夫も大切だ。要点だけを記述すれば済むような書式にするとか、書式のテンプレートを用意して必要な部分だけ記述させるとか、作成の手間を限界まで減らす。書式が決まっていてテンプレートがあれば、かなり書きやすいだろう。外部に提出する必要のない書類は、テキスト中心の簡単なもので済ませると効率的。
企画や設計の内容が適切かどうか、レビューをして確認することも重要だ。どの部分を誰がレビューするのか、また誰が承認するのか、プロジェクトの作業としてスケジュールに含めなければならない。たいていのケースでは、作成した成果物がレビューの対象となる。また、重要な成果物に関してだけは、レビュー段階で大きな間違いが発見されては遅すぎるので、途中の段階で行うミニレビューを入れておく。このような作業をスケジュールの中に組み込んで明示すれば、設計の質を高く維持できるし、設計者全体（レビューする側もされる側も）のレベルも向上できる。
プロジェクトでは、作業が予定どおり進んでいるのか定期的に確認しなければならない。方法は２つある。まず１つは、期日に達したアクティビティが実際に終了しているかを調べることだ。遅れた場合には、原因を調べるとともに対策も実施しなければならない。もう１つは、タスク単位で使用時間を観察する方法だ。10時間で終わる予定のタスクに、20時間以上もかかって終了してなければ、重要な問題が発生している可能性がある。そのタスクを重点的に調べることで、大きな問題を早目に発見できる。アクティビティの遅れで明らかになるよりも、かなり早く見付けられるメリットがある。少しでも早く発見すれば、対策を打つのは容易だ。費用に関しても、作業の進み具合と合わせて観察すれば、予算を越えるかどうかを判断できる。
以上のような目的をすべて満足するためには、開発全般に精通している必要がある。どこに問題が発生しそうか推測できなければ、優先的に行うべき作業を決められない。また、全部でどんな作業があるのかを知らなければ、プロジェクトの細かなスケジュールを立てられず、作業漏れで予定が狂ってしまいかねない。さらに、誰がどんな能力を持っているのか判断するのにも、技術力が必要だ。これらを総合すると、プロジェクトを管理するリーダーには、ある程度の高い技術力と管理能力の両方が求められる。当然、きちんとした開発の経験は必須だ。経験の少ない人を連れてきても、プロジェクトを失敗させるだけでしかない。プロジェクト・リーダーを決める際には、この点を十分に考慮する必要がある。
プロジェクト管理に関して、目的と概要を簡単に述べてみた。管理者の自己満足や記録を残すためとか、格好よく見えるからという理由で、プロジェクト管理を実施するわけではない。失敗できないプロジェクトだからこそ、何とか改善しようと試みているわけだ。プロジェクト管理とは、いろいろな工夫を盛り込みながら、リスクの回避と設計品質の向上を目指す道具である。結果として、プロジェクトが成功する確率を上げられる。難しい開発では、このような管理方法が絶対に必要なのだ。
（1997年10月31日）
プロジェクト管理：開発の成功確率の向上に貢献する |
