兼ねてより技術書典11に本を出そうということで執筆活動を続けていたが、なんとかかんとか一応「完成して売りに出す」というところに漕ぎつけることができた。いろいろと学びの深い活動になった気がするのでお気持ちを書き連ねておく。
出した本の販売ページはこちら。
Engineering Manager 一年生のときの僕はこんな感じでした。 : pankona
500 円で販売中。500円以下は設定できないので最安値での設定である。Engineering Manager にこれからなる、あるいはなったばかりの人に向けてという感じで書いてみました。よろしくね！！
このブログ記事を書いている時点 (2021 年 7 月 10 日 21:43) で既になんと驚くべきことに 12 冊売れている。しかも誤字脱字の報告や pull request での修正までいただいてしまってありがたいことこの上ない。感謝。
本当に読まれている…！という気持ちになってちょっとドキドキしながら販売初日を過ごしていた。
本を書くのは大変
出来上がったものを見てみると、目次も表紙も入れて全部で 26 ページでありそんなに多くない。なんなら技術書と呼ぶには薄すぎると思う。しかしこの 26 ページ (およそ 13,000 文字くらい) を書くことは、僕にとっては本当に大変なことだった。この分量の文章を書いたのは修士論文以来かもしれない。いやしかし修士論文は絵とか図をふんだんに盛り込んでやや嵩を水増ししていたみたいな一面もあったので、本当の意味でたくさん文章を書いたのは生まれて初めてだったかもしれない。
「残り一か月くらいあるな、ちょっとずつ書いていかないとやばいな…」と思ったあと 3 週間くらい 1 バイトの文字も書けなかったのはさすがに自分で自分の駄目さ加減にびびってしまった。筆が遅いんじゃなくてもはや止まっている。ガンダムだって動けよって言ったらもうちょっとすんなり動く気がする。もう諦めよう、俺は忙しいんだ…という気持ちが脳内を何度よぎったか分からない。でも諦めたらそこで終了だよねと自分に言い聞かせつつ、妻の「しっぴーつ、しっぴーつ、いますぐしっぴーつ、かけよー！」という懐かしの引っ越しおばさんのリズムでの煽りをくらいつつ、ちょっとずつ、ちょっとずつ、最初は一日に 100 文字くらいずつ、締め切りの二週間前くらいから書き始めたのを覚えている。始めるのが遅ければ書き出してからも遅い。
本当はもっと計画通りに体に負担のないように進める予定だったのだが、結局最後の二週間にやたらいっぱい頑張るみたいな実績になってしまった。計画通りにやるなんていうのが無理で最後に頑張るっていうのはいつも通りではあるんだけど、まあいい歳なんでもうちょっと大人な進め方をしたいと思わないでもない…。
本を書いている人は偉大
そんなもんだから、「技術書典11で出品します！新刊です！」みたいな他の方のツイートを見るたびに、「あぁ、あなたももしかして締め切りに追われながら頑張って書いてたのかい…？大変だったねぇ…」みたいな謎の尊敬の念を抱いてしまったりもする。尊い。
あと僕は電子書籍だけの販売だからちょっと手間が少なかった。中には物理本も用意している方もいらっしゃる。そういった方々は印刷所に何かを発注したり、在庫の管理が発生したりという電子書籍だけしか発行していない民にはない追加の作業が発生していることと思う。執筆作業だけでなく、そういった手間暇を乗り越えて本はイベントや店先に並ぶ。そう思うと本と本の書き手の存在が本当に尊く見えてきており、そういう気持ちを持つに至れたという点を見ても今回のサークル参加は価値があったと思うところ。いやーみんな尊い。
締め切りドリブンで無理やり完成させる
ゲームを作るんでもなんでもそうだけど、“創作物を作り始めたが延々と完成しない” というパターンは非常に多いと思う。僕自身も何度も経験している。この点において「締め切り」というのは非常に大きな存在で、今回僕はこの締め切りが存在していたからこそなんとか提出に至れたという気がしている。
僕が文章をこねるのが不慣れであるという点もあるが、文章というのはやろうと思えばずーっとこねていられるということに気付いた。語順を変えよう、違う単語を使おう、文章の構成がよくないから直そう、章立てを直そう、もうちょっとうまいこと言えないかな、などなど。時間の制約がなければ、おそらくひとつひとつのパートに膨大な時間を費やしてしまい、終いにはおそらく「全然いい文章が書けなーい！」と言って投げだしていたに違いない。
締め切りがあったことで、僕は「とりあえず、とりあえず全パートをいったん書き切ろう、その後直せるところは直す感じにしよう、このままじゃ提出できるものが出来上がらないからな…」という作戦を思いついて実行に移すことができた。締め切りがあったからこそいったん v1.0.0 を出すことができたわけである。締め切りありがとう…。
訓練してまた挑戦する
今回の経験を通して、良い文章を書くのが自分にとって難しいということがよく分かった。圧倒的に文章を書いている量が足りないということもあろうし、良い文章を書くための知識も不足しているからだと思う。一方で、良い文章を書くということにとても興味が出てきた。「文章力を鍛えること」は業務でも活かせる話だと思うし、自分の欲望を叶えることも果たせて一石二鳥ではないか。新しい趣味にできるかな…？文を書く趣味とはなんだろうな…？文通…？
訓練した後、ふたたび技術書典などの締め切りドリブンな創作に挑戦してもいいかもしれない。
技術書典 11 にサークル参加することを目指して技術書もどきの執筆に勤しんでいるが、本を書くのってなーんて大変なんだろうと思うわけです。
この手の活動をするのが生まれて初めてで不慣れだということもあるだろうが、それにしたって書けない。何が大変って 1 バイト目を書くのがもう大変。腰が重い。書こう書こう、書かなきゃ書かなきゃって思い続けて 1 バイトも文字を書かないまま 1 ヶ月過ぎちゃうとは思わなかった。やべーでしょ…
ライトニングトークでスライド作って発表、とかだったら前日にガッとやればまあまあなんとかなったりする場合もあるけれど、本を書こうって言ったら一日じゃどうあがいたって無理ってのはさすがに自分でも分かる。夏休みの宿題みたく、やりたくもないしやる約束もしてないみたいなやつならぶっちしてもあまり心が痛まないのだが (夏休みの宿題をぶっちしたことはない)、技術書典に関しては明確に自分からやるって言ってるわけだし、実際やりたい気持ちもあるのだ。あるんだけど筆が進まないのだ。ぐぬぬー…
しかしまあ、自身のこのような心境を観測して、自分の適性というか心癖というか、そういうものを客観的に捉えることができている点は大きな知見であると感じている。トライしてみなかったらこういったも分からなかったと思う。分かってよかった。一件落着。ではない。書かねばならぬ。書かねばならぬのだ。
ちなみにネタとして EM に関することを書くことにした。 https://github.com/pankona/techbookfest11 にて執筆を進めている。
執筆活動というものの性質
コードを書くのにちょっと似ているかもしれないと思った。
- 進めるにはある程度まとまった時間が必要で、隙間時間にちょこちょこ進めるというのはあまり捗らない（僕の場合は筆をとることすらできない）
- やり始めるためのコンテキストスイッチがそれなりに大きい負荷
- やり始めるとそれなりに進む
コードを書くのと明確に違うところもあって、
- やたら手戻りが発生する
- 一発でいい感じの文章が書けない。だけどこれは自分の力量の問題かもしれぬ
- 完成の定義があいまいで、進捗の管理が難しい。より良い表現を求めて日本語をこねていると延々と時間を使うことができてしまう
みたいなことを感じた。
進捗させるためには
自分の心癖と執筆活動というものの性質を踏まえると、
- 隙間時間にちょこちょこ進めることに期待しない。業務の合間などを使って進めるのは厳しい。就業後も個人的には厳しい。ちゃんとがっつり時間をとって進める。朝だ朝
- こだわり過ぎない。とりあえず全部を一通り書ききってから、盛りたいところを盛っていくようにしないといくら時間があっても足りぬ
- 夜中に期待するな
- 夜中に期待するな
夜中に頑張るみたいなのは若い人の特権でありますからね。22 時には眠くなっちゃう自分にはもう厳しいということをちゃんと認識しないとね…。
あとは諦めない気持ち
当初の計画は完全に破綻しているけれども (週に2ページ、等と計画していた) 、とはいえ諦めなければ何か出せるだろうし、やっただけクオリティもあがるような気がする。進捗しない理由も分析 (笑) した。自分の技術書典サークル活動は始まったばかりだ。もっと早くから始めておけよと言われたらそれはそうなんだが。とにかく、残りの時間を無駄にしないようにやっていくぞ。おー
「リーダーの仮面」という本が本屋で平積みになっていたもんで、それじゃあってことで読んでみた感想。
自分自身がもっとリーダーらしくあるために等と思って手に取ったわけではない。エンジニアリングマネージャとしての自分の振る舞いになんらか足しになるかもしれない、何かの気付きになればいいかな、くらいの気持ちで読んでみた。割とさっくり読めて1時間～2時間くらいで読み終わった。
賛否両論ありそうな内容だなーと思った。最近のマネジメントの風潮 (ホラクラシーであるとかティール組織であるとか) をそれなりに否定するようなことが書かれている。なのでこれ一冊を読んで「よーしこれの通りにやってみるぞー」みたいに思ってしまったりすると、導入の仕方によっては組織に “合わない” ということもありえそうだなと感じた。目標管理を数字で管理するということも書かれていたが、目標を数字にしにくい仕事 (ソフトウェアエンジニアなんかはそうだと思うんだが) だと適用しにくかったりしないかな、なんてことも思う。
気になった点をちょっとピックアップしてみると、
- リーダー (ちなみにマネージャと読み替えて読んでいた) はメンバーと距離を置くべきで、仲良しにならないほうがいい (1on1 も否定されていた気がする)
- なるべく機械的に評価をする。プロセスをことさら評価することはせず、結果を見る。未達ならじゃあ次はどうやって改善するのか、達成ならそれはあたりまえとして扱ってやたら褒めたりすべきでない、というような振る舞いをする
- メンバーのモチベーションをどうにかしようと思わなくてよい。それはリーダーの仕事ではない (会社とメンバーが成長していればそれでよい)
- リーダーは短期の成果ではなく未来を見据えて采配する。待つ。
ここにピックアップしたものについて自分はひとつも実践していない気がしていて、本書の言葉を借りれば「リーダー失格」でありそう。1on1 毎週やってるしプロセスめっちゃ見るし (そもそも未達とか達成とかの基準すら定義していない)、モチベーションが大事だと思うのでモチベーション下がる要因とかヒアリングしたりするし。
未来を見据えて～というのはそれはそうだなと思った。うん。
数値で目標を管理するという点は、チームで測っているベロシティなんかは物差しとして使えるのかもしれない。でもこれもなんというか、達成すべき数値目標というよりは “チームの実力測定器” みたいなところあるしな。ちょっと文脈と合わないかもしれない。
仮面をかぶる
やや本を否定するようなことを並べてしまったが、参考になる話も多かった。例えばちょっとメタにとらえて「仮面をかぶる」という話はとても参考になった。
人は誰しも時と場合によって人格を使い分けている。家庭内なら父とか母とかのロールがあるわけだし、転じて職場ならマネージャやプレイヤーだったりする。属するコミュニティによって “ペルソナ” は変わる。組織でマネージャやっていれば場合によっては冷たいことを言わなければならないこともあり、結果として嫌われることもあろうが、それはペルソナの関係上そういうものであって、人格が否定されたわけじゃないから落ち込む必要はないんだよ、と。まあ分かる。
まあ分かるんだが人間そんなに割り切れるもんか？と思わんでもない。コードレビューはコードについて話をしているので書いた人の人格を否定するものではないのだが、それでもあれで心を傷める人類が後を絶たないっていうのと同じことで、ペルソナの話は観念的には理解できるものの、実態としてそこまで人類は高尚ではないよなぁ、と思わんでもない。
とはいえマネージャは仕事を全うするために、嫌われることを厭わず、言うことを言わなければならない場合もあろうというのは確か。自分はもうこれに関しては「嫌われて落ち込んで復活するまでが仕事」くらいのことを思ってたりする。割り切れてないな。もう少し経験を積んだらこのへんの感じ方や考え方も変わるんかねー、なんてことも思いつつ。
自主性に任せること
メンバーの自主性に任せてあまり細かなマネジメントしない、というスタイルにもやや否定的な論調で触れられていた。これだと成長する人は成長するが、そうでない人は置いてきぼりになってしまうよね、と。これはね、分かる気がする。新しい人とかはほったらかしにできるわけないしね。分かる。
割と自分はほったらかしにしがちな自覚がある。ほったらかしで成長する人はそれで良いんだけど、そうでない人に対しては本書で述べられているアプローチが効くパターンありそうかなーって思ったりした。使い分けが大事なのかもしれない。
総評
少なくとも直ちに自分 (と自分のチーム) に取り入れるには合わなそうな部分が多いかも、と感じたものの、なるほどこういう考え方もあるのね、という、リーダー (マネジメント) の考え方のひとつのカットとしては大いに参考になる内容だった。近頃の組織論とは結構切り口が違うと思うので、こういった本があるのも良いよね、って思いましたです。
技術書典11にサークル参加 (本を書いて売る側) として参加するのを試みてみようと思ったんだ。
技術書典というイベントがある。いわゆる技術書の同人誌即売会である。
普段僕はこれに買う側で参加しているのだが、何を血迷ったか、「ちょっと書く側もやってみるか」等と思ってしまった。ので、とりあえずノリでサークル参加を申し込んでみた。サークルと言っても内訳は自分ひとりであるけれども。
参加には審査がある。2021-05-29 現在はまだ OK とも NG とも返事が返ってきていないので一応審査中なんだと思われる。審査というのは反社会的な何者かであるとか、あるいは明らかに営業宣伝目的での参加であるとか、そういうイベントの趣旨に添わない参加者をフィルターするという目的のものであるようだ。なので基本的に清廉に生きてきたはずの僕は審査 OK をもらえるはずである。はずである。はずである…。
まだ何を書くかすら決めていない段であるのによく参加を申し込んだなと自分でも思うのだが、こういうのは参加を申し込んだことを切っ掛けに “何を書こうか考える脳みそ” が働き始めたりするもんだと思うので、明日以降の自分を信じてとりあえず飛び込んでみた、みたいな感じである。がんばれ、明日以降の自分。
何を書くのか
さて、参加申し込みを行ったのが 2021-05-23 のことだったので、これを書いている 2021-05-29 はすでに申し込みから一週間程度が過ぎている。何を書きたいかと自問自答していて、「ここ一年エンジニアリングマネージャをやってみて思ったことや感じたこと」みたいな話を書くのがいいんじゃないかな、なんて思っているところ。
プレイヤーからマネージャになったばかりのころには様々な不安やら戸惑いやら葛藤やらがあったような気がしたが、そのへんの気持ちの推移やら乗り越え方みたいのは、「これから EM になる、あるいはなったばかりの」みたいな人にはもしかしたら興味深く読んでもらえるんではないかな、なんて思っている。
EM の仕事というのは会社やチームによって千差万別になるということがここんところ感じられてきたので、個人の体験を通して書かれたものがあらゆる EM に共感してもらえるとも思わない。が、まあ一例として参考になる、くらいのものが書ければいいのかなぁ、なんて思うところ。
イベントは 2021-07-10 から
イベントは 2021-07-10 からということで、電子書籍での販売を目指すということもあり、限界ギリギリの 2021-07-09 までは作業ができる予定。もういまから 1 か月半くらいしかない。週末の回数は 6 回くらいかな？なので週末にちょいちょい書いていっても 20 ページにも満たないものになりそう。という感じで 20 ページくらいを目指して「完成を目指す」というのをこれからやっていこうと思う。
ちなみに価格は最小を選択しても 500 円かららしい。なのでせめて 500 円くらいの価値はあるんじゃないかっていうものが書ければとても良いが。
社内の読書会で「エンジニアのためのマネジメントキャリアパス」という本を読んでいる。毎週金曜日の朝に開催。何人かの EM が参加していて、ちょっと読み進めては議論して、またちょっと読み進めては議論して、みたいな感じで読み進めている。
ソフトウェアに対するエンジニアリングとチームに対するエンジニアリング
議論の中のひとつに、Engineering Manager (以下 EM) あるいはチームメンバーという感じで立場が違っていても、向き合うものが組織なのかソフトウェアなのかという違いこそあれど、基本的には「課題を発見して解決していく」というところは同じだよね、みたいな話がなされていた。なるほど分かる。課題を発見し、ボトルネックを評価し、コスパのよい解決策を考えて実行する、みたいなことは確かに同じかもしれない。
では、ソフトウェアに対してエンジニアが行う問題解決のアプローチは、はたして EM がチームに対してという形でも同じように応用できるものだろうか、できるとしたらどのへんだろうか、なんてことを話に出してみたわけである。
型のない人間
この話題に対して自分は、「ソフトウェアに対しては高速にトライ＆エラーができる。文法がおかしかったらコンパイルエラーになるし、単体テストを書いて CI しておけば変にバグったりというのをまあまあ防げる。チームや組織に対してはそうではないんではないか。同じようなことを考えることができるか」みたいなことを問うてみた。はたしてチームに対して「CI をまわす」みたいなことはできるのか。回せるものなら回したいが。
それに対するアンサーは色々あったが、覚えている限りだと、
- 書いたとおりに動くソフトウェアとは違い、人間はそのときの調子だとか感情だとかで同じインプットでも時と場合によってアウトプットが異なる。ソフトウェアのようにコンパイルや単体テストもできない。型もない。
- EM にできることは、上がってくる例外をキャッチして、然るべき対処をしていくってことなのではないか。例外の発生を検知するための営みが大事。
なんかみんな無理やりソフトウェアに例えてるような気がしないでもないがまあ分かる。
チームが throw した例外をキャッチする
その後、ではその「例外をキャッチする」というのはどうやればいいのかっていうのを考えていた。単体テストとまでは言わないが、チームの現状、あるいは変化を知るための営みというのはいろいろやりようがあるよなぁ、と思った。
たとえば 1on1 。メンバーの話を聞いて、気持ちよく働けているか、やりにくい要素はないか、生産性を下げている何かがないか、などをヒアリングする。直接メンバーから話を聞くということで、“良からぬ何か” を知るためには一番効果のありそうなアプローチかもしれなくて、やはりこれを定期的に実行するのには価値があるんだろう、と思う。
その他の手段で、生産性みたいなものに関する指標を考えるならば、
- 稼働時間の傾向を見る
- 稼働時間に対するコミット数、あるいは pull request を出した数か何かの割合を見る
- 稼働時間に対する捌いた issue の数を見る
このようなものを定点観測すると少なくとも「いつもと違う」みたいなことには敏感になれるのかもしれない。起こった事柄についてどのような対処をしていくかというのはケースバイケースであろうと思うが、少なくとも catch できるものを増やすということには寄与するんじゃないかな、等と考えた。
コードをいっぱい書くという感じではなくていっぱいコミュニケーションをとって成果を出すようなタイプの人もいるので、コミット数や pull request の数が必ずしも生産性のすべてを示す数値であるとは思わないが、だったら「Slack でのコメント数」とかも計測していってみてもいいのかも。で、無理やり例えるならば、この手の指標を定点観測することが「チーム (あるいはメンバー) に対して CI をまわす」ってことにあたるのかもしれない。
推測するな計測せよ
みたいな言葉があるけれども、ソフトウェアエンジニアを長くやってきた上で EM というロールをやるからこそ、データドリブンなチーム運営という発想を持つことができると思うし、計測したいことを定点観測するようにツールを実装することもできるというアドバンテージがあるんではないかと思う。
2020 年度の自分は初めての EM ということもあり、このへんを雰囲気でやってたところがある。来年度はこういった「CI」を試しに導入してみて、少しでも EM 業を進化させていくぞ。
Engineering Manager (以下 EM) になって一年くらいが経過した。一年やってみてどうだったかなんとなく振り返りをしてみると、なんだか最近はプレイヤーとしての活動ばっかりしていたような気がする。
っていうか一年単位での振り返りってスパンが長すぎなので、もっと細かく振り返らねばならんな、と思った。一年前のことなんて覚えてない。昨日の朝ごはんだって覚えてるか怪しいというのに。
特に直近の数ヶ月、2020 年 10 月移行はプロジェクトが忙しかったというのもあるけど、特にプレイヤーとしての活動が多かったんではないかと思う。ほとんど毎日コード書いてたというか。いや、別に書いててそこまで悪いとは言わないんだけれど、本業であるはずの EM はどうなった、という。
ここ半年くらいでの EM っぽい活動といえば、
- 週に一回行うメンバーとの 1on1
- 勤怠申請の承認
- ミッションを作ること
- 採用活動 (書類選考、面接)
- よそのチームの EM と話してタスクを按配し合うとか
- あと最終的に評価 (昇格とかなんだとか) を扱う
割とあった。あんまり大したことやってないかと思ったけど改めて並べてみるとこれだけやってればまあいいか、っていう気にもなってきた…か…？
見えない障害物と向き合う
EM は何をやるロールなのか、というのを一年近く考え続けているが、結局のところ「チームを維持する上で障害になっている “何か” を検出して取り除く」ために存在するロールであるという認識になりつつある。障害はチームによって異なり、解決方法も千差万別だったりする。往々にして障害は緩やかなものであり、急に立ちふさがるというよりは真綿で首をしめられていくような性質のものが多いような気がする。対処をしなくても急に何かが起こったりはしないが、放っておけば緩やかに崩壊していく、ような。放っておくとメンバーのやる気は徐々に削がれていって、チームを異動するか転職するか、という形で発露するっていう流れなのかもしれない。
チームを維持するための努力
チームを維持するというのはつまり「メンバーがやる気のある状態をキープし続ける」というような意味で考えている。
やる気がいつも最高潮でなくてもいいんだけど (それはそれで気持ち悪い) 、忙しい時期があったり凪の時期があったり、作ったものが世界を良くしている実感を得られたり、適度に新しいものを学び吸収する機会があったり、みたいなのがやる気の維持につながる要素なのではないかと思っている。人によって何がやる気に繋がるかみたいのは違うと思うけど、最低限の報酬というのは必ず必要だとも思う。
メンバーのやりたいことにあわせて業務をアラインしていくというのは難しいことが多いが、それでもそれを意識して、なるべく良きに計らっていくというのが最低限 EM がすべき努力なんではないかな、と思ったりしている。
ずっと同じメンツでチームを続けられればそれはそれで良いんだけども、とはいえ IT 業界、特にウェブ業界というのは人材の流動が激しく、何年も同じチームが維持できるとは思わないほうがいいんだろう。だとしたら人が入れ替わる前提で建付けを考えておかねばならず、例えば新しく来た人にナレッジを授けるためのオンボーディングであるとか、プロダクトそのものもなるべく分かりやすく、壊れにくいものにしておく、一子相伝みたいなものを排除していく、というのも EM が配慮して然るべきなのかなーと思わないでもない。
ウェットになりすぎないのも大事
主に 1on1 を通して、メンバーの趣味趣向、どんな業務がやりたいかみたいなことは、なんとなくだが把握していく機会がある。
雑談のような 1on1 も多くなり、少なくとも僕からみたら「仲の良い」みたいな状態になっていくことがしばしばある気がするし、そうなりたいとも思っている。
ただ、その「仲良くなろう」みたいな気持ちは、いわゆる「ネガティブ・フィードバック」というのを遠ざけてしまうとも思う。そりゃあ気分悪くなるようなこと言ったら仲良くなるのからは遠ざかるよね、って思うんだけど、とはいえネガティブ・フィードバックの類ほど早く通達することが大事である。あとから「あのときのあれは良くなかった」みたいに回想しながら伝えるのは、記憶の鮮度が落ちているので正しく認識しにくいとか、後から混ぜ返すのはネチネチしててイヤだとか、とにかくあとから思い出したように悪かった思い出を伝えるのは一利なしである。早く言おう。言わないでほっとくのは問題を見て見ぬ振りしているに過ぎない。真綿で死ぬ。
あくまで業務であるんで、「仲良くなりたい」も大事なんだけど、それ以上に「言うことちゃんと言う」が大事だよなー、なんて思ったりしている。そんな単純なことだがなかなか実行できないのは自分が可愛いからなんだろうとも思う。嫌われなくない的な考え。ただ、そういったネガティブなフィードバックも迅速に行っていくことが、結局はチームの維持という面でポジティブに働くだろうとも思うし、何より本人のためにもなると思う。フィードバックが的を射ていればだが…。
あと苦言を言いにくい気持ちになるのは “心理的安全性” を僕自身が感じられていないせいかもしれない。思えば心理的安全性の醸成のための活動というのもしたことがなかったような気がする。今後の課題。
最近読んだ
最近読んだ記事の話。
前にも読んだことがあった気がしたけど、ふと気になって再び読んだ。
「マネージャになることは昇格ではない」ということが書いてあるけども、まあどうだろうね。昇格である会社もあるかもしれない。ただ自分も別にマネージャのほうがプレイヤーより偉いとは思っていなくて、あくまで EM もひとつのロールであり、ちょうど “野球部のマネージャ” みたいな立ち位置に自分がいることを想像していたりする。プレイヤーがしっかり実力を発揮できるように頑張るであるとか、新しい部員を探すために頑張るであるとか、みたいな。
ただあれだ、そんなふうに考えてもやっぱりマネージャとプレイヤーは必要とされるスキルセットが全く異なるような気がしていて、割とありがちな「プレイヤーがなんやかやあってマネージャになっていく」というのは全然メイクセンスではないように思えてくる。弊社のマネージャには「評価する」という役割が漏れなくくっついてくるんだけど、評価するためにはエンジニアリングのことをよく分かっていないといけないというのは分かる反面、チームの健康状態を維持するっていうのはエンジニアリングとは全然別のスキルが必要である気もするので、マネージメントする人と評価する人を一緒にしとくのがそもそも違うんかもなーなんて思わんでもない。
読んでる
人間を知るためにピープルウェアという本を読んでいる。
割とさくさく読める。読めたらまた感想でも書こう。
他の EM (Engineering Manager) から「THE TEAM 5 つの法則」という本をオススメされたので読んでみた。
読書感想文を書いておく。
とても読みやすい
内容とあんまり関係ない話ではあるが、スラスラ入ってくる感じの文体で非常に読みやすいと感じた。
理解が難しい箇所がほとんどなくて、読んでいてストレスがなかったのが印象的。本ってしばしば「途中まで読んだはいいもののまた再開するのが億劫で積まれていく」みたいになりがちかと思うが、そういう気持ちにはあんまりならなくて、サクッと再開する気持ちになれたというか、気楽に読めるというのはとても良いと思った。まあ内容に興味があったから早く先を読みたいっていう気持ちだっただけかもしれないが。
およそ 300 ページくらいでそんなに多くないのもあるけれど、サクッと読める感じでオススメ。
モチベーションの話
「モチベーションを出せ！」「気合だ！」等と言われてもモチベーションがあがらない (何なら下がるまである) というのは体感、あるいは体験として感じていたところではあるが、じゃあどのようにすればモチベーションが上がるんですかね、っていうようなことが書かれていてこのへんはとても興味深かった。
書かれていたのは結局のところ、「何にモチベーションを見出すのかは人それぞれだから、モチベーションを高める “それ” をお互いに提供できるように努めような」というような話なのかと理解していて (雑理解かもしれない)、まあそれはそうですよね、って思うところ。
なんだけども、そもそも「各々が何にモチベーションを見出すのか、あるいは何にモチベーションが下がるのか」っていうのをちゃんとチームの人々がお互いに知っているんだっけ？言語化できてるんだっけ？というとあんまりそんな気はしなくて、なのでそのへんの認識を合わせる何らかの催しみたいのはやってみたら面白いかもねぇ、等と思いながら読んでおったわけである。
だいたい「何がモチベーションになるか」なんて自分のことですら良く分かんない事柄ではありそう。
もう少し細かいモチベーションの話
本書には「4 種類のモチベーション」というのが紹介されていて、それは以下の 4 つであると。
- Philosophy (理念・方針)
- Profession (活動・成長)
- People (人材・風土)
- Privilege (待遇・特権)
これのうちのどれか 1 個にモチベーションを感じるというよりは、4 つそれぞれにどんだけモチベーション感じるかっていう感じで、ダイヤモンド的なグラフにできるようなものなんだろうと思う。
これらの分類分けっていうのはなんとなく"分かる"というか、これを念頭にメンバーの顔を思い浮かべると「あーあの人はこれにモチベーション感じてそうだなー」等と思い当たったりするような気もしてくる。
これを意識しながら 1on1 に望んだりすると、ちょっと相手への理解の解像度が増したりするのかもしれない。現在担当しているロール (マネージャなのか、そうでないのか、とか) によってどの類のモチベーションを感じやすい、みたいなのもありそう。
あとこれは他ならぬ自分自身がどれにモチベーションを感じているか、ってのを考えるのにも役立ちそう。セルフモチベートに用いるというかね。そういうの考えて整理しとくのも大事かと思われる。自分のような「最低賃金がまあまあであれば、あとは Go 書ければだいたい凄く満足するんだけどなー」みたいのは、「待遇そこそこ、活動強め」くらいな感じでモチベーション感じているのかなー、のように分類されるんだろうか。
Engineering Manager (以下 EM) の仕事のひとつとして、しばしば「メンバーの成長を促す」みたいなことが書かれているのを目にする。
開幕から「もう何も教えることはない」のだが
いまの自分の状況に照らすと、
「メンバーの成長って言うけどメンバーのほうが強いんですけど？何も教えられることなんてないんですけど？何も言わないでも爆速でみんな成長しているように見えるし、何ならむしろ僕は教わる側なんですけど？」
みたいなことを思いがちな現状であって、つまり「EM がメンバーの成長を促す」というのは、
- メンバーにジュニアレベルな人がいるとか
- あるいは EM がすごく経験豊富で教えることがたくさんある
みたいな状況における仕事なんじゃないかな、という理解をしていて、なんなら今の自分にはあんまり関係かな、と思っていた。
なんだけど、2 ヶ月 EM 生活をしてきて少しだけ考えが変わってきた。
誰も EM が自ら教えろなんて言ってないことに気づく
強いメンバーがいて、強いもの同士でペア作業であるとかモブ作業であるとか、その他なんでもいいんだけど「複数人での共同作業」をやっていると、ちょっとしたことでも色々知見だとか知識の共有が行われているってことに気づいた。
この様子を見て、「成長の援助する」っていうのの形は、なにも EM 手ずから何かを教えるとか導くとか、そういうのに限らないんじゃないか、ってことに気づいてきたわけ。
弊チームでは色々の事情を勘案して、いまは「いっぱい協業しようね」というのをテーマにして作業を行っている。
つまりこれも一種の「成長を促す環境作り」みたいなもんなんじゃないかな、と思い、言い換えればこういう状況を作っていくことがすなわち「成長を促す」と言ってもいいんじゃないかと思った。
こじつけっぽいが、そう考えるとちゃんとメンバーの成長を促す仕事をしているような気がしてきた。審議？
成長を促すやり方は他に何があるか
で、共同作業だけが成長を促すやり方ではないはずで、いろんな成長を促す手法を知っておく必要があるなーと思った。協業みたいの嫌いでもくもくやりたがる人もいるしね。
たとえば、案として、
- 任意の何かを勉強する時間を業務時間中に設けてカジュアルに発表し合う場を作る
- 任意の事柄についてライトニングトークできる場を作る
みたいな、これはどちらかと言うとアウトプットのほうにフォーカスしている案かもしれないが、こういった催しを継続的に行う立て付けを作る、っていうのもナレッジを高める手段であろうと思う。まあしかし、この手のものは言われてやるって言うと急にやる気なくなったりする一面もありそうで、やるにしても導入の仕方が難しいような気がしないでもない。まずは小さく、気軽に、そして何より隗より始めるのが良いのかな―等と思ってみたり。
「毎週この時間は Go の勉強会」みたいのだったら自分でもちょいとはできそうかもしれない…。いいじゃん…。みんなでおっちゃんと一緒に標準ライブラリ読もうや…。
やはり EM は「地相を変える仕事」であったのか
先日のポストで、「EM の仕事はロマサガ 3 で言うところのコマンダーバトルであり、地相を変えるのが EM の役目なのでは」等と雰囲気で書いていったわけであるが、 本稿の「成長を促す環境作り」みたいのはまさに「地相を自分らに有利なように変えていく」みたいに見えはしまいか。見えんかね。どうかね。
現在の地相が自分らに有利なのか不利なのか、地相を変えるとしてどの地相に変えると有利なのか。現実はもっと変数が多くて複雑であるのでゲームのように火星の砂を放っておけばいいという話にはならないわけだが。なんとなく共通点があるような気がしないでもない。まあちょっとこじつけではある。うむ。
EM も悪くないとだんだん思えてきた気がしないでもない雰囲気を感じつつある
先日までエンジニアだった自分は、しばしば「マネージャの仕事はコード書く量が減ってしまってつまらん」等と思いがちであるのだけれど、ただこうして「どういう課題に脳みその大半を割くのが EM の仕事なのか」ってのに整理がついてくると (ここで言うところの、どうやったらメンバーが成長するのか、という課題) 、それなりに重要で、それなりにやりがいのある、それなりに面白みのある、もののように思えてきている気がする。
これは自分にとっては大きな心境の変化で、日常のストレスの感じ方に直結しているのを強く感じる。当初よりはストレスフルでなくなってきたというかね。もしかしたら単なる慣れかもしれないが。課題が見えてきて、あるいは言語化されてきて、「納得感」が醸成されてきたってことかもしれない。納得は全てに優先するじゃん？
というような感じで 2020 年 6 月もやっていく。おかげさまでリモートを続けられる環境で嬉しい。
Engineering Manager (以下 EM) を始めて二ヶ月くらい経った。依然として EM というものはいったい何なのかを考え続けている。
引き続きもやもやしている
弊社 (Quipper) において EM が最低限こなさなければならない「義務」のようなものは概ね把握してきた。
それは第一には「メンバーの評価」であり、第二には「採用活動」である。これらは将来変わるかもしれないが、いま時点においてはこれらが EM の仕事といって差し支えないように見えている。実際、業務時間のだいたいはこれらに関する何かで時間を使っている。
さて、4 月に EM になってから 5 月末に至るまでずっと「もやもやした不安」を感じていた。
それは「EM になったはいいけど、EM ってどういう仕事する人なんだっけ」っていうのをよく分かっていなかったからだと思っていたのだけど、先述のようにそのへんが概ね明らかになってきたにも関わらず、やはりもやついた気持ちが晴れてこなかった。いったい僕は何を不安に思っているのか。天が落ちてくることでも心配しているんだろうか。
そんな悩みとも何とも言えない晴れない気持ちを、たまたま目の前 (※ やりとりは Slack なので目の前というのは少し語弊がある) にいた @ujihisa さんに相談してみた。
僕が思うに、ujihisa さんはもやもやした形の曖昧な気持ちや事象に「名前をつける」であるとか「モデル化して可視化してくれる」であるとかのチカラが凄いんである。けれどそれは本稿では割愛して、また別の機会に分析してみたいと思う。ほんと凄いんですよ、ええ。
そんで、もやもやを五月雨式に ujihisa さんに向かってダンプしていくうちに、だんだんその不安の正体がつかめてきた気がしてきた。
端的に言うと、「プロダクトに対する貢献感が少ないことに対して焦っている」んじゃないか、ということであり、つまりもうちょっと砕いて言えば「あんまりコード書いてないから"やってる感"を感じない」ということでありそうな気がする。
確かに、僕が近頃こなしている数々のミーティングや採用活動は、直接プロダクトを良くしているわけではないと感じている節がある。EM になる以前はもっとプロダクトへの直接的な寄与をできていたと思うし、それといまとのギャップも相まって「こんな仕事してて良いんだろうか」って考えてしまうってことなんじゃなかろうか。
しかし実際のところ、チームメンバーが鬼強い人たちばかりであるので、僕があんまりコードを書かなかったところで特に何も問題は起きないという一面がある。何もしなくて良いのである。
このシチュエーションはマネージャから見たらイージーモードと言えるのかもしれないが、ただ、そういう意味では「やっぱ自分はあんまりチームの役に立っていないなぁ」みたいなことも考えてしまうやつなのである。
うだうだ書いたが、つまり一言で言って「プロダクトを作っている感がなくて虚無を感じている」ということかと思われる。うむ。
その虚無は本当に虚無か
評価にせよ採用活動にせよ、はたまたコードを書くにせよ、それらは誰かがやらねばならないし、大きな価値のある尊い仕事であると思う。どっちの仕事が優れててどっちが劣っているという話ではない。
なので、僕が最近の自分自身の仕事に「やってる感を感じてない」とはいえ、それらには一定の価値があろうとも思う。断じて虚無ではない。
問題は「自分が思い描く寄与の形と、現実にギャップがある」ことで、それがつまり「仕事がつまらん」みたいな感情に繋がりつつあることである。
とはいえこの構図は、「やりたいことをやりたいようにやることが寄与に繋がってきた」今までの体験が、ロールが変わることによって一部崩れてしまい、その変化に対してダダを捏ねているようにも見えなくもないね…。みたいなことにも気付きつつある。
というわけで、目下は「どのようにやってる感を感じるか」というのがひとつ課題なのかと思う。自己効力感というか何というか。
ujihisa 曰く、「プロダクトに時間が割けない中でプロダクトへの効力感を感じるには、周囲に助けてもらって自分にプロダクトの仕事をさせてもらう」のが良いのではないか、である。
なるほど、何か難しそうであるが、これならメンバー評価の仕事をしつつ、自分もプロダクトに寄与していけるような気がしないでもない。助けてもらう前提 (ペアやモブ作業を行うという意味) であれば、たとえ割ける時間が少なかったとしても、多少なりとも自分が納得していけるような活動になっていく気がする。
一方で、言わば「プロダクトへの間接的な寄与」(直接的な寄与、と先述したのでそれに対するものの表現) に対しても同様の尊みを自分自身が感じていくのも大事かなぁと思う。
コミットログや GitHub の草のように可視化されるものでもないし、どのように達成感を得たらいいんだろうか。ここはもう少し分析や考察がいるところ。
ロマサガ 3 のコマンダーバトル
ところで、ロマンシングサガ 3 にはコマンダーバトルという戦闘モードがある。一言でいうと「主人公は直接戦わなくて後ろからざっくりとした指示を出す」モードである。
当時としては割と斬新な戦闘システムだったかと思う。二周目のプレイとかはコマンダーバトル縛りでやったような記憶がある。サラを主人公に選ぶとラスボスで強制的にコマンダーバトルになったりするけどあれはちょっとあんまりだと思った。少年も仲間だったんですけど没収されてしまうし。いま思うとホントひどいなこのゲーム…。好きだけど。
ちょっと記憶が曖昧だけど、コマンダーバトルというのはたしか各位に細かい指示は出せないんだった気がする。全員戦うとか全員守るとかの方針を決定するのと、どんな陣形で戦うかっていうのと、陣形技っていう複数人が連携する技を指示するとか、あとは主人公が後ろからアイテムを使うことができる、くらいだった気がする。
不自由かと思いきや、いくらかメリットもあり、コマンダーバトルではパーティメンバーは毎ターン HP 回復するし (戦闘不能だったら HP 1 で復活する) 、陣形技は超強力。軌道に乗ってくると通常の戦闘モードよりもコマンダーバトルのほうが安定するまであるような気がするし、だんだん楽しくなってくる。あと楽。
少々こじつけかもしれないが、EM の仕事というのはある意味コマンダーバトルみたいなところがあるのではないかと思う。 EM は直接敵と戦うわけではないが、戦況に鑑みて陣形と作戦指示だけしていく、みたいな。まさに同じ構図。そっくりじゃないか。俺はサラだったのか。まあなんというかね、コマンダーバトルはものすごい好きになることができたので、これもやはりこじつけかもしれないが EM の仕事も好きになれるんじゃないかと思っている。きっと僕の仕事は後ろから火星の砂とかを使って地相を変えることなんじゃないかな。どちらかと言うと寒い感じの地相にするほうが得意かもしれないが。
以上をふまえた 6 月の取り組み
- ペア/モブ作業を通してプロダクトに多少は寄与していく
- ミーティングをコンパクションしてプロダクトへ寄与する時間を増やす
- 地相を変える仕事に尊みを見出す
2020 年 4 月から所属している会社 (Quipper という) で Engineering Manager というロールをやっていくことになった。
これを書いているのが 2020-04-23 なのでロールを言い渡されてから概ね一ヶ月くらい経過しているのであるが、未だに Engineering Manager というものが何をすべきロールなのかちゃんと分かっていない。というのも、メンバーに「Engineering Manager って何する仕事なんですか」って聞いても (これを僕から聞くのもあれなんだけども) 、割とみんな Engineering Manager に期待する動きというのがバラバラであり、「メンバーが開発に集中できるようにする」と言う方もあれば、「開発もそれ以外もなんでもやる人でしょ」等と言う方もあったりする。なんでもってなんだ。植木に水でもやるか。
で、自分でも色々考えてみて、何をすべきかっていうよりは逆に「これは EM の仕事じゃなくてもいいよね」みたいのをちょいちょい集めていっている。
- こぼれ球拾っていくみたいな動きも別に EM じゃなくていい (権限が必要な場合は除いて気づいた人やればいい) 気がする
- なんでもやるってのは土台無理な気がする
最終的にメンバーの評価をするっていうのは EM しかやれないこと (これは弊社の立て付け上の事情だろうけども) なので、そのために 1on1 する等して色々な情報を収集する、みたいなのは自分がやらないといけないよね、というのは気づいたところ。
その情報収集を通して雑多に情報が集まってくると思うので、その情報を元に自分にしか見えない (あるいは他の人に比べて自分が気づきやすい) 問題っていうのはあるのかもしれない。ので、そのへんを意識して解決するように頑張っていくっていうのが EM として価値のでる仕事なのかなー等と考えていたところである。曖昧。
あと比較的安価なものであれば決済する権限も与えられているようなので、精一杯濫用していきたいと思っているところ。
昨今はコロナの影響もあってリモートワークが盛り上がっているので、経費使ってリモートお茶会くらい開催してもいいんじゃないかなー。どうかなー。