「もうバグで悩むのはやめよう」という日経ソフトウエア4月号（2月24日発売）特集の作業が終盤にさしかかったある晩，酒場のカウンターに女性と並んで，グレープフルーツ・ジュースを飲んでいた。

　彼女が勤めている会社は情報システム開発を発注したものの失敗し，訴訟を起こすのだという。「そりゃ，受注した会社はひどいねぇ」と話を合わせたいところだったが，アルコール抜きのためか，どうも調子が出ない。

　プログラムにバグが出て困ったり，情報システムが使いものにならなかったりする話は少なくない。限られた不心得者の仕業であれば，その不心得者を批判したり，制裁を加えたり，追放したりすれば済むだろう。「技術者としての良心」を批判しても別にかまわない。

　しかし，これだけ問題が長続きするということは，何か根本的に間違っているところがあるのではないだろうか。仕事の進め方が的外れなのではないか？　モラルの問題ではなく，経済の問題なのではないか？　そう感じられて仕方がない。特に私は，何かと批判の矢面に立たされているプログラマの立場を擁護したい。

　こうした問題の裏側には，単純化していえば以下のような構図が存在するのではないかと筆者は考える。

　ユーザーは発注金額を抑制する。営業SEは受注するために，多少の無理は承知で請け負ってしまう。提案SEは夢がいっぱいの提案をする。バラ色の契約が結ばれる。契約が結ばれたら発注者は「あとはよろしく」と言う。開発SEはヒアリングもできず，穴だらけの設計をせざるを得ない状況に追い込まれる。

　最後につじつまを合わせなければならないのはプログラマだ。しかもプログラマは経済的にみて，けっして恵まれているとはいえない。これでプログラマは真剣に仕事をするだろうか。自然なこととして，できあがったプログラムは動かない。もし動いたとしたら，それは希少な「技術者としての良心」が浪費された例なのだ，きっと。

　だったらどうすればよいのか。実装にもっとお金をかける，言い方を変えればプログラマにより多くの報酬を支払えばよい。

　まず，ユーザーはもっとお金を払うべきではないか。「オレたちを買いたたいておいて，品質ばかりを要求されても・・・」とプログラマが思っているとしたら，よいプログラムができるはずはない。

　ユーザーの資金の分配比率も変えるべきだろう。システム開発は通常，SEが行う「分析/設計」とプログラマが行う「実装（コーディング）」という2段階に分けられる。二つのうちのどちらか一方しかできないとしよう。「分析/設計だけしました。プログラムはありません」という話が通るはずはない。「実装だけしました。プログラムはこれです」。この方がテストできるだけマシだ。

　つまり，システム開発の本質的な活動は実装であって，分析/設計はそれを支援する工程である。だから，なるべく実装に資金を配分する。

　「問題の本質はプログラムの品質だ！」。SEの方々はそうおっしゃるかもしれない。だったら自分で書けばいい。「コーディングは単純労働だ」と言う人は，ぜひコード・ジェネレータを書いて，人間を単純労働から解放してほしい。それができないなら，プログラマにより多くの報酬を支払ってほしい。

　じゃあ，実装にいくら払えばいいのか？

　ちょっと考えてみたが，ざっと現在の5倍ってところだろう。まず，プログラマの給与を2倍にする。「ペアプログラミング」を導入して一つのタスクに二人のプログラマをアサインする。これで4倍。あとの1倍は，オフィスのレイアウト改善，「トラッカ」「テスタ」「コーチ」の報酬に使うのだ。ちなみに，この辺の単語の元ネタは「XPエクストリーム・プログラミング入門」（Kent Beck著，ピアソン・エデュケーション発行）という書籍。詳細は，そちらを参考にしてほしい。

　当然，「そんなお金，払えるわけないじゃないか！」という反応が返ってくるだろう。とにかく選択肢は複数ある。(1)今のやり方を続ける，(2)たくさん払ってみる，(3)人に頼らず自分で実装をしてみる。どれでも，好きなものを選べばよいと思う。人それぞれだろう。

　酒場のカウンターで話すには内容がヘビー過ぎた。お酒を飲んでいたら，悪酔いしそうだ。

（原田　英生＝日経ソフトウエア編集）