The Rational Edge

先駆者に学ぶ「開発プロセス改善の原則」

英Rational Services Organization
プロセス／プロジェクト管理チーム
技術主任
Ian Spence
2002/2/23

---

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

　ソフトウェアの開発プロセスを変えることは、規模の小さな試験的なプロジェクトに携わっているときでさえ難しいものです。ましてや、対象となるプロジェクトの規模や、部門、組織が大きくなると、これが飛躍的に難しくなります。

　本稿は、開発プロセスの変更をこれほどまでに難しくしているものが何であるか検証します。そして、組織改編の際に形式にかなった「プロセス改善計画」が果たす役割を検討して、計画を成功させる確率の向上を目指し、適用可能な経験則をいくつか紹介しましょう。

プロセスの変更は組織の変更である

　「プロセス改善計画」とその影響について検討する前に、まず、ソフトウェア開発を行う組織の行動を規定する基本概念を整理してみましょう。組織は図1に示される4つの基本概念によってその行動が決定されています。

図1　ソフトウェア開発組織の行動を決定する基本概念

　また、これらの4つの概念には、次のような基本的相互関係があります。

• 「プロジェクト」は「製品」の製造と変更を行う
  
• 「プロジェクト」は「組織単位」の資源を利用する
  
• 「組織単位」は資源を整然とまとめ、「カスタマー」「プロジェクト」および「製品」をサポートする
  
• 「カスタマー」は「製品」を発注して、それを使用する
  
• 「カスタマー」は製造される「製品」に対する要求事項と市場を提供する

　このモデルには、これらすべての概念を結び合わせるインフラが欠けています。それが「組織文化」（図2）です。

図2　「組織文化」こそがソフトウェア開発を行う組織のインフラである

　ソフトウェアエンジニアリング業務に携わる組織にとっての組織文化は、基盤となるビジネス文化とビジネス手順の組み合わせ、業務手順、そしてソフトウェア開発環境によって成り立っています。

　ソフトウェアの開発環境は、ソフトウェアエンジニアリング業務の効率に最も直接的に影響を与えます。そのため、大半の企業は、効率化を試みる際にソフトウェア開発環境の改善を考えるでしょう。

　実は、ソフトウェア開発環境（いわずもがな開発プロセスも含まれる）は、組織文化と切り離して変えることはできないというのが本稿の議論のポイントです。開発環境の大幅な変更は、組織文化に大きな影響を与えるのです。

　実際のところ、ソフトウェア開発の組織を永続的に改善するためには次のようなことが必要になります。

• 組織文化の中心に改善の必要性の認識を強く浸透させる
  
• 改善の取り組みを継続できるアプローチを取り入れる

　たいていの場合、ソフトウェア開発環境の中において根本的な変更を生み出すためには基盤のソフトウェア開発プロセスを変えるのが最も効果的な手法です。そして、これは組織改編計画への着手を意味します。

組織改編が困難である理由　*1

　残念ながら人は変化に抵抗するものです。実際に、惰性や未知のものに対する恐れによって、人は変化することを積極的に妨害するか、嫌でない程度に変化のスピードを落とそうとします。組織を変化させるには、これらの傾向を理解し、それに対抗するのではなく、対応しながら人々を導く必要があります。

　Roger Hebden氏は、1995年に書いた「Affecting Organizational Change」（組織改編に与える影響）*2という論文の中で、変化の力を次のような簡単な公式で表しています。

苦悩＋願望＝変化

　この公式は、変化は、最終的には感情によって起こることを示しています。苦悩と願望こそがわれわれに変化を起こさせ、それを受け入れさせる力となっているわけです。苦悩は変化を起こすきっかけとなり、願望はわれわれを目標へと進ませる力になります。移行を成功させるには、知覚される苦悩のレベルとソリューションに対する願望の理解や管理が必ず必要になります。これはD.Connor氏が「苦悩の管理と救済策の提供」と呼ぶものです*3。

　「苦悩の管理」とは、根本的な問題（経験上、根本的な問題は組織のプロセスもしくは、その不在にあることが多い）と変更が必要な理由を特定して伝達することを意味します。

　一方の「救済策の提供」は、ソリューションの提供と移行計画という2つの活動によって成り立っています。理想の目標を描写するだけでは十分ではなく、ソリューションを定義するには、主な中間地点を明確に定義してある、出発点からゴール地点までの経路も必要になります。

　変化は経営陣がそれを口にしただけで起こるものではありません。問題とソリューションの両方について一般論を述べるのはあまりにもたやすいことです。「どのプロジェクトもRational Unified Process（RUP：ラショナル統一プロセス）に従う必要がある」とは、プロジェクトにとって必要な進め方を大ざっぱに一般論化したものですが、これでは変化を起こすためにはほとんど役立ちません。

　組織改編をうまく実行するためには、組織に次のことが必要になります。

• 組織内のさまざまな地位にいる改編担当者を特定する。これらの個人が集まることで変化を起こすための作業を引き受ける
  
