「超上流ITガバナンスから見た共通フレーム」: SEC 菊島靖弘氏 (IPA/SEC)
について、レポートします。こちらも大変有意義な講演でした。
【IT開発力が企業競争力を決める】
金融機関は今どのような状況でしょう
・システムがなければ商品はマーケットに出せない
・システムの生産性が企業競争力を左右する
・保険会社などでは保険を売るだけではなく、
保険口座といったシステムが実現する仕組みを売っている
・IT開発は本業となった
・....
いかがでしょうか。ITなくして金融・保険はビジネスが成り立ちません。
保険商品とはソフトウェアそのもの(少し大げさ)になっているようです。
某保険会社では、毎年約3,000件の開発案件が出るそうですが、実現できるのはその約10分の1の300件程度だそうです。それでも毎年約300件の保険商品(ソフトウェアがそれを実現します)があるということです。
これだけ、ITがユーザ企業のビジネスの成功のカギを握っていると言っても過言ではないと思います。
ところが、経営者からは情報システム部門はどう見られているのでしょうか。
菊島氏発表資料より
この程度にしか見られていない、と嘆いておられました。少しお気の毒に思います。
CIOとはその程度の存在なのでしょうか。
その原因は何でしょう、後で少し触れたいと思います。
それだけではありません。現実の情報システム部門のIT開発能力は減衰の一路を進んでいるようです。30年くらい前は、企業のシステム開発はすべて内製していたそうです(筆者のいた組織でもそうでした)。ですが、最近のユーザ企業のIT開発力のレベルの低さは目を見張るものがあります。以下のプレゼン内容をご覧ください。
菊島氏資料より
【ユーザーのIT開発力は落ちている】
RFPによる役割分担(JUAS IT動向調査2004)
・RFPはユーザ企業が作成 16%
・ベースはユーザ企業が作成し、細部の作成はベンダに委託 33%
・ラフなRFPはユーザ企業が作成、あとはベンダに委託 41%
・すべてベンダが担当 9%
ここまで来てしまったのか、という驚きが強いです。もはやユーザ企業はRFPを自分では作れなくなっています。約半分が、ラフな要求仕様だけまたはすべて丸投げ、という状況です。
さらに、次のスライドをご覧ください。
菊島氏発表資料より
驚きの数字ですが、2004年の調査での事実です。
1位と2位の数字を合計しサンプル数(n=621)で割ると、aは52%、bは39%となります。
すなわち、システム仕様の定義が不十分のまま発注したのが52%、RFPを提示しなかったのが39%あったということです。これはユーザのIT開発力は落ちていることの証拠です。これではシステムの不具合が増えるのも当然と言えます。また、ITベンダーにとってはむしろチャンスと見ることも可能です。顧客の情報システム部門の能力が下がっている時こそ、ITベンダーの腕の見せ所かもしれません。
ユーザ企業として、課題を解決するためには、
【プロセスを見直し
IT構想力と構築力(実現力)を
取り戻さなくてはならない】
ごもっともですね。そのために、
【超上流からプロセスの強化が必要】
となります。
そして、具体的な方策として出されたのが次のスライドです。
菊島氏発表資料より
いわゆるSLCP(Software Life
Cycle Process)2007ということになります。
菊島氏発表資料より
特にこの日のテーマである「要求」に関連する、新しい「企画プロセス」と「要件定義プロセス」を紹介していただきました。「共通フレーム98」ではなかった、超上流工程の2つの新しいプロセスが「主ライフサイクルプロセス」に追加されました。
なお、各プロセスに関しての具体的な内容は「共通フレーム2007」をお読みいただければと思います。
【清水のまとめと提言】
最近のビジネス(特に金融・証券分野)では、IT(ソフトウェア)が金融商品そのものを構築することが多くなっています。東証の次世代システムもそうです。金融・証券に限りません。製造業でもSCMなど製造・流通プロセスはITに大きく依存しています。製薬ではITのサポートなしでは、新薬開発ができません。すなわち、現在の企業活動そのものがIT抜きには語ることができないほど、その重要性は増してきているのです。言いかえると、システム開発の超上流工程はユーザ企業のビジネスニーズ(もしくは事業計画)に他ならないということです。そして、超上流工程を成功するためには、ユーザ側と開発ベンダー側の双方の努力が不可欠になります。その共通の言葉を話すための枠組みとして「共通フレーム2007」があります。
ユーザ企業側は「共通フレーム」だけで良いのでしょうか。「企画プロセス」を有効に実施するためには、情報システム部門の戦略が必要ではないでしょうか。限られた資源(特に人材)を、どの分野(企業内のどの事業にどの程度)に投入するかを考える必要があります。どの事業分野のパートナーとなるべきでしょうか。事業部ではまだ気がつかないていないことで、ITを活用すればもっとビジネスがうまくいくような分野を見つけ、そこにリソースを投入するのがよいと思います。戦略的にインソースする部分です。逆に戦略的にアウトソースする部分も決めなくてはいけません。外部ベンダーとの役割分担(協調)が必要です。その場合は外部ベンダーも情報システム部門のパートナーになってもらう必要があります。そこでは「共通フレーム2007」が役に立つでしょう。
逆に、戦略がないとどうなるのでしょうか。事業部門からの依頼をこなすという、受け身の仕事になりがちです。 その結果、コスト削減のことばかり考えさせられる組織になり下がってしまうのではないでしょうか。前述の、経営者からは「コストセンター」としてしか見てくれないのも、戦略がないことが大きな要因だと思います。これではCIOの存在価値はありません。逆にそれだけ戦略を持つ必要があるということになります。戦略的に、フォーカスした事業をサポートしパートナーシップを確立して初めて、企業内で情報システム部門が戦略的ポジションを得ることができるのです。それができるのが本当のCIOではないでしょうか。そうすれば戦略的に人材を育成することも可能になり、組織としての価値を高めることができるようになります。
戦略を策定するためのヒントとして、本連載に掲載した「情報システム部門戦略」を参考にしていただければと思います。もしくは、以下の弊社Webページをご覧ください。
URL: http://www.kbmanagement.biz/sub80.html (前編)
URL: http://www.kbmanagement.biz/sub81.html (後編)
一方、開発ベンダー側はITスキル標準でスキルの向上を図りますが、ITSSで規定されている11の職種ですべてカバーできるとは限りません。特に上記のようなユーザ企業のパートナーとなるためには、UISS(ITSSではありません)で規定されている機能/タスクを肩代わりできる能力・スキルが必要になります。顧客であるユーザ企業の情報システム部門の仕事の一部(もしくは特定業務そのもの)を肩代わりできるようにならなければ、真のパートナーとは言えないと思います。そのためには顧客ユーザ企業のビジネス領域(事業計画)まで理解し、顧客ビジネスの成功につながるようなシステム提案ができる能力が期待されています。顧客ビジネス(事業計画)に貢献するシステム提案のできるスキルを身につける必要があるのです。
最後に、ユーザ企業、開発ベンダーともに超上流工程を成功に導くための、研修コースをご紹介します。このWebページでもご紹介しています「失敗しない要求定義」コースです。
コースの背景についての解説です。
URL: http://www.kbmanagement.biz/sub61.html
大変アクセスの多いページですので、すでにご覧になっている方もいると思います。
研修コースの概要です。ご覧頂ければ幸いです。
URL: http://www.kbmanagement.biz/req_def.html
特に最初のモジュール「顧客のビジネスを知る」の学習目標は次のようなものです。
SWOT分析とLogic Treeにより、RFPに書かれていない重要なビジネス要求を
顧客に気づいてもらうことができるようになる(差別化する)
開発ベンダーにとっては顧客のビジネスを理解し競合と差別できるようになります。またユーザ企業の情報システム部門にとっては、社内顧客である事業部のビジネス要求を明確にすることができるようになるものです。このコースにより、ユーザ企業の情報システム部門にとっても、開発ベンダーにとっても、超上流工程を成功に導くために必須なスキルを身につけることができるようになります。
最後は我田引水になりました(笑)が、ご参考になれば幸いです。
【前編に戻る】
|