リーン、アジャイル、リーンスタートアップは、改善を進める上でお互いを強化することができる。データ駆動型改善フレームワークであるLean Pilotsは、部門間の協力を阻害する主要な組織的障害の排除を目的として、組織内の継続的改善の推進に使用される。
Dun & Bradstreetでアジャイルとリーンプラクティスのディレクタを務めるMariya Breyter氏は、パリで開催されたLean IT Summit 2017で、Lean Pilotsに関して講演を行なった。なお、本記事で紹介する見解は氏自身のものであり、Dun & Bradstreetのものではないことをお断りしておく。
Breyter氏の講演は、部門間協力の非効率要因を特定し、リーンとアジャイルの発想を組み合わせたソリューションを試行することによって組織の課題解決を図る、同社のフレームワークがいかにして開発されたか、という説明から始まった。
チームが新たな改善に着手する時の最初のステップは、自分たちが達成すべき目標を知ることである。何を達成すべきかを明確にし、何をもって成功とするかを正確に知ることが必要だ、と氏は言う。そのために1ページ記述を使用して、チームが実現しようとしている改善点とその理由を文書化する。
改善の実行にはスクラムのアプローチを採用する。自己組織化チームとして成功するためには、どのような方法であれ、プロフェッショナルの協力を得ることになる。ここで必要なのは改善のバックログと、改善の優先度を決定するプロダクトオーナだ。この構成で、2週間のシックスシグマDMAICサイクルのイテレーションを実施する。改善イテレーションの最後にはデモを実施して成果を示すとともに、十分な議論を行ない、全員がデモとレトロスペクティブのリズムを同期する。
チームが立案したソリューションの試行と検証のためには、リーンスタートアップを併用する。適切でないことが判明したならば、それを放棄して、新たな解決策を模索する。ソリューションに執着してはいけない、問題に執着するのだ、と氏は言う。
InfoQではLean IT Summit 2017の様子をQ&Aや要約、記事で取り上げるとともに、Lean Pilotsフレームワークによる改善の実行についてMariya Breyter氏にインタビューした。
InfoQ: 大きな障害を取り除こうとする時に企業が直面する課題は、主にどのようなものがありますか?
Mariya Breyter: 2016 State of Agile Reportでは、製品デリバリの速度低下、優先順位変更に関する管理不在、デリバリの予測性と可視性に関わる問題などが共通的な課題としてあげられています。これらはいずれも、作業が文化の異なる場所に分散することによる作業者のモラル低下や管理上の問題などに関連しています。私たちDun & Bradstreetでもこのような、顧客を満足させるための製品の迅速なデリバリに影響を及ぼし、ビジネスの成功を覚束なくさせるような問題を経験しています。例えば新たなプラットフォームへのユーザの移行、サードパーティベンダの導入、販売資産のグローバルな統合、あるいは顧客とのサービス契約の更新、といったものです – いずれの場合においても私たちは、プロセスを簡素化・自動化・合理化し、社内外のユーザにとって生産的で満足いくものにする、というニーズを特定しました。
InfoQ: リーンとアジャイルはどのようにして相互補完し、互いを強化することができるのでしょう?
Breyter: リーンとアジャイルの関係は複雑です。直接的な関係性を否定するアジャイリストもいます。アジャイルのマインドセットが価値の実現、ムダの削減、システム思考に基づいている点は認識されていますが、リーンについては、ムダの削減とプロセス効率の改善によるコスト最小化に注目した製造業のアプローチであり、アジャイルはその考え方をソフトウェアデリバリとその関連プロセスに適用したに過ぎないと理解されていることが少なくないのです。これは部分的にしか正確ではありません。なぜならアジャイル、特にスクラムは、2つの重要な概念 – 漸進的デリバリ、機能横断型チームに基づく実行 – をリーンに持ち込むものだからです。
私たちのLean Pilotフレームワークは、作業リズムとしてのリーン・シックスシグマDMAICサイクルを、スクラムフレームワークを使って実装したものです。DMAICはデータ駆動型の品質戦略で、プロセス改善に使用されます。シックスシグマのイニシアティブとして不可欠な部分であると同時に、一般的な、独立した品質改善手順としても導入可能です。
スクラムの場合であれば、(ビジネスプロセスの改善やプロセス自動化、製品拡張などの)改善項目のバックログから、イテレーション(スプリント)毎にひとつ以上の優先的な機能を実施して、成果がLean Pilotの成功基準を満たしているかどうかを定義します。これこそが、リーンスタートアップの実験的なコンセプトが活躍する場です。その対策でパフォーマンスが既定のレベルに達するのであれば、私たちは辛抱強く実施します。成果が不十分ならば、その仮説を無効として、次回のスプリントでは次に優先度の高い対策に方向転換します。これは安全かつ早期に失敗を見極める方法であり、あらゆる仮定を検証する上で高い効率性が期待できます。
この組み合わせが、現代的な障害の持つ組織横断性と機能横断性とも相まって、リーン-アジャイルフレームワークを非常に強力なものにしているのです。
InfoQ: Lean Pilotsについて説明して頂けますか?どのような目的で、どのように使用するものなのでしょう?
Breyter: 定義としては次のとおりです – “Lean Pilotsは、組織の重大なリスクと関連性を持つ、主要かつ機能横断的な組織的問題を排除するためのフレームワークを提供する、内部改善のイニシアティブである。”
どういう意味でしょう?Lean Pilotは当社の社内技術ですから、まずは私たちを説明することから始めなくてはなりません。Dun & Bradstreetは、世界中の2億5000万を越える企業を記録した最大の商用データベースを駆使して、顧客のビジネス関係の構築を支援する企業です。
Lean Pilotは私たちに、内部的な非効率性を迅速に解決すると同時に、長期的なソリューションを提供するための手段を提供してくれます。私たちが運用しているLean Pilotは一般的に、プロセスの非効率性や顧客の不満、あるいはエンド・ツー・エンドプロセスにおけるさまざまなタイプのムダに関連しています。いずれの場合においても、これらPilotには、自己組織化チームによる分析と実験の実施、短周期での計測によるチームの活動継続あるいは方向転換の決定などが含まれています。
Lean Pilotプロセスで最も重要な部分は、それがリーン方式、ジャスト・イン・タイムで開発されたことです。私たちがLean Pilotを始めた時点では、スクラムフレームワークを採用し、機能横断型組織のみを目的として、DMAICをリズムとして提供する、という考えしかありませんでした。つまり、リーンプロジェクトのバックログはJIRAやTrelloで管理されていたのです – それぞれのLean Pilotチームには、バックログにある“ユーザストーリ”の優先順位付けを担当するプロダクトオーナと、選択された改善策の実施と継続的測定を行なうスクラムマスタがいました。各イテレーションの最後には、ステークホルダに対する完成した“製品”の“デモ”が行われ、チームがLean Pilotプロセスの改善策を検討する“レトロスペクティブ”が実施されました。当時の私たちは、複数の境界を作り、ベストプラクティスを定義しなくてはなりませんでした – 例えば、リーンプロジェクトの加入と退出を採点するメカニズムの開発と検証が必要だったのです。
完了基準について少し説明しましょう。6ヶ月間にわたって私たちは、3ヶ月毎の“go/no-go”デモを通じて、私たちの考え得た仮説の無効性をパイロットが証明することにより、早い段階でのコスト削減が可能であることを確認する一方で、それまでの仮説の一部に実行する価値のあることを確認しました。そこで私たちは、それまでのパイロットの管理から、パイロットに関する自己組織化チームの構築へとアプローチを転換したのです。現在では、4~6回のスプリント終了を経て自立したチームから、コーチが離れても影響がないようになりました。これは大きな成果であり、私たちのコンセプトに対するアプローチの指針となっています。
InfoQ: 講演ではLean Pilotに関するケーススタディがいくつか紹介されましたが、障害を取り除く上で、Lean Pilotがどのように使われたのでしょうか?
Breyter: 契約自動化(Contract Automation)パイロットを例に説明します。長い間、当社の顧客とのサービス契約は、セールスチームにとって大きな負担になっていました。更新時には多くの手作業を必要としていたため、平均的な処理時間が週単位に達していたのです。私たちは基本契約書の文言の変更に関する仮説をいくつか検証しました。その過程において、価格戦略に関する仮説については、実際に行なう前に無効と判断しました。伝統的な手法に従うならば、ワークフロー自動化ツールの導入から始まって、数百万ドルのプロジェクトになったと思いますが、Lean Pilotを使用することで、QTCアプリケーションの簡単なカスタマイズというわずかな投資のみで、人手による介入を必要としない電子的な契約を締結する顧客数を大幅に増やすことができました。12ヶ月の間で、電子的な手段による契約数が34%増加したのです。
この例では、フレームワーク全体が有機的に展開したと言えます。意図的ではありませんでしたが、パイロットの適合能力をよく反映しています。いくつか挙げるとすれば、顧客が電子的手段で受け入れる契約数を増やす自動契約パイロット、新しいEU規制の厳しい時間的制約に準拠するためのプライバシ保護パイロット、Comprehensive Assessment Report(当社製品のひとつ)によるプロセス拡張、新たなビジネスに対するグローバルなDUNS番号(固有ID)生成に関する顧客エクスペリエンス改善、サードパーティベンダエクスペリエンスおよび全体プロセス、といったものです。これらプロジェクトのほとんどにITコンポーネントが含まれていました。例えば、サードパーティベンダエクスペリエンスでは、ワークフロートラッキングを改善するためにポータルの改修を行いました。注目に値するのは、これらのパイロットとビジネス、ITステークホルダがすべてひとつのLean Pilotチームに属し、役割と期待される業務、責任が明確になっていた点です。
InfoQ:Lean Pilotsフレームワークの適用から学んだことは何ですか?
Breyter: 肯定的なことも課題も、多くのことを学びました。課題からお話しましょう。Lean Pilotチームのメンバはみな、ITやセールス、製品、マーケティング、法律など、それぞれの分野における主題専門家(SME)です。これはどのパイロットにも言えることで、彼らはみなLean Pilotにパートタイムで参加しながら、自身の日々の責務も並行して行なっています。これは問題でしたが、彼らの献身的な態度が救いになりました。Dun & Bradstreetはデータ重視、絶えない好奇心、本質的な寛大さを基本的価値としていますが、これらすべてをチームメンバに説きました。パイロットに“割り当てられた”人はいません – 個々に対して、貢献の意思があるかどうかを確認したのです。同時に私たちは、このプロジェクトがチームメンバのワークライフバランスに影響しないために、具体的な取り組みを行いました。詳しいことは、レトロスペクティブの時に説明します。
もう一つの課題は、パイロットのベースライン化でした。パイロットはそれぞれ、実前に定義された成功基準によるデータ駆動型で行われます。しかしながら収集するデータには、複数のワークフローやステークホルダー、世界中のシステムと連携したレガシーシステムやグローバル障害が含まることが少なくないため、成功を定義して漸進的に測定するのは簡単ではありませんでした。結果的に私たちは、スプリント0の一部としてデータのベースライン化を実施し、各スプリントでデータ測定を“ユーザーストーリ”として行なうことにしました。これが大きな課題であったのは、成功を事前に定義した上で、それに対して結果を継続的に測定しなければ、いつ終了してよいのか分からないからです。求めていた成果を達成できたかどうかさえ分かりません。例えばベンダ導入の改善プロジェクトを開始した時には、サイクルタイムを17.5日から短縮する必要があることは分かっていましたが、プロジェクトの完了時期を決定しなければなりませんでした。調査の結果、同等の作業の平均期間が10日であることが分かったため、その“Voice of Customer”調査に基づいて、少なくとも6日にまで短縮できればパイロットを成功と判断することにしました。現在は9.1日ですが、これが6日のサービス目標レベルに達したならば、パイロットを終了する予定です。
すでに成功しているものもいくつかあります。“go / no-go”チェックポイントをリズムとする漸進的なデリバリは、非常にうまくいっています。十分な参加者のあるレトロスペクティブと組み合わせることで、ムダを排除し、チームに対する継続的なフィードバックを可能するという、2つの目標を達成した力強いリズムを生み出すとともに、ステークホルダとの緊密な関係を築くことができました。一例として、最初私たちは、チームメンバたちの活動可能時間を問題とは思っていませんでした。彼らはいずれも、特定のスクラムチームにフルに割り当てられていなかったからです。レトロスペクティブでの指摘によって、メンバに対する期待値を明確化し、Lean Pilotチームに参加する前に、彼らのチームマネージャと作業時間の交渉を行なうようになりました。
また、Lean Pilotに参加してくれそうなメンバに対して、Lean Pilotに参加して自律型を実感してみたいという意思があるかを訊ねると同時に、自身で意思決定を行なう権限を彼らに与えました。また、プロセスを実行する必要が生じた直後に、ジャスト・イン・タイムでプレーブックとして文書化にすることが、すべてのプロセスを繰り返し実行可能にする上で非常に有効でした。これによってプロセス開発とドキュメントのオーバーヘッドがほとんどなくなると同時に、進行中のフィードバックループによって実際にテストされ、リアルタイムで改善されるフレームワークを構築することが可能になったのです。
最も重要なのは、私たちが学習と改善を継続していることです。この方法を試してみたい、あるいはもっと深く知りたい方には、いつでもノウハウを公開するつもりです – 製品としてのフレームワークではなく、実際にDun & Bradstreet社内で私たちが運用しているものですから、喜んで公開しますし、逆にコミュニティから学びたいと思っています。
この記事を評価
- 編集者評
- 編集長アクション