はじめに
エンジニアとプロダクトマネージャー（PM）の間で、「仕様の認識がずれていた」「アーキテクチャが決まった後に要件が変わった」という摩擦は、開発現場で絶えない課題です。
今回取り上げるのは、米国の大手小売チェーン Target（ターゲット） のテックブログに掲載された記事『 Cultivating a Strong Product Engineering Culture Through Feature Documents （Feature Documents を通じた強力なプロダクトエンジニアリング文化の醸成）』です。
この記事では、Target 社が従来の「アーキテクチャ決定記録（ADR）」を進化させ、プロダクト要件と技術設計を統合した「Feature Document（Feature Doc）」という手法を導入し、どのようにチームの連携と開発速度を向上させたかが語られています。
本記事では、このドキュメント手法がなぜ生まれたのか、そして具体的にどのような効果をもたらしたのかを解説・考察します。
1. 著者はどんな人物か
この記事の特筆すべき点は、単一の職種の人間によって書かれたものではなく、 「エンジニアリング」「マネジメント」「プロダクト」の 3 つの異なる視点を持つリーダーたちによる共著 であるという事実です。
経歴のハイライトと現在の活動
記事内で紹介されている著者は以下の 3 名です。
-
Jeffrey Bursik 氏（データエンジニアリング担当 プリンシパルエンジニア）
- 役割: 技術的な最高責任者の一人（IC リーダー）。アーキテクチャの整合性や技術的な卓越性を担保する立場です。
-
Jayanthi Narayanan 氏（シニアエンジニアリングマネージャー）
- 役割: チームビルディングとピープルマネジメントの責任者。メンバーのオンボーディングやキャリア成長、プロセスの最適化を担います。
-
Matt Jesser 氏（データサイエンスプラットフォーム プロダクトマネジメント担当ディレクター）
- 役割: ビジネス要件と製品の方向性を決定する責任者。ユーザー価値の最大化を目指す立場です。
評価される理由
彼らが評価される最大の理由は、 「三権分立」になりがちな 3 つの役割（技術・組織・製品）を分断せず、一つの解決策（Feature Doc）のもとに統合させた実績 にあります。
通常、プリンシパルエンジニアは「技術的負債」を気にし、PM は「機能リリース」を急ぎ、マネージャーは「チームの疲弊」を心配するものです。この 3 名が共同で記事を執筆していること自体が、Target 社において「プロダクト」と「エンジニアリング」の壁が取り払われ、健全な文化が醸成されていることの何よりの証明と言えます。
2. なぜこのブログが執筆されたのか（背景の考察）
なぜ Target 社は、わざわざ「Feature Doc」という独自の手法を開発し、それを公開したのでしょうか。その背景には、大規模開発組織特有の課題と、現代のアジャイル開発におけるジレンマがあると考えられます。
既存ドキュメントの限界
これまで多くの開発現場では、技術的な決定を残すために ADR（Architecture Decision Records） が使われてきました。しかし、著者は「ADR はエンジニアだけのものであり、プロダクト要件（なぜ作るのか）が抜け落ちがちで、PM を疎外してしまう」という課題を感じていました。逆に、PM が書く仕様書（PRD など）は技術的実現性が考慮されていないことがあります。
組織拡大とオンボーディングのコスト
Target のような巨大企業では、人の出入りやチーム間の異動が頻繁に発生します。「誰かに聞かないとわからない」という属人化した知識は、組織のスケーラビリティを阻害します。彼らは、新入社員やインターンであっても、ドキュメントを読むだけですぐに開発に参加できる環境（ドキュメントによる自律駆動）を求めていました。
"週次スプリント"を実現するための効率化
記事の中で驚くべきは、彼らが 「1 週間スプリント」 を採用している点です。極めて短いサイクルで成果を出し続けるためには、長時間の定例会議や、認識合わせのための手戻りは致命的です。「Feature Doc」は、同期的な会議を減らし、非同期コミュニケーションでアライメント（合意形成）を取るための必然的な解決策だったと推察されます。
3. 記事の要点解説
では、Target 社が実践する「Feature Doc」とは具体的にどのようなものでしょうか。記事の要点を 3 つの観点で整理します。
① Feature Doc = 「要件」+「設計」の統合
Feature Doc は単なる仕様書でも設計書でもありません。以下の要素が 一つのドキュメント に含まれています。
- 目的とスコープ（PM が執筆）: なぜやるのか、何を含み何を含まないのか。
- アーキテクチャ設計（エンジニアが執筆）: API 定義、データモデル、ユーザーフロー。
- リリース戦略（チームで執筆）: CI/CD、ユーザーへの周知方法。
これにより、「何を作るか（What）」と「どう作るか（How）」が分断されず、常にセットで語られるようになります。
② ドキュメントを「コード」として扱う（Docs as Code）
Feature Doc の運用プロセスは、ソフトウェア開発のプロセスそのものです。
- PM がテンプレートからドキュメントを作成（= Issue 作成）
- エンジニアが設計を追記（= コーディング）
- チーム全員でレビューし、承認されてから実装へ進む（= Code Review / Merge）
この「レビューと承認」を実装前に挟むことで、手戻りを防ぎます。また、ドキュメントは「生きた記録」として、実装中に変更があれば随時更新（コミット）され続けます。
③ 期待される 3 つの効果
記事では、Feature Doc の導入により以下の 3 点が達成されるとしています。
-
アライメント（認識統一）:
PM が定義したスコープに対し、エンジニアが技術的解を提案するプロセスを経るため、全員が「ゴール」と「手段」に納得した状態で開発に入れます。 -
コミュニケーションの効率化:
「この機能どうなってる？」という経営層や他チームからの質問に対し、Feature Doc のリンクを 1 つ送るだけで回答が完了します。会議のための資料作成時間が激減します。 -
エンジニアリング・エクセレンス（卓越性）:
ドキュメントを書くことは、自分の思考を整理し、プロとして説明責任を果たす訓練になります。これにより、インターンレベルからプリンシパルまで、エンジニア全体のスキル底上げにつながります。
さいごに
Target 社の事例は、単に「新しいドキュメントフォーマットを作った」という話ではありません。
「ドキュメントを通じて、PM とエンジニアが互いの領域に踏み込み、責任を分かち合う文化を作った」 という点が本質です。
日本の開発現場でも、「仕様書がない」「設計書が更新されていない」「言った言わないの議論になる」という悩みは尽きません。
「Feature Doc」のように、 職能を超えて一つのドキュメントを共同で育て上げる というアプローチは、サイロ化しがちな組織をつなぎ、開発速度と品質を両立させる強力なヒントになるのではないでしょうか。
もしあなたのチームで PM とエンジニアの距離を感じているなら、まずは「一つのドキュメントを一緒に書く」ところから始めてみるのも良いかもしれません。