優秀さは成果物に宿らない: PM、データベース、Rustに共通する「見えない設計」

「仕事ができる人」を一人、チームから外してみる。すると、その人が優秀だったかどうかは、意外なほど簡単に分かることがある。判断が速い。実装が正確だ。説明がうまい。顧客の信頼も厚い。

では、優秀なPMを同じ方法で見抜けるだろうか。むしろ、優秀なPMほど、本人がいなくなった後に初めて価値が分かることがある。会議が荒れない。決定が蒸し返されない。レビューで問題が早く見つかる。データが壊れにくい。チームが、誰か一人の英雄に依存せずに動き続ける。

ここには、エンジニアリングにおける重要な逆説がある。最も価値のある仕事は、最も目立つ成果物を作ることではなく、成果物と人が壊れにくい条件を設計することかもしれない。

この視点に立つと、PMの力量、RDBMSのスキーマ、コードレビュー、Rustの安全性、そして時に必要とされる危険なハックまでが、一つの問いでつながって見えてくる。

見えない仕事は、能力ではなく「可能性の分布」を変える

個人の仕事の能力は、比較的観察しやすい。短時間でコードを書ける、複雑なバグを直せる、資料を作れる。こうした能力は、本人が直接生み出した出力として現れる。

しかしPMの仕事は、本人の出力を増やすことではない。他の人が適切な判断をし、適切な順番で動き、誤りを早く発見できるようにすることである。だから、優秀なPMは「自分が何をしたか」よりも、「チームがどんな失敗をしなくなったか」によって評価されるべきだ。

たとえば、二つのチームが同じ機能を開発するとする。

Aのチームには、非常に優秀なPMがいる。要件の曖昧さを事前に分解し、意思決定者を明確にし、レビューの場を用意し、将来の変更点まで確認する。ただし、そのPM自身は、資料を作る速度も、技術的な会話の華やかさも平均的だ。

Bのチームには、仕事が速く、説明も巧みなPMがいる。しかし、決定の根拠は記録されず、問題が起きると本人が個別に調整し、レビューは形式的で、責任の所在は曖昧なままだ。

短期的には、Bのほうが優秀に見えるかもしれない。会議は速く終わり、質問には即答し、進捗報告も滑らかだからだ。しかし数か月後、Bのチームでは判断が本人に集中し、本人が不在になると停滞する。Aのチームでは、PMが目立たなくても、仕組みが判断を支えている。

ここで測るべきなのは、PMの個人パフォーマンスではない。チームが将来、どれだけ多くの良い選択肢を持てるようになったかである。

優秀な人とは、問題を自分で解く人だけではない。問題が発生したとき、解ける人が必ず見つかる状態をつくる人である。

この定義なら、データベース設計やプログラミング言語の設計思想も、単なる技術選択ではなく、チームの判断能力を設計する行為として読み直せる。

スキーマはデータの規則ではなく、組織の記憶である

RDBMSを使うか、NoSQLを使うか、ファイルシステムを使うか。この議論はしばしば、性能、拡張性、開発速度の比較として語られる。しかし実務では、もっと根本的な問題がある。

複数の人間が、時間をかけて同じ情報を扱うとき、どのように秩序を維持するか。

スキーマは、単に列の型を指定するものではない。それはチーム全体に対する約束である。どの値が必須なのか。何が一意なのか。どの関係が成立しているのか。どの状態が不正なのか。これらをデータベースに表現すると、知識が個人の頭の中から共有された構造へ移される。

たとえば、顧客の注文をJSONの塊として保存する場合を考えてみよう。最初は便利だ。新しい項目を追加しても、テーブル変更や移行を考えずに済む。しかし、担当者が増え、数年が経つと、同じ意味の値が違う名前で保存され始める。「customerId」と「customer_id」が混在し、日付の形式が複数になり、存在しない状態を表す値が入り込む。

