原文記事はこちら
ほとんどの企業では、意思決定のために会議を開きます。Alanでは、オンラインフォーラムで「issue」と呼ばれる書面による会話を開きます。これらの会話は、透明性、非同期性、執筆の文化の基礎です。このフォーラムの会話メカニズムをマスターすることは、すべてのAlanerにとって重要です。その方法を紹介します。
はじめに#
誰もが会議を嫌う#
誰も準備をせず、遅れて始まり、声の大きい人が正しいか間違っているかに関わらず、常に最後の言葉を持ちます。1時間後、あなたの心は入室前よりもさらに混乱しており、パラセタモールが残っているか疑問に思います。しかし、あなたはそれに慣れています。結局のところ、会議病はどんな自尊心のある企業の商標ですよね？
もし彼らが別のやり方ができると言ったらどうでしょうか？Alanでは、会議の限界とリスクを非常に早い段階で検出しました。会議は短く（15分以内）、よく組織され（明確な議題）、したがって意思決定を生み出すように設計されていました。問題は、彼らがしばしば脱線したことでした - ディスカッションをコントロールするのは難しいです。その結果、彼らはしばしば失望し、何が言われたかを覚えるのに苦労し、不在または遠隔地にいる人々との調整が複雑でした。
そこで彼らは、伝統的に口頭で行っていたことを…書面に移すことにしました！
結果：より良い意思決定を行います。なぜなら、書くことは私たちに反省する時間を与えるからです。ディスカッションはより微妙で、よりよく文書化され、議論されます。要するに、もはや雄弁さのコンテストではありません。そして、ケーキの上のアイシングは、会議を書面による内部フォーラムに置き換えることで、全員の自律性が向上することです：情報を公開することにより、ディスカッションに貢献する可能性が増加し、コラボレーションが容易になりました。
方法を知りたいですか？すべてを説明します。
1. プラットフォームをオンラインフォーラムに転用する#
現在、問題を解決するため、主題を深めるため、ソリューションを検証するためにチームの知性が必要な場合、会議をスケジュールする代わりに、オンラインフォーラムで会話（または「issue」）を開きます。このフォーラムは「Github」と呼ばれるプラットフォームでホストされています。
Githubとは何か？#
最初は、ウェブ開発者向けに設計されたコラボレーションプラットフォームです。アイデアは、彼らが作成するコードに関するフィードバックを共有し、集中化することです。
彼らは、ソーシャルプラットフォームと構造化されたフィードバック管理の間のトレードオフが興味深いと考え、Alanのすべての意思決定会話をホストするためにその使用を転用することにしました。
具体的には、どのように行われましたか？
- Githubにアカウントを作成しました。
- 偽の「コード」ディレクトリを作成し、それを「プライベート」にしました（Alanでは「Topics」と名付けました😇）
- 各会話トピックをより簡単に区別するためのラベリングシステムを作成しました。
- ディレクトリの「Issues」タブに移動して、すべての現在の「オープン」なディスカッションと、決定された「クローズ」されたものを見つけます。
💡現在、17,000件のissueマークを超えました。つまり、日の目を見なかった多くの会議と節約された多くの時間です！この知識の歴史は貴重です：各決定の詳細を理解するためにGithubで少し検索するだけです。そして、それに疑問を持ちたい場合、過去にどの議論が勝ったかをすでに知っています。
2. ルールを定義する：いつ「issue」を開くか？#
「ディスカッションを開くか開かないか、それが問題です。」効率性のために、すべての決定が体系的にissueを開くことを正当化するわけではないことを知っています。いくつかは数日で解決できますが、他のものは1週間以上かかることがあります…したがって、より良い決定をより速く行うために、彼らはシステムを開発しました。
正しい質問を自問する#
- 決定によって誰が影響を受けますか？
- 決定はどの程度可逆的ですか？
- これは緊急に決定する必要がありますか？
- 決定するためにより多くのコンテキストが必要ですか？
影響度を決定する#
一般的に、決定の影響度と可逆性の程度が重要と見なされる場合、issueが開かれます。簡単に言えば、Slackよりもフォーラムでのディスカッションを好む場合は次のとおりです：
主要な連絡先#
彼らはLOCI（Lead、Owner、Consulted、Informed）モデルを使用して、各ディスカッションで責任と対話者の配分をバランスよく明確にします。
Lead#
説明#
Leadは決定の成功に責任があります。彼/彼女は、各決定の背後にあるコンテキストがチーム内で正しく理解され、配布されることを保証します。
特徴#
ディスカッションの最初に、Ownerがすべてのカードを手に持って裁定できるように、どの程度決定に関与したいかを指定します。
ミッション#
Leadが最終的な意思決定者（Owner）でない場合、彼/彼女は次のことをすべきです：
➡️ 検討中の決定に同意していることを確認する。 ➡️ 「Owner」を信頼し、チームによって生産されたものに責任を受け入れる。 ➡️ 強い不一致がある場合に意見を表明する。
配分#
ディスカッションごとに1人の「Lead」のみが存在すべきです。
Owner#
説明#
Ownerは最終的な決定に責任があり、設定された目標を達成するためにプロジェクトを主導します。
特徴#
彼/彼女が解決できない問題に遭遇した場合、Leadに参照する必要があります。
ミッション#
指揮者として、彼/彼女は次のことをしなければなりません：
➡️ 各貢献者がディスカッションについて通知されていることを確認する（そしてタイムリーに貢献する） ➡️ 問題を調査し、回答を収集し、プロジェクトをフォローアップする。 ➡️ ディスカッションを開いて閉じる。最終決定を行い、共有する。
配分#
各決定に1人だけが責任を持つことをお勧めします。
Consulted#
説明#
「consulted」Alanersは、意思決定プロセスで意見が重要な人々です。彼らの意見は、可能な限り最良のトレードオフを行うために不可欠と見なされます。
特徴#
彼らは意思決定者（Owner）に制御を引き渡します。強い不一致の場合、彼らはアラームを鳴らし、最悪の場合、Leadに情報をエスカレートする必要があります。
ミッション#
ディスカッションへの積極的な貢献者として、たとえディスカッションに追加することが何もないことを確認するだけであっても、タイムリーに貢献する義務があります。
配分#
ディスカッションごとに6人以上のAlaners「consulted」を通知することは避けることをお勧めします。彼らの意見は重要ですが、これによりスケジュールに遅延が生じる可能性があります。
Informed#
説明#
これらは、しばしば決定が行われた後、進捗状況について通知されるAlanersです。
特徴#
これらのAlanersとのコミュニケーションは一方向です。
ミッション#
「informed」Alanerとして、彼らからの貢献は期待されていません。
配分#
意思決定者は、決定の潜在的な影響を考慮し、影響を受けるAlanersにそれに応じて通知する必要があります。
有用な定義#
さて、しかし、彼らはこの重要性の閾値をどのように評価しますか？Alanは2種類の決定を区別します：
- 一方向の決定（逆転が難しい）
- これらは、逆転するには多くの努力または重大な費用を必要とする決定です。
- 例：上方修正された料金の更新（彼らはすでにそれを下方修正していますが）
- 双方向の決定（簡単に可逆的）
- これらは、一見、あまりリスクを伴わない決定です。予期しない出来事はエネルギーの損失につながる可能性がありますが、これは許容されます。
「問題解決」アプローチを採用する#
プロジェクトやディスカッションをフレーム化することは、より良い決定を下すのに役立ちます。
フレームワークは作業ツールであり、思考を禁止しません。それどころか、それらは私たちが視点を構造化し、明確化することを可能にします。
問題や決定についての考えをできるだけ効果的に伝えるのに役立つように、各issueは同一のテンプレートを提供します。この構造により、ジュニアの人々に問題を分解する方法を教えながら、さらに1レベル進むことができます。
issueの典型的なアーキテクチャ#
- 「Scope」 - 範囲を定義し、ディスカッションの「なぜ」を明確にする
- 「この結果の目的は…」
- 「このissueは…についてではありません」
- 「Context & materials」 - コンテキストと有用なリソースを提供する
- コンテキストを提供するディスカッションやドキュメントへのリンクを追加します。
- 「LOCI」 - 責任と連絡先の配分を明確にする
- Lead
- Owner
- Consulted
- Informed
- 期限を設定する
- ここで期待を共有します：貢献する期限、issueを閉じる日付、ソリューションを見つける必要がある日付。
- ソリューション提案を共有する
- ここで問題に対する潜在的なソリューションを説明するか、選択するいくつかのソリューションを提案します。
- 質問に対処する
- 十分な情報に基づいた決定を下すのに役立つ意見と参加を持つすべての人が参加するように招待されます。議論を正しい方向に進めるために、ディスカッションリーダーは主要な貢献者に特定の質問をして仮定を確認または反証します - そして海に瓶を投げることを避けます。
- 十分な情報に基づいた決定を下すのに役立つ意見と参加を持つすべての人が参加するように招待されます。議論を正しい方向に進めるために、ディスカッションリーダーは主要な貢献者に特定の質問をして仮定を確認または反証します - そして海に瓶を投げることを避けます。
書面で自己主張する#
決定を取り巻く議論が長引くのを防ぐために、彼らはディスカッションを本質に焦点を合わせるためにいくつかのルールを採用します。
より効果的に書く#
- 簡潔で明瞭にする
- 彼らは有用な執筆を信じています：「よく考えられたものは明確に述べられる」とBoileauは言いました。単純な方法で何かを書き留めることができない場合、それは声明の正確さを確信していないことを意味します。
- 「So what?」テストを適用する。
- 何かを書くたびに、彼らはそれを読み直して自分自身に「So what?」と尋ねます。これは、メッセージの意味や議論をよりよく理解するのに役立ちます。答えが明白な場合、それは潜在的な質問により明確に答えるのに役立ちます。
フォローアップ#
- 「Million Dollar Question」に焦点を合わせる
- 多くの異なる意見を集めることは混乱を招く可能性があり、最も重要な問題やスティッキングポイントに焦点を合わせることは、優先順位に焦点を合わせ、詳細の海で迷子にならずに同僚の貢献を再焦点化するのに役立ちます。
- 定期的に合意点を要約する
- 集団的に合意されたことと、まだ議論する必要があることを明確にすることは、Githubの会話のownerにとって一般的な慣行です。それは同僚に貢献ラインをよりよく見えるようにする方法であり、また、優先順位の低い問題に焦点を当てた往復を避ける方法でもあります - 会話の目標は常に従うべき北極星であるべきです。
- 最後の手段としてSlackで再起動する
- 彼らはSlackでのリマインダーの数を制限します。2つの例外：貢献が遅れている場合、または緊急性が迅速な行動を必要とする場合。議題が尊重されることを確認するために、ownerが十分な情報に基づいた決定を下すために視点を比較する必要がある場合、Slackでのリマインダーを使用できます。
- 彼らはSlackでのリマインダーの数を制限します。2つの例外：貢献が遅れている場合、または緊急性が迅速な行動を必要とする場合。議題が尊重されることを確認するために、ownerが十分な情報に基づいた決定を下すために視点を比較する必要がある場合、Slackでのリマインダーを使用できます。
無関係なコメントを非表示にする#
- 一部のスレッドには多くのコメントがある場合があります。ownerとして、会話を進める貢献のみを保持することが役立つ場合があります。
フォーマットをマスターする#
- 書面で視点を伝えることになると、実質は形式と同じくらい重要です。Githubフォーラムを最大限に活用する方法は次のとおりです。
- キーボードショートカット
- 時間を節約するために、Githubのキーボードショートカットの完全なリストは次のとおりです。
- ページレイアウト
- タイトル（H1、H2、H3）、脚注、さらにはテーブルを追加してアイデアに本文を与えることがGithubで可能です。指示の完全なリストは次のとおりです。
- キーボードショートカット
落とし穴を避ける：非同期的に決定する#
issueシステムを使用すると、誰でもすべてのディスカッションに参加できます。ささやき、秘密、政治はありません：誰もが同じ情報を持っています - しかし、失望を避けるために心に留めておくべき特定の前提条件があります。
コンセンサス意思決定を避ける#
Alanでは、フォーラムで議論されるすべての決定には、「啓発された専制君主」として決定する責任を持つ単一の指定された「owner」がいます。
彼女の役割は、コンセンサスを求めることなく、政治なしで、会社にとって可能な限り最良の決定を下すことです。これを行うために、彼女は革新的なアイデアを調査し、リスクを測定し、データを分析し、同僚に疑問を投げかける必要がありますが、言われたすべてを実装する必要はありません。
会社では、意思決定はコンセンサスではなく、彼らは「民主主義」ではありません。誰もが株主であり、したがってAlanのownerです。各Alanerはチームまたは個人の利益よりも会社の利益を優先します。しかし、彼らは孤立した、性急な、または情報に基づかない意思決定も望んでいません。
決定のownerが正しい賭けをすることに合理的に確信している場合、彼は決定し、彼らは試みます。その後、影響がより明確になり始めると、彼らは彼らが下した決定を振り返り、将来さらに良くする方法を見ます。
貢献者の数を制限する#
効果的な決定は、主要な貢献者の見解に制限されているものです。Jeff Bezosの「2枚のピザまたは何もない」ルールを知っていますか？彼のアイデアはよく知られた事実に基づいています：会議に人が多すぎると、それは非効率的です。非同期意思決定はこのルールの例外ではありません：一般的に、人が多ければ多いほど、彼らの貢献は少なくなります。遠くでは、この一般的な参加を阻害する「傍観者効果」は、issueへの貢献者の数が制御されていない場合（6人を超えると複雑になります）、参加の質を変更する傾向があります。
段階的な通知アプローチを採用する#
ノイズを作成することにより、通知は重要なものと些細なものを識別することを困難にします。そのため、彼らはAlanで段階的な通知ルールを適用します：彼らは互いに信頼します。彼らは、すべてのAlanerが通知を受けるためにGithubアカウントを正しく設定していると仮定します。したがって、彼らは各issueの「Questions」セクションで人々のタグの数を制限します。
通知を受け取るためにアカウントを設定する#
- 「Settings」ページに移動します
- 「Participating」および「Watching」セクションで「Web and and Mobile」ボックスをチェックします
最後の言葉#
最善の意志があっても、そこにいなかった人に会議で起こったすべてを説明することは困難です。しかし、チームの誰もが決定に関連付けることができます。
明らかに、フォーラムを通じた意思決定のシステムは、この問題に対処するための最良または唯一の可能なソリューションではありません：それは単に次の理由で私たちに最も似ているものです：
- 彼らは中断を制限します：不適切な会議と関連する通知の洪水にさようなら。
- 彼らは傍観者効果を減らします：抑制された参加と出席主義にさようなら。
- 彼らは決定の質を改善します：一歩下がって事実的であることを歓迎します。
提案テンプレート#
Scope#
- このissueの目標は…
- このissueは…についてではありません