先進的な取り組みを続ける現場に訪問し、
今回は、
【インタビューされた人】
鈴木陽介（すずきようすけ）
（株）鈴木陽介
デジタル編成局の組織体制
- ──まず、
日経電子版の開発チームの人数や構成を教えてください。 鈴木：はい。電子版の開発はデジタル編成局というグループが中心でやっています。全体としてはざっくり100人ほどの組織ですが、
内製化としてサービス開発に取り組んでいるチームはその中の40人くらいですね。手を動かして自分でコードを書くメンバーはそのうちの20人弱くらいです。サービス開発の内容としてはフロントエンド寄りが多く、 モバイルのアプリやWebのフロントエンド、 検索APIなどの開発をしています。課金や認証といったサービス基盤部分はまた別のグループになっています。 - ──20人弱でフロントエンド側も開発されているんですね。ほぼ内製化は完了されているんでしょうか。
鈴木：全部を内製化しているわけではなく、
まだ途中ですね。最も内製化の進んでいるモバイルアプリのチームには、 現在iOS、 Android、 モバイルWebアプリの開発のために内製のエンジニアがいて、 基本的にはその中で開発を進められる状態になっています。それとは別に、 検索エンジンやバックエンドのAPIを作っているチームでも内製化が進んでいますね。また、 Webのフロントエンドを作っているチームもあります。そこでは技術的に新しいこともやっていて、 Service Workerを使ったプッシュ通知の開発などもしています。 - ──技術的に新しいことにも積極的に取り組まれているんですね。逆に内製化されていないのはどういった部分になるんでしょうか。
鈴木：もともとあったデスクトップWeb用のインフラやAPIなどは、
主に外から来てもらっているエンジニアの方に開発してもらっています。そこに社員が一部入って一緒に開発したり、 社員が 「こういう形でやりましょう」 と言ったものを実装してもらったりという形で連携しています。
内製化：まず自分が作ってみることからスタート
- ──すべて内製化されているわけではなく、
領域によってやり方を変えているんですね。内製化される前はどのように開発されていたんでしょうか。 鈴木：請負型の発注をするか、
先ほど説明したデスクトップのチームのように社外のエンジニアを社員がマネジメントするかという体制でした。昔の話をすると、 インターネット時代の前からコンピュータを使って新聞を作るといったことに業界の中でも早くから取り組んでいて、 インターネットサービスが始まってからは、 いくつかのシステムを内製化していたことがありました。でもその後、 2010年の3月に現在の日経電子版が始まったときには全面的に開発をSIerさんにお願いするという方針だったんですよ。当時は私も基本的にはUIの設計や画面設計といった企画寄りの仕事をしていたんですが、 システムの中身の実装はやっておらず全然知りませんでした。そして、 そのときにいろいろ企画を出しても実現するのはすごく小さな部分だったり、 実行するにはお金がいくらかかりますとか、 できるのは半年後ですといった話になってしまって。 - ──企画しても進めづらかったんですね。
鈴木：もちろん、
時間がかかる理由は開発以外も含めてそれなりにありました。ただ、 自分も少しWebアプリを書いたことはあったので、 素人的な考えでもう少し早く、 手軽にできるだろうとも感じていました。そこで、 企画したものを勝手に2人で作り始めました。そうやって作ったスマートフォン向けのモバイルWeb版を2011年に公開したのが直近の内製化のスタートだと思います。その後2013年くらいから本格的にWeb向けのモバイル版のフロントエンドを内製で作っていて、 そこから正式に出せるレベルの製品が出てきた、 という流れになっています。当時はあまり組織立っていなかったところもあり、 もう少しなんとかしたいと思っていたときに、 現在㈱一休で執行役員CTOを務めていらっしゃる伊藤直也さんに技術顧問として来てもらうことになって、 そこから本格的な内製化が進みはじめました。伊藤直也さんが来られるたびに内製化の進め方も開発手法自体の問題も整理されてきて、 たとえばそもそもチーム体制を見直したり、 情報共有をうまくやろうということでSlackやQiita:Teamを入れたり、 GitHubのPullRequestについて研修してもらったりなどして進めていきました。そして、 そうした中で2015年の4月にiPhone向けのモバイルアプリを内部の人メインで開発してリリースしたのが重要なポイントだったかなと。 - ──技術顧問として入ってもらったのは大きかったんですね。
鈴木：はい。外部から指導者の方に入ってもらうのは大事ですね。メンターとなってくれる人に入ってもらうことで、
自分たちだとどうしても迷ってしまうところをサポートしてもらえます。社内である程度理解が得られればコンサル的に動いてくれる人と契約して来ていただくことは比較的やりやすい環境なので、 そういう人たちに指導役としてついてもらって成長していくのが重要だったのかなという気はしますね。内製化といったときに社員による完全内製でなければならないことはなく、 一緒の気持ちになって動いてくれるメンバーがいることが重要です。そういう意味でプロセスの改善は伊藤直也さんが手伝ってくれていましたし、 現在は元クックパッドの舘野祐一さんが引き継いでくれています。また、 UIデザイナーとして活躍されている深津貴之さんにはアプリのUIの改善を一緒にやってもらっています。
実際のものを見せて進めていく
- ──それまでは基本的に外部の人に実装してもらっていた状態から、
内部の人が中心になってアプリをリリースしたというのは大きな変化ですね。最初は小規模で2人で作ってみて、 そこから少しずつ内製の部分を拡大していった、 という流れなんですね。 鈴木：そうですね。特に一番初めは
「ものを見せて説得する」 というのが大事だと思います。外部向けにモバイルアプリ開発や内製化について話すと、 同業の人から 「どうやれば内製できるんですか」 と聞かれることも多いんです。たしかにゼロから説得するのは難しい。本当に最初の実績がない状態での説得は難しいので、 まず 「自分たちでもできるんですよ」 というのをものを見せて、 証拠として示さないと回らないというのはありますね。 - ──最初の実績をどう作るか、
ですね。 鈴木：社内の人たちも
「特別お金がかからずに新しいものができてきたなら、 まあいいか」 といったところはあるので、 最初は作って実証してみせるというのは大事だと思います。ただ 「やりたい」 とだけずっと言っていても、 なかなか変わらないですね。 - ──ではトップダウン的に
「これからは内製していくぞ」 という方針になったわけではなく、 鈴木さんとして 「内製するようにしなければならない」 という課題感が大きくて、 それで実績を作って変えてきたということですね。 鈴木：私だけではありませんが、
開発スピードが出ないことにもやもやしていた人はいたと思います。たとえばUIの変更などは特に内製化する必要があると思うんです。ちょっとしたボタンやパーツの位置を動かすだけでも、 外部の人にお願いすると50万円ぐらいで2週間かかってしまったりする。でもこれが内製であれば、 1日で済む話だと思うんですよね。自分でもいろいろと試していく中で内製でやることの向き／ 不向きは見えてきたんですが、 たとえばフロントのUI周りの部分はとても内製に向いているところだと思います。何かを変えるときに毎回2週間かかるか1日で終わるかで全然変わってきますね。
ほかの人をどう巻き込んで変えていくか
- ──大きな改善ですね。内製化するうえで組織の体制としても大きく変えられたと思うんですが、
変わるのに抵抗がある人もいると思うんですね。変えることを嫌がったり、 反対はしなくても積極的ではない人をどう巻き込んで変えてこられたのかを伺いたいです。やり方として 「実際にものを作って説得力を持つ」 以外に心がけてこられたことはあるでしょうか。 鈴木：あまり自分では意識していませんでしたが、
情報共有は大きかったのかなと思っています。会議型の情報共有ではなく、 Qiita:Teamなどを使った広報的な共有ですね。関わるメンバーが社内に100人規模でいるので、 彼らに 「今はこういう取り組みをしています、 その意図はこういうものです」 というのを伝え続けるのは重要かなと。 - ──広報的な情報共有、
おもしろいですね。 鈴木：内製化が重要である理由は、
伊藤直也さんなどとロジカルに話すにつれて詰まっていったんですね。 「なぜ内製化する必要があるのか？ 自分がやりたいからやってるんじゃないか？」 と言われてしまうとよくない。そこで、 なぜ内製化しなければならないかをはっきりと繰り返し説明していくんです。説明を繰り返すことで筋が通ってきて、 そうすると自分たちも自信が出てきます。おかげで説明はきちんとできるようになってきました。 - ──繰り返し論理立てて説明することで、
周りの人たちもだんだん重要度を理解してきたんですね。 鈴木：そうですね、
最初は特に内製化しようという声は社内にはなかったですから。ただ、 最初から自分で内製化についてすべてのビジョンがきれいに見えていたわけではないです。 「何かおかしいな、 こうしたほうがいいんじゃないか」 と思ったことに対して、 若干後付けがありつつも、 ロジカルに整理して伝えてきたという感じです。 - ──いい流れですね。ぼんやりとした課題感やこうあるべきだという思いがあっても最初は穴があったりあいまいなところは多いですから、
そこを伊藤直也さんや社内の人たちと議論を通して固めていって、 その内容を繰り返し社内の人に向けて広報的に伝え続けて、 全員が必要性を理解したから変えられるようになったと。 鈴木：はい。そうですね。
- ──ちなみに鈴木さんが考える内製化が重要である理由はどういうものなんでしょうか。
鈴木：まず自分たちのプロダクト、
サービスを開発して一番良い品質のものを一番良いタイミングでユーザーに届けていく必要があります。そしてそれをコスト面からも見たうえで何を内製すべきか判断するのですが、 その際にはコモディティかどうかが一つのポイントになると思います。たとえば課金システムや認証システムはある意味コモディティで、 独自性は出しづらい。一方メディアとしての表現というのはコモディティにはなりません。日経独自のコンテンツや表現、 サービスがあるので、 そこを実現するのは必ず独自のシステムにならざるを得ないと思うんですよね。独自のシステムを作る、 特にフロントエンドの改善を回していくときなどに、 外の人とやりとりするよりも内部のメンバーでやったほうが速いことは明白ですし、 それはアプリのレビューの評価改善などの実績でも証明できています。コモディティではないもの、 どんどん変化させていくものを誰がやるべきかというと、 それこそを内部でやるべきという結論になるかなと。 - ──感覚的に良いというだけではなくて、
レビューなどの数値からも実証できているというのは大きいですね。
自律的に動けるチームが良いチーム
- ──では最後に、
鈴木さんが考える良いチームとはどういうものですか？ 鈴木：メンバーが自律的に動けることが重要だと思います。サービスの方向性をすべてのエンジニアがきちんと理解してほしいですね。皆がサービスの方向性を理解して、
エンジニア一人一人がマーケティングやユーザビリティなどの側面も理解して作れる状態が良いチームかなと思っています。阿吽の呼吸というか、 それぞれの人が自律的に動く中でだいたい同じ方向に向かって動いているチームがいいですね。 - ──
「このプロダクトにとってこれは重要でやるべきである、 こういうことはやらない」 というのを全員が理解しているのは大事ですよね。各自が判断基準を持って動いていて、 かつその判断結果がチームとしてブレていないというか。 鈴木：そうですね。技術的な視点での自律的な動きの例として、
日経の 「紙面ビューアー」 というアプリのアーキテクチャが現場の判断で大きく変わったことが挙げられます。最初は普通にサーバを立てて動かそうといろいろミドルウェアを作りながら進めていたのですが、 もう少しでだいたい実装が終わりそうというときにAmazon Web ServicesのLambdaというサービスが出てきました。そのとき、 Lambdaを使ったイベント駆動のアーキテクチャのほうがサービスに合っているだろうという判断を開発者自身がして、 リリースまで時間があったこともあり、 これまでの実装をすべて捨てて書き直したんです。こうしたサービス要件とは関係ない変えやすいところであれば、 現場の判断と工数の程度を勘案してパッと変えるといったことができています。 - ──いいですね。技術的な観点で変えるべきなら大きな変更も判断して変えられる、
まさに自律的なチームになっているんですね。本日はありがとうございました。
本誌最新号をチェック！
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判／
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現！ - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT