プロジェクトの依存関係管理のためのWebアプリの作り方

ユースケースと成功指標を明確にする

画面設計や技術選定の前に、解決しようとしている問題を正確に定義してください。依存関係アプリは「更新する別の場所」になってしまうと失敗します。本当の問題は、チーム間の驚きや遅延が続くことです。

コアとなる問題を定義する

会議のたびに繰り返せるシンプルな声明から始めましょう：

クロスファンクショナルな依存関係が、所有権・タイミング・ステータスの不明瞭さにより遅延と直前の驚きを引き起こしている。

組織に合わせて具体化してください：どのチームが最も影響を受けるか、どの種類の作業がブロックされるか、現状どこで時間を失っているか（引き継ぎ、承認、成果物、データアクセス等）を洗い出します。

ターゲットユーザー（と彼らのニーズ）を特定する

主要ユーザーと彼らがアプリをどう使うかを列挙します：

• プロジェクトマネージャー：差し迫ったブロッカーとエスカレーション事項を確実に把握したい
• チームリード：チームが何をいつまでに負うのか、トレードオフを明確にしたい
• エグゼクティブスポンサー：ハイレベルのリスクビューと説明責任を必要とする
• 個人貢献者（IC）：実行可能な依頼、コンテキスト、期限が必要

実行すべき主要なジョブを洗い出す

“ジョブ”は簡潔かつ検証可能に保ちます：

• 早期に依存関係を発見する（計画段階で、デリバリー中ではない）
• 依頼を作成する（スコープと日付を明確に）
• 検証する（受諾／却下。交渉したタイムラインを記録）
• 進捗を追跡する（変更履歴を含む）
• リスク増大時にエスカレーションする

ここでの「依存関係」を定義する

1段落で定義を書きましょう。例：ハンドオフ（チームAがデータを提供する）、承認（法務のサインオフ）、成果物（デザイン仕様）など。この定義がデータモデルとワークフローの中核になります。

成功指標を設定する

少数の測定可能なアウトカムを選びます：

• プロジェクト当たりのアクティブなブロッカーが減る（「遅れて発見される」依存の減少）
• リクエスト→受諾→納品までの平均時間が短くなる
• 予測可能性の向上（期日ズレの減少、オンタイム納品率の向上）

測定できなければ、アプリが実際に実行を改善していることを証明できません。

ステークホルダーと現行ワークフローをマップする

画面やデータベース設計の前に、依存に関与する人と仕事の流れを明確にします。クロスファンクショナルな依存管理はツールの問題より期待値の不一致で失敗することが多いです：「誰が所有するのか？」「完了とは何か？」「ステータスはどこで見られるのか？」といった問いに答えられるようにします。

現在依存データがどこにあるかを見つける

依存情報は散在していることが多いです。迅速なインベントリを行い、以下の例（実際のスクリーンショットやリンク）を収集してください：

• 要求と日付を追うスプレッドシート
• Jira/Asana/Trello のチケットやエピック
• ドキュメントや会議メモ（Google Docs/Notion/Confluence）
• Slack/Teams のスレッドでの決定や約束

これにより、人々が既に頼っているフィールド（期限、リンク、優先度）と欠けているもの（明確なオーナー、受入基準、ステータス）を把握できます。

ワークフローを端から端まで書き出す

現状のフローを平易な言葉で書いてください。典型的には：

request → accept → deliver → verify

各ステップに対して以下をメモします：

• 誰がトリガーするか（個人名ではなく役割／チーム）
• 次に進むために必要な情報
• 現在どこに記録されているか
• 「完了」とは何を意味し、誰が承認するか

失敗ポイントを見つけて痛みをランク付けする

オーナー不明、期限欠落、サイレントなステータス、遅れて発見される依存といったパターンを探します。ステークホルダーに最も痛いシナリオをランク付けしてもらい（例：「受諾されたが納品されない」対「納品されたが検証されない」）、上位1–2の改善を優先します。

ビルドの基準としてユーザーストーリーを定める

現実を反映した5–8個のユーザーストーリーを書きます。例：

• 「リクエストするPMとして、必要日とコンテキストを付けて依存を提出でき、所有チームが評価できるようにしたい。」
• 「所有チームのリードとして、受諾／却下を行い、コミット日を示して期待値を明確にしたい。」
• 「ステークホルダーとして、ステータスを一目で見られ、会議で追い回す必要がないようにしたい。」

これらのストーリーが機能要求が積み上がる際のスコープガードレールになります。

依存関係データモデルを設計する

依存関係アプリは、みんながデータを信頼できるかどうかで成功が決まります。データモデルの目標は「誰が何を誰からいつまでに必要か」を捉え、コミットメントの変化を時系列で残すことです。

コアの依存レコード

単独で読める「Dependency」エンティティから始めます：

• タイトル：短く具体的に（例：「更新されたチェックアウト文言の法務レビューを提供」）
• 説明：コンテキスト、受入基準、リンク
• タイプ：管理されたリスト（例：レビュー、納品、承認、データアクセス）
• 所有チーム：提供を期待するチーム
• リクエスター：依頼する人物またはチーム

可能な限りこれらのフィールドを必須にしてください。任意フィールドは空になりがちです。

日付とコミットメント

依存関係は時間に関するものなので、日付は明示的かつ分離して保存します：

• Requested by（リクエスターの必要日）
• Committed by（提供チームの約束日）
• Delivered on（実際の完了日）
• Review window（検証・サインオフの開始/終了）

これにより「要求した日」が「コミットした日」と混同されるのを防げます。

ステータスと関係性

シンプルで共有可能なステータスモデルを使います：proposed → pending → accepted → delivered、および at risk や rejected のような例外。

関係は1対多のリンクとしてモデル化し、各依存が以下と接続できるようにします：

• プロジェクト（1つの依存が複数のイニシアティブに影響する場合がある）
• マイルストーン（特定のデリバリーチェックポイントに紐づける）
• チケット（実行用のJiraなどのIssue）

監査性と信頼性

変更を追跡可能にします：

• 作成者/更新者
• 変更履歴（フィールド単位の更新履歴）
• コメント（意思決定メモ、承認記録）

監査トレイルを早期に整えると「言った・言わない」の議論を避け、引き継ぎを滑らかにします。

プロジェクト、マイルストーン、チーム所有権をモデル化する

みんなが「プロジェクトとは何か」「マイルストーンとは何か」「遅延時に誰が責任を持つか」で合意しないとアプリは機能しません。モデルはチームが実際に維持するのに十分シンプルにしてください。

プロジェクトとマイルストーン：適切な粒度を選ぶ

人々が計画や報告で使うレベルでプロジェクトを追跡します。通常は数週間〜数か月の成果のあるイニシアティブです。チケットごとのプロジェクト化は避け、チケットは実行ツールに置きます。

マイルストーンは他をアンロックする意味のあるチェックポイントに絞ります（例：「API契約承認」「ベータローンチ」「セキュリティレビュー完了」）。マイルストーンが多すぎると更新が面倒になり、データ品質が落ちます。

実用的なルール：プロジェクトは3〜8のマイルストーンを持ち、それぞれオーナー、目標日、ステータスを設定します。もっと必要ならプロジェクトを分割することを検討してください。

チームディレクトリ：所有権を見つけやすくする

依存は話すべき相手がわからないと失敗します。軽量なチームディレクトリを用意し、以下をサポートします：

• チーム名と機能（例：Payments、Data Platform、Legal）
• プライマリコンタクト（人）とバックアップ/オンコール
• 優先チャネル（メール、Slackハンドル、チケットキュー）

非技術パートナーでも使えるよう、人間に読みやすく検索可能なフィールドにします。

所有ルール：混乱のない説明責任

共有所有を許容するか事前に決めてください。依存関係では、最もクリーンなルールは：

• マイルストーン／依存ごとに単一の責任者（1人）
• 任意のコラボレーター（複数）は許容

もし2つのチームが真に共同責任を負うなら、共同所有のモヤモヤを避けるために、2つのマイルストーン（または2つの依存）として明確なハンドオフをモデル化してください。

クロスプロジェクト依存とプログラム集計

依存を要求するプロジェクト/マイルストーンと提供するプロジェクト/マイルストーンのリンクとして表現し、向きを持たせます（"AはBを必要とする"）。これにより日常のやり方を変えずに、後でイニシアティブ／四半期／ポートフォリオ別のロールアップビューを作れます。

継続して使えるタグ戦略

タグは新しい階層を強制せずにレポートの切り口を提供します。小さく制御されたセットから始めてください：

