メールニュース

ローグウェーブ ソフトウェア ジャパンでは、情報メール(eNews)を不定期で配信しています。 eNews では、製品のリリース情報、特長や機能紹介、 イベント&キャンペーンのご案内、お客様におけるローグウェーブ製品の導入事例の他、開発者向けのコラムを連載しています。弊社からの情報メール(eNews)をご希望の方は、件名に「eNews 希望」と明記の上、メール でお申込み下さい。 これまでに掲載した開発者向けコラムは以下をご覧下さい。

特集:開発者向けコラム


第一回:車輪の再発明の魅力と罠

車輪の再発明(reinventing the wheel)」という言葉があります。既に世の中に存在して広く使われている道具を、自分で1から改めて作ることであり、ソートアルゴリズムや独自の行列クラスなどを自分で作った経験は誰にでもあるのではないでしょうか?「車輪の再発明」は、先人が築き上げてきた技術的資産を使わずに無駄な作業を行って結局劣化コピーを作っているにすぎない、と批判的な意味合いで使われる言葉ですが、開発者としてはなかなか逃れることができません。

その理由の1つとして、既存の道具を改めて作り上げることが完全に無意味なことではない、という言い訳が成り立ってしまうからです。代表的な言い訳としては、1) 既存のものは目的に合わない。2) カスタマイズ性。3) 教育/学習目的。といったものが挙げられます。1) は例えば「既存のライブラリの想定している環境は今回のターゲットと違う」「想定通りの使い方ができない」といったものです。 2) は 1) とも関連していますが、使う道具は隅々まで自分がコントロールしておきたい、というものです。NIH(Not Invented Here)症候群もこれらに当てはまります。3) としては「自分で作ることによってそのアルゴリズムやデータ構造の思想を習得し、より適切な使い方ができる」といったもので、確かにその限りでは正しいのですが、実務の現場で常に勉強をしているというわけにも行きません。

ソフトウェア開発の世界ではデータコンテナ、ソートアルゴリズム、数値計算関数や可視化ライブラリなど様々な先人の知恵が用意されています。商用にせよオープンソースにしろ(ライセンスにご注意!)、長い期間にわたって広く使われてきたライブラリは様々な環境やドメインでの様々な使われ方を通して洗練されています。そうした先人の知恵を賢く利用することによって生産性を高め、自分ならではの独自の価値生成に注力する勇気が大切です。

by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top

第二回:「オープンソースの魅力と注意点」

オープンソースという開発スタイルの優位性を高らかにうたった「伽藍とバザール」から約20年。それ以来ウェブブラウザやテキストエディタをはじめとする多くの魅力的な製品や、現代生活の根幹を形成するzlibやOpenSSL、Linuxなどのさまざまな技術がオープンソースによって実現され、供給されてきました。伝統的な企業製品と共に OSSは現代の情報技術を考える上で欠かせない存在となっています。人気のある活発な OSSコミュニティは多くの開発者を集め、柔軟な新機能開発や、すばやいバグフィックスを行うことができます。ソースが公開されているため、企業製品にありがちな提供元による供給の終了といった懸念もありません。最後に、OSSは多くの場合無償あるいは少額の寄付で提供されるため、コストを抑える上での魅力も見過ごせません。

とはいえ一方で伝統的な企業製品とは異なったOSSならではのリスクもあります。主なものとして、GPLなどのライセンス条項違反による訴訟問題、セキュリティ脆弱性への対応可能性、不安定なサポート体制などが考えられます。また、使用する企業側でも気軽に導入できるがゆえに管理が杜撰になり、組織の大きなプロジェクト内のどこでどのようなOSSが使われているのか、きちんと把握することは困難であるため、潜在的なリスクが見えづらいという問題もあります。

ローグウェーブのサービス『OpenLogic』にはこれらの「把握、安全性、社内管理、サポート」の諸問題に対して一連の解決策が用意されています。ぜひご覧いただいて安心してオープンソースの魅力を享受し、開発を加速させましょう。

by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top

第三回:「まずは齧ってみる」

世の中は日進月歩で変化し、ちょっと前なら考えられなかったような新しい現象、事件、考え方が次から次へと登場してきます。 中でも私たちが主に活動しているIT技術の世界の変化はあまりに急速で、数多くの開発言語、ツール、フレームワークが現れ、あるものはあっという間に時代を象徴しあるものはあっという間に消えていきます。開発者や研究者のみなさんは、そういった新しい技術が登場するたびに興味半分、不安半分で距離のとり方を模索することになります。時代に乗り遅れるのは致命的ですが、逆に仮に時間をかけて習得した技術が時代遅れに なったとしたら、趣味の開発ならともかく仕事の上では大きく不利に働きます。かといってそういった中長期のトレンドを見極めることは誰にもできません。

