概念、具体例、問いの技術
概念と具体例のバランスをとるのが大事だなあと最近思っている。
自分は抽象化して概念として示すのは得意。たくさんの具体例を見て、それらをいい感じにまとめるのは好きだし、わりと好評なことが多い。
いっぽうで、具体例の提示や、解像度の高いアウトプットは苦手。それが Developer としての成長を阻んでいそうなので、最近は意識している。
社内のアウトプットを見ていると、自分がモヤるやつには以下の傾向があることが分かってきた(これもまた「具体例をもとにまとめるアプローチ」である・・・)
具体的なケースやHowだけが書かれており、背景や根拠などの「Why」が足りない
これは社内の他の人もよく言っている。ジュニアエンジニアの設計レビューとかにありがちだからか、指摘しやすいのかもしれない。
個人的には、いちいち指摘したり、都度聞いたりするよりはドキュメントのテンプレ化などで防ぎたいなーというお気持ち。
概念の提示だけがされていて「その概念から結局は具体的に何を伝えたくて、どうしてほしいのか」が分からない
最近このパターンにモヤることに気づいた。理想論とか、キレイゴトとか、そういうふうに見えちゃうのかもしれない。
たとえば「本にはこう書かれている」と言われても(本の中に具体例があって読めば良いのかもしれんが)それをどう行動に落とし込めば良いのか分からないときがある。
ミドルマネジメントを経験した身としては、経営層がそれをやるのはまだいいんだけど、それ以外の立場なら何らかの手段でブレークダウンしていくのも仕事じゃない?って思う(そこのあなた怒らないで!このあとに反省文があります)。
正論だけでは人は動かないと思うので、主張したい論旨から、誰かに働きかける行動に落とすとか、具体的なケースを示すとよさそう。
問いの技術
ここで突然の「問いの技術」なんだけど、上記のモヤるようなアウトプットを見た時に質問で解決するアプローチが自分はあんまりできてないな、と思った。
いちいち指摘したり、都度聞いたりするよりはドキュメントのテンプレ化などで防ぎたい
こういう考えになりがちだけど、それでは「今ここで向き合っているケースに対するモヤモヤ」は晴れないので、やっぱり「なんでそうしたんですか」って聞くことが必要なときはある。
「具体的にどうしてほしいのか」のほうも、実は上記で書いた流れ自体が正論だけの構造に若干なってそうで。笑
その場その場で「具体的にどうしてほしいのか」「どんなケースが当てはまるか」みたいに質問したり、「自分はこう解釈したんですが」っていうかたちで地道に確認していくことができそう。具体例は個人名が出るので出しづらいとかだったら、ログに残らないように雑談のついでに聞いたりしてもいいかもしれない。
そういうのをうまく質問するのが「問いの技術」なんだろうな、と思った。 なんかそういう本あった気がするので探して読んどこう。