【クライアントエンジニア編】エンジニアトレーナー対談。「仕事の任せ方」から「エンジニアとしての心得」まで

アプリボットでは毎年新卒社員に対して、トレーナーとして先輩社員が1名付き、1年に渡ってOJT形式で育成に取り組んでいます。


今回はクライアントエンジニアで過去にトレーナー経験のある社員が集まり、トレーニーの育成方法や目標設定の考え方など、”育成”についてそれぞれの実体験を元に語り合いました。育成に興味のある方、育成のやり方に悩んでいる方など、この記事を読んだ多くの方の参考にしていただければと思います。

(左奥)幸津川 康徳(Yasunori Sazukawa)

2011年 入社。エンジニアリーダーやエンジニアマネージャー、プロジェクトマネージャーとしてアプリの開発やマネジメントに従事。


(右前)吉村 智志(Satosi Yoshimura)

2015年入社。「ジョーカー〜ギャングロード〜」にクライアントエンジニアとして携わる。


(右奥)小澤 駿(Shun Ozawa)

2015年入社。「グリモア〜私立グリモワール魔法学園〜」でクライアントエンジニアとして従事。2018年「BLADE XLORD -ブレイドエクスロード-」に異動。


(左前)杉浦 優介(Yusuke Sugiura)

2018年入社。新規開発プロジェクトにてクライアントエンジニアとして携わる。今年初めて新卒エンジニアのトレーナーを担当。


◆トレーニーの目標設定を考える時に意識していること

ーーートレーニーの目標設定はどのように考えていますか?


吉村:最初に「トレーニー自身はどうしたいか」をヒアリングするようにしていますね。もちろん人によって、どういう方向に進んでいきたいかが決まっていない場合もあります。その時は、「どのような時に喜びを感じるのか」などの質問をしながら一緒に考えるようにしています。そうして目標がある程度決まったら、プロジェクトの目標や状況も考えて、この先どのようなステップアップを目指すのかを決めていくようにしています。


幸津川:それは中長期的なキャリアの目標設定の場合か、半年くらいの場合か、どれくらいの期間の話?


吉村:半年くらいのイメージですね。ただ、半期目標が中長期の目標に繋がるかどうかは、意識的に考えるようにしています。


杉浦:なるほど。でも、トレーニーがやりたいことがプロジェクト内の業務とは異なったり、プロジェクトの目指す方向と合わなかったりすることはありませんか?


小澤:その場合は、まずプロジェクト内にある業務に対してどのように取り組んでいくかを一緒に考えます。そして、プロジェクトに留まらず活躍できる人材になるための中長期的な目標をトレーニーと一緒に考えるようにしていますね。


吉村:UnityやCocos2d-xなど、どのような技術を使っているプロジェクトでも、「設計」や「コードの書き方」など、学べるものがあると思います。仮に配属されたプロジェクトに挑戦したい技術がなかったとしても、今後に活かせる学びはあるはずなので、その部分をトレーニーに伝えるようにしていますね。


幸津川:私の場合、最初の頃は任せたい仕事を明確にして渡して、できるところからやってもらうことが多いですね。


杉浦:なるほど。どちらかというと、プロジェクトの状況を見つつ任せるのですか?


幸津川:まずは技術よりも仕事の進め方を身につけたり、業務としてできるようになってもらうことが大事なので、見様見真似でできるタスクから任せていくことが理想です。ある程度できるようになってから、その先のことを考える方がいいと思っているので、将来やりたいことを聞いて最初の業務に反映することはあまりないですね。

杉浦:少し意外ですが、確かにはじめからトレーニーにやりたいことを聞いて、それに沿ったものを任せることが難しいのはとてもよくわかります!


◆どこまでトレーニーの意見を尊重するか

ーーートレーナーはAの実装がいいと思っていて、一方でトレーニーはBの実装の方がいいと思っている場合、どのように対応していますか?


杉浦:いったんやってもらった方がいいのか、先に答えを教えた方がいいのか悩みますね。


吉村:長期運用タイトルの場合は、過去の実装を考慮してプログラミングすることも重要なので、初期の頃は、トレーニーにその部分をまめに説明することが多いです。トレーニーの意見を尊重するというよりも、「1年後の運用を考えても、それで問題ないと思う?」という質問を投げかけることが多いですね。


幸津川:コードを書き始める前に相談に来るのか、後に相談に来るのかによっても対応の仕方は全然違うかもしれないですね。それに、それを学んでほしいのか、早く仕上げてもらいたいのかによっても変わってきます。ただ本当に初期の頃は、部分的な機能改修など、あまり悩まずにできる業務を任せて、コードのレビューをしっかりすることがほとんどですね。


杉浦:では、どれくらいから対応を考える時が出てきますか?


小澤:運用プロジェクトだと新しい機能開発をする時も、過去につくった機能と同じような手順でつくることが多いけれど、新規開発プロジェクトは基盤から変更になることもあるので、一概にタイミングをいつと言うことは難しいかもしれないですね。

◆振り返りの1on1ミーティング

ーーー1on1ミーティングでは、どのような話をしていますか?


杉浦:私の場合は、基本的に困っていることを聞いたり、その週で良かった動きを伝えたりして、それを踏まえて翌週や翌月に何をするかを一緒に考えるようにしています。


小澤:そんなに変わらない気がします(笑)


吉村:確かに(笑)あとはチームやプロジェクトの思想を伝えたり、雑談ベースで最近のトレンド技術の話とかもしますね。既存コードの直したい部分とかの話も。

幸津川:そもそも、1on1ミーティングはなかったとしてもあまり支障はないと思っています。基本的にトレーニーの業務を適切に見られていれば、それでフィードバックはできているはずなんですよ。


杉浦:それだとプロジェクトでの悩み以外のことについて、話す機会がなくなりませんか? 私の場合、1on1ミーティングの時に、新卒が企画する会社イベントの相談にのることもあります。


吉村:新卒は通常業務に加えて研修も多いので、「研修との両立が厳しい時は、業務量を調整するよ」と伝えることはありますが、イベントの企画内容の相談まではのったことがないかな(笑)


幸津川:日々業務に限らず相談できる関係は理想だと思います。理想通りはなかなか難しいので、定期的に振り返る機会をつくるのは良いことですが。


杉浦:そうなんですね!一緒にコンテンツ内容を考えるくらい相談にのっていました!もう少し、ゆるく1on1ミーティングをすることにします(笑)

◆トレーニーをどこまで過保護に見るか

ーーートレーニーをどこまで細かく見るようにしていますか?

吉村:新卒がプロジェクトに入りたての頃は、困ったことがないかよく聞きますね。すぐに正解を教えてしまうのではなく、「順調?」と聞いてみて、返ってきた答えに対して助け舟を出すイメージでアドバイスをします。仕事に慣れてきたら、ほぼ任せて「困ったらいつでも相談して」とだけ伝えておくくらいですね。


幸津川:任せる業務の影響範囲がどれくらいかによると思っています。トレーナーから業務を振る時は、自然とトレーニーとのコミュニケーションが発生するので、あえて気にかけなくても問題ないと思います。一方で、デザイナーやプランナーなど他の職種のメンバーと連携して進める業務であれば、意識的に気にかけてあげた方がいいと思います。


杉浦:なるほど。あまり過保護になりすぎるのはよくないけれど、業務によっては気にかけてあげた方がいいのですね。


吉村:「もしできなかったらみんなが困るし、大変な時は自分だけで何とかしようとせず相談してほしい」ということはよく言っていましたね。


◆エンジニアの心得

ーーーエンジニアの心得として、どのようなことを伝えていますか?

小澤:そんなに心得をしっかり考えたことがなかったんですが…(笑)新規開発でも運用プロジェクトでも、効率的に作業を進められるツール作りを開発の中に含めることは、必ずトレーニーに伝えるようにしています。そして、受け取った仕様書に対して違和感があれば、単なる作業者になるのではなく意見することも大事だと伝えますね。


吉村:そうですね。言われたものをつくるだけでなく、ユーザーにとって最高なものを常に考えてチームでクオリティを上げることは、私も心得としてよく伝えています。すでにリリースされているサービスであれば、しっかりとやりこむことで改善した方がいいポイントを見つけ出せたり、新しい機能を追加する時にも意見できたりすると思います。せっかくチームでモノづくりをしているので、色々な職種の人が意見を出し合った方が、より良いものができると思うんですよね。


そして、コードの一行一行を何となくつくるのではなく、常に何故そうしたか説明できるように仕事をした方がいいと思っています。自分の書いたコードに責任を持つということですよね。


幸津川:「社外に目を向けるように」は、トレーニーによく言っていますね。組織作りを大事に考える社風なので、社内に目が向きやすくなるんです。社内で活躍するだけじゃなく、世の中で活躍してね、って伝えるようにしています。また、基本的なことではありますが、「睡眠不足での仕事はNG」もよく伝えていますね。エンジニアリングはすごく頭を使う仕事なので、寝不足の状態だと良いアウトプットは出せないです。


エンジニアの3大美徳「怠惰・短気・傲慢」は、その通りだと思うので、時々伝えることがあります。怠惰な心があるから業務を効率化したり、問題が起こったときに早く且つ今後同じことが起きないように解決しようとしたり、自分がつくった設計が最高だと傲慢になれるほどのものをつくったり、良いものをつくるエンジニアとして必要な資質だと思いますね。