#Product Management #Documentation Jeff Pattonが考案した、プロダクトの機会（オポチュニティ）を1枚で記述するためのキャンバス 仮説検証前のアイデア整理に用いられ、ユーザー価値とビジネス価値を並列に整理する 主な構成要素 Problems / Solution Ideas（課題と解決アイデア） Users & Customers（ユーザーと顧客） Solutions Today（既存の代替手段） User Value / Adoption Strategy（ユーザー価値と採用戦略） Business Problems / Benefits / Metrics（ビジネス課題・便益・指標） Budget（予算） https://jpattonassociates.com/opportunity-canvas/

#Documentation WebサイトのコンテンツをLLMが効率的に利用するための提案標準。Jeremy Howard（Answer.AI）が2024年に提案 サイトルートにMarkdown形式で /llms.txt を配置しLLM向けの構造化された目次を提供する コンテキストウインドウの効率的な活用のためHTMLのノイズを排除する https://llmstxt.org/

#Documentation 以下の4つのダイアグラム図を表すアプローチ Context Diagram Container Diagram Component Diagram Code Diagram 順に抽象度が下がっていく流れになっている https://c4model.com/

Example Mapping #Documentation Agile Testing、BDDで紹介されるプラクティス。Matt Wynneによって考えられた マッピングする付箋の種類には Story Rule Example Question の4種があり、あるStoryにおけるExample（具体例）を軸に、定められるRuleと残論点としてのQuestionをマッピングする

#Documentation Open API仕様を元にドキュメンテーションを行いシンプルなUIで表示される CLIによるドキュメント生成またはHTMLファイルへのscript埋込が可能 Redoc

Large Language Model Wiki #LLM #Documentation Andrej Karpathyが提唱した、LLMが構造化されたmarkdown wikiを継続的に構築・保守する個人ナレッジベースのパターン。 3層構成: Raw Sources（不変の一次資料）、Wiki（LLMが生成・更新するmarkdown群）、Schema（構造と運用規約の設定ファイル） 3つのコアプリミティブ: Ingest（新規ソースを既存ページへ統合）、Query（wikiを検索して回答し、価値ある結果は新ページとしてfile back）、Lint（矛盾・古い記述・orphanページ・cross-reference欠落を定期検査） 動機は「ナレッジベース保守の面倒な部分は読むことや考えることではなく、bookkeeping」という洞察。人間はsource curationと問いに集中し、bookkeepingはLLMに委譲する https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

#Documentation 「何を作ればよいのか」を明確にするために行う

#Documentation Write the Docsコミュニティが提唱するソフトウェア開発と同じツールとワークフローを使用してドキュメントを作成・管理するアプローチ 以下のような特徴がある Gitを使用したバージョン管理 Markdownなどのマークアップ言語を利用 レビュープロセスを経る ドキュメントの品質をチェックする https://www.writethedocs.org/guide/docs-as-code/

Architectural Decision Records #Documentation アーキテクチャに関する意思決定とその理由を記録する文書。意思決定に際する文脈、根拠、その決定による成果物等を記述する ADRはなぜそのアーキテクチャを選出したかの意思決定を理解するのを助ける。 ADRはチームメンバーの誰もが作成できる。ただしオーナーシップとしてAuthorは明確にする必要がある。初期ステータスは Proposed とする。 次に他チームメンバーによるレビューを行う。修正すべき点がある場合は Proposed のままアクションのアサインを行う。このときアサインはチームメンバーの誰でもよい。ADR自体はRejectする場合はステータスを Rejected にしADRのライフサイクルは終了する。 レビューを経て全てのアクションが完了した場合、ステータスを Accepted にする。一度AcceptされたADRはイミュータブルに扱い変更はしない。 Architectural Decision Records (ADRs) ADR process - AWS Prescriptive Guidance

#Testing #Documentation Chris Mattsによって考えられた、以下のフォーマットでテストシナリオを記述する記法 Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters https://cucumber.io/docs/gherkin/reference

#Agile #Product Management #Documentation Jeff Pattonが考案したユーザーストーリーを洗い出すためのプラクティス。フラットなバックログの代わりに、ストーリーを地図（マップ）の形に並べてプロダクト全体を俯瞰する。 最終的なマップは、上位からアクティビティ、ユーザータスク、ストーリーの階層で構成される。 作成はこの完成形を上からなぞるのではなく、具体から始める。まずユーザータスクを書き出し、ナラティブフローに沿って並べて網羅したうえで、それらを集約してアクティビティを抽出する。 https://jpattonassociates.com/story-mapping/ https://jpattonassociates.com/the-new-backlog/

