なぜ今、共通フレームなのか
産業界にはたくさんの課題があり、これを解決するための国際標準のひとつにSLCP（ソフトウェアライフサイクルプロセス）があります。共通フレームとは、このSLCPをベースに日本国内のユーザーおよびベンダーらが集まり審議して拡張したものです。ライフサイクルですから、企画・開発・運用を中心に置いてすべての観点に対して作業項目を出すだけではなく、誰がそれを行えば成功に至るのかといった役割分担まで、今回の共通フレーム2007では、産業界の総意として情報を発信しています。
かつては社長室直下の電算室にきちんとした業務マニュアルがあり、きちんとしたルールがある中で、その見える世界をシステム化するというのが開発の流れでした。しかしITの利活用が拡大し、ITが身近で当たり前の今の時代では、いわば見えない世界をシステム化しろというリスクの高い仕事が当然のごとくやってきます。しかもお客様の業務も社内システムも、すべてはITに支えられている時代ですから、ITが停止するとビジネス全部が止まってしまうというところまできてしまった。
即ち今の時代では、システムの信頼性向上こそがITガバナンスの最重要課題であって、経営者がシステム部門に対して「よろしく頼むよ」、ベンダーさんに対しても「よろしく」とだけ言っていれば事足りた時代ではないわけです。経営者自らがそこに関与しなくてはいけない時代になっているのです。
失敗の大半は上流工程が原因
さて、プロジェクト失敗の事例を集めてみますと、上流工程に問題ありと思えるものが数多くを占めます。例えば、米国では上級管理者がプロジェクトマネージャーに向かって、次のプロジェクトを安い予算で仕上げたら君の給料を3倍にするよとプレッシャーをかける。すると少なめな予算でスタートし、当然必要なレビューが省略されテストもなくなる。結果として失敗は必然です。そんなことが日本でも起きているのではないでしょうか。
QCDのいずれで見ても、失敗の原因の50％以上がいわゆる上流工程、要件定義以前にあると断言できます。ユーザーのあいまいな要求が経営リスクの問題や見積りの問題、あるいは契約の問題を引き起こしています。
共通の言葉、物差しとしての共通フレーム
さらには、言葉の定義や解釈の違いに起因する類の、従来からの問題もあります。今回のセミナーは「測る化」をテーマにしていますが、そのベースになるべき作業項目の定義がきちんと定まっていなければ、計測したデータを比較検討することはできません。例えば、基本設計にどれくらい時間がかかるかといっても、基本設計の中味が異なればかかる時間を比較しても無意味です。したがって「測る化」の前のベースづくりがSLCPということが言えます。
また、技法とかツールが様々に存在しますが、作業標準とこれらがどうリンクするかという問題もあります。作業標準にぴったりとしたツールなら使えるが、そうでない場合は使いにくいといった問題も発生しています。
これらの問題を解決するために、共通フレームは10個のポイントを掲げてその解決策を提示しています。
