【IT開発力が企業競争力を決める】

　　金融機関は今どのような状況でしょう

　　・システムがなければ商品はマーケットに出せない

　　・システムの生産性が企業競争力を左右する

　　・保険会社などでは保険を売るだけではなく、

　　　保険口座といったシステムが実現する仕組みを売っている

　　・IT開発は本業となった

　　・．．．．

いかがでしょうか。ITなくして金融・保険はビジネスが成り立ちません。

保険商品とはソフトウェアそのもの（少し大げさ）になっているようです。
言いかえると、IT（ソフトウェア）が金融商品を構築することになっています。

東証の次世代システムもそうです。金融・証券に限りません。製造業でもSCMなど製造・流通プロセスはITに大きく依存しています。製薬ではITのサポートなしでは、新薬開発ができません。すなわち、現在の企業活動そのものがIT抜きには語ることができないほど、その重要性は増してきています。それだけ、ITがユーザ企業のビジネスの成功のカギを握っていると言っても過言ではないと思います。
言いかえると、システム開発の超上流工程はユーザ企業のビジネスニーズ（もしくは事業計画）に他ならないということです。

【超上流工程の問題】
それだけ重要なビジネス要求を発注側（ユーザー企業）はITベンダーにどれだけ正確に伝えているでしょうか。）


現実はこのようなありさまです。

ここまで来てしまったのか、という驚きが強いです。もはやユーザ企業はRFPを自分では作れなくなっています。約半分が、ラフな要求仕様だけまたはすべて丸投げ、という状況です。

さらに、次のスライドをご覧ください。

驚きの数字ですが、2004年の調査での事実です。

1位と2位の数字を合計しサンプル数（n=621）で割ると、aは52%、bは39%となります。

すなわち、システム仕様の定義が不十分のまま発注したのが52%、RFPを提示しなかったのが39%あったということです。これはユーザのIT開発力は落ちていることの証拠です。これではシステムの不具合が増えるのも当然と言えます。


【超上流工程の問題の及ぼす影響】
別の資料ですが、問題がプロジェクトに与える影響をみましょう。



システムプロジェクトの問題ですが、当然の結果ではないでしょうか。

・       品質問題　　53.6%

・       納期遅延　　45.1%

・       コスト超過　23.8%

では、品質問題と納期遅延の原因はどのようなものでしょうか。これも同じ日経コンピュータです。

システムの品質問題の原因

　　　　　　　　　　　　　（有効回答数：498件）

やはり「要件定義」が35.9%と圧倒的にナンバー1です。
仮説が裏付けられています。

それでは、納期遅延はどうでしょうか。

プロジェクトの遅れを招いた原因

　　　　　　　　　　　　　　（有効回答数：621件）

こちらも「要件定義」がナンバー1です。

ユーザー側が自分の要求をRFPで明確にできないのですから、システムの要件定義が不十分だったり、計画より長引いてしまうのは当然ですね。
その結果、納期が期限を過ぎ、品質も下がり、ひいてはITベンダーは赤字に陥ってしまっているようです。

ITベンダー側だけではありません。
発注側はもっと深刻ではないでしょうか。
最初の菊島氏のスライドをご覧ください。

【IT開発力が企業競争力を決める】

　　金融機関は今どのような状況でしょう

　　・システムがなければ商品はマーケットに出せない

　　・システムの生産性が企業競争力を左右する

　　・保険会社などでは保険を売るだけではなく、

　　　保険口座といったシステムが実現する仕組みを売っている

　　・IT開発は本業となった

　　・．．．．

そうです、システムができなければ、新たな金融商品を発売することができません。
本当に困るのは発注者（事業の担当責任者）なのです。会社として売上そのものも見えなくなります。ITベンダーが赤字になるだけでは済まないのです。発注者側の事業そのものがスタートできなくなります。決算数字に影響が出る可能性すらあります。
　さらに、ユーザー企業のイメージまでダウンしてしまいます。みずほ銀行のシステム統合のトラブル、東京証券取引所のシステムトラブル、．．．．枚挙にいとまがありません。新聞紙上をにぎわせることになり、会社のイメージ、信用が損なわれます。東証の場合は、「日本の国の信用」とまで言われてしまいました。




【問題解決の効果】

それでは、要求定義が正しく行われて、ビジネス要求ならびにユーザー要求を明確にする事ができればどのようなメリットが出てくるでしょうか。

まず、ITベンダー側のメリットとしては以下のものです

・     仕様/要求定義フェーズで発生する欠陥の減少

・     開発手戻りの減少

・     不要な機能の減少

・     機能拡張コストの低下

・     開発期間の短縮

・     コミュニケーション不良の減少

・     スコープクリープの減少

・     システムテストの見積もりの正確化

・     顧客とメンバーの満足度の向上

ひいては赤字プロジェクトの減少につながることが期待できます。

