要約

  • 2026年8月のTools Updateは、Datatrackerの約1,100件を例に、GitHubに数千件の未解決issueがあり、そのほとんどは関連する作業の構造にも入らず、工数と優先度も評価されていないと説明した。
  • 新しい計画は、Goal -> Project -> Epic -> Taskによる整理、最下層Taskの工数見積もり、GoalとProject単位の初期優先順位、そして方式未定のコミュニティ・フィードバックという三段階からなる。
  • 公開issueは要望が記録された証拠であって、採用、予算、日程、実装またはIETFの合意を示すものではない。
  • 公開issueごとにロードマップ上の処分までを結ぶ記録を設ければ、内部ZenHub、安全情報、契約情報、個人評価を公開せずに判断経路を監査できる。

作成日は列の順番を決めない

ソフトウェアのバックログを、窓口の待ち行列のように考えると誤る。早く受け付けられた要望が、必ず先に処理されるわけではない。修正範囲が小さく見える項目が、外部API、データの整合、恒久的な運用負担を伴うこともある。逆に、新しいissueが重大な障害や保安上の問題を示す場合もある。

Datatracker issue #9204は、この差を具体的に見せる。要望は、Designated Expertという役割を個人のDatatrackerページにも表示してほしい、というものだ。2025年7月に作成され、資料締切時点の公開ページには担当者、project、milestone、relationship、branch、pull requestが表示されていなかった。

だからといって、内部で何も検討されていないとは言えない。空欄が証明するのは、公開GitHub画面に制度上の次の状態が現れていないことだけだ。8月報告によれば、この機能にはIANA向けAPI仕様、Designated Expertを個人・Area Directorの役割・リスト・複数chairなどとして表すモデル、IANAとDatatrackerのデータ照合、APIからのlive importが必要になる。単独のUI改善に見えたものが、複数のepicを含むProjectとなり、標準化プロセス、役割、個人の貢献を正確かつ包括的に記録するというGoalに接続される。

issue数は、要求の異質さを消してしまう。重複、説明不足、既存Projectへの吸収、範囲外、安全上の制限、外部依存、運用負担を区別しない。約1,100という数字は2026年8月時点の規模感を示す例であり、1,100件すべてが有効で独立したコミュニティ要求だという意味ではない。

issueが「約束」に見える仕組み

公開リポジトリでは、状態がopenかclosedに集約されやすい。しかし統治上は、その間に複数の行為がある。

受付は、何が報告されたかを記録する。triageは、確認済みか、説明待ちか、重複か、範囲外か、非公開扱いが必要かを決める。分類はGoal、Project、Epic、Taskとの関係を定める。見積もりは実装条件と不確実性を扱う。優先順位は、限られた能力を何に先に使うかを決める。さらに、資源の承認、ロードマップへの掲載、実装、release、訂正、終了が続く。

openは最初の受付しか表していないかもしれない。ところが利用者には、「問題を認めたのだから、いつか対応する」という弱い約束に見える。一方で運営側が「issueは約束ではない」とだけ答えれば、確認前、妥当だが延期、重複、統合、却下、忘却の違いが見えない。入口だけが透明で、処分が見えない仕組みは、期待を減らすどころか増やす。

必要なのは、すべて実装する約束ではない。何を約束していないかを含め、現在の制度状態を言える記録である。

2025年のロードマップは接続を欠いていた

Tools Teamは2025年12月、旧ロードマップを撤回した理由を公開した。複数四半期に及ぶProjectをphaseに分けても、各phaseの作業が明確でなかった。組織レベルのGoalと詳細Projectが混在した。さらに、各ツールのリポジトリにあるGitHub issueとロードマップ項目の間にリンクがなかった。

後継の枠組みは、Tools Teamが管理するread-onlyのGitHub projectを使い、GoalとProjectを分けた。コミュニティには、構造が必要を満たすか、計画を理解して影響を与えられる粒度か、2026年のGoalとProjectが適切かを尋ねた。公式計画を誰でも書き換えられないことと、意見を受け付けることは両立する。read-only自体は問題ではない。

ただし、進捗の状態は残った。2026年2月のExecutive Director公開報告は、ロードマップ会合への参加が比較的少なかったと記録した。参加者は全体の進め方を支持したが、関与を広げる必要があるとされた。少数参加を反対や無関心の証拠にしてはならない。母集団も、参加しなかった理由も分からないからだ。

3月には一人の参加者が、Q1完了予定の項目が順調なのか遅れているのか、どこで確認できるのかと尋ねた。一人の質問を「コミュニティの総意」とは呼べない。しかし、目標時期と現在状態の接続が見えないという問題は明確だった。

4月にはRFC Production Centerの作業を優先するためロードマップ更新が止まり、6月にも更新されず、6月中旬のretreatで計画とコミュニティ関与を議論するとされた。これは放棄の証拠ではない。複数年の運用Projectが、ロードマップ自身の改善に使う能力まで消費するという、実際の優先順位の衝突である。

