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

一般的に予定通りにシステム開発が完了することはまれであり、追加コストやスケジュールの遅延が当たり前になっている。場合によっては機能をあきらめ運用でカバーすることさえ発生している。今回はこの状況を克服するために情シス部門が一緒にプロジェクト管理する方法を提案し、方法を紹介する。

[小林 博，＠IT]

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

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

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

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

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

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

図1：DualPDCA

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

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

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

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

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

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

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

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

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

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

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

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

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

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

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