アジャイルプロセスはなぜ機能しなかったのか

アジャイルソフトウェア開発宣言から四半世紀が経った。筆者は1999年にエクストリーム・プログラミング（XP）に出会い、2003年のアジャイルプロセス協議会設立に参画し、以来25年にわたってアジャイルプロセスの実践、研究、啓蒙に携わってきた。

その25年の実践から、率直に言わなければならないことがある。アジャイルプロセスは、多くの現場で機能しなかった。センセーショナルに登場し、一部の技術者に支持されたが、形式だけが広まり、本質は伝わらなかった。

本稿では、この機能不全の理由を、認識の前提が異なる構造という観点から説明する。

アジャイルプロセスの功績は否定しようがない。ブルックスが示したソフトウェアの本質的困難──複雑性、同調性、不可視性、可変性──に対して、アジャイルは人間の協調と反復による応答を可能にした。ウォータフォールに閉じ込められた産業に、変化への対応という息吹を吹き込んだ。

しかし、アジャイルマニフェストが唱えられてから10年が経過した2011年の時点で、筆者はすでに違和感を覚えていた。アジャイルプロセスは、実際のプロジェクトや組織でそれほど活発に利用されてきたとは言えなかった。この乖離はなぜ生まれたのか。

2011年4月、QCon Tokyoにて大槻繁氏との共同発表「アジャイルプロセスの呪縛」を講演した。「呪縛」とは、言葉によって行動の自由を制限すること。転じて、「アジャイル」という言葉を唱えて新しいパラダイムを妄信すること。そこで提示したのは、アジャイルプロセスに潜む四つの呪縛であった。

第一の呪縛：人間中心の呪縛。 アジャイルは開発者中心の幸福論に傾きすぎていた。個人の技術、能力、モチベーションに暗黙に頼り、ソフトウェアの側からの探求がほとんどされていなかった。やる気があってがんばれば上手くいくような無責任な姿勢。結局は人月の呪縛でもあった。

第二の呪縛：請負契約の呪縛。 アジャイルプロセスに合った契約を作るのではなく、ビジネスプロセスそのものを変えなければならなかった。しかし産業構造は動かなかった。

第三の呪縛：組織境界の呪縛。 ベンダーとユーザの構図、多段階下請け構造が、アジャイルの前提である協働を阻んでいた。

第四の呪縛：問題解決の呪縛。 アジャイルは問題解決の枠組みに閉じこめられていた。必要だったのは、問題解決（知識）から価値創造（知恵）への転換であった。

当時はこれらを産業や契約の問題として記述した。

その後も、エンタープライズアジャイル、アジャイルの標準化、スケーリングフレームワーク──アジャイルを機能させるための試みは何度となく現れた。しかし、どれも同じ壁にぶつかった。規模を大きくしても、手順を整備しても、認定制度を作っても、機能する現場は機能し、機能しない現場は機能しないままだった。

25年の実践を経て、筆者はこれらが本当の原因ではなかったと考えるようになった。四つの呪縛は現象の記述であり、その後の改善の試みもまた現象への対処であって、アジャイルが機能しなかった本当の理由はもっと深いところにある。

25年の実践の中で、筆者は繰り返し同じ現象に遭遇した。

ある技法や考え方は、それを必要としないほど既に実践できている人か、その必要性を認識できないほど混乱の中にいる人か、いずれかにしか届かない。分かる人には既に分かっている。分からない人にはいくら説明しても分からない。

この限界は、アジャイルにも例外なく当てはまった。

筆者自身も、この壁を越えようと試みてきた。赤点思考──完璧を目指すのではなく、まず最低限を見極めること。中心を捉える──枝葉ではなく本質に焦点を合わせること。間違える見積もり──正確さの幻想を捨て、不確実性を前提とすること。いずれも、アジャイルの本質に立ち返るための提案だった。しかし、これらが理解されることは少なかった。

