10/8(土)、forkwellが主催するイベント「Forkwell Meetup – この先生きのこるエンジニアとは」というイベントで、ゲストトークとして「ロックスターになれないエンジニアたちに贈る生存戦略」というお話をしてきました。

スライド

動画

スライドをバラして、iPhoneのボイスメモで録音したものを重ねただけです。まわりがガヤガヤしてますがご容赦ください。

Q&A

録音を晒してしまうのはちょっと自重して、雑な箇条書きでダイジェストをお届けします。

  • Q: お前はもうロックスターに憧れていないのか？
    • 今でも憧れる気持ちはある。
    • 業務以外のコードを書くことはどんなに遠くてもロックスターへの道だと信じている。
  • Q: 30代を過ぎるとロックスターとマネージャーの二択になってしまうのか？
    • まだメインになり得るような選択肢は発見されていないが、あると思う。こうして登壇しているのもその一環。
    • 軸足は二択のどちらかに置きつつ、第三の道を探していきたい。
  • Q: うまくいかないときのモチベーション維持は？
    • 相手は人なのでうまくいかないこともある。
    • 趣味のコードを書くことで回復することもある。
  • Q: 技術的負債の返済を認めないリーダーはどう対処したら？
    • ビジネス側から見ると「リファクタリングの時間をくれ」は無茶な要求。
    • ビジネス側の要求に答えつつ、普段の開発フローに返済計画をうまく丸め込んでいくのもリーダーの仕事のひとつ。
  • Q: コードを読まないリーダーとどう対処したら？
    • コードを読まなくてもちゃんとチームをよい方向にリードしているなら問題ない。
    • ビジネス側の要求を素通しするだけのリーダーは厳しい。「たたかう」「まほう」「にげる」などのコマンドも選択肢になってくる。

スライド後半のポエム

質問出なかったらさびしいのでポエムを用意しておいたんだけど、さいわい時間いっぱいまで質問は途切れませんでした。スライドには残っているので、軽く解説しておきます。

焦りを飼いならす

リーダーには「俺コード書いてなくてやばい腕が鈍る」という焦りがついて回るものです。その「焦り」はエンジニアとしての成長の原動力でもあるので、殺してはいけない。でも、過度に気にして自分がつぶれたら本末転倒。うまく飼いならしていきましょう。

会社とうまくやる

開発チームはともするとビジネスサイドとの対立構造に巻き込まれがちです。それを回避し、開発チームもビジネスのチームも同じ方向を向くようにしていく。その中で、技術的負債を返したり開発環境を整えたりといったエンジニアサイドの要求も実現していく必要がある。難しく厳しいロールだけれど、リーダーがやらなければ誰もやりません。

聖杯問答

元ネタはこちら。

チームの雑用を拾って回る「サーヴァント型」のリーダーは、うまく回ると成果を出すことができるが、様々な弊害がある。サーヴァント型であることを受け入れるだけではなく、ビジョンを示しロールモデルたらんとすることも大事ですよ、というお話です。

「言霊」というのはそれに関連して考えていることで、リーダーのぼやきも後継者育成には有害なので気をつけよう、という自分への戒めでもあります。7時間ミーティングしてたわー、ランチ食べる暇なかったわー、人間性を消耗したわー、などと発言するごとに、言霊が後継者からリーダーシップを削っていくのです（おおげさ）。

教科書は何も教えてはくれない

ソフトウェア開発というのはたかだか50年程度の若い仕事で、その内容や必要とされる知識・技能もどんどん変化しています。つまり正解やベストプラクティスといった「教科書」が存在しません。だからこそ、様々な事例からプラクティスを学んだ上で、自分のチームに最適なふるまいとはどんなものだろうか、と思考停止せず考え続ける必要があります。

ロールモデルがいないなら

ずばり1人「この人のようになりたい」というロールモデルがいるのは大変ラッキーで稀有なことです。そういう人がいないなら、社内外を問わず探しましょう。あるひとつのことがらにおいて尊敬できる人をみつけ、そういう人たちの「すごいところの集合」をロールモデルとして設定するのもいいでしょう。プログラミングならあの人、リーダーシップならあの人、問題解決能力ならあの人、みたいな。

そしてこの手の話になると必ず紹介するのが「ロールプレイングゲーム」というエッセイ。理想のリーダー像をつくり、思い浮かべ、演じてみましょう。だって、仕事でしょ？

最新技術マン

「焦りを飼いならす」に通じるテーマで、自分が / チーム全員が最新技術を追い求める勉強家である必要はありません。むしろそういうチームは不測の事態に弱い、とすら言えるかもしれません。それよりは、各自の得意分野が適度に散っており、それらを集めたときに総合力が高いチームの方が「つよい」チームでしょう。メンバーが自信を持ち、かつ謙虚に学び続けるようなマインドも、リーダーが育ててあげたいものです。

謝辞（とそしていいわけ）

このトークの半分は「マネジメントに悩める全てのエンジニアにささげる　伊藤直也の１人CTO Night」や「Rebuild」で伊藤直也さんが話したことに強く影響されています（そして相当量を拝借しています）。開発チームのマネジメントというテーマを深く考察し積極的に発信してくれるなおやさんには敬意と感謝でいっぱいです。

また、「プロセス知識スペクトル」「心理的安全性」という大事なキーワードは「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」という本を参考にしています。本としてはけっこうくどいしソフトウェア開発以外の事例紹介が多いので、エンジニアにはなかなか読みづらい本ですが、成果を出すチームに育てていくために重要なことがたくさん書いてあるので、頑張って読んでみてください。

登壇の機会をくださったforkwellさん、共演者のみなさま、そしてなによりトークを聞いてくださったみなさま、ありがとうございました。