ちょっと前にこちらの記事が話題になっていました。
非常に興味深い記事で、読書感想文的な位置づけで自分でも下記の本を読んでみました。まあ、まだギリギリ夏休みなんで。
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 作者: 市谷聡啓
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2019/06/14
- メディア: 単行本
- この商品を含むブログを見る
その思ったことのメモです。
tl; dr;
- なぜプロダクトづくりはうまくいかないのか
- 原因はさまざまあるが、発注者・受注者双方の頭の中に"完成形"のイメージがないことが大きい
- 不確実性の高いプロジェクトに対して、アジャイルは銀の弾丸ではない
- アジャイルでやっても失敗するときは失敗する
- 仮説検証型アジャイルとは？
- 正しいものを見極める
- 仮設キャンバスやユーザーストーリーマップを駆使してMVPを特定する
- 正しく作る
- アジャイル開発によって、不確実性に対応しながらMVPを検証する
- 正しいものを見極める
プロダクト開発が失敗する理由
システム開発において、プロジェクトが失敗する理由は「不確実性」です。 不確実性は、作るものに関する不確実性と作り手に関する不確実性の二種類に大きく分けられます。
作るものの不確実性
20年前と現在では、IT業界で作ろうとしているものは大きく変わっていると思います。 みんなが同じシステムを導入できればよかった、完成形が業界で共通認識として存在していたそうです。
それが、より複雑なものが求められている一方、発注者側ですら完成形を明確に定義できません。 技術要素も日進月歩で、表面上は同じ機能のものを作る場合でも、中の実装をモダナイゼーションしようとすると20年前と現在では作り方は大きく変わり、より多くの選択肢が考えられると思います。
作り手の不確実性
作り手側の状況についても、これまでに比べ不確実性が大きく増えました プロダクトの品質水準が上がってきていることに起因して、各役割で求められることがより専門的になってきています。 最近では、システムの信頼性向上のためのSREなんて役割があるくらい、役割は複雑化・専門化しています。
また、ITの業界では特にそうですが、働き方やその他多様性が重視される世の中になってきており、 それに伴って、従来の会社に来て、みんなでものを作るという、固定されたプロジェクトの進め方ができなくなっていることも、不確実性を高める要因になっています。
不確実性の源泉
プロダクトは作るものもはっきりしないし、作り手側も多様化してカオスな感じになっています。 これでは、プロダクトを作ってみてから不確実だったものが徐々にはっきりしてきます。 それは、期待だったりリスクだったりするわけですが、いずれにせよどこかのタイミングで顕在化した不確実性に対処する必要性が出てきます。
さて、この辺りで「不確実性」について見方を変えてみます。 システム開発のプロジェクトにおける不確実性には、大きく3種類になるかと思います。
- 方向性の不確実性
- 規模の不確実性
- 作業効率の不確実性
インセプションデッキを使用して、向かうべき方向については絶えず確認していきます。 スコープに幅と深さのバッファをもたせることで、ゴールに辿り着くための余裕を持って進めることである程度対応できます。 自分たちの歩く速度についても、確認をすることで現実的な速度を把握でき、対策を打ちやすくなります。
アジャイル開発は銀の弾丸ではない
ITの現場の人はわかると思いますが、アジャイルは全然完璧ではありません。 アジャイル開発でプロジェクトを進めていたとしても、失敗は起こります。
開発者目線でみると、ウォーターフォールよりアジャイルのほうが遥かに複雑で難しいと思います。 アジャイル開発は、顧客にとってより価値のあるプロダクトを提供することを優先する開発手法であって、アジャイルでやれば成功が保証される銀の弾丸ではありません。
アジャイル開発自体については、過去いくつか記事を書いているので、そちらもご参照ください。
仮説検証型アジャイル開発
なんとなくすごそうな図が乗っていたので、一部直して拝借するとこんな感じらしいです。
完成形のイメージが、ステークホルダーの中で固まりきらないなら、仮説検証によって固めればいい。 その仮説検証に基づいて、プロダクトのあるべき姿を再定義して、そこからアジャイル開発で作っていく。 そして、新たな領域に差し掛かったらまた仮説検証から考える…という、流れで進めると確かに「正しいもの」を「正しく作る」ことが できそうです。
ざっくり言いなおすと、価値探索とアジャイル開発をセットでものづくりを繰り返すってことになるでしょうか。
開発だけ見ればアジャイル開発ですが、価値探索によるMVPの特定とうまく連携させることで、通常のアジャイル開発で発生しうる問題を回避できるんでしょうね。
正しいものを見極める
これは非常に面白いですね。 はじめは「概念実証(PoC)に近いのかな？」と思ったんですが、結構違いました。
ちゃんと書くとこんな感じになるようです。
- 課題仮説／ソリューション仮説／インターフェース仮説の立案
- 仮説キャンバスを作成
- 2.の検証(インタビューなどで静的モデルの検証)
- 3.をもとに、ユーザーストーリーマップを作成
- 4.の検証(プロトタイプなどを用いて動的モデルの検証)
それぞれを複数回繰り返し、仮説の確度を上げることで不確実性を小さくすることでMVPを特定し、「間違ったものを正しく開発しない」ようにしていきます。
正しく作る
上のプロセスでMVPを特定してから、その方向に沿ってアジャイル開発らしくものをものを作っていく感じですね。
スクラムを始めとして、アジャイル開発は「言うは易く行うは難し」が付き物です。 この辺は経験者の胸を借りながら進めるのが良いんだろうなとか思ってます。 いずれにしろ、広い目で見ればここはアジャイル開発で開発することで開発開始時に残存する不確実性に対応していきます。
その他、「作るという側面」でアジャイル開発のポイントについては、本をご参照ください。 著者の経験を踏まえた、コツがたくさん詰まっていて非常に勉強になります。
感想
この本自体は、結構ボリュームが有るのと、開発の経験をたくさんしていないと実感がわかない部分も多いと思います。 そういう意味では、時間が立ってから改めて読み直したい本でした。
ITの世界にいるうちは、不確実な要件定義とずっと付きあっていかないといけないんだろうなあ、、、とか思っちゃいますね。 特に最近はお客さんの成果物に対する正しい理解を得てもらうのに苦労してたりしてなかったり。 こういう部分については、経験が物を言うところが大きいので、我慢するしかないんでしょうね。 要求水準がどんどん上がっているのを、モロに感じます。
