teratail Report vol.3

2017/09/26

「解決してあげることが改善ではない」20年のWeb開発から生まれた、楽天式"カイゼン"とは。

「解決してあげることが改善ではない」20年のWeb開発から生まれた、楽天式"カイゼン"とは。

こんにちは。teratail Report編集部です。

“teratail Report”は、エンジニアの中に隠れている「貴重な情報」を日本中のエンジニアに届けていくメディアです。技術の最前線を走るエンジニアたちの「考え方・捉え方・経験や思想」にはWebにはなかなか出てこない「有益な情報」が隠れているはずです。teratailは実際にエンジニアに会ってその根幹を探り、発信していきます。

第3弾となる今回は、楽天のエンジニア組織へのインタビューです。20年近く続く国内トップクラスの長寿サービス「楽天市場」を運営する傍ら、時代に合わせて次々と新規サービスをリリースし、現在では約70のサービスを運営しているという同社。果たして20年もの間Webサービスを運営すると、どのようなことが起こり、どのように対応がなされているのか?また、他に類を見ない多数のサービスの同時運営をしつつ、長寿サービスから立ち上げ数ヶ月の新規サービスの開発までを両立させていく秘訣は一体何なのか?先日楽天本社で開催された「楽天の精鋭部署 ECインキュベーション開発部が語る 開発の最前線」というイベントでの講演内容をベースに、今回のインタビューで楽天の開発チームの裏側を徹底解剖していきます!

椎葉 光行 氏

しいば みつゆき椎葉 光行

楽天株式会社 ECスタートアップ開発課 改善グループ

担当:ウェブアプリケーションエンジニア

今までやってきたこと:2010年に楽天に転職。いくつかの新規サービス立ち上げにエンジニアとして携わる。その中で、スクラムやDDDなどを導入し、より良いサービスづくりに取り組んでいる。2016年には改善グループを立ち上げ、色々なチームに入って内側からサポートしている。

國本 隆志 氏

くにもと たかし國本 隆志

楽天株式会社 エマージングECサービス開発課

担当:シニアマネージャ

今までやってきたこと:中小SIでエンジニアとして経験を積んだ後に2009年に楽天に転職。その後プロデューサ兼PHPエンジニアとして楽天B2B、楽天中古買取、楽天仕事紹介など複数のECサービスを立ち上げて保守・運用を経験。現在はシニアマネージャとして、エンジニアのバックグラウンドを生かしたエンジニア目線での組織マネジメントに従事。

若山 光太 氏

わかやま こうた若山 光太

楽天株式会社 ソーシャルツールプラットフォーム課
ユーザインタレスト開発グループ

担当:ウェブアプリケーションエンジニア (エンジニアリーダ)

今までやってきたこと: 2011年に楽天に新卒として入社。Review、Bookmarkといったユーザに近いサービスの開発に従事した後、現在はノティフィケーションサービスにてエンジニアリーダを担当。現場の最前線で開発、プロジェクトマネジメント、チームマネジメントに取り組んでいる。

ECインキュベーション開発部とは・・・

楽天では楽天市場を中心として様々なサービスを展開している。ECインキュベーション開発部では、ECに関わる大小様々なサービスや、楽天市場で使用されているプラットフォームを開発・運用している。小さく立ち上げたサービスを育てて大きくしていくために、そして、大きく育ったサービスを安定して運用していくために、エンジニアとして常に新しいことに挑戦していく姿勢が求められる。

イベントでは、楽天の精鋭集団ECインキュベーション開発部より、サービスの説明や開発体制のお話がありました。
その中で登場した「改善グループ」や「20年続くサービス」といった気になるトピックを深掘すべく、突撃インタビューを行ってきました!

「直接答えを渡さない!」グループ全体を横断する改善グループの取り組みとは

まず深堀していくのは、「改善グループ」という開発部隊の全体を横断し改善していくグループについて。チームやサービスの枠を超えて改善を行っていく取り組みの背景や運用を、早速解剖していきたいと思います。

改善グループ:ECインキュベーション開発部において、横串でサービスやシステム改善を行うチーム

── よろしくお願いします。まずはイベントでもお話のあった「改善グループ」発足の背景について聞かせてください。

椎葉光行氏(以下、椎葉)最初は僕が「開発チームを外から改善してみよう」と思ったところから始まりました。サービス開発は、サービスにとって良いことを、ものすごいスピードでやってかないといけないですよね。開発チームの中にいてサービスと向き合っていると、ちょっとした改善に時間をあてるのが難しくなってくるので、客観的な立場から改善したいと思ったんです。

そこから、「他のグループも興味あると思うからやってみて」と言われ部署全体を見るようになりました。チームを超えてエンジニア同士が同じ目線で相談できたらいいよな、他はどうやってるんだろうっと思い始めて、その頃からミドルからリーダクラスの人たちと話すようになりました。

── たしかに、サービスを開発している間って目の前のリリースや運用に追われていて、必要だとは思ってもなかなか手をつけられない部分って多いですよね。
チームごとに蓄積していくナレッジも、全体ではあまり共有できていないことが多い気がします。
チームを横断というと、一度に複数チームを担当しているということでしょうか?