• プロダクト領域
• 四半期（またはターゲットリリース窓）
• イニシアティブ／プログラム名
• 優先度（例：P0–P3）

コアタグはフリーテキストよりドロップダウンを優先し、「Payments」「payments」「Paymnts」のような表記揺れを避けます。

コアUIとナビゲーションを計画する

依存管理アプリが成功するのは、人が数秒で「自分が何を負っているか」と「何が自分をブロックしているか」を答えられるようになったときです。ナビゲーションはデータベースオブジェクトではなく、ジョブ・トゥ・ビー・ダン（やるべき仕事）に合わせて設計してください。

実際の仕事に合う主要ビュー

まずは週の異なる瞬間に最適化された4つのコアビューから始めます：

• 依存リスト：トリアージとソート（日常のチェックに最適）
• 依存グラフ：上流／下流の影響を一目で把握
• タイムライン：日付の衝突や遅延を可視化
• チーム受信箱：コントリビューターのデフォルトランディング（「自分宛てのリクエスト」）

グローバルナビゲーションは最小限に（例：Inbox、Dependencies、Timeline、Reports）し、フィルタを保持したままビュー間を行き来できるようにします。

速い作成体験と明確さの両立

依存の作成をメッセージ送信のように速く感じさせます。テンプレート（例：「API契約」「デザインレビュー」「データエクスポート」）と**クイック追加（Quick Add）**のドロワーを提供します。

ルーティングに必要な最小項目のみを必須にします：リクエストチーム、提供チーム、期限、短い説明、ステータス。その他は任意か段階的に表示してください。

フィルタ、検索、保存ビュー

人々はフィルタを多用します。チーム、日付範囲、リスク、ステータス、プロジェクト、および「自分に割り当てられた」などで検索・フィルタできるようにし、よく使う組み合わせは保存可能にしてください（例：「私のQ1ローンチ」「今月の高リスク」）。

アクセシビリティと空状態ガイダンス

色だけに依存しないリスク指標（アイコン＋ラベル）を使用し、作成、フィルタ、ステータス更新で完全なキーボード操作を保証します。

空状態は説明的にしてください。リストが空の場合は強い依存の例を短く示します：

「Paymentsチーム：Checkout v2用のサンドボックスAPIキーを3月14日までに提供。モバイルQA開始に必要。」

このようなガイダンスはデータ品質を改善します。

ワークフローを構築する：Request, Accept, Deliver, Close

依存ツールが成功するのは、チームが実際にコラボレーションする方法を反映しつつ、長いステータス会議を強要しないときです。全員が認識できる少数の状態にワークフローをまとめ、各状態変更が「次に何が起き、誰が担当か」を明確に答えるようにします。

依頼フロー：作成 → ルーティング → 受諾

ガイド付きの「依存作成」フォームで、実行に必要な最小情報（要求プロジェクト、必要な成果、目標日、ミスした場合の影響）を取得します。次に単純なルール（サービス／コンポーネントオーナー、チームディレクトリ、手動選択）で自動ルーティングします。

受諾は明示的に行うべきです：所有チームは受諾／却下／確認要求を選びます。コメントでの“曖昧な受諾”を避けるため、受諾はタイムスタンプ付きのボタンにします。

受入基準：完了定義とサインオフ

受諾時に軽量な完了定義を要求します：成果物（例：APIエンドポイント、仕様レビュー、データエクスポート）、受入テストや検証手順、リクエスター側のサインオフ担当者。

これにより「納品されたが使えない」という一般的な失敗を防ぎます。

変更管理：日付、スコープ、再割当

変更は日常茶飯事です。すべての変更は以下を満たすべきです：

• 何が変わったか（日付、スコープ、所有者）を記録
• 短い理由を必須にする
• 両チームに通知する
• 履歴を目に見える形で残す（議論を避けるため）

エスカレーションパス：At-risk フラグとSLA

ユーザーに明確なat-riskフラグとエスカレーションレベル（例：Team Lead → Program Lead → Exec Sponsor）を与え、オプションでSLA期待（X日以内に応答、Y日ごとに更新）を設定します。エスカレーションは単なる怒鳴りつけではなく、ワークフローアクションにしてください。

クローズフロー：証拠、検証、振り返りメモ

