ひがやすを技術ブログ

電通国際情報サービスのプログラマ

NTTデータが社内フレームワークをオープンソース化する意味

TERASOLUNAは,NTTデータが開発したフレームワーク開発プロセスである。技術開発や新規事業のために作ってみたソフトウエアではない。NTTデータで1999年から開発を始め,これまで約280の大規模プロジェクトに適用しているソフトウエアと開発プロセスである。NTTデータがオープン系システム開発の標準として現在も使い続けているものだ。

TERASOLUNAは、NTTデータオープンソース化した(元)社内フレームワークです。あのNTTデータと真昼の対決を企画したのもTERASOLUNAチームです。

「『敵に塩を送ることになるのではないか』,という声もあった」---NTTデータ 技術開発本部ソフトウェア工学推進センタ部長 冨安寛氏は「TERASOLUNA」を公開する際にたたかわされた議論を振り返る。

「敵に塩を送ることになるのではないか」というのは、当事者(それも立場が上の人)にとっては、当然最も議論になるところでしょうね。ただ、実際にライバル企業がTERASOLUNAを使ってコストダウンを実現し、案件を競合して負けてしまったということはほとんど起こらないと思います
なぜなら、TERASOLUNAは、フレームワーク開発プロセス、ツール(記事には抜けているような)から成り立っていますが、オープン化されたのは、フレームワークの一部であり、開発プロセスはまだオープン化されていないため、フレームワーク単独で利用するのは難しいためです。
TERASOLUNAは、大規模プロジェクトをターゲットにしているので、がちがちの縛りが多い重量級のフレームワークなはずです。これは、必ずしも悪いことではありませんが、開発プロセスなしで使うと、単なる重いだけのフレームワークになってしまいます。
TERASOLUNAは、フレームワーク開発プロセス、ツールの3点セットで公開しないと、外部の人が利用するにはつらいんじゃないかと思います。
これは、「だからTERASOLUNAは使えない」という意味ではなく、「全部を公開してね」という希望です。
ただし、全部を公開すると「敵に塩を送る」ことが現実に起こる可能性もあり、そう簡単には踏み切れないでしょうね。


というわけで、「敵に塩を送る」ことには、最初からならないと計算してTERASOLUNAの一部をオープン化したんだと思いますが、一部をオープン化することによって、敵に手の内を見せています。これは、英断だと思います。


それでは、なぜ「敵に手の内を見せる」というリスクを犯してまで、オープン化に踏み切ったのでしょうか。

公開の狙いは,システム構築ビジネスとサポート・ビジネスの拡大だ。TERASOLUNAを公開することで,ユーザーにとっては特定のベンダーに縛り付けられる「ベンダー・ロックイン」の恐れが軽減される。特に「政府や自治体などの受注にプラスに働くという期待があり,公共系システムを担当する部署は賛成した」(NTTデータ冨安氏)。またTERASOLUNA自体は無償だが,採用する企業が出てくればそこにサポート・ビジネスの機会が生まれる。

政府や自治体などにとっては、ソースが公開されているってことは安心につながるでしょうね。でも、NTTデータロックインにつながる気がするけど、気のせいかも(笑)。
サポート・ビジネスの機会が生まれるってのは、可能性としてはあるけど、上にも書いたとおり、全部を公開しないとTERASOLUNA自体をきちんと評価することはできないと思うので、ビジネスにはつながりにくいと思います。

年功序列がITの進化を阻害している?

例えば、ITは1980年代以降のものですから、その頃すでに企業の中堅になっていた世代の人たちが、いま企業において決定権を持っているわけですね。その人たちは、新しい技術に適応力を持っておらず、ITが得意なのは若い人です。だから、もし会社の中でITを活用するようなことになったら、下克上が起こる。

 そういう人たちがITの導入に積極的な考えを持つとは考えられません。これは、日本型企業のひとつの特徴である年功序列制が、新しい技術の導入に抑制的に働くことを意味します。

会社の中で、ITを活用するようになったら、ITの得意な若手によって下克上が起こるそうです。どんな下克上なんでしょうね。
まぁ、これはネタだと思いますが、でも、鋭いところもある。
「日本のSIの生産性は20年間進化していない」と読みかえてみると、実はあっているんじゃないでしょうか。ITの技術は、常に日進月歩ですよ。これはまちがいない。SIで使っているフレームワークだって8年くらい前と比べると格段に進歩している。でも、生産性は、あまり変わっていない気がするんだよなぁ。実際のところ。


これはなぜかというと理由は簡単で、開発のプロセスがほとんど変わっていないから。

実際にC/S以降何が起こったかというと、RAD、オブジェクト指向、Webアプリケーションなどの技術がプログラミングの世界を大きく変えることになりました。プログラミングは高度になり、プログラマの実力によって、生産性は大きく左右されるようになりました。

一方、プログラミングが高度になったことにより、プログラミングを知らずに上流工程はできなくなってしまったのです。

プログラムでできることが増えるということは、より使いやすい機能を提供できる可能性があるということですが、仕様を決める人が何ができるかを正確に知っていないと使いやすいものにはなりません。また、昔の汎用機時代の常識を持ち込んでもらっても困ります。ベースとなる技術が違うのだから。

悲劇はここから始まります。経営層は、時代が大きく変わったことを認識できていないので、「上流工程は自分たちが行い」「下流工程は下請けに任せよう」とします。

ここで、老害による悲劇が起こります。プログラミングを軽視し、若手にプログラミングを教えないのです。

技術は高度に進化したのに、経営層がその進化を認識できず、以前と同じやり方で仕事をやろうとするから、生産性は変わらないのです。高度な技術を使わせてもらえない。誰が書いても同じコードが重要だといって縛り付けるからです。もちろん、原因はそれだけじゃないけどね。
「誰が書いても同じコード」は大事なことなのか

経営層の考えを変えられないなら、せめて、老害のウィルスが若手に感染しないように、中堅の人は、若手をしっかりガードして欲しい。

このときに書いた心配が現実に起こっている気がする。今の大手の中堅どころが「上流工程は自分たちが行い」「下流工程は下請けに任せよう」って思っているようにみえる。「自分たちは管理する人」みたいな。


だから、野口さんには、「老害による日本の停滞を打破する究極手段」って本を書いて欲しい。