エンジニアの働き方を考える
安尾友佑氏（以下、安尾）：では、次の質問です。「人をチームに加える際、オンサイト、フルタイムは重要だと思いますか？」。いかがでしょうか。オンサイト、フルタイム。リモートや週3勤務を許容するかどうかですね。
南野充則氏（以下、南野）：チームの状況によるかなと思います。変化が激しいプロジェクトだと、リモートでやっていたりフルタイムではない場合は時間の制約もあって置いていかれてしまうこともあると思います。そういう場合はオンサイト・フルタイムで一緒にやったほうが効率がいいと思います。
ですが、長期で粛々とやっていくプロジェクトもあると思うので、その場合はリモートでも仕事内容や課題、目的を伝えればやれると思っているので、チームの状況や会社のフェーズによって重要度は変わるのかなと思います。
芹澤雅人氏（以下、芹澤）：まったく同じ意見です。弊社はフェーズとしてはまだまだ成長期であり、組織もプロダクトもどんどん大きくなっています。変化が激しいゆえにリモートはあまり推奨していなくて、みんな出社して仕事をしています。
過去にリモートワークのトライアルをしたこともあったのですが、PM との仕様のやりとりなどはテキストだと限界があって。「じゃあ電話すればいいじゃん？」って話もあるんですが、そこにはやはり心理的なハードルがあったり。
もちろん、先ほど南野さんがおっしゃったとおり、会社の成長が落ち着いてきたら、検討するのはありかなとは思います。
安尾：クラウドワークスさんの場合はけっこうリモートでやられていると思うので、ぜひおうかがいしたいです。
飯田意己氏（以下、飯田）：弊社は全社員フルフレックス・フルリモートでやっています。もともとエンジニアの中から始めてフィジビリして全社に展開したんですけれども、やはりチームビルディングが前提にあるのは本当に大事だと思っています。関係性ができていないのに違う場所でやるのは制約をどんどん増やしていくことになるので、それでチームワークなんか生まれないよねという話はあります。
始める際には、各チームどんなリモートワークをするか、どうフレックスに働くかは、チームごとにルールを決めてもらってやっています。
そこを踏み切った理由としては、子育てエンジニアが増えてきて、そういう人の中ですごく優秀な人がいたときに、「週に何回かは来てくださいね」というのをルールとして会社が決めてしまうと、その人にとってはできない人のための制約に自分が合わせることになってしまいます。
なので、本当に性善説で、できる人がちゃんとできるように、制約に縛られずに自由にパフォーマンスを上げていただけるようにということで、課題はいろいろありますが性善説の方に振り切りました。
エンジニアの評価をどうするか？
安尾：次に、また難しそうな質問が来ているのですが、「エンジニアの評価は難しいと思うのですが、意識していることはありますか？」という質問が来ています。評価はどのレイヤーの評価をされていますか？ 全体的に見られている感じですかね。
飯田：今は全体的に見ています。おそらく各社目標設定の仕方や評価の仕方は違うと思いますが、弊社の場合は「この期間にこういうものをどういうふうに定量評価するのか」みたいなことを個人個人で決めてもらって、それをもとに、評価を行う形です。
やはりエンジニアそれぞれのレベルによって、目標設定の観点がバラバラになるじゃないですか。人によっては普通に達成できそうな目標を出してくる人もいるし、人によっては目標が高すぎて達成できるイメージがわかない人もいるので。
そのあたりを全体でうまく合うようにアジャストしながら、1on1で「もうちょっと攻められるんじゃない？」とか「将来どんなキャリアにいきたいか」みたいな話をもとに、「今のフェーズではこのあたりをチャレンジしておくといいかもね」みたいな話をもとに、それがうまいこと達成できたらそれで評価していくという流れです。
芹澤：僕もエンジニア全員の評価に関わっていて、意識していることは2つあります。1つは目標設定です。僕らもOKRのようなやり方をとっているのですが、目標設定ってその人の成長につながるような目標を前提として考えなければいけなくて、会社の都合というよりは、その人がエンジニアとして半年でどれぐらい成長できるか、その成長を通して会社にどれぐらい貢献できるか、を考えた上で目標設定をすることが大切です。
もう1つは評価制度的なところです。前提として、完璧な評価制度を作るのはかなり難しいことだと思っています。エンジニアは定量的に成果が測れない、定性的なアウトプットがほとんどなので、そこに対して客観的な評価を下すことは厳密には無理という考えのもとに動いています。
ある程度主観的な要素がどうしても入ってしまいますが、評価者と被評価者の間に信頼感を構築し、自信を持って評価を決め、それに対して双方の納得感を得ることが重要です。
変な話、評価制度があまり整っていなくても、「この人に言われた評価なら納得がいくよね」のような信頼関係があれば、それはそれで問題ありませんし、逆に、その信頼関係がない場合は、どんなに整備された評価制度でも機能しないと思います。
安尾：ありがとうございます。ちなみに、上司と部下との信頼関係ってどういう感じで評価されているかってあったりしますか？
芹澤：正直ちゃんとはわからないですね。例えば、1on1で悩みが聞けているかとか。1on1というのは対象者の話を聞く場なので、「メンター側がずっとしゃべってないか？」とか「課題を聞き出し、それの解決に向けた動きができているか？」は気にしています。
FiNCにおけるエンジニアの評価
安尾：なるほど。南野さんいかがですか？
南野：評価が難しいと思ったことはないですね。たぶん評価が難しいのってエンジニアが少ない組織なのかなと思ったりしています。一定量を超えると評価しやすくなってくるのかなという実感はあります。
うちのやり方としては、行動指針の360度評価とOKRの結果、「半年で何しましたか？」というところを見て評価しています。
しっかりグレードを定義しているので、グレード同士でどんな結果を出したのか、1個上のグレードの人たちはどんな結果を出しているかを比べていけば、一定、上から順番に並んでいくなと思っています。例えばじゃあグレードごとに給与テーブルを決めて査定をするみたいなところでいけるのかなと思っているのと。
あとは、行動指針を360度評価することによって、部下が上司を評価することもできますし、上司が部下を評価すること、同僚が同僚を評価することもできるので、その数字をもとに意思決定していけば、評価はそんなに比較的難しくないかなと個人的には思っています。
安尾：なるほど。今のグレードの話なんですが、グレードの基準を作るときに技術的な観点であったりソフトスキル的な部分であったり、いろいろな軸があって一概に評価しづらいということが想定されてたりするのかなと思うのですがそこはどうしていますか？
南野：これも、人数が多ければ多いほどグレードは作りやすいと思っています。なので、例えば30人いたら30人の成果を半年並べ、それを上から順番に並べたときに、ここまではレベルが一番高い人、ここまでが次にレベルが低い人、みたいなことを5段階でクラスに分ければ、まずは5段階のグレードができます。
さらに、その人が伸びていくためには、その人たちの1個上のグレードはどういう人たちなのかを定義しておけば、グレードはちゃんと定まるかなという印象ですね。
安尾：ありがとうございます。
会社の強みを考えよ
安尾：それでは、最後に今回のテーマに立ち戻って、今日来られた方に今CTOやVPoEのような立場でやられているみなさまからアドバイスするとしたらというか、これからどういうキャリアをエンジニアとして歩んでいけばいいのか、アドバイスをお願いします。
芹澤：難しいですね（笑）。
安尾：そうですね（笑）。ちなみに、エンジニアを始めて3年未満の方はどれぐらいいらっしゃいますか？
（会場挙手）
安尾：なるほど。4年以上10年未満の方？
（会場挙手）
ありがとうございます。10年以上？
（会場挙手）
ちょっとバラけてますが、比較的中堅ぐらいまでが多いのかなという印象を受けました……。
（一同笑）
南野：なにも情報がないですね。キャリアの話をしますか？
安尾：そうですね。キャリアの話を。
南野：キャリアは一般論としては3パターンあると思っています。技術を突き詰めていく方と、VPoEとしてやっていく方、あとはプロダクトマネージャーになってプロダクトを引っ張っていくという3パターンがあるかなと思っています。
そのなかで、今日はエンジニアの方が多いと思うので、テックリードのレベルを上げていくために何をすればいいのかを考えた時、最終到達点としては会社の技術やアーキテクチャをどうしていくのか、どこを強みにするのかは考えていくべきだと思います。
それを分解した上で、今担当している機能が自分のどの場所に当たるのかは意識して仕事するべきだと思っています。自社が何を強みとして目指して技術を尖らせているのか。それに対してプロダクトのロードマップはどうなっていて、今の自分の役割が何なのかを考えて日々行動することですね。
その会社で突き詰めていくならば、どういう知識をつけていけばより会社に役立つのかを考えることもできると思うし、例えばRubyをやっているのであれば、Rubyがどう発展していくのかを考えて、Rubyを使えばRubyの開発者になっていけると思うし、それはほかの会社に行ったら役立つ技術だと思うので、自分のやってる場所から2個3個上の目線で日々技術を追っていくことが大事かなと思います。
安尾：ちなみに、その2個3個上の目線で技術を追うときになにか意識することや、コツはありますか？
南野：それでいうと、会社であればCTOと会話することだと思いますし、CTOの下のテックリードの方と会話して、「自社の強みって今は何で、技術は何を尖らせていく予定なんですか？」「今の自分の担当しているプロダクトは何をロードマップに技術を見てるんですか？」という会話を一緒にするべきだと思うし、それを自分で提案していく姿勢がすごく大事かなと思います。
例えば自分が使ってる言語のコミュニティだとそれを作っている方やカンファレンスで登壇している方とコミュニケーションとって、自分も登壇するべきだと思うし、そのなかで登壇している人とコミュニケーションとって、どういうところを追っていけば自分もそういう人材になれるのかを逆算して考えることが大切だと思います。
スペシャリスト以外のキャリアを考える
芹澤：今のがいわゆるスペシャリストというか、1つの技術分野を突き詰めていくタイプのキャリアだとしたら……この中で「技術1本でやっていくのにはちょっと自信がないかも」って人はどれぐらいいますか？
（会場挙手）
あっ、けっこういますね。実は僕もこの口だったんですよ。
文系出身で、プログラミングはできるけど、僕が社会人1〜2年目の頃ってマシンラーニングがすごく流行ってた時代で、自分もイキってたので手を出してみようと本を買ったんですけど、数式だらけなんですよね、あれ。統計学みたいな世界になってきて、それでもうくじけてやめてしまいました。
その時に自分のキャリアに悩みました。世の中できる専門家はゴロゴロいるんだなって思って、その時にスペシャリストになるのは諦めたんですよね。結局どうしたかというと、いろんな分野を広く浅くやってとにかくいろんなことを知っておくようにしました。一つの分野では勝てないけど、分野の組みわせで勝ちに行く作戦です。
おすすめなのが、今Advent Calendarってやってるじゃないですか。Engineering Manager Advent CalendarというのがQiitaにあって、それの1日目の記事に、さっき紹介があった『エンジニアリング組織論への招待』という本を書いた広木さんの記事があって。EMに必要な知識を一覧にした記事なんですが、それを読んだとき「さすが」って思いましたね。
技術のことだけではなく、ファシリテーション能力やコーチングのテクニック、チーミングのテクニックなど、必要とされる知識が体系的にまとめられていて、「これを得るためにはこの本を読みましょう」みたいなことが紹介されているんですが、そういうジェネラリストタイプだと思う人は、あのブログを見てちょっとずつ手をつけていくのがいいのかなと思います。
自分が責任を持てる範囲を広げる
安尾：ありがとうございます。ぜひ読みましょう。では飯田さんお願いします。
飯田：お二人ともいい話をしてたので、あと何を言ったらいいかなって感じですけれども（笑）。
今、スペシャリストとジェネラリストの話がありましたが、例えばうちのエンジニアにキャリアの話をするときに言っているのは、自分の責任を持てる範囲をどんどん広げていきましょうと話しています。
最初はチームの中の1つの施策の設計を考えるところから始まって、チームでやる領域の全体的な設計を考えたり、戦略を考えたりすると思います。そこからさらに広がってプロダクト全体、会社全体の技術の戦略を考えていくことにチャレンジしましょうということです。テクノロジーの部分でもそうですし、組織という領域でもどうやって影響力を広げていくかということは、同じ考え方なのかなと思います。
具体的なものもそうですし、影響する範囲が広ければ広くなるほど、扱う議論の抽象度が上がっていくと思うので、具体的な話と、「外側から見たときにそれが全体最適になってるんだっけ？」みたいな、具体の話と抽象の話を行ったり来たりすることが求められていくと思います。影響範囲を広げていくということを考えてキャリアを積んでいくと、給料もついてくるのかなという気がします。
安尾：では、時間になりましたので以上とさせていただきます。ありがとうございました。
（会場拍手）
