最近、社内の同じ開発チームの人とのコミュニケーションに悩むことが多く、見かねた先輩がこの本を勧めてくれた。
実はこの本は前にも一度読んだのだが、その時は何の課題意識も感じていなかったのか大して頭に残っていなかった。それが今回もう一度読んでみると、とても大きな学びの連続だった。

この本では、1章は自分自身の中の考え方について、2章は1対1でのメンタリングについて、3章以降はチームの作り方について扱っている。今回は 普通の仕事術とは異なるエンジニアのチームならではの振る舞い方を学び直す のが目的だったので、2章まで読んだ。

不確実性を減らす

まず最初に、エンジニアリングの意義として 不確実性を減らす というキーワードが挙げられる。
ソフトウェア開発は、最終的な成果物の具体性が他の仕事に比べて極めて高い。企画案や資料であれば解釈するのは人間だが、ソフトウェアはコンピュータによって動かされるものであるため、曖昧な部分が少しでも残っているとバグや仕様のズレに直結してしまう。そのため、エンジニア同士やステークホルダーとの間にある情報の非対称性や認識のズレに気を配らなければならず、これを解消するために密なコミュニケーションが必要になる。
振り返ってみると、自分の会社の強いエンジニアたちは不確実性の存在にとても敏感であり、不確実性を増やす言動(チケットにコメントを残さない、自分が書いた処理の理由を説明できないなど)にはとても厳しい。それが後から自分たちの首を絞めかねないからだ。

観測可能なもので判断する

これも不確実性の話に通じる。ソフトウェアが正しく動いているかをテストやログを通じて判断するように、自分が何か振る舞い方を変えるときも、変化を観測できるようなやり方をしなければいけない。例えば「心がける」「がんばる」というのは本当なのかどうかを観測できないが、「具体的に何かの行動を変える」ところまで落とし込めれば、周りからも変化が見えるようになる。

メンターの役割

不確実性と観測可能性という考え方は、メンター・メンティーが1on1をするときにも役立つ。メンティーが何か問題を抱えているとき、メンターがやるべきなのはその問題に答えを出すことや同情することではない。問題を分解していくことで不確実性を減らすこと、そして観測可能な形で行動を変えるようメンティー自身に考えてもらうことがメンターの役割である。
（ちなみにこれをメンターなしで一人の力でできる人は、速いスピードで自然に伸びていく。とはいえそこまでできる人は、自分自身を含めてほとんど見かけない）

コミュニケーションスタイルを変えていこう

自分はもともとエンジニアではない別の職種として今の会社に入った。そのときは、一つのプロジェクトは1-2ヶ月ほどで、メンバーは自分と多忙な上司だけであり、相談に行くときは入念に準備したうえで慎重に機会を伺っていた覚えがある。
しかし技術で問題解決をするチームの場合、一つの複雑なソフトウェアを長い時間をかけて共同で作りあげていく。そのため、コミュニケーションの小さなすれ違いが、不確実性を大幅に増やしてしまう。エンジニアという仕事は「コミュニケーションが苦手でも技術力があればやっていける職業」というイメージを持たれがちだが、実は他の職種以上に周りとの対話や気配りが必要な、とても人間臭い仕事であることがわかった。
この本を読んで、自分がエンジニアになる前のコミュニケーションスタイルをまだ予想以上に引きずっていたことに気付かされた。苦手なところではあるけれど、少しずつ変えていきたい。