依存は2つのステップを経てクローズします：納品証拠（リンク、添付、ノート）とリクエスターによる検証（または定義したウィンドウ後に自動クローズ）。短い振り返りフィールド（「何がボトルネックだったか？」）を残して将来の計画に活かします。

ロール、権限、監査性を追加する

誰がコミットできるか、誰が編集できるか、誰が何を変更したかが不明確だと依存管理は崩壊します。明確な権限モデルは誤操作を防ぎ、機密作業を保護し、チーム間の信頼を築きます。

実務に合うロールタイプを定義する

まずは少数のロールから始め、実際のニーズで拡張してください：

• Admin：ワークスペース設定、統合、グローバル権限を管理
• Program manager：ポートフォリオを監督し、ガバナンスを設定、争点を解決
• Team lead：チームレベルのコミットを所有し、受信依頼を承認
• Contributor：関与する依存を作成・更新、ノート追加、変更提案
• Viewer：読み取り専用のステークホルダー

オブジェクト別（アクション別）の権限

権限はオブジェクト単位（依存、プロジェクト、マイルストーン、コメント）で実装し、さらにアクション別に制御します：

• 依存の作成／編集
• 依存ステータスの変更（例：Proposed→Accepted→Delivered）
• コミット日と提案日の編集権限の分離
• 削除（通常はAdmin／Program managerに限定）

デフォルトは最小権限にし、新規ユーザーが記録を削除したりコミットメントを上書きしたりできないようにします。

データ可視性と機密作業

すべてのプロジェクトが同等に見える必要はありません。可視性スコープを追加します：

• Internal（デフォルト）：ワークスペースの認証ユーザーが閲覧可能
• Sensitive：特定チームやセキュリティグループに限定
• Team-private notes：提供チーム内のみ見える内省的なノートを持ち、依存のステータスはステークホルダーに見せる

承認制御と監査性

誰が受諾／却下できるか、誰がコミット日を変更できるかを定義します（原則は受信チームリードまたは代理）。UI上でルールを明示してください：「所有チームのみが日付をコミットできます」。

最後に、主要イベント（ステータス変更、日付編集、所有者変更、権限更新、削除）を監査ログに記録します。SSOをサポートする場合はアクセスログと組み合わせて説明責任を明確にしてください。

アラートと通知を実装する

アラートは依存ツールが本当に役立つか、あるいは誰も無視するノイズになるかを決めるポイントです。目標はシンプル：適切なタイミングで適切な人に、適切な緊急度で通知して仕事を前に進めること。

明確な通知トリガーから始める

クロスファンクショナル依存にとって重要なイベントを定義します：

• 新しいリクエスト作成（受信チームは承認が必要）
• リクエスト受諾／却下（リクエスターに確定情報を返す）
• 期限接近（直前の驚きを防ぐ）
• ステータスが"at risk"または"blocked"に変化（アクションを促す）

各トリガーにオーナーと「次のステップ」を紐づけ、通知が単なる情報提供で終わらないようにします。

チャネルは提供するが強制しない

複数チャネルをサポートします：

• アプリ内通知：監査トレイルとクリーントリアージのため
• メール：受信箱中心の人向け
• Slack/Teams：チーム可視性と迅速な反応のため

ユーザーとチームごとに設定可能にします。依存リードはSlackを好むかもしれませんし、エグゼクティブは日次メール要約を好むかもしれません。

リアルタイムとダイジェストのバランス

リアルタイムは意思決定やエスカレーション向け、ダイジェストは認知（期限や待ち項目）向けです。

設定例："割り当ては即時通知、期限は日次ダイジェスト、ヘルスは週次サマリ"。これで通知疲れを軽減しつつ可視性を保ちます。

リマインダーとエスカレーションの論理を正しく設計する

リマインダーは営業日、タイムゾーン、静音時間を考慮すべきです。例：期限の3営業日前にリマインドを送り、現地時間の9時〜18時外は通知しない。

エスカレーションは以下で発動します：

• 定義したSLA（例：48時間）で応答がない場合
• 期限がズレた、または依存がat riskにマークされた場合

エスカレーション先は責任レイヤー（チームリード→プログラムマネージャー）に順次行き、コンテキスト（何がブロックされているか、誰によるか、どんな決定が必要か）を含めます。

統合とデータ同期を計画する

