Rakuten Tech Blog

こんにちは kawaguti です。
この記事は楽天エンジニアアドベントカレンダーの一つとして書いております。

プロダクトオーナー祭りというイベントで、「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というパネルディスカッションを行いました。

なんでこんなのを企画したかといいますと、スクラムにおけるプロダクトオーナーや、より一般的にプロダクトマネージャーにとって、昨今のDevOpsやリーンスタートアップが、そのやり方にどういう変化をもたらしたのか、というのを皆さんと一緒に確認したかったのと、その上で、そこそこの大きさの会社の中にいる人達が、どういう取り組みをしているのか、知りたかったからです。

「プロダクトマネージャーの役割は2009年を境に大きく変化しました。リーマンショックをきっかけにした、リーンスタートアップ、そして、DevOpsの登場です。スクラムの普及によって開発チームの様相も変わってきました。201x年代のプロダクトマネージメントは、それまでの上流工程重視から、より流動的でクロスファンクショナルなものに変化しています。ふりかえれば、2000年代の前半から、世界も製品も複雑になり、マネージメントスタイルそのものがより変化への適応を重視したものに変わってきています。統制と効率の時代から、多様性と適応の時代へ。そして、2017年。景気循環の陰が色濃く感じられるようになった昨今、次なる波を乗り越えるために、私たちは何を準備しておかなければならないのでしょうか。

川口 恭伸 / 楽天株式会社
黒田 樹 氏 / 株式会社リクルートテクノロジーズ
森實 繁樹 氏 / 株式会社野村総合研究所
武市 大志 氏 / 株式会社日本経済新聞社
樽本 徹也 氏 / 利用品質ラボ」


パネル自体はとても盛り上がりまして、一応ベストパネルディスカッション賞をいただきました。このブログではディスカッションの前提として用意した、DevOpsとリーンスタートアップについてのざっくり説明を共有したいと思います。

DevOpsって結局なんなの？

DevOpsは2009年のVelocityカンファレンスでFlickr(Yahoo!傘下の写真共有サービスのパイオニア)が提案した、"10 deploys per day" という発表が有名です。このスライドで取り上げられているプラクティスは以下の6つ。

1. インフラ自動化
2. バージョン管理の共有
3. ビルド＆デプロイ一発
4. フィーチャーフラグ
5. メトリクスの共有
6. チャットとロボット

文化面は以下の４つです。

1. 尊敬
2. 信頼
3. 失敗への健全な態度
4. 非難しない

これって、これまでアジャイルの方面で言われてきた達人プログラマーや継続的デリバリーのプラクティスや文化そのものだったりします。フィーチャーフラグやチャットOpsはこの頃から流行ってきてる感じですね。

当時、これ自体は全然新しくない感じがして、DevOpsってなんやねん、と思っていた自分がいます。このあたりは2015年に再発見しまして。これが出てきた背景を考えないといけないことに気づきました。

まず、2000年代前半にアジャイルが出てきまして。この時点では、小さなチームで、技術的な卓越性を高めながら、顧客に価値をしよう、なるべくムダなこと(契約交渉で押し付け合うとか完璧なドキュメントを求めるとか)をせずに、ということでした(アジャイルソフトウェア開発宣言)。この背景には90年代後半にパソコンが一般化して、多くのエンジニアが一人一台のパソコンと開発環境を手にしたとか、企業システムやWebシステムが出てきて、システム開発が一気に軽量化、多様化した .... というあたりがあるのかなと思います。

で、2000年代後半にクラウドです。パソコン/サーバのチップがIntelアーキテクチャに集約された結果、VMwareがヒットしまして、その他の仮想化ツールが色々出てきました。データセンター側で自動化やデータの集約を進めた機構を、Googleのエリック・シュミットさんが情報発電所だとかクラウドと表現し、AmazonのAWSと続いていきます。クラウドは従量課金を売りにしていて、自前でデータセンターを借りるより、極めて低いコストで、今すぐサーバーの利用を始められるようになりました。

アジャイルとクラウドが揃えば、すぐにサービスがリリースできるようになります。さらに Ruby on Railsを始めとしたフレームワークがサービス構築のスピードを後押ししていきます。リーマンショック後の2009年にはリーンスタートアップが流行し、数名のスタートアップ企業がすぐにアプリをデプロイし、仮説を検証しながら、収益を挙げられる環境を目指していく、ということが一般化しました。

こうなると、大企業が不利にたってきます。開発部門と運用部門をきっちりと分け、予算管理を徹底し、サーバーを立てる手順や本番サービスをリリースする前の承認、品質保証のための打鍵テストを徹底している企業にとって、スタートアップのように軽量にリリースすることはむしろ難しくなりました。「アジャイルとクラウドでサービス可能な分野」では、企業規模は問題ではなくなり、新規のサービスを軽量・高速に立ち上げられるスタートアップ企業が優位に立ってきます。

そして、DevOpsです。エンタープライズ(大企業)ゆえの問題をなんとかして、アジャイル＋クラウドの時代に適応しようというのが、DevOpsムーブメントの主戦場です(たぶん)。2009年のFlickrは元々スタートアップですが、この時点では、開発と運用が別れている程度には大きな会社でした。大規模で落ちないサービスをやるのは大変ですので、スタートアップでもサービスが大きくなってくると、サーバのオーケストレーションだったり、監視だったり、データの持ち方だったりが問題になり、そのあたりもスコープに含まれてくるのだろうと思います。

リーンスタートアップって結局なんなの？

リーンスタートアップもまた、アジャイルの流れをくむ動きなのですが、スタートアップならではの部分として、顧客がまだ確定していなくて、顧客の仮説、ソリューションの仮説を順に検証していく戦略が大事になります。単純に言えば、シード資金を使いきるまでに、ヒットサービスを出せるかどうかがスタートアップ企業の目標です。

アイデア一つに賭けて、大きな投資を呼び込んで、ガツーンとひと山当てる、というのがインターネットバブル以降のスタートアップのありがちな姿だったのですが、リーマンショック前後から、そういう投資も難しくなってきまして、500 Startups や Y Combinatorのような、起業家育成と少額の投資を組みあせたファンドが出てきて、ビジネスとしてもきちんと仮説の検証を繰り返したほうが成功の確率が上がる、というリーンスタートアップが主流になってきたように思います。

というあたりが、カンタンですがDevOpsとリーンスタートアップの私なりの説明でした。

より詳しいお話を黒田さんが書いてくれているので、ぜひ読んでみてください。

@i2key のBlog : プロダクト開発を内製化やアジャイル化する際のどこからはじめるかの勘所の話