The Rational Edge

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

---

　ではいよいよ、筆者の経験に基づくプロセス改善の具体策に触れていこう。

プロセス改善に向けた、経験に基づくアプローチ

　経験上、プロセス改善プログラムが成功する確率を高めるには多数の基本原則が適用できます。

• 事業計画として実行する。「投資収益」を考慮する
  
• 既存の環境を理解する
  
• 財産を土台にしてその上に積み重ねていく。1からやり直すことはない
  
• 数字で評価しながら段階的に改善していく
  
• 組織ではなくプロジェクトと製品に焦点を合わせる
  
• プログラムは強制ではなく助言指導（メンタリング）によって妨害ではなく促進する
  
• プロセスの帰属を分散する
  
• 情報提供と参加への呼び掛けを継続する

　次に、これらの原則を個々に詳細に見ていきましょう。

●事業計画として実行する。「投資収益」を考慮する

　プロセス改善処置の管理と計画は、ほかのどの業務関連作業とも同じように進めたいものです。マイルストーンを設定し、資源を割り当てて、ほかのどの計画とも同じように管理とフォローアップを行うことが必要です。作業を物色するときは「投資収益（ROI）」を考慮し、投資額以上の金額を回収できるものにフォーカスします。

　「プロセス改善計画」の中には、詳細なガイドライン、カスタマイズされたプロセス、そしてプロセス関連の余分な素材の用意にプロジェクトの開始前からあまりにも多くの時間と資源を投入するものもありますが、これには4つの大きな問題があります。

• 人は詳細な説明など読まない
  
• 当初からすべてを実行するのは非常に困難だ。何か小さいことを試してそれに慣れ、それから範囲を広げたい
  
• プロセスに関する知識のある人は、その時間の大半を詳細な説明の執筆にではなく助言を提供することに充てるべきだ
  
• これらの作業は数字による評価の可能な投資収益（ROI）を生み出すものではない。プロセスの定義を作成しても、そのプロセスを適用しなければ何も改善されない

　実際に改善や投資収益（ROI）を達成するに当たり、完璧なプロセスを完全に網羅したドキュメントが用意されるまで何年も待てる余裕のある組織はありません。最終的な目的が何であれ、プロセス改善プログラムには、それが影響を与えるプロジェクトからの大きな見返りがなくてはなりません。

●既存の環境を理解する

　大規模なプロセス改善プログラムに着手する前に、以下をはじめとする既存の開発環境を明確に理解する必要があります。

• 既存のプロセスと慣習
  
• 既存のツールセット
  
• 既存の役割とチーム構造
  
• サポートおよび製造される製品
  
• 組織プロセスの成熟度
  
• 既存の組織構造の力関係と利害関係

　このように基準となる見解が用意されていないと、どのプロセス改善処置の優先度が最も高いとか、改善を数字によってどのように評価するのかといった判断が下せなくなります。

●財産を土台にしてその上に積み重ねていく。1からやり直すことはない

　プロセス改善プログラムにはその土台となるべき堅固な基盤が必要となります。これを構築するために必要な情報源には次の3つがあります。

• 組織が得意なもの。最も成功したプロセスから最優良事例を取り入れる
  
• 業界のトップの業務と製品
  
• 計画に参加する人々の経験

　一挙に環境を変えてしまうのではなく、徐々に物事を改善していくことが目的であることを忘れてはいけません。この目的を達するために、プロセス改善プログラムは組織のコアビジネスにフォーカスし、実際のプロジェクトに関連してすべての提案を試し、これが業績を改悪ではなく改善しつつあることを確実にする必要があります。

●数字で評価しながら段階的に改善していく

　環境、プロセス、そしてツールの変更を段階的に実施することで、新しい課題が生じるでしょう。しかし、あまりにも多くの新しい課題を一度に課すことによってプロジェクトチームを当惑させてしまうことを回避しましょう。新しい環境を1つ1つ小出しにしていくことで成功する確率が上がり、開発組織を慎重に評価すれば、どのプロセスから導入していくべきかが分かってきます。通常は最も問題の多い分野から取り組むのが最善です。

　例えば、次のようなアプローチが適切だと考えられます。

• 最初に、要求を取り込んで処理する手法を改善することに焦点を合わせる
  
• 次にアプリケーションとそのコンポーネントの分析およびデザインに焦点を合わせる
  
• その後、その環境のほかの部分を開発および導入していく

組織ではなくプロジェクトと製品に焦点を合わせる

　最適なプロセスが検証もしくは確立される前から、組織構造にフォーカスするプロセス改善構想があまりにも多いようです。「すべてを適切に配置すれば、自然と正しく機能し、正しい成果を上げるだろう」とか「作れば何とかなる」といった考え方です。実際、このアプローチはどうひいき目に見ても無知であり、最悪の場合は破滅を招くでしょう。

