IBMのEvan Leyboum氏が提唱する“アジャイル制約の理論”

InfoQでは、近く開催されるAgile Indonesiaカンファレンス2017の講演者に対するインタビューをシリーズで行なっている。講演者のひとりであるEvan Leybourn氏は現在、IBM Singaporeに勤務する。氏は世界中で開催されるAgile Conferenceの常連の講演者であり、最近ではニューヨークでBusiness Agilityカンファレンスの開催に参画した、シンガポールにおけるIBMのアジャイル実践者のリーダである。

InfoQ: Evanさん、簡単な自己紹介をお願いします。

私はいつも、自ら忙しくしています。IBMに来て18ヶ月ほどになりますが、これほどの規模の企業をどうやって“アジャイル組織”にするか、というチャレンジをずっと楽しんでいます！個人的に一番満足しているのは、ニューヨークで開催したBusiness Agilityカンファレンスですね。素晴らしいものでした。その他には、2冊目の本の執筆がほぼ完了しています(これは#noprojectsにあります)。今年中頃までに出版社用のレビューコピーを用意したいと思っています。

InfoQ: 過去数年間を見ると、アジャイルコミュニティでとても活発に活動していて、世界中を旅しているのが印象的ですが、世界のアジャイルシーンにおいて、最も重要な展開を３つ挙げるとすれば何ですか？

偏ってはいますが、ビジネスアジリティがナンバーワンです。アジャイルで“ある”という意識、すなわち組織のシステム、プロセス、部門全体にアジャイルを浸透させることが必要なのです。人事から財務、PMOまで。その次はDevOpsやCD、さらにその先を実現する重要なファクタとして、技術的なアジリティを継続的に発展させることです。そして最後は、従来のソフトウェア企業の枠を越えて、10年前には不可能と思われていた対象 — 銀行や政府機関においてアジャイルが成功したことです。

InfoQ: 確かに偏っているかも知れませんが、やりがいのある活動でもあると思います。組織全体がアジャイルになることが重要なのはなぜでしょう？

この件については、Eliyahu Goldratt氏には申し訳ないのですが、、“Evan’s Theory of Agile Constraints”という記事を書きました。

“組織がアジャイルになるレベルは、最もアジャイルでない部門によって制限される！”

とても基本的なことですが、制約の理論(Theory of Constraints)とは、どのようなプロセスにも制約要因があるということです。さらに重要なのは、制約要因が常に存在することです。アジャイルの制約理論(Theory of Agile Constraints)は、組織のビジネスアジリティに必ず制約があるということです。20年前のそれはITでした。すなわちソフトウェアチームです。ソフトウェアの領域にアジャイル、大文字の“A”で始まるAgileが登場したのは、その論理的帰結なのです。今日、アジリティの制約はITではありません。PMOであり、人事であり、財務であり、法務部門です。

InfoQ: そうですね。IT部門におけるアジャイルの採用はそのために始まりました。その結果として、ユーザが本当に必要とするものに基づいた、よりよいソフトウェアのインクリメンタルな提供が実現しました。一方でアジリティは、年間予算と固定的な計画サイクルという“古い方法”に拘るPMOによって制約を受けているように思われます。柔軟性のまったくない古めかしいルーチンのせいで、購買プロセスは相変わらず遅れたままです。しかし企業は、なぜそれをすべて変えたいのでしょう、なぜ彼らは“アジャイル”を目指すのでしょうか？

事はPMOに限りません。多くの組織のDNAがそうなのです。ですが、あなたの指摘は間違っていません。 同じ理由、すなわ見積の不正確さから、ソフトウェアは30年前にアジャイルになりました。アジャイルな組織は、5年計画が正しいという仮定だけで満足しません。その代わりに彼らは、反復的にマーケットの変化に対応する能力(およびガバナンス)を備えています。単なる受け身ではないアジャイル組織は、市場をリードする存在でもあるのです。

InfoQ 適確な答を得られないトピックのひとつとして、“価値の定義”があります。プロダクトオーナには、ユーザや顧客に提供する価値に基づいて、作業の優先順位を決めることが求められています。これはどのようにすればよいのでしょう？

定量化が簡単かどうかによって違います。多くの場合、金銭的利益で機能を表現することはできませんので、何らかの質的な指標を用いる必要があります。私がよく使うのは価値ポイント(value point)です。ストーリポイントのアプローチと同じように、価値ポイントは機能を他の機能と比較する相対的な尺度です。“どの機能を最初に手掛けるべきか”だけを知りたいのならば、価値ポイントで定義できます。

InfoQ: 初心者がストーリポイントや価値ポイントを簡単に計算するには、どのようにすればよいのでしょう？

これらはいずれも、複雑性や価値の相対的な尺度です。基準となるストーリ(これをXとして、その値を1SPとしましょう)に対する、相対的な労力ないし複雑性を評価します。YがXより2倍難しければ2 SP、ZがYより2倍難しければ4 SPになります。価値ポイントもこれと同じですが、プロダクトオーナが評価します。

InfoQ: 他の機能に関連している機能を評価する場合、それをビジネス価値、すなわちユーザに提供する価値に変換するには、どのようにすればよいのでしょう？プロダクトオーナが実際に(チームが認識する価値ではなく)ユーザを価値の優先度付けや定義の出発点として捉えていた、製品開発の好例は何かありますか？

まずは、推測値と実際値の違いを理解することです。この２つの数値は、まったく異なるものになる可能性があります。ですが、それがアジャイルを行なう理由でもあります — 一定の迅速なフィードバックがあることで、調整が可能になるのです。これを行なっている組織は、製品のインクリメントがリリースされる毎に、その実際のビジネス価値を積極的に測定することで、明確な値を手にすることができます。講演では、これを実現する方法のひとつである結果プロファイル(Outcome Profile)について話す予定です。

InfoQ: 同じように、アジャイル移行のROIを計算するにはどうすればよいのでしょう？アジャイルによるメリットを把握するために最も適したメトリクスは何ですか？

それは間違った質問だと思います。なぜアジャイルを行ないたいのか、という点から始めてください。結果プロファイル(説明、指標、ベースライン、ターゲット、依存関係、所有者)を定義するのです。ROIは、その結果に基づいて計算されます。それは組織毎に異なります。品質かも知れませんし、あるいはスタッフの維持、マーケットブランディング、ユーザの期待、市場投入時間、あるいは(正しくはありませんが)開発速度かも知れません。

InfoQ: なるほど、それでは私の会社は、３つの理由からアジャイル化を望んでいるとしましょう。A. より“スタートアップ企業的”に、革新的な製品をローンチできるようになりたい。B. より高品質なソフトウェアを開発したい(例えば、ウォーターフォールでは希望する品質を必ずしも実現できないので、それを改善したい)。C. 従業員の満足度を高めたい。この例では、先程の計算はどのようにすればよいのですか？

ビジネス成果の指標を定義できさえすれば、それは可能です。それは直接的な測定値かも知れませんし、間接的かも知れません。Cを例にしましょう。従業員満足度の向上は、満足度調査によって直接測定することができますし、退職率で間接的に見ることもできます。

InfoQ: 大企業の多くは、従来型の予算と計画のサイクルを使用しています。アジャイル的な成果の提供に合わせて予算方法を変更するには、どのようにすればよいのでしょう？

この質問には、ちょっとずるをさせてください。ひとつやふたつの段落で、お答えできそうもありませんから :-)

