Hatena::ブログ(Diary)

達人プログラマーを目指して このページをアンテナに追加 RSSフィード Twitter

2011-01-09

SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている?

私自身は10年以上も前(JDK1.1の頃)にSJC-Pの認定を取って以来、Javaプログラミング関連の認定試験は受けていないのですが、昨日たまたまネットを検索して、SJC-Pとは別にJavaプログラミング能力認定試験という試験が存在していることを知りました。結構メジャーな認定試験のようですので、現役のJavaプログラマーJavaプログラマーを目指している学生さんで、今後受験に向けて勉強されている方々も多くいらっしゃるのではないかと思います。

試験は難易度に応じて3級から1級までランクが分かれており、2級まではJava言語の知識に関する筆記試験ですが1級の試験では実際のプログラムの修正を行う能力が実技試験として課せられます。試験範囲は以下で公開されています。

Javaプログラミング能力認定試験(試験範囲)

私は(自分で言うのも変ですが)、Javaプログラミングについてはこの道15年近くのキャリアーがある「ベテランJava PG」なので、最上級の1級に余裕で合格できなくては恥ずかしいと思われますが、この1級の試験については実技試験で機能追加を行うベースとなるプログラムソースコードと設計書が正規のサイトで公開されていました。いきなりぶっつけ本番で仕様書を渡されてゼロベースでプログラムを書くということではなく、事前にソースコードを十分読み込んだ上で試験に臨むことができるようです。もちろん、プログラムのどの部分が改変対象となるのかというところについては公開されていません。(ちなみにサンプル問題を見る限り、改変は機能修正や機能追加であり、リファクタリングということではもちろんないです。改変部分の変更定義書の記述も必要。この問題が既存の設計をあるべきオブジェクト指向設計リファクタリングせよということであれば、非常に難易度が高いけど、チャレンジしてみたいと思う良問となるのですが・・・。)

私としてはちょっと興味があったので、以下から1級の試験問題のサンプルを実際ダウンロードして、試験で改変する対象となるプログラムの設計書とコードを読んでみました。

Javaプログラミング能力認定試験(試験サンプル)

もともと、この試験の目的としては

Javaに関する基本知識を有し、オブジェクト指向に基づくアプレットアプリケーションプログラムを作成できる能力を認定します。

オブジェクト指向に基づく分析・設計(UML)により業務システムの流れを把握し、変更仕様に従ってプログラム保守ができる能力を有する。なおUMLの表記はユースケース図、シーケンス図、クラス図などの基本的な知識を有する。

ということになっていて、あくまでもオブジェクト指向言語の試験であることが明記されているようですが、ダウンロードした設計書とコードを見ると、純然たる手続き型構造化のクラス設計で作られていることが一目瞭然でした。まず、個々のクラスの単位が以下のように処理の単位、すなわちCOBOLの主プログラム、副プログラムと同じ考え方で分割されています。このことは以下のようにクラス名が通常のように名詞ではなく、機能を表す動詞となっていることからも明らかです。

クラス名処理概要
Manage人材派遣管理メインクラス(機能選択)
DContents機能表示
GChars入力受取り
GGList業種リスト作成
JDelete人材情報削除
JDisplay人材情報表示
JInput人材情報追加
JUpdate人材情報更新
KDelete稼働状況削除
KDisplay稼働状況表示
KInput稼働状況追加
SInput検索情報入力(検索条件指定)
SOutput人材検索

これがStrutsのアクションのような感じでTransaction Scriptとして作られているなら良いのですが、そういうものではなく、純粋にCOBOLプログラムのような設計となっています。そして、クラスの抽出の方法のみでなく

  • ファイルから読み込んだレコードデータをオブジェクトに入れず、すべてString[ ]やString[ ][ ]などの配列として扱っている。(コレクションクラスはほとんど使われていない)
  • 単にグローバルメソッドのstatic importの目的のためだけにクラスを継承している。ポリモーフィズムは一切活用されていない。
  • privateやpublicなどのアクセススコープの指定は(mainメソッド以外)一切ない。
  • メインクラスからサブクラスまで処理単位の入れ子モジュールとして構造化されている
  • ファイルの読み込み(データアクセス)、画面出力、ロジックが混在して記述されており、アーキテクチャー上まったくレイヤー化されていないし、MVC構造といったものもない。
  • FileReaderなどの低水準のクラスを直接アプリケーション層のクラスが扱っている。(例題とは言え、例外処理やクローズ処理がいい加減過ぎる。)

