ベンダ任せにしないで情シスもPDCAサイクルを回せ！：情シスをもっと強くしよう（4）（2/4 ページ）

[小林 博，＠IT]

DualPDCAで問題解決スピードを速める

　筆者の会社では、ユーザー企業に入ってプロジェクト遂行を支援する中で、「情報システム部門がどうやってプロジェクト管理にかかわっていくと良いのか？」という指針として、「DualPDCA」という考え方を提案しています。

　DualPDCAというのは、プロジェクト管理のPDCAサイクルを発注側でも回していこうという考え方です。

　PDCAサイクルとは、「計画（Plan）」「実行（Do）」「評価（Check）」「改善（Act）」のプロセスを繰り返すことによって、継続的に業務改善活動を推進するマネジメント手法で、これまでこのプロセスはすべて開発ベンダが回していました。

　これに対してDualPDCAでは、PDCAサイクルのうち、作業手順やスケジュールといった計画（Plan）とその実行状況の確認（Check）を情報システム部門と開発ベンダが一緒に行いながら、それぞれに役割分担された作業の実行（Do）や、問題解決（Act）を繰り返していくという考え方です。

　いままで開発ベンダ任せになっていたプロジェクト管理を、プロジェクトの進行の要になる部分については情報システム部門が積極的にかかわり、開発ベンダが無駄な時間を浪費しないようにするのが目的です。

図1：DualPDCA

　プロジェクト進行中に発生する課題は、多くの場合で利用者であるユーザー部門との調整が重要になります。

　例えば、「仕様確定をいつ行うのか？」といった課題に対しては、ユーザー部門はできるだけ時間をかけたいといい、反対に開発ベンダはできるだけ早く確定したいといいます。

　ほかにも、ユーザー部門の要望通りに開発を進めると、当初の見込みよりも工数がかかるような機能があった場合に、開発ベンダはより工数のかからないような要件への変更を打診してきます。このような課題の調整を開発ベンダに任せていると、開発ベンダとユーザー部門の両者が自分たちの利害を譲らず、なかなか決着しないという事態になりがちです。

　このような両者の利害が関係する課題の解決では、両方の立場を理解することのできる情報システム部門が行動を起こさなければなりません。

　開発ベンダに対しては、ユーザーテストの段階になって仕様追加や仕様変更が発生した場合でも、対応できる計画を考えてもらうようにします。ユーザー部門に対しては、システム開発では仕様の確定が重要であることを説明し、理解してもらうように働きかけます。

　このように情報システム部門が計画の策定や、問題解決に積極的にかかわることによって、問題を放置したままにすることなく、問題解決のスピードを早くすることができます。

プロジェクト計画書の作成を共同で行う

　DualPDCAの進め方の拠り所は“プロジェクト計画書”に置きます。

　大抵の場合、プロジェクト計画書は開発ベンダがプロジェクトの開始時に、要件定義や基本設計といった開発工程の進め方や、開発工程ごとの成果物の定義、開発ベンダの作業スケジュールや、開発ベンダ側の技術者の体制について説明を行うために作成されます。

　内容はシステム開発の規模によって分厚かったり、少なかったりしますが、多くのプロジェクトで「開始時に1度だけ説明が行われて終わり」となるのを筆者は見てきました。

図2：プロジェクト計画書
1．プロジェクト概要		2．プロジェクト計画		3．プロジェクト管理手順
背景		開発方法		進ちょく管理
目的		作業計画		課題管理
範囲（スコープ）			工程定義と主な成果物	リスク管理
	対象業務（対象ビジネス）		WBS	障害管理
	関係する組織・関係者	スケジュール		仕様追加・変更管理
	システム構築の範囲		マイルストーン	構成管理（文書管理）
調整事項（制約事項）			概要スケジュール	コミュニケーション手順
	外部関係者との調整		詳細スケジュール
	既存システムへの影響箇所	体制
予算			体制図と役割
	システム構築予算（見積もり）		役割分担・責務
	予算計画		要員計画
リリース計画		会議体
			要件定義・設計作業の会議体
			プロジェクト管理の会議体
			ベンダ側会議体
		開発標準

　DualPDCAではこのプロジェクト計画書を、開発ベンダの振る舞い方やユーザー企業側のやるべきことをお互いに決めたルール集として位置付けます。

　計画する項目は、通常のプロジェクト計画書と変わりませんが、内容や作成過程が異なります。計画書の内容にはユーザー企業と開発ベンダとの両方のルールが記載され、計画書の作成ではユーザー部門も巻き込んで、ヒアリングやセッションを実施して決めていきます。開発ベンダ視点の計画ではなく、ユーザー企業側の視点も取り込んだ共通の計画を作成する点がポイントです。

　ユーザー部門、情報システム部門、開発ベンダが一緒になって作成することで、お互いの考え方を確認します。また、お互いの約束事や協力が必要な部分をあらかじめ合意し、プロジェクト進行中に問題が発生したときにも協力して問題解決に当たれるようにします。

　なお、開発ベンダの中にはPMBOKや、あるいは開発ベンダ社内の規定として定められている膨大な項目を網羅した計画書を作ってくる所があります。しかし、ユーザー企業側と開発ベンダ側が取り交わすプロジェクト計画書では、このような事細かなものを作成する必要はありません。

　必要なのは、ユーザー側と開発ベンダ側との間で関係する部分に対してのルールを決めることです。事細かなプロジェクト計画書はいままでどおり開発ベンダ側で作成して、開発ベンダの内部管理で使ってもらえばよいでしょう。

　このあと、DualPDCAで作成するプロジェクト計画書の記述内容について紹介していきます。