エンジニアリングマネージャーつらいよ問題への明日。

はじめに

　どうも、みなさん、こんにちは。
　妻の批判はアドバイスとモットーとする エンジニアリングマネージャー @warumonogakari こと かとうです。この記事は、Engineering Manager vol.2 Advent Calendar 2018 10日目向けに書いています。
　Advent Calendarなるものに参加するのは何分はじめてです。PCの前で どきどき・ぷるぷるしております。どうかお手柔らかにマサカリ投げのほど よろしくお願いします。
　また、エラクないのでツイートする内容は所属・関連する組織とは一切関係ありませんこと、ご承知願えればとおもいます。

　さてさて。
　今日は いわゆる「エンジニアリングマネージャーつらいよ」問題について取り上げたいとおもいます。

エンジニアリングマネージャつらいよ問題 あるある

　エンジニアリングマネージャつらいよ問題を整理すると、まず ざっくり以下の3点が「あるある」なのではないかとおもいます。

• まず一体なにをするのかもやもや
• 相手が計算機ではなく人間
• ずっとエンジニアでありたかったのに お気持ち

　いかがでしょうか？
　これらは すべて頼まれた時点です。頼まれた時点で このもやもやした気持ちが整理できないまま「お前のほかに誰がいるんだ」「やってもらわないと困る」といった塩梅で「うん」と言わされる。

　つらい。
　つらいですよね。

　あと、しばらく続けていくと こんなこともありそうです。

• どうやら 世の中ベースの価値につながっていないスキルのようだ。
• この役割に特化していくと いつしか役に立たたなくなるのでは？

　この中のスキルの一つが いわゆる社内政治に対するスキルになるとおもいます。たしかに 社内政治にたいするハウツー本があるにはあるのですが、それがエンジニアリングとは全く関係ないことが記載していて、

• ずっとエンジニアでありたかったのに お気持ち

をさらに大きくします。
　つまり、

• 機能不全をおこしている状況を是として、社内政治のなかで生き抜く、そのためにエンジニアを捨てる

か

• べつの誰かに社内政治をおしつけて エンジニアといわれている役割に特化する

の2者択一を迫られていると感じるから、「つらい。。」とおもうですよね。

　わかります。
　わかりすぎです。

　しかも、だいたいこれらのもやもやを 社内の先輩に相談すると いらだちともに「何をいっているんだ！」的に言われる。
　無理もありません、そもそも彼らだって社内政治で生き抜くのを選択している方々なんですよ。もやもやに向き合えないまま現在に至っているのです。それなのに、いきなり 無邪気な後輩に いまさら そのもやもやに向き合え的に質問されたらどう思いますか？

　そう。
　実は、かれらだってつらいのです。。

　わたしもかつてそうでした。

　実のところ わたしは会社を２回かえています。いずれも社内状況の変化、社内政治の方向性と自分のキャリアが合わないことが明白になったのが契機でした。現在も、社内政治に関しては真田パパな感じでやっています。¹

#真田丸 今週の予告で昌幸が「源三郎、源次郎、ワシはどこでまちがった？」となげいてましたが、武田家滅亡以降、これまでの放送で昌幸が決断してきた内容を振り返ってみましょう。あなたが昌幸ならどこからやり直しますか？ pic.twitter.com/o2qEXJaaSi

— 攻城団??公式 (@kojodanjp) 2016年5月8日

　社内政治の件は、正直、真田パパ以上の解決策は見いだせないので、真田丸のビデオをみることをお勧めします。
　で、ここでは、社内政治による機能不全が小さい前提で、最初の３つのエンジニアリングマネージャ問題のあるあるについてお話とさせてください。

まずなにをするのかもやもや

　そもそも エンジニアリングマネージャーとは何をする人でどういった役割をもっているのでしょうか？

　わたしはエンジニアリングマネージャーの役割とは「エンジニアリングチームの価値をより大きくすること」だとおもっています。²

