2018年におけるアジャイルソフトウェアの現状

これは、メルボルンで開催されたAgile Australia、2018での私の講演の書き起こしです。私は、アウトラインだけを参考に、即興で講演を行いました。この書き起こしは、講演の流れを追いつつ、文章がよりまとまりのあるものになるように編集しました。講演の動画はInfoQでご覧いただけます。

Agile Australiaで私の講演を以前に聞いたことがある方はどれくらいいらっしゃいますか？そして、また戻ってきてくださったのですか？すごいですね。Agile Australia、あるいは他のカンファレンスで私の講演を聞いたことがある方ならご存知かと思いますが、私は講演の度に、ほとんど毎回「21世紀におけるソフトウェアデザイン」のようなタイトルを付けています。なぜなら、それが曖昧なタイトルであり、何でも好きなことを話せるからです。今回もそうしようと思っていましたが、もう少し具体的に、2018年のアジャイルコミュニティの現状について話すことにしました。スライドや巧妙な図、美しいトランジションを使った綿密に計画された講演ではなく、ただ私が適当に話すことにしました。以前にもやったことはありますが、しばらくぶりなので、どうなるか見てみましょう。

アジャイルの現状を見てみると、多くの点で、ある意味表面上は非常に良い状況に見えます。例えば、この聴衆の規模を見てください。私たちは巨大であり、この大きな会議場に収まっています。実際には、外がかなり混雑していたため、あまりうまく収まってはいませんが。さまざまな場所に行くと、アジャイルが散見されます。誰かがハーバード・ビジネス・レビューの表紙に「アジャイル」と書かれたものを送ってきました。つまり、至る所にあるということです。これは、10年前、あるいはもっと昔に、スノーバードのスキー場で自分たちのことを何と呼ぶべきかについて話し合っていた頃からの大きな変化です。成功のように聞こえますが、昔からアジャイルに携わってきた人たち、90年代後半に「アジャイル」と呼ばれる前からやっていた人たちに話を聞くと、実際には多くの不安、失望、不満が漂っています。

実はそれは珍しいことではなく、私が知る限りでは、ほぼずっとそうでした[1]。そして、その不満は改善したいという願望の表れであるため、実は良いことです。しかし、それは「なぜ私たちは苦労しているのか？」という感覚につながります。

私たちが現在直面している課題は何でしょうか？10年前の課題は、人々がアジャイルを真剣に受け止めることでした。私がオーストラリアのThoughtworksのクライアントの1つに行った時のことを覚えています。彼らは私にいつもの「マーティン・ファウラーに来て講演をしてくれ」というようなルーティンをしてほしかったのです。クライアントの誰かが、「ええ、何でも好きなことを話してほしいのですが、アジャイルのことについては何も言わないでください」と言いました。これは、私がアジャイルについてよく話していた2000年代半ばには少し驚くべきことでしたが、当時はそのような感覚でした。それは、何か悪いことで、話したくないようなものだという感覚です。

今ではアジャイルはどこにでもあり、人気がありますが、重要な変化がありました。それは、私の同僚が「昔はアジャイルについて話すと、クライアントから最初から反発があり、そこから重要な会話が生まれていました。今は、彼らは『ああ、私たちはもうアジャイルをやっています』と言うのですが、そこに行ってみると、私たちが期待していることと非常に大きな違いがあることに気づきます。Thoughtworksは、自分たちがアジャイルの概念に深く浸透していると考えていますが、それでも『ええ、私たちはアジャイルをやっています、問題ありません』と言う企業に行ってみると、私たちが期待しているものとは全く違う世界を見つけることになります」と述べたように、非常にうまく要約されています。

現在の課題は、人々がアジャイルをやりたがらないようにすることではなく、私が偽アジャイルと呼ぶもの、つまり、名前だけがアジャイルであり、実践や価値観が全くないものへの対処です。ロン・ジェフリーズは、それを「ダークアジャイル」、または具体的に「ダークスクラム」とよく言及しています。これは、アジャイルを装うよりもさらに悪いことであり、90年代後半やスノーバードでこの種の仕事について議論していた際に目指していた基本的な原則に反して、積極的に「アジャイル」という名前を利用しています。

