プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）：The Rational Edge（1/3 ページ）

前編「反復開発の『ここはぜひカバーしたいポイント』」、中編「開発プロセス導入のアンチパターン」を通じて、反復開発への移行時に生じるであろう要検討のトレードオフと、開発プロセス-プロジェクトの性質について解説した。後編では、導入したプロセスの継続的なサポートと、コンプライアンスについて解説する。

継続的改良

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　ソフトウェア開発は、優先事項、要件、そして場合によってはチームメンバーも頻繁に変わるダイナミックな活動だ。さらに、場合によっては相反するさまざまな問題に取り組むことになるため、ソフトウェア開発は非常に複雑だ。固有の動きや複雑性があるため、プロジェクト当初に合理的かつ詳細に今後の流れを予測することはできない。挑戦はしてみるべきだが、ソフトウェア開発を本当に効率的に進めたいのなら、進行に合わせて積極的に学習し、必要に応じて戦術を変更する必要がある。

　この手法の背景にある重要なコンセプトはシンプルだ。チャンスが訪れるたびに作業方法を改善する。「毎日何か新しいことを学ぶはずだ」というのは優れた格言だ。だがこの手法では、一歩先へ進み、学んだことに対して何らかの行動を取り、全体の効率を引き上げることを推奨している。

　ソフトウェアプロジェクトの進行中に、その中で潜在的に改善可能な点を特定する方法は次のようにいくつもある。

1　非公式改善セッション。チームや、プロジェクトにとって重要な潜在的利害関係者を定期的に招集して、適切に進んでいるものとそうでないもの、そしてそれを協力して改善する方法についての議論を求める。

2　遡及（そきゅう）。遡及［注4］は、次の4つの質問について考える促進会議だ。論議抜きでは忘れ去られてしまうもので何がうまくいっただろうか？ 何を学んだだろうか？ 次回のやり方を変えるべきなのはどれか？ 依然として問題になっているのは何か？ ライフサイクルのどの段階でも実行可能な遡及の目標は改善分野を特定することだ。

3　スタッフ用目安箱。これが、潜在的な改善方法をいつでも匿名で提案するための最も簡単な方法になるときもある。「スタッフ用目安箱」は物理的な箱でも良いが、たいていは電子的にインプリメントされている。

4　個人の反省。スタッフに推奨したい優れた習慣の1つが、進ちょく状況、連携状況、そして目標達成状況について反省するための時間を時々設けることだ。この反省は個人的な戦略改善につながることが多いが、全体のプロセス改善提案にもつながる。

5　修正可能プロセス。チームに基本的なプロセスを提供しながら、プロセスを適宜修正するための権限とツール（Wikiなど）も提供する

・メリット

　この手法には以下のような複数のメリットがある。

　進めながら学習する。チームは次のプロジェクトで改善を試みるのではなく、新しい見識をすぐに活用することができる。これにより生産性が一段と早急に向上する。これは、1つの反復の中で得られた教訓を次の反復ですぐに活用できるため、前述の「反復開発」手法と組み合わせたときに特に効率的となる。

　チームは自身の運命を掌握している。この手法は、チームが効果的に自分たちでプロセスを改善し、容易に自己最適化できる力を与える（次回のパート3では、「自己最適化チーム」の手法でこのコンセプトの新たな詳細を説明する）。

・トレードオフ

　この手法には以下のような複数のトレードオフがある。

　投資の必要性。プロセス改善作業のためにプロジェクトスケジュールから時間を割く必要がある。

　行動の必要性。実際に行動に出なければ改善のチャンスを特定しても意味はない。

　自分に正直であれ。チームが直面する問題の多くは、個人を中心とするもので、それぞれのやりとりに起因する。プロジェクト関係者には、他者の意向に反するものであっても問題や潜在的ソリューションを指摘できる良好な雰囲気が必要だ。

　プロセス変更／コンフィギュレーション管理の必要性。一部のプロジェクトチームでは、プロセスを定義し、そのプロセスへの準拠の証明をチームに義務付けるISO 900XやFDAの21 CFR Part 11といった規制へのコンプライアンスが必要になってくる。その影響から、これらの規制へのコンプライアンスを目指したプロセスに対する変更、変更理由、変更時期をすべて追跡する必要が生じる場合がある。

・アンチパターン

　ソフトウェアプロセスの改善には以下のようなアンチパターンがある。

　指摘された教訓。多くのプロジェクトチームが一連の「教訓」を特定するものの、それに対して誰も行動を取らない。「学んだこと」から実際にソフトウェアプロセスを改善するまでは、一連の「指摘された問題」があるにすぎない。

　改善の遅れ。潜在的なプロセス改善点がプロジェクト終了時もしくは終了間際の「プロジェクト後」に特定される。そのときではプロジェクトチームが指摘された問題に対応するには遅過ぎ、もしチームメンバーがほかのプロジェクトに向けてほかのチームに別れようとしている場合は、本格的な対応策が講じられる可能性は非常に低い。

・推奨デフォルト

　各反復の最後に2時間を使って非公式プロセス改善もしくは遡及会議を開くよう推奨する。