450-500万

ビジネスコミュニケーション

• 社内のビジネスコミュニケーションの基礎が身についている
１５分ガイドラインを身につけられている
SlackのOJTガイドラインに沿って、毎日のSlackチャンネルの投稿を習慣化できている
何かわからないことがあった場合に、誰に相談すればいいか、あるいはどのチームに相談すればいいかを理解している
必要に応じて、ペアプロ・ペアワークの依頼、相談ができている
Bad News Fastを理解し、ガイドラインに沿った行動を行うことができる
ロジカルライティングの基礎を身につけている
モヤモヤ傾聴の議題において、自身が感じるモヤモヤしている事を話す事が概ねできている（少なくとも過去３ヶ月間全くモヤモヤを話せていないという事はない）
センシングの重要性について理解している

チームコラボレーション

• チーム開発に必要な専門基礎と連携性の基礎が身についている
• 専門基礎
Gitを使ったチーム開発の基礎（Git FlowやGitHub Flowなど）を理解して実践している（ミクシィ社のgit研修を理解しているレベル）
デバッグの基本を理解しツールを利用してデバッグができている（「ログを見ることができている」「printデバッグができる」「標準出力やログに変数の値を出力してデバッグできる」など）
可読性や保守性を考慮したコードを書くことができている
指導があった上でテストコードを書くことができる
適切な粒度のプルリクを出すことができている
レビュアーが意図を読み取りやすく、依頼観点などが整理されたプルリクを書くことができている（プロジェクトでメッセージフォーマットが規定されていれば、そこに沿うことができる）
基本情報技術者試験合格レベルの知識理解がある（取得していないといけない訳ではない）
プラットフォーム、開発言語、フレームワーク、ライブラリに関する基礎知識があって実践で活かせている
• 連携性
業務知識、開発標準、開発プロセス、ドキュメント作成方針、コーディング規約などプロジェクト毎の知識やガイドラインを理解した上で、方針に沿ってチームでの開発業務を行うことができている
チームやプロジェクトの方針に沿って、仕様やマニュアルのドキュメント化を行うことができている
指示を受けた上でインシデント対応を行うことができる
スクラムの基礎を理解している（一冊本を読んだ程度の理解はある）

自律・自学・自責

• 自ら行動する土台となる会社理解があり、必要な学びを自学した上で、責任を自ら遂行できる
Corporate BASICsを理解している
オンボーディング プログラムで1500点を超えるレベルの習熟がある
ZAC「研究開発業務2021＞プロジェクト学習」の調整係数が必要なくなった段階、ハンズオンでの育成担当も外れて自走できる状態になり、必要に応じて自ら相談しにいくだけで業務が進む段階になっている
自身の専門的な技術領域について社内外の勉強会に参加して、学びを深める事ができている
業務時間外も活用して、新しく必要となる技術の基礎は自主的に身につけることができ、日常的にアウトプットする学習習慣が身についている
必要に応じて、英語の公式ドキュメントや一次情報を読むことができる
GitHubで定期的にコードをアウトプットして、コードを書く習慣が身についている
積読の効用をポジティブに捉えた上で、目安として月間の読書量の５倍の積読を行うことができている
職位ガイドラインに沿った能力開発や専門性を身に付けるために、必要に応じたアドバイスをもらうため、メンターとなる相手に自主的に連絡をとってメンタリングを受けることができている
グループの方針を理解した上で、委員会活動に貢献できている
新卒採用に関係するカジュアル面談、オファー面談や説明会の機会があれば積極的に協力することができている

500-530万

アソシエイトエンジニア推奨図書

• リーダブルコード
• Clean Architecture - 達人に学ぶソフトウェアの構造と設計（アソシエイトには少しレベルが高いかもしれませんが，あえてアソシエイトの段階で一読することは勧めたい）
• SOFT SKILLS（技術ではなく，処世術や技術者としての生存戦略として）

520〜570万

ビジネスコミュニケーション

• 社内のビジネスコミュニケーションとして円滑なやりとりができる
結論から意見を伝えることができる
事実と意見を切り分けて話すことができる
特に成果物の完了の定義や最終イメージが関係者間で必ずしも明確でない場合に、例えば２割など途中の完成度や進捗の段階で、レビューやアドバイスをもらう事ができる（ドラフトのプルリクエスト含む）
イテレーションやWBSでのマイルストーンを理解し、PMやリードエンジニアなどに適切な進捗報告を行うことができる（少なくとも進捗管理を担当する役割の人が困る事が無いようにできている）
モヤモヤ傾聴の議題があった時に、他人のモヤモヤに対してすぐに解決策を提示せずに、まずは聴くことができる
センシングを行った上で、会議の参加者に感じたことを伝えることができる

