プロジェクトメンバーがそろう前に行っておく事前準備：ユーザーサイド・プロジェクト推進ガイド（14）（1/2 ページ）

業務部門からプロジェクトに人を出してもらう際、その人が来るまで手をこまぬいている必要はない。先にできる準備は、システム担当部門だけで進めておくことが大切だ。

　業務部門からプロジェクトチームに人を出してもらうことが決まってから、実際にその人がチームに参加するまでに、異動の事務手続きや引き継ぎなどのためにある程度の期間があります。

　プロジェクトの活動は、プロジェクトチームのメンバーが全員そろうのを待って、開始しなければならないということはありません。チーム編成の完了まで、何もせずに過ごすことはもったいないことです。貴重な時間は取り戻すことはできません。

　そこで業務部門からのメンバーを受け入れる前から、システム担当部署のメンバーだけでできる作業を進めておきます。この期間を有効に使うことで、ベンダに渡す見積要求仕様（RFP）（注1）を、より精度の高いものにできます。

未経験メンバーの即時戦力化

　業務部門からプロジェクトチームに参加した、システム開発の経験のないメンバーであっても、プロジェクトでは即戦力となることが求められます。この要求が満たされるか否かは本人の努力ももちろんですが、チーム側でも受け入れメンバーを速やかに戦力とする工夫をしなければなりません。

　プロジェクトがスタートすると、業務部門に業務プロセスや問題点などをヒアリングしたり、複数のベンダに見積もりを依頼したりといったさまざまなアクティビティが発生します。ところがこの段階になっても、経験あるシステム担当部署のメンバーは、既存システムのトラブルやメンテナンスに追われて、プロジェクトに十分かかわることが困難です。打ち合わせの最中であっても、トラブルが発生すれば中座しなければいけません。

　だからといって、打ち合わせそのものをキャンセルすることは、スケジュールが遅れることになるので避けなければなりません。プロジェクトには多人数がかかわっており、全員出席ではない打ち合わせだとしても出席者のスケジュールを調整し、日取りを決めることは大変です。1人欠席だからといって、すぐに打ち合わせをやり直すことはできません。そのため、既存システムのトラブル対応者を除いて打ち合わせを続けることになります。

　プロジェクトチーム内に組織されるサブチームは、システム担当部署のメンバーと業務部門出身のメンバーで組まれ、名目的にシステム担当部署のメンバーがサブチームのリーダーとなることが多いようです。しかし、実質的な主力は業務部門出身のメンバーで、彼らが中心となって各種の調査や業務部門とのヒアリング、打ち合わせを行います。

　しかし、業務部門出身のメンバーは、当然、コンピュータ・システムの開発に関しては素人です。いきなり、開発作業の主力となることは無理です。どのような作業が必要で、どのように進めればよいのか、考えなければいけないことは何か、調査した結果や考えた事柄をどのように表現すればよいか、などが分かりません。

テンプレートを準備する

　業務部門からメンバーを受け入れる前に、作業基準やルール、作成する資料や成果物のテンプレートを決めておきます。メンバーが全員そろってから、全員で話し合って決める時間はありません。プロジェクトリーダーだけで、あるいは、いまいるメンバーだけで決めていけばよいのです。作業を進める中で不備が明らかになれば、その時点で修正します。

　特に作成する資料や成果物のテンプレートは重要です。作成する資料や成果物とは具体的には、打ち合わせ案内や議事録、質疑応答の書類、機能要求仕様書、業務プロセスフロー図、画面や帳票のフォーマット図、項目の定義リスト（用語辞書）などです。

　これらのドキュメントは、ある作業の準備あるいは結果から作成されるものですが、テンプレートに必須の記述、あるいは記述が望ましい項目が記載されていれば、単純な記載モレや連絡モレを防ぐだけでなく､その作業において必要な項目に関する作業を忘れずに行うことができ、作業のやり直しなど、作業の無駄を省くことができます。

　例えば、テンプレートの中に「例外プロセス」「想定するトラブル」「関連システムの改善すべき機能」「詳細未調査事項」などの項目や記号があれば、ドキュメントを作成する際に、それらに注意を払うようになります。また、レビジョンによる変更項目を記載する欄があれば、自然にレビジョン管理の何たるかについても思い至るようになります。

　ほかにもテンプレートには、フォーマットが決まっていることで書き出しやすい、見やすいという利点があります。これは、ドキュメントの作成や閲覧のスピードアップに役立ちます。

手本を準備する

　ドキュメントのテンプレートだけを作っても、未経験の新メンバーには有効に活用することはできません。“知っている”だけと“実際にやってみる”ことの間には、大きな差があるのです。実際にドキュメントを作成するに当たり、テンプレートの使い方として参考になるサンプルがあれば大いに役立ちます。このようなサンプルを、業務部門からメンバーを受け入れる前に、システム担当部署のメンバーが作成しておくのです。

　サンプルはまったくプロジェクトに無関係な例題ではなく、プロジェクトで実際に作成・使用するドキュメントそのもの（の取り掛かり）として作ります。これらは資料や成果物の苗であり、業務部門出身の新メンバーがこれを大きな木に育てるのです。つまり、システム担当部署のメンバーがある程度資料を作成しておき、これを業務部門の出身者が引き継ぐ形にするわけです。これはシステム担当部署のメンバーの経験や知恵を、業務部門出身のメンバーが作業の中で自然に継承できるようにする工夫です。

　システム担当部署が忙しいからといっても、プロジェクトに割く時間がまったくないわけではありません。可能な範囲で時間を調達して、これから迎え入れる新メンバーのお手本となるような、素人にも分かりやすい、ドキュメントを作成しなければいけません。

　特に、コンピュータ・システムの更新プロジェクトであれば、システム担当部署のメンバーはシステムのメンテナンスを通じて業務知識やシステムの問題点をすでに把握しており、それを現状の資料にすることができるはずです。

　もちろん、最初から完成度の高いものを描こうとするとかなりの時間を費やしてしまうので、まずは簡単に描いていきます。調査の進展に伴って、テンプレート上に広く浅く、上塗りを繰り返すようにしていきます。

　なお、広く浅く描くようにするのは、システム範囲内の業務概要を早くつかんで、作業量を把握するためです。上塗りを繰り返すたびに精度が高まり、システム化の範囲や作業量を評価、調整するように意識付けしておきます。

　ドキュメントに使うアイコンなどの記号もこの際に部品として作っておき、すぐに利用できるようにしておきます。記号を描くことは結構な手間が掛かり、いちいち描いていると、思ったよりも時間を消費してしまいます。記号をあらかじめ準備しておくと、時間の無駄を防ぐことと、記号の統一性の確保にもなります。

　このように､業務部門からのメンバーを待たずに資料のテンプレートを作成し、実際に資料の作成を開始することには、

• 時間を無駄にしないこと
• 統一感のある見やすい資料ができること
• 業務部門出身のメンバーにとってドキュメント作成の参考となり、彼らが仕事に慣れるまでのチームの一時的な作業効率の停滞を最小限にできること
• 何より、システム担当部署のメンバーの経験や知恵を業務部門出身のメンバーに継承できること

などのメリットがあり、精度の高い見積要求仕様の作成につながります。