• 問題の本質を明確に定義する。改編担当者は苦悩の本質を理解し、意識を高めるべくそれを組織内のほかの人々に伝える必要がある
  
• 目標と、その目標に至るまでの経路の両方を示す、範囲を絞った妥当かつ適度なステップに改編作業を分割して計画を立てる。この計画は、組織の長期的な戦略目標の早急かつ賢明な改善達成に必要なもののバランスを取る必要がある
  
• 具体的で定量化できる実績と作業に置き換えて、組織のどのレベルでも理解できる方法を使って改編内容を伝える

　いかなる種類のものであっても、大規模な組織改編が失敗に終わるときは通常は次のいずれかの原因が考えられます。

• 段階的な改編実施の失敗
  
• 経営陣によるサポートの欠如
  
• 現場の人間によるサポートの欠如
  
• 利害関係者（すなわちカスタマー、ほかの部署、下請け業者、およびサプライヤー）によるサポートの欠如
  
• 組織改編に対処する意欲もしくは能力の欠如

　多くの組織が進める自社のソフトウェア開発環境を根本的に変えるための試みを狂わせてしまうのが、まさしくこれら技術以外の問題です。

プロセス改善プログラムの導入

　プロセスの変更は、人々の基本的な考え方や価値観の核心を突き、各自の仕事とその価値に対する見方を変えてしまうため、技術やツールの変化よりも個人や組織への影響の方が大きいのです。場合によっては、これが組織の報酬体系や物理的な作業環境、企業文化、そして経営まで変えてしまうこともあります。これはまた、プロジェクトレベル、部門レベル、そしてほかの組織との連携による組織の活動内容にも影響を与えます。Ivar Jacobson氏が『Software Reuse: Architecture, Process, and Organization for Business Success』*4の中で述べているように、このようなプロセスの変更は結局のところ「ソフトウェアエンジニアリング業務のエンジニアリング」だということになります。

　このような改編をサポートするために必要な管理、プランニング、コーディネーション、推進作業、インプリメンテーション、そして数値評価作業には形式にかなったプロセス改善プログラムが必要となります。

　そのプログラムでは次のような分野に取り組む必要があります。

人	これにはその適性、能力、意欲、そして姿勢が含まれる。全員が適切なトレーニングを受け、適切な意識を持つ必要がある
プロジェクト	プロセス改善プログラムと相互に影響する各プロジェクトは、関与することでメリットを直接享受しているのだということを感じる必要があるため、潜在的な効果と変更案に必要なコストの両方を理解すべきである
プロセスモデル	これはプロセス改善プログラムに左右される構造、活動、そして業務のほか、製造されるものを含めて定義すべきである
ディストリビューションメカニズム	これにはプロセスの記述、推進、および割り当ての方法が含まれる
サポートツール	新しいツールが古いものに取って代わることは避けられないが、それにはカスタマイズや統合が必要になる
出所が明確であること	参照される要求仕様すべてが一意的に確認できること
正確であること	記述された要求仕様すべてが、構築されるシステムに何らかの形で必要なものを示していること。これは当然のことのように思えるかもしれないが、関係のない要求仕様やまったく別のシステムに関する要求仕様が含まれてしまうことが驚くほど容易に発生する

　また、以下のものを含むさらに広範囲の利害関係者も考慮に入れる必要があります。

ソフトウェア開発組織の業績に対する責任を持つ 「経営陣」	どのプロセス改善プログラムにも経営陣のサポートが必要であるため、これらの人々はプロセスが変更される理由、潜在的な投資利益（ROI）、進展のある時期とその実現方法を理解する必要があり、予想されるこれらの事柄は慎重に管理する必要がある
社内外の「カスタマー」	各自の意見に対する対応の方法や時期、そして製品の出荷方法に影響が出るため、これらの人々に組織プロセスに変更があったことを伝える必要があるかもしれない

　組織の中には影響を受ける可能性のあるところがほかにもあります。場合によっては、ある業務部門に対する変更が、変更理由を理解できない別の部門からの抵抗や懐疑的な態度につながることもあります。たとえ計画の影響が直接はなくても、組織内のほかの部門を無視することは政治的な問題を引き起こす可能性があります。

　組織改編を主導するのがプロセス改善プログラムですが、これが変化を促進するために用いる主な手段が、基盤のソフトウェア開発プロセスと、これをサポートするツールセットの改善です。

1/3

INDEX
先駆者に学ぶ「開発プロセス改善の原則」
	プロセスの変更は組織の変更である 組織改変が困難である理由 プロセス改善のプログラムの導入
	プロセス改善に向けた経験に基づくアプローチ 組織ではなくプロジェクトと製品に焦点を合わせる 情報提供と参加への呼び掛けを継続する 変更を代行するプロセス改善プログラム
	プロセス改善のライフサイクル プロセス改善成功のためのキーポイント

（注釈）

*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刊