チームコラボレーション

• チーム開発における専門性と主体性を備えている
• 専門性
全体システムの設計思想、方針を理解した上で、担当する機能実装についての詳細設計を独力で実施できる
ログの観察、ブレークポイント設定、クライアントツールやキャプチャツール、テストコード実装など、デバッグに必要なツールや手法の基本を理解し体系的なデバッグを実践できている
可読性や保守性、トレーサビリティを踏まえたプログラム実装や、エラーハンドリング設計をした実装ができる
単体（Unit）テスト、機能（Feature）テスト、E2Eテストを意識的に使い分けられる、外部サービスに依存する部分をモック/スタブに置き換えてテストできる
アドバイスや支援をもらった上でセキュリティを考慮したコードを書くことができている
実施の必要性の相談をした上で、最適化されたリファクタリングを行うことができている
実装を担当する開発について工数見積もりを行う事ができる
• 主体性
開発標準、開発プロセス、開発環境、会議設計、ベロシティ、チームの関係性の質について意見や改善提案を主体的に行う事ができている
仕様について自ら関係者に働きかけて合意形成する事ができる
リードエンジニアなどに方針を確認をしながら主体的にインシデント対応を行うことができている
プリセールスにおいて、チームの状況に応じて営業と共に商談に参加した上で、ヒアリング、提案対応を主体的に行うことができる。

自律・自学・自責

• ビジネスプロフェッショナルとして質の高い仕事を行う事ができる
仕事を行う際には、適切な粒度のチケット、タスクに分解されているか確認した上で作業を行うことができている
チケットやタスクリストの中から作業を行う場合は、優先順位や依存関係を理解、考慮した上で作業を行うことができている
認定アトミック・スクラム　アソシエイト相当レベルの自己管理能力を保有している
特定の技術領域において専門性を持った上で、アソシエイト職位に対して、仕事の進め方についての指導や成果物レビュー（人格否定は行わず、成果物の品質に対してレビューができる）を行うことができる
自身のキャリアや成長目標を「キャリアプラン」としてNotionに記載して、チームメンバーに共有できている
自身の強みだけでなく弱みや苦手なポイントについて、Notionに「トリセツ」としてまとめて、チームメンバーに理解してもらっている（トリセツは自身のSlackのOJTチャンネルからリンクでたどれるようにしている）
アソシエイトに対して、グループの方針や委員会活動の方針を伝えることができる
チームのレップとしての役割を果たした上で、グループの方針や委員会活動について意見を出す事ができている
新人のバディ担当としてオンボーディングを支援する事ができる
採用に関係する取材の機会やカジュアル面談の機会があれば積極的に協力した上で、会社の基本方針を理解した上で、問題なく説明ができる

プロフェッショナル職位推薦図書

• エンジニア組織論への招待
• ソフトウェアテストの教科書　（こちらの書籍は異論があると思います）

570〜620万

ビジネスコミュニケーション

• 幅広い関係者とのコミュニケーションをビジネスインパクトを考慮して行うことができる
社内だけでなく、顧客とのビジネスコミュニケーションも問題なく円滑なやりとりができる
インシデントについて事後分析に積極的に関わり、再発防止策に対して提案することができる
プロジェクトにおいて連携する他職種の業務内容や専門用語などを理解しており、連携性において円滑なコミュニケーションができている
プロジェクトに関係するドメイン知識について、細部まで理解をしていたり、サービスを消費者視点で利用できるプロジェクトであれば、実際に体験した上でのコミュニケーションができている
実施する作業や業務内容が顧客のビジネスにどのようなインパクトを与えるかを理解していて、不明な点は確認している
センシングを、社内会議だけでなく、顧客との会議においても実施することができている

チームコラボレーション