8月の三段階を混同しない

Phase 1は整理である。IETF 126 Vienna後の三週間を中心に、未解決issueをGoal -> Project -> Epic -> Taskへ配置する。主な作業場所はコミュニティから見えないTools TeamのZenHubだが、公開リポジトリにリンクして結果を見せる意図が示されている。この時点で緊急項目は拾われ得るものの、大半はまだ見積もりも優先順位付けもされない。三週間で終わらず、追加sprintが必要になる可能性も報告に明記された。

Phase 2は工数の把握である。最下層Taskを実装する可能性が最も高いdeveloperが最初のLoEを出し、チームがestimation pokerで尺度を合わせる。上位の工数はTaskから合算し、許容する最大サイズを超えるTaskは分割する。これは計画上の推定であって、個人の成績表でも納期の保証でもない。

Phase 3は優先順位と関与である。通常はGoalとProjectの層でTools Teamが最初の順位案を作り、コミュニティにfeedbackを求める。8月6日時点で方法は未定だった。したがって、コミュニティがすでに承認したとも、Tools Team案が最終決定とも言えない。

分類済み、見積もり済み、優先、資源承認済み、予定、実装中、release済みは別々の状態である。この違いを画面に残すことが、三段階の価値を決める。

feedbackは票ではなく証拠である

IETFのツールは、文書提出、Working Group、review、ballot、会議、メール、RFC記録など、標準化活動の入口と履歴を支えている。利用者が現場の障害を伝える意味は大きい。歴史的なTools Architecture and Strategy Teamも広いconsultationを求めた一方、個別ツールの実装、保守、運用はTools Teamに残すとした。

ここでコメント数を順位にすると、見える要求が勝つ。保安更新、framework移行、database整合、サービス継続は、人気機能ほど反応を集めない。経験者がworkaroundで問題を隠している場合も、新参加者だけが同じ不便を何度も負う場合もある。会合の参加者数やreactionは、影響を受ける全体の分母にならない。

feedbackでは、影響するworkflow、頻度、severity、対象role、回避策、継続性への影響、外部期限、根拠URLを受けるべきだ。その後、Tools Teamは公開可能な処分を返す。分類変更、延期、他Projectへの統合、範囲外、安全上の制限、順位据え置きなどである。すべての意見を引用する必要はないが、何が判断を変え、何が変えなかったかは説明できる。

公開するのは内部ボードではなく処分経路

issue-to-roadmap記録には、元issue、作成日、最終triage日、現在の担当roleを置く。確認待ち、確認済み、重複、superseded、範囲外、security-sensitive、closedを区別する。安全な範囲でGoal、Project、Epic、Taskをリンクし、依存とblockerの種類を示す。

見積もりはband、基準日、confidenceを持つべきだ。依存が未解決なら「未見積もり」と明記する。優先順位もclass、決定日、現在のauthority holder、短い理由を持つか、「未決定」と書く。空欄は柔軟性ではなく、読者に推測を委ねる状態になる。

feedbackについては期間、channel、求めた証拠、分母の限界、総合した処分を残す。ロードマップ状態とtarget rangeは実際に承認された後だけ表示する。release、終了、統合、訂正は後続のstateとして追加し、過去を上書きしない。

この記録は計画システムから自動的に投影する必要がある。手作業の別台帳を作れば、GitHub、ZenHub、ロードマップという三つの現実がすぐにずれる。

非公開にすべきもの

説明責任は、ZenHub全体の公開を意味しない。内部メモには仮説、脆弱性、exploitの経路、個人情報、契約条件、担当者ごとの負荷が含まれ得る。個人名付きの工数を公開評価に使えば、見積もりは防御的に膨らむ。

必要なのは制度状態の安全なprojectionである。security-sensitiveな項目は、公開版が制限されていること、次の責任role、次回の安全な更新時期だけを示せる。契約依存は詳細条項ではなくprocurement blockerと表せる。チームで校正したLoEを公開し、個人の能力評価は出さない。

また、この記録が新たな決定機関になってはならない。Tools Teamは初期順位案を作る。Executive DirectorとIETF LLCは行政、契約、資源に関する権限を持つ。Boardには戦略的監督がある。コミュニティは証拠を出し、理由を問い直せる。技術標準の権限はIETFの既存手続に残る。記録は権限の所在を示すもので、権限を発明するものではない。

情報源

  1. August Tools Update
  2. Introducing a new roadmap framework
  3. Public Executive Director Report, 18 February 2026
  4. March tools update discussion
  5. IETF tools update 2026-04
  6. June tools update
  7. The Tools Team
  8. Tools Architecture and Strategy Team
  9. RFC 8711
  10. IETF Administrative Strategic Plan 2020
  11. Datatracker issue #9204