日本Javaユーザグループ主催で、クロスコミュニティカンファレンス(CCC)が、4/30日に行なわれました。 この稿ではそのうち「ITゼネコンをぶっつぶせ」というBOFについてレポートおよび考察となります。 講演者はSeasarの開発者として著名なひがやすを氏。会場は立ち見が出るほどの盛況ぶりでした(100人以上はいたと思われる)。

ITゼネコンをぶっつぶせ - ひがやすをblog
ITゼネコンを倒す方法をみんなで考えよう - ひがやすをblog
プログラミングファースト開発 - ひがやすをblog

セッション資料はそのうち公開されるのではないかと思います。

本セッションはITゼネコンの問題点をまず挙げ、ひがやすを氏の考える打開案であるところの 「プログラミングファースト開発」についてのプレゼンといった流れ。

残念なのはひがやすを氏が契約の部分に対して解をもっていなかったという点ですね。 セッション最後に「最大の弱点が契約」とおっしゃっていました。 まさにその点を克服しないことにはITゼネコンが変わることが出来ない。 このあたりについては手前味噌ではありますが以下の考察も参考にして貰えると幸いです。

SIerをカモに金を稼ぐ方法　- プログラマーの脳みそ
技術を持たない人で金を稼ぐシステム　- プログラマーの脳みそ

ITゼネコンよ、仕事しろ

序盤、ITゼネコンの問題については、「上流指向型」と「全丸投げ型」が例示されました。 全丸投げ型は論外として、上流指向というのも結局のところ、相応の仕事ができていないじゃないか、 という点が不満のポイントですよね。開発ができないのに設計するなんて無謀な話。

相応の仕事をした上で、相応の金を取るなら別に文句を言われる筋合いはない。 そうした点で、共通して言えることは「ITゼネコンよ、仕事しろ」ということでしょう。

「ひがやすを BOF ITゼネコンをぶっつぶせ」 に期待 - 凪瀬blog のコメント欄にてメインフレームの話がでています。 メインフレームのような大手でしか扱えないものを扱って金を取るというのは相応の仕事でしょうし、 そういった仕事をやることに対して批判するものではありません。

しかし、オープン系の開発では「資本力を持つ」以上の仕事が出来ていないITゼネコンもある。 そうした仕事はしないのに高利であがりを攫っていくというやり口は批判されるべきだし、 「ITゼネコンをぶっつぶせ」の対象そのものなわけですね。

また、 システム開発が資本力で効率化できない理由 - 凪瀬blog では、IT業界の大手はその資本をうまく活用できていないと指摘しました。

大規模システムの設計 - 凪瀬blog で取り上げた事項ですが

システム開発のコストに一番大きく影響するのはステップ数です。
（中略）
次にコストに影響するのは開発に関わる人員の質だ、とジェラルド・ワインバーグ氏が論文で述べています。
このあたり、詳しくは ソフトウェアエンジニアリング論文集80'sで読むことが出来ます。

と、30年前の論文ですでに開発のコストを下げたければ人の質を高めろと指摘されているのです。

そして、開発者の賃金は、能力による生産性の向上に対してゆるやかな上昇しかしない、 逆にいえば能力に見合った賃金が払われていないため、常に一番能力のある人を高い賃金で雇うことが 最善だということも書かれています。

人を育てて金額相応の仕事をしろ。これに尽きるかと思います。

プログラミングファースト開発

プログラミングファースト開発がいかなるものか、ということについてはひがやすを氏がblogで解説しているので そちらを見て頂くのが一番でしょう。

既存の標準とどう向かい合っていくのか

質問で上がった気になるキーワードに「共通フレーム」というものがありました。 これは社団法人日本電気計測器工業会（JEMIMA）の規定する 共通フレームのことのようですね。

こういったやり方を基準としている場合、どうやってその壁を破るかというのは大きな課題と言えましょう。 会場での質問と似たような指摘が他にもあり ITゼネコンは永遠に不滅、か？ - andalusiaの日記 では経済産業省の「システム管理基準」( PDF文書)を取り上げて、

ＩＴ全般統制という黒船が到来しようとしている今、おおっぴらに「プログラム設計書を書かない！」なんてことは、 多分上場企業の役員さんは言えないでしょう。 なにしろ、向こうには経済産業省謹製の「錦の御旗」があるのですから。 残念ながら、滝派(*1)管理脳が官軍で、アジャイラーは賊軍(*2)なのです。

という考察をしています。 最もこのシステム管理基準についてはその文章の中で

システム管理基準は、本管理基準と姉妹編をなすシステム監査基準に従って監査を行う場合、 原則として、監査人が監査上の判断の尺度として用いるべき基準となる。 ただし、組織体が属する業界又は事業活動の特性等を考慮して、必要ある場合には、 本管理基準の主旨及び体系に則って、該当する関係機関などにおいて、独自の管理基準を策定し活用することが望ましい。 また、時々の関連技術動向、関連法令、及び社会規範などを考慮し、それらを反映した 詳細なサブコントロール項目を策定することが望ましい。

と、そのまま使うのではなく必要に応じて独自に策定しろと推奨しているわけで、 この基準に則らないと駄目だ！という代物ではないのですが、そのまま採用している会社であれば やはりプログラミングファースト開発などの工夫にとっては障害となるのではないでしょうか。

オフショアなんてやめてしまえ！

ひがやすを氏曰く「オフショアなんてやめてしまえ！」ということなのですが（実際の語感は大分違います。念のため） その根拠として「品質向上には垂直統合が効果的」という話をしていたのがとても興味深い。

垂直統合については製造業まわりではよく議論された話題だと思いますが、現状の低品質なソフト開発体制で 水平分散などというのは時期尚早と言えるのかもしれません。

会場で、オフショアを経験した人に成功した例を聞きましたが、現地の教育も含めた質がその鍵のようにうかがえました。 ただ外に出せばいいというものではない。 また、スケールメリットというのも大きく、50名ぐらいの規模を下回ると採算がとれないのではないかという話も。

ちなみに、会場でのオフショア事例を経験されている方は7割ほど、 そのうちオフショアの成功事例を経験されている方は2名ほどでした。 いかにオフショア開発を成功させるのが難しいか物語っているように思えます。

教育にはペアプログラミングを活用しよう

XP(エクストリームプログラミング)が注目された2000年前後にその概念が広まったペアプログラミングですが、 教育的効果が高いということはよく知られているのではないでしょうか。 私も実践経験から、教育手法としては非常に優秀だと捉えています。

ベテラン - 新人というペアの他に、カテゴリ違いの人材をペアにするというアイデアを紹介していました。 これは面白いアイデアだと思いました。

ゲーム業界での事例

こうした方法論の実践事例はゲーム業界にあるとのことです。 この手法をSI業界に持ち込む。それがITゼネコンの体質改善のひとつの方策となるかもしれません。

またこの実践事例より、問題点として以下のことが挙げられていました。

• コードがメンテナンスし辛い
• テストが不十分

このうち、コードのメンテナンス性についてはペアプログラミングで対処できるのではないかと提案していました。 テストに関しては 極力ユニットテストを書かずに品質を確保する方法 - ひがやすをblog の手法を考察されているようでした。 テストに関しては多く議論が交わされていましたね。