チーム・開発組織・プロジェクト進行、LINEとYahoo! JAPANの大規模アプリ開発はどのように行われているのか

LINEとYahoo! JAPANの大規模アプリ開発の裏側

早石明浩氏（以下、早石）：本日はヤフー株式会社CTO室の西さんをお招きして、LINEアプリとYahoo! JAPANアプリ、大規模開発の裏側というテーマでお話ししたいと思います。

それではスピーカーの自己紹介から始めます。私はLINE開発2室チームでLINEのクライアントアプリの開発チーム室長をしている早石と申します。よろしくお願いします。

西磨翁氏（以下、西）：ヤフー株式会社のCTO室でYahoo! JAPANアプリ全体の責任者をしています、西磨翁と申します。よろしくお願いいたします。

早石：私と西さんで事前に、大規模開発、LINEとヤフーのアプリについて何かみなさんにお話できるようなことがあるんじゃないかという話をしていて、6つほどテーマを考えてきました。

チーム・開発組織や、プロジェクトの進行といった部分、大規模開発の特徴といった部分、困難なこと、今後の取り組み、そしてアプリエンジニアの今後のキャリアについてという内容で本日はお話ししたいと思います。

チーム・開発組織について

では最初は、チーム・開発組織について。こちら、ヤフーさんのほうで何かおもしろい話あったら、お願いします。

西：はい。ヤフー株式会社はいわゆる「開発部」「デザイナー部」「企画部」みたいな職種カットの組織体制ではなくて、ショッピングとかメディアとか、いわゆる市場ごとに統括本部を作っています。その統括本部ごとに開発部とかデザイナー部があります。

このやり方をすることで、それぞれの市場にとって最適な方法や体制で開発を進めてもらうことができるようになっており、これは2012年に社長が井上から宮坂に変わった時代にこの体制になって、それから約8年間ずっとこのやり方で進めています。

このやり方でやると、意思決定や開発速度は速くなるのですが、やっぱりいろいろな部署で同じようなものを作ってしまうとか、いろいろいろなルールを同じように作ってしまうことが起きますので、そうはならないように全社横串で使える開発ガイドラインを作っています。

このガイドラインの中で、Yahoo! JAPANとして必ず守るべきもの、それから推奨するものというふうに、レベルをいくつか分けてルールとノウハウを掲載して、それを使ってもらっています。市場ごとに最適な開発スタイルを選択してもらう。基本的にこういった流れで進めてもらっています。

早石：非常に興味深いお話ありがとうございます。ちょっと質問なんですが、その横串のガイドラインは、それぞれの事業組織にいる開発者・デザイナーの方も一緒に入って考えられているんでしょうか？　それともCTO室で出したものをみんなが受け入れているんですか？

西：ガイドラインを作る際はガイドラインチームといったいわゆるプロジェクトみたいなバーチャル組織を起こしますが、起こす際のメンバーは各統括本部から人を集めて、みんなで考えていっていますね。

ガイドライン自体はどの統括本部でも使えるようなレイヤーでカットしています。例えばHTTPSに関するガイドラインだとか、ヘッダー・セッション、アプリ、UIデザインとかですね。

早石：なるほど。横串のガイドラインと聞くと、けっこうもうそもそも作るのが、合意を取るのが大変というイメージがあるんですけど、それを実際に実践されて、縦串のよさと横串のよさが両方活かされているということですね。

このあたりちょっとLINE側の事情をお話ししますと、LINEでは横串のインフラ、セキュリティ・データ分析は、それぞれプロダクト共通で必要な機能になるので、専門の開発組織があります。

それ以外には、その事業部に対応したプロダクト開発組織があって、その中にフロントエンドの開発とか、サーバーのAPIを開発するチーム、ネイティブアプリを開発するチームというように分かれていて、その部分に関しては、その事業の中にある開発チームごとに、それぞれ独自のガイドラインを作って運用をしている感じですね。

このあたりが、チームによって異なっていて、カオスではあります。先ほどのヤフーさんのほうでも感じられていると思いますが、ある意味意思決定が速くなる部分もあって、今のところはそういうかたちで、それぞれのプロダクトごとやチームによってガイドラインを分けていたりします。

