 |
|
| オープンソースソフトウェアの性能・信頼性評価手法
|
第１回：開発基盤ワーキンググループインタビュー
2005/5/17
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
協業することや、これまで蓄積したノウハウを共有することに対して社内での抵抗はなかったのでしょうか？
鈴木氏
それはなかったですね。
|
 （株）野村総合研究所
西片 公一氏
西片氏
ノウハウにもいろいろレベルがありますよね。例えばドライバのインストールとかで試行錯誤しながら得たノウハウって、それはそれで重要だけど、恒久的な価値はそれほどないと思うんですよ。評価手順や、ファイルシステムは何が適しているかといったノウハウも、企業でこっそり持っていたとしてもすぐに陳腐化してしまう。OSSのスピードが速いこともあって、それこそ1年2年の話なのです。そうなると、コストをかけて頑張ってやってもあまり意味がないですよね。
それなら、そういうレベルのものは一緒にやって、お互いノウハウを共有するほうがいいだろうと。インストール手順を共有したって誰も困らないわけですし。SIer的な立場からすると、そういう共通化された部分の中で、上位のアプリケーションだとか、DBのチューニングだとかのレイヤーをもう少し突き詰めてみたいな、というイメージがありましたね。
|
 ミラクルリナックス（株）
吉岡 弘隆氏
吉岡氏
商用ソフトだと、ノウハウの共有はライセンス的に難しい部分があるかもしれないけど、OSSの場合、ライセンスに関してはまったくフリーで、ある程度の共有っていうのは原理的に大丈夫というところがありますよね。
もうひとつは、企業がOSSに本格的にコミットを始めたのがここ1、2年くらいで、商売になるほどのディープなノウハウを本当に持っていたか、という面がありますよね。もちろん、当然レベルの差はあるけれども、持っていてもね、1、2年くらいのノウハウだったんで「これくらいだったらいいかな」と、出すことに抵抗感がなかったんじゃないかな。
PostgreSQLだと、SRAさんは10年近くやっていらして、非常に深いノウハウをお持ちだと思う。だけどSRAさんが参加されるってことで、ノウハウを秘匿するよりもオープンにするほうがメリットがあるんだと皆さん実感したんじゃないでしょうか？それがOSSの強みでもあるわけですよね。
|
 （株）SRA
松田 亮一氏
松田氏
SRAとしてはPostgreSQL関連のサポート、コンサルティングでビジネスしているわけで、ノウハウを流通させるとサービスが売れなくなるといわれるんですが、その前にPostgreSQLのシェアを増やして、ユーザを増やすべきだろうと。
そのためには、導入方法や信頼性はどうだとかの情報をオープンにして使ってもらうようにするべきで、シェアが増えたらビジネスの機会も増えるだろうから、そちらの方が先なのかなって。ノウハウを出すというのは営業活動の一環みたいな感じですね（笑）。
|
 住商情報システム（株）
菅原 孝二氏
菅原氏
弊社でもMySQLの取り組みを始めてまだ2年たっていないのですが、お客さんと話しても「MySQLって何？」というのが最初の反応なんですね。オープンソースに取り組んでいかなければならないという思いがあって、一方でエンドユーザの意識はそこまでいっていないという現実もある。そのギャップの中で、プロモーションの方法としてこのプロジェクトは面白いという認識はあります。
でもデータベースのところだけ関わるのではなくて、トータルでSIをやっていく中で、オープンソースの個々のパーツの認知度を上げていくということをやっていかないと裾野は広がっていかないと思います。サポートメニューを作っても、お客さんがいなければ始まりませんし。そうした意義もあって、各社が協力することに抵抗がなかったのだと思います。
|
プロジェクトは実際にどのような形で進めたのですか？うまく進まないときはどうしていたのでしょうか？
|
鈴木氏
進捗状況は、毎週金曜の午後4時に集まって確認しました。報告書のフォーマットを決め、それをもとに発表していく感じですね。報告書は他社のいい書き方があればそれを見習って、改良を加えながら。
|
三浦氏
問題点だとか、つまずく点って各社で似たところがありましたね。どこが一番先にそれを突破するかっていう話もあって。ああ、先にやられちゃった、とか（笑）。
|
 （株）日立製作所
杉田 由美子氏
杉田氏
OS層で性能評価ツールのLKSTを使ってもらった時も「こういう評価をしたいのだけど」と聞かれれば、ウチのツールをこう使えばこういう情報が得られますよと伝え、なければどう追加すべきかを話し合っていきましたね。
鈴木氏
会議中に高度な議論が始まっちゃって、2時間の予定なのに、9時ごろまでやっていたってのもしょっちゅうでしたね。デバッグを始めちゃって、会議が終わるころバグがとれちゃったこともあったり（笑）。でもそれが、ひとつのポイントだったと思いますね。「メールだけでいいじゃん」という話もあったんですけど、やはりFace-to-Faceでやろうと。
|
プロジェクトがうまく進んだのは、どんなところに要因があったと思いますか？
|
鈴木氏
隠し事をしなかった、というのがあると思いますよ。遅れているのに遅れていないように取り繕っても、最終的には絶対うまくいかないですよね。
|
三浦氏
問題がある場合は、早く見つけて、早く出して、知恵のある人に教えてもらったほうが自分にとっても利がある。最後は成果を公開するというプロジェクトなので、変な意地を張ってもしょうがない、というのもありますし（笑）。
|
鈴木氏
でも遅れているからといってお互いにフォローするということではなく、各社とも立派な会社ですから、任務は会社の責任で遂行してください、という感じです。それしかないですからね、基本的には。
|
三浦氏
それに、それぞれの担当で抱えている問題って、根本的には他の人間では解決できないことがほとんどですからね。
|
杉田氏
障害解析ツールでも、「こういうことで困っているんだけど」と聞かれれば、ウチのツールを使えばこういうことがわかりますよ、こういうツールを使えば障害要因を突き止められますよと、そんなふうに自然と情報を交換していましたね。
|
吉岡氏
何でもそうですけど、プロジェクトが成功する要因は、やっぱりコミュニケーションですよね。それがうまくいったのは、鈴木さんの人柄によるところも大きいと思いますよ。
|
前のページ 1 2 3 4 次のページ
|