中級者の定義

アドテクDiv（大曲が所属している部署）では中級者をシニアエンジニアと定義しています。
定義の内容は以下のような感じです。

一人で設計、コーディングまで出来ることがシニアエンジニアの最低条件である。  
ただし、全て一人で解決せよということではない。分からないことがあればきちんと他の者に相談できる。  
ある一定の技術力がありセルフマネジメントが出来ることが重要

教育内容

教育内容は「設計」と「インフラ」の２軸になります。

設計
- 「処理のデータの流れ」と「処理を実現するためのミドルウェアの組み合わせ」の観点の確認や考える練習を行う
- 設計におけるリスクの認識を行うことで考える範囲を広げる
インフラ
- サービスのインフラに対して調査できる人材を目指す
- 構築、チューニング、監視項目の洗い出しなど

今回は設計問題に関して話したいと思います。

初めは実案件の設計のサポートをやろうと考えていましたが、
案件が決まらなかったりと外部の影響が大きかったので設計の練習問題を作りました。

練習問題は広告システムに関連する問題を作っています。
（外部との連携、スクレイピング、配信システムなど）

設計の練習問題の流れ

1日かけて設計の課題を行います。
途中に教育担当者との中間報告的な感じで議論をして
壁打ち相手をしています

1.(30m ~ 1h) 問題の説明
2.(3h ~ 6h) 黙々と設計する
　- 教育担当者と途中で議論する
3.(30m ~ 1h) 発表会
4.(1h 45m) FB会
　- (15m) レビュアーが黙々と評価記入
　- (30m) レビュアー同士で認識合わせと総評をまとめる
　- (30m) 対象者も含めFB
　- (30m) 教育担当者と対象者で振り返り

設計のアピールシート

設計の対象者が記入する項目です。
主に設計での自分なりのポイントとどんなリスクを考えられたかを書いてもらっています。

リスクに関しては全てを解決できるわけではないので
設計でどこを重要視し、どこを削ったのかを明確にわかるようにしました。

「パフォーマンスを考慮して敢えてDBを正規化しなかった」と似たような感じですね。
これも「正規化しないことでDBに格納されるデータ量が増えることになるが検索SQLの処理は速くなることを優先させた」
と判断した結果でもあると思います。そういった考えをこのリスクの項目で分かれば良いなと考えました。

カテゴリ	項目
設計のポイント	重要視したポイント(例：高負荷に耐えられること、データの再利用性)
	設計の一押しポイント(例：Redisをキャッシュとして使い高パフォーマンスを実現した部分)
リスク	この設計で起こりうるリスク(例：キャッシュデータの遅延時に処理がおかしくなる)
	この設計で敢えて無視したリスク(例：キャッシュデータが存在しなくなるリスク)
	今後に起こり得るリスク(例：高パフォーマンスには耐えられないかも)
	対応できなかったリスク解決策が見出せなかったリスク
その他	感じたこと
	良かったところ
	悪かったところ
	要望(こうしてほしい）や希望（こうしたい)

設計のレビュー

評価に関しては以下のスライドの項目とかを参考にもしています。
エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017

アピールシートは主観的になりやすいような感じですが、
レビューする際は客観的に見るために柔軟性やリスクなどの観点を追加しました。

カテゴリ	項目
何が課題で何が必要と考えたか	(実現力)要件定義を満たした設計になっているか？
	(リスク)その場しのぎで考えていないか、先のリスクを見据えているか？
	(アーキテクチャ、MVPの判断)考えすぎていないか。スピードを疎かにしていないか。必要以上にコストを掛けていないか。
	(柔軟性)テスト容易性、変更容易性を考慮しているか
	(セキュリティ面)セキュリティを考慮しているか
	(パフォーマンス)性能、可用性を考慮しているか
その他	成長のためにアドバイス
	気になった点..etc

実際の課題

アピールシート

色々考えています。

f:id:AdwaysEngineerBlog:20181204121729p:plain — アピールシート

レビュー結果

そして色々な指摘が来ます。

f:id:AdwaysEngineerBlog:20181204121852p:plain — レビュー結果

成果物

課題ごとで色々な設計が出来ます。
手書きの図を書いて説明してもらってます。
最初はPCで図を書いてもらってましたが、時間がないので手書きの図に切り替えました。

f:id:AdwaysEngineerBlog:20181204121936p:plain — 広告配信設計

f:id:AdwaysEngineerBlog:20181204122021p:plain — スクレイピング設計

やって見ての振り返り

Good

定性な評価にした部分
- 設計には完璧な答えはないので定量的にしなかったことで議論がしやすいです
意外とレビュアー同士で議論をすることもある
- 「いやーこの観点大事じゃないすか？」や「このリスクはこの案件の時はこう対応した」とか
- こういった議論を対象者が見れるのもいい経験になっているみたいです
レビュアーにもメリットあり
- 「その観点はなかった」「この感じの設計はいいね」とか逆に教わることがある

Bad