1. 設計
1.1. 要件定義からの読み取り
1.1.1. ディレクターからの要件を正確にキャッチアップ
1.1.2. エンジニア側の観点から適切に質問
1.1.2.1. 豊富なドメイン知識
1.1.2.1.1. 日頃の競合他社の研究
1.1.2.1.2. トレンドの把握
1.1.2.2. 現状のプロダクトの仕様の適切な理解
1.1.2.3. システム内のコードの理解
1.2. 設計書の作成
1.2.1. ドメイン知識がないエンジニアでもわかる設計書
1.2.1.1. 設計書のフォーマット化
1.2.1.2. 誰でもみやすいレイアウトに統一
1.2.1.3. ドメイン駆動設計に関する理解
2. 仕事の依頼
2.1. 実装の指示
2.1.1. 設計書をもとに適切な指示を出すことができる
2.1.1.1. 設計に関する質問を0にできる
2.2. 工数管理
2.2.1. エンジニアの実力を理解し工数の調整を行うことができる
2.2.1.1. 工数の延期をプラス3日までの案件を8割にできる
2.2.2. 遅れた場合工数の調整をディレクターと交渉できる
2.3. メンタリング
2.3.1. 質問の要点を押さえて何に困っているか理解できる
2.3.1.1. 質問しやすい環境を作っている
3. 実装
3.1. 実装
3.1.1. Rubyのバージョンアップができる
3.1.1.1. Ruby言語自体に対する豊富な知識
3.1.2. 5割以上を非同期通信で行える
3.1.2.1. JSに関する豊富な知識
3.2. コードレビュー
3.2.1. テストの段階で不具合が報告されないレビュー
3.2.1.1. 設計書を見て今回の仕様を理解できる
3.2.2. 技術的負債を0にするレビュー
3.2.2.1. 無駄なSQLが増えていないか気付けること
3.2.3. レビュワーのFBの回数を3回以内に収めることができる
3.3. 技術
3.3.1. 外部サービスとのAPI接続ができる
3.3.2. プロダクトのリプレイスができる
4. テスト
4.1. テストの自動化
4.1.1. GUIベースのテストの構築、導入ができる
4.1.2. リグレッションテストの自動化ができる
4.2. テストの正確性
4.2.1. カバレッジを計測できる
4.2.1.1. カバレッジ計測ツールの導入ができる
4.3. 不具合
4.3.1. 不具合を迅速で修正できアップ日を遅らせない
5. 運用保守
5.1. インフラ
5.1.1. デプロイ
5.1.1.1. 1コマンドでデプロイが行えるようなインフラ環境を構築する
5.1.2. エラーの検知
5.1.2.1. 課金処理などの重要度が高いもの
5.1.2.1.1. ユーザーの信用を損ねないようにする
5.1.2.2. その他
5.1.2.2.1. Issueを立てて案件の調整をディレクターと行うことができる
5.1.3. セキュリティ
5.1.3.1. 攻撃が来た時に検知ができる
5.1.3.2. 攻撃が来た時に最低限の対処できる
5.1.3.2.1. ログから攻撃内容を理解できる
5.1.3.2.2. いざという時にサーバーとの接続を断つことができる
5.1.4. 構築
5.1.4.1. インフラをコードベースで管理し障害が起こったとしてもすぐに復旧できる
5.2. パフォーマンスチューニング
5.2.1. 重いSQLの検知
5.2.1.1. 影響のあるSQLを検知できるツールの開発