ヤフーも取り組む「リーン」とDevOps、実践に欠かせないものとは：「Innovate2013 – The IBM Technical Summit」リポート

インターネット企業といえども大組織となったヤフー。同社も「リーン・スタートアップ」を実践している。そしてリーン・スタートアップの実践には、DevOpsに取り組まなければならない。日本IBMが｣10月29日に東京都内で開催した「Innovate2013 – The IBM Technical Summit」は、これに向けたヒントが満載だった。同イベントのレポートをお届けする。

「爆速」というマントラ、「リーン」という考え方

　「『爆速』という言葉は、ヤフーにとって『マントラ』とも呼べる存在になっている」。同社CMO （Chief Mobile Officer）室の河合太郎氏は、日本IBMが｣10月29日に東京都内で開催した「Innovate2013 – The IBM Technical Summit」の基調講演で、こう話した。これを実現するための具体的な取り組みの1つに、「リーン・スタートアップ」があるという。

ヤフー CMO室の河合太郎氏

　エリック・リース（Eric Ries）氏がトヨタの傾斜生産方式をもとに、自身の経験を踏まえて考案したリーン・スタートアップ。これは、「完成」した製品を世に送り出して勝負する代わりに、最小限の機能を実装した製品を早く提供し、ユーザーからの反応に基づいて改善を繰り返すプロセスを高速に回すことが、より確実で無駄の少ない成功につながるという考え方だ。

　「スタートアップ」という単語を含んでいるために、これは新興ベンチャー企業のための言葉であるかのように思われがちだ。だが河合氏は、ヤフーのような大組織こそ、変化の激しい業界で生き残っていくために取り組むべきだと考えているといい、「僕の来た道」というスマートフォンアプリの開発を実例として紹介した。

　河合氏は、「リーン」を目指すために、プロセスの可視化に努めながら人と人とのコミュニケーションを良くすること、そして実例をもとに、社内でこの動きを広げていくことが重要だという。ヤフーは社長のリーダーシップ、そして現場の理解と実践の両輪で、「爆速」を推進しようとしていると話した。

「リーン」はあらゆる企業における開発の新しい姿

　米IBMのラショナル・ソフトウェアでチーフ・ソフトウェア・エコノミストを務めるウォーカー・ロイス（Walker Royce）氏は、リーンへの取り組みとは、ヤフーのようなネット関連企業だけでなく、ソフトウェアを事業において活用するすべての企業にとって避けて通れないテーマだと話した。ソフトウェアがますますビジネスを左右するようになるため、リスクの低減が至上命題になる一方、クラウド、モバイル、ソーシャル、ビッグデータといった潮流が、変化と不確実性を増大していくからだという。そして、「DevOps」は、この難題をどのように解決するかという問いに答える手法、プロセス、企業文化の総称だという。

米IBM ラショナル・ソフトウェア チーフ・ソフトウェア・エコノミスト ウォーカー・ロイス氏

　ロイス氏は架空の例でこれを説明した。従来型の考え方に基づく、あるプロジェクト・マネージャは、12カ月後の結果を求めるマネジメントに対し、11カ月で開発を終了し、12カ月後までにリリースする計画を立てた。開発チームは容易な部分から取り組み、計画通りにプロジェクトが進行しているように見えた。後期は困難な部分で手間取りながらも、なんとか予定通りに統合テストにこぎつけたところ、これまで表面化しなかった大きな問題が発覚し、プロジェクトは大幅に遅れることになった。

　一方、リーンな考え方を持つ別のプロジェクト・マネージャは、同じ目標に対し、困難だが製品の中核部分から開発を進めることにした。そして中核部分の開発が進むと、早期にこれを段階的にリリースし、ユーザーからのフィードバックをもとに開発者による実現可能性を計測、これを繰り返す形をとった。こうした形でリスクとぶれを減らし、12カ月後には目標を達成できた。

　ロイス氏は、従来のやり方は、不確実性が増す状況に対して断定的な予測を当てはめようとするもので、これでは立ちいかなくなってきているという。対して、新しいリーンなやり方では、刻々変化する状況に対して結果への予測を動的に変えていくことで、確実性を高めることができるとする。

