SIer と受託開発、エンジニアの未来 (前編)

IT

先月 13 日に開催された「エンジニアの未来サミット」を受けた id:gothedistance さんのエントリー「受託開発がつまらないなんて言わせない」に端を発し、受託開発に関する議論が盛り上がったようだ。遅ればせながら、私も意見を述べたいと思う。
「エンジニアの未来サミット」で、私は観客席から 3 人目の質問者として、人月単価での受託開発がなぜここまで主流になり、そしてなぜその火が衰えることがないのかという意味のことを質問した。ただ、前々回のエントリーとして公開した私的不完全議事録にその部分の具体的な記述がなかったこともあり(現在は追記されています)、少し誤解を招いたかもしれないので、補足させてほしい。

私は長野で、いわゆる SIer と呼ばれる業種の会社に勤務している。この会社に転職してきて最初に投入されたプロジェクトは Java + Oracle の業務アプリケーション開発だった。プロジェクトが始まって驚いたのが、SE クラスの人たちが作ったデータベース仕様と、そのプロジェクトで使用する自社開発の Java フレームワークだ。

例えば、顧客ごとにある数値を毎日記録するテーブルがある。そのテーブルの定義はこんな感じだった。



  KOKYAKU_ID  VARCHAR2(8) PRIMARY KEY NOT NULL

  NEN         VARCHAR2(4)

  TUKI        VARCHAR2(2)

  HI_1        NUMBER(8)

  HI_2        NUMBER(8)

   :

  HI_31       NUMBER(8)

  BIKO        VARCHAR(200)

これを DX_10352_KOKYAKU_FOO_DATA のようなテーブル名で作る。そして、このテーブルからデータを持って来る Java のクラスが TABLE_DX_10352_KOKYAKU_FOO_DATA という、Java の命名規約をまるで無視した名前のクラスだ。このクラスをインスタンス化する際は、Java の命名規約に従って(!)最初の 1 文字は小文字にせよという。結果として、以下のような目がチカチカするコーディングを余儀なくされる。「Camel Case」という言葉は誰一人知らなかった。



  TABLE_DX_10352_KOKYAKU_FOO_DATA tABLE_DX_10352_KOKYAKU_FOO_DATA =

      new TABLE_DX_10352_KOKYAKU_FOO_DATA();

  tABLE_DX_10352_KOKYAKU_FOO_DATA.setKOKYAKU_ID("12345678");

  tABLE_DX_10352_KOKYAKU_FOO_DATA.setNEN("2003");

  tABLE_DX_10352_KOKYAKU_FOO_DATA.setTUKI("05");

  tABLE_DX_10352_KOKYAKU_FOO_DATA.getData();

このコードの続きはこんな感じになる。



  String[] hi = new String[32];

  hi[1] = tABLE_DX_10352_KOKYAKU_FOO_DATA.getHI_1();

  hi[2] = tABLE_DX_10352_KOKYAKU_FOO_DATA.getHI_2();

HI_1 〜 HI_31 は NUMBER(8) なのになぜ String[] なのかって? このフレームワーク経由で取得したデータは、データベースの定義によらず何でも String になるからだ。このため、次のように引数がことごとく String になっているメソッドをあちこちで目にする。



  String getTesuryo(String nen, String tuki, String kokyakuKbn,

      String shohinKbn, String kingaku)

  {

      :

      :

  }

このデータ取得クラスをテーブルやビューの数だけ Excel マクロで生成する。データベースアクセスの部分が実装された親クラスを継承しているのかと思いきや、Excel が吐き出すすべてのクラスにデータベース接続から開放まで全部丁寧に書かれている。

きりがないし、自社を見下すのが目的ではないのでこの辺にしておくが、一事が万事こんな COBOL 崩れのような開発手法だった。私は新人のくせに分をわきまえず、「こんな設計はおかしい」「こんなやり方は見たことがない」といちいち食ってかかるのだが、何を言っても「みんなと同じやり方でやれ」の一言で却下される。揚げ句の果てには三項演算子(hoge = foo ? bar : baz)までコードレビューで指摘されて if 〜 else に書き直させられた。仕様変更が生じたとき、目視でコードを書き換える際に一人だけ違う書き方をしていると見落とすからというのがその理由だ。

方眼紙 Excel に書かれた仕様書とにらめっこしながらこんな理不尽なコーディングを延々とさせられていると、徐々に自我が崩壊してくる。これはコーディングのクセとか、設計の流儀とかいうレベルの話ではない。ソフトウェア工学を専門に学ばなくとも、こんな常識のはるか斜め上をゆくやり方はおかしいと普通は気づくだろう、なぜ、自分の主張はまったく聞き入れられないのか──。

このような理不尽なシステム開発を余儀なくされているプログラマが SIer と呼ばれる会社にたくさんいることを、私は後になって知った。不平不満は表に出やすいことを勘案しても、まともな設計や手法を使わせてもらえないプログラマが多数派なのではないか。

ようやく「エンジニアの未来サミット」の話に戻る。多少なりともソフトウェアの勉強をしてきた新人は、こんな馬鹿馬鹿しい開発をさせられて最初のうちこそ反発するが、数年経つとまるでおとなしくなってしまう。足枷をはめられた象は最初のうちは激しく暴れるが、その抵抗が無意味であることを知ると暴れるのをやめてしまい、足枷を外されても逃げることはしなくなるという。彼らが調教された象に重なって、暗澹とした気分になるのだ。

「属人的な要素を極力排除した、誰が作っても同じように作れる仕組みに則った人月単価による開発」はそれほどまでにプログラマを従順にさせる力があるのか。また、使用者側にとって、人月商売はそれほど旨味があって手放せないのか。そんな思いで、私は要領の得ない質問をした。よしおかさんとひがさんから胸のすく回答をいただき、私は快哉を叫んだのだが。

受託開発が楽しいかと聞かれれば、私は楽しい仕事だと思う。未来があるかと問われれば、あると答える。システムを開発してお客さまの困りごとを解決するというのは、コンサルティングに近い領域の仕事だと思うからだ。ただし、「お客さまと直接お話をして、それを元にシステムを提案する」というのが前提条件だ。二次請けや三次請けとして、元請けの持ってきた狂った設計書とぶっ飛んだフレームワークを押しつけられ、提示された費用と期間で作る「コーダー」としての仕事には、喜びも未来もない。いわんやイノベーションをや。

長くなったので、続きは次回にさせてください。