Markdown Architectural Decision Records #Documentation ADRを記述するテンプレートカテゴリの一つ。マークダウンによって構造化された文書を提供する いくつかのテンプレートは以下から参照可能 https://github.com/adr/madr/tree/develop/template About MADR | MADR

#Data Engineering #Continuous Integration #Continuous Delivery #Documentation データベーススキーマの最新の状態をコードとして管理し、変更時の差分を元に自動でマイグレーションクエリを生成してくれるようなDevOpsツール PostgreSQLやMySQLといった代表的なデータベース管理システムに対応している Atlas CloudによってWeb上での可視化も可能 Ariga社によって開発されている https://atlasgo.io/docs

Product Requirements Document #Documentation #Product Management プロダクトに必要な機能・振る舞いを定義する文書。開発チームとステークホルダーの間で「何を作るか」の共通認識を形成する 主な構成要素として、目的・ゴール、ユーザーペルソナ、機能要件、非機能要件、成功指標を含む

#Documentation Go言語で書かれたhigh-level architectureダイアグラム/ドキュメント化ツール 単一のndiag.yml設定ファイルから複数のview（ダイアグラム + Markdown）を生成（N-diagrams） nested clusterによるノード／コンポーネントの階層化、実システムとの差分検証に対応し、ダイアグラムはGraphvizでレンダリングしてPNG/SVG/DOTを出力 https://github.com/k1LoW/ndiag

#Data Engineering #Documentation Go言語で書かれたデータベースドキュメント化ツール データベーススキーマを自動的にMarkdown形式で記録し、CI/CDパイプラインに統合可能 PostgreSQL、MySQL、BigQuery、Snowflakeなど多数のデータベースに対応し、差分検出（diff）、品質チェック（lint）、ドキュメント網羅率測定（coverage）などの機能を提供 https://github.com/k1LoW/tbls

Unified Modeling Language #Documentation システムの設計を視覚的に表現するための統一的な記法

Formulation #Testing #Documentation BDDのプラクティスのひとつ。システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する

#Documentation

#Documentation DevOps capabilitiesの1つ、Climate for Learningに分類される https://dora.dev/capabilities/documentation-quality/

#Documentation #LLM Devinと連携されたリポジトリの内容を説明するWikiを生成する機能 自動でインデックスされる

#Documentation Write the Docsコミュニティの2025年7月ニュースレター アニメーションGIF: 自動再生を避け、操作可能な短い動画や静止画+再生ボタンを推奨 ドキュメント監査: 目標の明確化、多様なレビューチーム編成、品質チェックリストの整備 ドキュメンタリアンのためのアジャイル: スプリントサイクルとの連携 AI/LLMの活用: オリジナルコンテンツ作成には不向きだが、テンプレート生成・スタイルガイドレビュー・要約・反復編集に有効。有効な場面を明確にした戦略策定が重要 https://www.writethedocs.org/blog/newsletter-july-2025/ ブログ

#LLM #Documentation Devinの一つの機能であるDevin WikiをPublicなリポジトリに絞って利用できるOSS Devin Searchに相当するAsk機能も備えている https://docs.devin.ai/work-with-devin/deepwiki

#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語 以下、原著から抽出 モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する

#LLM #Documentation Claude Codeにおいて、 .claude/commands ディレクトリ内にMarkdownファイルを用意しプロンプトを記述すると再利用が可能になる機能 https://docs.anthropic.com/ja/docs/claude-code/slash-commands#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89

#Agile #Product Management #Documentation プロダクトバックログアイテムが完成したと判断できる条件

#Documentation 文書の冒頭に書く要約に用いるフォーマット （S）シチュエーション （C）コンプリケーション （Q）クエスチョン （A）アンサー の4つを用いる

#Documentation Kubernetesの各リソース等のアイコンを公開しているリポジトリ 様々なダイアグラムサービスのデータセットに利用されている https://github.com/kubernetes/community/tree/master/icons

#Documentation ドキュメンテーションに関心を持つ人たちを歓迎するコミュニティ https://www.writethedocs.org/

#Documentation エンタープライズ・アーキテクチャーを記述するためのグラフィカルなオープンソース言語 https://www.archimatetool.com/