新人教育をお任せされているあーみーです。
今回は新人プログラマ応援キャンペーンという事もあって折角なので参加させて頂きたく記事を書いてみました。
私の仕事はプロジェクトを成功させることが業務の1つですが、それと同等に新人プログラマを1人前にすることも同時に重要なミッションとなります。
そこで、新人エンジニア・プログラマがやりがちなミスや抜けている点など9選をご紹介していきますので、入社されたエンジニア・プログラマーの方はこちらを見て参考にしていただければ幸いです。
また、教育の観点で新人の教育を配属することが決まった先輩エンジニアの方にも是非、参考にして頂けますとうれしいです。
Excelが使えない
入社する業種にもよりますが、SIerや受託開発等は基本的にExcelを触る業務が殆どです。主に要件定義や設計・テストなどのPJTの大半はExcelを触るケースが多いです。
私自身もExcelを触るのは大の苦手ですが、苦手だからといって時間をかけていては好きなプログラミングに集中できる時間は減少してしまいますし、本来議論すべきことや考える事の時間も同様に減っていきます。
Excelの関数も最低限のモノやショートカットは網羅しておきましょう。
新人さんは動くサービスを提供するものだけがすべてだと思いがちですが、お客様がいる以上納品物という意識を持ちましょう。
また、VSCodeなどのエディタと違いExcelはより便利になる事が少ないです。
（Office365は便利ですが、お客様の互換性の問題で使えない関数や機能等も当然存在します。）
そのため枯れない技術のひとつとしてExcelを覚えていきましょう。
教育の方へ
我々エンジニアは基本的にプログラムの品質などに目が行きがちですが、この辺りはExcelの操作が遅い（想定の見積もりより遅い）場合は新人さん本人が慣れてないケースが殆どです。
Excelでのペアプロ等も効率的なので、ぜひ実践してあげてください。
質問をせずに塞ぎ込む
これは完全に人による部分が強いのですが、プライドが高い子や負けず嫌いの子に非常に多い傾向です。
新人さんは赤っ恥をかきたくないのです。
ただ、実際にベテランの方でも業務知識が足りてなかったり、環境の情報が不足してたりルールが統一されてなかったりetc…。
といった形で様々な質問を投げるケースも多いです。
質問しなくても動けてる人もいますが、「質問せずにカッコよく振る舞いたい」と思ってもプロジェクトの成功・タスクの完了の目的から逸れているので無意味です。
まずは質問をする。という事を念頭におきましょう。
具体的な質問の内容については別の項目で説明します。
教育の方へ
「それがダメなんだよ！」と先輩は頭ごなしになる気持ちも分かりますが、それでは人は育ちません。
単純に本人の性格の問題で質問出来てないケースなら説教をしても良いですが、そうじゃなくて環境起因の問題の可能性もあります。
- (例：社内の空気感が張りつめている / 皆忙しそうにしている / フランクではない / アイデンティティを認められてない等) *
これらは解決出来る事はチーム内で改善していき、無理な部分であれば上長や経営層に報告していきましょう。
質問者の関係性を理解していない
上記の質問をしない問題としてチームの登場人物を理解していない事が挙げられます。
- PMは一郎さん
- PLは二郎さん
- いつもSlackで回答してるプログラマーの三郎さん
みたいな人が大半ですが、三郎さんにインフラや納期や契約の事を聞いても「僕じゃ分からないです。」の一言で終了してしまうパターンってあるかもしれません。
その際は最初の質問をした際に「この手の質問は誰にご相談すればよいですか？」と一言いいましょう。
まれにマルチスキルな方がいますが、そういう人は大半タスクが切迫していたり質問が集中しがちで回答が遅かったりします。
その結果自分自身の期日が狭まってしまいます。
そのため可能であれば
- Webに関する事は〇〇さん
- インフラは××さん
- ツールやアカウント周りは△△さん
などの関係性を理解しましょう。
PJTにもよりますが、メンションを付けないと気付かない人も多いので、適切な質問者を選んで回答を促しましょう。
先輩は皆優しい！（答えられないのが申し訳ないだけだヨ）
教育の方へ
この辺りは先に関係性を教えてあげられると良いかもしれません。
皆さんの立場にもよりますが、「上司（面倒を見てくれる人）が誰か分からない」って問題、案外多いです。
なので初対面の際に「私はあなたの上司・先輩です。」と明示的に伝えましょう。
本当にそれをするだけで新人さんの心労が軽減されるはずです。
質問の仕方が下手
先輩も忙しいから適切な質問を投げたいと思う事ってあると思います。
ただ、「何を言ってるか分からない」と言われた経験、ありませんか？
この際は質問がまとまっていない。具象的過ぎて前提を伝えきれていない等の例が挙げられます。
例：
新人さん：先輩！受け取った文字列をHTML形式に表示する方法がうまくいかないんです。
先輩：ああ、それは〇〇で出来るよ。
～～後日～～
新人さん：タスク出来ました！
先輩：（なんでこの方法使ったんだろう…）
これ、私が過去に経験した事です。（お恥ずかしい話ですが）
これで私は残業確定で一生懸命直す羽目になりました。
これは先輩が悪い訳ではなく自分が適切な情報を伝えきれてなかったという点が大きいです。
新人さん：先輩！〇〇の機能を実装してるのですが、受け取った文字列をHTML形式に表示する方法がうまくいかないんです。
先輩：えっ、そんなことしなくても良くない？××の機能と似てるから参考にしてみなよ。
新人さん：そうなんですね…見てみます！
～～後日～～
新人さん：タスク出来ました！
先輩：（OKやで）
こんな感じであればベターかなと思います。
まずはやりたい事の前提条件などをきちんと伝えましょう。
主語が抜けてない様で抜けているのが落とし穴なので。。
教育の方へ
勿論察して回答することは大事ですが、その後に「主語が抜けているね」と指摘してあげるのが大事です。
自分で気付いてたら言わなくても大丈夫ですが、指摘しないと分からないタイプの方もいます。
先輩は業務を効率的に進める事を重視しますが、教育は非効率なものであるということを理解しないといけません。
分からないと素直に言えない
タイトル通りです。。本人のプライドによる事象と、申し訳なさから来る感情から分からないと伝えられないの事象が要因です。
解決方法としては「アレコレは分かってるけど、〇〇が分からない」と質問内容を考える癖をつけていきましょう。
情報の整理にもなります。
何も分からない！と言ってしまうと回答者も「どこから説明しよう・・・？」と頭を抱えてしまいますし、一から説明してたら途方に暮れます。
例えば「Gitが分からない」という質問は
- Gitの概念が分からない
- Gitの操作やコマンドが分からない
- Gitのブランチの運用方法が分からない
- Gitの競合解決の方法が分からない
などなど粒度を細かくすることは可能なはず。
「〇〇の××が分からない。」までは最低限考えましょう。
下記のようなツリー構造をどれだけ深く作れるかが勝負です。
ツリー構造で下に行けば行くほど質問になればなるほど、具体的な回答をしやすいです。分からない事が恥ずかしいのではありません。
こうやって自分なりに深堀していく癖をつけてみてください。
それが出来るのであれば皆優しく答えてくれるはず。
教育者へ
背中を押してあげる事が大事だと思っています。おとなしい子だから聞けないとか、コミュ力高い子だから聞ける等の因果関係はないので、業務のコミュニケーションが円滑に出来るように1日1回は直接伺ってサポートしてあげてください。
タスクのゴールが定まってない
実際にどこまでをタスクのゴールか決まってない事や伝達不足から来るケースも多々ありますが、開発経験者の人とそうではない人は文化的な違い等から認識相違が結構あります。
例えば〇〇画面の実装というタスクに対して
- ソースコードはどの状態まで完成させたらよいのか？
- 動作確認はどの程度やればいいのか？
- 未作成で別タスクである遷移先ページはどうなるのが正なのか？
- データはどうするのか？（ダミーも併せて作る必要があるのか？）
などを確認していきましょう。
そして未決定の仕様がある際はいつまでもタスクが終わりません。。
なのでタスクのスコープを狭めて「未決定の所だけ別途タスクを作成して後日とりかかる形でも良いですか？」
といった形で無駄な時間が発生しない様にコミュニケーションをとっていきましょう。
教育者へ
こちらは教育者というかマネジメント層に言える事ですが、他機能や画面の疎通等のルールが決まってない事が多く、この問題は結合テストまで浮上しないので早急に是正した方が良いです。
Webアプリなどは小さな技術の大きい集合体なので疎通がうまくいってないと（画面や同一のモジュール含めて）出戻りが大きいのでWF型の開発に固執しすぎず柔軟な開発スケジュールを組んでください。
タスクの細分化が出来ない
例えば〇〇画面機能の実装というタスクに対して一気に取り掛かる人が多くいます。
この場合は
- ダミーデータでもいいから画面を表示させる。
- サーバーサイドとの疎通を行う
- DB等のミドルウェアとの疎通を行う
- ロジック部分を完成させる
- すべての機能を結合させる
- 動作確認を行う
このように細分化が出来るはずです。
仮にこのタスクが6日の猶予があれば1日ずつで割り算するか、配分をかえるなどの調整することも可能です。
なので自分の作業がどれだけ千切りに出来るかを考えてみてください。
教育者へ
この考えが出来ずに自分の作業が遅延しているのかそうではないかの差が分かってない方が非常に多いです。
この辺りはタスクの細分化を本人に行ってもらうか、マネジメント側でハンドリングするかで大分異なるので時間がある時は細分化してもらいつつリスクマネジメントを行ってください。
考えるポイントが具象的すぎる
#質問の仕方が下手でも説明しましたが、この辺り「思い込み」で来るポイントが強いです。
木を見て森を見ずということわざがある事から目の前の実装や設計書作成に入ってしまうことが多いです。
そうではなく、他の人はどうしてるのか？ルールはあるのか？など一旦俯瞰してみることが大事です。
自分の疑問が果たして正しいのか？一旦戻って考えるという事をイメージしてください。
教育者へ
最終版のレビューはスケジュールの関係上行うことが多いですが、前提条件が大幅に異なるとその分出戻りが大きいです。
そのためラフでのレビューや思想ベースでのレビューを設けて、大きな認識齟齬を潰していきましょう。
先輩のソースコードを見ない
これ…意外と多いです。
自分と似たような画面を作成している人のアイデアやソースコードが沢山あるのにそれを探さない行動をとって車輪の再開発になってる事象が非常に高いです。
私自身、車輪の再開発自体は否定しません。それがロジックだったりアイデアの柔軟性を高める上で重要なものだったりしますが、プロジェクト等のチーム開発等は別です。
自分に足りないアイデアやコーディング手法を先輩から盗んでいきましょう。
教育者へ
大規模開発になるとどのソースコードを見ていいか分からないと思います。
そして参考にして貰ったうえで注意点（例えばココとココが参考にする画面と実装する画面と違うよ）などを注釈してあげると良いでしょう。
あとがき
最後まで読んでくださってありがとうございました。
総括すると新人さんに求められる第一の能力としては「質問力」だと個人的には思っています。
技術力は確かに出来るに越したことはないけど、質問力は今のうちに身に着けた方が良い技術ではあります。
なので素敵なエンジニアライフを過ごせるように頑張ってください！！
…とはいえ、どちらかというと教育者向けのコンテンツになっちゃいましたｗ
日本ないし世界でエンジニア不足が嘆かれている現状なので、新人プログラマさんにもっとこの業界が楽しいと思ってくださるよう私もより一層努力していきたいなと思いました。
私はこんなマネジメントやコーチングしてるよ！などありましたらコメント等頂けますと嬉しいです。