などなど、これが資格試験の問題なのかと目が点になってしまうような驚くべき設計のコードとなっています。まさに、以前にJava EEや.NETはCOBOLやVB6よりも本当に生産性が高いか?で指摘したように、COBOLの方がよほど生産性が高いのではないかと思われるような設計となっています。

一応出題者の名誉のためにフォローしておくと、この試験の目的は

あくまでも取得した後に実社会で価値のある認定試験であること

ということのようなのです。よって、日本のSI業界でJava PGとして仕事をするためには、オブジェクト指向的にきれいなあるべき姿でコーディングできるスキルではなく、このようにオブジェクト指向をまったく理解していない上流のSEが作成した異常な設計書に忠実にしたがってコードを書き、また、その複雑なスパゲッティコードを長期にわたってメンテナンスする根性と忍耐が最重要のスキルとして試験で試されているということなのかと私は理解しました。(そういうことであれば、私はこの試験に合格する自信がないですが。)

運良く私がPGとしてかかわったプロジェクトではここまでひどい設計を押し付けられたことは無いのですが、仕事に役立つとされる資格試験の最上級の試験で、このような問題が出題されているという事実をあらためて知り愕然としました。

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

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

などという議論がネット上で盛んに行われていますが、こうした一流PGの方々は、業界の一般のPG(私を含めて)とはまったく別次元の遠く離れた世界で生きているのではないかと感じてしまいます。でも、少なくとも20年は遅れた開発手法が蔓延している、日本のSI業界のPGを取り巻く環境の惨状を、今後もはたして放置しておいてよいものなのでしょうか?確かに、このような時代遅れで低レベルのプログラムを開発しているのは自分とは関係の無い、ブラック会社などSI業界の底辺の一部の世界で行われていることなのであると単に無視してしまうことは容易です。しかしながら、一般の職業Javaプログラマーの大半は、旧態依然としたSI業界の枠組みの中で日々働いています。このような問題をずっと見過ごしていては、今後もSI業界を支える多くのプログラマーの価値が低く評価され続け、無益かつ過酷な単純労働を長時間強いられることになる*1のではないでしょうか?技術者として自分の興味のある最新技術を追いかけるのもよいですが、私としてはこういった業界の問題があたかも存在しないことのように無視され続けるのは非常に残念に思います。

なお、そもそもこの例題プログラムで行っていることは、単純なタブ区切りのファイルに対するCRUD処理を行うものです。今の時代にこのようなシステムの構築に最低限RDBを使うのが当然ということはおいておいたとしても、設計書に記載されているシステムの仕様自体、ビジネス上ほとんど価値のない事をやっているわけです。それにもかかわらず、正しい設計であれば本来不要な、大量のコードや設計書の記述が必要で、ちょっとした機能追加を行うだけで最上級の試験問題のネタになってしまうくらいに大変な作業が要求されることになるのです。プログラミング技術のわからないSEの書いた不適切な設計書に従ってこのような生産性の低いコーディング作業を行うのであれば、確かにPG付加価値の低い単純労働であり、その仕事に対する労働対価は非常に低いということはそのとおりであり、私としても否定する余地がありません。

ところで、百聞は一見にしかずです。機会があれば、この例題プログラムをあるべき形にリファクタリングした結果と、そのリファクタリング手順を皆さんにお見せできればと思います。そうすれば、生産性を向上させ、PGとして付加価値の高い仕事をする上で、プログラムの正しいアーキテクチャー設計がいかに大切であるかということをご理解いただけるものと思います。

*1:問題の本質は単に3Kとか7Kとかいうことではなくて、PGとしてのスキルが正当に評価されることなく、単純労働を強いられるということにあります。

