前回で述べた話は、プログラマとして十分な経験を積みたたき上げたＳＥにとっては当たり前のことです。
システムの開発工程の中で、それでも難しいことが、まだ二つ残ります。

その一つは、お客様の前で直接会話してシステムに求められる機能をその場で決めていく場合です。
短時間の会話の中で、要求された機能に対してシステム内部のイメージを作り、
出来る、出来ないを決めなくてはなりません。
出来る場合は良いのですが出来ない場合には、現実世界のシミュレーションの中から
お客様の求める効果に近い代替案を考え、さらにはその代替案のシステム内部のイメージを作り、
提案しなければなりません。
そもそもこの仕事はサービス業なので、お客様の案に特別な無理がなく、代替案がなければ、
効果が確実なお客様の案を無理を承知で受けるしかないでしょう。
この部分の難しさは、会話をしながらの短時間のうちに二つのシミュレーションをしなければならない点です。

もう一つは複数会社により連動する複数業務システム開発を行う場合なのですが、
会社をまたがって他システムインターフェースを決める場合です。
通常、他システムインターフェースは基本設計工程で確定され、それ以降変更することは至難の業です。
つまり基本設計工程でプログラミングのイメージを作り上げる必要があるのです。
この難しさは二つ先のシミュレーションを行わなくてはならないことにあります。

最後に、システムの開発工程の中で忘れがちな大事なことをことをもう一つ話させてもらいます。

それは、プログラミング工程で品質の作り込み自体をおざなりにしてしまうことです。
品質の作り込みの九十数パーセントまではここで行われるのです。

プログラミングの後のテスト工程にたよって十分な品質を確保することは至難の業です。
人の頭を開けてみて生産ラインのチェックができれば良いのですが、
そのことは会話またはコード自体から読み取る以外にありません。
あるプログラマが、その時点で求められるスキルレベルに極端に達していないことが判明した場合には、
（そのプログラマにとっては残酷な話ですが）
スクラップ＆ビルドが最も早い選択の場合がほとんどです。

つまるところシステム開発の最終到達点は、
効果的な機能仕様を持った使用に耐える品質のプログラム群を作り上げることです。
正確に作るためのドキュメントはもちろんのこと、
メンテナンスのためのドキュメントを作成するのであっても、
それはプログラミング群がきちんと出来た上での話です。

プログラミング以外の全ての工程は、プログラミングのためにあるのであって、
そのことを忘れてプログラミングをおろそかにして、良いものができるはずがありません。
ですから管理のレベルでは、他の工程を皺寄せたり、端折ったりしてでも、
出来る限り十分な時間をプログラミングのために確保するように努めなくてはなりません。
進捗の遅れをプログラミング工程で取り戻すようなことは、
本当に愚の骨頂でトラブルを招いているようなものであることは言うまでもありません。

実際にコードを編み綴るプログラマの方は、
プログラミングでのあいまいさの排除を
制限つきの時間の中で出来る限り理想的な形で実装し、
それを目視であっても動作を確認しなければなりません。
プログラマは、プロフェッショナルとして、
「硬いコード」を書き、そして確認しなくてはいけないことを、
強く自覚しなくてはなりません。