なんでJavaのプログラムでCOBOLチックなコードが出来上がっちゃうのか?を考えてみた

日々、なかなか面白い日記をUPしているid:ryoasaiさんが、これまたなかなか面白いエントリをUPしていたのでちょっとTBを送ってみる。

SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている?
http://d.hatena.ne.jp/ryoasai/20110109/1294581985

書籍の例題プログラムやOSSで公開されているソースを作成したプログラマーは、それなりにオブジェクト指向を理解している優秀なプログラマー達なのですから品質の極端に悪いコードを見かけることはめったにありません。その一方で、以前にも(グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと)で指摘したように、SIerが開発したシステムのソースコードがネット上に公開されたり、議論されたりすることは当然ですがほとんどありません。しかしながら、記述されているコードの分量から言えば、日本SI業界においてネットや書籍で多くの人から評価されないJavaコードの大半は、この試験の問題が象徴しているような低品質のものが多いということがやはり事実ではないでしょうか?

OSSなどで活躍されている一流のプログラマーの方々は、こうした業界の有り様には興味がないのでしょうか?実際、

などという議論がネット上で盛んに行われていますが、こうした一流PGの方々は、業界の一般のPG(私を含めて)とはまったく別次元の遠く離れた世界で生きているのではないかと感じてしまいます。

ちょっと長めの引用になってしまったけど、このあたりについてちょっと考えてみた事を書いてみようと思う。これは、私も最近「リアクティブプログラミングが世界中のソフトウェア技術者の95%に普及しない」とか書いて、「先端の人と現場との乖離」みたいなものを感じたので、その原因がいったいどこにあるのかを考えてみる。

ITに係わる仕事をする人や会社とっても、「コンピュータを使う」という点での共通項はあってもいろいろな違いがある。ひとまず思いつくままに列挙してみよう。

  • みんなに使ってもらって喜んでもらえるようなサービスを作る(はてなとかmixiとか)
  • 既にある社会インフラを支えるような基幹系システムの保守・再構築(IBMとかデータとか)
  • 研究開発(民間の研究開発部門とか大学とか)
  • ゲーム関連の開発(スクエニとかレベル5、最近だとモバゲーとか)

まず思いついたので仕事の分野で書いてみたけど、他には経営者、マネージャ、技術者みたいな社内での役割の違いなんてのもある。多層の受注構造の元受と下請けみたいな構造のなかで、どこにいるのかの違いもある。会社員かフリーランスかみたいな違いもある。最終的には能力の高低もある。こういった立場の違いがあるなかで、「これからのソフトウェアのありかたはこうだ!」とかの記事が@ITなんかに載ったとしても、書いた人の思いそのままには、読む人によって伝わったり伝わらなかったりする。これだけだとちょっと混沌としているので、違う切り口で整理してみよう。その為に、ちょっと歴史を振り返ってみる。時代とともに立ち上がってきた、大きな3つの仕事のかたまりを見てみよう。

1950〜

最初に始まったのはEDPとか呼ばれる仕事。コンピュータの仕事は「事務の効率化」であって、今みたいな「みんなが自由に使えるサービス」なんてものはなかった。銀行のお金の決済や出し入れとその記録、年金の記録・支払い、いろんな会社の給与や財務会計、物流関連の仕事や、交通だと運行管理やチケットの予約・発券。お役所の住民サービス。電力会社の発電施設の管理・制御や、お客様への料金請求。工場の生産管理や産業用ロボットの制御。こういった事務処理を機械化して正確性と効率を高める(人を減らす)。この時代に多く使われたのがCOBOLだった。この時代に働いていた人たちをいまどきはCOBOLerと呼んで揶揄したりするけども、これらの仕事の殆どはCOBOLで実装する前提での分析・設計をしたし、他に選択肢は少なかった。IT業界の黎明期にこれらの仕事を受注できたのはかなり資本力のある所だったので、こーゆー仕事をしているところは大手が多い。IBM、日立、NEC富士通みたいな、自分でハードウェアも作っているところがハードとソフトを一括して仕事をする。90年代あたりからオープンアーキテクチャなんていう流れがでてきて、そこから大手一本でやっていたのが、複数のベンダが絡んで仕事をするケースが増えてきた。いわゆるSIだ。データやNRIが登場するのはそのあたりの時代の要請があったからだと思う。最近だとオープンアーキテクチャの流れの延長で、基盤としてWeb技術を使うと便利そう!とか考えて、従来のEDPシステムをWeb技術をベースに再構築する仕事なんかも増えているところが、気になるところ。
私のいまの立場は、主にこの分野の金融機関をお客様にした仕事で、かなり現場寄りな所です。

