BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル JavaからRubyへ:パイロット戦略

JavaからRubyへ:パイロット戦略

ブックマーク

多くの開発者はRuby on Railsが今最も重要なオープンソースプロジェクトのひとつだということを知っています。成長の原動力となっているその驚異的な生産性は、同じようなマーケットシェアをもつフレームワークで並ぶものはありません。他のフレームワークは目覚しい生産性を誇りますが、どのフレームワークも、その技術的なイノベーションとマーケットシェアの見事な連携にはかないません。Railsコミュニティは現在、多数のプラグインを提供し(Gemsと呼ばれます)、書籍を刊行し(2006年だけで10冊以上)、トレーニングや大きなカンファレンスを実施し、オンラインリソースの見事な一覧を作成しています。Railsが波紋を広げるにつれて、もっとも保守的な企業さえもRubyの導入を検討し始めることでしょう。

今のところ、Rubyの広がりは開発者主導の革命です。マネジメント層を納得させるには、それとは違った理由付けが必要です。マネージャはRuby導入のリスクやJavaのようなメインストリーム言語をたとえひとつのプロジェクトだろうと冷遇するリスク、そしてRubyがもつ機能の技術的な全体像を理解しなければなりません。正直に言うと、この記事ではこれらの領域については十分に言及しきれません。この一連の記事は『JavaからRubyへ(サイト・英語)』をベースに、パイロットプロジェクト、リスクの理解、JavaとRubyの統合戦略という三つの角度から、保守的な顧客へのRubyの導入について探求していきます。

パイロットアプローチ

Rubyはすばらしい言語です。もしあなたが保守的な企業にRubyを定着させたいのなら、Rubyを使うのに適した状況で適切な問題を解決するようなパイロットプロジェクトをRubyで実装しましょう。そうすれば、Ruby自身が自らの魅力を証明してくれます。ですが、パイロットプロジェクトを立ち上げるために、まずリスクをとるに足るだけの魅力をRubyがもつような状況を組み立てなくてはなりません。そして、パイロット戦略にいくつかの構造を追加しなければなりません。新しい言語の導入は常に抵抗を呼び起こしますので、疑う余地のないアプローチを採り、最終的には、成功するために政治的な基盤を構築したいところです。

まずは、見返りをはっきりさせ、新しい言語の導入リスクを乗り越えるのに十分な説得力を身につけるべきです。Rubyについて、そういう状況を構築するのは皆さんが考えているよりも簡単です。

説得力のある見返りを見つける

何と言っても、アドバンテージの中核はおそらく短期および長期の生産性を中心に考えることになるでしょう。短期的な生産性は迅速なアプリケーション開発がテーマになります。長期的な生産性にはアプリケーションの保守や単純化が全面的に含まれます。ほとんどのスクリプト言語と同じようにRubyは短期的な生産性の向上に適していますが、一般的なスクリプト言語とは異なり、Rubyは保守のしやすさや単純化、拡張性など長期的な問題においても優れているということが早期に示されています。

Rubyとその主力アプリケーションであるRailsは、ある種のアプリケーションでしばしば3倍~5倍に達する劇的な生産性の向上を実現します。生産性がアップすれば、チームのサイズを小さくしてコミュニケーションコストを削減し、オーバーヘッドを取り除くことができます。小さなチームはアジャイル開発プロセスの効果も高めます。これらの向上がもたらす相乗的なインパクトは、低く評価されがちです。

開発者は動的型付けやメタプログラミングやDSL、そしてクロージャや継続のような豊かな抽象概念のもつインパクトを理解しています。Ruby on Railsフレームワークは、Javaのフレームワークがまだもっていない更に画期的な機能をもっています。高速なフィードバックサイクル、組込のテスティングフレームワーク、「設定より規約」というコンセプト、画期的な永続化フレームワークなど。これらの機能はJavaの開発者たちを惹きつけました。しかし、あなたが上司と話をしているときにその一連の機能について流暢に弁舌をふるっても、それが上司の胸に突き刺さることを期待するのは無理でしょう。あなたは、それらの機能を生産性の観点から説明しなくてはなりません。