このとき問題なのはJSONという形式ではない。未来の誰かが守るべき秩序を、現在の誰も明文化しなかったことである。

もちろん、厳格なスキーマにも代償はある。初期の仮説に固執し、まだ不確かなモデルを固定してしまう危険がある。だから重要なのは、最初から完璧な構造をつくることではない。まず関係データベースで基本的な秩序を持たせ、必要になった部分だけ別の形式へ切り出す、という発想には合理性がある。

この方法の本質は、RDBMSを永遠の正解とみなすことではない。後で自由になるために、先に最低限の共通ルールを置くことである。自由は、制約の反対ではない。適切な制約によって、局所的な変更が全体を壊さない状態こそ、実務における自由である。

これはPMの仕事とも一致する。優秀なPMは、チームの全員を細かく管理するのではなく、決定の形式、レビューの経路、責任の分担を整える。個々のメンバーの人格や善意に依存せず、情報が流れ、問題が発見され、判断が修正される構造をつくる。

レビューは「責任逃れ」ではなく、責任を増やす仕組みである

組織で仕事をする以上、設計レビューやコードレビューによって事前に問題を見つけ、知見を共有し、複数人で責任を持つことには大きな価値がある。

ただし、レビュー体制は誤解されやすい。レビューを通過したから自分には瑕疵がない、という態度になると、レビューは責任の分散ではなく責任の消滅になる。誰も決定を所有しない状態が生まれるからだ。

健全なレビューとは、「誰かが許可を出す場所」ではない。異なる視点を衝突させ、決定の品質を上げる場所である。レビューを受ける側は、指摘を自分への攻撃と捉えない。レビューする側は、後から責めるために細部を探すのではなく、未来の利用者や保守担当者の立場を代表する。

ここで必要なのが、互いへのリスペクトである。リスペクトは、相手を無条件に肯定することではない。むしろ、相手が合理的に判断しようとしていると仮定したうえで、厳しい問いを投げることだ。

「なぜこの設計にしたのか」 「どの前提が崩れると危険なのか」 「誰が、どの条件で、元に戻せるのか」

こうした問いが成立するには、レビューを人格評価から切り離す必要がある。問題を指摘された人が恥をかく文化では、問題は隠される。問題を早く出した人が信頼される文化では、チームは壊れる前に修正できる。

この観点から見ると、良いPMの「見えなさ」も理解できる。PMは、問題を自分の調整能力で消しているのではない。問題が安全に表面化し、関係者が共通の事実を見て、必要な判断をできるようにしている。本人が英雄になるほど、チームの問題発見能力は弱くなることがある。

Rustと危険なハックが教える、制約には階層がある

安全性を重視するRustのような設計思想は、メモリの危険な操作によってしか実現できない処理を、簡単には許さない。これは一見、表現力を狭めているように見える。しかし実際には、チーム全体が理解しやすく、壊しにくく、保守しやすいコードを生みやすくする。

一方で、ポインタ操作を駆使した低レベルのハックが、特定の環境では必要になることもある。性能、互換性、ハードウェア制御など、行儀の良い抽象化では届かない領域が存在するからだ。

ここで重要なのは、どちらが正しいかを決めることではない。制約には階層があり、どの層の制約を破るかを意識すべきだということだ。

個人の実験コードでは、局所的なハックを許してもよい。しかし、複数人が長期間触る基盤コードで同じことをすれば、知識のない人が安全に変更できなくなる。問題は危険な操作そのものではなく、危険の境界が明示されていないことにある。

実務で成熟した設計は、ハックを道徳的に禁止するのでも、自由に放置するのでもない。危険な処理を小さな境界に閉じ込め、理由を記録し、テストを厚くし、利用側には安全なインターフェースだけを見せる。

この考え方はデータベースにもPMにも適用できる。柔軟なJSONを使うなら、どの範囲が自由で、どの項目が契約なのかを明示する。重要な判断を一人に任せるなら、どの条件で再確認するのかを決める。例外を認めるなら、例外を通常運用へ拡大しない仕組みを置く。

