プレインズウォーカーになろうって話じゃないよ！ミーティングだよ！
1. チケットを使おう
大抵のまっとうな開発では、タスク管理ツール (バグトラッキングシステムと言ったりいろいろですが) が導入されています。
通常、殆どの作業はこのツール上にあるタスク、チケットで管理されています。
大抵の報告、連絡、相談のたぐいはこれで済みます。何かあったときは (そうするなという命令がないなら) 今やっている作業のチケットに記録しましょう。
そもそもミーティング自体がチケットベースで進んでいく現場も珍しくありません。
現状がチケットへ記載されているなら、それに越したことはないのです。
Excelで書くのだけはやめましょう。よっぽど込み入った表が必要ならともかく、ちょっと箇条書きにしたり、スクリーンショットにMSPaintで書き込めば済むものをExcelで書くのはいくらなんでもおさるさんです。
2.箇条書きを使おう
時間は有限です。
まずあらかじめ、いくつかの項目に分けて、言うべきことを箇条書きにしておきましょう。
予めこれをチャットやなにかで投げておくことも有効です。割とこれで解決します。
私の場合、概ね以下の項目に分けています。
- わからないこと
文字通り、現在の知識や資料ではわからない、断定できないこと。
「仕様のここがいまいちピンと来ない」というのはここ。ここからバグが見つかることもよくあります。 - 迷っていること
設計や実装のパターンをどういう方向に向けたほうがよいかなど、あまり具体的でないし重要度も低いこと。
「うーん、なんか引っかかるなあ」はここ。 - 判断が必要なこと
具体的な選択肢があり、その内容がサービスや仕様に関わるのはここ。
「今ここにこれこれこういうのがあるんですが、このまま行くとこういう問題があります。仕様を修正すれば対処できますが……」なんてのはここ。 - 共有したいこと
対処済みの問題やちょっとした気付き。
「このライブラリ、こういう時の挙動が妙でした。注意が必要かも」なんてのはここ。
3. どういうミーティングか確認しよう
ミーティングの形は、発言者と予定時間で決まります。
ミーティングの形に合わないことをするといろいろグダグダになります。
※ 以下の類型は私が勝手にそう呼んでるだけであり、あまり厳密な/体系立ったものではありません。
A. 相談型
だいたい数人レベルまで 一人あたり時間: 10分前後
一番ありがたいミーティングです。なんでありがたいかって、管理側からすると一番手間のかかるミーティングだから。
だいたいは 1on1 で20～30分、または数人規模の小さなチームが 1時間、ぐらいの規模になります。
こういうときは本当に楽です。
2. に書いたような内容を片っ端からかき集めてじっくり相談しましょう。ソースや資料を持ち込めるとなおよいです。
ただし、なんらかの高度な (営業的な/政治的な/人事その他的な) 判断が必要な場合、この形のミーティングでは即座に解決しないものです。
そういった内容が含まれそうなら、ミーティングを待たずにさっさと相談しましょう。
B. 共有型
数人～十人規模 一人あたり時間: 5分前後
よくある普通のミーティングです。
重要なのは、解決法や善後策を相談するような時間はないと意識することです。
このため、発言を求められた時、相談したいことがあるなら、問題の概略を話した上で「あとで相談させてくれ」としてさっさと終わりましょう。
あなたが一分短く済ませれば、皆の一分が節約されます。
C. 報告型
えらいひとあいて
……この記事「新人プログラマ向け」なのでそうそうないと思うんですが、たまにあるんですよね……営業に連れて行かれたら何故か先方の偉い人が出てきたとか……
とりあえず、黙ってましょう。そして、先輩社員に頼りましょう。
その上で、できるだけ聞いて、何を言われそうか先回りで考えてみてください。運が良ければ「おっ、こいつ、デキるな……？」と評価されます。
よっぽどアレな会社でなければ、偉い人相手に、新人をフォローもなしにぶち込むような真似はしないはずです。されたらなんかもう危ないので辞めていいです。
4. できるだけミーティングの外に追い出そう
ミーティングで最も重要なことは、ミーティングに持ち込まなくてよいことをミーティングから追い出すことです。
その「設計の相談」、ミーティングじゃないと駄目ですか？
その「実装の質問」、ミーティングじゃないと駄目ですか？
……「ミーティングの時ぐらいしか相談先が捕まらない」？
そりゃあ、その事自体をミーティングでぶち上げるか、もっと上位の人間に相談するべきでしょうね。