また、長期的なメリットも存在します。設定量の削減、目を見張るような単純さ、少ないコード量、そしてDSL。これらは通常Railsアプリケーションをより一層読みやすくしてくれます。組込みのテスティングフレームワークはユニットテスト、ファンクショナルテスト、インテグレーションテストを単純化します。Rubyのもつ動的な性質はRailsの拡張を簡単にしてくれます。総合すると、これらの属性は全て、長期的な保守と拡張を簡単にするのに役立ちます。

現実の抵抗

一般的にマネージャは新しいテクノロジーを大きくて派手なリスクのサインと見ます。それはもっともなことです。新しいテクノロジーは本質的にリスキーで、新しいプログラミング言語は全く新しい段階のリスクをもたらします。なぜなら、その決定はアプリケーションが存続する限りずっと続くからです。以下の厄介なリスクには説得力があります。

  • 間違った問題を選択する可能性がある。
  • その言語の開発が停滞し、サポートや将来の機能強化が制限される可能性がある。
  • その言語が技術的に要求の実現に失敗する可能性がある。
  • その言語がいまだ明らかでない長期的な問題をもたらす可能性がある。
  • 新しい技術を理解しそこなう可能性がある。

最終的にJavaからRubyへ切り替えることになるときには、技術的な議論を越えて、新しい言語の導入が本質的にもつリスクを上回る十分なビジネス価値をRubyが提供できるということを、技術面の意思決定者に納得させなくてはなりません。リスクがかすんで見えてしまうような潜在的な見返りが必要です。そしてパイロットはその利益を疑う余地なく証明しなくてはなりません。

パイロット戦略

『JavaからRubyへ』の執筆にあたって、私は、Rubyで製品アプリケーションを開発した、もしくは開発している多数の開発者にインタビューし、あらゆるタイプの企業にRubyを定着させるのに効果のあるパイロット戦略を探しました。パイロットの目標は通常二つの要素から成ります。

  • 技術的リスクの軸。高い技術的リスクを伴う問題は、調査中の技術についてより多くのことを教えてくれる。
  •  政治的リスクの軸。技術を導入できるよう、懐疑派の人たちにその技術が成功するのを見てもらいたい。

 これらの目標はしばしば対立します。売り込みには通常技術的リスクが少ないことが要求されますが、高い政治的リスクが目立ちます。学習には若干高い技術的リスクが求められます。TODOリストやブログ程度のものを新たに作ったところで何かを学習するのは無理です。そして高い技術的リスクは通常政治的リスクの低い状況で見られます。

成功するパイロット計画の立案の最初のステップは、これらの目標のバランスがとれていて、手元にあるリソースを有効利用できる効果的な戦略を立てることです。以下の戦略は書籍から直接抜き出してきたものです。どちらも、実用的な製品アプリケーションの提供にそのテクニックを活用したRuby開発者から学んだものです。

トロイの木馬

多くの技術者はRubyを使ってすごいアプリケーションを作ってやろうと試みますが、政治的でリスクを嫌う信条にぶつかってフラストレーションを募らせる一方です。そして何回か挫折した後、彼らはそんなことを考えるのをやめます。「トロイの木馬」は新しい技術に進むのが非常に遅い企業でとても役に立つ傾向があります。この戦略では、レーダーの下を感知されないよう潜り抜けてシステムにRubyを導入することに取り組みます。一般的な考え方は次のとおりです。

  • 無難な技術的課題を探す。
  • その問題をRubyを使ってマネジメント層にはなるべく知られないようにこっそり解決する。
  • 文化を育成してRubyのエバンジェリストを形成するため、草の根の活動を立ち上げる。

 「トロイの木馬」は低い技術的リスクと政治的リスクをもっています。目標はシンプルな課題の早期解決を達成すること、組織内部での実践を通じて技術の支持者を増やすこと、技術・政治両面で影響力を増すことです。

Amazon.comは「トロイの木馬」テクニックを使ってRubyが定着しつつある企業のよい例です。以前Amazon.comに勤めていて今はGoogleで働いているSteve Yeggeは、数年前にRubyを使い始めたプログラミング言語オタクです。彼は、他の人たちと共に、Rubyが開発者にとって有効であることを確認しました。Amazon.comではRubyはただのスクリプト言語としてしか使われていませんでしたが、Dave Thomas(最も有名なRuby本の著者兼発行者)やDavid Heinemeier Hannson(Railsの作者)などRubyのビジョナリーたちがAmazon.comで講演を行い、現在ではコミュニティは成長し、幅広くRubyが利用されています。

