タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 Munetoshi Ishikawa, supported by LINE corporation
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
Design Docの書き方
背景、目的 (Why?) 検討した別の方法 (alternatives considered) トレードオフ (Why not?: なぜ別の方法にしなかったのか？) 設計、アーキテクチャ (How?) メンバー (担当者やレビュワー) (Who?) セキュリティやプライバシーについての考察など 他プロジェクトとの関連性 テスト，モニタプランなど 基本的には、ソースコードを見てもわからない部分をDesign Docに書いて、議論するのが一般的のようです。 Design Docは、Googleに代表される最先端の技術企業で取り入れられている設計ドキュメントのスタイル。 単にドキュメントの書式だけを指すのではなく、書いた後の使い方までを含めた『開発のやり方』につながっているドキュメント方式。 アジャイルなどの現代的なソフトウェア開発スタイルにフィットしているため、シリコンバレーのスタートアップ企
How Google Works (日本経済新聞出版) 目次 目次 はじめに Design Docの要点メモ 参考資料 MyEnigma Supporters はじめに GoogleなどのIT企業がソフトウェアを開発する際には Design Docというドキュメントを利用しているそうです。 Design Docは「設計書」と訳されることが多いですが、 日本語の設計書とは少し意味合いが違うようです。 今回は、このDesing Docの要点を、 末尾の参考資料を元に勉強してみたので、 自分用のメモとしてまとめておきたいと思います。 Design Docの要点メモ Design Docは、 これから新しく開発しようとするソフトウェアの全体の設計や、 既存のコードのpatchやプルリクエスト(PR)のコード変更の 基本的な要点をまとめる文書です。 PRを作成する前に、Design Docを作成して
データ基盤を支えるdesign doc
この記事はdatatech-jp Advent Calendar 2022の12月11日の記事です！ 概要 自チームでデータ基盤を作っていく際に使っているdesign docの紹介と、導入背景をここに記します 感じていた課題感 レビュアーにアサインされてプルリクを見るときに「このプルリクはどういう背景があって、どういうコードを書いたのか、どういうテストをしたから大丈夫なのか」を汲み取るのに時間がかかるなって思っていた 備忘録的にissueにたてる、とりかかるときにタイトルだけ埋めたissueを立てて走り出す、ということが多く感じて、事前に整理しておくともっと効率が上がるのではと思った データ基盤を作っていく際に、ログやテーブルの値の意味などをエンジニアにヒアリングすることがあるが、それをちゃんと蓄積したいと思った これに関しては、別途Notionで蓄積してるものがあるのですがGithubに
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方｜kakomoe
仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方 💡このnoteはなに？ プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです 💡誰のためのnote？ プロダクト開発に必要なドキュメントについて日々心を悩ませている人 ドキュメントの話に着地をつけたい 誰かが言い出すアレ今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。 プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。 そしてそれぞれの言葉には単一の定義があるわけではない。 そもそもドキュメン
Design Doc自分用テンプレート（参考：http://diary.overlasting.net/2010-01-27-4.html）
design-doc-template.md [プロジェクトのタイトル。例：作成するライブラリの名前は？] プロジェクトの目的 [何を実現するの？] プロジェクトの背景 [どんな背景があるから実現するの？] ハイレベルアーキテクチャ [コードだけでは分からない作成物のアーキテクチャを画像などで] プロジェクトの参加者 [連絡先が大切。誰が参加するのかを明らかにしよう] 仕様（とくに従うべき仕様がなければ飛ばす） 実装する仕様 [事前に仕様が決まっていたら] 既存のものとの相違点 [既存のものと何が違うのか、比較対象の仕様があれば言えるだろう] 関連する仕様 [関連する仕様があれば] 各クラスの概要 [各クラスの概要を書く] 実装 インターフェイス [各クラスのインターフェイスの概要。hファイルや、javadocやpod形式かな。関数や構造体を定義するコードとコメント] 処理フロー [「どの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
網羅的なPRDやDesign Docを書かなくなった - kosui
プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke mori
Design Doc for react-boilerplate-2022
Googleなどで利用されているDesign Doc入門 - MyEnigma
www.kendo.or.jp
qiita.com/ysk-s
www.nikkei.com
ponpokonwes.com
intensive911.com
sn-jp.com