それが現在の戦いです。アジャイルをこのカンファレンスのような群衆が集まるほど立派なものにすることではなく、人々がアジャイルと呼んでいるものの多くが、そうではないことを認識することです。私たちはそれを認識して戦わなければなりません。なぜなら、「私たちは『ポストアジャイル』に進んでいるのだから、新しい言葉を考えなければならない」と言う人もいますが、それは根本的な問題の解決にはなりません。重要なのは価値観と原則であり、私たちはそれらに対処し、前進させ続けなければなりません。同じラベルを使っても構いませんが、それが実際に何を意味するのかを人々に知らせる必要があります。[2]

それが問題の大まかなレベルだとすると、どのように特定のことに焦点を当てればよいでしょうか？私は、私たちが注目すべき最も価値があると思われる、3つの主要な問題領域に焦点を当てたいと思います。

これらの最初の1つは、私がアジャイル産業複合体と呼ぶものです。公平を期すために言えば、私もその一部です。そうですよね？私は今、アジャイルについてここで講演をしていますが、実際、私たち全員がある程度はその一部であり、多くの人はアジャイルコンサルティング会社の何らかの形で関わっています。おそらく、そのタイトルにアジャイルが含まれているでしょう。しかし、推進されていることの多くは、私が述べたように、私たちの多くの概念に反する方法で推進されています。

特に、初期のアジャイル提唱者について非常に感銘を受けた中心的なことの1つは、人々がどのように働きたいかを自分たちで選択するときに、最高のパフォーマンスを発揮するという認識でした。

アジャイルマニフェストについて議論し、4つの価値観を提示した際、私たちはそれらの価値観がどのような順序で並んでいるかについてはあまり気にしていませんでした。しかし、最初のものについては意見がありました。それは、「プロセスやツールよりも個人と対話を重視する」ということです。私にとって、それはアジャイル思考の非常に重要な部分を明確にしました。ソフトウェア開発で成功したいのであれば、良い人材を見つける必要があります。人間的なレベルで協力し合い、効果的に連携できる良い人材を見つける必要があります。彼らが使用するツールの選択や従うべきプロセスの選択は、二の次です。それは、基本的にプロセスオタクの集まりから出た非常に重要な声明だと思いました。つまり、私たちは全員、ある程度プロセスの専門家でしたが、それでも私たちが議論していたことは実際には二次的な重要性であることを認めていました。重要なのは、チームが独自の道を選択することです。

さらに、チームは自分たちが従うプロセスを選択するだけでなく、それを継続的に進化させ、変更していくことが積極的に推奨されるべきです。あらゆる種類のアジャイルプロセスやアジャイル手法の1つの特徴は、本質的に非常に滑りやすいということです。それは、毎週、毎月変化します。私がよく人に言っていた言葉の1つは、「1年前にやっていたのと同じ方法でエクストリームプログラミングをやっているとしたら、それはもはやエクストリームプログラミングではない」ということです。なぜなら、もし自分たちで責任を持ち、自分たちの状況に合わせて変えなければ、その重要な部分を見逃しているからです。これを機能させるために設定できるさまざまな儀式や習慣があり、振り返りは、多くの人が非常に重要だと考えている手法です。実際、ロン・ジェフリーズは、アリスター・コックバーンのアジャイルへのアプローチは「平和と調和の中で集まり、毎週ソフトウェアをリリースし、改善する方法を見つけるために毎回振り返りを行う」ことだと冗談を言ったと思います。振り返りは、実践において本当に中心的な部分です。

さて、実際に形式的な振り返りを行うかどうかは、実際には問題ではありません。振り返りボードに4つまたは5つの項目のラベルがあるかどうか、あるいは振り返りをどのように行うかも重要ではありません。重要なのは、自分たちが何をしているのか、どうすればもっとうまくできるかを考えるという概念であり、それを実行するのがチームであるということです。それが中心的なことです。

