自分はこれまでメンバーレベルのポジションとしてしか働いたことがありません。
ただ、自分と比較して必ずしも技術的に優れているわけではない同僚がインパクトの大きい仕事をしたり、上司やマネージャーの信頼を得たりしていくのを見た経験から、
自分がよりインパクトの大きい仕事をしていくためにはどのような部分が足りていないのかを考えるために、色々と調べたり、考えたり、まとめたりしてみました。
シニアなエンジニアについて
ここでは、グレードの高いエンジニアや抽象度の高い仕事を日常的に行っているエンジニアをシニアなエンジニアと呼ぶことにします。
シニアなエンジニアの振る舞い
- タスクを発見できる
- タスクの担当者と期日を決められる
- 誰によって、いつまでに問題が解消されるか
- タスクの優先順位を顧客や営業の目線で考えられる
- タスクをなぜやるかを答えられる
- 緊急度と重要度
- やる必要性、やりたい理由、やらなくて良いわけではない理由
- タスクのゴールを決められる
- ゴールが何であるかをスタート時点で意識しておく
- ゴールを上司やマネージャーや顧客と共有してから、タスクに取り掛かる
- タスクの解決策として選択肢を提案できる
- 松竹梅
- Pros / Cons, メリット / デメリット
- タスクのマイルストーンを引くことができる
- タスクの進捗を、定期的に共有・相談できる
- 上司、マネージャーがまったく把握できていない状態にしない
- タスクの進捗に応じて、調整ができる
- 仕様、開発スコープ、担当者、期日
良いコミュニケーションの例
- 意見を添える
- 「このくらいの時期でどうですか？」
- 「他のメンバーのヘルプをお願いできますか？」
- 「仕様や開発スコープを調整できますか？」
- 「これでいいですか？」
- 「こう考えているので、こういう理由でこうしたいです」
- 選択肢を提案する
- 「どれにしましょうか？」
不十分なコミュニケーションの例
- 提案がない
- 「どうすればいいですか？」
- 「いつまでにやればいいですか？」
- 「優先度はどのくらいですか？」
- 「こう言われたからやってます」
- 「お前はどうしたいの？」と聞かれる
- 上司、マネージャーが状況を把握できていない
- 「なんでそういう方針になってるんだっけ？」と聞かれる
- 「他の選択肢検討した？」と聞かれる
- 「あれどうなってますか？」と聞かれる
- 「それ知らなかった」と言われる
スタッフエンジニアについて
スタッフエンジニアとは、より大きな価値やインパクトのある仕事（より広い範囲との調整・交渉・合意形成、組織的な動き、技術的なリーダーシップ）が期待される、技術の専門家の立場から組織を補佐する上級技術専門職。
一般に、シニアエンジニアよりも上位のポジション。
スタッフエンジニアの役割を支える3本柱
1. 大局的な思考
- 全体から見たときに、自分たちの取り組みや状況がどのように見えるかを俯瞰する
- 一見時間はかかるが、他部門への影響（追加となる工数）が少ない選択肢を選ぶなど
- 組織の文化、グループ間の関係、公式非公式の意思決定の経路などを把握する
- 物事をうまく進めるために問題がある部分に橋をかける行動を取っていく
- 組織全体がどこに行こうとしているのか、なぜ行きたいのか、どこ行こうとしているのかを理解する
2. 実行力
- 「誰かがなんとかしないといけない」と感じるときにその誰かが自分であると考える
- プロジェクトを動かしていくために必要なことは（いざとなったら）なんでもやる
- プロジェクトが始まる前から、タスクのスコープを把握し、提案書を作成する
- システム全体の設計を行う
- 設計に対する主要な窓口になる
- リスクを予測し、難しい質問を投げかける
- プロジェクトが行き詰まったときには、その原因を追求し、障害を取り除くのに十分な観点を示す
- ブロッカーの除去
- 他のチームの作業が必要でそれが進んでいない
- 組織やステークホルダーが意思決定できない
- 承認が得られない
- 仕事を進められない同僚がいる
- 誰にも割り当たっていない作業がある
- ブロッカーに対処する共通的なテクニック
- 理解し、説明する
- 仕事を簡単にする
- 組織のサポートを得る
- 代替案を立てる
- オンボーディング
- メンタリング
3. レベルアップ
- 重要だけれど緊急でない仕事に取り組む
- 手動デプロイで運用開始してしまった後でのデプロイの自動化
- 自動テストなしでリリースしてしまった後での自動テストの作成
- 機能は満たしているけれど、運用する中でより良いモジュール分解点がわかってきたコードの整理
- 運用を続けていく中で最新の状況と一致しなくなってきたドキュメント群の整理
- 緊急だけれど重要でない仕事は委譲する
- 他のメンバーに行動で示す、模倣される振る舞いをする
リーダーシップについて
- インパクトを大きい仕事をする上で、リーダーに限らず、誰しもがリーダーシップを持つことが重要。
- リーダーシップのある人は、リーダーとしてだけでなく、組織が成果を出すためのメンバーとしての振る舞いも理解している。
- また、変化できる組織/成果を上げられる組織は、カリスマ的リーダーがいる組織ではなく、リーダーシップを持つ人が一定数いる組織。
リーダーシップのスキル
- 何かの点において高い能力を持っている
- バランスが崩れていてもいい
- 目標を掲げることができる
- 先頭を走ることができる
- やるべきことはリスクを取って実行できる
- 決断ができる
- 「悪い決断」は「決断しない」よりも良い
- 「絶対にこっちがいいみたいなこだわりある人います？いなければとりあえずAでいいんじゃないですかね」
- 「目的は◯◯ですよね？今話してることは目的からちょっと遠そうな気がするんで、次いきませんか？」
- 「すみません、問題はなんでしたっけ？」
- 「それぞれやってみたらどのくらいかかるんですか？1日くらいなら両方やっちゃえばいいんじゃないですか？」
- 「これ情報少なくて今決めにくそうなので、この会議では決定するために必要な情報は何かだけ認識合わせましょう」
- ビジネス上の意思決定とは、確実にはわからない未知/未来のことについて決断すること
- 「悪い決断」は「決断しない」よりも良い
- 伝えることができる
- 言うべきことを言うことに躊躇しない
- 自分の意見を明確にする
マネージャーの場合
- 量より質を評価する
- 長時間オフィスに滞在し、ものすごい量の仕事をこなしている人よりも、明確な優先順位付け、迅速な意思決定、高いスキルで、早く仕事を終わらせる人を評価する
- 委譲する
- 仕事が他の人にも可能になるよう言語化し、移植する
- 自分自身は、どんどん違う仕事にチャレンジしていく
- メンバーのやる気を起こさせる
- 期待を寄せる
- 真剣にフィードバックをする
- 新たなことを学ぶ機会を提供する
- 成果を出せば褒める
- 成果を出さなければ指摘する
- スキルを共有してチームに貢献したいと思わせる
参考
- 抽象度の高い仕事の進め方 - Konifar's ZATSU
- "提案"のレベルを上げる - Konifar's ZATSU
- タスクの目的と担当と期日を決めろ - Konifar's ZATSU
- 抽象的な期待を自分ですり合わせるスキル - Konifar's ZATSU
- 無駄な議論を減らすために使ってる言葉 - Konifar's ZATSU
- 何が事業貢献なのか分からなくなっていた伊藤直也さんが再認識したユーザーエクスペリエンスへのコミット - Findy Engineer Lab
- ビジネス、開発、四方山 - しずかなインターネット
- LegalOn Technologies のエンジニアグレード評価基準を公開します - LegalOn Technologies Engineering Blog
- 【公開版】LegalOn Technologies Engineering Job Expectations - Google スプレッドシート
- sunaot on X: "転職ドラフトの査定していて思うのは - X
- LayerXが定義する「幹部メンバー」は？（Q&A） - YouTube
- スタッフエンジニアの道: The Staff Engineer’s Path - Speaker Deck
- 緊急度、優先度の4象限のアイゼンハワーマトリクスについてざっくりまとめる - コード日進月歩
- なんで全員にリーダーシップを求めるの？ - Chikirinの日記
- 【書評】リーダシップを身につけて人生をコントロールする〜「採用基準」を読んで - DevelopersIO
- 生産性 マッキンゼーが組織と人材に求め続けるもの 伊賀泰代 - 管理職おすすめの仕事に役立つ本100冊×2
- リーダーシップ・プリンシプル (Leadership Principles) - Amazon