統合は立ち上げ段階で依存アプリを有用にします。多くのチームは既に別の場所で作業を管理しているため、目的は「Jiraを置き換える」ことではなく、意思決定を実行ツールに接続することです。

優先すべき統合

作業・時間・コミュニケーションを表すツールから始めます：

• Jira / Linear：イシュー、ステータス、担当者、スプリント文脈
• GitHub：プルリク、リリース、デプロイシグナル
• Google Calendar：マイルストーン日、変更ウィンドウ、主要会議
• Slack：通知と軽量承認

最初は1–2個をパイロット。統合が多すぎるとデバッグが主業務になります。

インポート戦略：まずCSV、その後同期

既存の依存・プロジェクト・オーナーをブートストラップするために一度きりのCSVインポートを使います。フォーマットは意見を持って決める（例：タイトル、リクエスターチーム、提供チーム、期限、ステータス）。

その後、継続的な同期は必要なフィールドだけに限定（外部イシューのステータスや期限など）。これにより予期せぬ変更を減らし、トラブルシューティングを容易にします。

リンク vs 同期（どの時に使うか）

すべての外部フィールドをコピーする必要はありません。

• リンク：外部システムのID（Jiraキーなど）を保存し、深いリンクを張る。外部がソースオブトゥルースのときに有効。
• 同期：レポートやアラート、監査履歴のためにステータスや期限といった選択フィールドをローカルにコピーする。

実用的なパターンは：常に外部IDを保存、同期は最小限のフィールド、当アプリがソースオブトゥルースである場合のみ手動上書きを許容することです。

Webhook + API：イベント駆動の同期

ポーリングは単純ですがノイズが多いです。可能ならWebhookを優先します：

• ステータス変更を監視（例：「In Progress」→「Done」）
• 期限変更の検知（依存リスクに直結することが多い）

イベント受信時はバックグラウンドジョブで最新レコードをAPI経由で取得し、依存オブジェクトを更新します。

データ所有の境界を定義する

各フィールドの所有システムを明文化します：

• Jira/Linearはイシューのステータスと担当者を所有
• 当アプリは依存関係の関係性、コミット日、受諾／却下の決定を所有
• Slackは配信チャネルとメッセージ履歴を扱う（再現しようとしない）

ソースオブトゥルースのルールが明確だと同期競合が起きにくく、ガバナンスと監査が容易になります。

レポーティングとヘルスダッシュボードを作る

ダッシュボードはアプリが信頼を得る場です：リーダーは「もう一つスライドをくれ」と言わなくなり、チームはチャットで更新を追いかけるのをやめます。目標はチャートの洪水ではなく、「何が危険か、なぜか、次に誰が動くべきか」を素早く答えられることです。

明確なヘルスシグナルを定義する

一貫して算出できる少数のリスクフラグから始めます：

• Overdue（期限超過）：約束日を過ぎて未納品
• Blocked（ブロック）：ブロックにマークされている、または必要入力が欠落
• Missing owner（オーナー不在）：担当者が割り当てられていない
• Conflicting dates（日付の矛盾）：リクエスターの必要日が提供側の予定より後になっている等

これらは依存レベルとプロジェクト／プログラムの集計レベル双方で見えるようにします。

会議で使えるビューを作る

ステアリングミーティングの進め方に合うビューを用意します：

• 今後の重要依存：次2–4週間、リスクと期限順でソート
• チームの負荷影響：入ってくるリクエストがチームの利用可能容量を超えている箇所を表示（簡易な "低/中/高" 指標でも有用）
• プログラムロールアップ：依存をイニシアティブ／四半期／リリース列車別にグループ化して、リーダーがワークストリームを比較できるようにする

良いデフォルトは「先週から何が変わったか？」（新しいリスク、解決したブロッカー、日付変更）を答える単一ページです。

共有を簡単にする

ダッシュボードはアプリ外に出ることが多いです。文脈を保ったエクスポートを用意します：

• CSV：分析やフィルタ用
• PDF：ステアリング会議や承認用

エクスポートにはオーナー、期限、ステータス、最新コメントを含め、ファイル単体で文脈がわかるようにします。これによりダッシュボードが手動のステータススライドを置き換えます。

実用的な技術スタックとアーキテクチャを選ぶ

目的は「完璧な技術」を選ぶことではなく、チームが自信を持って構築・運用でき、依存ビューが高速かつ信頼できることです。

