エンジニアとしての伝え方 - 室長のひとりごち

某所でトラブルプロジェクトの事例を話すことになったので、そろそろスライドを作らねばと思い、印象が強い立て直しプロジェクトを思い出しながらそのうちの１つのプロジェクトのあらましをノートに書き出してみた。

なんでもそうなのだが、いきなりスライドを作り始めてはいけない。いや、頭の中で

「何を伝えたかったのか」

f:id:fumisan:20180411080254p:plain

が決まっていて、そこに落とし込めるなら構わない。

でも、人がスライドを作るとき、思いついたことから書き出してしまうし、伝えたいことよりは書けてしまうことを仔細に書いてしまい、ある程度書いてしまった後に全体を見回して、大変な思いをして整えていくことになる。

偉そうなことを言っているが、毎回似たようなことをしているのだが。

SOLOなふりかえり

その１つのプロジェクトのあらまし、特徴、体制、関わり方、出来事、対処などを書き出すと今でもプロジェクトで関わったアクティビティのいくつかを鮮明に思い出すことができる。

多くのことは忘れてしまったが、多分にストレスを感じていたか、アドレナリンが出ていたかはわからないが、パッといくつかのシーンを思い出すことができる。

１ページにざざっと書き出した後、見返してみると、割とすごいことをしていたな、と思う。トラブってからの立て直しの対策のことだ。

多分、今なら、トラブルの直接原因は防止できないだろうが、トラブルを部分的には極小化はできるかもしれない。

なぜ、トラブルの直接原因を防止できないかと言うと、原因がプロジェクトチームの外にあるからだ。外部依存というやつだ。ただ、それを識別することと行動を取るタイミングは、ループする世界線に紛れ込んだとしてもそのくらいはできるだろう。

ひとり、平日の夜にソファーに寝そべって、プロジェクトの振り返りをしているのは稀有な感じもしないではないが、なかなか発見があるものだ。

あらましをページに書くと8割方が、半ばプロジェクト説明のようなものになっている。8割のうち、その半分はトラブルの説明と対処だ。

トラブル事例に興味を持つエンジニアは少なくない。だから、それに時間を割けばそこそこ楽しめる（内容に若干、勧善懲悪的な世界観の要素も含まれている）ので、その場的には好評かもしれない。

でも、主旨が違うのだ。2つのポイントで切り口を作らねばならない。

を書かなければならない。

そうすると、ページ書いたことは2ページ程度のスライドに圧縮し、伝えたいことと直接関連しないことは削ってしまう方がいいだろう。

ページの2割しかないところから数ページのスライドを切り口で見せ方を変え、伝えたいことを伝えなければならない。

場の聞き手には3種の立場の方がいる。エンジニア、マネージャ、第三者の立場。この方たちに費やしてもらった時間の価値に満足を与えることまでは考えていない。

必要なことは主旨を捉え、伝えたいことを伝えきることだ。

こうしたことを夜に考えるためにも平日も定時近くで変えることが必要だと思った。