SEのイメージを異業種の方に尋ねた場合、帰ってくる答えは「残業が大変そう」というものが大半を占めるのではないでしょうか。
確かに残業が大変なことは事実ですが、それだけがSEの辛さかと言えば、答えはNoです。むしろ時間と引き換えにすれば確実に終わるであろう残業より、精神的に辛い仕事はいくらでもあるんですよ。
今回は筆者がこれまで携わった仕事の中から、本当に大変だったものについて、ご紹介していきましょう。

頻繁なメンバー異動

契約社員や派遣社員など、外部の方を開発の主力に置いたプロジェクトに多いのが、このパターンです。チームメンバーが頻繁に入れ替わるため、引継ぎの資料や後任の教育に時間を無駄に取られてしまいます。
対策は、開発をする上で必要な参考資料や、陥りやすい仕様の勘違いなどを纏めておくことです。こうすれば忙しい最中のメンバー変更があっても、「この資料を見ておいて！」と最小限の指示で業務を回すことができるようになります。

過剰な粒度のテスト要求

クライアント側の担当者が、半端にシステムに詳しい場合に起こりやすいのが、このパターンです。「とにかく全てのパターンを網羅するように！」と盲目的に要求してくるため、効率的にテストを進めることが出来ません。
特に多いのが、単体テストにも拘わらず結合テストレベルの粒度を求めてくるクライアントです。これではテスト仕様書を作るだけでも莫大な工数がかかってしまいますよね。
対策は、開発の計画段階でフォーマットを完全に決めてしまうことです。中でもオススメなのは、詳細設計書を丸ごとコピーし、そのままテスト仕様書に仕立てあげてしまう方法です。
これなら工数を削減できる上、詳細設計書の粒度を劇的に上げることもできるため、一石二鳥の成果が見込めます。

歴史あるシステムのリプレイス案件

何十年も昔のシステムの場合、設計書の管理が杜撰なことが多く、設計書が欠損していたり、酷い場合は最初から作っていなかったということもあります。
頼みの綱はクライアントへのヒアリングですが、大抵の場合、深い仕様についても把握していないことが多く、「今のシステムと同じにして下さい」という回答しか返ってこないこともあるでしょう。
クライアントが理解していないものを、どうして作れると思うのか、非常に疑問です。
結局ソースコードを一から解析する必要があるため、工数が莫大になるのが、このパターンの問題点です。
対策は、初めからテスト工数を可能な限り多く確保することです。クライアントからの情報だけでシステムを作っても絶対にうまくいかないため、ソース解析とテストを繰り返すことになることを、初めから覚悟してかなければなりません。

結局最後は「残業」へ

ここまで３つの事例をピックアップしましたが、どれだけSEの仕事が大変か、共感いただくことはできたでしょうか。
これらの業務の厄介な点は、どれも体力・精神力を大幅に消耗させられるという点です。その後納期に間に合わなくなるのは目に見えているため、疲労困憊の体で長時間の残業をしなければならなくなるのです。
どのケースでも共通して言える対策は、「先回りして対応する」という一点に尽きるため、迅速な仕事を心がけるようにしましょう。