吉村先生と大山

ソフトウェアは放っておくと腐る

―2002年にプロジェクトは終了したのですよね。

そうです。当時も今も変わらないのですが、競争的研究資金の元で進められる研究プロジェクトには、必ず期限があります。未来開拓事業も5年と決められていました。私はプロジェクトの開始時から、我々がこれから生み出すADVENTUREを未来開拓プロジェクト終了後も生き残らせるための方策を真剣に考えていました。

2002年3月にプロジェクトとしては一旦終了しましたが、その成果を維持していくためには、お金も優秀な人材も必要であるのは明々白々です。

矢川先生と同世代の小柳義夫先生[東京大学教授（当時）]のお言葉で「ソフトウェアは生ものである。放っておくと腐る」というものがあります。ソフトウェアは、ほかのハードウェアベースの成果物とは違うのです。例えば薬品の場合は、成分と製造法を理解しておけば時代が進んでも製造していくことができます。

それに対してソフトウェアは常に手を入れておかないと使えなくなります。時代の変化と共に動作環境やOSが変わっていくので、機能がまったく変化しないとしてもそのような環境変化に対応させる必要があるのです。

さらに、この分野の研究開発の進歩は速いですから、当初実装した機能もいずれ陳腐化していきます。常に最新技術への対応が必要となります。最新技術へ対応しつつ、ソフトウェアを正常に動き続けるようにする努力も必要ですし、R&D（Research and Development）への取り組みも両方必要です。

―当社でもR&Dへの取り組みを強化していこうと動き出しています。

そうですね。その両方の体制がないと、特にこのような計算科学のソフトウェアはいずれ使いものにならなくなってしまいます。公開したとたんに陳腐化が始まって、あっという間に使えなくなるぐらいです。

1つ目の工夫～突き抜けた機能の埋め込み～

そもそも汎用の計算力学ソフトウェアは市場にいくつもあり、社会の大半のユーザーはそちらに慣れているので、新しく出てきたコードに目を向けてもらうことは極めて難しいものです。

そこでADVENTUREに目を向けてもらうための1つ目の工夫として、ADVENTUREにしか実現できない、突き抜けた機能をソフトウェアの中に埋め込むことにしました。あれこれできるという汎用的な機能を付けても差別化にはならないですし、その割には開発作業も膨大になります。

そこで機能を絞り込みつつも、従来の計算力学ソフトウェアではできない圧倒的に大規模な計算を可能なコードとして開発しました。従来の計算規模より２桁３桁上の大規模な計算ができることや、それまでに誰も見たことがないような複雑な形状の問題が解けるということを示しました。

これは、ちょっとやそっとの努力で実現可能になるようなものではありません。正にADVENTUREの強みとなる、他のコードと圧倒的な差をつけるものでした。もちろん、大規模な計算をするためには、そのモデルを準備するプロセス（プリプロセスと言われる）も重要であり、それを適切に準備できる技術者の議論も行いました。

その部分ではアライドエンジニアリングには随分助けてもらい、その中でも湯山喜芳さんには彼の知識やスキルを十分に活用してもらい非常に大規模で魅力的な解析を実現していただきました。

当社がモデリングを担当した大規模で複雑な形状のモデル

それ以外に当時から考えていたこととして、流体など他の解析との連成があります。私自身が元々原子力や核融合分野、マイクロマシン分野における連成解析やそれに関する様々な研究をしていたので、構造解析で複雑な形状の問題を解けるだけでは、実用レベルで大規模な問題になってきた時に機能的に不十分だなと考えていました。

構造を理解しながら、なおかつ実用レベルの大規模な連成解析を様々な並列計算機環境において、フレキシブルにできるようにしたいという想いは常にあり、そのための工夫やベストな方法を模索していました。モジュール間に標準的なIOを開発し採用したのは、そうした連成解析や設計解析への適用を念頭においていたからでもあります。

2つ目の工夫～オープンソースとして公開～

ADVENTUREを生き残らせるための2つ目の工夫として、オープンソースとして公開することにしました。オープンソースとして出すか出さないかは、プロジェクトのメンバーとも何度も議論し方針を決めたのです。

しかし、無料公開するというだけでは不十分です。まず、どうやってユーザーが使える形で維持していくかが課題でした。オープンソースを元にするにしても開発する場合はユーザー側にも人件費が掛かってきますし、使用するためのノウハウの構築も必要です。無料というだけでは使われません。

それに大規模計算が可能なオープンソースを維持するためには、優秀な複数の人材と膨大な費用が掛かります。オープンソースコードは今では普通にあるものですが、当時はあまりなく、維持費用調達のために様々な機関に掛け合いましたが、理解してもらうことがまた一苦労でした。

ADVENTUREをオープンソースとしてフリーで公開することによって、様々な企業や研究機関が活用し手を掛けるので、産業界で実用的に使えるようになります。それが結果的に日本の産業競争力にフィードバックされます、という説明をしっかりと行いました。そのための文書も時間を掛けて作成しました。

オープンソースとしたことにより、プロジェクトメンバー各人がそれぞれ開発した別々のモジュールが、全部一か所に集まっている状況にすることができます。そうなれば、プロジェクトが終了後も引き続き皆で関われる環境を作れるわけです。

