PR

トラブルの要因

 開発プロジェクトには目的・目標があります。事務の効率化や新商品・サービスの提供、経営の精緻化、内部統制の強化などです。プロジェクト憲章などに定めた目的・目標に沿って、プロジェクトのスコープが定められているはずです。

 気をつけたいのは、目的や方針がお題目にとどまっていて、プロジェクトのステークホルダーに浸透していない場合があることです。そもそも目的や方針は、日常業務レベルまでブレークダウンされるべきですが、組織によっては、それが十分できていない場合があります。特に事務ルールは、問題が出れば責任を問われるのは現場ですから、現状のルールを変えることに抵抗があるのはやむを得ないと言えるでしょう。

 しかし、パッケージの導入を選択するのであれば、簡素化や割り切りは必須です。アドオン開発やカスタマイズは、開発コストだけではなく保守コストも押し上げます。煩雑になった事務を整理して、シンプルにするというせっかくのチャンスも失うことにもなります。スコープに関するあつれきは、看過できない、正しく解決すべきトラブルと認識する必要があります。

鎮火法

(1)目的・目標を再確認する

 まず、本来の目的・目標を取り戻しましょう。目的・目標は、本来プロジェクト憲章に定められているはずです(図2)。プロジェクト計画書やRFP(提案依頼書)に記載されている場合もあります。

図2●プロジェクト憲章を利用して目的・目標を正しく認識してもらう
図2●プロジェクト憲章を利用して目的・目標を正しく認識してもらう
[画像のクリックで拡大表示]

 「それは建前…」という空気は一掃して合意方針とします。ステアリングコミッティーのような経営層や上位職者が出席する場で再確認するとよいでしょう。

 もちろん、方針が現実的でないなら、見直すべきです。見直すなら公式に見直しましょう。担当者レベルで勝手に解釈することは許されません。方針が誤っているなら、「パッケージ導入」といったソリューションも誤っている可能性があります。そこを曖昧にしたまま、コストや時間をつぎ込むのは一種の背任行為です。きちんと見直して合意しておく必要があります。

(2)実務的な指針やプロセスを定める

 「簡素化」「BPR」「パッケージに事務を合わせる」といった包括的なスローガンだけでは、現場は判断できません。目的・目標・方針が明確になったら、それを実務的な指針とプロセスにブレークダウンします。

 パッケージ導入の場合、例えば「アドオン判定基準」などを定め、スコープの調整・決定をする会議体を設定したり、要望・変更管理表などの書式を整備したりすることが有効です。

 判定基準とは、「既存業務フローの変更で解決する場合、機能の作り込みは行わない」「年間10人日程度のハンド事務で代替できる場合はアドオン開発はしない」といった基本ルールの集合体です。これを定めて合意することで、方針を目に見える基準として機能させることができます。

 会議体は、プロジェクトとしてオフィシャルにジャッジ・決定することを目的に設定します。書式は、「代替事務」「運用による回避策」「既存事務の変更可否」「コスト」「リスク」といった判断要素を漏れなく俎上に載せるように整備するとともに、事務担当者、開発担当者、PM、責任者など、ステークホルダーの評価・承認が記録されるようにしておくといいでしょう。