プログラマ新人にありがちな悩みとその対処4つのポイント
念願なのか、事故なのかプログラマになってしまった新人さん、ようこそこちらの世界へ。
業務内容が、普通とは違うことがおおいプログラム職は慣れない事が多いと思います。
特に新人の方には、全然ついていけなくて困っているという人も多いのでなないでしょうか？
今日はそういう新人プログラマさんのよくある悩みとその対処法をお伝えします。
目次
新人プログラマにありがちな悩みとその対処法
今回は、4点に狙いを絞ってお話します
お品書きは以下の通り。
- 他の人のコードが読めない
- 指示の内容が分からない
- 見積もりが出来ない
- あ、これ無理なやつだ・・・
では、１つずつ順に説明をしたいと思います
他の人のコードが読めない
コレがもっとも多くて、もっとも厄介な内容です。ちなみに、新人だから読めないとか思ってる人が居るかもしれませんが、何年経ってもこの悩みは解消されません。
断言できます、人のコードに悩まないプログラマはいない。これまでも、これからもね！
なので、読めなくて困っていること自体に絶望しててもだれも気にしないのであれば、それは自然なことだからなのです。
たまーに、くっそ読みやすいプログラムを書く変人がいますが、ガチャチケ１枚でSSRでお目当てのキャラを引くぐらいの確率だと思ってください。
対処法：とにかくログ！
では、ソースコードが読めない場合はどうすればいいのか？答えはデバッグログをしっかり使いこなすということです。
プログラムが読めないというのは、流れがつかめてないということといえます。
読むように言われている箇所が、どこから流れてどうやって到達しているかが分かることが第1です。
みなさんが、どの言語、どの開発環境に身をおいているかはそれぞれだと思いますが、まずはデバッグプリントを表示させる方法を覚えてください。
PHPとかサーバー関連だとログファイル経由になるかもしてませんが、その場合もコンソールで監視できるようにしてください。
一番原始的ですが、どのような言語を扱うことになっても、確実にフローを読み解くのに必要になります。
基本的には問題の箇所からどんどんと上流のプログラムを目指しながらログを付け足していき、流れを掴んだところで修正を開始するなど、割り振られた作業を行うと良いでしょう。
長くやっている人は、この作業のアテを探す嗅覚が育つので、簡単にバグを見つけたりしますが、こういう地道な経験のタマモノです。
嘆く前にどんどんログを追加する、とにかく手を動かすことが重要です
指示の内容が分からない
会話の中で、何言ってるか分からなくて情報が頭に入ってこない現象。
ネットで調べて補間すると思いますが、それでもどうすればいいかがわからずに時間をつぶしてしまうパターン。
この、理解が追いついていない状態ですが、単純に実力不足かというと、そうでもありません。
対処法：作業内容を明確にした確認を取る
この対処法は、復唱確認に少し情報を足すことで、結構解決します。
たとえば、プログラムではないですが、「そこの箱を運んでおいて」という指示のうち、20%ぐらいしか理解できないとします。
このとき何も考えずに「分かりました」と返事をして、どうするか考えるのではなく。
「分かりました。Ａから台車を持ってきて、2つずつ重ねて運びます。2時間ぐらいで終わると思います」
という感じで返答してみてください。この返答内容のポイントは分かりますでしょうか？
手段・方法・時間を盛り込んで確認をしています。こうすることで、作業指示を出した人が、
「いやいや、割れ物なんで手で運んで。1個ずつね。あー、3時間ぐらいかかると思うよ。」
という感じで訂正をしてくれるはずです。
先輩というのが、的確な指示を出来ると思っている人がいるかもしれませんが、教えるプロな人は結構少ないです。（これはプログラムが上手い下手とかそういう問題ではありません）
実際入社2年目の人は、作業指示をすることに関しては新人同様です。
プログラマならプログラマらしく、正確な指示をもらえるように「バリデーション」処理を入れて指示をもらいましょう
見積もりが出来ない
これも最初の壁だと思います。
2日で出来ると思ったら、1週間かかるやつですね。あ、見てないですけど知ってますよ。
さて、この見積もりというのは慣れるまでが本当に不透明で困った問題です。
自分のパートが拡大すれば、他の人との絡みが増えて、なぞの待ち時間や他の人のバグに飲み込まれて遅延さえします。
今回は簡単に出来る対処法と、慣れてきたら意識するべき対処法をお教えします
対処法１：3倍して
誰かに見積もりを依頼されて、頭に浮かんだ工数の3倍を口に出してください。
マジで。
このとき、「いやさすがにそれは長すぎる」と思った人は絶対に3倍にするべきなのです。
なぜなら、もともと出した工数が、この作業がこの期間で終わらないとダメだなという作業ありきではなく、プロジェクトありきで算出された可能性が高いからです。
見積もりといわれたときに、「作業」時間を返答するのではなく、「仕様確認・設計」「作業」「デバッグ」までを含んだ時間のすべてが必要なのです。
これらを完璧に把握して始めて正しい見積もりといえます。デバッグ一つとっても、「何人が必要で」「いつから出来て」「デバッグ環境は用意できるか」など、現場によってはどれかが重たくなったりします。
まぁこの作業見積もりに関しては、山ほど注意する点があるのですが今回は割愛します。
とにかく今言ったことがぱっと思いつかないのであれば、3倍して返答してください。
もし発言力がなく、押し切られてしまう場合、実際に始めに見積もった期間からどのくらい差があったか、しっかり覚えておくとよいと思います。
対処法２：関数レベルまで想像する
実際に見積もりをする時、どんな関数が何個必要かまできっちりと設計します。そして各関数ごとに実装がどのくらいの時間がかかるかを計ります。その合計時間が見積もりになります。
この方法はプログラマとしての設計力も大幅に向上します。
実際に作業をした際、想定してない関数がなくなるまで訓練を続けることが必要になります。
見積もりは本当にいつまでも必要になりますので、日ごろから精度をあげる練習を続けましょう。
あ、これ無理なやつだ・・・
依頼された瞬間に背筋が凍るお仕事、ありますね。
さすがにこの対処法はないと思っているかもしれませんが、全然そんなことはありません。
新人さんというのは、自分で仕上げないといけないと思いがちな人が多いですが、そもそも仕事とは仕上げることが必要です。この違いをしっかりと理解しましょう。
対処法：その仕事、誰に聞けば分かるかを把握する
起こる問題ごとに、誰に相談すればいいかをしっかり把握しておくことが大事です
職場にはいろんな人がいると思います。また、それぞれの強い分野が異なることが多いです。
自分が打開できない壁にぶつかったとき、あの人に聞けば分かる、というのがすぐ出るようにしておくことがとても大事です。
そのためには普段からいろんな人に話をして、積極的に情報を集めておく必要があります。
作業の方向性や、その人ならどのくらいで出来る作業かなどをしっかりヒアリングして、自分だとどのくらい時間がかかるとかを見極めて、一人で難しい場合はしっかりと相談してください。
「誰さんに相談して、こうすれば出来るんですが、自分だと作業時間が足りなくて遅れそう」
ということを明確にすることで、ヘルプももらいやすくなります。
繰り返しますが、自分で完結させることが目的ではありません。ただ、ヘルプをもらった場合でも、誰かにお願いする場合でも、その人のフォローしてもらう分はあとでちゃんと見直して、次回からは自分で解決できるようにしましょう。
まとめ
いかがだったでしょうか。どれも現場に入って、なんどか経験のある話だったのではないでしょうか？
最近の会社だと、知識的な研修は多くなってきましたが、実際の現場で困る自体にはあまりフォローがないように感じてます。
新人のころは、最低でも自分のチーム全員と話が出来るぐらいは歩き回って、同じ職種であればチーム外にも話が出来るようにしておくのがベストです。
その中で、誰にどういう風に頼ればよいかなどを、問題が起こる前に準備しておきましょう。
プログラマやっていると、本当に自分だけじゃ無理な事態は必ず訪れます。
プログラム技術の研鑽はもちろんですが、それ以外の部分もしっかりと対応できるようにしてください。
少しでも新人プログラマの心が安らぐことを願います。