これは、フレデリック・テイラーのプロセス担当者を分離するという考えに対する反動です。ここにいる人の中で、フレデリック・テイラーとそのアプローチの話を知っている人はどれくらいいますか？[数人が手を挙げる]フレデリック・テイラーという名前を聞いたことがある人、または聞いたことのある人はどれくらいいますか？さらに数人。もっと多くの人が手を挙げるべきです。彼は、人々の日常生活に実際に影響を与えたという点で、20世紀の歴史の中で最も重要な人物の一人です。彼は、19世紀後半にアメリカで、当時発展していた産業職場の人々をより効率的にしようとすることに非常に興味を持っていました。彼の平均的な労働者の見解は、彼らは怠惰で、腐敗しており、愚かであるということでした。したがって、彼らが特定の機械を作る方法を決定することを望まず、もっと知的で教育を受けた誰か他の人が、それを実行するための最良の方法を正確に把握する必要がありました。つまり、これをしてからあれをするのか、あれをしてからこれをするのかということにまで踏み込みます。これは、動作と動きの非常にスクリプト化された感覚です。時間と動作の業界全体がそこから生まれました。この概念の中心にあったのは、仕事をしている人がそのやり方を決めるべきではないということです。計画を立てる別のグループがこれを行うべきであり、それが20世紀初頭の製造業や工場での作業に大きな影響を与えました。

そしてそれはソフトウェア業界にも影響を与えました。「物事をどう進めるかを考えるにはソフトウェアプロセスの専門家が必要で、プログラマーはただその枠に当てはまればいい」という考え方が蔓延したのです。しかし面白いことに、ソフトウェアの人々が、ソフトウェア開発の未来として、このような非常にテイラー主義的な考え方を採用する必要があると話していた（80年代から90年代にかけて、そう言う人々をよく見かけました）一方で、製造業の世界では、それから脱却する動きがありました。多くの製造現場で起きていたことは、実際に作業をしている人が、何が起きているのかを一番よく理解しているので、より発言権を持つべきだという考え方でした。

アジャイル運動は、それを推し進めようとする動きの一部であり、「実際に作業をしているチームが、どのように進めるかを決めるべきだ」と主張しようとするものでした。なぜなら、私たちはソフトウェア開発者について話しているのです。高給で、高学歴で、できれば意欲的な人々です。ですから、彼らはそれぞれの状況において何が必要かを判断すべきなのです。

「それぞれの状況」が重要になるのは、ソフトウェアの種類によって異なるからです。私は人生のほとんどをエンタープライズアプリケーション、つまりデータベースをバックエンドとし、GUI/Webフロントエンドの世界で過ごしてきました。私が知っているほとんどの人がそうですが、それは電話交換機や組み込みソフトウェアの設計とは大きく異なります。私が比較的慣れ親しんでいる世界でさえ、チームによって状況は異なり、連携する必要があるレガシー環境も異なり、チーム内の個人の関係性も異なります。これほど多くの違いがあるのに、どうして誰にでも当てはまるような一つの方法があると言えるでしょうか？それは不可能です。しかし、私がよく耳にするのは、アジャイル産業複合体が人々に方法を押し付けているということです。それは私にとっては絶対に間違った行為です。

私は「悲劇」と言おうとしましたが、「間違った行為」という言葉の方が適切だと思います。なぜなら、ソフトウェア開発には万能な解決策などないからです。アジャイルの提唱者でさえ、アジャイルが必ずしもどこでも最良の方法だとは言わないでしょう。重要なのは、作業を行うチームがどのように行うかを決めるということです。それはアジャイルの基本的な原則です。つまり、チームがアジャイルなやり方で作業したくないのであれば、その状況ではアジャイルは適切ではない可能性があり、（アジャイルを使わないこと）が、ある種のねじれた論理の世界では、彼らが物事を進める最もアジャイルな方法だということさえあり得ます。

ですから、最初の問題は、アジャイル産業複合体と、物事を行うための唯一最良の方法を押し付けることです。これは私たちが戦わなければならないものです。