.私は以前、「トロイの木馬」シナリオを実行する絶好のチャンスが訪れている企業にいました。Javaのプロジェクトに取り組んでいるヨーロッパのコンサルタント会社で、アプリケーションの管理画面を構築する前に予算を使い果たしてしまったため、管理画面を開発する代わりに顧客が直接SQLを発行してデータベースを管理しており、データの整合性を失う無視できないリスクがありました。私たちは、管理画面をJavaで構築するのは大変だけれども、Ruby on Railsを使って構築するのは大したことではないだろうと判断しましたが、この顧客がRailsの導入に前向きかどうかはわかりませんでした。

抵抗

「トロイの木馬」シナリオの目標は、気付かれないようにプロジェクトを進めることによって反発をなくしてしまうことです。もし抵抗にぶつかったら、 Perl、HTML、SQL、XMLと同じ気分でRubyをユーティリティ的なスクリプト言語ということにしてしまいましょう。

何と言っても、「トロイの木馬」は純粋な草の根活動です。その草を育てるための肥沃な土壌を忍耐強く作り上げてください。成功をこつこつと積み重ねることで企業内におけるRubyプロジェクトあるいはRubyの役割が育っていくことに賭けるのです。正式な承認プロセスを通さないという選択をするか、もしくは重要性の低い問題に対処することになるでしょう。

競争

私が出会った中で断然興味深いのが「競争」シナリオです。その前提は次のようなものです。

  • すでにJavaを使って解決に向けて取り組み中である要求の厳しい問題を選ぶ。
  • 平行してRubyのプロジェクトを立ち上げるのに臨時予算を注ぎ込む。
  • Javaプロジェクトに従事している開発者の20%~33%程度の人数のチームを作る。
  • 一定期間後、もっとも進捗の進んでいる方のプロジェクトを選ぶ。

このシナリオでは、Rubyプロジェクトの技術的リスクは高いですが、Javaプロジェクトを平行して走らせることでそのリスクが減ることを期待します。「競争」シナリオはRubyの生産性を強く前面に打ち出します。デメリットは失敗時のコストです。失敗すると、しばらくの間ふたつの開発努力に対して資金を供給する羽目になります。ですがもし成功すれば、長い目で見ると費やす資金はずっと少なくなるでしょう。実際には、ハイリスク・ハイリターンのRuby プロジェクトが中心になり、平行して走るJavaプロジェクトは高価な保険となります。「競争」シナリオの導入方法は次のように調整されるようです。

  • あるコンサルタント会社はJavaのプロジェクトと平行してRubyのプロジェクトを立ち上げ、その開発に対しては自分たち自身で資金を注ぎ込みました。彼らはRubyを戦略的に見ており、Ruby on Railsが利用可能な選択肢であるということを、「競争」シナリオを通じて顧客に納得させることを期待していました。
  • ある開発者は一日をRubyでの開発に、四日をJavaでの開発に費やすという提案をしました。マネージャは一ヶ月ほどの後、ベストなソリューションを選択しました。
  • あるコンサルタント会社はRubyソリューションの効果をデモンストレートするためにJavaとRubyの両方でプロトタイプを構築しました。

 この戦略には少しいやらしい面がありますが、興味は持ちながらも二の足を踏んでいるマネージャを説得するのには非常に有効です。「競争」シナリオは、他に類を見ないRubyの爆発的な生産性をはっきりと示します。私が出会った四つの「競争」シナリオのうち、二つは成功を収め、三つ目はまだ進行中です。そして四つ目のプロジェクトは予算を残しながらスケジュールを前倒しにして進んでいましたが、財源を失ってしまいました。

『競争」シナリオは実は皆さんが考えているほど過激ではありません。特に、Rubyが場合によっては数倍の生産性を発揮するということをマネジメントチームが知っているケースではそうです。たとえコストは高くても、このシナリオはもっともリスクの小さいRuby導入シナリオです。ただし、注意してほしい点があります。マイナス面のひとつは、パイロットが進行中で、しかも成功したあとであっても、Javaは依然として選択肢であり続けるということです。技術的に成功を収めることができても、政治的には自分の求める状況を作り出すことに失敗してしまうかもしれません。私がインタビューしたある顧客は、Ruby のパイロットをJavaの場合の1/4のコストで成功裡に完了させましたが、その顧客は「プロトタイプ」が大好きで、結局それをJavaで完成させることを要請してきました。

