フィードバックの反映

本プロジェクトは、多くの人の意見を取り込んで精度を上げていく前提で作っています。このページは、受けた意見をどう扱うかの手順です。

**受けた意見を反映しない判断も、記録の対象です。**反映と不反映のどちらも残らない状態では、同じ指摘が繰り返し届き、そのたびに一から検討することになります。

受ける場所

場所	主に来るもの
GitHub Issues	内容への指摘、機能の要望、誤りの報告
GitHub Discussions	質問、雑談、まとまる前の意見
Zenn のコメント	概要記事の読者からの反応
外部の媒体(SNS など)	感想、反論、事例

**外部の媒体で受けた意見は、Issue へ転記してから扱います。**転記しないものは、後から辿れません。転記の際、発言者を特定できる情報は含めません。意見の内容だけを扱います。

トリアージの区分

受けた意見を5つに分けます。分類そのものが判断であり、分類した時点で行き先が決まります。

区分	内容	行き先
A. 誤りの指摘	事実の誤り、リンク切れ、記述の矛盾	即座に修正する
B. 根拠の提供	実測データ、一次資料、事例	根拠水準の引き上げを検討する
C. 設計への反論	前提が違う、この打ち手は効かない	判断記録(ADR)で応答する
D. 適用条件の質問	うちの条件だとどうなるか	テーラリングの規則を確認し、不足なら追加する
E. 範囲外	本標準が扱わないと決めた領域	理由を添えて閉じる

区分が決まらない意見は、決まるまで質問します。**「とりあえず保留」のラベルを作りません。**保留は、後から見たときに未着手と区別が付きません。

区分ごとの手続

A. 誤りの指摘

修正して閉じます。ADR は要しません。

ただし、同じ種類の誤りが3回以上出た場合は、検査の追加を検討します。人が毎回指摘することは、機械が指摘できます。npm run check の検査項目を増やすか、.textlintrc.json の規則を足します。

B. 根拠の提供

本標準には、実証に基づかない値が多数あります。これらは根拠水準のマークで識別子と見直し期限を付けて公開しています。

根拠が提供されたときの手続は3段階です。

#	手続
1	提供された資料が、当該マークの差し替え条件を満たすかを確認する
2	満たす場合、判断記録(ADR)を起票して採否を決める
3	採択後に本文を更新し、マークを削除する。台帳を再生成する

**マークだけを削除してはなりません。**手続を経ずに削除すると、根拠が得られたのか、単に消したのかを区別できなくなります。

差し替え条件を満たさない場合も、資料は記録します。次に近い資料が来たときの判断材料になります。

C. 設計への反論

最も重要な区分です。**反論は歓迎します。**根拠の弱い箇所を自分で全部見つけるのには限界があります。

手続は次のとおりです。

#	手続
1	反論が、どの規定のどの部分に向けられているかを特定する
2	現行の判断記録(ADR)に、その論点が既に書かれているかを確認する
3	書かれていれば、その ADR へリンクして応答する
4	書かれていなければ、新しい ADR を起票して判断する

**採用済みの ADR の本文は書き換えません。**決定を変える場合は、新しい ADR で置き換え、古い ADR のステータスを「置き換え」にして後継へリンクします(ADR の運用)。

当時なぜそう決めたのかが失われると、同じ検討を繰り返すことになります。

反論を採らない場合も、採らない理由を ADR の「検討した選択肢」へ書きます。「検討したが採らなかった」と「検討していない」は、外から区別が付きません。

D. 適用条件の質問

第8章テーラリングの規則で答えられるかを確認します。

状況	対応
既存の規則で答えられる	規則へリンクして回答する
規則の組み合わせで答えられるが、書かれていない	組み合わせ例へ追加する
どの軸にも当てはまらない	調整軸そのものの不足。ADR を起票して軸の追加を検討する

3つ目は設計の欠陥を示しています。軽く扱いません。

E. 範囲外

本標準が扱わないと決めた領域があります。

特定の製品・手段の指定(ADR-0021 決定9ほか)
特定の業界規格への適合の証明(附属書F F.1)
AI モデルの性能そのものの評価

**「対象外です」だけで閉じません。**なぜ対象外なのか、どこを見れば根拠があるかを添えます。範囲の決定にも理由があり、その理由自体が反論の対象になりうるためです。

応答の期限

区分	目安
A. 誤りの指摘	1週間
B〜D	2週間以内に区分を返す。反映の完了はこの限りではない
E. 範囲外	2週間

**期限を過ぎた Issue を自動で閉じません。**自動クローズは、意見を出した側から見れば黙殺と区別が付きません。期限は応答の目安であり、閉じる根拠にしません。

区分を返すまでの時間と、反映が完了するまでの時間を分けているのは、まず受け取ったことを返すためです。検討に時間がかかる論点ほど、沈黙が長くなります。

反映しない判断の記録

反映しない場合、次のいずれかの形で残します。

反映しない理由	残す場所
設計上そう決めている	ADR の「検討した選択肢」
根拠が差し替え条件を満たさない	当該マークの近くか、Issue のコメント
本標準の範囲外	Issue のコメント(範囲の根拠へのリンクつき)
判断を保留する	保留にしない。区分が決まるまで質問する

Issue を閉じるときは、受け入れ条件のどれを満たしたか、または満たさないと判断した理由を書きます。無言のクローズをしません。

記録に含めないもの

発言者を特定できる情報(氏名、所属、アカウント名)
特定の組織の内部事情として共有されたもの
意見の質に対する評価

3つ目が抜けやすい箇所です。「有益な指摘」「的外れな指摘」といった評価を記録へ残すと、次に意見を出す人がそれを読みます。扱うのは意見の内容だけです。

この運用自体の見直し

フィードバックが蓄積したら、この手順も見直します。区分が実態と合わない、期限が守れない、といったことは運用してみないと分かりません。