エフェクチュエーションの観点から見るソフトウェア開発プロセス
はじめに
ここ何年かにSaaS事業の撤退をいくつか体験しました。
「頑張って作ったのに」「あの時、方向転換できてたら」
そんな後ろ向きな気持ちを抱えていました。根本的に考え方を改めなければならない、と考えていたところ、Shape Up という開発方法論とエフェクチュエーションという思想に触れ、これが私の身につけるべき考え方だと思いました。
本記事ではエフェクチュエーションの観点からソフトウェア開発プロセスを見直していきます。
私の失敗
私はプロダクト開発においてScrumを実践している、と思っていましたが実際には以下のようなしくじりをしていました。
- 事業性を確認する前にプロダクトや追加機能を作りはじめる
- 何を作るかを内側の人間だけで決める / 言われたものを作る
- 売れない理由を機能不足に求めて、半年～1年後までに追加する予定を立てる
- エンジニアが手待ちになることを恐れて、仕様の在庫を抱える
- 作り始めてから違和感を覚えても中止しない
振り返ってみると、これらはすべて「良い結果を得るためには良い計画が必要」「想定外なことがあっても計画は守るべき」という前提に立った行動と言えます。スタートアップでは何を作ったら良いか事前に分からないから経験から学ぶべきだと、知識としては持っていたはずなのに、実際には最初に計画を立て、それを遂行することにこだわっていたのです。
エフェクチュエーションとコーゼーション
"最初に計画を立て、それを遂行する"という思考法は「コーゼーション」（因果理論）と呼ばれるものです。これに対し、"手持ちのリソースから始め、進みながら構築する"という態度は「エフェクチュエーション」（実効理論）と呼ばれます。エフェクチュエーションとは成功した起業家が用いる実証済みのアプローチとされています。
エフェクチュエーションは予測が困難な状況で有効な思考法であり、予測可能な状況で用いられてきた従来の思考法とは大きく異なります。effectuation.org にエフェクチュエーションとコーゼーションを対比した説明があったので翻訳して引用します。
| コーゼーション | エフェクチュエーション | |
|---|---|---|
| 初手 | 詳細な事業計画を立てる | 既存のリソースから始める |
| 市場の発見 | 市場機会を調査する | 初期のパートナーと顧客を見つける |
| 投資 | 投資を調達する | 許容可能な損失に焦点を当てる |
| 目標 | 期待収益に注目する | フィードバックに基づき目標を適応させる |
エフェクチュエーションは行き当たりばったりのようにも見えますが、不確実性が高く将来を予測することが困難であることを認めるならば、合理的に行動していると言えます。エフェクチュエーション的な思考を持った起業家たちは、リスクを抑えながら可能性のある方向へ軌道修正しつつ学んだことを最大限に生かそうとします。
エフェクチュエーションの5つの原則
エフェクチュエーション思考のエッセンスは以下の5つの原則であるとされています。
- 手中の鳥の原則：ゴールから考えるのではなく、自分たちが持つ「手段」から何ができるか？を考える
- 許容可能な損失の原則：成果の最大化ではなく、失敗した時の損失が致命的になることを避ける
- クレイジーキルトの原則：協力者を巻き込み、彼らとの共創を目指す
- レモネードの原則：予期せぬ事態（良いことも悪いことも）を好機に変える
- パイロットの原則：トレンドを予測して適応するより、望む未来を主体的に創造していく
Scrumが誤用される理由
Scrum is founded on empiricism and lean thinking.
https://scrumguides.org/scrum-guide.html#scrum-definition
私の失敗は不確実性の中でコーゼーション的に行動したことであることを認めますが、これは Scrum が悪かったわけではありません。Scrum は経験と観察に基づいて意思決定し、無駄を省いて本質に焦点を当てるものとされています。これはコーゼーションではなくエフェクチュエーションに近い考え方と言えます。
それなのに、なぜ私は Scrum を誤用していたのでしょうか。2つの理由が考えられます。
- コーゼーション的な思考に基づく長期目標に縛られ、意思決定と適応の幅が狭かった
- Scrum のプラクティス、プロダクトバックログや振り返りなどを、不確実さに抗って計画を守ることとコーディングのスループットを高めるために用いる
問題は Scrum が「コーゼーション的な思考のままでも運用できてしまう」ことにあるかもしれません。
Scrum にはプロダクトのゴールを設定したり変更する具体的なやり方は書いていません。それはプロダクトオーナーやステークホルダーにゆだねられています。プロダクトオーナーやステークホルダーがコーゼーション的に意思決定することは防げません。
Scrum は、不確実性に適応する実践フレームワークである一方で、思考様式を矯正する仕組みまでは持っていないのです。
Shape Upとエフェクチュエーション
私が「Scrum をコーゼーション的に運用していた」と言語化できるまでには少し時間がかかりました。コーゼーションとエフェクチュエーションという二つの思考様式があることも知らなかったからです。初めはプロダクトバックログに疑問を持ち、別の方法を探していたところ Base Camp社が提唱する Shape Up という開発手法を見つけました。
Shape Up の詳しい説明は省略しますが、Scrum と比較すると以下の特徴があります。
- バックログを持たない
- 開発サイクルに入る前に解決したい課題やリスクなどをまとめた「ピッチ」と呼ばれるドキュメントを作成する
- ステークホルダーが要望のリストなどを持つことを許可するが、それらを在庫のように扱わない
- 見積もりはしない
- ピッチには投入できる時間リソース（Appetite）が書かれており、開発側はその範囲で可能かを判断する。
- サイクルの中でスコープを削ることも行われる
- 計画ではなく、賭け（ベッティング）を行い、失敗したら打ち切る（サーキット・ブレーカー）
- 毎回、次のサイクルで取り組む「ピッチ」を選択する。これは計画ではなく「ベッティング・テーブル」と呼ばれる。サイクルの中で開発が終わらないことは賭けが失敗したことを意味し、追加のリソース投下は打ち切られる
これらは、エフェクチュエーションの観点からみるとコーゼーション的思考を抑える仕掛けになっています。
- バックログが大きな計画の分解に陥ることを防ぎ、そのサイクル開始時点の最善策を実行する
- Appetite はエフェクチュエーションの「許容可能な損失」という原則と一致する。これにより一定のリスク範囲内でプロダクトを改善し続けることができる
- アイデアを実際に開発へ移すことは計画でなく「限度額の決まった賭け」であり、失敗することも織り込まれている
不確実性を積極的に活用するには
Shape Up の「Appetite」や「サーキット・ブレーカー」は、ソフトウェア開発の不確実性を抑える巧みな仕掛けであり、エフェクチュエーションの「許容可能な損失」という原則と一致します。しかしながら、不確実性とは常に歓迎されないものというわけではありません。思いがけないきっかけから想像を超える良い結果を生むことだってあるでしょう。
エフェクチュエーションでは、
- クレイジーキルトの原則：協力者を巻き込み、彼らとの共創を目指す
- レモネードの原則：予期せぬ事態（良いことも悪いことも）を好機に変える
の2つが「不確実性」を良い方向に活かす考え方です。これらを Shape Up に取り込むことでさらに不確実性に強い開発方法論とすることができるかもしれません。
AIを前提とするソフトウェア開発におけるエフェクチュエーションの重要性
今日のソフトウェア開発を考えるにあたって、AIの存在を無視することはできません。これには2つの意味があります。
- コーディングAIによりソフトウェア開発のコストがゼロに近づく
- LLMの持つ柔軟性・自律性により、社会の属人的な領域がソフトウェアシステム化されていく
これはソフトウェア開発が持つ不確実性をさらに高めるはずです。作り方が分かっているソフトウェアはあっという間に模倣されるため、誰も見たことのないものを作り続けることに価値を見出すしかないからです。同時に、社会そのものが予測不可能に変化していくため、既知のソフトウェアシステムはそもそも役に立たなくなるかもしれません。
また、ソフトウェア開発における不確実性とは、社会の変化の速さだけでなく、人間の能力の限界という側面もあります。仕様駆動開発が注目されていますが、かつて仕様が完全に書かれた試しはなく、出来上がったソフトウェアを触ってみてようやく本当の要求に気づくということがしばしばです。AIによって設計～コーディング～テスト～リリースの工程が極限まで高速化すると、ボトルネックは人間がそのソフトウェアを理解し、使いこなすスピードに移ります。
ですから、人間が受け入れられる大きさ・変化量にスコープを刻んで、繰り返し型で開発するというのが唯一の選択肢となるはずです。
おわりに
本記事では、私個人の失敗を題材に、エフェクチュエーションという思想的な観点から Scrum や Shape Up といったソフトウェア開発プロセスを見直してきました。
エフェクチュエーションの立場から見ると、私の失敗は特別なものではなく、
「不確実な状況にもかかわらず、コーゼーション的に振る舞おうとしたこと」
と簡潔に言い表すことができます。
Scrum は本来不確実性に対応するための優れたフレームワークですが、私たちが計画と予測への執着を手放さない限り、それは「短いサイクルで回るウォーターフォール」に陥ってしまいます。
Shape Up は、その点で非常に示唆に富んだ方法論です。計画につながるドキュメントを廃し、小さな失敗を織り込んだ意思決定をさせることで、コーゼーション的な制御をさせないよう設計されています。
今後、ソフトウェア開発の不確実性は、AIの登場によってさらに高まっていくでしょう。そのときに必要なのは、より精緻な計画ではなく、損失を限定しながら学習し続けるという思考様式と言えます。
エフェクチュエーションは、起業論としてだけでなく、これからのソフトウェア開発における世界観としても取り入れる価値のある思想だとお伝えしたいと思います。
Discussion