tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

July Tech Festa 2020で組織に良い開発文化を植え付ける「Software Engineering Coach」という役割の話をしてきました

はじめに

インフラエンジニアの祭典 July Tech Festa 2020で登壇の機会をいただき話してきました。今年のテーマが「Extend Your Engineering Life」ということで、自分のキャリア観についての話となっています。ひっそりTwitterなどのプロフィールは「Software Engineering Coach」に変えていましたが、今日を機にもっと積極的に名乗って行こうと思います。

講演動画


B2:組織に良い開発文化を植え付ける「Software Engineering Coach」という役割 - JTF2020

当日Slidoでいただいたコメント

Software Engineering Coach という役割は、社内でどのくらい浸透していますか?

自称なので浸透していません。これから名乗って行きます。

マネージャーという立場とコーチという役割の利害関係がぶつかる場合がありそうだなと思いました。やはりその都度いろいろな検討をされたのでしょうか。

利害がぶつかって他に手がない場合はマネージャーに倒して考えることが多いかなと思っています。 利害関係がぶつかることは頻繁にはないのですが、頻度が多くなるなら役割を分けることは必要なのかもしれません。

Twitterでいただいた主なコメント・質問

そうですよね、役割に関係なく良いソフトウェア開発やりたいですよね。難しい願いじゃないと思うんですが、やってみると難しいんですよね。

実際に効く弾丸(ただしとどめを刺すには至らず効果がいずれなくなる)と、効果がない錯覚が混じっているような気がします。テスト自動化は今まさにハイプを上り詰めようとしているところな気がします。Rettyもテスト自動化SaaSmablを導入していますがお付き合いしていくのはそれなりに大変です。

役割つけた瞬間に縛られることがありますよね。なので嘘にならない一番抽象度の高い役割を名乗ることって大事なのかなと思っています。

私が"Software Engineering Coach"の役割を見たのはTargetのミグズさんの講演でした。ConfengineのプロフィールもSoftware Engineering Coachになっていました。 f:id:tune:20200725143517p:plain

誰かが翻訳進めているのかもしれませんが英語だけのようです。これを見たオライリーの方、私に本の翻訳任せてみませんか😁

50万円ですね。十分ペイするとは理解していますが、会社として行かせるとなると改まってしまいます。

やり方を知っていてもできるわけではないですからね。RIZAPが流行ったのも同じ理由のような気がします。

ドキュメントに目的とかスコープを書いておくと後から見返してわかりやすくなりますよね(自戒)

エンジニアが不要なコードを消せないはずはないので、消えてないとしたら別な理由があるんですよね。習慣がないのもよくあるのですが、「消した場合の検証をどう行ったら良いのか前例がなくわからない」というのは自分も目から鱗でした。

コーチングやチーミングを目的にしてしまうとちょっとした変化で満足して続かないことはありますね。そもそも解決したかった問題は紙にでも書き出しておいてたまに振り返ると良いと思います。

やっていき( ・ㅂ・)و ̑̑

言及いただいたブログ

pazoo.hatenablog.com

amarelo24.hatenablog.com

補足

自分の原体験を話していたときのスライド、せっかく映画の画像引用したのに触れるの忘れていました。「陽はまた昇る」は日本ビクターがVHSテープを開発したときの実話を元にした映画です。デスマーチの移動中にレンタルで見て涙が止まらなくなった思い出の映画です。

movies.yahoo.co.jp

失敗して涙を流すぐらいの良い仕事、やっていきましょう。