　組織構造がプロセスに依存すべきであって、その逆であってはなりません。自社の選ぶプロセスは、自社が着手するプロジェクトの種類と自社が作り出す製品の種類によって決まるべきです。最適な組織構造（プロセス改善プログラムの目標）は、プロセスが適切である場合に限り確立できるものです。必要とされる組織構造は、プロセス改善プログラム全体の成功から組織的に発展すべきです。実際、プロセス改善プログラムの成果物の開発、確立、および導入には、通常は多数の暫定的かつ過渡的な組織構造が必要とされます。

　組織構造の効率化を図る判断基準はプロセス改善プログラム向けのそれと同じで、製造される製品の品質と、それを製造するプロジェクトの効率です。組織自体の劇的なリストラの実行を試みる前に組織内の製品とプロジェクトに焦点を当ててみましょう。

　プロセス改善プログラムによって推奨されるプロセスは、組織の一連の製品が進化を続けるためのしっかりとした基盤を提供するものでなくてはなりません。プロセスはスケーラブルであるとともに、これをサポートする業務と並行して絶え間のない改善と進化が可能なものでなくてはなりません。プロセスはビジネスの成長と変化に伴い、基盤の組織構造を決定付け、形作っていくことになります。

　成功する「プロセス改善計画」の大半は、規模が小さく焦点が絞られたプロジェクトとして既存の構造の範囲内でスタートします。コンサルタント、中核機関（COE）、査察チーム、特命チームなどは、進行中のプロセス改善プログラムの一部として導入できるツールにすぎないことを覚えておきたいものです。

●改善促進のためには、妨害よりむしろ助言指導（メンタリング）すべき。強制してはならない

　助言指導者（メンター）は変化の推進役になります。経験上、新しいプロセスの遂行を成功させたい場合は助言指導者の活用が不可欠です。助言指導者がいない場合は、古い習慣へと逆戻りしてしまう危険があることは明白です。

　助言指導活動は、十分な資源を割り当てて慎重に計画したいものです。導入するプロジェクトやプロセスの形成に関する助言指導を可能にするために、プロセス改善プログラムには資源と予算の両方が必要となります。新しいプロセスを導入するためのコストをプロジェクトの導入だけにかけてはなりません。プロジェクトの作業と相乗効果を発揮させながらプロセスの変更を進めるには、プロセスの助言指導者がプロジェクトの開発スタッフをサポートする以外に、プロジェクトマネージャと協力し、これをサポートすることも重要です。

　助言指導者は、知識と責務の両方をプロジェクトメンバーへと伝えることに専念し、最終的には不要な過去のものになるべきです。助言指導者はまた、プロセス改善プログラムに対する自分たちの以下のような責任を忘れてはなりません。

• サポートするプロジェクトから最優良事例を収穫すること
  
• 「ジャスト・イン・タイム方式」によるプロセス改善と構成を行うこと
  
• プロジェクトの範囲内でプロセス改善プログラムを推進すること

　中にはプロセス改善に対して無干渉主義で評価主導のアプローチを取る組織もあります。彼らは、新しいプロセスの導入を推奨および促進すべくプロジェクトに積極的には参加せず、威嚇や調査に頼って確実に準拠させようとします。この「強制」的なアプローチには根本的な欠陥があります。新しいプロセスの導入を進めるプロジェクトへの関与がほぼ例外なく遅れ、結果的には導入やプロジェクトの進行を推進するのではなく妨害することになってしまうのです。プロセスの原動力となる助言指導者がいないと、多くの場合はインプリメンテーション全体が失敗してしまいます。

●プロセスの帰属を分散する

　プロセスの帰属をプロジェクトメンバー全体で分散することで各自の参加が進み、変化に対する抵抗が弱まって、各自の経験を組織全体に役立てられるようになります。「真の専門家」（実際にプロジェクトを進める人々）が自分たちで開発した方が結果として生まれるプロセスは優れたものになります。プロセスの帰属を分散することで、プロジェクトが社外コンサルタントに過度に依存する可能性を引き下げるとともに、プロジェクトメンバーが被害者ではなく計画への参加者だと感じられるようになります。

　プロジェクトでは、プロセス改善の核心部分の範囲を担当する責任者を早急に任命するべきです。責任者はその分野を熟知し、ほかのプロジェクトメンバーを助言指導することができる人物であるべきであり、プロジェクトの中でプロセス改善プログラムのために“戦う”ことになります。

　彼らは主に、プロセスの各部分の構成や発表を担当し、プロセスのさまざまな部分を管理する人々によるプロセスの定義、構成、およびドキュメント化も支援すべきです。

情報提供と参加への呼び掛けを継続する

　どの組織改編にとっても最大の脅威は、人々が変化に対して自然に抵抗することです。新しいプロセスやツールを導入することは、人々が自分たちの作業方法を修正しなくてはならないことを意味し、その多くは少なくとも不満を漏らすことになります。これは否定的な態度が悪い結果を生み出し、それがまた否定的な態度へとつながっていくという悪循環のリスクを生み出すことになります。