ADVENTUREに関わっているメンバーはそれを元に、また自分たちで研究費を獲得したり、産学連携を続けたり、またチームを組んで新しいテーマに向かって一緒に動き出せます。実際にそのような成果があり、ADVENTUREのバージョンアップ時に新しい機能を入れる際、別枠での研究成果がADVENTUREに取り込まれ、自律的に進化していくということを実現しています。

また、アライドエンジニアリングではADVENTUREの技術を活用しつつ、新しいものを取り込んでADVENTUREClusterを作り出しました。

ADVENTUREはゼロスクラッチから生まれた

ADVENTUREのコードをオープンソースとして公開することが可能だった理由は他にもあります。それはゼロスクラッチからプログラミングをしたことです。

当時は他者が開発した既存のコードをソフトウェアに入れこむ傾向がありました。コード開発の効率を考えたら、すでに出来上がっている技術を組み込んだ方が楽なわけです。

しかしそういうことをすると、後々その技術の開発元が配布ライセンスを変えた場合、組み込んだコード全体がオープンソースとして公開できない問題に繋がってしまいます。当時もそのような事例がしばしば起こっていました。

このような経緯から、活用できそうなコードがあったとしても、極力自分たちの力でゼロスクラッチから作るようにしました。そうすれば開発した人だけではなく、外部の研究者や技術者をユーザーとして呼び込むこともできますし、それを自由に開発して商用ソフト化もできるようになります。

開発言語の選定についても、当時としては新しい方針を取りました。当時、有限要素法のコードはFORTRANが主流でした。一方、開発環境については、情報系分野の影響でUNIXやLinuxといったオープン系の技術が使用されていました。

そういったオープン系の開発環境はFORTRANよりもC言語の方に親和性があるのですが、一方、従来から計算力学を行ってきた方からは、よりなじみがあるFORTRANを使用して欲しいという要望もありました。

しかしながら、これからはフリーの環境が主流になっていくだろうという読みがあり、また、様々な計算機環境、ネットワーク環境の登場が予想されたので、様々な観点から議論してC言語を採用する方向にしました。

開発側のエフォートが報われるように

―当時、オープンソースの成功例としてLinux等が注目されていました。ADVENTUREもオープンソースですが、その先例と同じように、多くの人を開発に参加させる路線を選択しなかった理由を教えてください。

その理由の一つとしては、計算力学の既存ソフトウェアではほとんどがクローズドな環境での開発であったからです。ADVENTUREはオープンソースにはしたけれども、一方で開発の主体を広げ過ぎないようにもしました。

Linux等の成功例はあったものの、そのコードを元に開発したコードの公開を義務付けるライセンス（GPLなどのコピーレフトと呼ばれるライセンス）とはしませんでした。

もし、そのようなライセンスとした場合、新機能リリース時に必ずコードを公開しなければならなくなり、それによって応用や個別の研究、商用化などには使いづらくなってしまいます。それでは、せっかく開発した人のメリットが減じてしまうと考えたのです。

ユーザーが多数いるような環境であればそういった方法も良いと思いますが、計算力学ソフトウェアにおいては環境が違います。オープンにして皆が開発していく環境でありながらも、開発した人のエフォートが報われる形態。手を掛けた本人に、それなりの見返りが来るようなライセンス形態の方が良いと考えました。多くの人が関わるソフトウェアの研究開発では、知的貢献をした人がある程度報われる仕組みも必要なのです。

力学関係はしっかりした知識が必要で、不特定多数の人が開発したコードを無条件に安心して使えるかというとそうではありません。顔が分かる、信頼関係が成立した環境の元で開発する方がよいというのがもう一つの理由です。

また、実はADVENTUREは、オープンソースといいながらも実はライセンスに制約を掛けている部分もあります。何故かというと、使い方によってはどうとでも使えてしまうようになってしまうからです。軍事研究等に使用されてしまうようなことに繋がる可能性もあります。

制約を掛けずに、もう少し自由に情報を出した方が世界的なユーザーはより多く獲得できたのかもしれません。一方で、国の予算で開発してきたものを軍事研究等に使われてしまうリスクを考えると、制約を掛けるべきだとも思います。

我々が青春を賭けて、知恵を出して開発してきたものを変なところに使われて欲しくないので、ある程度は自分たちのところに開発の主体を残してきているという想いがあるのです。

3つ目の工夫～特殊なチューニングを制限～

3つめの工夫は、メンテナンスのしやすさを実現したことです。SC（Super Computing）分野では、ある特定の計算機に向けて徹底的にチューニングして性能を上げる傾向があります。しかし、そのコードを別の並列計算機で動かそうとすると使い物にならない場合があります。

私が例えとしてあげるのですが、F1のレーシングカーが公道でも速いのか、という話と似ています。もちろんSC分野での、研究実績としての価値は確かにあります。

一方、ADVENTUREでは標準的な開発環境を基本とし、特殊なチューニングは行わないようにしました。移植性やメンテナンス性と計算性能を両立できる、ある程度の落としどころを見極め、あえて自己制限を掛けたのです。

当時からすると、スーパーコンピューター用のコードを作っているのに徹底的なチューニングはしないとなると、違和感を持たれてしまう面は確かにありました。

しかし、私たちはエンジニアリングで実用レベルの問題を解決したいと思って開発をしていますし、その後のメンテナンスや移植性を担保することこそが、汎用ソフトウェア開発ではすごく難しくもあり重要であると考えたのです。