こんにちは！Recustomer株式会社でEMをしております、Tatsukiです。Recustomerではスクラム開発を導入しています。また1スプリントは1週間として、短いスプリントを回すことで日々プロダクトを磨いています。
私たちはスクラムの中に「デモ駆動開発」という考え方を導入し、日々のタスクについて優先度を考えています。本記事では私たちが取り組んでいる「デモ駆動開発」について、解説します。
デモ駆動開発を始めてからチームの開発生産性が向上し、デプロイ頻度が3回/日から5回/日に増えており、価値提供のスピードが向上した効果が得られました！
スクラムマスターやそれに近しい役割の方、または見積もりや作業の洗い出しに課題を感じているエンジニアの方にも参考になる部分があるかと思いますので、ぜひご覧ください！
1. 前提: エンジニアリングとは不確実性を減らす作業であること
突然ですが、エンジニアが日々行なっている「エンジニアリング」とはどのように定義することができるでしょうか？？書籍「エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング」では下記のように定義されています
「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答え
この「曖昧さ」は経済学の分野では「不確実性」と呼ばれていることから、エンジニアリングとは不確実性を効率的に減らしていくことが重要であると言えます。
また、スクラムはプロジェクトの成功を妨げるリスクや仕様の曖昧さの早期発見や、顧客からのフィードバックを短いスパンで受けることで、不確実性を減らすためのフレームワークの1つであることと言えます。
また、同書籍では不確実性が高いものから作業を行うことのメリットについても言及されています。主に「工数見積もりの正確性」「クオリティ」について言及されています。
工数見積もりと不確実性
工数見積もりの正確性について、プロジェクトマネジメントでは、不確実性に対する考え方として「不確実性コーン」があります。不確実性コーンとは下記画像のような縦軸にプロジェクトに対する見積もり工数の誤差範囲、横軸にプロジェクトの進行度を示したものになります。
引用: https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/
この図からわかることは、プロジェクトの初期段階では工数の見積もり誤差が最大±400%の誤差と大きく、意思決定の回数を重ね設計や開発のフェーズが進むことで誤差が収束していくことがわかります。このことから、初期段階で出る見積もりの信頼性は低く、それはプロジェクトが進み不確実性が削減されることで徐々に収束することがわかります。不確実性を効率的に削減することで、見積もり工数の精度も向上することが期待できます。
クオリティと不確実性
クオリティの面では、不確実性の高いものから着手することで全体像が早い段階で見えることから、リスクや早めに見えることでのリカバリー対応が早めにできることや、全体的な見積もり工数で早くこと出すことができます。
この着手する順序の違いがプロフェッショナルとアマチュアの仕事の違いだと言われています。
引用: 広木 大地. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング (p.54). 株式会社技術評論社. Kindle 版.
上記のことから、プロジェクトのキックオフやスプリントプランニングで「不確実性」が何か？「プロジェクトにおけるリスク」は何か？を事前に洗い出して認識を合わせることが重要であることが言えます。
2. 不確実性を事前に洗い出すことは意外と難しい
前節であったように、「不確実性」「リスク」を把握し、それを「開発者」と「マネージャー」感で認識を合わせることが重要になります。しかし、実際の現場では思うようにいかないケースが多いことを体験しました。
私自身が直面した課題について、2点上げさせていただきます。
開発者「実際に開発してみないとわかりません」
プロジェクトのキックオフやプランニング時には、開発者に「このプロジェクトのリスクって何になりますか？」「大体どれくらいの工数感でしょうか？」のような質問を投げかけます。これは前述しているプロジェクトの不確実性を理解し、リスクがあれば早めにリカバリーする体制を整えることで手戻りのリスクを早めに解消することを目的としていることがあります。
引用: https://tech-blog.tabelog.com/entry/project-quality-innovation-through-failure-analysis
そこでよく得られる回答が「開発してみないとわかりません」というものです。この回答は最初にはネガティブな印象を感じます。「それをなんとか見積もって欲しい...」と思うこともあります。しかし、これはアジャイルな文化だと、あり得る話であると私は考えます。詳細な要件を詰め切って開発に着手するウォーターフォールを採用しない都合上、開発者もマネージャーも不明な点があります。その不確実性を整理する効率的な方法は開発者にとっては「コードを書いてみること」だけという視点になってしまうことも十分に理解ができるものです。
その対策として「バッファを設ける」ことが挙げられますが、リスクや不確実性がわからない状態で、どれくらいバッファを設けたら良いかという疑問もエンジニアは儲けるバッファの量を各々の勘で答えてしまうのも想像できます。
マネージャーやステークホルダー「動いているものを見ないとわかりません」
実際に開発をしてみて、マネージャーやステークホルダーに機能を提供したところ、「ここはこのような機能が必要だった」「すみませんが、これも追加しないとリリースできない」「イメージと違う」とコメントをもらうことが多かったように感じます。
これはプロダクトマネジメント視点として、要件の洗い出しや顧客へのヒアリングが不足していることもありますが、「動いているものを見てみないとわからない」という視点もあるかと思います。動作しているものを見てから不確実性が判明するケースの場合、開発後期まで進んだタスクに対する手戻りの工数は非常に大きくなります。
顧客満足度の狩野モデルというものがあります。この図は横軸に「機能の充足度」、縦軸に「顧客満足度」があり、「必須の機能」「一元的品質(あればあるほど良い機能)」「魅力的な機能」のそれぞれの関係を示したものです。ステークホルダーが「どの機能」に対して「必須」と感じているのか、「一元的」と感じているのか、動作させてみないとわからないことも多くあります。
引用: https://qualitycube.jp/2024/10/09/kanomodel/
そのため、早く動いているものを見せる立ち回りは、動作させて見えてから不確実性を早期に発見し手戻りのリスクや、認識のずれによる双方の心理的な負担削減にも繋がります。
3. デモ駆動開発とは、「デモが早くできること」をタスクの優先度として捉える
ここまで、エンジニアリングとは不確実性を減らすことで、不確実性性が高いタスクを優先的に対応することでプロジェクトの見積もりと品質を高めることが可能になること、しかし、実際の現場では不確実性を洗い出すことは難しい背景をご説明しました。
Recustomerでは不確実性と適切に向き合い、プロジェクトを適切に進行させる方法として、「デモ稼働開発」を取り入れています。デモ稼働開発とは「プロジェクトのタスク優先度を決める要素として"デモが出来るかどうか？？"を考慮すること」としています。
この視点を取り入れることで、未完成でも良いから動くプロダクトを作成することを目指す視点になります。スプリントプランニングやスプリントゴール設定時の議論として「次ってデモできる？」「デモするためには何が必要になるだろう？」と言った動作するプロダクトを開発する視点を開発者の議論に追加することができるようになります。
この開発をすることで開発者は「ここは仮である(不確実である)」「ここは仕様が決まっていないので、把握する必要がある」ということが議論の中で洗い出されます。
更に動作するものが見えることから、フィードバックをもらえる機会を早めに作ることができます。その動作するものをデモとして「スプリントレビュー」で披露します。私たちはスプリントレビューではなく「デモ会」と呼ぶことでデモをすることを重要しています。
また、スプリントゴールについてもデモを意識したゴールを設定することで、1週間後のあるべき姿や具体的な機能の動作イメージなどをチームの共通認識として持たせることも可能になります。
4. デモ駆動開発を取り入れた効果
4-1. デプロイ頻度・リードタイムの向上
私たちはデプロイ頻度やプルリクエストのリードタイムなどを、Findy Team +を使って計測しています。
以前の弊社CTOの眞鍋の発表の中ではデプロイ頻度は3回/日だったということがありましたが、現在は5回/日まで向上しています。
これはインフラ的な改善もありましたが、デモ駆動開発を日々取り入れることで「動作するもの」「価値を提供するもの」を開発することを日々意識することで自然にデプロイが意識されデプロイ頻度向上にもつながったことと考えています。
また、リードタイムについても10時間以下を多くの時期でキープすることが実現できており、開発からリリースまでも短い時間で実現できています。
4-2. マネージャー・経営陣とのコミュニケーションの変化
マネージャー間や経営陣とのコミュニケーションで、プロジェクトの進行状況について聞かれた際、「(この開発者がこれくらいという風に見積もっていたので)恐らくXX週間後に完了します！」「これくらい完了見込みです！(勘でバッファ入れているけど)」のような不確実性を多く含む報告になってしまうことが多く、プロジェクト自体に大きな遅れを発生させてしまったこともありました。
直近ではデモ駆動開発を導入することで、不確実性が見え始め「現状だとここまで動作するものが作れているので、残りはXX日くらいあれば開発完了しそうです」「(この部分がまだデモできていないから、見積もりが出せないので)このタスクが完了してでもができたら、見積もりが出せると思うので、もう少しお待ちください」という根拠や状況説明・想定リスクを含めたコミュニケーションが可能になりました。
5. まとめ
本記事ではRecustomerが取り入れている「デモ駆動開発」についての紹介と、導入した効果について説明しました。エンジニアリングやプロジェクトマネジメントにおいて、不確実性とは常に向き合う必要がありますが、デモを意識する考えは不確実性と適切に向き合うための一つのフレームワークであると考えます。不確実性と仲良くなり、ぜひ良いエンジニアリングライフをお過ごしください！
Recustomerでは新しいメンバーを大大大募集しています！
今回の記事に関することや、Recustomerに興味を持っていただいた方はカジュアル面談でぜひお話ししましょう！
参考書籍
- エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- アジャイルな見積もりと計画づくり
- エッセンシャルスクラム
Discussion