第二の問題は、私たちの仕事における技術的な卓越性の重要性が認識されていないことです。私が参加する多くのアジャイルカンファレンスでは、ソフトウェアを書くための実際の技術についてはあまり語られません。ちなみに、ここにいる人のうち、ソフトウェア開発者は何人いますか？[数人が手を挙げる] まばらですが、ごく少数です。同じ問題は、アジャイルアライアンスのメインカンファレンスでもしばらくの間見られました。彼らは、プロジェクト管理側の人々やそのような種類の人がたくさん参加していることに気づきましたが、実際に作業をする技術的な人はあまり多くなかったのです。それは本当に悲劇的なことです。さらに悲劇的なことに、一部のソフトウェア開発者は「ああ、私たちは自分たちのための全く新しい世界を作らなければならない。ソフトウェア職人運動で、私たちはビジネスの専門家やプロジェクトマネージャー、ビジネスアナリストから離れて、技術的なことだけを話すことができるようにしよう」と言うようになりました。しかし、それはひどいことです。なぜなら、アジャイルのポイントは、これらの異なる分野を組み合わせることだからです。JavaScriptを叩いている一番下っ端の新米プログラマーは、彼らが働いているグループのビジネス問題やビジネス戦略について考えている人々と繋がっているべきなのです。

私の第三のポイントで、それについてもう少し詳しく説明しますが、それは、私たちがこれらの技術的なスキルに注意を払い、それらをどのように育成し、成長させ、重要にするかを考えなければならないことを意味します。私はここ数年、主な執筆活動として、リファクタリングに関する本の新版を執筆してきました。ここにいる人で、リファクタリングについて聞いたことがある人は？[多くの人が手を挙げる] よいでしょう。では、リファクタリングを正確に説明できる人は？[手を挙げる人が減る] むしろ少ないですね。リファクタリングは、ソフトウェアを簡単に変更できるように構築できる方法全体に適合するため、アジャイルな考え方全体の中核となる技術です。アジャイルを人に説明するとき、私は通常、2つの主要な要素があると説明します。1つは既に話しましたが、チームの優位性と、チームがどのように行うかという選択です。しかし、もう1つは、変化に迅速に対応し、変化に簡単に対応できる私たちの能力です。

私はいつもメアリー・ポッペンディークの「要件の遅い変更は競争上の優位性だ」という言葉を気に入っていました。しかし、それを実現するためには、そのような変化に対応できるように設計されたソフトウェアが必要です。リファクタリングは、変更を行うための規律正しい方法であるため、この点で中心的な役割を果たします。しかし、「現在、ソフトウェアをリファクタリングしているので、今後2週間は壊れたままになります」のようなツイートを誰かがした場合、それはひどいことです。ブーッ、それはリファクタリングではありません。リファクタリングは、すべてが機能し続けるような小さな変更のことです。リファクタリングはソフトウェアの観察可能な振る舞いを変更しません。それがリファクタリングの定義です。そして、私はそれを定義した張本人なので、よく知っているはずです。

リファクタリングは、ソフトウェアの観察可能な部分を変更しない小さな変更の積み重ねですが、その内部構造はすべて変更します。通常、（リファクタリングは）新しい機能を追加したいものの、現在の内部構造がその新しい機能にあまり適していない場合に実行します。そこで、新しい機能を簡単に組み込めるように構造を変更し、常にリファクタリングを行い、何も壊さないようにして、それから組み込みます。ケント・ベックはこれを次のように要約しています。「変更を行いたいときは、まず、変更を容易にしてください。（警告：これは難しいかもしれません。）次に、容易な変更を実行してください」。これはリファクタリングを使用するための非常に重要な方法ですが、リファクタリングは常に継続的に行うものであるため、それ以上の意味があります。あなたはコードを見て、「これは何をするのだろう？どうも理解できない。これについて考えてみよう。掘り下げてみよう。ああ、このコードが何をするのか理解できた」と自問自答します。次に、ウォー​​ド・カニンガムの言葉を借りれば、「頭の中の理解をコードに落とし込む」ために、構造を再構築したり、名前を変更したりします。名前付けは、これらすべてにおいて非常に重要な部分です。そうすることで、次回あなたが、あるいは誰かが同じコードを見るとき、そのパズルを解くような作業をする必要がなくなります。

望ましい変更ごとに、変更を容易にし（警告：これは難しいかもしれません）、次に容易な変更を行う

-- ケント・ベック

なぜこれが重要なのでしょうか？変更を行いたい場合、変更を迅速に追加したい場合、プログラムのどの部分が重要なのか、それらは何をするのか、そしてどのようにすれば変更を迅速に行えるのかを理解する必要があるからです。これはモジュール性にも影響を与えます。モジュール化されたソフトウェアがあれば、すべてを理解する必要はなく、その一部だけを理解すればよいのです。技術的な卓越性とは、そのような適応性の高いソフトウェアを構築できることです。

