イノベーションと計画策定の反復

惰性は過去の革新への取り組みの名残である。放置すると、次世代の革新のために必要なリソースを消費する。

─Geoffrey Moore

稼働率を100%にすると予測が困難になる。

─Don Reinertsen

イノベーションと計画策定の反復の概要

リーンでもアジャイルでもSAFeでも、顧客の価値を継続的に納品することに集中する。各プログラムインクリメント(PI)の終わりにシステムデモを行い、検査と適応のワークショップを実施することで、アジャイルリリース列車(ART)や価値のストリーム全体にとっての焦点と統合ポイントを作成する。これは、開発における重要な点であり、ここでソリューションの進捗が利害関係者全員に示される。また、これは、継続的な価値の納品というニーズを満たすためにも役立つ。それを実現するため、チームは、PIのあいだ、PI計画で引き受けたフィーチャーにせっせと取り組む。どの反復も重要であり、チームは目先の納品に集中して、たいていは「うつむいて」いる。次から次へとPIが続き、ソリューションは市場へ向かって進む。納品への集中は弱まることがない。

もちろん、納品という1つのことに集中すると、別のこと、この場合はイノベーションへの注意は失われがちになる。このように常に切迫した状態にいると、イノベーションのための時間を別に確保しておかないと、「緊急の反復という名の専制」によって、常に革新的でいなければならないというニーズが打ち負かされてしまう。これに対処できるよう、SAFeではイノベーションと計画策定の反復を用意している。この反復は、計画や振り返りのために確保された時間、または調査やイノベーションの機会など、さまざまな目的で使用することができる。それらについて、この後で詳しく説明する。

詳細

IP反復の活動を理解する

イノベーションと計画策定の反復は、PIごとにリズムベースで定期的に設けられ、継続的でインクリメンタルな価値納品のパラダイムには納まりにくい作業にチームが取り組むための機会となる。たとえば次のような目的に用いることができる。

  • イノベーションや調査のための時間
  • PIのシステムデモ検査と適応ワークショップ、PI計画イベント、バックログの手入れに使うための専用の時間
  • ソリューションの最終統合
  • 技術インフラ、ツール、システム障害のための作業
  • 継続的な教育のための作業
  • さらに、IP反復は、PI目標を達成するための見積もりのバッファとなる、リリースの予測性を向上するなどの、重要な役割も果たす。

「バッテリーを充電してツールの手入れをする」機会を定期的に設けることで、全体的な効率や、ベロシティー、ペースの持続性、仕事の満足度がすべて向上するという報告が、多くのアジャイルリリース列車から寄せられている。

イノベーションのための時間を設ける

イノベーションはSAFeのリーン-アジャイルの考え方の柱の1つに挙げられているが、納品の締め切りに追われる中で自由連想やイノベーションのための時間を見つけるのは困難である。そのため、多くの企業では、調査および設計の活動や「ハッカソン」のためにIP反復を設ける。ハッカソンのルールは以下のような簡単なものである。1. チームメンバーは、好きな人と好きな仕事を行う。会社の使命が反映されていれば何でもよい。
2. ハッカソンの終わりに、結果を他の人にデモする。

ハッカソンで学んだことは、当たり前のようにプログラムバックログに入り込んできて、イノベーションが促進される。それに、これは面白い作業でもある。

PIイベント用の時間を設ける

PIのシステムデモや、検査と適応のワークショップ、PI計画策定は、時間を取って実施する重要なイベントである。これを専用のIP反復に含めると、他のすべての反復が標準の長さとベロシティーになり、これらの重要な作業の時間を取るために短縮されずにすむ。さらに重要なのは、イベントが制度的にプログラムのスケジュールに組み込まれ、実施が保証されることである。

また、対応できる最後の瞬間におけるジャストインタイムのプログラムおよび価値のストリームのバックログの手入れやフィーチャーおよびシステム能力の推敲をこの期間に行うことで、今後の計画セッションの生産性を大幅に向上できる。

すべてが揃ったソリューションを統合する

IP反復には、システムデモが含まれる。また、この反復は、最終的なソリューションテストを行うための時間にもなる。具体的には、パフォーマンスやその他の非機能要求(NFR)の最終テストや、標準やセキュリティの検証、ユーザー受け入れテスト、最終ドキュメント、その他の準備作業のうち個々の反復で実施するのは不可能であったり経済的でないものである。

