【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ

[kei_0000]

この手のドキュメント指針において、「デザインドキュメントを書いてはいけない時」という章があるのは珍しいのでは。無駄なことは極力避けると言う文化が根付いている結果と思われる。羨ましい。

[gabuchan]

設計の中でも特に Why が明文化されてると良いよね

[masahiko_of_joytoy]

アジャイルだからドキュメントは書かなくていい、コードとテストケースでわかるから。みたいなこと平気で言うエンジニアはぜひともこれを読んでいただきたい

[xlc]

ドキュメントをいつ書くのかでどんな組織か分かると思う。日本だとSIerなら最初から書き、ソフトハウスは永遠に書かないという印象。プロトタイプ段階ではコード優先、製品化の段階でドキュメント化がいいのかな。

[lalupin4]

日本だと「共有サーバの『大手ＳＩer様Ｓｉ案件\06_基本設計\99_基本設計資料\資料\他社事例\グーグル（概要）.xlsx』を参考にしてください」とか言われる。

[zou3dazou]

"デザインドキュメントを書くかどうかの判断は、設計、文書化、上級職によるレビューなどに関する組織的な合意形成のメリットが、デザインドキュメントの作成に伴う労力を上回るかどうかのトレードオフに帰着します"

[michael-unltd]

“Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。”

[JGEEM]

デザインドック／some circles -> the rest of the fucking owl

[manhole]

design doc

[tick2tack]

デザインドキュメント

[simomm]

仕様書なのか設計書なのか要件定義書なのか

[ramda-phi]

“文脈と範囲”

[nonsugertan]

あとで読む

[kagehiens]

ほー。ちょっと意識してドキュメント整備してみよう。

[tasukuchan]

“ ”

[sezemi]

“合意を得るための優れた方法”Readme とかに書くのが良さそう

[pwatermark]

機械的にやるものってほとんどなくて、目的をまず設定すれば「やるべきこと」と「やらないこと」は大体決まってくるんだよね その辺をすっ飛ばす人が多すぎる

[minamishinji]

よいなぁ。

[aipacommander]

ちゃんと読みたい

[vine_hate]

ドキュメント

[TheTrueMirror]

"将来の保守プログラマーがデザインドキュメントの考古学を通して対象のシステムを理解しようとしている場合にはきっと役立つでしょう。"すごい婉曲

[awkad]

Google様のやることはすべて礼賛される。いや欧米のやることは全て素晴らしいと日本人の遺伝子に刻み込まれている

[sabinezu]

デザインと設計を勘違いする人いそう。

[h_taiji]

共有

[roshi]

ふくろうの絵を見た覚えがあるからブクマしてると思ったのに、、これとは違うかもだけど最近だとGitHubのPRコメント先頭に似たようなのが書かれる印象。

[sadoru3]

“ソフトウェアエンジニアとしての私たちの仕事は、コードを作成すること自体ではなく、むしろ問題を解決することです。”

[tettekete37564]

「一部を除いてぶっちゃけ酷いの多く無い？」 < その一部の成功に相当する再現性を上げる、失敗も第三者による評価が可能になる、同じ失敗が起きないようにできる、等々組織自身の成長にメリットが大きい

[yasu-osu]

考えたことを言語化するというよりも、モノを作る前に考えておくべきことを言葉にする（ドキュメントを書く）習慣を持つことで、強制的に考える機会を作る習慣を得るということかなと理解しています。

[gohan108]

プロジェクト憲章みたいなものか

[getcha]

Googleのプロダクトって一部を除いてぶっちゃけ酷いの多く無い？方法論ばかり出してくるコンサルみたいな会社になってる気がする。