こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
第66回目では『スタッフエンジニアの道―優れた技術専門職になるためのガイド』を取り上げます。 本書は技術専門職としてのキャリア成長に必要な考え方やスキルを詳細に解説しています。上級技術専門職に求められる役割、大局的な視点を持って自らの仕事に取り組む方法、大規模プロジェクトを成功に導く手法、自身の専門性を深めながらチームメンバーの成長を支援する方法を学ぶことができます。
今回は技術専門職としてのキャリアを目指すエンジニア必携の本書をテーマに、訳者の島田 浩二 氏に本書のポイントについてお話していただきます。
スライド
会の様子(講演)
スライドがあるため、スライドにかかれていない内容を中心に書いていきます。
本書の概要
ソフトウェアエンジニアとしてのキャリアはマネジメントとしてのキャリアや技術専門職としてのキャリアがありますが、技術専門職としてのキャリアに関してはまだあまりキャリアパスのイメージが少ないという問題意識をもとに書かれた本だということでした。
内容としては、著者自身の経験やコミュニティの経験をもとにスタッフエンジニアのキャリアが整理されているということです。
技術専門職としてのキャリア
技術専門職というとICが有名ですが、ICは個人貢献者のような間違った印象を与えかねない名称で、組織的なところにこだわる必要があるという話がありました。
局所最適と全体最適
やりたいことがあってその要件に満たすソフトウェアを探す際に、セットアップが容易なものとセットアップが複雑なものがある状況だと普通は前者を選びますが、例えば前者に関して法務部門とセキュリティ部門の仕事が必要な場合は、後者を選ぶような動きができるような人材がスタッフエンジニアだという話がありました。
ロケーターマップ
自分たちのコンテキストで見るのではなく、自分たちを見ている人たちの視点で俯瞰的に見られるようになるために使えるロケーターマップが重要だという話が書かれているそうです。
トポグラフィックマップ
地図の特徴を観察するようなものが語源で、組織の特徴を理解するマップが紹介されているそうです。
こういう話は政治の話として扱いが難しいことを理由に蔑ろにされがちですが、理解をしてもらうために働きかけたりすることは自然なことなので、重要な仕事の一つだという話がありました。
トレジャーマップ
シビラリゼーションというゲームを題材に、多くの技術投資は長期的な目的があってこその投資であることが多いという話がされているそうです。
リーダーとしての資質
ギャップを見つけるだけではリーダーではないし、ギャップが見つけられていない状況でただ行動するのもやはりリーダーではないという話が書かれているそうで、リーダーとはギャップを見つけてそこに向かって行動するのが重要だという話が書かれているそうです。
また、誰かがなんとかしないといけない状況では、誰か=自分だと捉えることが重要だというお話があり、プロジェクトを動かすために必要なものは雑務であってもやるべきだという主張がされているということでした。
メッセージを発信したりルールを決めたり福利厚生を充実させたりをしがちではあるんだけれど、思うような成果に繋がらないことも多いという話があり、組織をレベルアップさせるために
- ロールモデルになる
- 良い影響力を広げる
- 自分自身をレベルアップする
というのが重要だという話があるそうです。
なんでもやるなら結局マネジメントと同じでは？
書籍の話を踏まえると、マネジメント/スタッフエンジニアは同じ方向に進むタイミングもあって、重なるところもあったりする(一本道ではなく行って戻ってを繰り返したりすることもある)ということですが、技術でプロジェクトが詰まる際にそこを解決するのは技術専門職の仕事だということでした。
「会社、チーム、自分自身」フレームワーク
書籍エレガントパズルでは「会社、チーム、自分自身」フレームワークが紹介されているそうですが、著者が自らそのフレームワークを紹介したのは失敗だったという話があるそうです。
モデルとしては正しいと思っているものの、燃え尽きるような人たちも多く見てきたそうで、概念的には正しいことであってもそこに厳密に従うのではなく、自分自身のエネルギーの厳選を大切にすることも同じくらい重要だということでした。
会の様子(Q&A)
講演のあとはQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
スタッフエンジニアのポジションが一般的になるまでの課題は？
CTOや技術顧問くらいしか職位がない。また、そんなに大きくない組織では技術者が輝けるようにしていくのが大切
スタッフエンジニアとシステムアーキテクトの違いは？
システムアーキテクトはスタッフエンジニアの仕事の一つであると思っている。
スタッフエンジニアは職能かグレードなのか？
ここは混乱があるため、スタッフ+という概念が出ているのだろうと思っている。
スタッフエンジニア=優れた技術を持つエンジニアというイメージがないのだがなぜか？
技術参謀と日本語訳してもらえれば大分レベルが高そうだなと思ってもらえるはず。
スタッフエンジニアという肩書がある会社はあるのか？
ある。CARTA HOLDINGSなど。
スタッフエンジニア/マネジメントを超えるリーダーシップとの比較をしてほしい
内容は近いと思うが、マネジメントとしての立場なのかスタッフエンジニアとしての立場なのかが違うので、客観的な話(外から見ている)なのか主観的な話(中から見ている)なのかは違うはず。
スタッフエンジニアは複数いるのか？それとも一人の想定なのか？
アーキテクトやソルバーという役割の話もあるので、一人だけではないと思う。
一番訳しにくかったところは？
4章の限りある時間に関しては、E+2Sというタイトルがあるのだが数式にしか見えないので日本語訳するときに頭を悩ました。
スタッフエンジニアに憧れているマネージャーが読むべきところは？
書かれている内容はマネージャーにとっても全部参考になると思う。
スタッフエンジニアの道を読む時の適齢期は？
読まなくてもいいというと誤解があるが、シニアエンジニアになる前の人は対象読者ではないような気がする。キャリア的には10年くらいのイメージ。
会全体を通した感想
書籍を自分も読んだのですが思ったよりもマネージャーに近い話が多く書かれている感じがあって、そのあたりの背景を自分が読んでいない書籍も絡めながら説明してくれたのが特にありがたかったです。
また、島田さんが最後にどうしても話したいということで入れ込んだ自分自身のエネルギーの話は、すごく身に沁みましたし、自分自身のやりたいことはなにか？というのも常に問いかけられるようにしたいなあと思いました。
