ベンダ任せにしないで情シスもPDCAサイクルを回せ！

小林 博
ウルシステムズ

2010/3/2

前のページ｜1　2　3　4｜次のページ

1.プロジェクト概要―プロジェクトのゴールと制約を共有する

　プロジェクト計画書の最初の項目が、プロジェクト概要です。

　このプロジェクト概要で最も重要なことは、プロジェクトのゴールを共有することです。このために、背景や目的をまず明確にします。ゴールに対する認識がずれていると目先の課題に目が行き、ゴールには貢献しない機能を作りこんでしまうようなことが起きます。

　プロジェクト概要では、背景や目的以外にも、開発機能の範囲、調整事項、予算、リリース計画などを記述します。これらはいずれもプロジェクトを進めて行くうえでの制約や前提になるものです。

　この中でも特に気を付けなければならないことは、予算の使い方を共有することです。開発ベンダから、予算についてハードウェアやソフトウェア別の割り振り方、開発工程ごとのエンジニアの工数見積もりや、それに基づくコスト見積もりについて明らかにしてもらうようにします。

　開発ベンダによっては工数提示を嫌うところがあるかもしれませんが、コスト管理のためには工数がどれだけ消費されたのかを意識して、予定内に収まるように関係者全員で協力をすることが重要です。そのためには、どの作業がどういう根拠でどれだけ工数がかかるのかということを開発ベンダと共有します。ここでお互いの手の内を隠すようなことをしていた場合、結局、最後に見積もり内だったのかどうかで揉めることになります。

　このような目的や制約、かかるコストといったものは、開発ベンダとの間だけで共有するのではなく、ユーザー部門にもしっかりと意識してもらうことによって、要件検討で迷走をしないようにしてもらいます。

　こういった共通認識を持つように仕向けることができるのは、ユーザー部門と開発ベンダの間に立つ情報システム部門以外にありません。

表1：プロジェクト概要の内容で情シスが気を付けるポイント

項目 情シスが気を付けるポイント 背景 ・システム開発が必要になった背景や狙いが開発ベンダに伝わっているか ・課題や実現できなければならない機能が明確になっているか 目的 範囲 ・開発機能の範囲に漏れがないか。開始時点では漏れがありそうな場合は、開発ベンダに漏れている分が追加で入ってきた場合に備えた計画を考えてもらう 調整事項（制約事項） ・社内調整に時間がかかりそうな要件が伝わっているか ・ほかのシステムとの連携について、そのシステムの制約が明確になっているか 予算 ・技術者の作業工数とコストは明らかになっているか ・工数の見積もりの根拠は納得できるか リリース計画 ・構築システムのリリース日、リリース前後の計画や制約が明確になっているか

2．プロジェクト計画―自社に合ったスケジュールや進め方を決める

　2つ目の項目は、プロジェクト計画です。

　ここで示すのは、スケジュール、作業の進め方、体制など、どうやってプロジェクトを進めるかの計画です。この中で特に気を付けなければならないことは、計画を自社の特性に合わせてカスタマイズすることです。

　開発プロジェクトの事情は、会社ごとに異なっています。開発ベンダ任せで作られる計画は一般性の高いものであって、自社の特性、例えばユーザーが動くものを見てから新たな機能を思い付くことがあり、最後まで機能の見直しをすることが多いといったことは反映されません。

　しかし、実際に効率的に進めるには、このような特性を考慮した計画を立てることが非常に重要です。そうでないと、ユーザー部門からシステム開発の都合だけで進め方を決めていると思われ、プロジェクトの進行に協力を得られなくなることが起きます。

　これ以外にも、自社の開発経験を基にして、設計書や会議体についてもカスタマイズします。設計書であれば、ユーザー部門にはどんな書き方がされていれば分かりやすかったか、会議についても開発ベンダが自社に常駐し、毎朝短い会議を行った方がユーザー要件がまとまりやすかったかなどを考えて計画をします。

　ユーザー部門には一緒にプロジェクト計画書を作成している場で、計画についてコミットしてもらいましょう。

　ユーザー部門にとっては、システム開発は専門外であるため、進め方については無関心になりがちです。このような意識に対して、情報システム部門が働きかけ、システム開発の開発工程のつながり方や、それぞれの作業がどれくらい時間を費やすのかについて理解してもらい、スケジュール遅延が起きないように協力をしてもらいます。

図3：自社の特徴にあったスケジュール

表2：プロジェクト計画の内容で情シスが気を付けるポイント

項目 情シスが気を付けるポイント 開発方法 ・開発ベンダのプロジェクトマネージャやチームリーダーに、その開発方法での経験があるか。ない場合は体制の見直しをしてもらう 開発標準 作業計画（WBS） ・タスクの完了条件や、成果物や記述内容がはっきりしているか ・ユーザー側の作業内容や作業量は明確になっているか スケジュール ・作業期間が1カ月間となっているようなざっくりとしたタスクがないか ・仕様確定などのマイルストーンが明確になっているか 体制 ・ユーザー側、ベンダ側の体制と役割分担が担当者名まで明確になっているか 会議体 ・現場だけの会議体だけでなく、上層部も参加する会議体が計画されているか ・開発ベンダ内部で行われる会議体についても確認し、現場の問題がプロジェクトマネージャやチームリーダーにすぐに届く仕組みになっているか

前のページ｜1　2　3　4｜次のページ

	Page1 ベンダ任せがプロセスのギャップを生んでいる プロセスのギャップを埋めるのは情報システム部門
	Page2 DualPDCAで問題解決スピードを速める プロジェクト計画書の作成を共同で行う
	Page3 1.プロジェクト概要―プロジェクトのゴールと制約を共有する 2．プロジェクト計画―自社に合ったスケジュールや進め方を決める
	Page4 3．プロジェクト管理手順−問題解決のルールと手順を決める 最も必要なのは信頼関係

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）