2020年のミーティングベストプラクティス

仕事でミーティングを主催するようになって、かつて自分が感じたミーティングに対する不満をすべて解決しようと試行錯誤してきた。昔作ったミーティングへの不満を箇条書きしたものが出てきたのでアップしておく。笑ってしまう勢いがある。

• アジェンダがない
• 議事録がない
• 議論がループする
• 会議に関するファイルが見つからない
• 合意形成の経緯がわからない
• 発言の少ないメンバーの意見が反映されない
• 後からSlackで意見が投げられる
• メンバーによって使える時間がまちまち
• リモート参加も多く現地メンバーとすれ違いがち

この件を友達と話したところ、みんなさも当たり前のようにミーティングをしているけど、誰にもミーティングの仕方を教わったことないし、勉強してないよねって話題になり、それもそうだなぁと思って改めて調べてみて色々試してきた。その結果たる現時点の川鍋流ベストプラクティスを共有する。リモートワークにももちろん対応している。

ミーティング 4つの原則

1. アジェンダ兼議事録を大画面で写す/共有しながら会議する
2. ホワイトボードを用意する
3. アイデアや意見を集めるときは会話を禁止して書かせる
4. ミーティング後TODOを明示する

1. アジェンダ兼議事録を大画面で写す/共有しながら会議する

アジェンダを箇条書きで書いておいて、その下に議事録を書いていく。僕が参加した会議の多くで参加者が会議冒頭で話した内容を忘れることが頻発していて、議論が繰り返される不毛な時間があった。これをすることで完全になくなる。議論のペースは少し落ちるが、目の前のタスクにより集中し、あやふやな状態が減るのでメリットが上回る。また、常に何を話しているかの意識が行き、脱線が明確化*1するのでファシリテーションもしやすい。

クラウドノートテイキングが必須の要件で以下3つなら個人的には最低水準を満たしていると思っている。順番はオススメ順。

1. Scrapbox
2. Googleドキュメント
3. Dropbox Paper

Scrapboxはドキュメント群の管理と箇条書きが最もしやすくベスト。Googleドキュメントはデフォルトのレイアウトの一覧性がイマイチだがカスタマイズで修正可能で、Dropbox Paperも同じく一覧性に欠けるがカスタマイズ不可能なので最下位って感じ。

Tips

• 決まったことは強調表示する
• カジュアルなミーティングではアジェンダの箇条書きを発展させる形で議事録にしても良い
• アジェンダ部分と議事録部分は装飾等で表現を変えても良い
• 各自のアイコンの絵文字を決めて文頭に入れると発言が分かりやすい

2. ホワイトボードを用意する

ビジュアルで表現すればすぐ伝わることを延々と話している会議、結構ある。ホワイトボードを用意しましょう。また、ビジュアルは創造性を喚起するらしいので、ミーティングのアクセントにも。

オンラインでは『Google Jamboard』 を使用している。JamboardはGoogle Driveから作成できる。

Tips

• 4人以下ならコピー用紙でもOK
• 付箋もあるといいですね

3.アイデアや意見を集めるときは会話を禁止して書かせる

適切に行わないブレストは、集団浅慮（グループシンクとも）の危険がある。アイデアや意見に多様性がほしいなら、会話をさせずに個別に作業してもらうほうが出てくる。前述のアジェンダ兼議事録を使ってもいいし、付箋にそれぞれ書いてもらっても良い。必ず時間を区切る。5分か10分。様子を見て伸ばしてもよいが、15分が限度。

Tips

• トピックについて話していると自然に議論が始まる時があるが、大きなトピックほどグッと堪えてこれを行うのがオススメ
• さらにアイデアや意見を出してほしいなら、一度ひとり数分で共有してもらってから再度やらせる
• 意見を匿名化するかどうかもファシリテーションの選択肢

4.ミーティング後TODOを明示する

決定した事項で、なんらかの行動が必要ならそれを明示化し、人に割り当て記録する。カンバンボードを使っているならその場で起票したり、カンバンに書き込んだりしても良いし、ないならアジェンダ兼議事録に書いていく。

Tips

• 絶対に決めておきたいTODOは最初にやると良い
• 最後に5分休憩して抜け漏れがないかを各自に確認してもらったりしても

4つの原則を元にしたミーティングの一例

よくあるやつ書きますね。

1. 事前にGoogleドキュメントでアジェンダ兼議事録の作成とJamboadを用意
2. Teamsで画面共有をする
3. アジェンダを元に順番にディスカッション
4. システム構成の確認でJamboardで図を描いて認識を共有する
5. Googleドキュメントでシステム構成案について意見集約を行う
6. ミーティング後TODOを確認し終わる

参考書籍

『ミーティングのデザイン エンジニア、デザイナー、マネージャーが知っておくべき会議設計・運営ガイド』

ミーティングのデザイン エンジニア、デザイナー、マネージャーが知っておくべき会議設計・運営ガイド

ミーティングをデザインの視点から一冊の本にまとめた素晴らしい本。脳やグラフ理論の知見からミーティングの制約を示しているのがエキサイティングで、特に脳の記憶の機序からミーティングの構成についてのアドバイスをまとめているところや、グラフ理論の基礎の基礎を持ち出して、ミーティングの参加者が増えると指数的に繋がりの数が増大していくから、参加者を適切に分割してグループを分けることで議論しやすくなるといった話が面白い。プレゼン資料の作り方ではなく、ミーティングに焦点を当てているところも中間成果物よりも成果への道程を重視してて良い。

『デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド』

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

僕がミーティングを明示的にファシリテーションし始めたのは、実はデザインスプリントの導入と同時だった。デザインスプリントはデザイン思考の流れを組んだ問題発見・解決手法で、1週間でそれをすべて行う、ギュッと凝縮されている手法だ。詳細は別記事に上げるけども、キックオフだったり、プロジェクトが迷走した時に役に立つ。このデザインスプリントの本では、ミーティング、ワークショップの実例を組み合わせて全体のデザインスプリントが構成されている。それぞれのミーティングやワークショップはかなり独立した作りをしているので、そのまま他の場面でも使えるし、今回のように一般的なミーティングすべてに適用出来るものを抜き出すことも出来る。デザインスプリント自体を採用しなくてもオススメできる本。

『SHIFT：イノベーションの作法』

SHIFT：イノベーションの作法

プロジェクトメンバーが大好きな本で、集団浅慮に関してはこの本から。

*1:脱線自体は悪いことではないです

AppleScriptでディスプレイ検出

※ 2014/12/09にQiitaに投稿した記事です。現在そのまま使えるかは不明です。

前提

Macって外部ディスプレイを接続しているのに認識しないことよくありますよね。そんな時はシステム環境設定でoptionを押すと「ディスプレイを検出」ボタンが出てきて、それを押すと認識されるということがしばしばあります。この「ディスプレイを検出」をスクリプトから実行するのが今回紹介するAppleScriptです。

optionを押すと、画面の右下に「ディスプレイを検出」ボタンが出現しますが、これをGUI操作のスクリプトで押してやります。

スクリプト

delayを挟んで3つのブロックがありますが、最後はシステム環境設定のウィンドウを閉じるパートなので、お好みで削除してください。

tell application "System Preferences"
    activate
    reveal pane "com.apple.preference.displays"
end tell

delay 0.5

tell application "System Events"
    tell process "System Preferences"
        try
            key down option
            delay 0.2
            click button "Detect Displays" of window 1
            delay 0.2
            key up option
        on error
            key up option
        end try
    end tell
end tell

delay 0.5

tell application "System Preferences"
    activate
    close window 1
end tell

個人的な技術マネジメントの話

乙女電芸部、初めての展覧会『乙女電芸部と札幌の冬を考えよう！展』 が札幌の札幌文化芸術交流センターというところで開催（1/8-2/11）しています。

www.facebook.com

札幌の中高生と組んで作品を作り上げたのですが、4つのチームで5つの作品があり、1チーム2作品（『パルマフラー』というヒーターが内蔵されたマフラー）を僕の担当として技術部分を見ていました。僕の担当パートは比較的早く終わったので、他チーム・作品のお手伝いもしたのですが、最近自分がやっているマネジメントに近かったので、ちょっとその辺りの技術マネジメント的な話をまとめておきます。

パルマフラーの制作風景

CTO？テックリード？技術顧問？スクラムマスター？

肩書はともかくとして、大雑把に技術的に頼りがいがあるポジションとして乙電やその他の仕事で存在しています。全体を見渡して、ちょっと詰まってそうな人がいたらその人のところに話を聞きにいってました。これはこちらから行くこともあるし、本人から来て欲しいと言われることもあります。定例のミーティングで聞くスクラム的なやり方もするし、トイレ行くついでに聞きにいったりと色々です。

「話を聞く」の具体的な中身ですが、1on1といよりはペアプロもしくはテディベアプログラミングで、大体本人に話させると5割は解決します。残り5割の時は

• 一緒にコードを見る
• タスクの優先順位の整理
• こちらが巻き取ってその人には別作業

という感じですね。

必要スキル

正直にいって難しいことをしていないつもりなのですが、かといってこれが5年前の自分に出来たかというと絶対に出来ないんです。リストにしてみると下記能力が必要。

• メンバーからの信頼
• タスクを見積もれる能力
• 全体を見渡す視野
• プロジェクトを完遂させることが出来るという自信

この中で最も重要なのは「メンバーからの信頼」で、この人に相談したら良いことがある、怒られないという雰囲気が作れたら勝ちですね。エンジニアとしては、あんまり技術そのものにこだわりがなく、マネジメントで解決するならそれでいいじゃんて方なので、こういうポジション向いてたっぽいです。

現状見えてないこと

自分自身のタスクの技術的見積もりはかなりの精度*1で出来るのですが、他の人のタスクでの見積もりが難しい状況があります。一応難しそうな時はどう？って聞いて気にしているよってシグナルは出しているのですが、それが功を奏さず、結局難しい状態のままってことが多いです。特にハードの案件だと「出来ているように見えるけど、実際は出来ていない状態」がままあって、これがスケジュール上で地雷になります。

これに関してはペアプロやモブプロがベストプラクティスだと思うのですが、リモートだとなかなかしづらいです。特に乙電のようなプロジェクトがアドホックすぎる上に固定の拠点もない場合では。もしかしたらいわゆる「作業イプ」をやるといいかもしれません。

もう一つのソリューションはレビューの改善です。レビューは「出来ているように見えるけど、実際は出来ていない状態」をあぶり出してくれるのですが、だいたいもっと早く見つけたかった！てことが多いことを踏まえると、早めのレビューを組み込みたいです。早めのレビューをする場合、全体の枠を作ってから肉付けしていく仕事のやり方を強制することになるので、丁寧な取り扱いが必要なのがネックですね。

*1:もちろん相対的な見積もりです