　事業活動をリーンなものにしていくには、製品提供に至るあらゆる段階において、上記のような考え方を取り入れ、多様な無駄や負荷を低減し、一方で生産性を高める取り組みをすべきだ、これが「DevOps」の意味だと話した。

　「現在多くの組織に見られるプロセスは、エラーやこれによる手戻りが発生しやすい。負荷やコミュニケーション・エラー、透明性の不足が過大なリソース要求につながり、摩擦を増大し、活動のスピードを低下させてしまう」（ロイス氏）。DevOpsでは、プラットフォームを活用することで、手戻りや重複、摩擦を回避し、関係者がより創造的で価値を生む作業に専念できるようになって生産性が上がるという。

DevOpsは事業目標に向け、あらゆる部門をまとめ上げる

　日本IBMの理事で、ソフトウェア事業 ラショナル事業部 事業部長である渡辺公成氏は、開発と運用をつなぐDevOpsという言葉の本質をとらえ、同社では「市場機会をとらえる時間と、顧客フィードバックを得る時間を短縮することを可能にするための、継続的なソフトウェアデリバリを実現する企業規模の能力」と定義している、と説明した。

日本IBM 理事 ソフトウェア事業 ラショナル事業部 事業部長 渡辺公成氏

　そして、これを実現するためのカギは、ツール、プロセス、組織文化の3点だと話した。

　ツール面では、2013年4月のUrbanCode買収により、「単なる継続的インテグレーションや継続的デリバリではなく、開発、テスト、モニタリングといったDevOpsの要件すべてを網羅する、IBMのDevOpsライフサイクル管理プラットフォームを届ける準備が整った」（渡辺氏）。同社はUrbanCode買収以前にも、モバイル開発のWorklight、テスト仮想化のGreen Hut、ユーザー体験情報分析ツールのTealeaf、Web分析・WebマーケティングツールのCoremetricsなどの製品群を次々に買収、これを開発プラットフォームに統合することで、開発者のためのプラットフォームを、ソフトウェア提供に関わるすべての人々のための統合プラットフォームへと進化させている。

　プロセスでは、「Rational Unified Process（RUP）」に体現された10年前のビジョンを、「Disciplined Agile Delivery（DAD）」に進化させた。DADでは、開発と運用をつなぐためのプラクティスも提供しているという。

　文化については、例えばUrbanCodeが、開発と運用という利害の異なるチームを1つにするためのプラットフォームやノウハウを影響している。構成・変更管理、テスト、リリースといった、ソフトウェアデリバリのライフサイクル全体を自動化することが重要と、渡辺氏は話した。

UrbanCodeは開発と運用が共通の言葉を持つための場

　UrbanCodeは、「リリース／デプロイ自動化ツール」と表現されるが、同製品の機能は狭義の自動化にとどまらないと、UrbanCodeの共同創立者で、デプロイ／リリース製品ラインのディレクターを務めるマチェイ・ザワツキー（Maciej Zawadzki）氏は強調した。

米IBM デプロイ／リリース製品ライン ディレクター マチェイ・ザワツキー氏

　「UrbanCodeは、リリース／デプロイ自動化ツールというより、リリースプランニングとコーディネーションのためのツールだ」（ザワツキー氏）。

　UrbanCodeでは、たしかにデプロイ作業の自動化で強力な機能を備えている。スクリプティングツールなど、数多くの外部ソフトウェアと連携して、デプロイの作業を自動実行。手作業のデプロイに起こりがちなエラーを回避できる。

　だが、インベントリ機能や構成管理機能も見逃せない。「インベントリ機能では、どの環境にどのソフトウェアのどのバージョンがデプロイされているか、またはされるべきかを管理できる。このため、あるソフトウェアのごく一部のファイルだけが更新された場合、この差分だけをデプロイできる。また、構成管理では、アプリケーションのリッスンポート、ヒープサイズ、データベースのURLや認証情報といった構成情報を外部化し、デプロイプロセスと切り離せる。このため、1つのデプロイプロセスを再利用し、さまざまな環境に適用できる」（ザワツキー氏）。

