Alanが会議を見限った理由

#

出発点は誰にでも覚えがあるはずです。誰も準備してこない、開始は遅れる、そして声の大きい人が正しかろうが間違っていようが議論を制する。1時間後には入室前より頭が混乱していて、鎮痛剤の残りを気にしている。

Alanもまず会議の改善を試みました。最大15分、明確なアジェンダ、必ず決定を出す。それでもダメでした。議論は脱線し、何が話されたか誰も覚えておらず、欠席者やリモートの人は蚊帳の外。それで、丸ごと文章に移すことにしたそうです。

彼らの主張には頷けるものがあります。書くとなると立ち止まって考えざるを得ないので、議論はより丁寧に、根拠のあるものになる。すべてが記録に残り、うろ覚えに頼らなくて済む。弁論大会でもなくなる。しかもフォーラムは全社に公開されているので、たまたま会議室にいた人だけでなく、誰でも議論に参加できます。

社内フォーラムとしてのGitHub

#

フォーラムの正体はGitHubです。本来コードレビューのためのプラットフォームを、Alanは堂々と転用しました。仕組みは拍子抜けするほど簡単です。

1. GitHubのアカウントを作る。
2. コードの入っていないプライベートリポジトリを作る（Alanでは「Topics」という名前）。
3. 会話を分類するためのラベル体系を用意する。
4. 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に移すつもりはありませんが、下のテンプレートはさっそくうちのリポジトリに入れます。

GitHubのissueテンプレートとして使う

#

フォーラムとして使うリポジトリに.github/ISSUE_TEMPLATE/decision.mdとして保存しておけば、誰かが新しいissueを開くたびに、GitHubがこのテンプレートを選択肢として出してくれます。セクションの構成はAlanのもので、LOCIの行とラベルは私が足しました。

---
name: 意思決定
about: 決定を提案して、意見を文章で集める
title: "[意思決定] "
labels: decision
---

## スコープ
- このissueの目標は...
- このissueでは...は扱いません

## このissueを開いた理由

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## 期限
- 意見の締め切り:
- 決定日:

## 背景と資料

## 提案

## 質問

GitHub IssuesとGitHub Projectsの使い分け

#

GitHubをもっと広くプロジェクト管理に使おうと考えているなら、この2つは役割が違うと押さえておくと楽です。Issuesには議論が残り、閉じたあとはそれがそのまま決定の記録になります。GitHub Projectsは、1つ以上のリポジトリのissueの上に重ねるボードや表で、ステータスや担当者、期限といった独自のフィールドを持たせられます。Alanのような意思決定フォーラムなら、ラベルとissue一覧で十分です。Projectsを足すのは、開いている決定を、決めなければならない日付順に1画面で並べたくなったとき。それから、開発の進捗も同じ場所で追い始めたときです。たいていのチームは、結局そこで両方を使うことになります。

「進捗どうですか？」と聞かれて嬉しい人はいません。とはいえ、仕事でプロジェクトを率いる立場としては、進捗を知らないわけにもいきません。私の妥協点がGitグラフです。誰かに聞く前に、まずグラフを見る。たいていの場合、答えはすでにそこにあります。コミットの動き、ブランチ、マージがひと目で分かり、そのために誰も会議に出る必要がありません。

グラフから実際に何が読めるか

#

じっくり見たことがない方のために説明すると、ノードひとつがコミット、枝分かれした線がブランチで、全体がプロジェクトの時系列になっています。このレイアウトには驚くほど情報が詰まっています。

• 一瞥するだけで、アクティブなブランチの数とコミットの頻度が分かります。
• 急に静かになったブランチや、何週間もマージされていないブランチは、たいてい誰かが詰まっているサインです。この早期警告には価値があります。
• マージの頻度はチームのコラボレーションの形を映します。マージが頻繁なら作業がきちんと統合されている証拠で、長生きしすぎたブランチは、孤立した作業になっている可能性が高いです。

中断は減り、会話は良くなる

#