　では、エンジニアリングチーム（以下、単にチームと略）の価値は何で定まるのでしょうか？
　まず一つはいうまでもなく ソフトウェアやそれにかかわる設計情報ですね。テストプログラムに代表されるテストももちろん含まれると思います。これらは事業に直接結びつく資産となります。
　もう一つは、事業に結びつかないが観測可能なもの、チームメンバの行動だとおもいます。行動によってチームの習慣や開発体験が培われ、それがいわゆる組織の文化となっていきます。よい習慣や開発体験をもったチームはよいソフトウェアを生み出す可能性が高く価値の高いチームと言えます。
　これらが観測可能な output です。

　では、チームにoutputがあるとなると、チームへのinputはなんでしょうか？
　ひとつは、過去培ってきた資産、すなわち過去のソフトウェアやそれにかかわる設計情報が inputになります。その際、基盤となる開発環境やハードウェアもinputの一つですね。世の中で使われている資産、OSSも inputとなるとおもいます。
　もうひとつは、チームメンバ自体と、そのメンバがやってきた過去のチームの行動・体験です。よくエンジニアリングマネージャーの仕事の一つにメンバの採用があげられることがありますが、チームに優れたよいメンバを inputできればチームの価値は向上することが期待できるからです。またメンバが過去経験してきた開発体験も重要です。どんなにメンバが優秀でも事業にかかわる開発体験をしてこなければ一から学習していく必要があり、最初から高いoutputは期待できませんよね。

　最後に重要なのは、チームへのフィードバックだとおもいます。どんな outputが価値があるのか、どんな行動がよいのか・あるいはわるいのか、それに基づいて何が習慣化されるのか、エンジニアリングマネージャーは的確にフィードバックをおこない、チームとともに学習し成長していく必要があるとおもうのです。

　以上、これらを図にしてまとめると以下のようになります。

　このように図解化することで、エンジニアリングマネージャの役割、すなわち、開発チームのシステムをマネージする際のポイントがみえてきます。
　たとえば、行動の機敏性をあげようとすれば、行動の input のバリエーションを増やすように働きかけたいところだし、行動を深化させるなら、フィードバックにある強化スイッチにて 深化の内容を最大化させるように働きかける必要がありますよね。
　また 真ん中にあたるところがエンジンリングチームとなりますが、この組織構造の初期値をどのようにおき、そして変化を促すアルゴリズムはどうしておくよいか。けっして正解がない活動であるけど、その検討が必要となります。

　で、以上のことを設計することが、エンジニアリングマネージャの一番重要な役割じゃないかと考えています。
　過去・現在のチームへの inputが変化せず、強化スイッチも場当たりなら、チームの習慣はつらいままで固着、つらい開発体験が習慣化し、チーム自体が悪い意味でのレガシー組織になります。
　逆に、チームをよりよくするため 適切なinputをあたえ、強化スイッチも適切なタイミングと最適なフィードバックを制御できれば、きっとよい意味での組織となりシステムとなるのです。
　このように、チームをよい組織・よいシステムとしていくのが、エンジニアリングマネージャのお仕事なのではないでしょうか。

相手が計算機ではなく人間

　エンジニアリングマネージャーつらいよ問題のうち、もう一つのつらい問題とは、相手が計算機ではなく、エンジニアリングチームつまり人間にかわることですね。
　数年取り組んできてやっと計算機のことソフトウェア言語のことがわかってきた。そんな中、今度は人間を相手にしないといけない。計算機の場合、必ず正解がある。期待通り動かなければプログラマ、つまり貴方（貴女）が直せばよい。ところが人間の場合、まず期待通り動かないこともままあることですし、直せといってもどこをどうするのかさっぱりわからない。そもそも直すようにうながすことはできても、実は直せるようなものですらないのかもしれません。
　ここら辺がジョブチェンジとか「ドラゴンクエストで例えると、戦士が僧侶に転職したようなものなのでLV1からのスタート」³と言われる所以なのでしょう。
　ジョブチェンジなら、本来ならプログラミング業務にかけてきた同様のトレーニングが必要となります。ところがどういうわけか ことマネージャーとなると 全くトレーニングなし・武器もなしの状態で実践につっこまれる。これでつらくないはずはありませんよね。

ここでトレーニングがない背景には、エンジニアリングマネージャーにとって取得しておく必要があるスキル、とくに人間の心理にかかわるスキルがまだ未熟で体系だっていないことにあると思っています。
　たとえば、心理学といえば、みなさん思い浮かべるのは フロイトやユングのような精神分析ではないでしょうか？
　実は、ここ数十年、心理学も様々な方向で研究され、人間の行動に着目したシステム思考のアプローチ、たとえば、

