16
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

未経験エンジニアをプロジェクトに受け入れるにあたって

Last updated at Posted at 2019-09-22

少し前まで未経験からエンジニアになる人が多かったのですが、自分は実際にそういった人たちを受け入れる側になり、その時(プロジェクト・未経験エンジニアに対して)感じたことや行って良かったこと/行うべきではなかったことをまとめたいと思います。
あくまでも個人的に考えたことなので自身の愚痴や未経験エンジニアに関係ないこともあり、
また、間違っている可能性があります。

前提

  • プロジェクト

    • 自社サービスをマイクロサービスで開発(マイクロサービス経験者無し)
    • 開発チーム(社員)は8人(POが1人、開発経験者2人、開発未経験5人)
    • スクラム組んでアジャイル開発(アジャイル経験者なし)
  • 自分(当時)

    • 1つの開発チームのエンジニアリーダー的な立場
  • 自分のチームの状態

    • 自分、外部パートナー1人、未経験4人
    • 未経験は全員スクール上がり

感じたこと

未経験エンジニアに対して

  • 基本的にスクール卒業したばかりの実務未経験に即戦力を求めるのは間違い
  • ポートフォリオなんてほぼあてにならない
  • テスト関係の知識(境界値やホワイトボックステストなど)も持っておいてほしい
  • 多少のアルゴリズムに関する知識も持っておいてほしい
  • SQLちゃんと理解しておいてほしい
  • RESTAPIもちゃんと勉強しておいてほしい
  • pushした後ちゃんとdiffを確認して、デバッグ用のログや変なdiffが出ていないか、typoがないか確認してほしい(要推敲)
  • 基本的にPullRequestの説明はしっかり書いてほしい
  • 成長の手助けはするが、自分から動いてくれないとこちらとしてはどうしようもない
  • 結果が出てないならせめて姿勢だけでも見せてほしい
  • やりたい事への希望は極力汲むが、それに対して実力や将来性が見合ってなければアサインするのは難しい

プロジェクトに対して

  • プロジェクトメンバーの大半がモノリシックでの開発すらまともにやったことがないのに、いきなりマイクロサービスに挑戦するのは無謀
  • 未経験エンジニアが大半の状態でのスクラム開発は見積もりができないので開発がきつい

#行って良かった事

コードレビュー

  • 特に命名やテストコードについては時間をかけて考えさせる
  • 相談されたなら答えまでは言わず、方向性だけを示す
  • 未経験エンジニア同士でコードレビューさせると、1人に指摘した事を他のメンバーにも指摘してくれるので非常に楽

チームの雰囲気

  • 相談しやすい雰囲気にする
  • リーダーは基本的に機嫌を良くしておくべき
  • しかし指摘するべきことは自分(リーダー)が憎まれ役になったとしても指摘する
  • 基本的にチームに決断を委ね、議論がまとまらなかった時のみ自分が決める(責任を自分が持つ)
  • なのでチームで決めたことに後から異論は挟ませない
  • 開発初期は自分が決めるようにして、後から少しずつチームに権限を移譲させていくとよい
  • メンバー1人ずつに、やっているタスクがどれだけ重要かを分からせて当事者意識を持たせる

リーダーとして

  • 基本的に暇そうにする(暇そうにしてると、メンバーから相談されやすい)
  • 自らメンバーに話しかけに行くと、ふとした話題からメンバーの価値観を知れたり、質問を受けやすくなる
  • ちょっとしたことでもめちゃくちゃ褒める(「○○くんのおかげでめちゃくちゃ便利になりました!最高!!!!」みたいな感じで)
  • 基本的に自分が悪者になる
  • つまらない仕事はメンバーにやらせず自分が率先して片付ける
  • 開発で必要なmodule等は予め自分が用意しておく and 常に全体を俯瞰してリファクタする
  • よほどじゃない限り、任せたタスクは最後までやらせる
  • こなしたタスク量は自分がチームで1番じゃないといけない
  • 率先してリーダーが働かないとメンバーはついてこない
  • パトレイバーの後藤隊長的な感じが良い

行うべきではなかったこと

  • チーム間での人のやりとり
  • 抽象度の高いタスクの見積もり(まずは抽象度を下げることに注力すべき)

未経験エンジニアを採る人へ

  • そもそもあなたの組織には未経験エンジニアを教育するリソースはありますか?
    • ないなら採用するのはやめましょう
    • お互い不幸になります
  • 未経験エンジニアの教育とプロジェクトの進捗、どちらを優先しますか?
    • 教育優先するなら、進捗について口うるさく言うのはやめましょう
      • かつ、教育を担当するエンジニアに「教育」と「開発」のどちらも課すのはやめましょう
      • 結局どっちも中途半端な状態になります
    • 進捗を優先するなら、そもそもプロジェクトの頭数に未経験エンジニアを含めないようにしましょう
      • 見積もりができないので、スクラムチームの一員とするのもおすすめしません
      • まずはバックログの「重要ではない」かつ「急ぎではない」タスクをやってもらうのがいいでしょう

 

16
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?