分かりやすいメリットは、誰の作業も中断せずに状況を把握できることです。それ以上に効くのは、いざ会話が必要になったときです。推測ではなく、グラフから話を始められます。「このブランチ、火曜日から動いてないけど、何か詰まってる？」は、「進捗どうですか？」よりずっとましな切り出し方です。

ルーチンを明示しておくのも効きます。私の場合は、ほぼ毎朝さっと眺めて、週に一度じっくり見る。チームもそのリズムを知っているので、誰も驚きません。

監視ツールにしないこと

#

ここは自分にも言い聞かせ続けている部分です。コミット数は価値ではありません。よく考えられたコミット1つが、騒がしいコミット50個に勝つこともあります。すべてのコミットが見えるからといって、すべての判断に口を出していいわけではない。チームを信頼して、パターンが本当に怪しいときだけ介入する。そしてグラフを会話に持ち込むときは、フィードバックの出発点として使うこと。検察側の証拠にしてはいけません。

ターミナルでグラフを表示する

#

必要なのはGitだけです。

git log --graph --oneline --all --decorate

それぞれのオプションの意味は次のとおりです。

• --graph：左側にブランチとマージの線を描きます。
• --oneline：1コミットを1行で、短いハッシュとメッセージの1行目だけ表示します。
• --all：今いるブランチだけでなく、リモートを含むすべてのブランチとタグを表示します。
• --decorate：ブランチ名やタグ名を、それが指すコミットの横に表示します。最近のGitは出力先がターミナルなら何もしなくても表示しますが、このオプションを付けておけば、パイプで別のコマンドに渡したときも消えません。

毎朝これを打つのは面倒なので、エイリアスにしておきます。

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

長く続いているリポジトリだと、グラフ全体はいつまでもスクロールが終わりません。絞り込む方法をいくつか挙げます。

git graph --since="2 weeks ago"    # 直近2週間だけ
git graph -20                      # 直近20コミットだけ
git log --graph --oneline main..feature                # featureにあってmainにまだないもの
git log --graph --oneline --left-right main...feature  # 両側を < と > で区別して表示

最後の2つは2つのブランチの比較です。エイリアスではなく素の git log を使っているのは、--all が入っていると他のブランチまで全部戻ってきてしまうからです。ドット2つは「feature にあって main にないもの」を表示します。ドット3つに --left-right を付けると、お互いに相手にないものを両側とも表示するので、長生きしているブランチがどれだけ離れてしまったかをすぐ確認できます。

VS Codeでグラフを表示する

#

VS Codeにはグラフが標準で入っています。ソース管理ビュー（Ctrl+Shift+G）を開くと、そのパネルの中に「Source Control Graph」のセクションがあります。バージョン1.93（2024年8月）からの機能です。初期状態では今のブランチとそのリモートを表示し、グラフのタイトルバーにあるブランチ選択で他のブランチを追加できます。さっと眺めるだけなら、これで十分です。

すべてのブランチを一度に見たいなら、mhutchie氏のGit Graph拡張を入れます（拡張機能ビューで「Git Graph」を検索）。開き方は、ステータスバーの「Git Graph」、ソース管理ビュー上部のGit Graphアイコン、またはコマンドパレットの Git Graph: View Git Graph (git log) のいずれかです。コミットをクリックすると変更されたファイルが見られ、あるコミットをクリックしてから別のコミットをCtrl/Cmd+クリックすると2つを比較できます。ただ、この拡張は2021年からリリースが止まっているので、標準のグラフも知っておいて損はありません。

Git Graphのボタンが出てこない場合は、拡張機能がリポジトリを見つけられていない可能性が高いです。初期設定では開いたフォルダそのものしか探さず、サブフォルダまでは見に行きません。リポジトリのフォルダを直接開くか、設定で git-graph.maxDepthOfRepoSearch の値を上げてください。

その他のツール

#