　一方、リリース管理も大きな特徴となっている、統合テストからデプロイに至る、個々のリリースの進捗（ステータス）を可視化し、追跡できる。予定より遅れているか、進んでいるのか。どこで止まっているのか。テストが完了するまではデプロイに移行できないように、統制をかけることも可能だ。コードのステータスからデプロイのスクリプトまでを、開発側と運用側の双方が同じように確認できる。ここに、利害を異にする二者の間の共通の土台が生まれる。

　ザワツキー氏は、UrbanCodeでビジネスが大きく変わった実例を2つ挙げた。

　ある国際的な投資会社は、自社にとって最も戦略的なソフトウェアであるトレーディング・プラットフォームのデプロイ／リリース管理に、UrbanCodeを導入した。それまではせっかく開発を高速化しているのに、手作業によるデプロイが足を引っ張り、フィードバックループを速く回せる状態ではなかった。UrbanCode導入後、リリースの所要時間は2〜3日から1〜2時間へと大幅に短縮できた。

　もう1つの例は通貨取引関連企業。市場は平日24時間、世界のどこかで開いているため、週末にデプロイしなければならない。このため、リリース後の月曜日には、担当者が全員、バグなどの不具合発生に備え、待機していなければならなかった。しかし、UrbanCode導入後は、この月曜日の負荷が大きく減少できた。なぜなら、テストで成功したのとまったく同一のデプロイプロセスを、異なる環境に対応した構成情報と組み合わせることで、完全に自動的に実行できるようになったからだ。

　では、デプロイ／リリースのプロセスを改善したい企業は、まずどこから手を付けるべきか。ザワツキー氏は、「これまで開発からスタートしてテスト、本番デプロイの自動化を順次進める例が多かった。しかし最近では、本番デプロイ、運用サイドから進めるほうが成功しやすいことが分かってきている」と話した。

これからの開発ニーズに応えるため、何ができるか

　米IBM ラショナル・ソフトウェアCTO兼フェローのケビン・ストゥッドリー（Kevin Stoodley）は、UrbanCodeのような製品が目指すDevOpsの動きについて同社自体も学び、実践してきたと話した。

米IBM ラショナル・ソフトウェアCTO兼フェロー ケビン・ストゥッドリー氏

　「DevOpsについて学ぶほど、この考え方には大きな価値があることが分かってきた。ツールを採用するだけの話でなく、組織全体が評価し、実践し、継続的な向上を図っていく必要のある活動だ」（ストゥッドリー氏）。また、強力な統合的プラットフォームによって、コードのトレーサビリティを確保することで無駄を大幅に減らせることも分かったという。

　IBMのある製品のリリース間隔は、以前は年1度だったが、現在では3カ月に1回。これを毎週にまで短縮することが目標だという。同製品で毎週のリリースが必要かどうかは別として、必要とあらばこうした速さで投入できる体制づくりが重要だと考えているという。

　ラショナル・ソフトウェアでは、今後クラウドが開発ツールにもたらす影響を考慮し、複数の取り組みを進めている。

　1つは「JazzHub」。Rational Team Concert（RTC）のホスティング版で、プランニングからソース管理、変更管理までをクラウド上で提供。柔軟な共同作業を実現するプロジェクトだ。現在のところ、無料で試すことができる。もう1つは、JazzHubにPaaS製品のCloud Foundryを組み合わせた「Blue Mix」。クラウド上でのデプロイするアプリケーションのための開発作業の場を、クラウド上に持てる。こちらはアーリーアクセス・プログラムを提供中という。

　こうした活動を通じて、顧客の課題についてさらに深く理解できるようになったと、ストゥッドリー氏は話した。クラウドがいくら存在感を増すといっても、将来すべてのコードがクラウドで開発され、運用されるようになるわけではない。ユーザー組織の内部でクラウドのような開発・運用体制を築くことの重要性も減るわけではなく、IBMはこのためのツールとプロセスも提供できると話した。

提供：日本アイ・ビー・エム株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2013年12月18日