それ以外に特徴としては、アプリを作るチームがグローバルに分かれていて、チームが東京だけではなくて福岡・韓国・台湾と国内外にあったりします。こちらはけっこうOne Teamで開発できていて、それぞれメンバーがチャットでコミュニケーションを気軽に取ったり、ビデオ会議で顔を合わせながら開発をしている、けっこうグローバルなチームになっています。

西：やはりガイドラインが個々によって分かれているとはいえ、意思決定が速いのはすばらしいと思いますね。本当に。やっぱり事情が会社さんや部署によって違うので、それぞれ最適なやり方を選んでいくのがすごく大事かな、と私も思いますね。

早石：もちろん、プロダクトによってはチームが大きいので、チームごとでもコーディング・コンベンションを作るのが大変だったりはするのですが、みんながんばってやっている感じです。

プロジェクトの進行について

では、次のテーマに移りたいと思います。次はプロジェクトの進行。どういったときにプロジェクトが発生するのか・できるのかということについて、ちょっとお話ししていきたいと思うのですが、どうですか？　

西：売り上げをあげるためのプロモーションに関するものや機能開発などいろいろなプロジェクトがあると思うのですが、アプリでの注目プロジェクトで言うと、年に1回のOSのメジャーバージョンアップのときですね。

先日リリースされたiOS 14で言いますと、6月にWWDCがあって新しくウィジェットが発表されましたと。そのときに、私たちは6月に発表されたその直後にプロトタイプの開発を開始しまして、iOS 14が出る9月には、Yahoo! JAPANのアプリは全部で約30個あるのですが、その半数弱である12個のアプリでウィジェットを実装して、リリースできています。

新しいOSの機能を使った機能は、まだ世の中にはないので、β版のOSを触りながらプロトタイプを作ってマネージャーにプレゼンして、それから承認をもらってリリースするという、いわゆるボトムアップの流れが特徴的なところです。

早石：質問なのですが、こういったプロトタイプを作るときに、例えばiOSでは新しい体験になると思うんですが、そういった場合って、まずは開発者だけでアイデアを考えて、それを提案していくかたちなんですか？　それともデザイナーやプロダクトを作っているメンバーも巻き込んで、一緒にプロトタイプしていく感じなのでしょうか？

西：基本的には職種は関係なく、興味がある人が手を挙げながらやっていくかたちが多いです。サンプルプログラムを書けるエンジニアが率先する立場になることが多いですが、デザイナーも「こんなことができるんじゃないか」とか、企画のほうも「こんなことをすると売上増につながるんじゃないか」とか、それぞれアイデアを出し合いながらプロトタイプを作っていきます。

早石：ボトムアップなアプローチで、いきなり12個のアプリで対応できるのは、本当にすごいなと思います。ウィジェットの例でいうと、LINEでは毎年「Early Bird TF」というタスクフォースを作っていまして、新しくリリースされるOSのバージョンに合わせて新機能を提案して、ボトムアップなアプローチでリリースしていくようなことを行っています。

去年（2019年）であれば、ダークモードであったりとか、今年はウィジェットがリリースできると思うのですが、けっこういろいろなプロジェクトが並行して動いているなかで、ちゃんとタスクフォースというかたちでメンバーを確保して、ボトムアップのアプローチで進めていっているのがLINE側の事情になりますね。

去年の例で言うと、ダークモードのような、もうデザインを全部見直さないといけない、実際にはかなり大規模なアプローチとその影響範囲がすごく広かったので、Early Birdと言いながら、すぐには出せなかったのですが、そういったアイデア部分の作り込みから、プロトタイピングといったものもボトムアップで行っています。

西：きっちりしたリリースサイクルを準備されているのは、非常にすばらしいと思います。このEarly Birdのタスクフォースは開発の専用レーンだと思いますが、弊社の場合はあまりそういった仕組みはなく、仕組みとして整っているLINEさんの環境を非常にうらやましく思います。

早石：ただ、これはアプリごとに事情が異なりまして、Early Bird TFというタスクフォースを作っているのは、主にLINEアプリで、ほかのアプリに関しては、それぞれの事業の優先順位に対して決めたり、ボトムアップのアプローチを適用したりというかたちで進めています。

西：いいですね。

早石：ありがとうございます。

開発の長期化で大変なところ

では、次のテーマにいっていきたいと思います。大規模開発をしていると、けっこう開発チーム自体が大きくなったりとか開発自体が長期化してくると思うのですが、こういった開発において、お互い工夫していることや「こういうのが大変です」というような話ができればいいかなと思うのですが、ヤフーさんはどうでしょうか？

