はじめに
積まれまくっていた『スタッフエンジニア マネジメントを超えるリーダーシップ』を今さら読んだので、自分用の備忘録です。完全に私の知識・経験を前提にしています。
読んだきっかけ
いくつかありますが、この本の目次を見たときに主に以下のような課題への回答を見つけられるかもしれないと思ったためです。
- PRD や DesignDoc といった各種ドキュメントの運用について、どのようなライフサイクルを定義することで持続可能にできるかのヒントを探していた
- リアーキテクトする際のテスト戦略について、知識としてインプットしておきたかった
- 生産性とはなんなのか、Four Keys などは知っているが未だに腑に落ちたことがなかったので良い定義・解釈があれば知りたかった
先にまとめをば
私が 期待しているような知見は得られませんでした。イントロにも明示されている通り この本は解説書ではなく著者の経験をケーススタディとしてまとめた読み物 だからです。
ただし初歩的な用語の定義や概要の説明はしっかりされているので、第一部はこれからチーム開発を始める人にはおすすめできると思いました。扱っている情報がユニークで、例えば PRD の書き方を具体例とともにまとめている書籍は他に多くないでしょう (要件定義のやり方といった観点の書籍は大量にありますが)。 第二部は組織の作り方やその参考事例についてなので、これから開発組織のマネジメントに関わる人のインプットや所属している組織に生産性向上施策が行われようとしているエンジニアがその背景をキャッチアップするためには良いかもしれません。
いずれも状況に適応させないといけない項目が多数ある点には注意が必要です。銀の弾丸が存在しない領域なので仕方ないですね。
個人的なメモ
PRD では何を開発するのかの詳細に立ち入りすぎない
これはめちゃくちゃわかる～～となった部分です。開発プロセスによって求められるものは異なりますが、個人的な経験としてはビジネス要件とシステム要件 (要求と要件などと呼ぶ場合もある) が混ざっていると開発プロセスとしてスケールしづらい感覚があります。PRD を使ったプロセスで要件定義と開発を分業したいなら、PRD で何を開発するのか (≈システム要件) には深入りせず、ビジネス要件に集中されていると嬉しいですね。
参考
- 1-2 代表的な章立て - 「機能要求」の章
PRD にリリーススケジュールおよびマイルストーンを書く
このことについて、書籍内では次のような背景が紹介されていました。外的要因の考慮として、市場投入タイミングが重要なプロダクトであればスケジュールも非常に重要だというものです。PRD にプロジェクトマネジメント的なものが入ると見なすと違和感がありましたが、非機能要件の一種のようなものと解釈することで納得できました。
参考
- 1-2 代表的な章立て - 「リリーススケジュールおよびマイルストーン」の章
企画立案者が PRD のドラフトを作成するのが望ましい・ドラフトは概要～ユースケースが中心となる
機能要求以降の内容は概要～ユースケースを詳細化したものであるためドラフトの時点では書けないだろうと紹介されているのがとてもリアルに感じました。個人的には書けないに留まらず書かないと言い切ってしまってもよいのではと思っています。一人で書き進めた内容の手戻りリスクを考慮すると、早めに広いフィードバックを入れて手戻りリスクを軽減してから前進したほうが良いと思うからです。
このあたりの進め方について、特に規模が大きくプロトタイピングを挟むような場合、個人的には Dual-Track Agile のような考えも持っておくと良いと思っています。これ自体は Agile を前提とした戦術ですが、骨子である Discovery と Delivery を分けるという考え方は応用しやすいはずです。PRD を Discovery と Delivery のインターフェースにすると組織構造的にもプロセス的にもスケールしやすいだろうというのが私の持論です。
参考
- 1-3 PRD の書き進め方 - 企画立案者によるドラフト版の執筆
運用中のプロダクトの PRD
PRD を開発プロセスに組み入れるとして、既に運用中のプロダクトの扱いって悩ましいですよね。もちろん時間をかければ PRD に起こすことはできますが、えーあいってやつでなんとかしてほしい。
参考
- 1-3 PRD を書く単位
プロダクトが変化するときは新規で PRD を作成する運用の方がうまくいきやすい
これまたリアルでとても悩ましい問題です。PRD は背景やユースケースなども含むため、プロダクトの変化に追従させ続けるのは難しいです。一方で変化のたびに PRD を書く方式だと重複項目や古くなった情報の扱いが難しくなります。このあたりを完璧に運用するのは非現実的だと思いつつも、構造化することでなんとかできないかなとも思うところです。
参考
- 1-3 PRD を書く単位
Design Doc は書き捨てる
書き捨てること自体には賛成ですが、後から参照できるようにうまいことストック情報に落とし込めないかと常々思っています。NotebookLM のようなものに食わせるのが正解なのだろうか。
参考
- 2-3 タスクごとに使い捨てる
ウォーターフォールとアジャイルを組み合わせたプロセス
ある程度の規模になるとやっぱりみんなこうなるのかというのが感想です。LeSS みたいなフレームワークもあるけどやっぱり難しいよね。
参考
- 4-3 出前館におけるソフトウェア開発
SPACE フレームワーク
開発生産性を定義したフレームワークだそうです。定量的なアウトプットに基づくメトリクスだけでなく、満足度のような (中長期に効いてきそうな気がする) 定性的なものも組み込まれていて面白いですね。例えば Four Keys のようなアウトプットの計測に特化した指標とは違った意義があるかもしれません。とはいえ SPACE をちゃんと運用できる組織はどれだけ存在するのでしょうか。。。
参考
- 7-8 生産性を定義するメトリクスの考案
おわりに
ちゃんと知りたいことが書かれていそうな本を選ぼう！