シンプルで実績ある形から始める

実用的なベースライン：

• 日常利用のためのWebアプリ（サーバーサイドレンダリングかSPA）
• UIと統合を支える単一のAPI（RESTまたはGraphQL）
• リレーショナルデータベース
• 通知、スケジュール同期、レポート生成のためのバックグラウンドジョブ

ユーザー操作は同期的に処理し、遅い作業（アラート送信、ヘルス指標計算）は非同期に行う形が運用しやすいです。

データベース：リンクを本気で設計する

依存管理では「Xに阻害されているすべての項目を見つける」クエリが多くなります。リレーショナルモデルはこれに有効で、適切なインデックスが重要です。

最低限、Projects、Milestones/Deliverables、Dependencies（from_id、to_id、type、status、due dates、owners）といったテーブルを計画してください。チーム、ステータス、期限、プロジェクト、from_id/to_id用のインデックスを追加して、リンクが増えても性能が落ちないようにします。

グラフとタイムライン：パフォーマンスを重視してライブラリを選ぶ

依存グラフやガント系タイムラインは重くなり得ます。可視領域だけをレンダリングするバーチャライゼーションをサポートするライブラリを選び、インクリメンタル更新が効くものにします。"全部見せる"ビューは上級者向けとして扱い、デフォルトはプロジェクト／チーム／日付範囲でスコープするようにします。

ビューを高速に保つ：キャッシュとページネーション

リストはページネーション、共通計算結果（例：プロジェクトごとのブロック数）はキャッシュします。グラフは選択ノード周辺のみプリロードして、必要に応じて展開する方式が有効です。

デプロイの基本

dev/staging/prod の環境分離、監視とエラートラッキング、監査関連イベントのログは早めに用意してください。依存アプリは真のソースオブトゥルースになり得るため、ダウンやサイレントな失敗は実際の調整コストに直結します。

プロトタイピングのための高速路線

ワークフローとUI（受信箱、受諾、エスカレーション、ダッシュボード）を素早く検証したい場合、Koder.ai のようなvibe-codingプラットフォームでプロトタイプを作るのは速い道です。データモデル、ロール／権限、主要画面をチャットで反復し、準備ができたらソースコードをエクスポートできます（一般的な選択肢はフロントにReact、バックにGo + PostgreSQL）。2–3チームのパイロットでは、初期の反復速度は完璧なアーキテクチャより重要です。

テスト、パイロット、段階的ロールアウト

人々の信頼は丁寧なテスト、限定的なパイロット、チームの配信途中で混乱させないロールアウトによって得られます。

ワークフローをエンドツーエンドでテストする

まずハッピーパスを検証：チームが依頼し、所有チームが受諾し、作業が納品され、依存が明確にクローズされる一連を確認します。

次に現実運用で壊れやすいエッジケースを試します：

• 再割当：所有権を別チームに移したときに履歴が保たれるか
• 却下：理由付きで却下→リクエスターが修正して再提出できるか
• 日付変更：マイルストーン日を変更したら下流のタイムラインやSLA、レポートが正しく調整されるか

権限と監査のチェック

権限が厳しすぎる（作業ができない）か緩すぎる（チームがコントロールを失う）かで失敗します。以下をテストしてください：

• リクエスターは自分の依頼を編集できるが、提供側の納品フィールドは編集できない
• 指定されたオーナーのみが受諾／コミット日を変更できる
• 管理者は介入可能で、重要変更はすべて監査ログに記録される（誰／何を／いつ）

通知はノイズではなく行動につながること

重複通知が出ない、フィールド変更が複数発生しても1つの要約通知にまとまる、ダイジェストに十分なコンテキストが含まれている等を確認します。

検証用のデモデータを用意する

チームを巻き込む前にリアルなデモプロジェクト、マイルストーン、クロスチーム依存をプリロードしてください。良いシードデータは、誤解を招くラベル、欠けたステータス、レポートのギャップを実運用前に露呈させます。

小さなパイロットから段階的に拡大する

2–3チームでパイロットを実施し、短期（2–4週間）で毎週フィードバックを集め、必須フィールド、ステータス名、通知ルールを改善します。

パイロットチームが「時間を節約できる」と合意したら、波状的に展開し、アプリのヘッダー等から参照できる「これが今のやり方」ドキュメントを公開して期待値を一貫させます。