なぜ組織論が重要なのか

なぜ組織論が重要なのか

このドキュメントは、理想論を排し、エンジニアの「集中」と「自律」を最大化する組織運営の憲法として位置づけます。 目的は「管理」ではなく、面倒な報告を減らし、コードに集中できる状態を作ることです。

問題のある組織運営

1. 情報の散在

問題のある状況:

- 仕様がSlackのチャットに埋もれている
- 開発環境のセットアップ方法が口頭でしか伝わっていない
- 重要なURLが個人のブックマークにしかない
- コードレビューのルールが明確でない
- 新メンバーのオンボーディングに時間がかかる

影響:

• 情報を探すのに時間がかかる
• 同じ質問が繰り返される
• 知識が属人化する
• チーム全体の生産性が低下する

2. 仕様の周知不足

問題のある状況:

- 仕様変更が一部のメンバーにしか伝わっていない
- 変更理由が不明確
- 影響範囲が把握できていない
- 実装方針が統一されていない

影響:

• 実装の不整合が発生する
• リリース後の不具合が増える
• コードレビューで指摘が増える
• リファクタリングのコストが増える

組織論による解決（注意: 「一元管理」の幻想と「誰がメンテするの？」問題）

❌ 問題のあるアプローチ（理想論）:

- 羅針盤資料（ルールブック）を作成
- すべての情報を1箇所に集約  # ❌ 幻想: 情報は本質的に分散する
- 定期的に更新・メンテナンス  # ❌ 問題: 誰がメンテするの？そのコストは？
- 検索しやすい構造にする

🪓 マサカリ:

【指摘】「一元管理」の幻想と「誰がメンテするの？」問題があります。
【問題1: 「一元管理」の幻想】
「すべての情報を1箇所に集約」という理想論は、実務では機能しません。
情報は本質的に分散するものであり、強制的に一元管理しようとすると、
柔軟性を奪い、エンジニアの生産性を下げます。
Slackのチャット、GitHubのIssue、コード内のコメント、個人のメモなど、
それぞれに適した情報の置き場所があります。

【問題2: 「誰がメンテするの？」問題】
「定期的に更新・メンテナンス」と言っていますが、誰がそのコストを負担するのかが不明確です。
開発者の評価は納期とコード品質で決まり、ドキュメントのメンテナンスは
「やったら評価される」わけではありません。その結果、1年後には
「動かないゴミ」になったドキュメントが残り続けます。

【問題3: 「情報の負債化」への懸念】
「ドキュメントの継続的な更新」と言っていますが、実際にはドキュメントは腐敗します。
コードが変更されてもドキュメントが更新されない、古い情報が残り続ける、
「どれが正しい情報か分からない」という新たなゴミが生まれます。

【問題4: 「それ、ただの理想論だよね？」問題】
開発者のインセンティブ（納期、評価）と矛盾しています。
納期に追われている開発者が、ドキュメントの更新に時間を割くことはありません。
「ドキュメントを更新することが評価される」仕組みがない限り、
この理想論は実行不可能です。

✅ 改善されたアプローチ（実効性を重視）:

- 情報は分散させるが、「地図（Portal）」は一元化する
- 非同期で意思決定を伝播させ、会議による周知を敗北とみなす
- 更新されない資料は「ゴミ」として自動的にアーカイブする
- 仕組みに従うほど、報告が減り集中できる設計にする

具体的な解決策:

1. 地図（Portal）を一元化する

   • 情報は分散させるが、「どこに何があるか」だけは厳格に一元化する
   • 入口はREADME/Portalに統一し、検索ではなく導線で迷いをゼロにする

2. ドキュメント腐敗への自動制裁

   • 更新されない資料は「ゴミ」と明記し、一定期間で自動アーカイブする
   • アーカイブは「隠蔽」であり、現役の情報だけを前に出す
   • 評価ではなく仕組みで強制する

3. 非同期コミュニケーションを絶対優先

   • 周知のために人を集めることを「敗北」と定義する
   • Issue / PR / ADR を通じて、証拠が残る形で意思決定を伝播させる
   • 会議は「決める場」ではなく「記録を補足する場」に限定する

4. 自律の報酬を明確化

   • 仕組みに従うほど、報告・説明・確認が減る
   • 「自分のコードが誰にも邪魔されない」状態を最大の報酬にする

2. 仕様の明確な周知

解決策:

- 仕様書を明確に定義
- 変更履歴を記録
- 影響範囲を明示
- 実装方針を共有

メリット:

• 実装の不整合が減る
• コードレビューが効率化される
• リリース後の不具合が減る
• チーム全体の理解が深まる

組織論の要素

1. ドキュメント管理

• 羅針盤資料: 迷わないための入口（Portal）
• ルールブック: 開発環境やお作法をまとめた資料
• 仕様書: 機能の仕様を明確に定義した資料
• アーキテクチャ資料: システムの設計を説明した資料

2. 知識共有の仕組み（注意: 「継続的な更新」の幻想）

❌ 問題のあるアプローチ:

- 定期的な勉強会: 技術的な知識を共有
- コードレビュー: 実装の品質を向上
- ペアプログラミング: 知識の伝承
- ドキュメントの継続的な更新: 情報の鮮度を保つ  # ❌ 問題: 誰が更新するの？

🪓 マサカリ:

【指摘】「ドキュメントの継続的な更新」は幻想です。
【問題】「情報の鮮度を保つ」と言っていますが、実際にはドキュメントは腐敗します。
       コードが変更されてもドキュメントが更新されない、古い情報が残り続ける、
       「どれが正しい情報か分からない」という新たなゴミが生まれます。
       勉強会やペアプログラミングは良いですが、それらが「ドキュメントの更新」に
       つながる保証はありません。

✅ 改善されたアプローチ:

- 定期的な勉強会: 技術的な知識を共有（ドキュメント化は任意）
- コードレビュー: 実装の品質を向上（コード内のコメントで知識を共有）
- ペアプログラミング: 知識の伝承（ドキュメントではなく、実践で伝承）
- コードから自動生成できる情報は自動生成する（更新の手間をゼロに）
- 手動で管理する情報は「オーナー」を明確にする（誰がメンテするか明確）
- 更新されない情報は削除する（腐敗を防ぐ）

3. オンボーディング

• オンボーディング資料: 新メンバー向けの資料
• 環境構築ガイド: 開発環境のセットアップ手順
• チームのルール: 開発のお作法
• メンター制度: 新メンバーのサポート

まとめ

組織論が重要な理由：

• Portalの一元化: 迷いをゼロにし、集中を守る
• 非同期の徹底: 周知のための会議を排除する
• 腐敗への自動制裁: ゴミを前に出さない仕組み
• 自律の報酬: 報告が減り、コードに集中できる

実効性を確保するための原則

1. Portalだけは一元化する: 入口を一本化し、情報探索をゼロにする
2. 非同期を前提にする: 証拠が残る意思決定のみを正とする
3. 腐敗に自動制裁を与える: ゴミは前から消す
4. 自律が得をする構造にする: 報告負荷を減らし、集中を守る

適切な組織論とドキュメント管理により、エンジニア組織の生産性と品質を向上できます。 ただし、「一元管理」「継続的な更新」という理想論ではなく、実効性と持続可能性を重視した設計が必要です。