TOP
＞
プロジェクト管理
＞ 成果物の作り方をリアルに共有
ユーザ納得のWin - Winプロジェクト管理
第２回：アクセル全開で臨むキックオフ
著者：
ウルシステムズ 村上 歴
2007/8/23
前のページ
1
2
3
次のページ
成果物の作り方をリアルに共有
会議は進み、今日の山場であるアジェンダの「3.全体スケジュール」に進んでいる。弁田氏は工程の定義の説明をしている。
弁田氏「今回、プロジェクト計画の中で以下の用語を頻繁に使うことになりますが、まず御社と弊社で認識をあわせておきたいと考えています。実際に前回の支援では、小さな規模のプロジェクトとはいえ、工程名やその成果物の名前などについてかなり認識のずれがあり、議論の焦点が合わないことが多々ありました」
弁田氏はプロジェクタにいくつかの用語を並べたスライドを映しながら話をしている。
弁田氏「まず、『キャッチアップ』『要件定義』、それから『基盤設計、方式設計、フレームワーク設計、アーキテクチャ設計』。これは言葉がゆれてますね。また、『共通部品』『共通ライブラリ』とよばれる類のものも、チーム間で浮いてしまってすわりが悪いものでした。あとは王道『プロトタイプ』ですね。さらにあいまいなのが『開発プロセス、開発標準、基準、規約』。また、データベース設計の進め方、数多くある『○○テスト』の区別、最後は『移行、リリース、サービス開始、本番開始』もぶれがあったように感じています」
結佐「そうですね。それから、ジョブの設計やデータベース設計、ネットワーク設計のような、現行システムとの整合性を保ちながら進めていかなければならないものについては、弊社の今の設計のやり方を掴んでからでないと、具体的な作業計画を立てることができないと思います。あと、似たような文書名がいろいろあり、議論したことがどの成果物にかかれるかよくわからなかったので、そこも明確にしたいです」
弁田「そういえば、『ロジック設計』も難産でしたね。何のことだか、やってみるまで意識が合わなかったですね」
いろいろと認識を合わせなければならない言葉があるようだ。
今回、弁田氏は以下のような成果物の全体像と、それらの詳細をとことん具体的（さすがに今日の範囲は上流工程にしぼっているが）に説明した一覧表を作成した。下流工程の成果物は、「プロジェクト計画書V2で語る」とのことだ。この発言にしても、成果物一覧がないとなんとも怪しい発言だが、一覧があれは納得感が増す。
図2：成果物全体像の例（上流工程分。一部は省略）
（画像をクリックすると別ウィンドウに拡大図を表示します）
表3：成果物の一覧（上流工程分。一部は省略）
（画像をクリックすると別ウィンドウに拡大図を表示します）
では、このような成果物一覧にリアリティを持たせる上で欠かせないポイントを以下にあげていこう。
1.何をどこまで書くのか／体裁／目次構成／ボリュームなどを明記する
成果物名だけでは説明したことにならない。例えばデータベース設計なら「論理設計のレベルです」ではなく、「業務上意識する項目、および設計に大きな影響を与える項目までを書きます。具体的には、日本語のカラム名まで出します。主キーは決めますが、型や桁数までは決めません。区分などは日本語での一覧まで出します。一方、あとから機械的に付与できる管理用の属性、FKやNOT NULLの制約もこの時点では書きません……」というレベルまで語るようにする。文章よりも、本物に限りなく近い成果物サンプルがわかりやすい。
また、どんな体裁（Word、Excel、Visioなど）で何ページくらいになるのかを書いておくと、それを作るのに必要な時間を本当に意識できているかが明確になる。さらに、ユーザ側も、放っておいては完成しないことが理解でき、完成させるために自分がどれだけ参加しなければいけないのかを実感できる。
2.成果物作成の具体的な方法／必要な打ち合わせ時間を明記する
ユーザ企業が参加するタスクは、できる限り具体的にしておこう。漠然と「課題を基に新業務フローを起こします」だと、いっている側もわかっていっているかどうか怪しい。
新業務フロー作成の進め方で説明すると、例えば以下のようになるだろう。
ブレインストーミングをしながらホワイトボードにフローを起こす
その段階で課題が解決できているかのチェックを全員で行う
合意できたものを開発ベンダーが清書する
業務が回るかどうかや、漏れ・抜けがないかを日次打ち合わせでチェックする
さらにヒアリングを実施してネタを集める場合、何時間のヒアリングを何回・何カ所でやるのか、議事録と課題一覧の関係はどうするのか、議事録はどれくらい体裁を重視するのか、誰にどう配布して合意を取るのか、といったこのように細かい所までエイヤで仮決めしておく。
実際は違うやり方になるかも知れないが「このままだとこうなる」というイメージまでを示しておけば、ユーザ企業側も注文がつけやすい。
3.レビュー担当者／対象者／メンテナンス方針を明記する
レビュー方法も明確にしておこう。毎日少しずつなのか、最後にまとめてなのかといったタイミングだけでなく、レビューする側にみて欲しい観点は何か、という点も重要だ。さらに、レビュー時にあわせて用意すべき成果物が同時に全部揃うのかや、作成する成果物のボリュームに対して適切な時間を確保できているかといった点まで定めておく必要もあるだろう。
こうしておくことで、レビューに思った以上に時間がかかり、最終決定権限を持つ偉い人の予定がとれず一週間作業が浮いてしまった、というような事態も避けられる。
また、成果物を読む対象は誰なのかも明確にしておくとよい。想定読者が不明確な場合はレビューがしづらいだけでなく、作ったものの結局参照されないといった事態が発生する可能性は高い。
最後に、よくみられる「途中でいったん仮の版を作り、プロジェクトが進んでからそれを改版する」ケースについて触れておく。この場合も、漠然と「随時更新」と書かず、随時とはどのような時で、何を受けて更新するのか、更新した結果をどのように周知するのかを明確にしよう。
一度やってしまえば負担は軽減できる
これまでの解説でわかるように、リアリティを出すためには詳細を語る必要がある。その重要性は理解したとしても、これを毎回続けるのはプロジェクトマネージャにとっては大変な負荷と感じるかも知れない。
とはいえ、本当にこのプロジェクトの各タスクを実施するのであれば、プロジェクトマネージャの頭の中には詳細が入っているはずだ。その上、開発ベンダーはこの道のプロであり、膨大な実績に基づく知恵を結集した社内の開発標準も持っている。本来は「それを書くだけ」で済むはずなのだ。何かの試験だと思って一度やってしまうと、それ以降はネタもできるので楽になる。
リアリティのあるプロジェクト像を描くことができれば、ユーザ企業側にとってもこれからやることが非常に明確になる。「なんでも開発ベンダーに任せるのではなく、要所々に自分たちも入らなければうまく進まない」ということが理解でき、タスクの期間や工数にも納得できる。
単に「お客様の参画が必要」というのではなく、リアリティを持って「このような作業をお願いします」という。こうやって同じ立場に立つことが、後々の対立を防ぐ上で重要な第一歩だと筆者は考えている。
さて、これらのポイントをまとめると以下のようになる。
プロジェクトマネジメントを助けるツール名：リアリティのある成果物一覧
効果：不透明になりがちな上流工程の作業内容が明確になり、ユーザ企業の参加意識と安心感が高まる
プロジェクトに対するユーザ納得度への貢献：★★★★☆
キックオフでリアルに描くべき項目、つまりユーザ企業と早めに共有しておいた方がよいポイントは他にも数多くある。例えばレビューの進め方や体制の変遷、発注の予定、仕様変更の吸収の仕方、サイジングの考え方などなど、きりはない。そこで、手間がかからない割に強力な管理ツールを1つ紹介しよう。
前のページ
1
2
3
次のページ
著者プロフィール
ウルシステムズ株式会社 村上 歴
シニアコンサルタント。8bit時代からのコアな技術屋であり今でもそのつもりだが、最近はパワーポイントの方が主な成果物になっている。「この矢印の意味は何ですか？」のように、文書を添削してくれるツールがつくれないか思案中。
INDEX
第2回：アクセル全開で臨むキックオフ
アクセル全開で臨むキックオフ
成果物の作り方をリアルに共有
日次スケジュール表は簡単便利