椎葉いえ、がっつりチームの中に入ってやりたいので同時に進めるチームは1つか2つです。エンジニアの横に座って、実際に手を動かしてサポートしたくて。聞かれたことだけ答えて居なくなる、ではなく「自分が居なくなったあともチームが良くなっていける状態」になるようにサポートしたいんです。

── 「チームをより良い方向に導く」ということですね。チームが持っている力をより上げていくにはチームの根幹部分の改善が必要だと思うんですが、どうやって外から改善点を見つけているのですか?

椎葉トップダウンの場合もボトムアップの場合も両方あります。(ECインキュベーション開発部のリーダーの)國本からはトップダウンの形でサポートを入れるべきところを指摘され、僕からはそれとは別に技術的な解決を示してあげたいなあと。上からと下からで痒いところに手が届く活動にしたいなと思っています。

國本隆志氏(以下、國本)今では僕は上から見て「ここのグループのここにテコ入れする」と決めて椎葉を派遣していますが、発足当初は探り探りだったので「困っていることないですか」と聞いて回っていました。例えば「スクラムを導入してみたいけど始め方がわからない」という話がでてきて、そういうことに悩んでいるんだなと。でも、改善に行ってはみたけど「僕たち自分で頑張りたいので今は助けいらないです!」って言われたこともあります(笑)

── 現場の声を丁寧に汲みあげることで進化してきたんですね。改善点の優先順位はどのように決めるんですか?

椎葉体制を整えてあげるだけでほとんどの点が改善することが多いので、あまり優先順位をつけることはないです。そもそもプロジェクトに参加するのではなくチームの力を上げに行く、という活動なので、「全てを解決してあげる」のではなく「解決する力をつけるサポート」をしているイメージです。実際には開発チームは全力のスピードで動いているので「一旦立ち止まってここ見直してみよう」と立ち止まらせて、自動化しようとか、このスキル習得しようとか、長い目でみてスピードが上がる方法を提示してます。

── なるほど。チームを育てるために、あえてあまり介入しすぎないんですね。サポートのバランスがすごく難しそうですが、どんなことに気をつけていますか?

椎葉「直接答えを渡さない」ということですね。僕がすぐ解決できることでも、チームがいま出せる力で一緒にやります。チームみんなが成長したら僕一人がやるより何倍も強くなるのでこれは絶対です。

國本「完成したソリューション」で渡すのではなく「方法」を教えてあげるっていうところだよね。

椎葉そうですね。例えば「理想的なスクラムのやり方」ってモデルはあるんですけど、チームの性格とか問題とかスキルを見てチームに合った方法を伝えます。

── 方法を教えるにしても、チームが既に走り出しているときの軌道修正はなかなか大変ではないですか?

椎葉まず間違ったことに早く気づける仕組みをつくることがポイントです。3日とか、短いスパンで失敗できるようにする。チームで決めてみて「違うよね、じゃあどうする?」という形で次第に進めていきます。

國本チームのメンバー自身も「間違っているかも」と感じている人はいるんだけど、意思決定の方法がわからず流れでやってしまうことも多い。そこに改善グループが入って意思を引き出してあげるようにしています。「これを選んだのはなんで?」と。

── チームを尊重して改善を進めているんですね。改善グループの目標はどうやって決めているんですか?

椎葉僕が抜けて1年後に開発速度や品質が上がっていることだと思ってます。チーム全体としてリリースが増えて、トラブルが減って、エンジニアが働きやすくなったと感じることを目標にしています。とにかく「長い目で見て改善したほうがいい」ことをしっかり伝えていきたいですね。

長く続くサービスの運用と新規サービスの共存の鍵とは?

続いて深堀していくのは、楽天を支えるさまざまな「サービスの運用」について。インターネットの普及とともに今なおトップを走り続ける「楽天市場」と、次々に立ち上がる新規サービスはどのように共存しているのでしょうか?
楽天だからこその運用方法や、普段聞けない苦労エピソードまでじっくり深堀りさせていただきます!

── 楽天といえばやはり楽天市場ですが、20年近く経ったサービスのシステム運用って実際どんな感じなんでしょうか?

若山光太氏(以下、若山)我々は楽天市場そのものではなく、そこで利用される「お気に入り機能」のようなプラットフォームを開発していますが、そこでも同じように長くメンテされているものがあります。 昔は開発スピードが最優先だったので、やっぱりぐちゃぐちゃになったレガシーなコードとか資料がないものとかもたくさんあります。

── やはり長く続くサービスでは避けられない部分ですよね。とはいっても新規機能も追加していかないといけないと思うんですが、レガシーコードや資料の改善と新規開発はどのくらいのバランスになっているんですか?

若山基本的にはレガシーな部分が原因で機能障害が起きてしまったときなどに根本的な解決をはかることが多いです。何人かが立ち上がって、バンとまとまった資料を作ります。

