チームメンバーと1on1をしていた時, チームメンバーとの相談についての話になりました. 例えば, ある機能を実装するとき, A案, B案, C案があって, それぞれメリデメなどがあって, どれにするべきか悩ましい... という時がありますよね. そういう時, (内容なチームメンバーの様子など, 時と場合によりますが)より良い案を選びたいので, チームメンバーに相談することがあります.
そういう時, 予めドキュメントを書くようにしています(会社ではScrapboxを使っているので, これに書くことが多いです). 自分の場合, 物忘れが激しいのでノー準備で行くと何を話せばいいのかわからなくなるのと, 後はドキュメントに相談内容をまとめることで, いわば｢一人で壁打ち｣のような状態になって, より良いアイデアが浮かんできたりするのが嬉しいところです.
そういった行いをしていると, ｢相談の型｣みたいなのができてきます. 自分の場合, だいたいこういう感じです.
- 前提: どういうタスクをしているのか, 関係するドキュメントやIssueの紹介
- 課題: そのタスクで, どのような問題に直面しているのか
- 解決案: どのような解決案が思いついているか, 概要とメリデメの共有
- 私案: 解決案の中で, 自分が良いと思う案とその理由
この辺りをまとめておくと, 相談された側としてもドキュメントを見るだけで様子がわかって, 回答しやすくなる気がします(相談のミーティングを開かず, 非同期にドキュメントにコメント書くだけで事足りたりもします. 同期的なミーティングはお互いの時間拘束するので, 非同期で済ませられるのはありがたいですね).
ところで書いていて, これ論文っぽい気もしますね, と思いました. 論文も, 前提を紹介して, 課題を述べた後, 解決案を提案/評価して, 結論を出す(先の相談の型では, 結論が私案の提案になるのかな)... と捉えると似ている気がします.
そう考えると, まだ読んだことないのですが, ｢理科系の作文技術｣とか読んだら, 実はこういう相談の場でも活きてくるんじゃないか? という気がしました. ちょっと読んでみようかな...