そうすると、自己強化的な原則が生まれます。ソフトウェアを迅速に変更して新しいものを追加できると分かると、最初からソフトウェアにやりたいことをすべてやらせようとしなくなります。そうする必要がないからです。後で変更できるからです。これはYAGNI（「You aren't gonna need it」）の原則です。ソフトウェアに機能を追加しないでください。必要になるまで。そうすると、ソフトウェアが肥大化して理解しにくくなるからです。しかし、この戦略は優れたリファクタリング技術がなければ全く役に立ちません。そして、リファクタリングはテストに依存しており、継続的インテグレーションにも依存しています。そして継続的インテグレーションと共に、継続的デリバリーという手法があり、ソフトウェアを非常に頻繁にリリースできるという考え方があります。そして一部の組織では、実際にソフトウェアを非常に頻繁にリリースしています。

さて、ソフトウェアの迅速なリリースは、大量のエラーを容認する覚悟がある場合にのみ可能であり、ソフトウェアを信頼できるものにしたいのであれば、よりゆっくりと慎重に行う必要があるという考え方があります。それは間違いです。そして、これが非常に間違っていることを示す証拠がますます積み重なってきています。今年私のお気に入りの本であり、今年最高のになるだろうと思っているのは、ニコール・フォースグレン、ジェズ・ハンブル、ジーン・キムによる「Accelerate」です。（私の本が今年出るので、それを考えると悲しいですが、2位になることを願っています）この本の中で彼らは、多くの組織の調査を調べ、さまざまなプラクティスが物事にどのように影響するかを示しています。彼らが実証していることの一つに、1日に何度もリリースすることと低い欠陥率が両立することがあります。なぜなら、欠陥率を下げる方法を見つけなければ、1日に何度もリリースすることはできないからです。それには、自動テスト、リファクタリング、YAGNIなど、私たちが話しているようなプラクティスが必要です。エクストリームプログラミングの最も重要な点は、エクストリームプログラミングの個々のプラクティスが互いに補強し合うことです。

私が強調したい3つ目のことは、ソフトウェアプロジェクトという概念をなくすことの重要性です。代わりに、立ち上げてしばらく実行したら停止するプロジェクトではなく、「より長期的なものに焦点を当て、その周りにプロダクトチームを組織しよう」と言う、プロダクト指向の視点に切り替えたいと思っています。別の考え方としては、組織が持つビジネスケイパビリティは何かを考え、それらの周りにチームを編成するという方法もあります。これらのビジネスケイパビリティは長期的なものであり、必然的に技術者とビジネス側の担当者を同じチームにまとめることを意味します。

現在人気のある考え方は、アマゾンのツーピザチームです。「ツーピザチームで組織しましょう」とよく言われます。アメリカのピザは本当に大きいので、思ったよりも大きなチームにできるというジョークを少し交えながら。しかし、彼らがその説明をするとき、私がアマゾンの人々の話を聞くたびに明確になるあることをしばしば見逃します。それは、これらのチームのそれぞれが、顧客までつながっている必要があるということです。各チームは、顧客のエクスペリエンスのある側面、キャシー・シエラが顧客が自分の仕事でうまくいくようにすると呼ぶことのある側面に焦点を当てています。このことは、小さなチームが何をするのかという考え方を大きく変えます。なぜなら、もしその小さなチームが顧客のエクスペリエンスの一部、顧客が自分の仕事をより良く行う方法の一部に焦点を当てているのであれば、それは、小さなチームの間でどのように線を引くべきかを教えてくれるからです。これを実現するのは必ずしも簡単ではありませんが、私はそれが原動力となる概念であるべきだと思います。

