はじめに
自分はバックエンドの実装を中心に数年やってきて、去年から仕様を決める側の仕事が増えた。最初に詰まったのは技術的な問題ではなかった。設計レビューでAPIの責務分割やトランザクション境界の話ならいくらでも議論できるのに、「そもそもなぜこの機能を作るのか」と聞かれた瞬間に言葉が出てこない。
もっと具体的に言うと、要件を受け取って実装可能性を判断するのは得意だった。けれど要件そのものの妥当性を疑う筋力がなかった。ユーザーが本当に困っているのはここなのか、この順番で作るのが最短なのか、そういう問いに対して自分の中に判断の基準がない。結果として「言われたものを綺麗に作る人」で止まる。
同じ場所で止まっているエンジニアは多いと思う。アーキテクチャの本は山ほど読んでいるのに、何を作らないかを決める技術については一冊も読んでいない。自分もそうだった。
そこでこの一年、設計判断の上流にあたる領域を扱った本をまとめて読んだ。その中から、実際に日々の意思決定が変わった4冊を紹介する。順番は意図的に「役割の全体像を掴む → 問題の見つけ方を深掘る → 優先順位の付け方を学ぶ → 社内で通す」という流れに並べた。頭から読めば一本の線になるはずだ。
① Principles of Product Management: How to Land a PM Job and Launch Your Product Career — Peter Yang
著者のPeter Yangは Reddit や Amazon でプロダクトを担当してきた実務家で、エンジニアからの転向組でもある。だからこの本は理論書の匂いがしない。
扱っているのは、プロダクトを決める役割が実際に一日をどう過ごしているかという地味な話だ。朝のスタンドアップで何を確認し、デザイナーとどこまで詰め、データを見てどの判断を覆すのか。その粒度で書かれた文章は意外と少ない。
後半には複数のプロダクトリーダーへのインタビューが入る。それぞれキャリアの入り口が違い、技術からの転向、デザインからの転向、カスタマーサポートからの転向と経路が並ぶ。自分と近い背景の人の語りを読むと、必要なスキルの地図が具体的になる。
英語は平易で、技術ドキュメントを普段読んでいれば詰まるところはない。分量も薄いので週末で読み切れる。
注意点としては、採用面接の話に割かれたページが日本の転職市場とはやや噛み合わない。自分はそこは流し読みして、日常業務の章だけ繰り返し読んだ。
こんな人に: 実装から一歩外に出る役割を任されて、まず全体像が欲しい人。
② ジョブ理論 イノベーションを予測可能にする消費のメカニズム — クレイトン・M・クリステンセン ほか
著者は『イノベーションのジレンマ』で知られるハーバードのクレイトン・クリステンセン。本書は共著で、実務への落とし込みを担う章が厚い。
中心にあるのは、顧客は製品そのものを欲しいわけではなく、生活の中で片付けたい用事を済ませるために製品を雇っている、という見方だ。ミルクシェイクがなぜ朝に売れるのかという有名な調査が導入になっている。買っていたのは味ではなく、通勤中の退屈をしのぐ手段だった。
この視点はログ分析の設計にそのまま効く。自分は以前、機能の利用回数ばかりを計測指標に置いていた。ジョブ理論を読んでからは、ユーザーがその機能を使う直前に何をしていたか、代わりに何をやめたかを取るようになった。置き換えられた行動が見えると、競合は同業他社ではなく手作業のスプレッドシートだったと分かる。
機能要望をそのまま実装タスクに翻訳する癖がある人には特に刺さると思う。要望の背後にある用事を聞き出せると、作るものが半分になることもある。
こんな人に: ユーザーインタビューの結果を機能リストに変換する以外の使い方を知りたい人。
③ 良い戦略、悪い戦略 — リチャード・P・ルメルト
リチャード・ルメルトはUCLAアンダーソン経営大学院の教授で、戦略論の分野で長く教えてきた人物だ。
本書の主張はかなり厳しい。世に出回る戦略の多くは、売上目標とスローガンを並べただけの中身のない文書だと切り捨てる。ルメルトが言う戦略の骨格は三つで、現状の障害を見極める診断、障害への対処方針、そして方針に沿った一貫した行動。この三点が揃っていないものは戦略と呼べない。
読みながら、自分たちのロードマップを思い出して冷や汗が出た。四半期ごとに注力領域が三つも四つも並んでいて、どれも落とさない前提になっていた。資源を集中させる決断が一つも入っていない。それは願望のリストだった。
技術的負債の返済計画にもこの枠組みが使える。どこが本当のボトルネックかを診断し、対処方針を一つ選び、スプリントの配分をそこに寄せる。やらないことを明文化するだけでレビューの議論が噛み合うようになった。
400ページ超あって読み通すのは骨が折れる。章ごとに独立性が高いので、診断と方針の部分から入るのがいいと思う。
こんな人に: ロードマップに優先順位が付かず、全部やる計画になりがちな人。
④ Storyworthy: Engage, Teach, Persuade, and Change Your Life through the Power of Storytelling — Matthew Dicks
Matthew Dicks はストーリーテリング競技の世界で何度も優勝している作家で、企業研修でも教えている。
本書の核は、どんな話も必ず「何かが決定的に変わった5秒」に収斂するという発想だ。その瞬間を先に特定し、そこへ向かう最短の道だけを残す。前置きや背景説明は切り落とす。
これは設計提案の資料づくりに直結した。自分は以前、現状のアーキテクチャ図から順に積み上げて最後に結論を置く構成を好んでいた。聞き手は途中で興味を失う。変わった瞬間、つまり「この制約が外れると処理時間が10分の1になる」を最初に置くと、残りの説明が全部その証拠として機能する。
障害の振り返り報告にも効く。時系列の羅列ではなく、判断が分岐した一点を軸に据えると、同じ失敗を避けるための教訓が伝わる。
原書のみで英語は口語的だが、章が短く区切られているので読みやすい。本のテーマがそのままサンプルになっている構成も気持ちがいい。
こんな人に: 技術的には正しい提案が会議で通らず、理由が分からない人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 全体像を掴む | Principles of Product Management | 仕様を決める役割の日常と必要スキルの地図 |
| 問題を見つける | ジョブ理論 | 要望の背後にある用事を掘る質問の型 |
| 優先順位を決める | 良い戦略、悪い戦略 | 診断から方針へ落とし込む思考の骨格 |
| 社内を動かす | Storyworthy | 提案を一点に絞って伝える構成力 |
今の課題から一冊だけ選ぶなら、こう考えるといい。
- 役割が変わったばかりで何から手を付けるか分からない → Principles of Product Management
- 機能要望が積み上がる一方で、どれも本質的に見えない → ジョブ理論
- やることが多すぎて四半期の計画が絞れない → 良い戦略、悪い戦略
- 設計の正しさは示せるのに合意形成で詰まる → Storyworthy
四冊とも共通して扱っているのは、コードを書く前の判断だ。実装力が上がるほど、作らない判断の価値が相対的に大きくなる。自分はこの一年でそれを実感した。