ID:85876さん

保守改善開発チームのリードエンジニアとして、新しくチームに加わったエンジニア2名のメンターを務め、2名の立ち上がりを担当しました。

2名が、自社サービスの複雑なドメインを理解したうえで、保守改善の開発を自走できる状態にする責務がありました。具体的には次の3つです。 ・技術のキャッチアップ：チームで使う技術スタックと開発の進め方に慣れ、実装からレビュー対応までを一人で進められるようにする。 ・ドメイン知識の伝達：発注、在庫、原価などの業務とデータの関係を理解し、問い合わせ調査や不具合修正で、原因を自分で突き止められるようにする。 ・コードの品質の担保：2名のPRレビューを担当し、動くだけでなく、後から読んで直しやすいコードを書けるようにする。

【前提と考えたこと】 2名とも中途採用で、エンジニアとしての基本的な技術は入社時から身につけていました。一方で、自社サービスの複雑なドメイン知識は持っていません。保守改善開発で活躍してもらうには、ドメイン知識の補強が急務でした。そこで、技術を一から教えるよりも、ドメイン知識を実際の案件の中で身につけてもらうことを優先しました。 【問題1：複雑なドメイン知識を、どう身につけてもらうか】 ドメインの知識は範囲が広く、資料を読むだけでは、どこが大事なのかをつかみにくいものです。そこで、私が抱えていた大きめの案件のうち、自分が深く理解しているものを細かいタスクに分解して、2名に依頼しました。タスクを進めるうえで必要になるドメイン知識や仕様は、分からない点があれば質問してもらうようにお願いしました。実際の案件を進めながら、必要な知識をその場で学べるようにするためです。また、自分が深く理解している案件を選んだのは、どの質問にも背景まで含めてすぐに答えられ、2名の手が止まらないようにするためでした。 【問題2：正しく動くコードと、保守しやすいコードの差】 2名のコードは、ロジックとしては正しく動くものでした。ただし保守改善の開発では、後から別の人が読み、直すことを前提にコードを書く必要があります。そこでPRレビューでは、技術的な観点からのコメントを多く付けました。たとえば、クラス全体を見ると同じ処理が重なっている箇所は、DRY原則に沿って整理し直してもらいました。また、保守性の観点から、カプセル化と可読性の改善も求めました。 【問題3：仕様が固まりきっていない部分への対応】 実装を進めると、仕様が固まりきっていない部分が見つかることはよくあります。私たちのチームでは、そうした点をPdMに確認してから進める開発フローで運用しています。2名にはこのフローを伝え、仕様の不明点に気づいたら自分でPdMに確認する動き方を身につけてもらいました。開発者として自走するには、コードを書く力だけでなく、仕様を確かめに行く力も必要だと考えたためです。 【結果】 2名とも、半年が経つころには、マネージャーから直接タスクを引き受け、一人で進められる状態になりました。