• 特定の技術領域についての高い専門性を保有し、プロフェッショナルの指導をすることができる
• 高い専門性
可読性や保守性、テスト容易性、変更容易性、耐障害性、追跡可能性を考慮した上で、安定して本番反映可能なコードを書くことができる
仕様書（顧客と合意した各種ドキュメントの総称）の新規作成及び定期的な更新を行い、特に重要な部分の情報については最新で正しい状態を保ち、履歴を記録管理することができている
テスト観点を考慮して、テストケースを作成する事ができ、必要に応じて機能テスト仕様書、非機能テスト仕様書を作成することができる
保守運用においては、自動化・効率化を行うことが普段からできている
技術的負債の削減のため、計画されたリファクタリングを行うことができる
システム全体のアーキテクチャの設計思想や方針を理解した上で、サブシステムの設計や実装を行う事ができる
仕様が複雑な部分であったり、サービスに影響ある部分の開発も担当する事ができる
セキュリティやパフォーマンスといった非機能要件を考慮したコードを書くことができる
応用情報技術者試験で出題される範囲の内容について基礎的な理解がある（取得していないといけない訳ではない）
• 指導力
リードエンジニア業務の一部の業務（合意形成、リスク洗い出し、進捗管理など）を補佐することができる
特定の技術領域についてのプラットフォーム理解、言語仕様、フレームワーク、ライブラリなどについて深い理解があり教えられるレベル
技術標準の選定ができる
プロフェッショナル職位へのコードレビューやペアプロ・ペアワークなどを通じて開発についての指導ができる
１年先には導入が必要となる新しい技術について調査・検証を行っており、勉強会などで啓蒙・事前共有ができている
テストコードを普段から当たり前に書いており、プロフェッショナルに指導することができる
工数見積レビューができる
プリセールスにおいて、営業と共に商談に参加した上で、顧客に直接質問をしたり、前向きに進める意見を出したり、ネガティブリスクについて指摘をする事ができる

自律・自学・自責

• 高い自己管理能力と、連携に必要な周辺技術理解、組織貢献ができている
特定のプロジェクト、プロダクト、チームに関わらずに独力で成果を出すことができている
認定アトミック・スクラムのプロフェッショナル相当レベルの自己管理能力を保有している
特定の専門領域だけでなく、関連する周辺の技術領域についても、実際に手を動かしてみて理解している
推薦図書で書かれている書籍の内容について理解している
他社のカジュアル面談を定期的に受けるなど、自身の人材市場評価や今後の成長機会点など、キャリアの可能性を考える機会を作る事ができている
職位に関係なく関わるメンバーに対して良い点（Good）だけでなく、今後の機会点（Next）もフィードバックすることができる
グループの方針や委員会活動について改善提案やJIKKEN的な取り組みについて提案することができる
採用関係のコーディング試験のレビューを行うことができる

600〜650万

ビジネスコミュニケーション

チームコラボレーション

• 高い専門性
技術的負債の削減・返済についての計画を行い、主導的な役割を担って解決を行う事ができる
各種設計パターン、設計手法を理解した上で、リードエンジニアのレビュー・支援をもらいながら基本設計を行う事ができる
チームが担当する機能の実装容易性や実装可能性を損なう事が無いように、前行程での仕様の確認、合意形成、連携する関連システムとの仕様調整などを行う事ができる
• チームマネジメント
チーフ・プロフェッショナルに対してプロジェクトリードの役割の一部を任せた上で育成、指導を行うことができる
インシデントについて事後分析を行い、再発防止策を立ててチームに定着させることができる
メンバーに対して中期的なキャリアの観点からフィードバックすることができる
チームメンバーの強みや弱みを理解している
チームのタスクの優先順位を理解している
チームメンバーの負荷状況を把握している
チームに新しく参画するメンバーのオンボーディングプログラムの改善を行う事ができる
システムコーチやリードエンジニアの支援をもらった上で、チームの関係性の質を高めるための対話の場を作ることができる
チームのメンバーが意見を言いやすい場作りができる
チームメンバー同士での定期的な振り返りの場を作ることができている

650〜720万

• 標準を超える難易度が高いプロジェクトにおいても、プロジェクトリードとして３つのコアバリューの発揮が十分に認められた段階

ビジネスコミュニケーション

チームコラボレーション