アジャイル開発の本質は「目的に接続しながら変化を起こす」ための思考のあり方である。目的と手段の関係を構造として見通し、状況が変わったときに何を変えるべきかを問い直す──それが自然にできる認識の前提を持つ人のためのものだった。

ところが、手順に従い、決められた通りに実行することが仕事の中心にある人にとって、ユーザーストーリーは「やるべきことが明確に書かれていない曖昧な記述」にしか見えない。目標の背景が変わっても、それを再構成して行動に反映するという発想そのものがない。

これは知識の差ではない。説明を重ねても、事例を見せても、伝わらないものは伝わらない。結果として、形式だけを取り入れた"アジャイルごっこ"が蔓延する。

筆者はこの現象を幾度となく目撃し、長い時間をかけてようやく理解した。

人には、認識の前提が構造的に異なるものがある。

同じものを見ていても、何が問題で、何が当然かが、人によって根本から異なることがある。たとえば、「目的を共有しよう」と呼びかけたとする。ある人にとって、これは「上司が決めた目標を全員で確認する」ことを意味する。別の人にとって、これは「なぜこの事業を行うのかを問い直す」ことを意味する。同じ言葉を使っていても、見えているものがまったく違う。

この違いは、知識量の差ではない。経験の差でもない。認識の前提そのものが構造的に異なっている。これは能力の優劣ではない。

認識の前提が異なれば、同じプラクティスでも意味がまったく変わってくる。ペアプログラミングひとつをとっても、ある人にとっては「設計判断をリアルタイムに共有しながら構造を練り上げる行為」であり、別の人にとっては「隣で監視されながらコードを書く苦痛」でしかない。同じプラクティスが、認識の前提によって別のものになる。

アジャイルプロセスは、構造を扱える人のためのプロセスだった。目的と手段の関係を構造として見通し、状況の変化に応じて自らの行動を再構成できる人──そういう認識の前提を持つ人の間でのみ、プラクティスは機能する。認識の前提が異なる人がその場にいるとき、プラクティスは意味を失い、形式だけが残る。

四つの呪縛として記述した現象も、認識の前提の違いから説明し直すことができる。人間中心の呪縛は、個人の意欲や能力に頼る認識の前提から生じていた。請負契約の呪縛、組織境界の呪縛、問題解決の呪縛は、制度や手続きの枠組みで物事を処理しようとする認識の前提から生じていた。どちらも、構造を扱うという認識の前提とは異なるものである。

アジャイルの普及が限界を持っていたのは、やり方が悪かったからではない。構造を扱えることを暗黙に前提としたプロセスを、認識の前提が異なる人々に適用しようとしたからである。

認識の前提が異なるという事実は、アジャイルに限った話ではない。あらゆる制度──組織、教育、医療、行政──が、全員が同じものを見ているという暗黙の仮定の上に設計されている。アジャイルもまた、この仮定の上にあった。

この構造を見誤らずに読むための道具が必要になる。筆者はそれをメタウェアと呼んでいる。

メタウェアは問題を解決するための装置ではない。問題がどの認識の前提から、どの構造として現れているかを認識するための道具である。アジャイルが機能しない現場で起きていることを、「プロセスの不備」や「人の能力不足」として処理するのではなく、認識の前提が構造的に異なっているという事実として読む。

アジャイルプロセスの機能不全は、この道具なしには構造的に説明できなかった。そして、この説明が可能になったとき、同じ構造があらゆる領域に存在していることが見えてくる。

1. 濵勝巳・大槻繁「アジャイルプロセスの呪縛」QCon Tokyo 2011（2011年4月）
2. 濵勝巳「ソフトウェアエンジニアリングの遺言」ソフトウェアシンポジウム2014 WG6（2014年6月）
3. 濵勝巳「工業化の負債からの脱却」知働化フォーラム（2015年3月）
4. 濵勝巳「アジャイルプロセスの呪縛 概要」（2011年2月）