西：売上を上げるアプリは自然と寿命が長いアプリになって、もちろん長期運用になるということで、最初に設計したアーキテクチャがだんだん古く感じる場面は多くなってきます。そこに対して、リプレイスをするとかアーキテクトを見直すってこともやりたいのですが、並行で案件が発生していることもあって、なかなか大きな工数をとってアーキテクチャを見直すことができないことがあります。

アプリで言うと、言語がObjective-CからSwift、JavaからKotlinに変わるといったタイミングが過去ありました。こういった案件、言語やアーキテクチャを変えていくところは、先ほどお話ししたボトムアップだと工数の面で非常に難しい。こういったケースではトップダウンでやってくださいというふうに指示を落とすこともあります。この言語の移行のケースでは、役員であるCTOから発信してもらうような工夫もやっています。

技術案件は、売上に直結せず、将来的に開発効率があがって多くの施策が打てるようになってくるなどジワジワ効いてくるものも多くありますので、効果がすぐにでないことに対してなかなか理解が得られないとか合意を取るのに非常にコストがかかるものだと思っていて、そういったところに現場のコストを割くのではなくて、現場のみなさんは安心して作業に着手できるようにするために、CTOからのトップダウンという方法をあえて選んでやったりもしていますね。

早石：なるほど、今の話、まさに言語の切り替えっておもしろいテーマだなと思うのですが、Yahoo! JAPANアプリもそうだと思いますし、LINEアプリも、SwiftやKotlinが出る前から開発していたものだと思うので、既存のコードベースがすごく残っているなかで、それをそもそも新しい言語に切り替えのは、いろいろなアプローチがあると思っています。

LINEの例で言うと、例えばKotlinやSwiftが出たときに、新規のファイル、新規のコードはなるべく新しい言語で書いて、既存のコードは、時間があるときや開発側に余裕があるときにマイグレーションしていくような、ボトムアップなアプローチを採っていました。

これは、けっこうLINEだと開発側で技術的な、リファクタリングやそもそもの言語の移行といったことは、開発側でプロジェクト化して進行することが多くいのですが、あまりトップダウンでやることはないんですね。

現場の開発者がエンジニアリングマネージャーと話して、エンジニアリングマネージャーがプロダクトマネージャーと話して、その優先順位を決めていくようなことをしていたり、それがさらにプロジェクトやプロダクトによってけっこう異なったりしています。

全社横串でそういった方向性をかけられるのは、けっこうおもしろいアプローチだな、すごく効率的なアプローチだなと思いました。

確かにちょっとLINEのアプローチだと、自由度はけっこうあってストレスはそんなにないのですが、自分たちでしっかり計画を立てて進行しないと、ほかのプロジェクトの優先順位に押されて完了までに時間がかかったり伸びてしまうことがあるので、いろいろなアプローチがあるとは思いますが、ヤフーさんのアプローチはすごく興味深いです。

西：横串の活動は多くの人が関わってくるため、ナレッジをどう共有しながら長く安定して運用していくかがポイントになってきます。ナレッジ共有のためのドキュメントを作ることも大事なのですが、ドキュメントもメンテナンスコストかかるので、どこまで詳細に作るかは非常に悩ましいポイントです。

そういった中でどのようにドキュメントやナレッジを共有しているかといいますと、まず、サービス仕様といったそのサービスのあるべき振る舞いを記載したドキュメントは最低限作成します。しかし、プログラムの詳細な設計といった部分についてはドキュメントを作成して知識を共有することはせず、ペアプロを使った開発作業の中で共有をしています。

ペアプロは、2人でプログラミングするだけじゃなくて、そのペアを日々ローテーションさせながら、ナレッジを共有しながら開発していきます。大規模な仕様をもつアプリに対しては、大規模なリソースを投入すると、情報共有のミーティング開催や状況の確認と伝達などマネジメントコストが多くかかるのですが、ペアプロを使いながら開発者が知識を伝達させていくことをすると、自然に知識が共有されて、結果として属人化しなくなっていくんですよね。

開発タスクって、基本的に「このモジュールはあなたです。このモジュールはあそこのチームです」みたいな感じで縦割り型になっていきますが、開発コストを最適化しようとすると、役割が明確で開発コストが管理しやすい縦割りになりがちです。そうすると開発させられている感というか、やることが決まってしまっている感も出てきます。こうなると情報を積極的に共有しようとしなくなる。チームで開発させるようなかたちに置き換えていくことも、1つポイントかなと思っていますね。

