2015 年、Agilent のソフトウェアおよび情報科学部門は問題を抱えていました。主要な新製品リリースの最中に、チームがリリース日に間に合いそうにありませんでした。これは初めてのことではなく、部門は予定どおりのリリースの約 20 パーセントしか達成していませんでした。
リリース日に間に合わなかったことで、ソフトウェア チームには極めて大きなプレッシャーがかかりました。「プレッシャーがかかると、チームは誤った決断を下してしまいます」と Agilent の副社長およびソフトウェアおよび情報科学部門の GM である John Sadler 氏は話しました。「チームは品質を犠牲にすると、最終段階でひどい目にあうことになります。概して、チームの士気は相対的に低下し、予定どおりに何かを提供することに苦労していました」
課題の一部は、Agilent のソフトウェアおよび情報科学部門には 150 人の従業員が 2 つの大陸にいて、3 つ目の大陸の請負業者と連携していたことでした。エンジニアリング、マーケティング、品質保証、技術サポート、セールスの専門職が無秩序に広がっている部門でした。会社はチームの新しい実践方法を確立し、より優れた品質と予測可能性を伴う価値をより迅速に提供できるようにし、より適切に変更に対応する必要がありました。要するに、チームにはアジャイル変革が必要でした。
アジャイル変革に乗り出す
2015 年に、Agilent は次の目標を掲げてアジャイル変革を計画しました。
- 予測可能性を重視する
- 確実なリリース間隔を展開する
- 再現可能なデリバリー サイクルを構築する
- 継続的な改善を推進する
アジャイル アプローチでは、第一に品質、第二に再現可能な間隔、第三にスコープに重点を置きます。「チームがこれらの優先順位に従わなければ、多くの場合、第一にスコープを重視し、締め切りという形でタイムラインが強要され、品質は低下します」と Sadler 氏は述べました。
Agilent は、優先順位をソフトウェア開発に組み込んだアジャイル プロセスを確立することを希望していました。継続的な改善を第一の価値として確立することは、変革のための状況を作り出す文化的な変化を伴います。品質を第一に考えることとは、社内外の顧客両方の満足度を向上させることでした。Agilent は、現場の顧客の期待を満たすためには、スコープを犠牲にしても構わないと考えていました。
2 つ目の優先事項は、部門が、時間をかけて微調整できる予測可能なリリース サイクルを作成することでした。より短い、確実な開発サイクルがあれば、チームは問題を回避して早期にリスクを軽減し、適切な対応時間を得ることができます。
段階的なアジャイル変革
2015 年 8 月から、Agilent はアジャイル変革によって組織を支援した実績を持つコンサルティング企業である cPrime と提携し、その後に主要な製品開発コンサルタント会社である TCGen と提携しました。
最初のステップは、アジャイル製品管理ツールである Jira を実装することでした。現在、Jira は分散するグローバルなチームにわたる Agilent の開発業務のすべてを記録する 1 つのシステムを備えています。データの一元性・一貫性によって透明性を生み出し、アジェンダの特徴、それが発揮されるタイミング、および複数のチーム全体で達成した内容を明らかにします。
cPrime, Inc. の許可を得て適応
次の優先事項はアジャイル トレーニングであり、アジャイルの原理とコンセプトを教えて、共通の用語を確立することを目標としました。cPrime は、同社の Recipes for Agile Governance in the Enterprise (RAGE) (企業でのアジャイル ガバナンスの秘訣) モデルで、リリース計画ミーティング、チームの Scrum of Scrums ミーティング、プロダクト所有者の Scrum of Scrums ミーティング、リリース バックログ グルーミング ミーティング、リリース レビュー、リリースの振り返りミーティングなど、主要な方法を概説しています。
また、Agilent はエリア プロダクト所有者の役割とプログラム マネージャーの役割も確立し、バーンアップ チャートによって進捗を測定しました。さらに、Agilent は軽量の意思決定手法を採用して、セレモニーを実施し、アジャイルのスクラム アーティファクトを使用して他のアジャイル プラクティスも採用しました。
アジャイルの実践
2015 年 11 月に、Agilent のソフトウェアおよび情報科学部門は、トレーニングを受けた 14 チームと共に 2 週間のアジャイル計画セッション「スプリント ゼロ」を実施しました。OpenLAB クロマトグラフィー データ システムの製品リリース計画は 8 か月にわたって開発されました。
スプリント ゼロのアクティビティには次の 3 つのカテゴリーが含まれていました。
- ビジネスおよび技術的な目標、推進要素、OpenLAB の大まかな要件に関して、プレゼンテーションやポスターによってチームを教育する。
- 新たに学んだ手法を利用して、要件を作成し、ストーリー、エピック、欠陥を推定する。
- リリース計画ボードにストーリー、エピック、欠陥を提示し、チーム間の依存関係をすべてマークする。
Agilent は、アジャイル改善がパイロット プロジェクトを超えて拡大していることにすぐに気づきました。成功を収めた最初の指標の 1 つは社内でした。「私たちは他の Agilent 部門と提携する必要があったため、実行すると提示した内容を実行することは非常に重要でした」と Sadler 氏は話しました。
Agilent はまた、社外での改善にも気づきました。顧客からのフィードバックが、市場の変化に対する Agilent チームの即応性の向上に役立ちました。開発プロセスの早い段階に顧客を含めることで、Agilent はソフトウェアの品質を向上し、市場と統合のリスクを低減できました。
Agilent のインサイトの 1 つは、すべてのアジャイル エピックにはストーリーのアップグレードが含まれるということを、完了の定義に含むことでした。Agilent でのソフトウェア品質の担当ディレクターである Babita Jain 氏とソフトウェア統合のマネージャーである Stefan Weiss 氏は、変革の実装を主導し、チームがプロジェクトの全体的なスコープを理解できるようにしました。「アップグレードが含まれていない場合は、エピックが完了したとは見なしませんでした」と Jain 氏は話しました。
アジャイル変革によって、品質だけでなく、信頼性も向上しました。2016 年には、OpenLAB クロマトグラフィー データ システムが予定どおりにリリースされました。アジャイル変革以降、Agilent は安定した頻度でソフトウェアを提供しており、現場で報告される不具合は減少しています。
成果の測定
「Agilent はアジャイル イニシアチブの成功は「現場での故障率の低さと顧客ロイヤルティの高さ」によって定義し、測定しています」と Sadler 氏は話します。顧客の定着率も重要です。ライフ サイエンス分野の成熟した競争市場では、顧客の減少は危機的な状況です。既存の顧客に新しいシステムを販売する力量は不可欠です。
Agilent の Jira ベースのキャパシティ モデルによって可能となる 4 つの重要な指標は次のとおりです。
バーンダウン/バーンアップ チャート
Agilent は以前、エンジニアリングの時間、人日、またはストーリー ポイントで作業を測定していました。今では、全員がバーンアップ チャートを使用して、完了した作業や総作業量を追跡しています。バーンダウン チャートは残っている作業量を示します。
市場に提供されたキャパシティの割合 (ペイロード)
キャパシティをモデル化して追跡する機能は、Agilent の成功の測定方法において重要な役割を果たします。Jira によって、Agilent は詳細なキャパシティ モデルを構築できました。「このモデルでは、計画フェーズで、リリースのために取り組む必要のあるストーリー ポイントの数をマーケティングに伝えることができました。マーケティングは、そのキャパシティに合わせてバックログをランク付けします」と Sadler 氏は話しています。
修正を提供する総数と時間の中央値
キャパシティ モデルではより詳細に表示されるため、Agilent は現場で報告される重大または深刻な欠陥の修正に使用されたキャパシティと、品質チームが発見し報告した欠陥の修正に使用されたキャパシティを比較して確認できるようになりました。
手動テストによって発見された欠陥の修正に費やした時間の割合
キャパシティ モデルによって、Agilent は顧客が高く評価する機能を作成するために費やした時間と、既存の製品を維持するために費やした時間を比較して測定できます。
3 年あまりで、この部門は付加価値のある作業に注力するキャパシティの割合を 2 倍以上に増やし、30 パーセントから 65 パーセントに増加しました。新しいアジャイル アプローチによって促進され、ソフトウェアの品質が改善すると、後で修正する欠陥も減少しました。
アジャイル変革プロセスを開始して 1 年後、Agilent のチーム メンバーがさまざまな「変革前」と「変革後」のシナリオを説明しています。
 | Before: Performance was measured in engineering hours, person days, or story points. |
