SEとして何年か経験を積んでみると、案件によって仕事の難易度がピンキリであることを実感しますよね。中には数十人のチームの一員となり、積みあがった仕事に忙殺されることもありますが、人間、要注意なのはそんな時です。
余裕を失くして判断力を失い、気づけばとんでもない迷走を始めていたという経験はありませんか？
ここでは筆者が実際に経験した、努力の方向性を完全に間違えてしまった現場について、その一例をご紹介します。

要件が複雑化しても、当初の予定に拘り続ける

これはあるシステムのデータベースを、物理サーバから仮想サーバに移し替えることになった時の話です。システム改修ではないため、JP1のジョブを一気通貫で実行し、そのログを解析しよう、というテストと解析がメインの案件でした。
私が担当していたのは、ExcelのVBAでログファイルを簡単なキーワードを使って収集するツールだったのですが、プロジェクトリーダーが「どうせならトラブル時にも使えるツールにするべきだ」と言い出したあたりからおかしくなり始めました。
当初の簡単な仕様はどこかに行ってしまい、リスト化した曜日や祝日、エラーレベルでのフィルタリング機能までつけることになったのです。
フィルタリング機能なんて、エクセルの機能を使えば簡単にできるものなのに、リーダーはあくまで「全自動で全ての機能が動くこと」に拘り続けたために、処理は重く、それでいて使いにくい、非常に非効率なツールになってしまいました。

課題別にブランチが作られたソース管理

いくつもの課題を複数のチームで同時に対応しなければならなくなった場合、デグレードは何よりも気を付けなければならないポイントです。自分の作ったソースが他のメンバーに上書きされないよう、ソース管理ソフトを用いてロックをかけたいところですが、筆者が以前参画したプロジェクトの中には、おかしな方法が取られていました。
余りに大量に発生した課題の数々に焦ったらしいプロジェクトマネージャーは、何と課題別にブランチ（大本のソースを複製し、それぞれのチームで修正したものを後でマージする手法）に分けてしまったのです。
こんなことをしてしまっては、後でマージを行う作業が大変になるばかりです。開発メンバーはすぐにプロジェクトマネージャーに抗議したのですが、「もう皆に周知したから」と一蹴され、結果として開発者全員がいらない苦労を背負うことになってしまいました。

詫び状システム

筆者が最初に勤めていた会社は、受注してくるシステム規模の大きさの割に納期が短い、いわゆるブラック気味の企業でした。無理な納期のため、当然のように炎上案件が多く、品質の悪さによってしょっちゅうクライアントやユーザーに頭を下げる結果になっていました。
特に問題になったのは、勤怠システムの不具合です。労働時間の集計を間違え、給与計算にまで影響してしまい、何百人ものユーザーに「○○円の齟齬があり、申し訳ありません」という旨のお詫びの書類を郵送することになってしまいました。
そんな状況の中、上司の一人が出してきたのが、「詫び状システム」です。
IDと姓名、金額や文言を入力すると、謝罪の書面を自動で作成し、印刷まで行うというものでしたが、そんなものを作る暇があるならプログラムのクォリティを上げればいいのにと、メンバー全員で呆れかえった事件でした。

目先のことに囚われてはいけない

ここまで挙げた事例はどれも、思い出すだけでウンザリするような出来事でした。その全てに共通していることは、目先のことで手一杯になった結果だった、ということです。
SEの仕事とは、緻密な全体像を見据え、地道な作業でそれを実現させていくこと。自分が作業の指示を出すような立場になった時は、このような情けないことを起こさないように、広い視野をもって仕事に臨むよう、気を付けましょう。