社内の読書会で「エンジニアのためのマネジメントキャリアパス」という本を読んでいる。毎週金曜日の朝に開催。何人かの EM が参加していて、ちょっと読み進めては議論して、またちょっと読み進めては議論して、みたいな感じで読み進めている。

ソフトウェアに対するエンジニアリングとチームに対するエンジニアリング

議論の中のひとつに、Engineering Manager (以下 EM) あるいはチームメンバーという感じで立場が違っていても、向き合うものが組織なのかソフトウェアなのかという違いこそあれど、基本的には「課題を発見して解決していく」というところは同じだよね、みたいな話がなされていた。なるほど分かる。課題を発見し、ボトルネックを評価し、コスパのよい解決策を考えて実行する、みたいなことは確かに同じかもしれない。

では、ソフトウェアに対してエンジニアが行う問題解決のアプローチは、はたして EM がチームに対してという形でも同じように応用できるものだろうか、できるとしたらどのへんだろうか、なんてことを話に出してみたわけである。

型のない人間

この話題に対して自分は、「ソフトウェアに対しては高速にトライ＆エラーができる。文法がおかしかったらコンパイルエラーになるし、単体テストを書いて CI しておけば変にバグったりというのをまあまあ防げる。チームや組織に対してはそうではないんではないか。同じようなことを考えることができるか」みたいなことを問うてみた。はたしてチームに対して「CI をまわす」みたいなことはできるのか。回せるものなら回したいが。

それに対するアンサーは色々あったが、覚えている限りだと、

• 書いたとおりに動くソフトウェアとは違い、人間はそのときの調子だとか感情だとかで同じインプットでも時と場合によってアウトプットが異なる。ソフトウェアのようにコンパイルや単体テストもできない。型もない。
• EM にできることは、上がってくる例外をキャッチして、然るべき対処をしていくってことなのではないか。例外の発生を検知するための営みが大事。

なんかみんな無理やりソフトウェアに例えてるような気がしないでもないがまあ分かる。

チームが throw した例外をキャッチする

その後、ではその「例外をキャッチする」というのはどうやればいいのかっていうのを考えていた。単体テストとまでは言わないが、チームの現状、あるいは変化を知るための営みというのはいろいろやりようがあるよなぁ、と思った。

たとえば 1on1 。メンバーの話を聞いて、気持ちよく働けているか、やりにくい要素はないか、生産性を下げている何かがないか、などをヒアリングする。直接メンバーから話を聞くということで、“良からぬ何か” を知るためには一番効果のありそうなアプローチかもしれなくて、やはりこれを定期的に実行するのには価値があるんだろう、と思う。

その他の手段で、生産性みたいなものに関する指標を考えるならば、

• 稼働時間の傾向を見る
• 稼働時間に対するコミット数、あるいは pull request を出した数か何かの割合を見る
• 稼働時間に対する捌いた issue の数を見る

このようなものを定点観測すると少なくとも「いつもと違う」みたいなことには敏感になれるのかもしれない。起こった事柄についてどのような対処をしていくかというのはケースバイケースであろうと思うが、少なくとも catch できるものを増やすということには寄与するんじゃないかな、等と考えた。

コードをいっぱい書くという感じではなくていっぱいコミュニケーションをとって成果を出すようなタイプの人もいるので、コミット数や pull request の数が必ずしも生産性のすべてを示す数値であるとは思わないが、だったら「Slack でのコメント数」とかも計測していってみてもいいのかも。で、無理やり例えるならば、この手の指標を定点観測することが「チーム (あるいはメンバー) に対して CI をまわす」ってことにあたるのかもしれない。

推測するな計測せよ

みたいな言葉があるけれども、ソフトウェアエンジニアを長くやってきた上で EM というロールをやるからこそ、データドリブンなチーム運営という発想を持つことができると思うし、計測したいことを定点観測するようにツールを実装することもできるというアドバンテージがあるんではないかと思う。

2020 年度の自分は初めての EM ということもあり、このへんを雰囲気でやってたところがある。来年度はこういった「CI」を試しに導入してみて、少しでも EM 業を進化させていくぞ。