抵抗

「競争」シナリオでは最大級の大きな抵抗がコストになります。この抵抗に対する反応は、感情的にならず、理にかなっていなくてはなりません。もし成功したら、全体的なコストはJavaのプロジェクトを完成させたときよりもずっと少なくなるかもしれません。よくあるRailsアプリケーションなど、Ruby が4倍の生産力をもつプロジェクトについて考えてみましょう。プロジェクトが半分過ぎた時点でマネジメント層がRailsを採用し、Javaのほうを廃棄すると決定すれば、トータルコストはJavaプロジェクトをスクラッチで構築する場合のわずか75%になります。もしプロジェクトが25%完了した時点で決断したなら、プロジェクト全体でかかるコストは、全てをJavaで作業した場合のたった50%です。なんと、損得の分岐点はプロジェクトの75%完了時点なのです。

ここでお見せした二つのパイロットプロジェクトは、私がこれまでに見たアプローチのうちの二つに過ぎません。他にもたくさんのアプローチが考えられます。

  • 標準的なパイロットを実装し、売り込みよりも学習を重視する。
  • Rubyによる小さなチームを作ってJavaプロジェクトを救出する。
  • プロジェクトに注ぎ込む労力を減らし、トータルでより少ない労力で成功を収めることに賭ける。例えば、私は通常より労力を30%削減したプロジェクトを首尾よく提案した。
  • DSLやAjax統合といったフレームワークの主要機能を見せる。

もちろん、他にも効果的なテクニックが存在します。強力なRuby支持者がいる一部の企業では、Rubyは比較的簡単に売り込めるでしょう。そういったケースではパイロットの役割は変わります。売り込みよりも学習を重視したくなるでしょう。そして、どのケースでも、順調な進行を保つためには常に作業を続けなければなりません。

成功を利用する

うまくいっているパイロットを計画進行のために活用する絶対的な鍵となるのはデータです。成功したパイロットについて説明した公正で正確な評価指標を集めます。一般的には生産性を強調したいですが、反発を受けそうな主な領域については実際的なデータを示したいところです。

  • パフォーマンスデータ。よくあるRubyへの批判はスケーラビリティの欠如だが、この批判は大抵リアリティに欠ける。
  • 開発者数の増加。ほとんどのマネージャは、プーリングされているアベイラブルな人材に基づいてJava開発者数のほうがRubyよりも調達しやすいと考えている。実際にはRails開発者の増加は非常に速い。
  • チームの大きさ。この議論は大抵の場合非常に説得力がある。少ない人員でより多くのことができるのだから。
  • コードの行数。コードの総行数をカウントする。ただし、設定ファイルの行数を忘れないように。

この追加作業には多くの時間はとりませんが、パイロットの成功を活用するのを一層簡単にしてくれるでしょう。鍵は、技術的な目標と政治的な目標のバランスをとることです。Javaが使われている環境でRubyの定着に取り組んでいる場合、劇的な改善を示す必要があるだろうということを覚えておいてください。政治的な環境では何が役に立つのか、チームはどの程度の技術力を実現できるのか、決定しなくてはなりません。もしJavaに反対してRubyを効果的に売り込みたいのであれば、Rubyに適した環境で、適切な問題をRubyのパイロットを使って解決し、言語自身に自分がもつ魅力を語らせてください。

著者紹介

Bruce TateはRapidRed, LLC(サイト・英語)の創設者。テキサス州オースティン在住で、カヤック乗り・マウンテンバイク乗り・父親・書籍の執筆者・Javaプログラマ。「Better, Faster, Lighter Java」とベストセラーの「Bitter Java」など5冊の著書がある。17年におよぶ経験にはIBMでの勤務、二度の失敗した新規事業、J2Life, LLCという自分自身の独立したコンサルティング事務などがある。

原文はこちらです:http://www.infoq.com/articles/From-Java-to-Ruby--Strategies

(このArticleは2006年7月27日にリリースされました)

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT