サポートを受けながら、新しい業務や役割に挑戦
実際の仕事における責任について、かつては自分の案件単位だったものが、プロダクト単位で開発全てに責任を持つことが求められるようになる。そのため、単に開発するだけでなく、レビューやリリース作業なども担当するようになった。技術選定などの決断もチーフエンジニアの役割として課されている。
若宮氏は「かつては開発してリリースするまでがゴールと考えていたが、リリース作業を任されるようになって『本当にこれで大丈夫か』とリリース後の運用も含めた品質やリスクについても考えるようになり、意識するポイントが変わってきた」と語る。
高嶋氏も「リリース作業自体はシステム化されてシンプルになっているが、自分たちが作ったものが世の中に出るということで喜びと同時に責任を感じるようになった」と同意する。はじめの頃は緊張のあまり震えながらリリース作業を行ったこともあるという。
永井氏も「不安があったが、いきなり任されるのではなくOJTでサポートしてもらえたので、少しずつ確かめながら取り組むことができた」と語る。新入社員の野村氏も「若手でも任せてもらえる文化は、新人も同じ。それが実現できるのも、サポートが手厚いから」とうなずきあった。
しかし、安心してチャレンジできる環境があるとはいえ、やはりチーフエンジニアになる際には、スキルや仕事の内容だけでなく「マインド面」の変化が必要で時間がかかったという。若宮氏は「以前からテックリードやマネジャーに相談することは多かったが、ただアドバイスをもらうのではなく、自分の意見を伝えた上でアドバイスをもらうという形にすべきと感じた。そこで、少しずつ小さなことから決断するようになった」と語る。
仕事の内容も少しずつ変化し、担当しているサービスのロードマップ作成などにも挑んでいる。高嶋氏は「技術的な視点だけでなく、事業としてどう成長させるかを考える必要があるため、プロダクト全体の理解や外部環境のキャッチアップが必要となる。難しさはあるが、未来を考えるワクワク感がある」と語る。
また、若宮氏も新しい取り組みとして「エンジニアの相談部屋」を主催したことを紹介。コロナ禍によってリモートワークが増えたことで、エンジニアが相談したりコミュニケーションをとったりする機会が求められていたため、チーフエンジニア同士で話し合ってオンライン上でいつでも相談や雑談ができる場を設置した。
2年で組織全体の成長に結びついたチーフエンジニア
こうしたさまざまな変化の中で、チーフエンジニアとなって2年がたった今、社内メンバーにはどのような変化が現れているのか。
若宮氏は「如実に変化があったのは、開発スピードやリリースまでの時間が速くなったこと」と語り、「マネジャーなどからチーフエンジニアに権限移譲などが進んだこと、レビューや相談をチーフエンジニアに一本化したことなどで、効率的に動けるようになったからではないか」と分析する。
また、個人的な変化として高嶋氏は「エンジニアの成長といえば『技術的な成長』と考えがちだったが、自分とのギャップに思い悩むところはあった。しかし、それに加えて事業を成長させるためのプロダクト視点を併せ持つことが重要だと気づいたことで、視野が広がった気がした」と述べ、永井氏も「コードのレビューなどもプログラムとして妥当かという目線から、プロダクトや事業としてどうか、運用後のリスクにならないかという目線で見ている」と語る。
若宮氏も「事業目線を持つようになったことは大きな成長」と語り、「入社4～5年目という一般的には若手になる人たちが、当社では中堅として振る舞っている。その層が成長したことで、組織全体の成長に結びついたのは間違いない。開発の自走力だけでなく、組織をひっぱっていくような成長を求められていたタイミングでチーフエンジニアに抜擢され、そこにコミットできたのがよかったと思っている」と自信を見せた。
年次や知識の差を言い訳にせず、自分のプロダクトについて責任をもつことの重要性を認識し、技術ありきではなく、プロダクトのために必要な技術を身に付けるという発想になっていった。逆に言えば、技術的な裏付けを持たないと自信をもって決断することが難しくなるため、危機感が高まったともいえる。実際、複数名のチーフエンジニアでこれまで経験したことのない領域の資格試験に挑んだこともあったという。
野村氏は、「チーフエンジニアになるとプロダクトを俯瞰して見るために、少し技術からは離れて管理するイメージだったが、逆に全体を見るからこそスキルを上げることに対しての意欲も高まるのだと実感した」と評した。