── なるほど。どんどん追加機能を加えていくと、古いものと新しいものが混在してツギハギのようになってしまいそうですが、機能追加するときの方針などはありますか?

若山機能の追加なら改修ですが、サービスの追加なら分割しちゃいます。インフラも開発言語もフリーで、環境を選ぶところから。既存サービスからデータを取る必要があるので、データはAPI経由で取得できるようインターフェースを作っています。同じところに作ってもいいかなというサービスでも、ある日「これ分割にしたい」ということがあるので最初からわけるようにしています。
いわゆるマイクロサービスの考え方を取り入れた、小規模なサービスを疎結合した作りですね。
例えば、お気に入り情報を元にお知らせを通知する機能を実装する際に、お知らせの機能は完全に別のサービスとして作ってしまって、API経由でデータを取るようにしています。

── なるほど。そうすることで「一枚岩(モノリシック)」のシステムの複雑さから開放され、変化に強いシステムを作れるというわけですね。インフラの選定もフリーとのことですが、どのように進めているのでしょうか。

若山インフラの構築は専任チームがいて、相談しながら選定していきます。

國本相談に乗ってくれたり、環境を作ってくれたり。環境は最近パブリッククラウドもちょっと使いますが、一番ベーシックなのは社内のIaaSですね。

若山インフラの選択肢は多いです。社内環境と合わせてAzureを使うこととかもあります。

── 社内のIaaSとパブリッククラウドは、どのように使い分けているのですか?

國本非機能要件や予算などもありますが、トータルで開発チームが面倒見たいケースはパブリッククラウド、役割分担してインフラを任せたいときは社内IaaS、といった感じですね。

「自社サービス」だからこそ出来るエンジニアの関わり方

── 新規サービス立ち上げの裏側についても教えて下さい。楽天ではバンバン新規サービスが立ち上がっていますが、エンジニアってどういう立ち位置なんでしょうか。

國本事業部やプロダクトマネージャといった役割の人が中心となりサービスの仕様を考えて、エンジニアはトラフィック要件とかを踏まえながらアーキテクチャ構成など決めていきます。自社サービスなのでユーザにとっていいと思うことはもちろんエンジニアサイド含め多方向からブラッシュアップしていきます。あとは会社の共通基盤としてインフラチームや各種のプラットフォームチームがいるので、それぞれ連携をとって進めます。

── トラフィック要件やアーキテクチャ構成はどのような過程で決めていくのですか?

國本トラフィック要件はそのサービスが目指す目標予算と過去他サービスでの実績をベースに辺りをつけることが多いと思います。アーキテクチャ構成はエンジニアリード的な役割のエンジニアが中心となってチームで新規性と保守・運用性の両面から考えるようにしていますね。

── なるほど。立ち上げ時は、企画段階からエンジニアが入っているんですか?

國本そうですね。はじめに事業側からこういうのがやりたいと上がってくるので、エンジニアが具体的にどう作っていくか落とし込みます。例えば楽天市場だと「店舗さんが今こんなことに困っているらしい」と上から降りてくる。それをどういうサービスでどういう機能を追加していくか提案していきます。

── エンジニアも「自社サービスを担っている」と実感できそうですね。サービス視点での開発を大事にされていることが伺えます。

楽天で働くことで広がる価値観のカタチ

最後のトピックは「働くこと」について。長寿サービス、大規模、英語、などさまざまなイメージを持つ楽天ですが、実際に働いてわかるカルチャーを深堀りしてみます。

── 楽天といえば「英語」が強いというイメージですが、そんな中で働いてみてどうでしょうか?

椎葉そうですね。やはり技術の1次情報は英語で出てくるので、キャッチアップしやすくなり嬉しいです。あとは日本文化をちょっと離れたところから見られるようになる。文化が違うと当たり前だと思っていたことが当然通じないことも多いので、相手と違う価値観を受け入れやすくなりました。

── 多様性に溢れているんですね。新しいアイデアや独創的なアイデアが生まれやすい風土が整っていそうです。エンジニアの側面でいうと、どのような文化がありますか?

國本開発の締め会、全体ミーティングなどでの共有や、Tech Talkという社内イベントを開催しています。Tech Talkではテーマを決めて人が集まって、成功事例や失敗事例を共有します。

── 自発的な学びができる場があるのはすごくいいですね。そういう雰囲気があると、刺激を受けて全体の士気が高まりそうです。

まとめ

  • これだけ多くのサービスを同時並行で運用しても、「改善グループ」が事業を横断して機能することで、客観的視点からの開発効率の向上、ノウハウ共有による全体の技術力の底上げができている。
  • マイクロサービスやドメイン駆動開発といった、変化に強い設計思考/開発思考を徹底することで、長寿サービス含めた多数のサービス運用の隣で、新規サービス次々に立ち上げることができる状態を維持している。
  • 自社でサービスを作っているからこそ、企画から入り込んでサービスをつくっていくので、サービス志向の強いエンジニアたちが育ち、活躍している。

── 御三方のお話をお伺いし、新旧サービスがなぜうまく共存できているのか楽天の裏側を覗けた気がしました!本日はありがとうございました。