プログラミング

プログラミング作業は、プログラム設計（詳細設計）の段階で作成した設計書に書いてある内容をコード化するだけで、それほど頭を使わずに行える楽な作業と言える、はずなのですが、実際はそうではありません。

設計書には必ず足りない部分や間違っている箇所があるかです。

机上で組み立てた設計書の中のシステムは、机上でしか確認しておらず、実際に動かして問題がないことを確認したわけではありません。

動くものが出来上がってないので確認できないのは当然です。

もちろん、設計書を作成する段階でレビューなどを行い、その内容で問題がないか確認するわけですが、やはり実際に動かしてみないとわからないといったところは多く出てきます。

さらにスケジュールに間に合わせるために、プログラム設計工程をおろそかにする設計者もいるため、設計者によって設計書の出来が大きく違ってきます。

私が今まで見た中で一番ひどかった設計書は、
「○○帳票を作成する」
と、設計書のテンプレートの上にその一文だけが書かれていたものです。

これを見た時はかなりの衝撃を受けました。
いったいどうしろと……

プログラマ、あるいはシステムエンジニアは"仕様変更"との闘いはまず避けられません。私はプログラマとして働き出して3年以上が経ち、その間に参加したプロジェクトで、仕様変更がなかったことはひとつもありませんでした。

なぜ仕様変更がこれほど多く発生するのか？

働き出した当初はそんな疑問をいつも抱いていたのですが、少しずつその理由が分かってきた気がします。

仕様変更が多いのは、そもそもの仕様を取り決める段階でこと細かく仕様を決めていないというのが原因とするところが多いようです。
仕様をこと細かく決めることを「仕様を詰める」と表現しますが、プログラミングに入る前にその「仕様を詰める」ということが出来ていないと、その後に仕様変更が発生するのは必然なのです。

システム開発を発注してくる会社は、システム開発については素人の場合がほとんどです。
ですので、自分達が欲しがっているシステムのイメージが具現化しておらず、かなり漠然としています。

そこでシステムエンジニアはお客さんがどういうシステムを求めているのか聞き出して、お客さんと一緒にその漠然としてイメージを具現化していくのです。

と言っても、机上の話し合いでは具現化できる範囲は知れており、細かいところはまだ漠然としています。

ですのでシステム開発のプロであるシステムエンジニアは「こういう場合はどうするか？」「こういうケースは考えられないか？」など、「そんなこと確認するまでもないだろ」とお客さんに思わせるほど考えさせ、考えがまとまってから、プログラムを組んでいかないといけません。
その辺をシステムエンジニアが曖昧にすると下流フェーズの途中、高確率で仕様変更が発生します。

ですので、システムエンジニアが「また仕様変更言ってきやがった」などと一方的にお客さんの文句を言うのは、システムエンジニアがお客さんの要望をきちんと聞けなかったということもひとつの原因であるため、筋が通りません。

もちろんシステムエンジニアにはまったく非がないケースもあります。
仕様書に具体的に書いてある仕様を、お客さんに「やっぱりこうしてくれ」などと言われたケースは、システムエンジニアに責任はありません。

プログラマ底辺思考トップへ戻る