Dan North氏が,ベルギーのブリュッセルで開催されたScaling Agile for the Enterprise 2016会議で,ビジネスマッピングについて講演を行なった。同イベントはAgile Consortium InternationalとUnicomが主催するもので,InfoQが取材している。
InfoQはそのNorth氏に,組織のIT部門がアジャイルを導入する際の,ビジネス的な見地から氏が見た問題点についてインタビューするとともに,ビジネスマッピングとは何か,組織のアジリティ向上にどのように役立つのかを聞いた。
InfoQ: 組織のIT部門がアジャイルを導入しようとする時の,ビジネス的な見地から見た問題について,詳しく説明して頂けますか?
North: 圧倒的に多いのは,ソリューションや,場合によっては詳細な内容も合意が取れているにも関わらず,対象となる組織がそれをまったく知らないというケースです。それでも彼ら自分たちのアジャイルメソッドを適用しようとするのですが,結果は機能のブレークダウンや見積,バックログのグルーミングといった,細かなプロセスの見掛け倒しに終わるだけです。いわゆる“ウォータ・スクラム・フォール”というもので,プロセス—表立った解析やリリース管理,その背後にある生きるための移行(transition to live)—が完了しても,相変わらずヘビーウェイトなプロセスのままで,市場投入時間の削減がまったくできていない,という状態なのです。
”アジャイル”プロセスがビジネスから完全に乖離しているから,何をやるにも遅くなってしまうのです。以前は単にサイロ型の開発者の肩を叩いて,機能を要求さえすれば,後はそれが出来上がるのを待つだけでよかったのですが,今では彼らの要求はバックログに送られて,見積に2週間を費やした後,数ヶ月たってスプリントにスケジュールされ,揚げ句の果てにはそれさえも守られないかも知れません。つまり皮肉なことに,彼らにとっての“アジャイル”エクスペリエンスとは,デリバリの遅延であり,プロセスとオーバーヘッドの増加であり,作業をしている人たちとの距離の拡大なのです。プラクティスを山ほど取り込んでみても,基本となっている原理やアプローチの目標を理解しないまま盲目的に適用すれば,このような結果になってしまいます。
InfoQ: アジャイルの採用はビジネスとITの距離を縮める役には立たない,ということなのでしょうか?
North: これはもどかしい部分です。このようなITによる専横的なアジャイルの導入では,ITとビジネス間の距離を縮められないのはもちろん,内部的な意味でも,デリバリチームとプロジェクトマネージャやプログラムマネージャといった従来型ガバナンスとの間に楔を打ち込むことになるのです。
InfoQ: ビジネスマッピングとは何か,説明して頂けますか?
North: ビジネスマッピングは,私とChris Mattsが開発したテクニックを包括した名称です。Chris Mattsは元ビジネスアナリストで,現在はポートフォリオとプロダクトマネージメントのコーチをしています。私たちは10年以上前にThoughtWorksで一緒に働いていました—私がBDDに感化されたのは彼の影響です—が,それ以来,彼からは影響を受けています。1年ほど前に私たちは,開発のスケーリングに関して非常によく似たモデルを開発していることに気が付いたのです。彼はポートフォリオのレベルから100単位のチームの1,500人程度を対象として,私はプログラムのレベルで10単位のチームの500人程度を対象として,それぞれが作業をしていました。それぞれ違うデータポイントを持っていたことで,このテクニックがどちらのスケールでも有効なことが分かったのです。
私たちは昨年の大半を,アクティビティやテクニックのさまざまなコンポーネントを洗練し,明確にする作業に費やしました。その結果が,一般的なコントロールベースのアプローチとは違う,ビジネスのアジリティに対するリスクベースのアプローチとなったのです。ビジネスマッピングでは,制約条件の理論(Theory of Constraints)を適用して不確実性の所在を明らかにするとともに,生産性の問題解決のために制約を仮定するのではなく,デリバリのための選択肢を作り出す方法を取っています。
InfoQ: 組織のアジリティ向上に対して,ビジネスマッピングはどのような効果を持つのでしょうか?
North: まず最初に,ポートフォリオレベルのイニシアティブとビジネスのおもな要因を整合させる“イニシアティブマッピング”を行います。次にそのイニシアティブの中で“デマンドマッピング”と呼ばれるプロセスを使用して,イニシアティブを実現するビジネス能力の提供に必要な作業を特定し,おおよその規模を測ります。そのライトウェイトなスコープ特定作業の一環として,プログラムチームは,スキルや能力上の制約を明らかにします。組織の側では“スキルマッピング”という活動によって,現在の能力と向上力—何ができるのか,どのような新たな機能を学びたいのか—を明確にすることで,制約問題に対するインプットを提供します。
そして最後の“デリバリマッピング”が,作業に従事する人々をフローと学習の両面において最適な方法で組織化します。現状のスキルや必要なスキルが何であるかによって,作業項目の再スケジュールや不足するスキルに対する再構成,あるいは予想されるスキル不足のバランスを取るための相互訓練や相互教育を行なうことが可能です。スキルの流動性(Skills Liquidity)として知られるこのアプローチは,従来のリソース平準化テクニックに対する新たな代替手段なのです。
InfoQ: InfoQ読者がビジネスマッピングをより詳しく学ぶためには,どのような方法があるのでしょうか?
North: 現時点では,これに関するChrisと私の書き物は多くありませんので,まずはleanpubで書籍として,ドキュメント化を始めたいと思っています。デマンドマッピングの概要に関する講演はオンラインでいくつか公開されていますし,スキルの流動性やリアルオプション(Real Option)については,Chrisが“TheITRiskManager.wordpress.com”という自身のブログに書いています。私自身のブログにも,個人的なバックログがあるので,もっと書かなくてはいけませんね!
この記事を評価
- 編集者評
- 編集長対応