経験上、プロセス改善プログラムが成功する確率を高めるには多数の基本原則が適用できます。
次に、これらの原則を個々に詳細に見ていきましょう。
プロセス改善処置の管理と計画は、ほかのどの業務関連作業とも同じように進めたいものです。マイルストーンを設定し、資源を割り当てて、ほかのどの計画とも同じように管理とフォローアップを行うことが必要です。作業を物色するときは「投資収益(ROI)」を考慮し、投資額以上の金額を回収できるものにフォーカスします。
「プロセス改善計画」の中には、詳細なガイドライン、カスタマイズされたプロセス、そしてプロセス関連の余分な素材の用意にプロジェクトの開始前からあまりにも多くの時間と資源を投入するものもありますが、これには4つの大きな問題があります。
実際に改善や投資収益(ROI)を達成するに当たり、完璧なプロセスを完全に網羅したドキュメントが用意されるまで何年も待てる余裕のある組織はありません。最終的な目的が何であれ、プロセス改善プログラムには、それが影響を与えるプロジェクトからの大きな見返りがなくてはなりません。
大規模なプロセス改善プログラムに着手する前に、以下をはじめとする既存の開発環境を明確に理解する必要があります。
このように基準となる見解が用意されていないと、どのプロセス改善処置の優先度が最も高いとか、改善を数字によってどのように評価するのかといった判断が下せなくなります。
プロセス改善プログラムにはその土台となるべき堅固な基盤が必要となります。これを構築するために必要な情報源には次の3つがあります。
一挙に環境を変えてしまうのではなく、徐々に物事を改善していくことが目的であることを忘れてはいけません。この目的を達するために、プロセス改善プログラムは組織のコアビジネスにフォーカスし、実際のプロジェクトに関連してすべての提案を試し、これが業績を改悪ではなく改善しつつあることを確実にする必要があります。
環境、プロセス、そしてツールの変更を段階的に実施することで、新しい課題が生じるでしょう。しかし、あまりにも多くの新しい課題を一度に課すことによってプロジェクトチームを当惑させてしまうことを回避しましょう。新しい環境を1つ1つ小出しにしていくことで成功する確率が上がり、開発組織を慎重に評価すれば、どのプロセスから導入していくべきかが分かってきます。通常は最も問題の多い分野から取り組むのが最善です。
例えば、次のようなアプローチが適切だと考えられます。
最適なプロセスが検証もしくは確立される前から、組織構造にフォーカスするプロセス改善構想があまりにも多いようです。「すべてを適切に配置すれば、自然と正しく機能し、正しい成果を上げるだろう」とか「作れば何とかなる」といった考え方です。実際、このアプローチはどうひいき目に見ても無知であり、最悪の場合は破滅を招くでしょう。
組織構造がプロセスに依存すべきであって、その逆であってはなりません。自社の選ぶプロセスは、自社が着手するプロジェクトの種類と自社が作り出す製品の種類によって決まるべきです。最適な組織構造(プロセス改善プログラムの目標)は、プロセスが適切である場合に限り確立できるものです。必要とされる組織構造は、プロセス改善プログラム全体の成功から組織的に発展すべきです。実際、プロセス改善プログラムの成果物の開発、確立、および導入には、通常は多数の暫定的かつ過渡的な組織構造が必要とされます。
組織構造の効率化を図る判断基準はプロセス改善プログラム向けのそれと同じで、製造される製品の品質と、それを製造するプロジェクトの効率です。組織自体の劇的なリストラの実行を試みる前に組織内の製品とプロジェクトに焦点を当ててみましょう。
プロセス改善プログラムによって推奨されるプロセスは、組織の一連の製品が進化を続けるためのしっかりとした基盤を提供するものでなくてはなりません。プロセスはスケーラブルであるとともに、これをサポートする業務と並行して絶え間のない改善と進化が可能なものでなくてはなりません。プロセスはビジネスの成長と変化に伴い、基盤の組織構造を決定付け、形作っていくことになります。
成功する「プロセス改善計画」の大半は、規模が小さく焦点が絞られたプロジェクトとして既存の構造の範囲内でスタートします。コンサルタント、中核機関(COE)、査察チーム、特命チームなどは、進行中のプロセス改善プログラムの一部として導入できるツールにすぎないことを覚えておきたいものです。
助言指導者(メンター)は変化の推進役になります。経験上、新しいプロセスの遂行を成功させたい場合は助言指導者の活用が不可欠です。助言指導者がいない場合は、古い習慣へと逆戻りしてしまう危険があることは明白です。
助言指導活動は、十分な資源を割り当てて慎重に計画したいものです。導入するプロジェクトやプロセスの形成に関する助言指導を可能にするために、プロセス改善プログラムには資源と予算の両方が必要となります。新しいプロセスを導入するためのコストをプロジェクトの導入だけにかけてはなりません。プロジェクトの作業と相乗効果を発揮させながらプロセスの変更を進めるには、プロセスの助言指導者がプロジェクトの開発スタッフをサポートする以外に、プロジェクトマネージャと協力し、これをサポートすることも重要です。
助言指導者は、知識と責務の両方をプロジェクトメンバーへと伝えることに専念し、最終的には不要な過去のものになるべきです。助言指導者はまた、プロセス改善プログラムに対する自分たちの以下のような責任を忘れてはなりません。
中にはプロセス改善に対して無干渉主義で評価主導のアプローチを取る組織もあります。彼らは、新しいプロセスの導入を推奨および促進すべくプロジェクトに積極的には参加せず、威嚇や調査に頼って確実に準拠させようとします。この「強制」的なアプローチには根本的な欠陥があります。新しいプロセスの導入を進めるプロジェクトへの関与がほぼ例外なく遅れ、結果的には導入やプロジェクトの進行を推進するのではなく妨害することになってしまうのです。プロセスの原動力となる助言指導者がいないと、多くの場合はインプリメンテーション全体が失敗してしまいます。
プロセスの帰属をプロジェクトメンバー全体で分散することで各自の参加が進み、変化に対する抵抗が弱まって、各自の経験を組織全体に役立てられるようになります。「真の専門家」(実際にプロジェクトを進める人々)が自分たちで開発した方が結果として生まれるプロセスは優れたものになります。プロセスの帰属を分散することで、プロジェクトが社外コンサルタントに過度に依存する可能性を引き下げるとともに、プロジェクトメンバーが被害者ではなく計画への参加者だと感じられるようになります。
プロジェクトでは、プロセス改善の核心部分の範囲を担当する責任者を早急に任命するべきです。責任者はその分野を熟知し、ほかのプロジェクトメンバーを助言指導することができる人物であるべきであり、プロジェクトの中でプロセス改善プログラムのために“戦う”ことになります。
彼らは主に、プロセスの各部分の構成や発表を担当し、プロセスのさまざまな部分を管理する人々によるプロセスの定義、構成、およびドキュメント化も支援すべきです。
どの組織改編にとっても最大の脅威は、人々が変化に対して自然に抵抗することです。新しいプロセスやツールを導入することは、人々が自分たちの作業方法を修正しなくてはならないことを意味し、その多くは少なくとも不満を漏らすことになります。これは否定的な態度が悪い結果を生み出し、それがまた否定的な態度へとつながっていくという悪循環のリスクを生み出すことになります。
否定的な態度のまん延を防ぐには次のような行動を取ることができます。
ウオーターフォール型から反復型へと開発のアプローチを変更するような場合など、利害関係者は反復型開発プロジェクトの管理方法や進ちょく状況の把握の仕方について理解する必要がある。例えば、反復型開発プロジェクトでは初期のマイルストーンでデザインが完全に固まることは見込めないし、要求の取り込み方も異なることを知っておく必要がある。
プロセス改善プログラムは変更を進めるための手順であって担当部門ではありません。当初は作り出すソフトウェア開発環境のサポートと熟成を責任を持って進めることになりますが、「プログラム」は過度な集中を進めて一大勢力を築く衝動を抑える必要があります。
これまで見てきたように、組織改編をうまくやり遂げるに当たって大きな問題となるのは、手法、ツール、テクニックに関連した問題ではなく、政治的かつ個人的なものです。
計画の管理者は以下のことに留意するべきです。
一元化ソリューションはどれもフレームワークにすぎません。ソフトウェア開発環境が成熟すると、既存および将来のプロジェクトで要求される「1つのサイズですべてに対応する」ソリューションの存在をどうしても信じたくなってしまいます。プロセスのタイプはさまざまな力に応じて変化します。プロジェクト管理プロセスは、プロジェクトの規模と手続き、デザイン、そして選択された技術によるインプリメンテーションプロセスに応じて変わってくるのです。集中管理プロセスはどれも、プロジェクトは効果的に進行できなくてはならないとの自律性を維持しながら、プロジェクトをうまく実行するために共通の環境を提供する必要があります。
さらに、個々のプロジェクトは組織文化の制約の中でプロセスを調整しなくてはなりません。プロセスはこれを推進するとともに、個々のプロセス改善処置がプロセス改善プログラムにフィードバックされ、組織内の残りの人々にも役立つようなメカニズムを提供する必要があります。
ソフトウェア開発環境は自力で立ち上げるべきです(つまり自ら毒味をするということです)。提案されたソリューションの概念、手法、ツール、およびテクニックを使ってソリューション自体を構築します。例えば次のようなことが考えられるでしょう。
実際に、このアドバイスはプログラムの大半の分野に当てはまるので、組織に利用させたい新しいプロセスを使ってすべての作業を行ってみることが大切です。
Copyright © ITmedia, Inc. All Rights Reserved.