先駆者に学ぶ「開発プロセス改善の原則」：The Rational Edge（3/3 ページ）

　「新しい秩序の確立は他の何にも増して困難である。なぜならば、改革者は旧秩序から利益を得ているすべての者を敵にまわし、新秩序から利益を受けるはずの者からは熱のこもらない支持しか期待できないからである」（1513年ニコロ・マキャヴェッリ）

[Ian Spence（英Rational Services Organization），＠IT] PC用表示関連情報

LINE

Hatena

　プロセス改善活動は、ある時点で終わることはありません。常に、取り組みが繰り返され、継続していくものです。

プロセス改善のライフサイクル

　プロセス改善プログラムで本当に成功していれば、プロセスを改善すること自体が組織文化の中において絶対不可欠な基本原則になるでしょう。プロセス改善プログラムが終わることはなく、図3のような流れで繰り返されていきます。

図3　プロセス改善プログラムのライフサイクル

　プロセス改善プログラム自体は多数のフェーズによって構成されていて、すべてが図3のような流れになっています。そして、それぞれのフェーズが基盤となるプロセスフレームワークの範囲内、もしくはその延長線上にある特定のプロセス改善処置の計画とインプリメンテーションを包含しています。プロセスが組織文化の基盤として定着すると、組織全体が継続的にプロセス改善を行う状態に移行していくようになります（図4）。

図4　プロセス改善処置の継続

　初期フェーズではソフトウェア開発環境の確立に焦点を当てることになります。これが完全にインプリメントされれば、計画のその後のフェーズはこれの微調整、保守、そしてサポートに関連するものとなっていきます。プロセス改善への探求は継続的なものであるべきで、常に自分たちの経験から学び、プロセスと組織文化の両方を進化および改善し続けることに努めるべきでしょう。

　計画の各フェーズの規模、数、スタイル、そして期間は、処理を進める組織に関する詳細な知識、その組織における既存プロセスの状況、プロセス改善プログラム自体の対象範囲などによって決まります。RUPには典型的なプロセスインプリメンテーションパターンとアプローチに関する詳細なガイドと説明が用意されています。

　もう1つ絶対不可欠な指標の情報源となるのがCarnegie Mellon Software Engineering Instituteです。同研究所は、それ自体がプロセス改善に着手するためのフレームワークの役割を担う『Capability Maturity Model for Software』の出版に加え、各組織に効果的なソフトウェアプロセス改善プログラム*5のプランニングとインプリメンテーションを指導すべくIDEALモデルも開発しています。このモデルは「Capability Maturity Model」を基盤とし、図3に示されるシンプルなモデルよりも一段と形式を整え、徹底的にドキュメント化された反復型のライフサイクルを示しています。

プロセス改善成功のためのキーポイント

　ソフトウェア開発組織の業務遂行能力を長期的に改善するためには、改善の必要性を組織文化の中心に植え込み、組織のあらゆる面に対するサポートを継続的に改善する総合的なアプローチを導入する必要があります。これは組織改編計画への着手を意味します。

　ソフトウェア開発環境の中に根本的な変化を生み出すための最も効果的な手法は、プロセス改善プログラムを通じて基盤となっている開発プロセスを変えることです。「プログラム」は、ほかのどの事業計画とも同じように準備および管理し、投資収益（ROI）とインプリメンテーションの複数のフェーズに徹底的に焦点を当てなくてはなりません。

　成功するためには次のような戦略があります。

簡単に好結果を出すことが可能で、早い時期にメリットを目にすることのできる問題分野に焦点を当てることにより、プロセス改善プログラムにはずみをつける
いまの組織に問題を伝える。その問題を理解してもらえれば、変更の必要性を受け入れてもらえる
何もかも一度にやろうとするのではなく、インプリメンテーションをいくつかのフェーズに分割し、サポート用のツールと一緒に各フェーズで新しいプロセスを部分的にインプリメントしていく。変更が最も大きな影響を与える分野に焦点を当てる
財産を基盤にする。組織が得意とするものを何もかも無駄にせず、選択した標準プロセスとこれらとを統合する
プロセスとツールを次々に進む実際のソフトウェア開発プロジェクトの中でインプリメントし、早い段階から実際の環境でプロセスとツールを検証する。プロセスは、これを利用するプロジェクトと連携して向上および進化する必要がある
プロセスの帰属をプロジェクトチームの中で分散する。これにより、一段と優れたプロセスが誕生し、より多くの人が参加し、プロジェクト内における変化に対する抵抗が弱まる

　プロセス改善プログラムを担当するプロジェクトチームメンバーには次のような作業が必要となります。

プロセスを導入するプロジェクトを指導および推進する
プロジェクトに密接に関与し、適切なプロセス改善処置を取り入れ、ドキュメント化する
組織内で新しいプロセスを推進する

　「1つのサイズですべてに対応する」完璧なプロセスを立案しようなどと思ってはいけません。プロセスは、常に特有のコンフィグレーションを必要とするようになりますが、次の3つを提供します。

プロセスを素早く例示するプロジェクトのフレームワーク
すべてのプロジェクトに当てはまる共通基盤と最低承認基準
プロジェクトが利用できるツールとテクニックのライブラリ

　新しいプロセス、新しいツール、そして場合によっては新しい技術をインプリメントすると、ソフトウェアプロジェクトのスケジュールが変化しやすくなってしまいます。それが何回目であっても、プロセスのインプリメントや人材育成などには必ず十分な時間と資源を割り当てるべきです。また、プロセス改善プログラムを進めていく中では、利害関係者全員に十分な情報を提供し、参加を促すことを常に忘れないようにしたいものです。

著者プロフィール

Ian Spence

英Rational Services Organization

プロセス／プロジェクト管理チーム

技術主任

（注釈）

*1　本節は「Rational Unified Process: Environment/Concepts/Managing Organizational Change」からの抜粋だが、同書もRoger Hebden氏の「Affecting Organizational Change」という論文を引用している（次の*2を参照）

*2　『Affecting Organizational Change』Roger Hebden氏著、1995年、米Rational Software刊

*3　『Managing at the Speed of Change』D. Conner著、1993年、米Random House刊

*4　『Software Reuse: Architecture, Process and Organization for Business Success』Ivar Jacobson、Martin Griss、Patrik Jonsson共著、1997年、米Addison-Wesley刊

*5　「Capability Maturity Model for Software, Version 1.1」（Mark C. Paulk，Bill Curtis，Mary Beth Chrissis、Charles V. Weber共著、1993年2月、米Software Engineering Institute刊、CMU/SEI-93-TR-24、DTIC Number ADA263403）および「Key Practices of the Capability Maturity Model, Version 1.1」（Mark C. Paulk、Charles V. Weber、Suzanne M Garcia、Mary Beth Chrissis、Marilyn W. Bush共著、1993年2月、米Software Engineering Institute刊、CMU/SEI-93-TR-25、DTIC Number ADA263432）を参照

「The Rational Edge」バックナンバー