この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。
はじめに: 人と成りては童子のことを棄てたり
インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。
プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。
それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通されてしまう意思決定の問題でもあります)
プロダクト開発においては、死屍累々のプロジェクトから得られた直観に反する知見が数多くあります。こうした知見を体得している人と、そうでない人が議論しても、そもそもの前提が噛み合わないため非建設的な議論になりがちです。
そうした不幸を1つでも減らすべく、この記事ではプロダクト開発の重要な要素である「デザイン思考」「アジャイル開発」「DevOps」を題材に、非直感的な知見を紹介していきます。
デザイン思考: 顧客は自分が本当に欲しいものを知らない
直観は: 顧客の要望通りに開発すればよい しかし: 顧客は自分が本当に欲しいものを知らない だから: 顧客を深く理解し、真の課題と解決策を探索する
顧客からの要望が来ているのであれば、その通りに開発すればよい。そんなふうに考えていた時期が俺にもありました。
しかし、顧客は自分が「本当に欲しいもの」を知りません。家を建てるとなれば「広いリビングが欲しい」「アイランドキッチンだけはゆずれない」など要望は多く出てきますが、実際に住むと「リビングはいいから書斎が欲しい」「動線の邪魔」など不満が出てきます。「家は3回建てないと理想の家にならない」ともよく言われます。
ではどうしたらいいのか。顧客の直接的な要望ではなく、顧客の行動から真の課題と解決策を探索する、いわゆるデザイン思考的なアプローチが必要になります。ここに関しては、下記の羽山さんのスライドがまとまっています。
また、デザイン思考（デザインシステム）については12月20日にデザイナーの林さんのブログで言及しています。 ご参考ください。
アジャイル開発: 不確実性が高く、見積り通りにはいかない
直観は: 全ての要件を確定して見積り、その通りに開発すればよい しかし: 不確実性が高く、見積り通りにはいかない だから: 小さな単位の開発を繰り返す
「タスクを分解して、それぞれを見積もる。それを積み上げれば計画ができる。簡単な話だ。あとは粛々とやるだけだし、計画から遅れるのはサボっているからで、どやしつけて徹夜で挽回させれば納期なんて守れるだろう。」 テイラーの科学的管理法から連綿と続くマネジメント方法です。実際有用な方法ではあるのですが、対象は定型業務に限られます。
定型業務の場合、かかる時間は正規分布で、タスクは独立に進みます。一方でプロダクト開発の場合、かかる時間は冪乗分布で、タスクは依存しています。おまえは何を言っているんだ。
簡単に言えば、見積りからずれるとしても、定型業務であれば2倍ずれるのは稀ですが、プロダクト開発は平気で10倍ずれることがあります。またタスクに依存関係があり、1つのタスクの遅れが波及して全体としても遅れていきます。要は不確実性が高いのです。
プロダクト開発でやっていることは製造ではなく設計です。プロダクト開発を工場生産のアナロジーで捉えてしまうと、定型業務のようにマネジメントする発想になってしまいますが、実際にはそうではありません。
プロダクト開発における製造段階は、プログラムをコンピュータが実行している部分です。人がしているのは設計段階であり、それは例えて言えば数学の難問を解くことに似て時間をかければ必ずできるといったものではなく、不確実性が高いのです。
そうした理由の詳細はともかく、不確実性が高いのであれば、どう計画を立てればいいのでしょうか。細かくステップを繰り返し、常に計画を更新し続けるアジャイル開発のアプローチが必要になります。 前述のように不確実性が高い中で、不正確な見積り*3を元にした当初のスケジュール通りにいくかどうかは博打です。そして大抵そのとおりにはいきません。一方で、不確実性に甘えてなにも計画しないのも、ビジネス上は問題です。そのため、見通しは立てるものの、それを常に更新し続けていき、必要であれば期間を伸ばしたり機能を削ったりといった対処をしていく形になります。
DevOps: リリースしたものは必ず間違っている
直観は: リリースはゴール しかし: リリースしたものは必ず間違っている だから: リリースはスタート
「ようやくシステムをリリースできた。これで当初の目論見通り、課題は解決するだろう。あとは細々とした運用保守はあるかもしれないが、開発チームは解散して、別のプロダクトに取り掛かってもらおう。」 プロジェクトはある目的を達成するために、限られた期間/リソースで取り組むチームです。目的の達成のためにシステムを開発してきたので、リリースをゴールとしてプロジェクトは解散します。
しかし、リリースしたものは必ず間違っています。それはデザイン思考のパートにあるように、なにが顧客は本当に欲しいものかを誰も知らないからです。事前にプロトタイピングなどによりリスクは低減させたとしても、広く顧客に使ってもらえばまた別の改善点が見出されます。
ではどうすればいいのでしょうか。システムのリリースはゴールではなく、スタートとして捉える必要があります。
顧客のフィードバックを受けて、常にプロダクトを改善し続けていく体制が必要です。
DORAチームは長年の研究から「素早く安定して何度もリリースする」チームが、ビジネスの成果も出しているという調査結果を報告しています。速度の指標2つ、安定性の指標2つで (Four Keys) と呼ばれるものです。こうした指標も取り入れて、継続的に走り続ける体制が目的達成のためには求められます。
おわりに: 修せざれば現われず
ということで「デザイン思考」「アジャイル開発」「DevOps」を題材とした、直観に反する知見を紹介していきました。
これを読めばプロダクト開発のあれこれを改善できる... とは、残念ながらなりません。「修せざれば現われず」*4という言葉にあるように、「知る」ということと「わかる」ということは違うもので、結局はプロダクト開発に身を投じないと、理解することは難しいのです。そして、理解できないものをマネジメントすることはできません。
でも旧来の知見が通用しない領域がある、という理解は必要です。これは何もプロダクト開発だけが特別な地位にあるのではありません。ビジネスの常識を知らない人は、そこに別の常識で動く世界があることを知っていなければ、建設的なコミュニケーションは取れないでしょう。
自らの常識で、世界を全てを理解した気になるのは井の中の蛙です。異なる専門領域であれば、自らの常識が通用しない世界が広がっています。そうした異なる常識が交わる界面では、相互に敬意を持って共通認識を打ち立てたいものですね。
今年も1年間おつかれさまでした。みなさんよいお年を。