• 高い専門性
技術的な高い専門性を持っていて、特定のチームやプロジェクトに依存せず、リードエンジニア業務を独力で行うことができている（必須）
実際に複数のプロジェクトや異なるチームメンバーとの組み合わせでリードエンジニアとして業務を独力で行った実績がある
顧客企業のエンジニアチームと共同開発を行う内製化支援業務においても、顧客からリードエンジニアとして技術的に評価されるレベル
技術的負債の返済についての方針策定を主導して行い、自ら複雑な部分の解決も行う事ができる
• チームマネジメント
設計方針、実装方針、ドキュメント方針、会議設計、役割分担などプロダクト開発に必要な内容を明確に文書で定める事ができている
チームメンバーの強みや弱みを理解し、チームの成果を最大限発揮するような役割分担を行うことができる
例えば、ドラッカー風エクササイズなど、チームビルディングや関係性の質を高めるために必要な施策を選択し、実行することができる
タスクの優先順位を理解した上で、チームメンバーの負荷状況を考慮しながら、適切な粒度のチケット、タスクでメンバーに分担することができる
タスクの進捗状況を積極的に把握した上で、遅れているタスクに対して適切な解決を行うためのアクションを行うことができる
チーム全体に関係する工数見積もりを取りまとめることができる
必要に応じて、スクラムマスターの役割を担う事ができる
サブ・リードエンジニアに対してプロジェクトリードとしての支援、育成を行うことができる
チームのメンバーが新しい挑戦やJIKKENを行うことを推奨し、挑戦行動に対してポジティブなフィードバックを返すことができている
意見をあまり言わないチームのメンバーがいた場合に、配慮して意見を聞き、居場所をつくってあげることができる
チームの関係性の質を高めるための対話の場を設計、用意することができる
メンバー同士のピア・フィードバックを行う場づくりを定期的に行うことができた上で、自分自身への今後の機会点（Next）も含めたフィードバックを積極的に受けるようにできている

720〜800万

• 社内でも手本となるリードエンジニアである

800万〜1000万

マルチスタックの例

• iOS、Androidの両方の技術の専門性を持った上で、iOS、 Android両方のプロダクトの設計理解、コード理解があるため、モバイルアプリに関する仕様調整を手戻りなく、実装容易性も考慮した上で、統合的にリードできる場合となります

マルチハットの例

• アーキテクトあるいはプロジェクトマネージャー（チームビルディング・プリセールス・顧客折衝・リスク管理など）の役割も兼務して担うことで、プロジェクトの高い品質や生産性に貢献できる
• 社内のグループ全体の委員会活動、あるいはグループを横断した委員会活動をリードできるレベルでのプロセスマネジメントを兼務して担い、組織に貢献できる

700万〜

800〜900万

行動指針の参考

良いテックリード、悪いテックリード - 小さなごちそう

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。ベン・ホロウィッツの「 良いプロダクトマージャー、悪いプロダクトマージャー 」からインスピレーションを得ている。 ...

tannomizuki.hatenablog.com

900〜1000万

700〜800万

技術理解

以下の技術の利用経験があった上で

• コンピューティング(EC2)
• ネットワーク(VPC)
• ロードバランシング(ALB/NLB)
• データベース(RDS/Aurora)
• ストレージ(S3)
• メトリクス(ClodWatch Metrics)とログ(CloudWatch Logs)
• コンテナ(ECS)
• サーバレス(Lambda)
• CDN(CloudFront)
• キュー(SQS)

• データ分析( Firehose、Athena)
• OLTP(Redshift)
• CI/CD( CodePipeline, CodeBuild. CodeDeploy)
• アプリモニタリング( AWS X-Ray)
• セキュリティモニタリング(Amazon GuardDuty)
• アイデンティティ( Cognito )
• コンテナのロギング(Firelens)

リードアーキテクト

800〜1000万

技術理解

• ビックデータ(EMR)
• ETL (Glue)
• サービスメッシュ(AWS App Mesh)
• Machine Learning系
• シングル・サイン・オン(AWS SSO)

650〜700万

• 社内でマイスターエンジニアと認められた段階
（重要項目）グループにおいて上位１５％以内の生産性を誇っている（例えば、Findy Teamsなどで測定される項目において）
プルリクの修正理由が詳しく書かれていてレビューしやすい
レビューで実際に動作確認をきちんとして、責務の切り出しや具体的な改善案を丁寧に出すことができている
繰り返し作業を自動化、短縮化している
周りがなかなかやらないが、やらないといけない作業を率先してやっている
将来の懸念点やリスクを事前に的確に予見し、意見することができている
複雑な仕様であったり、サービスに重大影響ある領域（決済や会員基盤、金銭や個人情報に関わるなど）の開発を品質高く開発する事ができる
技術的負債が大きく、まとめて影響範囲大きいリプレースやリファクタリングが必要なコードベースについても、推進力持って負債の返済を行う事ができる
ユーザー体験を考慮した上で、提案、意見を出すことができている
疑問点を調べるだけでなく、一段深いレベルで物事を理解する事を行なっている
ドキュメントにおいては無駄な情報を整理した上で、定期的に最新化し、初めて見る人にもわかりやすく構造化、言語化するなど考慮できている
一つの観点や自分なりの流儀に拘らずに他者視点、多角的な視点を持った上で議論をすることができている
指示を鵜呑みにせずに、前提や目的を確認したうえで、目的に沿っているかを理解している

