本記事は、【第３回】ramble Advent Calendar 2023 1日目の記事です。
これは弊社で実際にあった話で、開発の責任者である 佐藤功樹 目線の成果の振り返りです。
この記事を見て引っかかったことがあれば、SNSなどでレビューしていただけると助かります。
スクラム開発 – エピソードゼロ –
とある日、全社的にインセンティブ設計の見直しが告知されました。
エクセルなどで物事を管理してもいいですが、さまざまな要件を叶えるために開発がスタートします。
👤「社内プロダクトの開発で、１ヶ月で開発して欲しくて….。」
🧑💼「なるほど、１ヶ月ですか？…どういうものが作りたいんですか？」
👤「とりあえず、要件はこれでお願いしたいんだよね」
🧑💼「うーん、まあアジャイルなら可能かなぁと…(速いって聞いたし)」
👤「あぁ、まあ何でもいいから“期日通り”に、ね。」
あなたはウォーターフォールでのみ開発経験がある、いちエンジニアです。
今回は、ユーザー *1 から納期が短いプロダクトの開発を依頼されました。
やりとりは口頭だったので、
「実装のアジリティを重視するなら、アジャイル開発だな」
と二つ返事で OK してしまいましたが、アジャイルなんてやったこともないし知見がありません。
さて、あなたならどうするでしょうか？
*1 ユーザー
アジャイルの文脈では、ユーザーとは顧客（クライアント）のことを指す。
ああ、失敗した！
さて、最初の要件の定義を行い、残された実装に使える時間は３週間程度です。
あなたが取れる選択肢は、２つあります。
① やり慣れている「ウォータフォール開発 *2」で WBS を作成して、開発速度を上げる。
② 全く知見がない、どうやら開発速度が速いらしい「アジャイル開発 *3」をやってみる。
悩ましいところですが、アジャイルでは細かな工数管理が発生して、管理が難しいと聞きます。
したがって、多くの人は心理的に安全性が高い①を選択することでしょう。
かくいう筆者も、やったことのあるウォーターフォール開発でプロジェクトを推し進めました。
しかし、開発に着手して１週間が経った頃には要件の変更、作業の手戻り、仕様書の作成タスク、単体テストの必要性…と最初に考慮していなかったものが発生し、開発が滞って行きます。
結局のところ、メンバーの助けもありプロジェクトは完了しました。
ただ、期日には間に合いませんでした。
あのとき、どうすればプロジェクトを成功へと導けたのでしょうか？
*2 ウォーターフォール開発
滝のように上から下へ、上流工程から下流工程へと順番に開発が進められていく開発手法。
*3 アジャイル開発
機敏に迅速にソフトウェアを提供できる反復増加型の開発。
反復期間ごとに現実に動作し役に立つソフトウェアを提供する。
どうしてこうなった？
あなたがしなければならないことは、より早くより多くのソフトウェアを作ることではない。
Jeff Patton – 「ユーザーストーリーマッピング」より引用
作ると決めたものから最大限の成果とインパクトを生み出すことだ。
ここでは、最初の段階で考慮できていなかったことを挙げましょう。
① アジャイルそのものへの理解不足
まず、アジャイル開発への理解が足りてなかったことが第一にあります。
最初の段階で、アジャイルについての調査を進めていればこうはならなかったはずです。
当時のアジャイルへの理解
- 実装が早いらしい。
- 仕様変更に強く、柔軟に対応できる。
- 仕様が固まらないため設計書とテストは後回しになる。
実際のアジャイルへの理解
- MVP *4 開発により、ユーザーが欲している最低限のアプリが素早く出来る。
- ユーザーとの連携で、チーム全体のストーリー *5 を共有、能動的に仕様確認と変更を行う。
- デザイン準拠にすることで、設計書を書く必要がなく、テストもモンキーテストのみで完了。
*4 MVP（ Minimum Viable Product ）
そのソフトウェアに持たせる、必要最小限の機能の実装手法。
*5 ストーリー
要件ではなく、チーム全体で一致している実装するための項目の理解。
② アジャイルの手法について
次に、アジャイル開発の手法について理解が出来ていなかったことが挙げられます。
今回のケースでは、スプリント開発のみ採用した場合の失敗する可能性まで深掘る必要がありました。
当時の実装手法についての理解
- スプリント *6 の期日さえあれば計画として機能する。
- したがって、WBS でもスプリント管理すれば対応可能。
実際の実装手法についての理解
- ストーリーに紐づいたタスクをバッグログ *7 で管理。
- 手戻りが発生した時点で WBS でのスプリント管理は破綻する。
*6 スプリント
開発期間をある一定の周期で細切れにした単位。
1〜2週間を基準に構築し、期間ごとに仕様設計や開発、リリースを行う。
*7 バッグログ
スプリントで実装する必要がある機能リスト。
スプリントバックログ、デイリーバックログなど一定の期間でステータスを変更する。
ウォーターフォールの性質について
最後に、思考停止でウォーターフォールで進めるということの重さを理解していませんでした。
消極的な決定ではなく、どちらも調査した上で開発の形態を選択する必要がありました。
これが出来ていれば、メンバーの体制への理解も深まり一体感が生まれ、ベロシティも出たはずです。
当時のウォーターフォールへの理解
- 仕様変更も別途チケットを切れば問題ない。
- 期日が短いため、品質やテストが完了しなくても説明が付く。
実際のウォーターフォールへの理解
- 期日が守れない = 取り戻せない遅れが発生した。
- アジャイルに比べ、連携が少ないために進めている段階で品質が上がらない。
今回の反省を活かして
左記のことがらに価値があることを認めながら、私たちは右記のことがらにより価値をおく。
Ward Cunningham – 「アジャイルマニフェスト」より抜粋
① プロセスやツール < 個人と対話
② 包括的なドキュメント < 動くソフトウェア
③ 契約交渉 < 顧客との対話
④ 計画に従う < 変化への対応
それでは記事の最後に、今回のケースでベストの動き方を考えます。
① アジャイル開発の意思決定の時点で、舵を切る。
② アイデアの枠組みを作り、ユーザーとイメージを描く。
③ MVP を定義して、リリースロードマップを切り出す。
④ ユーザーと連携しつつ、最低限の機能を素早く反復実装する。
このように動けば、チームの認識が一致して一枚岩となって実装を進められただろうと思います。
あとがき
最後に、筆者がアジャイルについて調べた結果、好きだった一節を紹介します。
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。
アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。
（中略）
「大きなことは大きなチームでするんじゃないの？」そんなことはない！
大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。
– Clean Agile 基本に立ち戻れ（アスキードワンゴ）
プロジェクトの進行を迅速に行いたい場合でも、アジャイル開発は銀の弾丸ではありません。
世の中には多種多様なケースが存在し、それぞれに最適なアプローチが異なります。
したがって、各プロジェクトの特性に応じて、最適な実装方法を慎重に選択することが肝要です。
参考
Clean Agile 基本に立ち戻れ – アスキードワンゴ
蛇足
よければ、【第３回】ramble Advent Calendar 2023 の他の記事も読んでみてください！ 👀