情報システム学会 メールマガジン 2010.2.25 No.04-12 [12]

会員コラム
情報システム目的達成の為にユーザ企業の上流工程対応力強化取り組みを!

「情報システムのあり方と人間行動」研究会幹事 渋谷照夫

 産業界では多くの企業が経営課題の達成に向けて、業務改革・改善に大変な努力をされていると思います。その手段として、情報システムの企画、構築、運用を計画に沿ってQCDを遵守しながら推進する必要がありますが、なかなかうまくいっていないのが現状と思います。
 少し古いデータですが、

・国内のSI・システム構築プロジェクトの平均成功率は31%
・納期遅れプロジェクトの原因として要件定義までの問題を挙げた企業は44%

(日経コンピュータ08年12月1日号より)の報告が出ています。
 ユーザ企業、ベンダ企業で、いろいろと努力をしているが両方が満足するケースは少ないのが現状と思います。

 この問題に関して、小職も実際に経験し痛い目に会い苦労してきておりますがケース事例と課題解決に向けた視点や対応策の概要をこのメルマガにて説明し、今後、討議してゆければと思います。

1.情報システム企画、構築でうまくゆかいないケース例
 実際に発生したケースのポイントからユーザ企業、ベンダ企業の満足状況について、以下に列挙します。この課題に取り組んでおられる企業の方々から見られると既知の問題と思われるかもしれませんが、確認の意味で記述します。

ケース1:重要な追加要件項目が抜け、ユーザ目的達成ができない。
要件が十分確定し切れない業務機能があることを前提に、契約上「概要設計(外部設計)終了後の要件・仕様の追加、変更は別途有償とし、スケジュールを見直しさせていただきます。」の条件を結んでいる。
システム開発が進んで、テスト工程中に重要な追加項目が発生したが、ベンダ側は契約を盾に、この追加要件を受け付けず、開発を終え納品した。
⇒その結果、システムはできたがお客様の目的通りに動いていない。結局、追加機能を入れることや運用見直しを必要とし、お客様は何とか少ない費用で対応してくれないかとベンダ側へ申し入れる。
【両者の状態】
ユーザ:×顧客不満足状態、ベンダ:△直接の非はないが悪影響を受ける

ケース2:追加要件対応で、ベンダのPJ採算が悪化

ケース1と同様の契約条件において、開発製造工程の途中で工程追加項目を対応したがスケジュールの変更、追加費用の請求ができなかった。
⇒もともとの開発項目でベンダ側のスケジュールに一部遅れが発生し回復中ではあったが、それが弱み、引け目となった。スケジュール、費用の変更を要求したがお客様から貴社を信頼してお願いしているのだから、見積書の条件に書いてあってもなんとかやってほしいと押し込まれ、ユーザとの関係を悪化させたくないとも思いからやむを得ず対応した。
【両者の状態】
ユーザ:システムは稼動、ベンダ:×プロジェクト原価率が悪化し不満

ケース3:お客様の体制が弱く、適切なRFP、要件を提示できない

ベンダ側では見積もり、提案の受注案件審査会で、顧客の体制が弱い、RFPが十分レビューされていないなどの理由から不合格にした。この案件は業務要件が十分固まっていないのでリスクの大きさが不明なので受けないとの判断をした。
⇒一旦、提案を拒否した。(後に、再考し、条件をつけて提案した。)
【両者の状態】
ユーザ:△受けてくれるところへ発注、ベンダ:×オーダが入って来なくなる(発注を受けたベンダが被害を蒙る可能性あり。受注条件、スコープを明確にして受ければ、問題回避の可能性は高まるが。)

2.上流工程プロセスの課題
 上記のケースのような、いわゆる上流工程:要件定義までに起因する情報システム企画、構築での問題の原因はいくつか考えられるが集約すると以下の2点がポイントで課題と考える。

1つ目のポイント:
 そもそもの経営の課題、それに基づく業務の現状と改善後の姿が正しく定義認識されているか、そして、そのGAPを埋めるために業務プロセスの改善、情報システムの改善項目が要件として正しく定義されているかの問題がある。
 システムの要件定義までが適切な目的手段分析や因果関係分析に基づいたプロセスを経て実施されているかがポイントである。

2つ目のポイント:
 このプロセスを難しくしている大きな原因として、情報システム企画構築に関わるステークホルダ、とりわけ、ユーザ側とベンダ側の役割分担とスキルの問題である。本来、お客様のシステムであるから、企画、要件定義、設計、製造、評価までをお客様が中心にリーダシップを図り責任を持って実施すべきである。
 少なくとも要件定義や外部設計まではお客様が実施することが望ましい。しかしながら、ユーザの情報システム部門の体制がまだ十分でないことが多くベンダ側に頼っているケースが多い。

2つ目のポイントの役割分担について、5つのモデルパタンに分けて以下に示す。(情報システム学会総会・09年5月・JUAS殿発表資料より)

 これは、情報システム企画開発における役割を大枠で、次の5つの工程
(戦略企画、要件定義、外部設計、内部設計、製造)でユーザ:U、ベンダ:Vのどちらが役割責任を持って遂行するかを定義したものであり、プロジェクト企画時にどのタイプパタンを選択するか明確にして始めることが重要であるとしている。当然であるが、モデル2から3へを目指してゆくことが望まれる姿である。お客様のレベルに応じた役割分担、契約方法を適切に選択してゆくことが重要である。

 モデル1 IT利用模索PJ
       戦略企画→要件定義→外部設計→内部設計→製造
       U    U/V  V    V    V

 モデル2 標準モデル
       戦略企画→要件定義→外部設計→内部設計→製造
       U    U    V    V    V

 モデル3 米国型インハウス・モデル
       戦略企画→要件定義→外部設計→内部設計→製造
       U    U    U    V    V

 モデル4 先進企業モデル
       戦略企画→要件定義→外部設計→内部設計→製造
       U    U    U    U/V  V

 モデル5 Win−Winモデル
       戦略企画→要件定義→外部設計→内部設計→製造
       U/V  U/V  U/V  V    V

3.対応策の視点
 前述した3つのケースのようなどちらか又は両方が不満足な状態になる結果をなくす、減らす意味で、上流工程でのユーザ側、ベンダ側双方での工夫、努力が必要であり、下記の視点で対応策を実施してゆくことが重要と考える。

 ・本来の役割分担であるユーザ側中心での役割になってゆくこと
 ・要件定義工程までのプロセスや成果物が標準化されてゆくこと
 ・要件が部門内上下・関係部門間で十分レビュー・承認合意がされ品質担保されること

 これらの視点の対応策については、特に、ユーザ側・情報システム部門が主体的に実施できるようになるための支援強化が必要であると考える。また、この課題解決を追求してゆくと、企業の組織体質、意思決定ルール、経営者の考え方など企業文化との関係まで入り込む必要があると思われる。

 本テーマについては、本情報システム学会でも幾度か議論はされているが明確な方向性や施策は課題になっていると認識しております。今後、課題解決の方向性や方策を打ち出してゆくことを目指して、研究会、シンポジウム等の場で討議してゆきたいと思います。