概要

複数プロダクトで共有しているコーディングガイドラインが機能しない。その原因は技術的な問題ではなく、組織構造にある。元記事の「mdベースのナレッジ管理は大企業で通用するか？」を起点に、自組織の課題を構造的に整理する。

「作る人 ≠ 使う人 ≠ 管理する人」問題

元記事の指摘で最も刺さったのがこれ。個人やSmall Teamのナレッジ管理が機能するのは、作る人・使う人・管理する人が同一だから。

共有ガイドラインでは：

  • 誰の責任か不明 — 両プロダクトとも「自分が主管」と思っていない
  • 文脈が違う — プロダクトごとに技術スタック・フェーズ・優先度が異なるのに、一つのルールで縛ろうとしている
  • 更新インセンティブがない — 変更したい側が「もう片方と合意する」コストを払いたくないので放置される

合意形成コストが技術コストを圧倒する

ガイドラインの内容を改善すること自体は難しくない。難しいのは合意を取るプロセス：

  • ボトムアップで提案するが、2〜3層の承認が必要
  • 非同期で決定できない（会議体での合意が前提）
  • 後半になって「やめましょう」が出て、提案者のモチベーションが下がる
  • 次の提案も出なくなる → 運用崩壊ループ

解決の方向：合意が必要な範囲を小さくする

元記事のStage 1「島を作る」Stage 2「島同士をつなぐ」がヒントになる。

やること 合意が必要？
自チーム内でコーディング規約を決める 不要
自チームのPRレビューでそれを適用する 不要
共有ガイドラインを廃止・変更する 必要

ポイントは 誰の承認も要らない行動だけで構成する こと：

  1. 自チームのプロダクトで「こう書く」というルールをチーム内だけで決めて実践する
  2. 共有ガイドラインを「廃止する」とは言わない。自チームの補足ルールとして運用する
  3. 実績ができたら「うちはこれでうまく回ってます」と見せる

共有ガイドラインには触れないから反対されようがない。実質的に自チームのガイドラインが「生きたルール」になり、共有版は自然と参照されなくなる。

まとめ

  • 共有ガイドラインが機能しないのは、内容の問題ではなく責任構造の問題
  • 「全社統一」を先に作ろうとすると合意形成コストで頓挫する
  • まず「島」を作り、合意なしで変えられる範囲を既成事実として積み上げる

参考