フランスの医療保険会社Alanの意思決定に関するこの記事を、何度も読み返しています。要するに、会議を予約する代わりにGitHubのissueを開いて、文章で議論を戦わせるという話です。自分もチームをマネジメントする立場になったので、今回はきちんとメモを取りました。以下は彼らの仕組みの要約に、私のコメントを混ぜたものです。
Alanが会議を見限った理由#
出発点は誰にでも覚えがあるはずです。誰も準備してこない、開始は遅れる、そして声の大きい人が正しかろうが間違っていようが議論を制する。1時間後には入室前より頭が混乱していて、鎮痛剤の残りを気にしている。
Alanもまず会議の改善を試みました。最大15分、明確なアジェンダ、必ず決定を出す。それでもダメでした。議論は脱線し、何が話されたか誰も覚えておらず、欠席者やリモートの人は蚊帳の外。それで、丸ごと文章に移すことにしたそうです。
彼らの主張には頷けるものがあります。書くとなると立ち止まって考えざるを得ないので、議論はより丁寧に、根拠のあるものになる。すべてが記録に残り、うろ覚えに頼らなくて済む。弁論大会でもなくなる。しかもフォーラムは全社に公開されているので、たまたま会議室にいた人だけでなく、誰でも議論に参加できます。
社内フォーラムとしてのGitHub#
フォーラムの正体はGitHubです。本来コードレビューのためのプラットフォームを、Alanは堂々と転用しました。仕組みは拍子抜けするほど簡単です。
- GitHubのアカウントを作る。
- コードの入っていないプライベートリポジトリを作る（Alanでは「Topics」という名前）。
- 会話を分類するためのラベル体系を用意する。
- Issuesタブを使う。openなissueは進行中の議論、closedは決定済み。
彼らのissueは17,000件を超えました。開かれずに済んだ会議の数と考えると相当なものです。そして私が一番惹かれるのはここですが、すべての決定について「なぜそうなったか」を検索できる履歴が残ります。過去の決定を蒸し返したくなったら、前回どの議論が勝ったのかを先に読めるわけです。
いつissueを開くか#
すべての決定がissueに値するわけではありません。彼らのフィルターは4つの質問です。誰が影響を受けるか？どれくらい可逆的か？どれくらい急ぎか？決めるためにもっと文脈が必要か？
大まかには、影響が大きく後戻りしにくい決定はフォーラムへ、それ以外はSlackで済ませます。ワンウェイ・ツーウェイの区別も使っています。ワンウェイの決定（撤回に大きなコストや労力がかかるもの。例として挙がっているのは料金の値上げ）はフルコースの文章化。ツーウェイの決定（安く取り消せて、失敗しても多少エネルギーを失うだけのもの）には儀式は不要です。
LOCI：誰が何をするか#
すべての議論に、LOCIモデル（Lead、Owner、Consulted、Informed）で役割を割り当てます。
Leadは決定の成否に責任を持ち、決定の背景がチームに正しく理解されるようにします。冒頭で自分がどこまで関与したいかを表明し、あとはOwnerを信頼してチームの成果に責任を持ち、強く反対のときだけ口を出します。Leadは議論ごとに1人だけ。
Ownerは最終決定を下し、プロジェクトを前に進めます。貢献者に情報が行き渡り、期限内に意見が集まるようにし、問題を調査し、issueを開いて閉じ、決定を共有します。自分で解決できない壁に当たったらLeadに相談します。Ownerも決定ごとに1人。
Consultedは、トレードオフの判断に本当に意見が必要な人たちです。期限内の貢献が義務で、「追加することはありません」の一言でも構いません。決定が大きく間違っていると思ったら警鐘を鳴らし、最悪の場合はLeadにエスカレーションします。Alanはこの人数を6人程度までに抑えています。それ以上はスケジュールが犠牲になるからです。
Informedは、たいてい決定後に知らされるだけの人たちです。コミュニケーションは一方通行で、何の貢献も期待されません。誰に知らせるかは、影響範囲を考えてOwnerが決めます。
issueの解剖図#
どのissueも同じテンプレートに従います。思考が研ぎ澄まされるうえ、ジュニアメンバーへの「問題の分解の仕方」の教材にもなっています。
- Scope - 議論の「なぜ」。地味に効くのが「このissueは〜については扱わない」の一文
- Context & materials - 過去の議論や資料へのリンク
- LOCI - 誰がLead、Owner、Consulted、Informedか
- 期限 - 貢献の締め切り、issueを閉じる日、解決策が必要になる日
- 解決策の提案 - 推す案をひとつ、または選択肢をいくつか
- 質問 - 特定の人に向けて、特定の仮定を確認・反証するための質問。issueを「海に流すボトルレター」にしないための工夫です
議論を停滞させないための書き方のルール#
文章の議論も、口頭と同じくらいダラダラと長引き得ます。だからルールがあります。まず簡潔に。彼らはボワローの「よく構想されたものは明晰に語られる」を引いています。シンプルに書けないなら、まだ自分の主張に確信がない証拠です。それから、書いたものすべてに「So what?」テストをかけること。コメントの含意が自明でないなら、はっきり書き添えます。
Ownerにとっては、開いた後の運営も同じくらい重要です。議論を「100万ドルの質問」、つまり本当に重要なたったひとつの争点に向け続け、細部の海で迷子にさせない。合意できた点とまだ開いている点を定期的に整理して見せる。そしてSlackでの催促は最後の手段。貢献の遅延か、本当の緊急時に限ります。
Ownerは会話を前に進めないコメントを非表示にすることもあります。また、見出し、脚注、表、キーボードショートカットといったGitHubの書式機能は全員が使いこなす前提です。文章では、中身と同じくらい見た目が物を言うからです。
コンセンサスなし、傍観者なし#
この仕組みが「委員会による決定」に堕ちないよう、2つの歯止めがあります。
1つ目。Ownerは、Alanいわく「啓蒙専制君主」として決定します。アイデアを調査し、リスクを測り、同僚に質問はするけれど、コンセンサスは求めないし、言われたことを全部実装する義務もない。Alanは「うちは民主主義ではない」と言い切っています。全員が株主であり、チームや個人よりも会社の利益を優先する。とはいえ、孤立した拙速な決定を望んでいるわけでもありません。Ownerが「この賭けで行ける」とそれなりに確信したら決めて、みんなで試し、影響が見えてきたら振り返って次に活かします。
2つ目。貢献者の数を管理します。Jeff Bezosの「ピザ2枚ルール」は非同期にも当てはまります。人が増えるほど、1人あたりの貢献は減る。6人を超えたあたりから傍観者効果が顔を出し、参加の質が落ちるそうです。通知も同じ思想で、段階的に。全員が自分のGitHub通知を正しく設定している（Settingsで「Participating」と「Watching」の「Web and Mobile」にチェック）と信頼して、issueのQuestionsセクションでのタグ付けは最小限に抑えます。
自分が持ち帰るもの#
会議の内容を、その場にいなかった人に完全に説明することはできません。でも、書かれた決定なら誰でも読めます。Alan自身、これが最善で唯一の仕組みだとは言っていません。ただ自分たちに一番合っていた、というだけです。割り込みが減り、傍観者効果が薄れ、一歩引いて事実ベースで決められるようになった。私もチームの決定を全部GitHubのissueに移すつもりはありませんが、下のテンプレートはさっそくうちのリポジトリに入れます。
提案テンプレート#
Scope#
- このissueの目標は…
- このissueは…についてではありません