COBOLでオフコンな、内部設計に特異点を配するうぉーたーふぉーるな環境に身を置いたせいで、人生で初めてプログラム開発はつまらないと思うようになってしまった。
ひとはなぜこんなにもうぉーたーふぉーるのじゅばくからのがれられないのか。
そんなことを日々考えているうちに、読もうと思って忘れてた本を思い出した。
違った。読んだことを完全に忘却していた本を、初読のつもりで再読してしまった。まるで初読のように。
1975年刊。1995年、1975年版を総括する内容の新装版が刊行された。
人月は幻想であること、ウォータフォールはおかしいことが述べられている。
人月（にんげつ）とは工数すなわち人x月（時間）で表現される作業単位のことで、このように表現するからには人と月（時間）は交換できなくてはならない。だが、実際は交換できない。人が増えれば効率が上がるというものではない。途中参加となればなおさら。通常は失敗するアレ、戦力の逐次投入というやつだ。
この本がどれだけの人に読まれているのかわからないが、発刊から、すなわち少なくとも一つはおおっぴらに問題点を指摘されてから40年以上を経てなお、逃れられない呪縛がある。
ウォーターフォールは工程を遡らない開発手法だ。ひとつひとつの工程が完璧にこなされるから戻る必要はないというものであり、下流の工程でおかしなことになったのなら、それは下流のせい、という手法らしい。
上流にいる人はきっとエリートばかりだったんだろう。どう考えてもおかしいことに、みんな目をつぶっていたんだ。ボスが経費といえば高級ホテルの宿泊費も公費で落ちるんだ。
今の環境でいうなら、外部設計と内部設計のあいだにある滝はひどく高低差があり、外部設計が穿つ淵は深くよどんでいる。不明点の質問というレベルではなく、明らかに足りないものをQAの過程で埋めていっている。となればこれは内部設計ではなく事前調査か外部設計のレビューといわれるべきものになろう。しかし、外部設計のやり直しにはならない。外部設計の工数がないからだlol
外部設計の精度はひどく悪いのに、内部設計にはプログラムの実装まで書けという。ここまでするなら内部設計は不要であろう。開発工程とやらはコピペするだけとなる。
COBOLに対するあれこれをなんとかするためにいろいろあたって、「誰が書いても同じになるCOBOL」という言葉を学んだ。これを実現することはきっと容易ではないのだろう。でなければ、ドキュメントにコードを書けなどというはずがない。コピペするだけだから同じになるわけだ。
社会人になってはじめて不審を覚えた仕事の仕組みはスケジュールというやつだ。
何十本というプログラムの開発に自分の名前が書いてあり、日程的に重複している。一日ずつずれているのはお情けか、コピペじゃないことをしめす小細工か。こうやれば実現できるではなく、これで実現しろ、がスケジュールというやつだ。軍服に身体を合わせろというやつだ。
まともな開発手法に触れることなくこれまでやってきてしまって、というのも火消とか仕様書のない仕事ばかりをやってきたからだが、ようやく触れたウォーターフォールは、もとはどうであったにせよ、歪みに歪んでしまったシロモノだった。
「みんなでレビューしたから、みんな文句言わないでね☆」という官僚主義的な側面と、内部設計は外注だからコキ使えというハラスメントのコラボレーションというところか。
古すぎてなにかなと思うところも少なからずあったが、本書で提示されている問題の多くはマシにはなっているにせよ解決には至っていない。
本書は、問題は開発サイドにあるとしている。ソフトウェア工学や組織学といえるものだ。問題のとらえ方にあいまいな点がなきにしもあらずと思うのは、個人的には、顧客ありきのシステムの場合、顧客自身が自身の仕事の実態を知らないこと、どのようなソリューションがなされるべきかビジョンをもっていないことを経験から得ているためである。
顧客から聞き出すのが仕事だろという話だが、外部設計と内部設計のように、顧客とシステム屋の間にも、ものすごい高低差やよどみがある。
本書で一つ、おもしろい表現があった。
技術の中にはわくわくするものとそうでないものがあり、それを一覧にしていて、わくわくしないものの中にCOBOLがまじっていたことである。