たいていのGitツールには、どこかにグラフがあります。gitk --all はGit自身の履歴ブラウザです。GitHub、GitLab、Bitbucketには、リポジトリページに「ネットワーク」や「グラフ」のビューがあります。デスクトップクライアントでも、SourceTree（Atlassianの無料ツール）、GitKraken、Tower、WindowsならTortoiseGitに、どれもグラフ表示があります。

どれを選んでも、目的は同じです。進捗を理解すること。コミットを数えることではありません。

これまで巻き込まれてきたプロジェクトの混乱は、ひどいコードが原因だったことはほとんどありません。必要な情報が、手遅れになるまで必要な人に届かなかった——原因はたいていこれです。仕事でプロジェクトリードを任されるようになってから、「もし自分がCTOの席に座ることになったら、コミュニケーションをどう回すか」というメモを書き溜めています。今回はそれを公開してみます。

誰に何を知らせるかを決める

#

地味ですが土台になるのはコミュニケーション計画です。誰に知らせる必要があるのか、どんな情報を、どのくらいの頻度で、どのチャネルで届けるのか。プロジェクトの開始時に必ず作り、担当者の名前まで入れておくべきだと思っています。「全員の仕事」になったコミュニケーションは、結局誰の仕事でもなくなりますから。ステークホルダーも同じです。誰が本当にこのプロジェクトを気にかけているのかを整理し、それぞれが好む報告のされ方を把握しておく。CEOに、開発チャンネルと同じ内容の報告を送ってはいけません。それから、明文化したルールをいくつか。返信の目安時間、何を「緊急」と呼ぶか、どのチャネルを何に使うか。「コミュニケーションの問題」の正体は、口に出していない期待のすれ違いであることがほとんどです。

ソフトウェア開発プロジェクトのコミュニケーション計画サンプル

#

私ならまずこれを用意して、プロジェクトに合わせて手を入れていきます。行は会議ごとではなく、伝える相手ごとに分けています。

表の下には、先ほどの明文化したルールを、できるだけ平易に書き添えます。「緊急」とはリリースか顧客を止めてしまうもののことで、そのときはメッセージではなく電話する。質問はチャットに、決定事項はトラッカーに。返信は1営業日以内。意思決定ログには意思決定文書を使っていて、作業のすぐ隣に置けるようにGitHub Issuesで管理しています。

この手の計画がうまく回るかどうかは、2つの点で決まります。どの行にも最後の列に必ず誰かの名前が入っていること。そして経営層への報告を口頭ではなく文章にすること。文章なら、そのまま転送しても何も抜け落ちません。

ツールとリズム

#

ツールは、世間で議論されているほど重要ではありません。チャットはSlack、タスク管理はTrello、顔を見て話したいときはZoom。チームに合うものを選んだら、さっさと先へ進めばいい。それより大事なのはリズムです。アジャイルなら毎日のスタンドアップ、サイクルが長いなら週次の報告。そして決めたリズムをちゃんと守ること。あとは、書き残すことです。決定事項、変更、アクションアイテムをNotionやJiraへ、後付けの作業ではなくプロセスの一部として記録する。半年後、みんなの記憶に残っているのはドキュメントだけです。

柔らかい部分こそ難しい

#

ここまでは仕組みの話です。難しいのはその先で、今のコミュニケーションが本当に機能しているかをチームに聞き、機能していなければ変えること。メンバーの育成もそうです。チームにはいろいろなバックグラウンドの人がいて、うまく回っているプロジェクトを見たことがない人もいます。話す順番を待つのではなく、きちんと聴くこと。衝突は小さいうちに早めに扱うこと。しかも、この手の問題は一度解決したら終わり、にはなりません。前の四半期にうまくいっていたやり方が、いつの間にか効かなくなる。定期的に見直すしかありません。

分散・非同期の開発チームで働くということ

#

リモートや非同期中心のチームなら、このトークは観る価値があります。

自分がこの全部を完璧にできているかというと、そんなことはありません。誰にもできないでしょう。ただ、これまでスムーズに進んだプロジェクトはこの大半が揃っていて、痛い目を見たプロジェクトは少なくとも3つは欠けていました。