• 認知行動療法
• 家族療法
• メンタライゼーション

といった手法が提案されています。筆者の理解では、テストにたとえると、精神分析がホワイトボックステスト、これらの行動に注目した手法はブラックボックステストに相当するもののようです。
　メンバの行動をよりよくするためには、まず これらの手法をとりいれるのがよさそうのですが、筆者の場合まだまだ勉強不足で体系だった位置づけをおこない理解・試すところまで至っていません(
誰か一緒に勉強しませんか？ (^^))

　ただ、かわんじ@学習の心理学本執筆中さんが、学習のための心理学について、すばらしいモーメントの形でまとめてくださっているので下記に示します。

成長とアジャイル、ふりかえり、機械学習あたりに興味がある人は、きっとおもしろいと思う。 https://t.co/wZGHEl8McK

— 福々亭ひろにゃんこ (@warumonogakari) 2018年11月16日

　これらは、きっと新人などの育成に参考となるとおもいますので、ぜひ参照していただければとおもいます。

ずっとエンジニアでありたかったのに お気持ち

　以上、エンジニアリングチームを図解したものと、その中でのマネージャーの役割を説明し、相手が計算機からチームメンバという人間にかわることを説明してきました。

　いかがでしょうか？
　たしかに、機械を直接相手にする必要はなくなりますが、チームの価値を最大化するという課題にたいしエンジニアリングすること自体にかわりがないことに気づかれたかとおもいます。
　そうなんです、決してエンジニアを捨てることにならないのです。むしろ事業に直結する存在としてシステムをマネージする、そういうエンジニアだととらえればよいのです。

　しかも。
　機械学習をすこし勉強された方はお気づきになられたでしょう、エンジニアリングチームの学習と成長モデルは機械学習モデルそのものです。決して機械学習の知見をそのままもってくることはできませんが、考え方はもってくることができます。機械にかわって人間を構成要素に学習モデルを試しては壊す そんな実験ができるのです。

　これって、たのしくないですか？ (^^)

おわりに

　以上、エンジニアリングマネージャーになっちゃった人むけに、

• エンジニアリングマネージャーつらいよ問題、頼まれた時点でのもやもや3点の洗い出し
• それぞれに対してこんな方向性でやってみたら ええ感じになるんとちゃう？
• 別に、エンジニアを捨てることはないのだよ

というお話をしてきました。

　ところで。
　すこしだけ話がそらします。
　実は、わが家に娘のようにかわいがっている二匹の猫がいます。このうち、おねえさんは 普段から その大きなお目目でじっと観察し、ほんと実によいタイミングでパパである わたし、ママである妻を 動機づけ うまくうごかします。

　彼女の動きをみていると、マネージャーの仕事の1割は実験準備で7割は観察なんだなと つくづく思います。どうやったらパパママがスムーズに動くか実験し観察している。当然 ねこなので 一日の大半は寝ていて労働時間はすくないようにみえます。

　このように、マネージャーの時間の大半は実は観察にさくのが理想なんだろうとおもいます。

　だから、エンジニアの皆さん。
　マネージャーがひなたぼっこして うつらうつらしていても、実はああ観察に勤しんでいるだとおもって 生暖かく見守ってくれないでしょうか？

　以上、なにかしらの参考になれば幸いです。

　ではでは、よい開発体験を。

　次回は、紫苑(@grwth1009)さんです。コミュニティ運営でおきたことをなにか書いてくれるそうです。楽しみですね(^^)

謝辞

　このような楽しい Advent Calendarなる機会をつくってくれた ゆのんさん、daichi hirokiさんに感謝します。

1. 自分が草刈正雄さんみたいな悪い顔したイケメンだとおもうと楽しいですが、現実はただの悪い顔したおっさんです。 ↩

2. たとえばエンジニアリングマネージャーという仕事について - kobakei's blogの記事参照。 ↩

3. @TAKAKING22さんの記事 意識低いエンジニアリングマネージャーを目指してやったことからの引用です。 ↩