名無し名無し 2011/01/10 11:51 PGとか言ってる時点で狭い日本のSI業界でしか生きていない。どう略したらProgrammerがPGになるんだ?恥ずかしくて俺は使えん。

ryoasairyoasai 2011/01/10 14:04 PGという用語については、http://d.hatena.ne.jp/ryoasai/20101215/1292424227で書いたとおりですが、やはりSI業界固有の用語ですかね。SEと同様に今後は積極的に使わない方が懸命かもしれませんね。やはり、PGという言葉はイメージが悪いのでしょうか。
省略については、英単語の最初の2つの音節の先頭を取ったものではないですか。(Pro・Gram・mer)

hageyahhoohageyahhoo 2011/01/10 15:45 私も、プログラミングを知らない SE の作成した設計書と日々格闘しているところです。
そういう人たちと一緒に仕事をしていると、どうしても彼らに「妥協」しなければならない時が出て来ることを心苦しく感じています。
動ける側が動けない側に合わせてあげなければならない…本当に高いスキルが要求されるのがいわゆる「下流」側というのが、なんとも皮肉な感じがします。

UrinUrin 2011/01/10 20:48 大手SIerのSE兼プログラマです。

>などなど、これが資格試験の問題なのかと目が点になってしまうような驚くべき設計のコードとなっています

確かに試験として出題される内容としては「驚くべき」設計ですが、
私が今いる環境では、「当たり前すぎる」設計で、
怒りを通り越して何も考えることができない状態で、
そんなことを考えるより、目の前にある腐った仕事を一刻も早く片付けようと、
敢えて盲目的になる努力をしています。
理想を考え始めると、吐きそうになるので。

本当にオブジェクト指向より忍耐力が求められているんです。
実際、上の人間は何も分かっていないことを分かっていないので、
忍耐力が必要となるような努力を求めてきます。
それを止められる上の人間もいない・・・。
かと言って、あの巨大なスパゲッティをリファクタリングするには、
要求される以上のコストが必要なのは明白なので・・・
どちらにしてもイバラの道。

であれば、「なるべく既存のソースを流用しやすい形で」設計することで
管理者が大嫌いな「リスク」を少なくできると考えているみたいです。
何に対してのリスクなのか全く理解できませんし、
自分の知識の及ばない技術に「恐れ」を抱いているようにしか見えません。
技術出身で管理職になるのはやはり辛いことですね。

なまえ なまえ 2011/01/10 21:01 下流な人がいくら「こんなイカれた設計をよこしやがって」と息をまいていても、
上の人たちは「あいつらバカで良くわからない色気だして失敗しそうだから、
仕方なくイカれた、しかし枯れた(今までほかはなんとかなった)設計をしてやるか」とでも思っているかもしれません。

この投稿や上の人のコメントを見るに、双方が「あいつはバカ」と罵り合うより、
もう少し歩み寄り(もしくは、新しいスタイルの開発)を行ったほうがいいのかな、と。

ryoasairyoasai 2011/01/10 22:10 >であれば、「なるべく既存のソースを流用しやすい形で」設計することで
管理者が大嫌いな「リスク」を少なくできると考えているみたいです。

