優秀なエンジニアが書くDesign Docは何が違うのか? - pospomeのプログラミング日記

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 自分はここ数年いろんなエンジニアが書いたDesign Docをレビューする機会があるんですけど、その中で「優秀なエンジニアであれば、ここは押さえて欲しい」「ここでエンジニアとしてのスキルが分かる」というポイントがありまして、今回はそれを言語化してみようと思います（同じ話を社内でしたので、せっかくなら記事にしようかなと・・・）。 もちろん、Design Docだけでエンジニアの能力が決まるわけではありません。ただ、設計時にどこまで選択肢を広げ、リスクを深掘りし、何を今決めるべきか判断できているかは、Design Docによく表れます。 Design Docのフォーマットは組織によっていろいろあると思いますが、本記事は特定のフォーマットに依存しない形で書いています。 Design Docはなぜ重要なのか? De

[pmint]

例が残念なので、思いつきを語ってるだけだと分かる。「機能を何年持たせるのか」は経営者。「どのテーブルが肥大化するのか」が設計者。未決定事項より依存関係が大事で、未決を明らかにしつつ、判断を軽減する。

[gengo_k]

文章の途中に広告入ってくるの私だけ？普通に誤認してしまう。

[JULY]

とりあえず「Design Doc」という表現がいけ好かないなぁ。言っている事は分かるけど。

[kiririmode]

優れたDesign Docの価値は、採用した設計の結果ではなく、「採用しなかった選択肢」「採用後も残る不安」「意図的に先送りした判断」という、設計結果の外側にある情報を可視化できていることに現れる

[mcddx30]

https://x.com/engineer_ryoma/status/2092807523527233739

[puruhime]

よくやってる

[aalpaca375]

「本当に頭の良い人はわかりやすい説明ができる」案件じゃないか。この観点では、読み手と書き手のレベル差が小さいことしかわからない。

[rdrcks1319]

✔

[yarumato]

“設計書には、以下をしっかり書いて欲しい。代替案、懸念点、未決定事項”

[bamch0h]

このままAIに食わせよう（アカン('ω'乂)

[rook5963]

難しい言葉や独自用語が少なくて読みやすいのも追加であると思う。主線がすっきりしてて整理されつつ懸念などが書いてあって読みやすい。

[peketamin]

なるほど、選択肢を選んだ理由以外にも選ばなかった理由も、たしかに書くといいよね

[mkusaka]

Design Docレビューで重要な「代替案・懸念点・未決定事項」を言語化し、優秀さの違いを解説する。