Beyond Budgeting、Pat Reed氏のアジャイルアカウント標準、InfoQのこちらにある私の#noprojects記事を参照してください。

InfoQ: #noprojectの話題もたくさん出ましたが、あなたにとってこれは何を意味しているのでしょう、また、なぜ組織にとって重要なのですか？

私にとって重要なのは、“一時的な努力(temporary endeavour)”というそのコンセプトが、アジリティとはまったく正反対だからです。組織が真の競争力を持つためには、継続的な価値提供と継続的な変化が可能でなければなりません。ここで重要なのが継続(continuous)です。需要や活動には変動があるかも知れませんが、ほとんどのITシステムを維持し、拡張するためには、リソースを継続的に配分すべきです。正しく実行されれば、“アップグレード”プロジェクトや“バージョン２”プロジェクト、“メンテナンス”プロジェクト、“グリーンフィールド”プロジェクト、“再開発”プロジェクトといったものを実行する必要はなくなります。何かを初めて作っている時や、進化ではなく革新的に変化している時であっても、プロジェクト構造はその終わり、つまりそのプロジェクトないし製品開発が完了するポイントを明示的に定義します。逆にむしろ、すべての製品は継続的に変化し、改善されるということを理解しなくてはなりません。早い時期にスタッフを投入することも可能ですが、適切な管理とキャパシティ計画ができていれば、さまざまな要求に対応することが可能になります。

#noprojectとは基本的にこのようなものです。継続的変化を成功裏に実現するためのアプローチ、構造、戦術、テクニックなのです。根本的に#noprojectsは、成果に対する活動の準拠性に基づき、価値によって評価され、指針となる原則によって制約され、継続的デリバリのテクニックによってサポートされます。

この話題に関して本を書いています。少しの幸運があれば、あと１～２ヶ月で完成するでしょう。

InfoQ: 来月のAgile Indonesiaでの講演では、どのような内容を期待してよいのでしょう？

ビジネスアジリティについて、実践的な紹介をする予定です。組織設計(“アジャイル組織は自分自身をどのように設計しているか？”)や移行(“1,000人の従業員をアジャイル組織のビジョンに従わせるにはどうすればよいのか？”)から、ガバナンス(“アジャイル組織が正しいことを行なっていると確信を持つにはどうすればよいのか？”)やリーダシップ(“アジャイルリーダになるというのはどういうことか？”)までです。