サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

改善 旧館より 考え方

業務の引継ぎや情報の伝達で思ったこと

投稿日:2012年9月18日 更新日:


今のチームで仕事をやり始めて2ヶ月半が過ぎました。
その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。

自分の立場

中途入社でしたので、チームが携わっていた業務、またその業務に関するプロダクトへの知識は低い状態でした。
チーム自体はあまりメンバーは出入りせず、しばらくの間、この業務、プロダクトに関わっている状態でした。

職位としては上長にあたる立場で、期待されている役割としては引っ張っていくことが存在していましいた。

この2つの自分の状況が良いように影響し、うまく情報の伝達ができました。さらに改善できそうなプロセスやよりうまくやるためのボトルネックまで見つけることができました。

伝える側の話

私に情報や状況を伝えてくれる当初からいるメンバーの視座で見てみます。

日常的に忙しいと、後から入ってきたメンバー(今回の場合だと私)に業務や決まり事などを説明する時間が十分確保できないことがあります。
十分確保できないと「ここにあるから後は見ておいて」と、伝達を端折ってしまい、相手の理解度が不十分なまま日常の業務を進めることになります。
不十分なまま業務を進めると、アウトプットの質が十分でなく手戻りが起きることも多くあります。

今回の状況では、伝える相手は職位が上ということもあり「この人、わかっていないなぁ」と思いながらも丁寧に伝えようとしてくれました。
#もちろん「上長だから」丁寧に伝えてもらえるというわけではなく、聞き手の態度や姿勢なども関係しているとは思います。

この時間をとって、より丁寧に伝えようとすると、伝える側もあまり意識していなかった暗黙知が表出化してくることもあります。
この表出化の過程で、これまでなんとなく続けてやっていたけど、面倒、複雑なやり方であることに気づくこともあります。面倒や複雑なプロセスはムダやムリがあることも多くあり、改善するポイントでもあります。
「伝える」という行為を通じてこのような改善するポイントが見えることもメリットの1つだと感じました。

本来であれば相手が誰であれ、そのような暗黙知やムダなプロセスが明確になれば嬉しいのですが、なかなかうまくいかない経験をした方も多いと思います。

聴く側の話

伝えてくれる相手が職位的に上の場合だと、説明されている内容に違和感を覚えてもなかなかしつこく質問して聞けないこともあります。
またその業務やプロダクトに対する聴く側の経験が浅かったりすると、そもそもそのような質問を思い至らないかもしれません。

今回の場合、私が業務、プロダクトそのものの経験は少なくても、エンジニアとしての経験はそれなりにあったので、その経験と照らし合わせた上で伝えられた内容に対して質問や疑問を持って話をすることができました。
結果として、聴く側の動きによっても、先に書いたように暗黙知やムダなプロセスが明確になりました。

聴く側としては「聞くのが恥ずかしい」「こんなこと聞いたらバカにされるのでは?」といった自分をよく見せようとする気持ちが強くあると、知ったかぶりな態度を取ったり、表面的なことのみでわかった気になったりして、うまく情報を伝達できないということもあります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: davis.steve32 via Visualhunt.com / CC BY

-改善, 旧館より, 考え方

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

会社を移ることになりました

2012年6月末で会社を移ることになりました。 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。 思い出1:Rubyとの出会い 入社後しばらくして …

マルチスレッド

仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 …

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設 …

【引継ぎ】タスクへの考え

 『トラックナンバー』について以前書きました。 そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。 ほとんどのプロジェクトでは、後工程に …

仕様を縦断する視点、横断する視点

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。 レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。 そこではある要求仕様が …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。