こんにちは、システムチームのKです。
業務中、部下から相談を受けることがあるのですが、
自分はそれらに返答する際に、「技術的」な話をしがちです。
例えば、
「デザインカンプのこの部分を再現したいのですが、CSSを書いてもうまくいきません」
こういった相談を受けたときは、
まず自分なら「どうやって対応するかな」、を考えてから
今の部下のやり方との違いがどこかを見て、
○○ではできないので、××でやればできるよ。
という伝えかたをしています。
でもそれって、
ほとんど「答え」になっているんですよね。
「答え」であることの何が問題かというと、
わからないときは相談すれば、
「答え」がもらえる
という誤った前例ができてしまうことです。
ここは学校ではありませんから、
そんな前例は作ってはいけません。
業務中か業務外か
業務時間外であれば、どんどん技術的な話をメインにすればいいと思います。
それ自体がコミュニケーションのきっかけになったり、
自主的な勉強会なんかは、
技術の話をお互いに共有しあったりする形が多いですよね。
でも業務中はきちんと住み分けをしなければいけなくて、
会社がコストを払っている状態です。
相談に対応する時でも、
今後部下が「自走」して仕事を進められるようになるよう、
育成を考えて答える必要があります。
解決策につながる考え方を伝える
できないことがあっても、
大抵のことは広いインターネットの海から調べて、
解決策を導き出すことは可能なはずです。
インターネットで無理なら、本を使って調べたりもします。
やっていることは上司も部下も変わりないはずなのですが、
大きな違いは、クリティカルな「答え」を求めに行っているかどうか
だと思います。
例えばデキテルのCSSでカンプを再現できない要素があるときに、
こう書けばOK！みたいな答えはまず見つかりません。
デキテル独自のセレクタ指定や
先に読み込んでいるCSSの都合がありますからね。
だから上司側はこうすれば「なぜ解決するのか」という目線で
情報を得ています。
そうすると今後類似の問題に直面したときにも
自分で考えることができます。
いわゆる「自走」している状態です。
そして、次はさらにレベルの高いところの相談が発生する。
そこでまた解決できることの幅をひろげて成長する。
良い循環が出来上がります。
部下の相談に乗るときも、
「技術的」な話をするのではなく、
「なぜ解決するのか」という根本の部分を伝えるようにします。
