この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の9日目の記事です。8日目の記事は当社が誇るデータサイエンティスト tymob の「必要なデータの量は？90%の精度を出すためには？データサイエンスあるあるQ&A」でした。

ニフクラの事業企画やアライアンスを担当している 浜中( kei_hamanaka )です。

今回はエンジニアリングマネージャーとしてメンバーと相互理解を深めるために使ってきたフレームワークを紹介します。

私は元々Webサービス事業でエンジニアをしていたのですが、クラウド事業に異動し全く知らないチームにマネージャーとして joinしました。そこで、新しいメンバーのことを理解する「とっかかり」がほしいと思ってこの方法を使いだしたのですが、手軽で効果も高かったので、1 on 1 の初回によく使ってきました。

組織が大きくなってメンバーが増えたり、新しいチームをマネジメントする事になったマネージャーの方はぜひ使ってみてください。必要なものはホワイトボードとペンだけで事前準備も不要です！

好き/嫌い/得意/苦手のマトリクス分析のやり方

1 on 1の中で会話をしながら、ホワイトボードに十字の線を書き、それぞれの先端に好き/嫌い/得意/苦手と書きます

次に担当業務がどこに当てはまるかを書き出します。以下のようなイメージです。以下の例はタスクの抽象度が高めですが、実際はもっと具体的なことを書く方が良いです（Aシステムの開発は得意で好きだけど、Bシステムの開発は嫌いで苦手など）。

これだけです。簡単ですね。ポイントはあまり考えすぎないことなので、事前宿題で書いてきてもらうよりは、その場で10分くらいでライブ感を持ちながら一緒に書き出すほうが、よりその人らしさが出る気がします。

私のスタイル：
雑談的に業務の話をしながら出てきたキーワードを本人にどこに位置するか決めてもらい、「このあたりかなー」とやりとりをしながら私が書き出すことが多いです（考えることに集中してもらうため）。

効果

自分自身の可視化
スキルを棚卸しして可視化することで自分自身を知ることができ、今後のキャリアを考えるきっかけにもなります。なぜAは得意なのにBは苦手なのか？使っている言語の違い、過去のコード資産、メンバーとの相性...と深掘りすると色々見えてくるものもあります。

相互理解
また、その業務が相手にとってどういう意味を持つのかを可視化することでお互いに理解を深めます。また、新しい仕事をお願いする際も、その仕事がその人にとってどういう意味を持つのか把握できます。

メンバーの性格を知るきっかけ
マトリックスの使い方にも性格が出るので、その人の人となりを知ることにも繋がります。極端に苦手なことが多い/得意なことが少ない（謙遜してたり自己評価が低めだったり）、キーワードの粒度が荒かったり（業務内容をあまり具体化出来ていないケース）、様々です。

自己評価が低いケース

業務理解度が低いケース

（やる気がないだけという気もする...）

1 on 1 で実施する場合、同僚のマトリックスを見ないで自分の言葉で書いていくのでその人らしさがそのまま出ることが多いです。

応用編：2人で書く

また、一緒に仕事をしたことがあるメンバーの場合は、本人の自己申告マトリックスの隣に、自分（マネージャー）から見たマトリックスを記載をしていくと、自分から見た自分と人から見た自分の対比がみえて面白いです。

例えば過去の経験では「調整作業」が苦手できらいな場所に書く人が多かったですが、マネージャーから見ると非常に上手だったりするケースもあり（得意で嫌いなパターン）、自分で気づいていない強みを発見する機会にもなります。

私のスタイル：
ここで書いたマトリックスは、お互い記憶に残すだけにして、写真を撮ったり、マトリックス自体は残さないようにしています（本人が残したいといった場合は除く）。特に若手メンバーの場合、位置づけは経験とともに変わるのであまり過去の気持ちに囚われすぎないようにするためです。

ただ、定期的に実施して過去との差分を把握してみることは自己分析に有効だと思いますので、1 on 1のネタとして年に一度実施するなどしてみても面白いかもしれません。

注意

一点注意したほうが良いことは、ここで作ったマトリックスをマネージャーが「改善」に使おうと思わないことです。きらいなことを好きになってもらうということは非常に難しいですし、パーソナルな事柄に相手に踏み込まれることをよく思わない人もいます。

この手法は相手のきらいなこと/ 苦手なことを解消させようと考えるのではなく、本人が自分の強み弱みを可視化したり共有することに意味があります（嫌い/苦手と思っていることは、逆に本人が重要視しているポイントだったりします）。

改善的な提案を行う場合も、お互いに信頼貯金が溜まってから行うべきで、関係が出来ていない状態ではあくまで相手を理解をすることを主眼に置きましょう。

信頼関係ができる前にこういうことをしない

というわけで

こういうことを一緒に考えていきたいマネージャー志向のエンジニアも、こういうことをやりたくないテックリード志向のエンジニアも募集していますので、ぜひご応募ください！いや、本当に！

さて、明日は jinshi の「Operation as a code に向けた運用用統合ライブラリの作成活動について」です。おたのしみに！