ローテーションさせながらやると、全員で作っていく雰囲気になってきますので、モチベーションを高くできます。長いプロジェクトに関しては、こういったところも大事かなと思って実践しています。

早石：なるほど。LINEアプリではヤフーさんのように「ペアプログラミングをシステム化してチーム全体で開発している雰囲気を出していこう」というかたちではないのですが、チームによっては行っていたり、1つの機能の開発を、1人ではなくてバディを組んで進行するようなことを行って、言われていたような属人化をなるべく減らそうという試みをしていますね。

西：属人化の解消は非常に難しいですよね。

早石：そうですね、私自身もそういった経験がありますね。

それ以外に、ちょっと大規模開発ならではの特徴というか、コミュニケーションがやっぱりすごく多くなってくる。で、開発自体が複雑になってきて、違う領域同士のコミュニケーションが複雑になってくることがあると思うのですが、LINEアプリでは初期から「Thrift」というフレームワークを使いまして、IDLを定義してAPIや型を定義して、そのIDL上でプルリクエストなどで議論を行って、クライアントやサーバーといった領域を跨いではいるのですが、同じAPIについて議論をして、そこからコードを自動生成して、お互いにちゃんと意図したものを使えるといったような仕組みを、当初から導入していますね。

西：いいですね。

早石：ドキュメントを作るってもちろんすごく大事ですし、実際我々もAPIのドキュメントを作ってたりはするのですが、ドキュメント自体がコードになるので、誰かが間違って変更しても、それがコンパイルが通らなかったりとか、そもそも後方互換がしっかりしているので、追加された新しいフィールドがほかの機能に影響を及ぼすことを減らしたりはしていますね。こういう技術面でコミュニケーションコストを減らしたりするような取り組みも行っています。

西：いや、すばらしいです。本当にそのとおりだと思いますね。我々もSwaggerを使ったりとかしながら、できるだけ書き方が誰かのやり方に寄らないようにとか、テストも書いて自動化していますね。

早石：それ以外には、リリースについては、先ほどちょっとEarly Bird TFの話をしたのですが、そういったタスクフォースやプロジェクトはけっこう並行してかなりの数が動いている状況で、リリースを調整するコストがけっこう高くなってきています。

それに対してLINEの採っているアプローチは、2週間に一度決められた期間でテストをして、決められた期間で開発をして、月に2回リリースするような固定のリリースサイクルを作っています。

もちろん、問題があったときのホットフィックスや特別な対応のバージョンがイレギュラーで存在するのですが、スタンダードなリリースサイクルを用意することで、先ほど言ったようなコミュニケーションコストを下げることに、今のところは役に立っていますね。

例えばなにかのプロジェクトで、ちょっとテストが遅延してしまって、このままだと「全体のテストを遅らせて、リリース少しずらせますか？」というコミュニケーションもあると思うのですが、それがテストの初期からわかっていれば、次のリリーススケジュールに延期できるようにするといったアプローチを採っています。

固定のリリースサイクルがあることで、開発だけじゃなくてQAチームやプロダクトマネージャーのチームも、今回出せなかったとしても、次に出せることがもうすでにスケジュール上でわかっているので、心理的な安心感もあって、そういったことが柔軟にできるようになっています。

結果としては、プロダクトの安定性やコミュニケーションコストを減らすようなことにつながっているのかなと思います。ヤフーさんはそういったリリースサイクルに対して工夫をされていたりしますか？

西：そうですね。確かに、リリースに関するコミュニケーションコストは意外と高いので、リリースサイクルは基本はやっぱり2週間に1回や、多くても1週間に1回で、固定化していますね。

リリースすべきものとか「これは出せないよね」というもののジャッジポイントも明確にしておいて、その判断基準も事前に設定をしておいて、そこも自動化するといったところまで、今のところは踏み込んでやっていますね。なので、どこまでいけばリリースできるんだというところの擦り合わせコストを都度払わなくていいのが非常によいかなと思って、実践していますね。

早石：そのあたりはLINEとヤフーさん、お互いかなりやっぱりコミュニケーションコストを減らすところに関しては、工夫していることが多いですよね。