第8回　やってはいけない、「製造工程」の丸投げ：キーワードでわかるシステム開発の流れ（3/3 ページ）

» 2008年03月18日 12時00分 公開
[高田淳志，株式会社オープントーン]
前のページへ 1|2|3 　　　　　　

3. プロジェクト費用・納期の迅速な調整・決定

　こちらも開発担当者側ではどうしようもありません。実現要望が想定以上に膨らんだ場合にどのような対応をするか、あらかじめ方針を立てておくとよいでしょう。例えば、開発開始に先立ち「開発方針」という形で次の点を明示して合意しておくと良いでしょう。

【実現要求への対応方針】

　

（ア） 納期・費用の制限なく、すべての要求を実現することが最優先

（イ） 納期・費用の制限を超える場合は、実現方法を十分に検討し、より低いコストで実現

（ウ） 納期・費用の厳守を前提として、実現優先度の高い要求を選択して実現

　

【実現方法への対応方針】

　

（ア） 納期・費用の制限なく、すべて設計仕様通りに実現することが最優先

（イ） 納期・費用の制限を超える難易度の場合は、実現方法を十分に検討しより低いコストで実現

（ウ） 納期・費用の制限を超える難易度の場合は、実現コストを加味して実施の是非を再検討



　これらを合意してもあいまいな部分は残るかもしれませんが、それでも、発注担当者側で何を最優先にしているのか（とにかく実現させたい、費用の枠内で実現させたいなど）という認識を確認する機会にもなります。

進捗確認を分かりやすくするため

　これまで説明してきた内容のように、「レビューを頻繁に行う」「社内決定プロセス・体制を確立する」など発注担当者側で引き受けるべき仕事に対する準備ができたら、後は「さあ、思う存分、製造作業をバリバリ進めてください！」という状態ですね。これで準備は整いました。後は、製造作業が順調に進んでいくことを、時に支援しながら見守っていく段階となります。特に、製造工程においては、進捗（しんちょく）状況の推移を確認していくという監視作業が必要です。

　製造工程だけでなく、ヒアリング作業、設計工程や最終的な試験作業など、一般的には開発担当者側から詳細なスケジュール（実行プラン）が提示されているはずです。大きな工程をより小さな工程に分割したタスクの集合からなるスケジュール表（いわゆる「スケジュール線表」）が多いと思います。

ALT 図3 タスク一覧表示形式でのスケジュール表

　スケジュール表中にどのような項目が記載されるかは分かりませんが、達成度に関して、「○○部分は80％完了です」と報告を受けても、感覚的に100％に近いからほぼ終わりってことかなぁという気はしますが、実際にどれ程ゴールに近づいているのかが分からないものです。

　進捗状況を客観的にとらえるために、開発担当者（主に、プロジェクトマネージャの役割）に次の点を求めてみましょう。

1. 進捗率の各数字はどのように算出しているかの説明

　

2. 各タスクを成果物ベースで目に見える形で分割



　例えば、「1. 進捗率の各数字はどのように算出しているかの説明」についての一例として、資料作成を行うタスクであれば次のような判定基準があれば、「80％完了ということは、レビューが完了し修正中なのだな」ということが具体的に分かります。実際に作業時間を案分（基準となる数量に比例してモノを分けること）したものではないかもしれませんが、この達成率の報告目的は、発注担当者側と開発担当者側で「何がどこまで完了したか」を共有するための指標なのですから、この程度で十分だと思います。

【資料作成タスクの達成率報告基準】

　

1. 初期作成が完了……60％

　

完了するまでは、その時点での完成割合を示す。全体の半分ほど完了であれば60％×1/2＝30％完了

　

2. レビュー実施中（ドキュメント確認中など）……70％

　

3. レビュー実施の完了……80％

　

4. レビュー後修正の完了……90％

　

5. 顧客へのレビュー依頼や送付の完了……100％



　次に、「2. 各タスクを成果物ベースで目に見える形で分割」については、まさしくプロジェクトマネージャとしての知識・経験が問われるところです。機能名や作業名ではなく、そのタスクによって得られる成果物を細かい粒度にブレークダウン（細分化、分割）します。下記のタスク例をご覧ください。タスク例2の方が分かりやすいと思います。また、例にあるように、開発担当者側だけでなく発注担当者側のタスク（レビューや承認など）についても併せて記載してもらうようにすると、何がボトルネックで作業が停滞・中断しているのかという確認に使用できる資料にもできます。

No. タスク名
3. プログラミング
3.1. 注文機能開発
3.2. 発送機能開発
3.3. 在庫機能開発
タスク例1：粒度の粗いタスク分割

No. タスク名
3. プログラミング
3.1. 注文機能開発
3.1.1. 画面デザイン案作成＋顧客承認
　 プログラミング＆テスト
　 顧客レビュー
3.2. 発送機能開発
　 （省略）
3.3. 在庫機能開発
　 （省略）
タスク例2：作業レベルに細かい粒度としたタスク分割

“正しく作る”のは大変

青木室長　「赤井君、どの工程まで進んでも、相変わらず私たちは楽にならんね（苦笑）」

赤井君　「仕方ないですよ。今回のプロジェクトの中では、私たちがわが社の代表として開発ベンダと接しているわけですし、何せ私たちのプロジェクトなのですから。それとも、いわゆる“丸投げ”の方がよかったですか？」

青木室長　「いやいや、そういうつもりでいったのではないんだよ。システムを作るってことは本当に大変なことなんだなとあらためて思っているところさ」

赤井君　「単に“作る”だけならそうでもないのかもしれません。けれど、“正しく作る”ことを目標にするのであれば、やはり、私たちも真剣に最後まで取り組まなければなりません」

青木室長　「そうだなあ、いろいろ勉強になるよ」

赤井君　「完成まで気を抜かずに頑張りましょう！」

　今回説明した製造工程は、発注担当者からは最も距離感のある工程といえ、直接的に参加できる場面はそう多くありません。最初に伝えたように、どちらかといえば支援的な立場で開発側の作業進行を見守る……といったスタンスで臨めば、それでも十分に開発進行に貢献しているといえると思います。

製造工程に関してより知識を深めるためのリンク集
企業システム戦略の基礎知識（10）　紛争勃発に備えよ！──受け入れ検査時のトブル対策
企業システム戦略の基礎知識（13）　ウォークスルーで新システム、新業務のイメージ共有
明日からできるプロジェクト管理（1）　デスマーチを止める進ちょく管理の現実解

筆者プロフィール

高田 淳志

株式会社オープントーン


「キーワードでわかるシステム開発の流れ」バックナンバー
前のページへ 1|2|3 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