The Rational Edge
先駆者に学ぶ「開発プロセス改善の原則」
プロセス改善活動は、ある時点で終わることはありません。常に、取り組みが繰り返され、継続していくものです。
プロセス改善のライフサイクル |
プロセス改善プログラムで本当に成功していれば、プロセスを改善すること自体が組織文化の中において絶対不可欠な基本原則になるでしょう。プロセス改善プログラムが終わることはなく、図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つを提供します。
- プロセスを素早く例示するプロジェクトのフレームワーク
- すべてのプロジェクトに当てはまる共通基盤と最低承認基準
- プロジェクトが利用できるツールとテクニックのライブラリ
新しいプロセス、新しいツール、そして場合によっては新しい技術をインプリメントすると、ソフトウェアプロジェクトのスケジュールが変化しやすくなってしまいます。それが何回目であっても、プロセスのインプリメントや人材育成などには必ず十分な時間と資源を割り当てるべきです。また、プロセス改善プログラムを進めていく中では、利害関係者全員に十分な情報を提供し、参加を促すことを常に忘れないようにしたいものです。
Development Style 連載記事一覧 |
3/3 |
INDEX |
||
先駆者に学ぶ「開発プロセス改善の原則」 | ||
プロセスの変更は組織の変更である 組織改変が困難である理由 プロセス改善のプログラムの導入 |
||
プロセス改善に向けた経験に基づくアプローチ 組織ではなくプロジェクトと製品に焦点を合わせる 情報提供と参加への呼び掛けを継続する 変更を代行するプロセス改善プログラム |
||
プロセス改善のライフサイクル プロセス改善成功のためのキーポイント |
||
*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」に掲載された「Principle
of Process Improvement」をアットマーク・アイティが翻訳したものです。