複雑なソリューションに、ハードウェアなどエンドツーエンドの継続的な統合が困難な有形のコンポーネントが含まれる場合、プログラムレベル価値のストリームレベルでの完全な統合は、IP反復でしか実施できないかもしれない。そのような場合は、それに合わせた計画を立てるのが当然である。

それでも、資産をシステムに統合する試みはこれ以外にも必要である。SAFeを導入した組織は頻繁な統合を行うことを前提としていて、この統合によって、完全にすべてを網羅してはいなくても、ソリューションの具体的な側面に目を向け、重大な問題やリスクが発生したとしてもPI内で対応可能な早い段階で想定が正しいことを検証する。統合されたものは、各反復の終わりのシステムデモでデモされる。IP反復は、少なくともPIごとに一度行わなければならない最終的な全体のソリューション統合のプレースホルダーとなる。通常、この統合作業は、システムチームアジャイルチームを手伝って行う。

開発インフラを進歩させる

リーンな納品を行うと開発インフラの負担が増える。継続的インテグレーションを行うための環境を新しく立ち上げなければならないし、新しいテスト自動化フレームワークのインストールと保守もしなければならない。プロジェクト管理ツールを導入したり、チーム内およびチーム間のコミュニケーションシステムをアップグレードあるいは機能強化しなければならない。作業リストはまだまだ続く。このリストの項目の多くは各反復内で対処できるし対処しなければならない(チームの反復の振り返りで見つかった改善ストーリーやイネイブラーであることも多い)が、更新や移行は数日後に重要なデモが控えていない時に行ったほうが効率がよい場合もある。ときどきはツールの手入れをしなければならないことを我々はみんな理解している。アジャイルチームも例外ではない。実際に、アジャイルチームは通常のチームと比べて、作業環境への依存度が高い。そのため、環境の構築に時間を割く必要がある。

継続的な学習を可能にする

リーンなエンジニアやリーダーは生涯にわたって学習を続ける。技術の変化はもちろん、手法やプラクティスの変化も日常茶飯事である。一方、継続的な教育の機会ははるかに少ない。さらに、リーン-アジャイルへ移行する初期段階では、フィーチャーやストーリーの記述、品質の作り込み、自動テスト、共同所有、リーン-アジャイルなアーキテクチャー、継続的インテグレーション、ペア作業、プロダクトオーナーおよびスクラムマスターのスキル、チーム作りなど、多くの新しい手法が必要である。継続的な教育のために時間を設けることで、チームやリーダーは、これらの新しい手法を学習し使いこなすために必要な時間を得ることができる。また、この時間は、そのようなテーマごとの専門技能コミュニティーを育て、支援するのにも利用できる。最終的な結果として、個人と企業の両方が恩恵を受けられる。従業員のスキルと仕事の満足度が向上し、ベロシティーが高くなり、市場投入までの時間が短縮するからである。

組み込まれた見積もりバッファを利用する

100%で稼働すると結果が予測できなくなることを、リーンフローは教えてくれる。簡単に言うと、全員が処理能力いっぱいまで計画に入れられた場合、必然的に発生する問題に柔軟に対処できる人がいなくなる。その結果、予測性が低下し、価値納品が遅延する。これに対処するために、「保護帯」つまり見積もりのバッファとしてIP反復を使用する。PI計画策定時に、IP反復の計画にはフィーチャーやストーリーの開発は含められない。このバッファは、予測できなかった出来事や依存関係にかかわる遅延などの要因にチームが対応するのに必要な余裕時間となり、結果として、チームとプログラムのPI目標を達成できる可能性が高まる。そして、ビジネス担当者にとって非常に重要な指標であるプログラムの成果の予測性が大幅に向上する。ただし、常にこの時間を作業を完成するために使用するのは、失敗のパターンである。それではIP反復の第一の目的が満たされず、イノベーションに悪影響が出る。チームは、見積もりの保護帯がただの杖にならないよう気を配る必要がある。

IP反復カレンダーの例

上記すべてを考慮すると、多くのチームのIP反復はある程度同じようなスケジュールと形式になる。その例を図1に挙げる。

図1.  IP反復のカレンダーの例

 


さらに知りたい場合

[1] Reinertsen, Donald G. The Principles of Product Development Flow:Second Generation Lean Product Development.Celeritas Publishing, 2009.

[2] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011, 第17章 (邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

 

Last update:18 August 2015