また、発注側は事業がスムーズに開始でき、順調な売り上げが期待できます。
それだけではありません。要求開発の過程のおいて、ユーザー側の気付かない新たなビジネスチャンスが明確になることすらあります。そうなれば、発注側には予想外の売上向上の可能性まで期待できますから、飛躍的な顧客満足度の向上につながります。
これは、下の3種類のニーズを考えてみるとよく分かります。

基本的ニーズ（当たり前の品質）：

　−このニーズ（品質）が満たされないと、顧客は大変不満を持ちます。

しかし、これが満たされていても何も感じません。

　−顧客は自分からこれが満たされないと不満だ、とも言いません（当たり前だからです）。

　☆インタビューでこのニーズを聴き出せないと致命的な問題が発生する可能性があります。

　例えば、自動車のバックミラーが必要だというお客はいませんよね。当たり前だからです。

　バックミラーのない自動車は明らかに欠陥車です。顧客がニーズを口にしなくても、聴きだすスキル、もしくは業界知識（常識）を開発側が身につける必要がある、ということです。

期待のニーズ（一元的品質）

　−これについて、顧客は自分から何が必要かを、話してくれます。

　−この機能が欲しい、これが満たされないと困る（不満）、と言ってくれます。

　☆どんなインタビューアでも聴けるニーズです。

　  インタビューでこれしか聴けない（受身の）ケースがあまりに多いと思います。

　　 これでは残念ながら差別化できません。

　　　自動車のエアーやオーディオ類。人によってニーズが異なります。

喜びのニーズ（魅力的品質）

　−顧客が気付いていなかった、特別付録です。大変喜んでくれます。

　−逆にこれが満たされなくても、別に不満に思いません（気付いていないからです）。

　　☆インタビューでこれが聴きだせると、差別化につながります。

　　　「失敗しない要求定義」コースではSWOT分析などにより、RFPで気がつかないビジネスニーズを
　　　見つけることができるようになります。またインタビューでは、質問スキルによりユーザーの気付か
　　　ない潜在ニーズを顕在化し、真のニーズ（喜びのニーズ）を明確にする事ができます。

【解決策として「失敗しない要求定義研修」】

■参加対象者　：　ユーザー企業：　RFP作成担当者
　　　　　　　　　ITベンダー　：　コンサルタント、ITアーキテクト、
　　　　　　　　　　　　　　　　　プロジェクトマネジャー

　　　　　　　　　　　　　　　　　（ITSSレベル3以上）

■プログラムの焦点：　何を修得するか？

顧客の要求を理解するため、ビジネス背景を明確にし、当該プロジェクトが顧客ビジネスの成功に、本当に寄与できるものなのかを確認できるようになります。そして顧客に真の要求（ＲＦＰに書かれていない部分まで）に気付いてもらえるようになります。インタビュー/ファシリテーションを通じて、さまざまな要求の重要度を明確にできるようになります。それらを正確に反映し、あいまいさを排除した要求定義書が記述できるようになります。

■     プログラムの方法論：　どのように修得するか？

　要求定義プロセスの流れにそって学習を進めます。講義だけでなく、演習、ロールプレイを交えて、実例に近い形で学習ができますから、効果的な学習ができます。

■     プログラムの展開

特に最初のモジュール「顧客のビジネスを知る」の学習目標は次のようなものです。

　　SWOT分析とLogic Treeにより、RFPに書かれていない重要なビジネス要求を

顧客に気づいてもらうことができるようになる（差別化する）

これにより、「喜びのニーズ（魅力的品質）」まで実現可能になります。

開発ベンダーにとっては顧客のビジネスを理解し競合と差別できるようになります。

またユーザ企業の情報システム部門（RFPを作成する立場の方）にとっては、社内顧客である事業部のビジネス要求を明確にすることができるようになります。

このコースにより、ユーザ企業の情報システム部門にとっても、開発ベンダーにとっても、超上流工程を成功に導くために必須なスキルを身につけることができるようになります。


【セミナー参加者の声】

−PDU取得のためにPMBOKの座学研修を受けるくらいなら、

　実務にも役立つこの研修を受けて、一石二鳥をすすめたい

−業務から離れ、改めて学ぶことで自分の悪さ（当然と思っていた）を

　みつけられた

−演習と通して実体験ができたこと。座学では分かったつもりで終わっていたと思う。

−要求定義を書けるつもりでいる人が多く、演習を通して反省してもらいたい

　経験レベルでとしてはマネージャクラス、またはマネージャ候補の人たちには

　是非参加していただきたい

−演習を通すことで、ティーチングで言われたことを実感でき、なおかつ

　頭で分かっているつもりで実際には理解していないことに気がついた

−ラーニング中心形式なのが非常に良く、多くの「気付き」「納得」が得られた

−他受講者の意見に触れることや、講義中に自由に意見を言いあえる雰囲気が

　よかった

　−演習が多く、あきなかった。　ロールプレイはなかなか楽しかった

　−要求定義のプロセスを広く網羅していただき、今までの復習も兼ねて、

　　とても有意義でした