1990〜

このあたりからゲームの仕事が増えてきた。ファミコンが83年、PC Engineが87年、メガドライブが88年、ゲームボーイが89年、初代プレステが94年という感じで、80年代に下地ができて90年代から大量にゲームソフトウェア開発の需要が高まった。このあたり、市場規模の推移を示す統計とかあればもっと面白いんだけど、まあ、今回はそこまで追及しない。私自身よくこの業界のやりかたとか知らないけど、EDPとは明らかに目的が違う。なので、その作り方、仕事のやりかたも相当違うんだろうなーと思います。ましてやCOBOLの開発はないよねw でも、比較的新しい技術が投入されてくる分野で、ハードウェアの制約が強く働く。そう考えると、プログラムを作る色々なテクニックで武装したプログラマが活躍するっていう感じがするな。ま、私のイメージだけどもw 最近ではケータイゲーム(携帯ゲーム機ではなく、携帯電話としての方)が流行っている。そしてWeb上で遊べるゲームもあって、ちょっとWeb業界とクロスオーバーな感じになってきているのが気になるところ。

2000〜

このあたりからWeb業界の仕事が増えてきた。個人向けのインターネット接続は90年半ばぐらいから本格的になったけど、当時Webにあったのは個人の趣味サイトがほとんどだったと思う。FTPGopherの方がWebよりもよく利用されていた時期もあった。あとはNetNewsとか。この頃のWebは大きな企業がビジネスをする道具ではなかった*1。それが変わってきたのは2000年ごろからかなと。Amazonが始まったのが2000年、ヤフオクが始まったのが2001年、はてな人力検索をスタートさせたのも2001年、Wikipediaの日本語版も2001年、mixiがサービスインしたのは2004年。Web界隈では老舗と思われる所をもっと書ければよかったんだろうけど、思いつくのはこんなところか。そして今では百花繚乱、玉石混交といった状況になっているのは皆さんご存知の通り。ここらあたりが面白いのは、ゲームではないんだけど「娯楽性」を、EDPではないんだけど「利便性」をそれぞれ、一般の個人ユーザに提供するのが目的になっている事。EDPともゲームとも目的は微妙に異なる。それはきっと「楽しさ」を提供するのが目的になっているからだ。人間の生活に、なくても困りはしないんだけど、あったほうが面白い・楽しい。そーゆー事にコンピュータが使われるようになった。ゲームの頃からそれは始まっていたけれど、より緩く、そして多くの人に届く感じ。最近だとそこに、ソーシャルなんてキーワードがついてfacebooktwitterが出てきている。個人的にははてなハイクが好きだけどw
技術的にはWebの世界は真新しいまっさらな世界なので、必然的に新しい技術が研究されて採用されてきた。そしてそれがどんどん進化を続けていて、今でも新しい技術が開発され続けている。あと、すごくオープンで相互の接続性にかかわる部分も標準化が進んでいる。相互の接続性が高まる事で、既存のものを組み合わせて作る新しいサービスも日々生まれてきている。やっぱり今一番ホットな分野だなーと思う世界だ。
 
 
やや大雑把ではあるけれど、時代とともに新しい仕事が立ち上がってきたという事を示せたと思う。そしてその目的や、使われる技術の違いもざっくりとはわかるかなと。研究機関は入らないんだけど、これはもう例外かなと。無理やりに当てはめるとすれば、常に最先端を追いかけているので全部の分野の立ち上がりに関係がある。ま、これについては深く追求しません。
 
 
で、最近はWebの技術をEDPの世界でもゲームの世界でも使わないといけなくなってきている。本来、違う目的で使っていた技術を、別なところで使おうとしたところに、いろいろな人の行き違いや軋轢、技術のミスマッチや不適切な使われ方が生じているのが今の状況なのかなと。特にEDPの分野では「事務の効率化」が仕事としてプログラムを作る動機であって、当時必要十分だったCOBOLを使ったシステムを当時既に作ってしまっていたという事情もあり、技術に対して保守的だっていう背景があるので、ゲーム業界の人よりも深刻だ。そして、ここで生じたミスマッチというのが、Webの日記やtwitterなんかで指摘される。クラスがクラスになってないとか、継承がないとか、ヘンな命名規約があるとか。それがもし新規で作られたシステムの新規でつくられたプログラムなのだとしたら、きっと技術者のスキルに問題があるのだろう。その場合はそれを問題にするべきだ。
でも
EDPという分野の仕事は全くもって新しくない。昔からある仕組みで、大抵は既存のシステムが動いている。そしてその昔からあるシステムは大昔にCOBOLで書かれる事を前提に分析・設計しているわけです。で、さあこれをシステム更改しましょう!となったとき、その理由は「事務のプロセスを見直して会社組織全体の効率を改善しよう!」*2なんていうものではなく「今使っている大型汎用機、ハードウェア保守期限切れだからシステム更改しないとだめだってさ。」、あるいは「大型汎用機の維持コスト高いから、小型のPCサーバにダウンサイジングしましょう!」だったんです、大抵の場合。後者の2つの理由の時、設計を見直す理由はない。むしろ、プログラムなんかは変えずにそのまま移行できれば最高だ。でもここで、「Webシステムとして再構築しましょう。」になってしまった。理由はいくつか考えられる。

  • JCLやハードウェア依存の部分があったりしてPCサーバに移すにしろどうせCOBOLをそのままは移行できない。
  • 必要な部分だけ改修をかけたいけど、年々減っているCOBOL技術者の調達が難しい。
  • Java技術者のほうがCOBOL技術者よりは調達が容易。
  • ベンダーがCOBOL to Javaの移行ツールを提供している。機械的変換ができれば楽(コスト削減)
  • 中国への発注で人件費削減。要求は「このCOBOLと同じプログラムをJavaで作って!」これなら発注は簡単。
  • Javaの方が生産性が高い(但し、COBOLの移行に使う前提で成り立つかは激しく微妙w)