プログラミングのわかるhands-onアーキテクト(http://d.hatena.ne.jp/ryoasai/20101125/1290693787)の仕事がもっと尊重されるようになれば、個々のコードの中身の品質には目をつぶるとしても、全体としてはもう少しまともな設計もできるのではないかと思います。レイヤーを分けるとか、業務機能ごとにサービスモジュールを分けるとか。そうすれば、部分的にリファクタリングする余地もできますし。とにかく、この問題のように、見かけ上シーケンス図などオブジェクト指向を装っていても、実は単なるフローチャートだったりするような設計を上流SEが作って、それをいきなりコードに落とすというCOBOL文化を、そのまま現代的な開発に持ち込まないようにするあたりが、当面、上流と下流が歩み寄るための妥協案としては現実的な落としどころかと考えています。

t-tomiokat-tomioka 2011/01/11 00:26 私も、いわゆるプログラマのお仕事をしています。
指摘されている「生産性の低いコーディング」はとても理解できて、無視できない問題であるとおもいます。
この記事を読ませて頂いたときに思い出したのが
野球のコンディショニングコーチで有名な立花龍司さんの言葉です。
「日本野球はサボる人間に合わせてルールを作っている。メジャーリーグはベストを尽くす人間に合わせてルールを作る。」
サボる(勉強しない)人に合わせるのは冗談じゃないという思いはありますが
正直解決する方法は見つからず、その組織を抜ける方法を考えようという結論に
どうしても至ってしまいます。

ryoasairyoasai 2011/01/11 01:28 >「日本野球はサボる人間に合わせてルールを作っている。メジャーリーグはベストを尽くす人間に合わせてルールを作る。」
なるほど、そういう言葉があるとは知りませんでした。確かに伝統的には日本はチーム全体の成果、欧米は個人の成果とは言われますね。ただ、高度成長時代とかにできた格言であれば、現在にもそれがそのまま当てはまっているかどうかは多少微妙なところがありますが。
救いようがない会社なら、選択肢の一つとして組織を抜けるというのもありだと思います。実際、SI業界といってもさまざまな会社があると思いますし、別の業界への転職もあるわけですから。
ただ、本文にも書いたように多くのプログラマーはSI業界で働いているのが現実なので、やはり、全体として今の状況が改善される良い方法がないかと思うわけですが。悲観的な意見が多いですね。以前はSeasar2などでJavaEE関係で活躍されていた比嘉さんもhttp://d.hatena.ne.jp/higayasuo/20100823/1282550428のようにおっしゃっていますし。

shinsuke789shinsuke789 2011/01/11 12:11 Javaプログラマーです。

日本のSIerの悪いところですね。
そもそもSEなんていう職種あるんでしょうか。
それさえなければプログラマーの価値っていうのはずっとあがるんですけどね。

自分も古いシステムのメンテナンスをやっています。
最新技術を使えば楽にできるのですが、すでに動いてるので置き換えなんて出来ません。
毎度、ソースの解析に時間がかかるし精神的にもしんどいです。

常に良い設計に変えつつリファクタリングをしています。
同じようなことを考えている人がいてちょっと嬉しいです。

この例題をリファクタリングして公開したら今のシステムの中身がいかに悪い設計、コーディングでになっているかが分かるようになりますね。

ryoasairyoasai 2011/01/11 13:41 SEについては私の考え方は以下に書きました。http://d.hatena.ne.jp/ryoasai/20110106/1294318585

例題のリファクタリングは鋭意実行中です。
早ければ今日にでもアップできると思います。お楽しみに。

norinori 2011/01/11 13:50 単に駄目試験だってだけなのでは。

ryoasairyoasai 2011/01/11 13:56 そのような駄目試験が10年近くも「実践的な試験」としてずっと生き残っていることが病んだ業界の構造を反映していると思います。その点を看過してはならないと考えます。

AC/DCAC/DC 2011/01/11 14:20 たぶん、
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
のコラムニストとか、
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
で書かれているマネージャのためにあるんだろう。

izagonizagon 2011/01/11 15:04 現場のPM、SEが無理解なのに加えて、採用や育成の担当者も「分かってない」のが原因じゃないかと思います。新しい技術を習得し、より良い方法を実現しようとする熱意と努力の無い人たちが、いろんな場所で影響力を使いすぎていますよね。

通りすがり通りすがり 2011/01/12 00:27 まさにAC/DCさんのいうとおりではあるが^^;

現実問題として、COBOLチックな書き方は『文法は知ってる』(逆に言うと文法しか知らない)プログラマを現場に投入して戦力と出来る点はメリットでしょうが、その後の保守や延命を考えると最悪の方法です。単体テストがまともに出来ないし、複雑度も恐ろしいぐらいに高いですからまっとうな品質は保てないですからね。
まぁそれがマッチポンプになって保守料を・・・、ってそれはあまりにも酷いですわ。
(うちの会社はそれでかなり痛い目みてますし)

yorickyorick 2011/01/12 10:05 SIer中心の設計がヘボすぎる、PGのレベルが低すぎる、という主旨はまったくその通りだと思います。
ただし、(論点が違うしレベルの低い問題を持ち出すように聞こえたら、申し訳ないんですが)オブジェクト指向設計をちゃんと理解せずにオブジェクト指向プログラミングの機能を使いまくるPGは最悪の結果をもたらす、という明白な事実もありますよね。そして、オブジェクト指向設計をちゃんと理解できるレベルの人口は、それができない人の数に比べて少ない(したがって、人月勝負のSI調達対象とすること困難である)ことも明らか。問題とされていた資格試験は、そういう低レベル人口を対象としたものなのかもしれません。
私は、オブジェクト指向設計を本当に理解しアプリケーションのフレームワークを設計できる上級の「コアプログラマ」がSIerにも絶対必要だと思います。しかし、そのフレームワークの上で与えられた道具立てを使って素直にシーケンシャルなロジックを実装してくれる多数の人間も、メガステップ級のプロジェクトでは調達せざるをえないのではないかと思います。

chao2sukechao2suke 2011/01/12 14:34 私は6年目に入った所謂業務系のプログラマーですが、SEとPGの違いがよくわからなくなってきました。
うちの会社ではSEの人がまとめてくるのは画面仕様とDB構成図、どのデータをどのように計算してどう格納、参照するかということで、レイヤーやクラス分け等は全てPGの仕事です。半年1年レベルの大規模プロジェクトでもそうです。
なので記事にあるような不可思議なクラス分けを
「設計が悪い」「このようにオブジェクト指向をまったく理解していない上流のSEが作成した異常な設計書」
と断じているのを読み
「もしかして自分が普段やっているのは設計なのか?だとすればSEの人がやっているのはなんなんだろう?」
と多少混乱してしまいました。

OTTiiOTTii 2011/01/13 14:00 chao2sukeさんへ。あなたの職場での役割分担は結構理想に近いものな気がします。設計といっても、ユーザーの業務の一部としてシステムがどのように動作するのか(いわゆる外部設計とか詳細設計とかいわれるやつ)と、それをコンピュータプログラムとしてどのように実現するのか(こっちは内部設計とか詳細設計とかいわれるやつですね)に分かれると思います。このうち前者の方をあなたの会社のSEさんがやって、後者をあなたを含めてPGさんたちがやっているのではないでしょうか?これら二つの設計はCOBOL全盛時代の大昔ならいざ知らず、現在ではかなりスキルの方向性が違うものだと私は思っています。
またレイヤーやクラス分け等をあなたを含めたPGに任せているということは、PGの力をSEの人たちはそれなりに信頼しているという事でもあると思います。元記事やそのコメントでもあるような嫌な状態というのは、SEはPGのことを任せておくとなにをしでかすか分からない無能なコーダーとしてしか認識せず、またPG側もSEのことをプログラムも出来なくなった時代遅れのやつらとしか認識していないが上に培われた酷い状態なのだと思います。

月並みですが以下の翻訳記事も参考までに挙げておきます。
ソフトウェア設計とはなにか?(http://bit.ly/b1HuJ9)

ryoasairyoasai 2011/01/13 19:56 @yorickさん。私もSIerと呼ばれる会社の人間ですし、おっしゃることは非常によく理解できます。実際、私人本当にアジャイルでバリバリに開発した経験も無いですし、最近はある程度大規模な何件のアーキテクトを担当することが多いので。ですから最新技術を追い求める「一流」プログラマーの発想からは妥協ということになると思いますが、上のコメントでも書いたように以下のように考えています。

>プログラミングのわかるhands-onアーキテクト(http://d.hatena.ne.jp/ryoasai/20101125/1290693787)の仕事がもっと尊重されるようになれば、個々のコードの中身の品質には目をつぶるとしても、全体としてはもう少しまともな設計もできるのではないかと思います。

だから、そんなに考え方はずれていないと思います。でも適当に妥協することも達人プログラマーの教えなのかなとも思います。達人プログラマーとは本来Pragmatic Programmerなのであり、メンバーのスキルの制約なども考えて最適な妥協点をも見出せる人のことを言うのではないでしょうかね。
ただし、http://d.hatena.ne.jp/ryoasai/20101208/1291821499でも指摘しましたし、また、多くの人が以前にもいろいろと説明されていますが、今後大量の人を集めてメガステップのコードを記述することで売り上げを上げるという伝統的なSIの考え方のビジネスはますます厳しくなっていくことは確かだと思います。私は直ちに基幹業務システムを作成する仕事がすべて汎用的なSaaSに置き換わるということは信じていませんが、今後はその会社固有の業務など、少なくとも少数精鋭できちんとしたオブジェクト指向のできるレベルの開発者を集めて、高品質のシステムを構築するという仕事が中心となるべきであると考えています。

ryoasairyoasai 2011/01/13 20:02 @chao2sukeさん、@OTTiiさん。コメントをありがとうございます。
既に私のブログのいろいろな場所で指摘させていただいているとおり、アーキテクチャーや内部設計はプログラマーが担当し、いわゆるSEは、業務フローやデータ標準化など非常に業務よりの設計を行うというのが理想的であると考えています。
問題なのはこの問題に象徴されているようなCOBOL的なSEとPGの役割分担にあります。SEやPGという言葉自体がそうした古い役割分担を示しているのであれば、今後は利用を避け、ディベロッパーとかアナリシストなど別の名前で呼ぶのも良いと思います。以下も是非ご覧ください。
http://d.hatena.ne.jp/ryoasai/20101227/1293454488
http://d.hatena.ne.jp/ryoasai/20110106/1294318585

hamlet-rhamlet-r 2011/01/14 01:37 最近、大手のSIerがSEとして文系の学生を好む傾向にあるようですが、厳しい就職戦線を潜り抜けて入ってくる学生の正体が、実はコピペ学生だったり( http://blog.tatsuru.com/2011/01/09_1554.php )する所に問題の根っこがあるような。

開発標準があればあればで、それを盲信してしまうし。無ければイメージ、概要レベルで曖昧でいい加減な設計しかしないし。もうやれやれとしか、何でちゃんと考えることをしないのだと、言いようの無いむなしさを感じることが多いですね。

もう少し対象の問題構造や情報構造を分析する力とか、アーキテクチャパターンの検討とか、理想を追求する姿勢を見せて仕事をしたいものです。やっぱりシステムエンジニアは普通の文系学生にゃ無理だよ。

COBOCOBO 2011/05/27 16:35 「すなわちCOBOLの主プログラム、副プログラムと同じ考え方で分割されています。」って、本当にCOBOL知っているんですか?20年以上前から構造化プログラミングできますよ。

ryoasairyoasai 2011/05/28 03:16 「主プログラム、副プログラムと同じ考え方で分割」というのはCOBOLが構造化のプログラミング言語であるということを言っていているのでおっしゃる通りですし、本文の内容と矛盾していないと思うのですが。もちろん、ここでは条件文やループ構造などより粒度の細かい部分のプログラム構造については最近の手続き型言語では当然として触れていませんが。ここでは、Javaなのにオブジェクト指向プログラミング的なモジュール分割の設計になっていなくてCOBOL85のような構造化プログラミング的になっていることを問題と主張しているのです。

ryoasairyoasai 2011/05/28 03:23 誤解を招きやすい表現だったため、手続き型を構造化に修正しました。でも、試験問題のプログラムが構造化のモジュール構造としてもきれいに分割されているとも思えないのですけれどね。

ene0kcalene0kcal 2011/10/20 05:46 今頃来ましたが、例題の設計(実装)が変わっているようですよ。一応、ステートマシーンを用いて設計しなおしされていますね。もちろんクラス名もオブジェクト指向らしい命名になっており、OODされています。

ryoasairyoasai 2011/10/24 00:03 はい、試験問題が修正されているようですね。以下の記事もごらんください。

http://d.hatena.ne.jp/ryoasai/20110611/1307811507
http://d.hatena.ne.jp/ryoasai/20110612/1307848780