仕様変更のルールが曖昧になっている
指示された通りにプログラミングを行っているはずなのに、なぜかスケジュール通りに作業が終わらず、連日のように遅くまで残って仕事をしている人は少なくありません。実は、自分自身の作業スピードの問題ではなく、開発のプロセスそのものに原因が隠れているケースがあります。では、どのような運用の問題がプログラマの手戻りを増やし、過酷な長時間労働へとつながってしまうのでしょうか。
開発途中で繰り返される仕様変更
プログラマがどれほど効率よく綺麗なコードを書いていたとしても、開発の途中で何度も仕様変更が繰り返されてしまえば、作業時間はいくらあっても足りなくなります。このような問題が起こる背景には、プロジェクトがスタートする段階で要件定義がしっかりと固まっていないという原因があります。
クライアント自身もシステムで実現したいことが明確になっていないまま、見切り発車で開発が始まってしまうケースは珍しくありません。本来であれば、上流工程で仕様をしっかりと詰め、合意を得てから実装に移るべきですが、「まずは作りながら考えていきましょう」という曖昧な運用のまま進んでしまうと、そのシワ寄せはすべて現場のプログラマに集まります。機能を追加したり、一度作った部分を修正したりする作業が何度も発生するため、スケジュールは簡単に崩壊し、結果として深夜まで残業を重ねる状況が生み出されてしまうのです。
柔軟な開発手法という落とし穴
時代の変化に合わせて、仕様変更に柔軟に対応できる開発手法を取り入れる企業が増えています。状況に応じて計画を変更しながら少しずつ開発を進めるやり方は、一見すると合理的で効率的に思えるかもしれません。しかし、ここに大きな落とし穴が存在します。
この柔軟な開発手法が、クライアントやプロジェクトの管理者に都合よく解釈されてしまうと、「いつでも、いくらでも変更していい」という誤った認識に変わってしまいます。明確なルールや期限を設けずに仕様変更を受け入れ続けてしまうと、現場のプログラマは終わりのない修正作業に追われることになります。変更に伴う工数の増加や納期の調整が適切に行われないまま、現場の努力や時間外労働だけで解決しようとする構造がある限り、いくら技術力があっても残業から抜け出すことは難しくなってしまいます。
作ったコードを捨てる精神的負担
仕様変更による度重なる残業は、プログラマの肉体を疲弊させるだけでなく、心にも大きな負担を与えます。プログラマにとって、プログラムは頭を悩ませて丁寧に構築した作品のようなものです。それが仕様変更という一言で、簡単に破棄されることの精神的苦痛は計り知れません。
時間をかけてきれいに整理したソースコードを捨て、また一から作り直さなければならない状況が続くと、仕事に対するやりがいやモチベーションは著しく低下してしまいます。「どうせまた変更になるのだろう」と思いながら作業を続けるのは、心身ともに非常に辛いものです。もし、自分の努力ではどうにもならない理不尽な仕様変更が日常化しており、会社もそれを改善する姿勢を見せない環境であるならば、健康を損ねてしまう前に、自分のスキルを正当に評価し、守ってくれる別の職場へ移る選択肢を真剣に考えるべきかもしれません。
