papanda 「アジャイル」という言葉を用いるとき、多くの場合その期待とは「アジャイルな開発」を意味するだろう。ソフトウェア開発、プロダクト開発をアジャイルにしたい、そうすることで…と。その入り方に何ら問題があるわけではない。ただ、現代組織の実状を踏まえたとき、アジャイルへの期待は異なってくる。
長らく効率性への最適化を直走ってきた事業や組織に必要なのが「探索（と適応）」であることには、もはや一片の疑いもない。そう、アジャイルへの期待とは「探索」それによる可能性を組織にもたらすことだ。これは「アジャイル開発」という言葉の守備範囲に入るものではあるが、より強調する点が「開発をアジャイルにすること」と「探索というケイパビリティを組織に宿す」ということで異なる。要は、開発と組織という点で語り先が違う。
この微妙な差分がときに期待違いを生むことになる。地と図の関係で言えば、「図」にあたるのがアジャイルな開発プラクティスなのか、探索活動（仮説検証）なのか。「アジャイルを組織に適用する」という肝いりで始めたプロジェクトが半年後にこの差分に直面し、一向に探索が進んでいないチームにステークホルダーから失望が寄せられるということがありえる。
開発プラクティスの実践と、仮説検証の実行とでは大きな開きがある。そんなこと起こる？と思う方も居るかもしれないが、「アジャイル」がまだ得体のしれない言葉として使われている組織では十分に起こりうる。得体は知れないが、とにかく組織にとってこれまでに無い何かが起こると、ステークホルダーは信じている。信じているからこそプロジェクトがスタートを切れるのだ。それだけに結果についての反応は時に激しくなる。
この手の期待違いを扱うのは実際のところ難しい。
・チーム、ステークホルダー、アジャイルコーチで思い描いている「アジャイル」が異なる
・そもそもアジャイルな開発プラクティスを実践するケイパビリティがチームにない
・もちろん、探索（仮説検証）が何たるかを知っている者もいない
・チャレンジすることにモチベーションを高めているメンバーがいる一方で、全くそうでもない者もいる
こうした背景を置きながら、一体どこからはじめれば良いのか。
何度かこの状況に直面している中で、得たのは「プロダクト作り」から始めることだった。多くの組織にとって最終的に必要なのは冒頭のとおり「探索」のケイパビリティである（最終的と言いつつ、実際には喫緊である）。その探索のケイパビリティを宿すためには、その経験を最も条件良く身につけるための「手段」としてプロダクト作りを用いる。もちろん、プロダクトを作ること自体には何らかの目的を要する。その一方で、組織ケイパビリティという観点では、プロダクト作り自体が探索のケイパビリティを得るための手段となるのだ。
実際の経験の積み上がりが無いところでの「新たな手法」に深入りしていくことの危うさは言うまでもない。プロダクト作りが探索活動の経験を支えることになる。「条件が良い」と述べたのは、たいていの組織がソフトウェア開発には無縁ではなく、何らかの環境を有していること。また、プロダクト作りのナレッジが一般的に広く流布している状況にあることからだ。
このあたりの主旨を次のスライドにまとめている。プロダクト作りを「仮説検証型アジャイル開発」で実践し、探索に関する最初の経験を獲得する。どのように仮説検証を行うか具体的な経験を得て、それを次の事業開発や組織運営に活かすというのが狙いだ。
もちろん、プロダクト作りに際して「アジャイルな開発」が求められるのは言うまでもない。かくして、冒頭におけるアジャイルの期待違いを吸収する下地が揃うことになる。あとは、いかにして探索の経験をケイパビリティとして昇華させるかだ。ここは容易ではない。開発、仮説検証から組織運営まで総合的に扱えるような環境があるのが望ましい。となると、R&D部門、新規事業部署、DX推進部署、情シス、マーケティング部門といったところで、”出島”的に取り組むのが現実的だ。組織に探索を宿すために、まずは探索の経験を十分に有する組織体を作ること。ここが変革における最初のマイルストーンになる。
Photo credit: matthias.ripp on Visualhunt.com
