こんにちは、Repro Boosterの開発責任者・プロダクトマネージャーの Edward Fox です。全国的に長く続いた酷暑も少し落ち着きを見せ始め、朝晩は涼しく感じるようになってきましたね。
はじめに
2021年からプロトタイプ開発を始めたRepro Boosterですが、2022年の8月頃に正式なプロジェクト・チーム化しました。開発チームにはRepro社歴が長いメンバーも多く、チームが組成されてからこれまで大きな入れ替わりもなく開発を行ってきたのもあり、非常に安定した組織運営ができていると感じています。
これ自体は素晴らしいことであり、チームの成熟度が高い証でもあります。しかしながら、新規事業の本分は「非線形的な成長」であり、安定の先にある未来の解像度が高く持ててしまっている点に、得も言われぬ不安を感じるようになったタイミングがありました。プロダクト・事業の成長に「天井」が見え始めているのではないか、というような焦燥感です。Repro Boosterは正式リリース以来、多くのお客様に導入いただいており、特に事業が伸び悩んでいるわけではありません。が、冷徹に全体を俯瞰したときに、「この事業単体でユニコーンを目指せるのか？」「世界をリードするプロダクトに足り得るのか？」という問いを立てたときに、まだまだ伸び代は大きいと感じた次第です。
こういった葛藤や苦悩を通して得た「アジャイル開発と不確実性やリスク」に対する私の直観について、この記事で言語化を試みました。アジャイル開発がもたらす「安定」の先に待っている罠と、事業を非連続的に成長させるために、私たちが再び向き合うべき「不確実性」や「リスク」について整理してみたいと思います。
アジャイル開発と不確実性
Reproでは過去に LeSS（Large-Scale Scrum）というフレームワークを採用し、開発フローを回していました。私のスクラムの原体験であり、この時期の活動や試行錯誤がベースになって今の自分の考え方が形作られています。
アジャイルやスクラムについて学習し実践する中で、私はアジャイルの原典とも言える『アジャイルソフトウェア開発宣言』を節目節目で参照するようになりました。シンプルがゆえに深遠で、自身の状況が変わったり経験値が増えるとそれまでとは違った解釈を与えてくれる、非常に示唆に富んだ文章です。下記に全文を引用します。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、 Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、 Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、 Jeff Sutherland、Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
ここに書かれた4つの価値（「プロセスやツールよりも個人と対話」など）の根底に流れているのは、ソフトウェア開発というが本質的に「不確実性の高い活動である」という認識です。顧客が本当に欲しているものは何なのか、この技術で何が実現できるのか、市場環境はどう変わるのか。すべての事柄に確証を持つことができないからこそ、私たちは重厚長大な計画やドキュメントに頼るのではなく、短いサイクルで動くソフトウェアを作り、顧客と対話し、変化に柔軟に対応することで、不確実性の波を乗りこなそうとします。
スクラムにおけるスプリント、デイリースクラム、レトロスペクティブといったプラクティスも、すべてはこの「不確実性をコントロールする」という目的のために設計されています（と私は解釈しています）。アジャイル開発とは、いわば不確実性との戦いにおける知見の集積であり、いかに不確実性を低減させ未来の見通しを良くするかが、多くの現場での成功指標となっているように感じています。
予測可能性 a.k.a. 予定調和？
不確実性を低減させ安定した開発サイクルの礎を作ることは、言わずもがな非常に重要です。継続的な改善サイクルこそが、ユーザーに価値を届け続け、ビジネスの基盤を支える「守りのアジリティ」とも言えるでしょう。チームの発達段階を示す「タックマンモデル」でいうところの「機能期」、つまり最も生産性が高い状態であり、あらゆるチームがまず目指すべき姿です。
一方で、この「守り」の活動が目的化してしまうと、新しいアイデアや非連続的なイノベーション、すなわち「攻めのアジリティ」が生まれにくくなる、という結果にも陥りかねません。
Repro Boosterのプロダクト開発は多くの機能開発やクライアントと協同して行うPoC（Proof Of Concept）を通して経験を積み、チームが持つドメイン知識も豊富になりました。しかし、練度の高さが、いつしか新たな挑戦や「不確実なものに取り組むチャレンジ」を阻む障壁にもなっていた側面もあったと感じます。
ブレインストーミングの中で突飛なアイデアが出ても、議論を通して「これは実装しなくてもある程度結果が分かる」「こういうリスクがあるからやめておこう」と、高い解像度ゆえに結論が早期に見えてしまうのです。予測可能性の高さは無用なリソース投資を減らす効果がある一方で、「うまくいくか分からないけどやってみよう」という挑戦の芽を無意識に摘んでいました。中長期的な製品戦略について思いを巡らせるタイミングでは「攻め」の大きな革新を求めながらも、日常的には「守り」の確実性を優先してしまう。そんな状況に遭遇することがありました。
この状況は、クレイトン・クリステンセンが「イノベーションのジレンマ」で指摘した、大企業が陥る構造と非常によく似ていると思います。利益率の高い既存事業の改善と効率化（≒ 不確実性の低減）を追求するあまり、市場を破壊するような新しい変化の波に乗り遅れてしまう、という構図です。私たちのチームが感じていた停滞感は、まさにこのジレンマの縮小版だったのかもしれません。
リスクは成長の燃料
こうした経験を繰り返すうちに、「リスク」という言葉を捉え直すことで突破口が見つかるかもしれない、と考えるようになりました。
一般的に「リスク」という言葉を使うと、「危険」「懸念」といったネガティブなニュアンスで捉えられがちです。しかし、事業活動の文脈においては、リスクはリターンと表裏一体の存在です（投資や金融の世界でもリスクは「危険」とは異なるニュアンスで用いられます）。むしろ、「不確実性が低い状態」とは、裏を返せば「取るべきリスクが取れていない機会損失の状態」だと言い換えることができます。
心理学の世界には「リスク・ホメオスタシス」という考え方があるそうです。これは、人間は無意識に自分自身が許容できる一定のリスク水準を保とうとする、という心理的な傾向およびその理論です。
例えば、車のABS（アンチロック・ブレーキ・システム）のような安全装置が搭載されても、結果的に事故率はあまり下がらなかった、という研究があるそうです。ブレーキの性能が上がって安全になった分だけ、ドライバーは無意識に車間距離を詰めたり、スピードを上げたりして、結果的にリスクの総量を元に戻してしまうからだと説明されています。本筋から外れるため、この理論の信憑性については問わないこととしますが、感覚的には納得できるところが大きいです。健康診断のあとに揚げ物やジャンクフードが食べたくなる心理と似ている気がしますね（たぶん違う）。
プロセスを改善・仕組み化し、足元の安全（不確実性の低減）が確保されたのであれば、私たちはより挑戦的な行動（事業的なリスクテイク）を取って、リスクのバランスを取るべきなのです。しかし、「安定」を至上命題とするメンタルモデルでは、この健全なリスクテイクが抑制されてしまいます。
熊とワルツを
ソフトウェア開発におけるリスク管理の名著、トム・デマルコの『熊とワルツを』には、こんな一節があります。
リスクから逃げ、うまくやれるとわかっていることだけをやろうとする企業は、敵に陣地を明け渡すようなものだ
リスク管理はおとなのプロジェクト管理だ
ここでの「リスク管理」とは、リスクをゼロにすることを意味しません。むしろ、取るべきリスクと避けるべきリスクを見極め、コントロールしながら、積極的にリターンを狙いにいくことこそが本質だとデマルコは説いています。アジャイルとは単なる開発手法ではなく、事業活動の「あり方」そのものです。そうであるならば、私たちはリスクを避けるのではなく、もっとうまく戦略的に付き合ってソフトウェア開発を営むべきなのです。
あなたのチームは不確実性を「歓迎」できますか？
あらためて、アジャイルにおける不確実性の低減の意義を自分なりに咀嚼すると、「適切な目的とタイミングでリスクを取り、大きなリターンを得るための下ごしらえ」だと私は捉えています。足腰を鍛えるのは、より高い山に速く登るためであり、そのための準備自体が目的化してはいけません。
「アジャイルソフトウェア開発宣言」を補足する文書として書かれたアジャイル宣言の背後にある原則 には次のような一節があります。
要求の変更はたとえ開発の後期であっても歓迎します。
この一文を読むと、背筋が伸ばされる思いがします。一般的には開発後期の要件の変更はご法度で、歓迎というニュアンスからは程遠い現場が多いのではないでしょうか。
これは、単に差し込みタスクに寛容であれ、という意味ではありません。顧客の要求や市場環境の変化を「歓迎」できるほどの強いチーム（安定した基盤と高い対応力）だけが、変化の中に潜む大きなチャンスを掴み、自らリスクを取って大きなリターンを狙いにいける、ということを示唆しているのだと私は解釈しています。
みなさんのチームは要件の変更であったり市場環境の変化といった不確実性を「歓迎」できているでしょうか。あるいは、チームの議論において、「どうすればもっと効率的にできるか」という議題だけでなく、「全く新しい価値をどう創出するか」という未来志向の議論に時間を使えているでしょうか。
闇雲にリスクを取ればいいというわけではありません。私達のチームでも、例えば「このスプリントは、直接的な事業KPIに結びつかない技術的な『探索』に時間を使う」「あえて『もし〇〇という制約がなかったら？』という非現実的な問いからブレストを始める」といった小さな実験から始めています。大切なのは、チームの中に意図的に「予定不調和」の時間を組み込むことかもしれません。
まとめ
本記事では、アジャイル開発がもたらす安定が、時として成長を阻む罠になり得ること、そしてその先へ進むためには、リスクというものを捉え直し、果敢にコントロールしていく必要があることをお話ししました。
アジャイル開発で得られる安定は、ゴールではありません。それは、次の大きな挑戦を可能にするための、強固な基盤です。不確実性を下げる努力は、そこに安住するためではなく、より大きなリスクを取り、非連続的な成長を遂げるための準備に他なりません。
あなたのチームは、不確実性を下げることに満足してはいないでしょうか。この記事が、チームにおけるソフトウェア開発のあり方や方向性を見つめ直すための一助となれば幸いです。
WE ARE HIRING!
最後に、Repro Boosterでは開発者を採用しています。Webパフォーマンスに関心がある方、あるいは「タグを入れる」だけでWebパフォーマンスを改善するRepro Boosterの技術に興味を持っていただけた方は、ぜひ気軽にご連絡ください。