そうした予見不可能な世界を生き抜くためには、「ちょっと齧って、まずそうだったり毒になりそうだと感じたら早めに撤退する」 という戦略が必要になります。自分である程度触らないと何も判断できませんが、これは違う、と感じたり、自分もしくは携わっているプロジェクトに向いていない、と感じたら早々に撤退することです。そのためにはその技術の初期の習得コストがある程度低くあるべきでしょう。豊富なドキュメントと使い方事例、わかりやすいAPI、親切なコミュニティやサポートの存在が不可欠です。

Java版のMapReduceフレームワークであるHadoopと呼ばれる技術があり、一時期もてはやされましたが現在では失速を懸念する声も聞かれます。今までリレーショナルデータベースの世界で活躍してきた方が急にMapReduceの独特のデータ構造やアルゴリズムに馴染むのは時間がかかるように思えます。勉強して身につけたところで果たして潰しが利くのかどうか、不安に思うのは当然のことです。そんな時、そのギャップを埋め、少しでも学習曲線をなだらかにする助けとなるツールが世の中にはいくつか存在します。以下のブログで紹介しましたが、ローグウェーブソフトウェアのJava版数値統計ライブラリであるJMSLを使うとほとんど余分のコーディングなしにアプリケーションをMapReduce対応にできます。チュートリアル形式で使い方を学ぶこともできます。

ビッグデータに立ち向かう準備はできましたか?」こうした補助技術を使って新しい技術に触れてみてください。本当にそうした新しい技術が自分にとって必要なものかどうか、まずは試してみるのが一番です。

by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top

第四回:「ソフトウェア開発における攻めと守り」

新しいアプリケーションを作る時、攻めの姿勢と守りの姿勢、どちらが大切でしょうか。こういった形の二分法による質問は、多くの場合意図的に誤っていたり曖昧な前提を使って特定の結論に相手を導きたい場合に使われます。もちろん答えは、どちらも重要である、です。

ただし、開発の工程や局面によってどちらを重視するのかは変わることがあります。新しいソフトウェアを構想する時にはまず、それがどのような機能を持ちどのような目的に役に立つのか、を考えるものです。目的より先に侵入可能性などを考えていてはスタートラインに立つことができません。大まかな構想を決めたら目的を実現する最小限の機能を持つプロトタイプ(MVP)を作り、実際に自分で、または仲の良い人や最初の顧客候補に試してもらい、どんどんフィードバックを取り入れて改良していきます。開発の効率を上げるためにライブラリやOSSの利用を考えることもあるでしょう。自分のアプリケーションにとって本質的な新しい 機能を実現するために、すでに存在する先人の知恵を利用してさらなる高みへと進むのは賢明な判断です。これは攻めの姿勢です。

一方で、がむしゃらに先へ先へと進んでいくと、当然ながらあちこちに隙ができます。初期の限られた段階ではユーザーも環境も善意かつ親切であるため、セキュリティの心配など後回しになりますが、そろそろ落ち着いて置かれた状況を見直してみましょう。作成したソフトウェアのベータバージョンは幸い評判がよく来月にも一般公開の運びとなっています。販売代理店も多数の売上を見込んでいるようです。

しかし、ここで多くの不安が浮かび上がってきます。このアプリケーションはいくつかのファイルやコマンドの入力を受け入れるようになっているが、不正な動作を許すような入力へのチェックは本当にあらゆるケースを想定しているだろうか、充分注意はしたつもりだが? 初期段階でいくつか外部のOSSライブラリを組み込んだが、それらのうちどれかが最近脆弱性が話題になったあのOSSを使ったりはしていないだろうか?高速化のためにデータを分散処理しているが、データの種類によってハングしたりメモリリークを起こしたりはしないだろうか、あの急いで書いたコードは本当に意図通りに動いているだろうか?現時点でこういう状態なのに、この先バージョンアップは無事にし続けられるのだろうか?やや恣意的なシナリオですが、どんなソフトウェア開発もよほど小規模でないかぎりは必ず備えを必要とすることになります。

