CTOのsuzukenです。先週金曜日にアマゾン ウェブ サービス ジャパン合同会社主催のイベント「第2回 クラウド時代のエンジニア像とは?」で登壇してきました。
本イベントは、クラウド技術を活用できるエンジニア育成を主としたイベントです。昨今多くのTech Leadersやエンジニアが興味を持つ「エンジニアの成長」をテーマに、複数の成長Tech企業の取り組みを紹介いただきます。また、ご登壇企業様は、いずれも高い技術力で、クラウドのメリットを最大限に活かしたアーキテクチャで事業成長を実現されています。
今回は、チームを牽引するTech Leaderからエンジニアの成長を支えるための制度や環境についてお話いただきます。また、チームメンバーであるエンジニアから自身の成長の実現方法についてお話いただきます。Tech Leadとエンジニアそれぞれの目線からお話いただき、エンジニアが成長するためには何が必要なのかを明らかにしていきます。
登壇資料
技術力評価会を軸にした育成の設計
今回は「エンジニアの育成」をテーマに、ということでCARTAでどんな仕組みをもっているかについてお話しました。
CARTAではVOYAGE GROUP時代から10年以上、エンジニアが部署をまたいで相互にスキル評価の仕組みである技術力評価会を実施しています。今回の発表では技術力評価会を中心に、評価時期を1つのリズムとしつつ各事業の現場における学びを転移し、チームをまたいでエンジニアが相互に学べる仕組みとして設計されている点について紹介しました。
CARTAでは新卒エンジニア研修や読書会、Slackでの日々技術談義も数多くなされています。その中で実践知を磨く仕組みとして技術力評価会を育成の軸においています。
自分自身の体験を交えて
今回のセッションでは私自身の体験も交えながらお話しました。私が新卒入社した2012年当時にはすでに技術力評価会は実施されており、そこで他のチームの先輩エンジニアからフィードバックをもらいました。*1
技術力評価会では自身も評価者として他の事業部のエンジニアの評価をする機会が生まれます。当初は他のプロダクトの評価をするなんてどうやったらいいのだろう・・と思いつつ、各プロダクトの事業構造をヒアリングして課題を知るなかで、徐々に社内の各事業についての理解が深まっていきました。また同時に、「他のチームでも似たような課題が発生するのだなあ」ということも経験的に知る機会となり、ある種の安心感も覚えたものでした。
とはいえ評価をするというプレッシャーは常にありました。回数を重ねるごとに、これをずっとこなしてきた先輩エンジニア陣のフィードバックをみながら「すごいなあ、こういうフィードバックを書けるのかあ」と勉強させてもらいつつ、少しずつ自分の着眼点を育ててもらいました。
「評価会」という名前が生みがちな誤解
これは社内でも話していますが「評価」だから厳しいものなのか・・と捉えられやすくあります。もちろん最終的には等級制度上のグレードに反映されるものなのですが、評価者には、次のように伝えています。
技術力評価会はもちろん「評価制度」であるのですが、それは決して
- 「評価者として被評価者のことを厳しくみて、粗探しをし、批判すること」
が目的ではありません。評価者としてのみなさんには、
- よい点を見つける
- 被評価者自身が気づいていない観点に気づきを与える
- より一層成果をだせるために、アドバイスする
という観点を大事にしてほしいと思っています。誤解を恐れずにいえば、相手を下げ、厳しくみることは形式で簡単です。そうではなく、評価する相手もわたしたちのメンバーであり仲間です。なので、「どうやったらもっとよくなるか」という観点でぜひみてください
なので登壇資料にもあるように、明日の仕事のために「フィードバック」であることをとても大切にしています。
フィードバックを活かしているか?
とはいえコストもかかります。「なんでこの機能をつくってほしいのに、わざわざ貴重な時間を割いて他のチームの評価をしないといけないんだ」等、他のチームのために時間を割くことになかなか理解が得づらい環境もあるかもしれません。
実際に私たちも多くの時間をこの評価会に費やしてます。しかし、続けていくと共に働くメンバーも次の変化に気づきます。
- エンジニアメンバーの着眼点が育ってきた
- 長期的にまっとうなものづくりができるようになった
- 事業が複雑になってきても仕組みが内部的にちゃんと更新され続けている
こうして事業の現場で活躍して成長していくエンジニアメンバーを自分自身も多くみてきました。
エンジニア個々人の状況判断が磨かれ、プロダクト開発の現場での練度があがることは、「事業をエンジニアリングする」組織としてなにより大切なことです。これは私たちが書籍のなかで「フルサイクル開発者」のスタイルとして紹介しているフィードバックの重視と深く関連しています。
"開発したものが運用する"というアプローチでは、システムを開発するチームが運用とサポートにも責任を持つことでdevopsの原則を実践する。責任を外部化するのではなく開発チームに与えることで、ダイレクトなフィードバックループと共通のインセンティブを持つことができるのだ。
これを重視する開発文化が育つなかで、自然と問いが生まれるようになってきました。評価者からは次のような質問がよくされています。
Tech Visionの価値観は、事業をエンジニアリングするなかでのこうした問いから生まれてきたものだと感じています。
まとめ
以上、登壇資料を補足しつつ解説をしてみました。
ウェビナー形式ではありましたが、登壇会場に一同に会しての配信ということもあり、久々にオフラインで技術談義をする楽しさを味わうこともできました。運営の皆様、そして登壇者の皆様、どうもありがとうございました!
*1:当時は異様に張り切って、やったことをすべて盛り込み、早口で全部しゃべりきるというスタイルで実施して、評価者の先輩方にはたいへん苦労をかけてしまったという反省があります…