　否定的な態度のまん延を防ぐには次のような行動を取ることができます。

• 現実的な予想を立てる。新しいプロセスや新しいツールを過大評価しない
  
• 改編が必要な理由を説明する。解決を必要とする組織の問題、新しいプロセスや新しいツールで技術的に必要な変更、これらの新しいツールやプロセスを使うことで得られるメリットを確実に伝える
  
• 組織内の全員に現状を伝える。この情報はさほど詳細である必要はない。重要なのは人々に変更について確実に知らせること
  
• カスタマーやスポンサーなどの利害関係者を忘れないこと

　ウオーターフォール型から反復型へと開発のアプローチを変更するような場合など、利害関係者は反復型開発プロジェクトの管理方法や進ちょく状況の把握の仕方について理解する必要がある。例えば、反復型開発プロジェクトでは初期のマイルストーンでデザインが完全に固まることは見込めないし、要求の取り込み方も異なることを知っておく必要がある。

• カギを握る人々を改編作業に巻き込み、プロセスの各部分を担当してもらう
  
• 結局は新しいプロセスの仕組みと新しいツールの使い方の両方を理解しなくてはならなくなるので、プロジェクトメンバーに新しいプロセスやツールに関する知識を与える

変更を代行するプロセス改善プログラム

　プロセス改善プログラムは変更を進めるための手順であって担当部門ではありません。当初は作り出すソフトウェア開発環境のサポートと熟成を責任を持って進めることになりますが、「プログラム」は過度な集中を進めて一大勢力を築く衝動を抑える必要があります。

　これまで見てきたように、組織改編をうまくやり遂げるに当たって大きな問題となるのは、手法、ツール、テクニックに関連した問題ではなく、政治的かつ個人的なものです。

　計画の管理者は以下のことに留意するべきです。

• サポート組織の準備はすでに整っている可能性がある。多くの組織にはソフトウェア開発環境のコンポーネントをサポートするチームがすでに配備されている。彼らはプロセス改善プログラムを効果的に実施するために絶対不可欠な知識と経験を持っており、早急に参加させるべきである
  
• 確定し、実証されるまでは改編を発表しようなどとは考えないこと。中心的なチームを大量に結成し、プロセス自体が確定もしくは実証される前に作業方法を規定しようとする計画が多い。例えば、形式にかなった再利用可能資産の生産／保守能力を実証もしないで再利用可能レポジトリのセットアップや構築に大金を投じる組織が多い
  
• 自分が有名になろうとして調子に乗り過ぎない。組織改革には時間がかかる。プロセス改善プログラムの最終的な成果は、すべてのチームをコンポーネントベースの開発へと変えるか、再利用可能なビジネス構造を作り出すことだ。だが、これはプロセス全体が改善されることのみによって成し得ることであり、一歩一歩着実なアプローチを取る必要がある。

　一元化ソリューションはどれもフレームワークにすぎません。ソフトウェア開発環境が成熟すると、既存および将来のプロジェクトで要求される「1つのサイズですべてに対応する」ソリューションの存在をどうしても信じたくなってしまいます。プロセスのタイプはさまざまな力に応じて変化します。プロジェクト管理プロセスは、プロジェクトの規模と手続き、デザイン、そして選択された技術によるインプリメンテーションプロセスに応じて変わってくるのです。集中管理プロセスはどれも、プロジェクトは効果的に進行できなくてはならないとの自律性を維持しながら、プロジェクトをうまく実行するために共通の環境を提供する必要があります。

　さらに、個々のプロジェクトは組織文化の制約の中でプロセスを調整しなくてはなりません。プロセスはこれを推進するとともに、個々のプロセス改善処置がプロセス改善プログラムにフィードバックされ、組織内の残りの人々にも役立つようなメカニズムを提供する必要があります。

　ソフトウェア開発環境は自力で立ち上げるべきです（つまり自ら毒味をするということです）。提案されたソリューションの概念、手法、ツール、およびテクニックを使ってソリューション自体を構築します。例えば次のようなことが考えられるでしょう。

• ビジネスモデリングテクニックの導入を提案する場合は、ソフトウェアエンジニアリング組織をモデリングしてこれらのテクニックを実証してみる
  
• プロジェクトが特定のプロセスやツールを使って自身の要求事項を管理する提案を行っている場合は、これらを使ってソフトウェア開発環境の要求事項を管理してみる
  
• 特定のプロジェクト管理アプローチを提案している場合は、そのアプローチを使ってプロセス改善プログラムを管理してみる

　実際に、このアドバイスはプログラムの大半の分野に当てはまるので、組織に利用させたい新しいプロセスを使ってすべての作業を行ってみることが大切です。

2/3

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