今のチームで仕事をやり始めて2ヶ月半が過ぎました。
その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。
自分の立場
中途入社でしたので、チームが携わっていた業務、またその業務に関するプロダクトへの知識は低い状態でした。
チーム自体はあまりメンバーは出入りせず、しばらくの間、この業務、プロダクトに関わっている状態でした。
職位としては上長にあたる立場で、期待されている役割としては引っ張っていくことが存在していましいた。
この2つの自分の状況が良いように影響し、うまく情報の伝達ができました。さらに改善できそうなプロセスやよりうまくやるためのボトルネックまで見つけることができました。
伝える側の話
私に情報や状況を伝えてくれる当初からいるメンバーの視座で見てみます。
日常的に忙しいと、後から入ってきたメンバー(今回の場合だと私)に業務や決まり事などを説明する時間が十分確保できないことがあります。
十分確保できないと「ここにあるから後は見ておいて」と、伝達を端折ってしまい、相手の理解度が不十分なまま日常の業務を進めることになります。
不十分なまま業務を進めると、アウトプットの質が十分でなく手戻りが起きることも多くあります。
今回の状況では、伝える相手は職位が上ということもあり「この人、わかっていないなぁ」と思いながらも丁寧に伝えようとしてくれました。
#もちろん「上長だから」丁寧に伝えてもらえるというわけではなく、聞き手の態度や姿勢なども関係しているとは思います。
この時間をとって、より丁寧に伝えようとすると、伝える側もあまり意識していなかった暗黙知が表出化してくることもあります。
この表出化の過程で、これまでなんとなく続けてやっていたけど、面倒、複雑なやり方であることに気づくこともあります。面倒や複雑なプロセスはムダやムリがあることも多くあり、改善するポイントでもあります。
「伝える」という行為を通じてこのような改善するポイントが見えることもメリットの1つだと感じました。
本来であれば相手が誰であれ、そのような暗黙知やムダなプロセスが明確になれば嬉しいのですが、なかなかうまくいかない経験をした方も多いと思います。
聴く側の話
伝えてくれる相手が職位的に上の場合だと、説明されている内容に違和感を覚えてもなかなかしつこく質問して聞けないこともあります。
またその業務やプロダクトに対する聴く側の経験が浅かったりすると、そもそもそのような質問を思い至らないかもしれません。
今回の場合、私が業務、プロダクトそのものの経験は少なくても、エンジニアとしての経験はそれなりにあったので、その経験と照らし合わせた上で伝えられた内容に対して質問や疑問を持って話をすることができました。
結果として、聴く側の動きによっても、先に書いたように暗黙知やムダなプロセスが明確になりました。
聴く側としては「聞くのが恥ずかしい」「こんなこと聞いたらバカにされるのでは？」といった自分をよく見せようとする気持ちが強くあると、知ったかぶりな態度を取ったり、表面的なことのみでわかった気になったりして、うまく情報を伝達できないということもあります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: davis.steve32 via Visualhunt.com / CC BY
コメント