デザイナーが「エンジニアのためのマネジメントキャリアパス」を読んでみた

会社の同僚が「エンジニアのためのマネジメントキャリアパス」をおすすめしていて、デザイナーだけど読むことにした。

なぜそう思ったのかというと、普段接しているからか、純粋にエンジニアのキャリアに興味があったからだ。

もちろんそれだけではなく、わたし自身が最近マネジメントをする側に回った、というのも大きい。

おそらく、デザイナーにも当てはめて横展開できることも多いのでは？と思っていて、実際にその通りだった。

共通点としては、デザイナーもエンジニアも手を動かすのが好きで、スペシャリストかマネージャーかの分岐があるところだろうか。

そして、デザイナーもエンジニアも、マネージャーをやりたがる人は少ない。わたしの主観によると。

そんなわけで、ざっと読んでみて、印象に残った部分について書き留めておく。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

1on1をセラピーの場にしてはいけない

第4章「人の管理」の中で、1on1の進め方のタイプと、注意事項について書かれていた。

いくつかのタイプの中で、わたしが普段行っているのは「キャッチアップ型」と呼ばれる手法に当てはまる。

話す内容のToDoリストは用意せず、相手の話す内容に対して、ひたすら傾聴するというやり方だ。（もちろん、接する人や、場合によっては内容を決めているのだけれど）

この「キャッチアップ型」で気を付けなければならないのは、相手に共感するあまり、不満や愚痴に対してひたすら同情するというものだ。

これでは、ただの心理療法（セラピー）のような状態になってしまう。

わたしの場合、まさしく思い当たるフシがあったので、ギクリとさせられた。

ついつい相手の話に共感してしまい、一緒にドンヨリした気分になるだけでは、仕事のためにはならない。

問題に対して、どうすれば解決に向かえるか、そのためにわたしが支援できることはあるか。

そのようにして、相手の問題解決を支援したり、正しい壁打ち相手になれるようにしていきたいと思った。

プレイヤーとしての機会は自分で見つける

第5章「チームの管理」の中で、エンジニアリングリードの動き方についての話が書かれていた。

エンジニアリングリードになるとコードを書く作業に費やす時間は減るが、チーム全体の作業の進行を遅らせたり妨げたりしなければ、小規模な技術的成果物の作成（バグ処理やちょっとした機能の作成など）に携わるべきである。

そういえば、マネージャーになるにあたり、上司から次のようなことを言われた。

マネージャーは、作られた環境を受け取る側ではなく、自ら環境を作りに行く側の人であると。

マネージャーになったからといって、急に人格が変わるわけでもないし、依然として「つくること」が好きだ。

とはいえ、これからはそういった機会すらも、自分で作っていかなければならない。

たしかに、ひとつのチームの中にがっつり入って、プロダクトオーナーやエンジニアとわいわい仕事をする楽しさからは遠のいてしまう。

しかし、違う視点で見れば、自分の裁量で動ける範囲は広がったので、やりようによっては何でもできるとも言える。

半年くらい前に、社内の管理画面のデザインを片手間でやったことがあったが、普段絡まないエンジニアと仲良くなるきっかけにもなって楽しかった。

これからは、プレイヤーとしての機会は自分で見つけるのだと、意識して動いていきたい。

デザインの仕事が恋しくてたまらない？

一番グサっと刺さったのは、第6章「複数チームの管理」の中の、「CTOに訊け」というコラムの一説だ。

現場のエンジニアから管理職に転じた人やほぼ例外なく「この進路変更は間違いだったんじゃないだろうか？」と自問を重ねる過渡期を経験するものです。

まず、ありがちは話かもしれないがプレイヤーからマネジメント側に行ったときに思うこの気持ち。

それに対して、コラムの中で、CTOは次のように書いている。

ですから「技術畑にいた頃はシンプルでよかったなあ、相手といったらコンピュータだけ。ややこしくて面倒な人間様のお世話なんてしなくてよかったんだから」と思うのも無理はないのです。

これに似た「昔を懐かしむ気持ち」を、社会人になって大人の日々がどういうものかわかり始めた頃に、学生時代を振り返って抱きませんでしたか。

これはもう、グサグサ刺さりまくりだった。

わたしも、ちょっと仕事で大変だなと感じる度に、これに近いようなことを思ってしまっていた。

ああ、ソフトウェアを相手にしたUIデザインの方が、楽しかったな。すぐに成果として見えるし、格好いいし。

しかし、そういった感情を「学生時代へのノスタルジーと同じ」と指摘されてしまい、情けない気持ちでいっぱいだ。

本当に、人を相手にした仕事は大変だなと思うのが、「こうでこうで、こうだからこう」という直線的な問題解決のアプローチが通用しないところだ。

UIデザインをしていた時は、そのようにして問題を紐解きながらデザインしていたが、組織となると話は変わる。

実にたくさんの要素がかかわっており、それぞれが自己組織化し、互いに影響を与え合って複雑系を形成しているのだ。

そのため、目先の表出した問題だけを見ていてはだめで、全体像を正しく捉えなければ本質的な問題解決には向かえない。

こうした大変さから、わたしもつい、やっぱりプレイヤーのままでいたいという気持ちになる。

しかし、すぐに「やっぱり向いてないや」と思ってしまうのは、ただの逃げなのかもしれない。

つらいなと思ったら、上の言葉を自分に投げかけて、深く考える癖をつけたいと思う。

おわりに

この本の優れているところは、本の冒頭でも紹介されているが、いつものオライリーの技術書のように、リファレンスとして使えるところだ。

テックリードからCTOまで、一歩一歩階段を上がるような形で書かれているので、今の自分の状況と照らし合わせて読むことができる。

そして、わたしが冒頭で書いたように、デザイナーに置き換えて横展開する形でも読めるのでおすすめだ。

一定の年数デザイナーとして勤めて、マネジメントという言葉がちらついてきたデザイナーの方にとっては、役に立つ内容が書かれている。