Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ちゃんと Design Doc を書いたら技術負債の解消が捗った

ちゃんと Design Doc を書いたら技術負債の解消が捗った

SRE Kaigi 2025 アフターイベント【増員】
https://hireroo.connpass.com/event/342513/

masahiro ogawa

January 29, 2025
Tweet

Other Decks in Programming

Transcript

  1. 2 小川 仁寛 / Masahiro Ogawa / MSHR-Dec 株式会社primeNumber SRE

    SRE. primeNumber inc. AWS / Kubernetes / Go らへんが好きです。 開発言語を問わずプロダクトの技術負債解消に取り組 んでいます。 2023/6 から株式会社primeNumberの SRE に従事。 Ruby on Rails と Kubernetes を用いてトイルの解消や プロダクトの技術負債を粛々と解消しています。
  2. 4 Design Doc 書いてますか? 煽っているわけではありません! 私自身、pN 入社後から本格的に読み書きを始めました。 ちなみに弊社でどのような Design Doc

    を作成しているかといった Design Doc それ自体を掘り下げることはしません。 また Design Doc の定義は組織によって異なるとは思います。 そのため今回の発表内容がすぐに活用できるものでない点ご承知おきください。
  3. 5 Design Doc のイメージ Design Doc 活用以前の個人的なイメージです。 • 新規機能開発で使うイメージ ◦

    明確なゴール (機能の実装) へ向かう How をまとめる • 技術負債解消は不確定要素が多いため Design Doc と相性悪そう ◦ その都度技術的課題は GitHub にコメントしているし大丈夫でしょ • ドキュメントは書いているつもり ◦ 他部署への共有のため ▪ How よりは Why や What が強いもの
  4. 8 PR のレビューが快適になる • 実装の差分でなく、負債解消を体系的に共有できる ◦ 実装 PR の前に Design

    Doc のレビューを行うため • PR 作成側も実装の説明に Design Doc を添えるだけで済む ◦ コメントの打ち合いも減る
  5. 10 新たな技術負債を生みにくくなる • 課題や方針を体系立ててチームで共有できる ◦ 色々な観点から鋭いフィードバックを受けることが可能 ◦ 考慮漏れなどからくる負債が減る • Design

    Doc 作成の段階で頭が整理される ◦ 淡々と GitHub にコメントを書くのとは違う ◦ 筋道を立てて説明する必要があり整理が捗る ◦ 結果負債も減る
  6. 12 負債解消後も活躍する • あそこの仕様どうなってたっけ? ◦ Design Doc でまとめていた場合はリンクを貼れば済む • 負債解消箇所の改修で役立つ

    ◦ 意図などがまとまっているため実装が捗る • 後日談をブログにまとめる時に役立つ ◦ 人に説明する目的で作っているためブログへの流用が簡単 ◦ 反響いただいた記事は Design Doc があったから書くことができた ▪ 【ログ分離】 ログデータを DB に保存してはいけません