どうも、大曲です。
リモートワークにも慣れて来ました。
今回は技術に特化した人材のための「技術ごとのスペシャリスト制度」の背景や責任部分を紹介します。
初めはコントリビューターという名前にしていたのですが、浸透しなかったりしてこの名前になりました。
※アドウェイズ全体の制度ではありません。あくまで自分が管轄している組織の話です。
この制度が出来るまでのタイムライン
最初は自分一人で動きや成果を検証しつつ作っていきました。
徐々に関わる人を増やしていき最終的に2020/04に制度として確立させました。
そのため、この制度にたどり着くまで1年以上かかりました。
この制度に関わった人の人数の変化。
各技術ごとの取り組みの動き。
現在はScala、Vue.js(TypeScriptも含む)、Ansibleの３つの言語でこの制度に基づいて改善などを行なっています。
目的
特定の技術（主に言語）に特化したメンバーで集まり、組織内における技術の知見やコードの管理を行う。
背景
「チーフ＝技術的プロデューサー」としてサービスチームの技術的バランスに責任を持っています。（チーフ定義）
チーフは技術的基盤を一から作ったり技術調査をするのは必須ではなく、技術をどう活用し、運用していくかが目的です。
ただし現状ではどうしてもチーフ自ら調査をしたり、教育の資料を作成したりする作業が発生しやすいです。
また、サービスを支える技術が昔と異なり多様化しており一人（チーフのみ）では対応できなくなっているのが現状です。
軽く今と昔をまとめるとこんな感じかなと思っています。
| 範囲 | 昔 | 今 |
|---|---|---|
| 言語 | Perlだけでおk | 言語（Perl,Scala,Vue.js,TypeScript）がたくさんで網羅できない 自分が勉強するだけで一杯で教育まで行き届かない 品質担保の方法が増えた（テストコードやE2Eサービス） |
| インフラ | インフラ部署が良しなにする 手順書でカバー |
インフラも考える必要あり（クラウド） アプリケーションの特徴を知った上でのインフラ構成が当たり前になった 手順書やインフラ自体のコード化が進んだ(Ansible、Terraform) |
| 設計 | シンプルな構成（PerlとMySQL） | 色々なミドルウェアがある構成（MySQL,Redis,Memcached,BigQuery,Fluentd） |
| ツール | チャット | 開発環境のツールたくさん。Slack、CI/CDツール、Bot、Docker |
スペシャリストがいないことでの課題
これらの状況から課題が二つあります。
- バランスは取れるが技術的価値の最大化が出来ない
- 技術的な価値の低下に気づかない
下記のグラフは縦軸が技術的価値、横軸が時系列です。
時間とともに技術的価値は低下することをイメージできるグラフです。
サンプルとして例を挙げます。
下のグラフだとインフラの改善を行ったからインフラの価値（縦軸）が上がることを表しています。
バランスは取れるが技術的価値の最大化が出来ない
特定の分野を専門的にやれるわけでは無いため、新しい技術を利用した価値の最大化までは実施することが難しいです。
（時間的にもリソース的にもやるタイミングが無いなども理由にあります）
技術的な価値の低下に気づかない
特定の分野を専門的に行うわけでは無いので、チーフのみでは判断ミスもあると思います。
このような課題があるため、技術に特化した制度を確立しようと考えました。
責任
技術ごとのスペシャリストには３つの責任があります。
- 展開責任
- 知見蓄積責任
- 教育責任
ちなみにチーフには以下の責任があります。
- 運用責任（サービスの運用に責任を持つ）
導入責任（サービスで導入する技術に責任を持つ）
強制的な導入には逆らえない場合もあります
例：クラウド化が嫌だと言っても組織としてやる判断を上司が行っているため拒否権が無いパターン
この場合は組織的な判断なため仕方ないです（どうしても拒否したいなどは）
展開責任
スペシャリストとして保持している知見を各チームに展開する責任です。
Scalaの新たなアーキテクチャやライブラリの情報をチームに共有し、
チームが自分たちで使いこなせるまでサポートします。
知見蓄積責任
チーフを筆頭に各チームで技術的な調査や検証を行なっています。
その内容を棚卸しやヒアリングなどを行い、スペシャリストの人たちが吸収します。
（最終的には他のチームに対して知見の展開まで行います。）
スペシャリストの人達だけが技術的な挑戦をする特権を持っている訳ではないです。
技術的な挑戦は誰がやっても問題ないと考えてます。
そのため、スペシャリストの人たちは色々な人がやった挑戦をきちんと吸収して組織全体の最適化のために役立てて欲しいと思っているためこの責任を追加しています。
教育責任
特定の技術の底上げのために教育を実施します。
内容は各チームごとで異なるためチーフと連携して実施します。
仕事内容
- テンプレートリポジトリの管理
- 教育方法の管理
- プロダクションコードの棚卸し
- 技術の検証
この仕事内容の詳細は改めてブログで紹介したいなと思っています。
デリゲーションポーカー
テクニカルマネージャーが（以下「テクマ」という）上司に当たります。
チーフの上司でもあります。
組織全体の判断やこの制度を通した成果に関わる責任はテクマが持っています。
コードの品質やツールの選定などは譲渡しています。コードの品質やツールの選定などは譲渡しています。そうすることでスペシャリストが技術のみに打ち込みやすくしています。
補足：
1. 命令する ：テクマとして意思決定を行う
2. 説得する ：テクマが意思決定についての技術ごとのスペシャリストを納得させる
3. 相談する ：テクマが決定する前に、技術ごとのスペシャリストからの意見を得る
4. 同意する ：テクマと技術ごとのスペシャリストと一緒に決定を下す
5. 助言する ：テクマが技術ごとのスペシャリストによる意思決定に影響を及ぼす
6. 尋ねる ：テクマが技術ごとのスペシャリストの決定後のフィードバックを求める
7. 委任する ：テクマは特に影響を及ぼさず技術ごとのスペシャリストに任せる
仕事の割合に関して
スペシャリスト用として20％まで利用できるようにしています。
半期で1ヶ月分は確保できるため技術の検証などを考慮すると十分ではないかと考えました。
Ansible moleculeの検証はこれくらいかかりました。
時間=48h（週3日分は対応していた）
着手期間=07/10 ~ 07/23
まとめ
スペシャリスト職とまでいかないですが、技術ごとのスペシャリストに関する制度として紹介しました。
自主的に行われる勉強会の集まりに知見の蓄積や展開の責任が付いた、という感じを自分はイメージしています。
責任がある分リソースを確保できたと考えており、今期からようやく各言語が足並み揃えて方針を共有し改善を行なっているところです。
リソースは確保して良いとしているが実際に各担当者が柔軟にリソースを確保できるかは別なのでこの辺りがまた制度として調整する必要がありそうな気配がしています。