こんなところか。あと、仕様・設計レベルの見直しがやりたくても出来ない理由というのもいくつか考えられる。

  • 現場の利用者(事務処理をしているオペレータ)の要求は「今のやり方を変えないでくれ」。
  • そもそも、設計書・仕様書がない。→今のプログラムの通りにするしかない。
  • 設計のやり直しをするにも、要求分析からやり直すにしろ、金がかかる。
  • やんなきゃいけない理由(保守期限切れ、コスト削減)からして、そんなにお金をかける理由は無い。

これらの事情が重なると「Javaプログラミング能力認定試験」の問題になるようなプログラムが大量に作られるわけです。なんせ、移行しないといけないプログラムはうんざりするほどあるんだ。プログラムの構造を変えずに機械的に変換をかけてテストするだけでも莫大な金額になったと思う。その時の移行プロジェクトの目的を最高のコスト効率で完遂しようとしたら、こーゆー事になる。もちろん、それでも分析・設計をやり直したほうが、全体の生産性は上がるし、保守コストを考えたらそっちのほうが安上がりになるはずだよ!という主張はある。でもその論を通すには具体的な数字を出さないといけない。それでダメだったら責任問題です。数字を出すのも大変で、一苦労や二苦労はしないと出ないでしょう。労が多くて益がすくなければ、なかなかこーゆー事を押し通す人が出てこないのも、仕方が無い事かなと。

念のため自己保身の言い訳をしておくけど、私はこの現実が最高で、「技術の使い方がおかしい」って技術者の指摘を否定する考えではないです。ただ、いろいろな制約のある現実社会の中で、やむをえず苦しい選択をしないといけない場面はある。単純な技術者の技術不足や上長や発注元の技術への無理解なんて浅いところでグダグダ言っても何も変わらないよと。もしこの現実を変えたいなら、上に列挙したような問題を解決する方法を考えないといけない。それが、いい技術を使いたいという願いを持つ、みんなの宿題ということになる。このみんなには、もちろん私も含まれます。

現実は苦くて苦しい。でも、それでも、明日もその現実を生きないといけないんだ。どうすれば明日をちょっとでも良く出来るのか、それを考えて生きようじゃないか。

蛇足:まあ、本当に超のつくド新規でも、ゴミみたいなコード持ってくるところも現実にはある。付き合いがあるので、そこを切って捨てるわけにもいかん。なるべくレビューをやったり時には勉強会をやったりしてなんとかして底上げをしようとしているんだけども、そーゆー所をどうしたらいいのか?という問いはあるんだよなあ。

*1:商売をしていたのはプロバイダー業で、それもITではあるけど、今回の主題であるプログラムの技術ってところとは違うのでパス。

*2:システム投資するには役員会を通すような大義名分が必要なので、こんな言葉が横行した可能性は高い。