この記事は株式会社カオナビ Advent Calendar 2024の2日目の記事です。
「アジャイル」といえば「スクラム」
筆者はアジャイル開発といえば、「スクラムフレームワーク」という安易な気持ちでチーム開発を行っていたプロジェクトリードである。
プランニング・レトロスペクティブ・スプリントレビューなどのイベントを１週間単位にイテレーションを行ってきた。
しかし、開発はうまく進まずチームが腐り始めてしまう状態へ進んでいった。
なぜ腐り始めたのか
腐敗が始まった原因を振り返った結果、大きく1つのポイントが明らかになった。
それは「課題解決」を中心に考えることができていなかったことだ。
課題解決を中心に考えられなかったこと
本来、プロダクトは顧客が潜在的に抱えている業務課題や煩わしさを解決するための手段として提供するものである。
私たち開発チームは、顧客はなぜそれを課題と認識しているのか。
またどのような方法で突破することによって、顧客の望む未来を買えるのか。
という観点を常に追い続けることが大切だと考えている。
しかし今回はそれに失敗し、挫折をしてしまった。
どうしてそうなったのか
これは明快であり、目的もなく安易な気持ちでスクラムフレームワークを選択したことによる影響である。
高いベロシティをコンスタントに発揮し、高速でイテレーションを回せるチームを目指した。
一見悪いことではないように感じるが、以下の観点にとらわれることで意味が変わってくる。
私はそれに「執着」してしまった。
執着した結果
スクラムを成立させることに執着した結果、顧客の潜在的に抱える痛みに目も向けることに集中できていない状態が蔓延することになった。
ここにチームで集中しなかったことで、作るべきものが明らかにならない時間がとても長くなってしまった。
作るべきものが明らかにならない
ここが一番のポイントだった。
作るべきものを明らかにするプロセスに対して投資しなかったことで、プロダクトバックログに達成可能なチケットを作れなくなっていった。
完了の定義があやふやなチケットに対して、ストーリーポイントを振り出したとしても、何の見通しも立たないし、意味を持っていない。
そんなチケットは作っても無意味なのだが、私はそこに疑問を持たなかった。
なぜならスクラムフレームワークに執着していたことで、とにかく数字を出すことだけにこだわってしまったからだ。
それに気づいたとき、私たちはスクラムをやめた。
アジャイルの手法を見直す
スクラム以外にフレームワークがあることを見失っていたので、まずそこから改めることを始めた。
| フレームワーク名 | 特色 | 私の憧れ度 |
|---|---|---|
| カンバン | カンバンの要諦は、仕事の流れやタスクを可視化し、進行中の作業量をコントロール・マネジメントすることで、効率的かつ継続的なプロジェクト進行を可能にする | 🤨 |
| エクストリーム・プログラミング（XP) | 高品質なソフトウェアを迅速に提供することを目的とする手法です。XPは、従来のソフトウェア工学の手法を「極端」（エクストリーム）なレベルまで推し進める | 🤩 |
| クリスタル | チームのコミュニケーションと相互作用を最大化し、プロジェクトの透明性を高めること | 🧐 |
| 動的システム開発手法 (DSDM) | 時間とリソースを固定し、機能を調整可能にする「タイムボックス」の概念を重視します。これにより、期限とコストを守りつつ、最も価値のある機能を優先的に提供 | 🧐 |
| 機能駆動開発手法 (FDD) | アジャイルソフトウェア開発の一つで、顧客にとって価値のある機能（フィーチャー）を中心に据えた手法 | 🧐 |
| 適応型ソフトウェア開発（ASD） | 複雑で不確実な環境下でのソフトウェア開発に適した手法 | 🧐 |
正直こうやって比較してみてもよくわからないな...。というのが個人的な感想ではあった。
さらに憧れのフレームワークもあるが、それを選んでしまってはまたフレームワークに執着しそうなので撤退。
現状に最も近いのはバックログチケットすら作ることができていない現状があるほど、複雑で不確実な環境にいるので、直感的に 適応型ソフトウェア開発を選んでみよう。という気持ちで選択した。
しかしこれがハマった。
適応型ソフトウェア開発
このフレームワークについての取り組みをこの記事だけに詰め込むのは、とんでもない物量になってしまうので今回は要約に留める。
アドベントカレンダーという良い機会もあり、別でまとめる挑戦をしているので、もし興味があれば追って見てもらえるととても嬉しい。
適応型ソフトウェア開発の要約
以下参考資料から引用
変化を前提として、それに適応することを重視する。計画よりも適応を重視している。
開発サイクルは「思案」「協調」「学習」の3つのフェーズで構成され、このサイクルを繰り返すことに特徴がある。
失敗を学習の機会と捉え、リスクをおそれずに挑戦することを奨励する手法だ。
この手法はチームの自律性はもちろん、創造性も促進し、急速に変化する環境に柔軟に対応することも可能にする。
私たちが救われたのは「思案」・「協調」・「学習」という枠組みを得られたことが特に大きかった。
適応型ソフトウェア開発を学んだ結果得たもの
この学習を経て得たものは大きく３つあった。
タスクが終わるようになった
完了が難しかったタスクのゴールをそれぞれ、「思案し協調できる状態にする」・「学習し思案できる状態にする」・「協調してタスクを終える」という文脈に落とし込むことができるようになった。
このタスクは、ここまで考えられるように勉強しよう。
ここは、勉強した結果を使って、方向性を考えよう。
方向性に沿って、協力してみよう。
と言った段階を経て、プロジェクト進行を進めていくことが可能になった。
この1つづつのプロセスに重みづけをしながら進めることで、見通しも明るくなっていった。
破壊することに躊躇しなくなった
いつでも変化・適応することを前提にしているため、破壊活動が当たり前になった。
そして失敗することも当たり前になった。
その結果、より適切な未来に向けてピボットを繰り返すことができるようになった。
作るものを決めるために、雑に作り、そしてそれを破壊し、前に進む適応スタイルがチームのカラーになっていった。
スクラム以外を行っている社内でも数少ないチームになった
スクラムを用いたアジャイル体験を知っているチームとなり、他のチームに適応型ソフトウェア開発のエッセンスの一部を共有し、他のチームの活動にもひっそりと貢献できるようになっていた。
スクラムを使っているがなかなかうまくいかないんだよね...。という相談をそっと支えていくことができたのも、この活動を通して得られた体験かもしれない。
まとめ
適応型ソフトウェア開発は原初のアジャイルフレームワークに位置している。
これをベースに考えていった時、スクラムや他のフレームワークの意図していることや使い方・有効な盤面を意識してそれを行使できるような気持ちを作ることができた。
なによりもアジャイルフレームワークはただの道具であるという事実に気づくことができた。
そして、人と同じことをやらないことで、得た知見やより失敗を積み重ねた泥臭い日々を送ったことで自分自身新しい視座を見つけることができた。
思考停止せず、常に新しいことを始めるのはいつも新鮮で健康なことなんだと学ぶことができた。
もし１つのフレームワークの進行状態が悪く、行き詰まっていたり、停滞を感じているチームがいたら、他のアジャイルフレームワークに乗り換えてみることも１つの手立てなのではないだろうか。
参考資料