すぐれた開発補助ツールを使うと、攻めつつ守ることも可能になります。クロスプラットフォーム対応の大規模ライブラリは、強力で親切な機能をアプリケーションに提供しつつ、環境依存の問題やこみいったコードに潜む誤りの可能性を未然に防いでくれます。動的や静的のコード解析を開発初期から使っていくことにより、コードやデータの内容を理解して開発を加速させつつバグや脆弱性の問題を自動的に検出し、また見つけやすくしてくれます。人がOSSを使う理由は第一にイノベーションを開発に取り込むためですが、実績のある検証済みのOSSを使い、どこに何があるのかを常に把握していくことによってその効果を最大限に活かすことができます。

by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top

第五回:「Agileの次のステップかカルチャーショックか?」

Frog and Toad Are Friends(邦題: ふたりはともだち) は私の子どもたちが最も好きな本のひとつです。この中に、ガマくんのジャケットからボタンが取れてしまい、親友のカエルくんと一緒に探してなくしたボタンを見つけるというお話がありました。しかし、どうやら「世界はボタンでいっぱいだ、そしてどれも僕のじゃない」

私が考えたのはこれが開発者の状況に似ている、ということでした。世界はさまざまな技術的選択肢に満ちていてどれも魅力的に見え、でもぴったりなものは見つかりません。もしかしたらこれが私たちの受容と導入を遅らせるプロセスなのかもしれません。

私たちはテクノロジーのベンダーであり、お客様のニーズを見つけて解決するのが仕事です。多くのお客様にとってこれはソフトウェアの開発プロセスからレイテンシを取り除き、生産を加速するために可能な限り自動化を押し進める、とい うものです。価値を提供することに力点を置き、サイクルタイムの加速に対する障害を取り除くのです。

※この記事の続きは、ローグウェーブのBlog「継続的インテグレーション: Agileの次のステップかカルチャーショックか?」をご覧ください。

Written by ローグウェーブソフトウェア CMO Christine Bottagaro
Translated by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top

第六回:「自立と依存」

依存性切除 dependency elimination #23」 という興味深いコラムがあります。冗長性と依存性というテーマで、一般にコードのコピペは問題視されているが案外実害は少なく、逆にコードの共通化やライブラリへの依存に際してはいくつも弊害が考えられる、という趣旨です。これに続くエントリでも実行環境や開発環境などの「密封化」によって依存性の切除方法を具体的に検討しているので目を通すことをおすすめします。

さて、先日公開したBlog 記事では、ローグウェーブが提供する2つのライブラリを組み合わせることによって、いとも簡単にデータベース内解析が可能になる、というホワイトペーパー「チュートリアル: SourceProとJMSLを使ったデータベース内解析」をご紹介しました。この方法を使えば堅牢で包括的なC++ライブラリ群と様々な解析機能を持ったJavaライブラリ群に対して、わずかな glue コードを書くだけで手軽に解析が実現できてしまいます。それだけでなく、ライブラリ内でAPIの使い方は一貫しているため、簡単に同様の方法で他の解析アルゴリズムも試すことができます。プラットフォーム依存もなく、OS の更新に伴ってライブラリを入れ替えればコードを変える必要なくそのまま使えます。Java クラスのロード方法を変える他のデータベースを使う際にも簡単に切り替えることができます。要するに導入が容易でメンテナンスコストが掛からず、さらに特定の環境への依存性が最小限に抑えられるのです。今回はご紹介しませんでしたが、可視化ライブラリを組み合わせる場合も同様のメリットを享受できます。

その代償は何でしょうか。購入費やサポート費はもちろん無視できませんが、一般的に自前で用意すべき人員や開発工数を減らすことができるため、金銭的にはまかなえることが多いです。最大の問題は外部の企業への依存です。ベンダーロックインという言い方もされますが、もし将来提供側の何らかの都合で開発や提供を停止した場合、利用者は大きな影響を受けます。オープンソース製品なら問題はやや軽減されますが、コミュニティの主たる開発主体が撤退して引き継ぐ人員が現れない場合、現実的にはメンテナンスやましてや機能強化を継続していくことは難しいでしょう。

では自立を選び、全てを自分たちで開発するという選択肢を取るべきなのでしょうか?コストや時間はかかりますが組織外の要因によるリスクを抑えることはできます。社内に知識を蓄積していくことも期待できそうです。しかし、この場合も結局社内的なリスク、たとえば担当の開発者が部署を移ったり会社を去ったり、あるいは品質よりも納期を優先することにより長期的な再利用性が損なわれる、といったリスクは避けることができません。

他者を信頼することは一定の勇気を必要とします。信頼に値するかどうか、対話を開始して見極めるのも一つの策です。結局のところベンダーには少なくとも主体というものが存在するからです。

by ローグウェーブソフトウェア ジャパン Y.K.
Back to Top