|---|---|
 | 変革前: 異なるレベルのアジャイル トレーニングを受けたチームでは、エピック、ストーリー、サブタスクの定義が異なっていました。 |
 | 変革前: スクラム マスターがコードを記述し、チーム ミーティングを主導して、機能の優先順位を検討していました。 |
 | 変革前: バグを含む機能が承認されて、欠陥が後続の開発フェーズに持ち込まれる可能性がありました。 |
 | Before: Problems often occurred at the final hour, causing panic and substantial delays. |
 | 変革前: チームの作業のキャパシティを測定する手段はありませんでした。 |
Agilent のアジャイルな未来
継続的な改善を重視するあらゆる文化と同様に、Agilent のアジャイル変革は決して完了したわけではありません。次のステップには、サイクル期間の短縮や、能力に磨きをかけることを継続し、DevOps の指標の主要な要素である、市場のフィードバックから早期にインサイトを得ることが含まれています。
Agilent はリリースを毎年商品化していますが、すでにサイクル期間を大幅に短縮し、年 1 回のリリースを 6 か月のサイクル 2 回に分割しました。同社はサイクル期間を再び半分に短縮する計画であり、四半期ごとの頻度に移行する予定です。
顧客に、早期かつ頻繁に開発プロセスに関与してもらうことも、継続的な改善の対象となります。市場のフィードバックによる明確な証拠があれば、製品スコープに関する議論での利益相反の仲裁が減るということに自身のグループが気づいた、と Sadler 氏は報告しています。現場の顧客のために品質と使いやすさを維持することは継続的な優先事項であり、継続的にユーザーに関与することによって、第一に品質、次にリリース間隔とスコープ、という会社の優先順位を維持できるようになります。
教訓
Sadler 氏は、リーダーである Jain 氏と Weiss 氏を含むチームの成功を確信しています。両氏は、迅速かつ継続的な改善を促進する方法としてアジャイル開発を活用しました。Jira や Confluence など、適切なツールを利用すれば、チームは作業を 1 か所に統合して、進捗を測定できます。
Agilent は、アジャイル変革には研究開発、インバウンド マーケティング、品質を監督するスポンサーが必要だとわかりました。「この 3 つすべてを変革できなければ、成功を収めることはできないでしょう」と Sadler 氏は話します。「研究開発だけではアジャイル変革は成し遂げられません」最も重要なのは、職務内で行う作業ではなく、チームが連携する方法です。
また、Agilent は、開発工程内で顧客のニーズを完全に理解するという思い込みをやめることが不可欠だということもわかりました。アジャイル アプローチとは、確実な頻度に従って製品をリリースしたら、直接顧客からのフィードバックを受け取ることです。このアプローチでは、リリース日を重要なものとして扱う必要があり、適切な時期になったらチームは製品を現状のままリリースします。
最後に、アジャイル フレームワークでは問題が可視化されます、と Sadler 氏はアドバイスしています。たとえば、アジャイルはキャパシティのギャップを明らかにします。遅延を引き起こし、品質の低さを示す、プロセスの付加価値のない部分を明らかにします。ウオーターフォール アプローチからアジャイル アプローチに移行するには、チームの働き方を変えるだけでなく、文化的な変化も必要となります。アジャイルは、実に人から人へと伝播する継続的な改善の文化を促進します。
