何が起きているかを知り、受け入れることの大切さと難しさ。

汎用機システム開発。時代から取り残されたかのように言われるIT業界の遺産の管理人を社会人となって中断を挟みながらも７，８年やって来ている。

先週、担当していた印刷プログラムを開発期限に間に合わせるために上司と徹夜した。直せるのは朝までという限れた時間の中でどこまで直すかで、もめた挙げ句、
「こんなやり方じゃいつまでたっても終わらねーよ、担当外すからな」
と上司には匙を投げられ、俺は途中で修正を切り上げるはめになりさんざんだった。そもそも、顧客の要件を詰めないまま開発を行ったことに始まり…言い出すときりがないのでやめるが、結果、開発期限になっても、顧客が納得するものが出来なかった訳だ。

上司と対応について話したが開発に対する認識がちぐはぐなところがしょっちゅう顔を出す。「ツー」と言えば「はあ？」といった感じ。特に違和感を感じたのが、

「開発手法はウオーターフローなんだからきっちりやれ。それにちゃんとしたプログラムの構造化とかを知らないからこんなことになるんだ」

という発言だった。

まず、
「開発手法はウオーターフローなんだからきっちりやれ」というのは発言としては正しい。
顧客の要望をもとにシステム仕様書を作成し、実際にどのように作るかシステム設計書を作成してから、実際に作り込む。
なら、作る担当のはずの俺がシステム設計書を書きながら、作り込んでいたことを黙認していたのは矛盾する。
いわば、師匠秘伝のラーメンレシピを勝手に書き換える弟子を許すようなもので、役割分担が曖昧になり、上流への行きつ戻りつする事が目的を見失わせ、混乱を招き、開発を遅らせたのだ。
実際にはやらせていたつもりだったのだろうがそうではない事に差し迫るまで気づかなかった訳だ。
また、差し迫るまでシステム仕様書の矛盾や未決事項の存在に気づかなかったのは確かに俺の責任だろうが、担当が一人じゃ、システム仕様をちゃんと盛り込んだ設計書を作成したか誰がチェック出来るというのだろう。よくわからない。

では、
「ちゃんとしたプログラムの構造化とかを知らないからこんなことになるんだ」はどうだろうか。
俺が問題を起こす理由付けとしては全くその通りだと俺も思う。体系だったプログラミング技法は、習う事が無かったからだ。仕事での経験によるOJTのみでこれまで乗り切って来たと言ってもいい。
仕事として請け負っているのだから、（能力的に）期限内に出来ないようなら、出来ないと言えばいいともいわれていたのも事実だ。
でも、だからこそ、俺は、能力の限界が来ても、明らかに遅れが発生しても、仕事から引く事が出来ない。どんな形であれ、難易の高い仕事を、手放す事はすなわち成長の機会をみすみす捨てる事になるからだ。俺だって無能者に居る場所は無い。そのくらいに危機感は常に持っている。そういう背景は、上司には見えていないだろうし見透かされた場合警戒されて今後が心配といえよう。

そして、最も問題にすべきは、
ウオーターフォールを適用し、技術力がある社員を担当に当てても、完成間近で仕様変更がされてしまえば、行程の戻りが発生し大幅に遅れるという現実である。
開発期間短縮・低コストを謳う新しい技術に対抗するために開発期間が短くなって来ており、使える時間が短くなった分行程の戻りによる失敗のリスクは以前より、高くなっているのは間違いない。
また、印刷物や画面表示等は顧客にしてみれば、現物無しでは、判断がつきかねる点が多いのだから、ウオーターフォール技法はそもそもなじまないのだ。
俺としては開発手法自体が古いこと、仕様を固めてから開発依頼するウオーターフォール手法の鉄則が顧客に受け入れられていない事を問題にしたいのだが、まあ、失敗してからでは無理かなあ。
今回も、テスト結果を見た顧客が、
仕様変更を言い出し、上司がその場で仕様書を直し、修正を指示して来た。

切羽詰まれば何でもあり。
でも、それじゃ、いつまでたっても出来ませんよ。