700万〜1000万

• 社内で実績あり手本となるマイスターエンジニア。
• グループにおいて上位１〜５％の生産性を誇っている（例えば、Findy Teamsなどで測定される項目において）
• 大規模なサービスにおける重大な影響ある領域（決済や会員基盤、金銭や個人情報に関わるなど）の開発を品質の高さに加えて、生産性高く開発する事ができる

• マイスターエンジニアがリードエンジニアの役割も担う場合
• 但し、マイスターエンジニアとして重要なチェック項目である上位１５%の生産性を誇る部分は必須項目とすること
• 逆に生産性が低いリードエンジニアについては減算要素になり得る

• 緊急的な状況ではリードエンジニアを自身で行いながらも、リードエンジニアの育成対象がいる場合は、リードエンジニアの支援的、教育的な役割にシフトして、技術的な支援に専念するなど、柔軟にリードエンジニアからテックリードの役割を変化させることができる
• ただし、単に兼務しているだけではなく相乗効果が発揮できることも必要

• サーバーサイド、フロントエンドなど連携性が高い２つ以上の技術領域において専門的な知識、経験を保有するチーフ・プロフェッショナル以上のエンジニアを指す
• 特に技術領域として連携性が高く、例え疎結合に設計されていたとしても、責務範囲を切り分ける際には、実装容易性などを考慮した詳細設計が必要であるため、複数分野について精通している事が将来的な保守性やコードの複雑化の回避に影響する
• リードエンジニアのようにチームをリードする役割でなくても、詳細設計、高い品質をリードしていくという役割としてフルスタックエンジニアの役割が期待される場合がある
• サーバーサイド、フロントエンド、インフラの３領域に渡って、チーフ・プロフェッショナルであるマルチスタック・エンジニアをフルスタック・エンジニアと呼ぶ。Netflixのような大規模なマイクロサービスアーキテクチャを採用する中で、フィーチャーチームが確立されていれば有用な役割ではあるが、ゆめみではフルスタックが求められる場面は多くはなく、アーキテクトとしての役割として複数技術理解が必要となる場面の方が多い。一方で、アーキテクトであっても全ての技術領域を教えられるレベルになるには難易度が高く、サーバーサイド寄り、フロントエンド寄り、モバイルアプリ寄りに分かれる。
• モバイルアプリエンジニアについては、iOSエンジニア、Androidエンジニア、Flutterエンジニアの3つの技術領域において2つ以上の理解を必要とする。
• フロントエンドとUIデザインを２つの領域での専門性がある場合は、UXエンジニアと呼ぶ
• コーポレートエンジニアリングにおいては高いレベルになると、フルスタックかつフルサイクルが求められる

• プロダクトオーナーあるいはスクラムマスターというスクラム における役割を兼務（帽子の被りわけ）ができるエンジニア
• チームビルディング初期ではなく、スクラムチームが安定してきた段階では、エンジニアがスクラムマスターを兼務したりすることも実施できるようになる
• あるいは、プロダクトに一定期間関わることによって業務知識を深く理解することになり、プロダクトオーナーの役割の一部を担うこともできる（例：エピックプロダクトオーナー など）
• 兼務することによってチームとして、スクラムマスターが一人に依存してしまう問題を回避したり、プロダクトオーナー の負担を軽減することにつながる

• 継続的なディリバリーフェーズのプロジェクトを担当する
• リード・エンジニアとしての能力に加えて、ヒアリング、要件定義、DevOps、窓口対応も行う事ができ、プロジェクトの要件定義フェーズからリリースまでの全ての工程において、複数の役割を一連して行うことができ、通常では発揮できないプロジェクトのクオリティ、アジリティの両立と、一人何役もの高い生産性の発揮をすることができている
• グロースハック、コーポレートエンジニアリング、プロトタイピングなどで活躍が期待される