プロジェクト自体は順調に終わったのにビジネスに貢献しないシステム。不具合がないのにユーザに使われないソフトウェア。システム開発プロジェクト自体の失敗もさることながら、無事終わったはずのプロジェクトでできあがったシステムが想定したものでない、使えない、という事例は少なくない。実際身近でも見かけるだろう。
反対に、プロジェクトも確実に進められ、できあがったシステムもユーザから喜ばれ感謝される例もある。失敗しがちなプロジェクトマネージャがいる一方、困難とみられるプロジェクトでも、恒に確実に成果を出すプロジェクトマネージャやチームがいる。
いったい感謝されるシステムと、そうでないシステムの開発では何がどう違うのだろうか。 この疑問に答えるために開発されたのが「ImprovAbilityモデル」である（注1）。デンマークで2007年に発表され、現在ISO/IEC TR 33014として審議が進められている（注2）。早ければ今年審議が完了すると予想されている（注3）。
動かないシステムはもちろんのこと、動くのに使われない、ビジネスに貢献しないシステムとなる原因について、成功事例と失敗事例を分析し、成功システムのポイントをモデル化・体系化したものである。16プロジェクトに関してインタビューなどにのべ1000名が関係して4年かけて開発された（注4）。
プロセス改善の功罪
簡単に現状の標準的なシステム開発の活動をふり返ってみる。
ソフトウェアプロセスインプルーブメント（SPI）が人口に膾炙して久しい。20年以上の歴史があるが、日本では特に21世紀に入り業界で注目され10年以上が経ち、ソフトウェア開発で「プロセス」及び「プロセス改善」の言葉が当然のように使われている。
SPIの代表的なモデルであるCMMI（Capability Maturity Model Integration：注5）は、システム開発失敗の主原因として、ソフトウェアの開発のプロセスに問題があることに着目し、ベストプラクティスをプロセス（プロセスエリア）ごとに体系化したモデルである。背景として、優秀なメンバを集め、良いツールを備えても、必ずしもプロジェクトが成功するわけでないことがある。その活用が広がっている様子は、CMMIに基づいた公式アプレイザル（診断）の数にも表れている（図1参照）。
図１ 日本における公式アプレイザル数の推移
「作った結果」（製品）だけでなく「作る過程」（プロセス）に着目するアプローチは、アドホックに開発を進める習慣が残っている現場の基本動作を確実にし、再現性のある作り方を実現することで、品質向上に寄与したことは間違いないだろう。
一方、CMMIをはじめ様々な取り組みがなされても、効果が実感できない、どうしても失敗プロジェクトがなくならない、なぜか使われないシステムができあがるといった感触も残り続けているのも現実である。冒頭で述べた課題である。
きちんとプロセスを組み立ててそれに従いプロジェクトを進めているのに、何かが欠けていることを示している。
「ImprovAbilityモデル」の視点
モデルの基本的な考え方は、”Being Ready”と”On-going Improvement” の実現である。
使えるシステムにするには、そのための準備を万端にし、プロジェクトの状況はいくら準備しても変わり続けるものと認識し、変化に即時対応して、開発するシステムを本来の目的から外れないようにすることである。基本的にITユーザの視点である。開発の仕組みを整えて安心するのではなく、システムごとに目的や関係者や状況などは様々であることを認識し、プロジェクトの組み立てのポイントを常に「考えて」押さえようとするものである。
ポイントとして、20個の視点（パラメータ）を抽出している（図2参照）。これらは大きく４つのカテゴリに分けられる。
図2 ImprovAbilityモデルにおける20の視点 （DELTA社資料より）
2 、3のパラメータを見てみよう。
例えば、Foundation（IT体幹力）における「期待管理」。これは、使われないシステムとならないために必須の視点である。また、Initiation（IT構想力）における「危機意識」。これは、システムの必要性を適時適切に感知することだが、なぜそのシステムが必要かを明確に認識する重要な活動である。同様に、IT構築力、IT活用力として、必要となれば常にシステムの本来の目的に立ち返り、意識し、さらに実際に使われる状況を想像して、システムを実現するための一連の基本的な視点が示されている。
一つ一つ良く見ると、これらは、熟練したプロジェクトマネージャが常日頃はずさないように心がけているものだと分かる。何だ、当たり前のことをまとめているだけじゃないか。普段気をつけていることそのものだ。そう感じる人は、優秀なプロジェクトマネージャである。しかし、当たり前なものを当たり前と考えて、当たり前に実践することがいかに難しいか。これが現実である。
「ImprovAbilityモデル」の特徴
このモデルの特徴は、その視点だけでなく、課題があればその解決方法を示唆するところである。これは他のモデルにはない特徴である。
また、モデルというものが一般に網羅性を追求する中で、現在進行のプロジェクトの課題を解決するために、できるだけ効率的な、すなわち、重点を置くべきものをあぶりだして、対策をとろうとする点が特徴的である。
当たり前のことを当たり前にできるように手順を含めて体系化している。
活用手順は、図3に示すとおりである。
図3 ImprovAbilityモデルを活用した課題解決の手順 （DELTA社資料より）
CMMI等との関係
ImprovAbilityモデルは、CMMI等の他のモデルを否定するものではない。ImprovAbilityモデル単独で使ってもシステムの成功につなげられるが、逆に、CMMI等で確実にプロセスを実現（Implement）している場合に使われれば鬼に金棒である。要するに、他のモデルではカバーしきれない部分、つまりプロジェクトの組み立て方、ユーザとのインタフェースの取り方、方針の明確化、利用されるための方策などのシステム開発における人の意思決定に近い、より「アート」の部分を考えるためのフレームワークを提供する。
モデルの今後
CMMI等のプロセス成熟度モデルは、人のスキルや技術だけで解決できない課題をプロセスに着目にして解決を図っている。ImprovAbilityモデルはプロジェクトの成功のための視点とその使い方をモデル化したものである。
システム開発の歴史は、人の活動が中心でありなかなかエンジニアリングにならないと言われながらも、過去の経験に基づきスパイラルに、エンジニアリングとして確立を進めている。ImprovAbilityモデルに至り、より「アート」の部分を「エンジニアリング」として体系化するところまできた。
汎用性の高いモデルであり、プロジェクトの状況の診断だけでなく、プロジェクトマネージャの弱いところを指摘できるなど、様々な使い方がある。今システム開発で残り続ける課題への解決策の一つとして、大いに期待している。
本文中のリンク・関連リンク：
- 参考：ImprovAbilityモデルに関する書籍 “Improve IT”：（現在三菱総研で翻訳中）
注2）ISO/IEC DTR 33014
注3）ISOのワーキンググループメンバとの意見交換に基づく
注4）開発プロジェクト（Talent@ITプロジェクト）ホームページ
注5）CMMI Overview（米国カーネギーメロン大学ソフトウェア工学研究所）
注6）Company Profile – Historical Profiles（米国カーネギーメロン大学ソフトウェア工学研究所）