制約をなくすことが自由なのではない。どの制約を、誰が、どの条件で破ってよいかを共有することが自由である。

優秀なPMとは、すべてを厳格にする人でも、すべてを許容する人でもない。組織にとって重要な境界を見極め、境界の内側には自由を、境界の外側には慎重さを配分する人である。

「属人性を消す」のではなく、属人性を安全に配置する

ここまでの議論から、一つの実務的なモデルを導ける。チームの設計を、三つの層に分けて考えるモデルである。

第一層は、不変に近い契約だ。データの必須条件、公開APIの意味、法的要件、障害時の復旧手順など、壊れると広範囲に影響するものを置く。ここはスキーマやテスト、レビューによって強く守る。

第二層は、チームで調整可能な運用だ。優先順位、実装方針、担当の分担など、状況に応じて変えるものを置く。ここでは議論と記録が重要になる。固定しすぎると現場の判断力を奪い、緩すぎると毎回同じ議論が発生する。

第三層は、局所的な実験と例外だ。新しい技術、性能改善のハック、まだ検証されていない仮説を置く。自由に試してよいが、影響範囲を狭くし、失敗して戻せるようにする。

この三層を混同すると、二つの失敗が起きる。すべてを第一層のように扱えば、組織は動けなくなる。すべてを第三層のように扱えば、組織は学習せず、同じ事故を繰り返す。

良いPM、良いアーキテクト、良い技術リーダーは、仕事をこの三層へ適切に配置する。自分の能力で全てを処理するのではなく、何をルールにし、何を議論にし、何を実験にするかを決める。

だから、優秀さは個人の手際だけでは測れない。その人がいなくても、チームが適切に考え続けられるかが、より深い評価基準になる。

Key Takeaways

1. 成果ではなく、将来の判断可能性を評価する その人が何件処理したかだけでなく、本人が不在でもチームが判断できるかを確認する。意思決定の記録、前提の共有、問題発見の早さを測る。

2. 自由にする領域と、契約として守る領域を分ける すべてを厳格に管理する必要はない。しかし、データの意味や障害対応のように全体へ影響する部分は、スキーマ、テスト、レビューで守る。

3. レビューを承認手続きから学習の場へ変える 「誰が許可したか」ではなく、「どの前提を検証したか」を記録する。指摘された人の評価を下げるのではなく、早く問題を出したことを価値にする。

4. 例外は禁じるのではなく、隔離する 危険なハックや柔軟なデータ形式を使う場合は、影響範囲を限定し、理由、撤退条件、テスト方法を明記する。例外を共有された設計に変える。

5. PMの価値を、目立たなさから探す 会議で最も話す人や、最も速く答える人だけを評価しない。手戻りが減ったか、判断が再利用できるか、責任が健全に分散しているかを見る。

最後に、優秀さの定義を反転させる

私たちは、優秀な人を見つけると、その人の能力を組織へ投入しようとする。しかし本当に優れた人は、自分の能力を投入するだけでなく、能力が組織の構造へ変換されるように働く。

データベースのスキーマは、個人の記憶を共有された秩序に変える。レビューは、個人の責任を集団の学習に変える。安全な言語は、熟練者の勘を、多くの人が扱える制約に変える。優秀なPMは、これらと同じ仕事を人間関係と意思決定の領域で行う。

だから、優秀さを「どれだけ自分でできるか」だけで測るのは不十分だ。より本質的な問いはこうである。

その人の働きによって、他の人がより安全に自由になり、より早く学び、より良い判断を続けられるようになったか。

もし答えが肯定なら、その人は目立たなくても、仕事の最も重要な部分を担っている。優秀なPMが見抜きにくいのは、能力が隠れているからではない。能力が、本人の外側にある仕組みや習慣や信頼へ変換されているからである。