プログラマーが辛いと思う瞬間を上げてみる
こんにちは管理人です。
今回はプログラマーとして働いていて「つらい」と思う瞬間を上げてみようと思います。
IT業界は一見ゆるく働きやすいイメージを持つ方も多いと思いますが
仕事内容としては細かな作業が多いことやシビアなことも多いです。
私の周りの人間も結構辛いという人が多い印象です。
なので今回この記事でプログラマとして働く上で
どのようなときに辛いと感じるのかをまとめることにしました。
下記のような方は是非参考にしてください。
- IT業界に転職を検討している方
- プログラマに興味がある方
- すでにプログラマとして働いている方
プログラマーが辛いと思う瞬間
プログラマとして働いていて辛いと思う瞬間を上げています。
別業界の方や興味がある方は是非参考にしてください。
要求を満たした成果物の作成
これは技術力がない転職した当初、
実装の段階からプロジェクトに参画した時や(流用できそうなものがない)
初めてのフレームワークを使用する時等
特にに痛感しました。
できないとは当然言えず、マイナーなフレームワークやDBを使用していると
ググってもなかなか出てこず、理解しにくいんですよね。
これはめちゃくちゃ辛いです。
また誰も手を付けてないとなるとなかなか大変で
孤独との戦いになります。
バグを修正しながら試行錯誤してなんとか作っても
振り返ると、コードが複雑になりすぎて
機能単体としては問題なくても
結合する際にバグが出たり
仕様変更や機能追加する際に
バグが出たりすると
簡単に修正することができず結構時間がかかってしまうものです。
自分の中で色々理解が深まっていくと
あの時このような実装をしていたら良かったと思うものですが
それを反映させるのも開発規模が大きすぎたらなかなか難しいものです。
バグが発生したとき
バグが発生した時は辛いです。
プログラマーだと誰もが通る道だと思います。
理想はバグを出さないことですが現実的には難しいものです。
誰に発見されるかにもよって指摘内容がかなり変化します。
バグが発生した状況や処理後の結果を
説明してもらえるのであれば助かるのですが
漠然とバグが有ると伝えられた時はかなり辛いです。
特に定時直前に緊急性が高いバグが上がってくると絶望です。
原因を調査してバグを修正してテストをして
修正内容を反映させると気づけばかなり時間が過ぎています。
バグを出さないことは無理なので極力バグが出にくい、実装方法を身に着けていく必要があります。
納期の問題
納期の問題ですが、プロジェクトや開発会社によって結構差があったりします。
後は技術的な内容もついてまわるのでかなり個人差を感じます。
数年目のプログラマー等は該当すると思います。
私もそうでした。
本当に辛くてなぜエンジニアとして働くことを選んだのかと後悔したものです。
人によっては毎度、納期に追われることが続いて
落ち着くことがないので辛いと思う人もいるようです。
小さなプロジェクトなら当然納期に追われますが
大きなプロジェクトといえど機能ごとにスケジュールを割り振るので当然納期に追われることになります。
ただ技術力が高くなればなる程、見積もりの工数より当然早く終わるので楽に感じてくるはずです。
その分設計などに携わってくるのでまた別の仕事の苦労が生じますが
仕事の幅が広がれば楽しいと思うものです。
技術的な内容
技術的についていけず、仕事をするのが辛いと思うかもしれません。
特にSES等で働いている人は経歴を盛っている人が多いと思います。
盛っている人や単純に技術力が低い人等からすれば
相手から求められている仕事に対して答えることができないと辛いですね。
また技術が低いと会話すること厳しいかもしれません。
IT業界は横文字が多く、転職したばかりの人などは
何を言っているのかさっぱりになる人も少なくないはずです。
技術力が低ければ先程説明した内容のような、納期に追われたりバグを起こしたりする頻度が高くなるのでかなり悪循環です。
ですが仕事をしていると技術力はある程度身についてきます。
そこから技術書などを読み技術を身に付けて、より品質を高めていきます。
旧開発メンバーの負の遺産
開発をしているとメンバーの入れ替わりや人数が減ったりするものです。
これも長期間のプロジェクトに携わっている人ならわかるはずです。
この入れ替わる人間がとんでもないバグを残したり
隠蔽しているのが明るみになってきたりするとかなり大変です。
結局後処理をするのは残っている人間になるからです。
この残作業が発生すると思うのですが
残りの人間が少なかったりすると割り振られる割合も当然高くなり
この作業については追加工数をもらうことは当然できません。
なので残業必須でさっさと終わらせる必要が出てきます。
過去にあったのはテストを偽ったり、コードが無茶苦茶だったりして痛い目にあいました。
入れ替わる方なら良いですがもし残される人間になる可能性があるなら
その人の担当機能を必要以上にチェックすることをおすすめします。
辛いと思わないようにするには
今回の辛いと思う内容は下記のとおりでした。
「バグ・納期・技術的・負の遺産」
負の遺産については、ちゃんと機能するかチェックして仕様などについて
しっかり引き継ぎを意識をすれば解決するものです。
これをしっかりしていないと後々痛い目を見ることになります。
バグ・納期・技術的
これらについては技術力を高めたり、仕様や機能の理解を深めることで
大方の問題を解決することができるのではないでしょうか。
（納期が適正の場合）
そもそもバグが発覚するのはテストが不十分だったり、追加機能を実装したときによく起こります。
追加機能は絶対にないことなんてほぼほぼありえないので
追加機能に対応しやすい実装方法を身につけることができるのであれば、
負担がかなり減るのではないでしょうか。
まとめ
今回のまとめです。
プログラマーとして働いていると辛いと思う瞬間をまとめてみました。
基本的には、働きだして数年間で解消する内容が多かったのではないかと思います。