AI時代を乗り切る「無常アジャイル」な開発組織とは
こんにちは。
株式会社ラクスで楽楽精算開発部の部長を務めている吉田です。
私が尊敬している人物の一人に、ブッダがいます。
仏教の始祖というと宗教家のイメージが強いかもしれませんが、私の中でのブッダは、人間の苦しみを正面から見つめ、それとどう向き合うかを探求し続けた哲学者です。
今回は、そのブッダの教えのひとつ「諸行無常」と、アジャイル開発の思想を接続しながら、変化の激しいAI時代に開発組織がどう向き合うかを書いてみました。
AI時代の変化の中で日々奮闘しているエンジニアの皆様に、何かひとつでもヒントになれば幸いです。
変化を恐れず、無計画にも逃げないために
AI時代に入り、開発組織を取り巻く変化の速度は明らかに上がっています。
技術が変わる。
開発プロセスが変わる。
エンジニアの役割が変わる。
プロダクトの価値基準が変わる。
競合の動きが変わる。
顧客の期待値が変わる。
事業方針そのものが変わる。
AIは、開発組織に大きな生産性向上の可能性をもたらしますが、一方で開発組織への期待値も上げています。
もっと速く作れるのではないか。
もっと少人数でできるのではないか。
もっと柔軟に変えられるのではないか。
つまりAIは、生産性向上の道具であると同時に、変化への追従圧力を高める存在でもあります。
では、そのような時代に、開発組織はどう変化と向き合えばよいのでしょうか。
この記事では、東洋思想における「諸行無常」と、アジャイルの経験主義を接続しながら、AI時代のプロダクトエンジニアに必要な態度について考えてみます。
ただし、これは思想遊びではありません。
アジャイルは無計画ではない。
不確実性と未整理を混同せず、分かることは、分かるところまで明らかにする。
それでも残る不確実性に、小さく試して学ぶ。
そのような開発組織のあり方を、ここでは「無常アジャイル」と呼んでみたいと思います。
変化は、常態になった
変化そのものは、今に始まったものではありません。
ソフトウェア開発は、もともと変化と不確実性に満ちた営みです。顧客の要望は変わり、市場は変わり、競合は変わり、技術も変わります。
ただ、AI時代に入り、その変化の速度と範囲は一段上がりました。
以前であれば数年単位で起きていた技術的な変化が、数か月単位で起きる。昨日まで難しかったことが、今日にはツールで実現できるようになる。競合がAIを活用した機能を出すことで、顧客の期待値も変わる。開発組織の中でも、AIを前提にした生産性や判断速度が求められる。
変化は、例外ではなくなっています。
「今回はたまたま前提が変わった」
「このプロジェクトだけ不確実性が高い」
「落ち着いたら、また安定する」
そう考えたくなる気持ちはあります。
しかし、AI時代においては、変化し続けること自体が前提になりつつあります。
開発組織は、変化を一時的なノイズとして扱うのではなく、常態として扱う必要があります。
これは、何でも場当たり的に変えればよいという意味ではありません。むしろ逆です。
変化が常態になるからこそ、開発組織には、変化を観察し、解釈し、判断を更新する力が必要になります。
諸行無常──「見る」という態度
そこで私が引きたいのが、仏教の言葉「諸行無常」です。
馴染みはあるけれど、少し重たく感じる言葉かもしれません。「どうせ何も続かない」「変化するものに執着するな」という諦めの文脈で語られることが多い。
でも、本来の意味はもう少し違うところにあると思っています。諸行無常とは、「すべての現象は変化する」という、ただそれだけの事実の記述です。
儚さを嘆く言葉ではなく、現実をありのままに「見る」ための認識の枠組みです。
プロダクトの仕様を考えてみてください。仕様は、顧客の要望、市場の動向、技術の制約、組織のリソース、事業方針──そうした無数の条件が交差した結果として成り立っています。それらの条件のどれかが変われば、仕様が変わるのは当然のことです。
「仕様が変わった」ではなく、「仕様を成り立たせていた条件が変わった」と見る。
それだけで、受け取り方がずいぶん変わります。
変更は裏切りではなく、現実の更新です。固定した前提に立って見るから苦しくなる。事実として見れば、それは次の判断のための情報になります。
これが、諸行無常を「諦め」ではなく「態度」として使うということです。
経験主義──分からないことを、分かるようにしていく
「見る」の次は、「試して学ぶ」です。
現実をありのままに見るということは、同時に「自分たちが分かっていないこと」を認識することでもあります。
やってみないと分からない。出してみないと分からない。ユーザーに届けてみないと分からない。
ソフトウェア開発には、構造的にそういう不確実性があります。これは能力の問題ではありません。作る前には分からないことがある、というソフトウェアの性質です。
だとすれば、取るべき態度は一つです。
分からないことを、小さく試して明らかにしていく。
大きな賭けをしないために、分かることは先に明らかにする。分からないことは、できるだけ小さい単位で触れてみる。そこで得た情報をもとに、次の判断をアップデートする。
これは、無常観の実務への接続です。変化する現実を正しく見て、その現実に小さく触れながら認識を更新し続ける。無常という現実認識と、エンジニアが現場で行っている仮説検証は、実はそう遠くないところでつながっているのかもしれません。
これはアジャイルそのものだ
経験主義。反復。フィードバックループ。仮説と検証。
こう並べると、これはアジャイルの核心とも重なります。
アジャイルとは、ざっくり言えば「分からないことを前提に、小さく作って学びながら進む」開発の進め方です。2001年に米国で17名のソフトウェア開発者たちが「アジャイルソフトウェア開発宣言」にまとめたこの考え方は、いまや世界中の開発組織に広がっています。
ただ、「アジャイル」という言葉には、誤解もつきまといます。
アジャイルは無計画ではない。
「とりあえず動くものを作ってから考える」「計画は不要、変化に対応すればいい」──これはアジャイルではなく、不確実性と未整理を混同した状態です。
分かることは、分かるところまで明らかにする。決めることは、決める。それでも残る霧の部分に、小さく踏み込んで学ぶ。
アジャイルは、変化を言い訳にする思想ではなく、変化を正しく扱うための実務の作法です。
アジャイルを、東洋的な無常観から捉え直してみる
少し立ち止まって、考えてみたいことがあります。
現在の意味での「アジャイル」は、2001年に米国でまとめられた「アジャイルソフトウェア開発宣言」をきっかけに、世界中の開発組織へ広がっていきました。
カタカナで「アジャイル」と書くと、どこか輸入品のような感覚があります。
でも、そのルーツを辿ると、少し違う景色も見えてきます。
アジャイルの源流の一つであるスクラムは、日本の製造現場における新製品開発のあり方から影響を受けています。また、カンバンやリーンがトヨタ生産方式と深く関係していることも、よく知られています。
つまり、アジャイルは単なる輸入品としてだけ見る必要はありません。日本の現場から生まれた知恵が、別の場所で体系化され、ソフトウェア開発の文脈に乗って戻ってきた側面もあります。
そして、その核にある態度──「変化を前提とし、不確実性を認めながら小さく動いて学ぶ」──は、現場感覚に親しんできた私たちにとっても、そんなに遠い感覚ではないはずです。
「諸行無常」は、仏教が伝わって以来、日本の文化や美意識に深く根を張ってきた感覚だと感じます。桜は散るから美しい。潮は満ちては引く。永遠に続くものなどない。
変化するものを変化するものとして見る。条件が変わればあり方も変わる。それを諦めではなく、現実への誠実さとして受け取る。
そういう感性は、私たちの中にもともとあるのではないでしょうか。
アジャイルを「外から来た難しいもの」として扱うより、「自分たちの中にもあった態度を、開発の実務に落とし込んだもの」として捉え直してみると、少し腑に落ちる感覚があるかもしれません。
おわりに
変化に疲れるのは、正しい感覚です。ただ、その疲れの多くは、変化そのものから来るのではなく、「変わらないはずだ」という前提を手放せないことから来ているかもしれません。
諸行無常は、諦めではなく、現実を正しく見るための態度です。そして経験主義は、その見えた現実に、誠実に小さく向き合っていくための実務の作法です。
それは、アジャイルの根底にある考え方とも重なっており、日本の文化に慣れ親しんできた私たちにとっても、どこか馴染みのある開発の哲学なのだと思います。
変化の一段と激しい時代ですが、その変化を現実として扱いながら一緒に考え続けられる人と働きたいと思っています。
この記事に共感いただけた方は、ぜひ声をかけてください！
カジュアル面談はこちらから