しかし、またしても、私たちはそれが破られているのをよく目にします。私はある、アジャイルを標榜する組織に行きました。そこで開発チームと話をしたのですが、プログラマーは6人ほどいました。彼らが書いているソフトウェアのユーザーは、小売計画のシニアプランナー4人だけでした。6人の開発者、4人のユーザー。彼らは一度も話したことがありませんでした。話すことを許されていなかったのです。代わりに、彼らの間の会話を管理するスクラムプロダクトオーナーがいました。まあ、実際には、1年の間に4人のプロダクトオーナーがいたのです。私は、彼らが「アジャイル」という言葉を使うことができる、この悪夢のようなアジャイルの世界は何なのかと思いました。スノーバードでアジャイルソフトウェア開発の名前について話し合っていたとき、ケント・ベックは「会話的」という言葉を提案しました。なぜなら、ソフトウェア開発者、ビジネスパーソン、そして顧客体験をより良くすることに関わるすべての人々の間で、継続的な会話があるべきだからです。

もし私が開発者としてそのチームにいたら、すべてのユーザーとファーストネームで呼び合える関係になりたいと思うでしょう。話したいでしょう。彼らが何をしているかを見たい、顧客を幸せにする方法についての彼らの考え方を理解し、その流れ全体を見たいと思うでしょう。ですから、私たちはそのことを考える必要があります。それが私の3番目の課題です。

つまり、私が課題として向き合うべき3つのことは

• アジャイル産業複合体と、チームに押し付けるという考え方をなくすこと。チームが自分たちに合ったやり方を自分で見つけ出すようにすること。
• 技術的な卓越性を高めること。そして、ソフトウェアを書くとき、技術面が本当に重要であることを決して忘れないこと、そして
• 製品を中心に組織すること.

アジャイルの現状の問題について話してきたので、少しネガティブに聞こえるかもしれません。私がこの状況についてあまり悲観していない理由を1つ挙げるために、残り2分45秒です。それはおそらく、アジャイルマニフェスト全体の中で私のお気に入りのことの一つから来ています。これは私たちがそれを書いたスノーバードで起こったことではなく、約6ヶ月後、フロリダ州タンパで開催されたOOPSLAで、マニフェストを書いた人々のほとんどが、他の関心のある人々と一緒に集まったときに起こりました。この時点で、アジャイルマニフェストは、私たちが想像もできなかったような形で広まっていました。突然、興味深いことを行うための大きな機会があることが明らかになり、多くの人が「ここで本当の組織を立ち上げる必要がある」と言いました。

質問の一つは、「マニフェストを書いた元の17人が、この継続的な取り組みにおいて特別な地位を占めるべきか？」というものでした。私が誇りに思っていることは、私たち17人の著者が「ノー」と言ったことです。私たちはマニフェストを書きました。素晴らしい仕事をし、将来の活動の一部になるでしょうが、その将来において特別な役割はありません。その役割は成長していく必要があります。私たちは「新しい人々が来て素晴らしいことをするだろう」と言いました。そして、実際そうなりました。

それが重要だった方法の一つは、マニフェストを書いた人々、特に2018年の視点から見ると、大きな問題があったことです。17人：17人の白人、中年の男性。[3]そこには多様性の欠片もありませんでしたが、私たちが手放したからこそ、アジャイルの世界はあらゆる背景を持つ多くの人々を取り込み、参加することができました。メアリー・ポペンディックは、初期のアジャイルアライアンスの取り組みにおける偉大なリーダーの一人でした。私のThoughtworksでの上司であるレベッカ・パーソンズは、長年アジャイルアライアンスの議長を務めていました。私がアジャイル会議に行くと、他の種類のソフトウェア会議よりもはるかに多くの女性を見かける傾向があります。それは良いことです。確かに、それは私たち初期のメンバーの功績ではありませんでした。私たちはそれについてさえ考えていませんでした。しかし、重要なのは、私たちが手放したからこそ、自分たちで物事を開発できるコミュニティができたということです。私たちが想像もしていなかった課題に取り組み、それに取り組むことができるようになったのです。そして、それが私たちの最大の強みである、コミュニティとしての絶え間ない学習、成長、変化です。

つい先日、アジャイルの世界に遅れてきた人に話を聞いたところ、彼らは他の多くのグループにはない歓迎と開放感を感じたと言っていました。それが私を本当に幸せな気分にさせました。なぜなら、私たちが柔軟であり続け、常に変化できる限り、どんな課題に直面しても、私たちは未来があると思うからです。ありがとうございました。

---