進化を先取る現場から

第4回 日本経済新聞社 鈴木陽介―周囲を巻き込み,内製化を実現

この記事を読むのに必要な時間:およそ 3.5 分

実際のものを見せて進めていく

画像

─⁠─それまでは基本的に外部の人に実装してもらっていた状態から,内部の人が中心になってアプリをリリースしたというのは大きな変化ですね。最初は小規模で2人で作ってみて,そこから少しずつ内製の部分を拡大していった,という流れなんですね。

鈴木:そうですね。特に一番初めは「ものを見せて説得する」というのが大事だと思います。外部向けにモバイルアプリ開発や内製化について話すと,同業の人から「どうやれば内製できるんですか」と聞かれることも多いんです。たしかにゼロから説得するのは難しい。本当に最初の実績がない状態での説得は難しいので,まず「自分たちでもできるんですよ」というのをものを見せて,証拠として示さないと回らないというのはありますね。

─⁠─最初の実績をどう作るか,ですね。

鈴木:社内の人たちも「特別お金がかからずに新しいものができてきたなら,まあいいか」といったところはあるので,最初は作って実証してみせるというのは大事だと思います。ただ「やりたい」とだけずっと言っていても,なかなか変わらないですね。

─⁠─ではトップダウン的に「これからは内製していくぞ」という方針になったわけではなく,鈴木さんとして「内製するようにしなければならない」という課題感が大きくて,それで実績を作って変えてきたということですね。

鈴木:私だけではありませんが,開発スピードが出ないことにもやもやしていた人はいたと思います。たとえばUIの変更などは特に内製化する必要があると思うんです。ちょっとしたボタンやパーツの位置を動かすだけでも,外部の人にお願いすると50万円ぐらいで2週間かかってしまったりする。でもこれが内製であれば,1日で済む話だと思うんですよね。自分でもいろいろと試していく中で内製でやることの向き/不向きは見えてきたんですが,たとえばフロントのUI周りの部分はとても内製に向いているところだと思います。何かを変えるときに毎回2週間かかるか1日で終わるかで全然変わってきますね。

ほかの人をどう巻き込んで変えていくか

─⁠─大きな改善ですね。内製化するうえで組織の体制としても大きく変えられたと思うんですが,変わるのに抵抗がある人もいると思うんですね。変えることを嫌がったり,反対はしなくても積極的ではない人をどう巻き込んで変えてこられたのかを伺いたいです。やり方として「実際にものを作って説得力を持つ」以外に心がけてこられたことはあるでしょうか。

鈴木:あまり自分では意識していませんでしたが,情報共有は大きかったのかなと思っています。会議型の情報共有ではなく,Qiita:Teamなどを使った広報的な共有ですね。関わるメンバーが社内に100人規模でいるので,彼らに「今はこういう取り組みをしています,その意図はこういうものです」というのを伝え続けるのは重要かなと。

─⁠─広報的な情報共有,おもしろいですね。

鈴木:内製化が重要である理由は,伊藤直也さんなどとロジカルに話すにつれて詰まっていったんですね。⁠なぜ内製化する必要があるのか? 自分がやりたいからやってるんじゃないか?」と言われてしまうとよくない。そこで,なぜ内製化しなければならないかをはっきりと繰り返し説明していくんです。説明を繰り返すことで筋が通ってきて,そうすると自分たちも自信が出てきます。おかげで説明はきちんとできるようになってきました。

─⁠─繰り返し論理立てて説明することで,周りの人たちもだんだん重要度を理解してきたんですね。

鈴木:そうですね,最初は特に内製化しようという声は社内にはなかったですから。ただ,最初から自分で内製化についてすべてのビジョンがきれいに見えていたわけではないです。⁠何かおかしいな,こうしたほうがいいんじゃないか」と思ったことに対して,若干後付けがありつつも,ロジカルに整理して伝えてきたという感じです。

─⁠─いい流れですね。ぼんやりとした課題感やこうあるべきだという思いがあっても最初は穴があったりあいまいなところは多いですから,そこを伊藤直也さんや社内の人たちと議論を通して固めていって,その内容を繰り返し社内の人に向けて広報的に伝え続けて,全員が必要性を理解したから変えられるようになったと。

鈴木:はい。そうですね。

─⁠─ちなみに鈴木さんが考える内製化が重要である理由はどういうものなんでしょうか。

鈴木:まず自分たちのプロダクト,サービスを開発して一番良い品質のものを一番良いタイミングでユーザーに届けていく必要があります。そしてそれをコスト面からも見たうえで何を内製すべきか判断するのですが,その際にはコモディティかどうかが一つのポイントになると思います。たとえば課金システムや認証システムはある意味コモディティで,独自性は出しづらい。一方メディアとしての表現というのはコモディティにはなりません。日経独自のコンテンツや表現,サービスがあるので,そこを実現するのは必ず独自のシステムにならざるを得ないと思うんですよね。独自のシステムを作る,特にフロントエンドの改善を回していくときなどに,外の人とやりとりするよりも内部のメンバーでやったほうが速いことは明白ですし,それはアプリのレビューの評価改善などの実績でも証明できています。コモディティではないもの,どんどん変化させていくものを誰がやるべきかというと,それこそを内部でやるべきという結論になるかなと。

─⁠─感覚的に良いというだけではなくて,レビューなどの数値からも実証できているというのは大きいですね。

記者からエンジニアまで多彩な職種の方が集ってサマーナイトフェスティバルニュースを伝える日本経済新聞社のオフィスでお話を伺いました

記者からエンジニアまで多彩な職種の方が集ってニュースを伝える日本経済新聞社のオフィスでお話を伺いました

自律的に動けるチームが良いチーム

─⁠─では最後に,鈴木さんが考える良いチームとはどういうものですか?

鈴木:メンバーが自律的に動けることが重要だと思います。サービスの方向性をすべてのエンジニアがきちんと理解してほしいですね。皆がサービスの方向性を理解して,エンジニア一人一人がマーケティングやユーザビリティなどの側面も理解して作れる状態が良いチームかなと思っています。阿吽の呼吸というか,それぞれの人が自律的に動く中でだいたい同じ方向に向かって動いているチームがいいですね。

─⁠─「このプロダクトにとってこれは重要でやるべきである,こういうことはやらない」というのを全員が理解しているのは大事ですよね。各自が判断基準を持って動いていて,かつその判断結果がチームとしてブレていないというか。

鈴木:そうですね。技術的な視点での自律的な動きの例として,日経の「紙面ビューアー」というアプリのアーキテクチャが現場の判断で大きく変わったことが挙げられます。最初は普通にサーバを立てて動かそうといろいろミドルウェアを作りながら進めていたのですが,もう少しでだいたい実装が終わりそうというときにAmazon Web ServicesのLambdaというサービスが出てきました。そのとき,Lambdaを使ったイベント駆動のアーキテクチャのほうがサービスに合っているだろうという判断を開発者自身がして,リリースまで時間があったこともあり,これまでの実装をすべて捨てて書き直したんです。こうしたサービス要件とは関係ない変えやすいところであれば,現場の判断と工数の程度を勘案してパッと変えるといったことができています。

─⁠─いいですね。技術的な観点で変えるべきなら大きな変更も判断して変えられる,まさに自律的なチームになっているんですね。本日はありがとうございました。
WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.119

2020年10月24日発売
B5判/160ページ
定価(本体1,480円+税)
ISBN978-4-297-11669-9

  • 特集1
    [古い技術,コードの重複,密結合]
    フロントエンド脱レガシー
    長く愛されるプロダクトをさらに改善していくために
  • 特集2
    インフラ障害対応演習
    「避難訓練」でいざに備える!
  • 特集3
    深層学習入門以前
    チュートリアルを動かす前に知っておくこと

著者プロフィール

海野弘成(うみのひろしげ)

京都大学工学部にて情報工学を専攻。在学中にはてなやGoogleにてソフトウェアエンジニアとしてインターン,アルバイトを経験。iOSアプリ開発などを担当する。2011年,友人2人と作ったプログラマーのための技術情報共有サービス『Qiita』を公開。大学卒業後の12年2月,Increments株式会社を設立し,代表取締役に就任。主なサービスに,『Qiita』のほか,チーム内情報共有ツール『Qiita:Team』がある。

Qiita:http://qiita.com/yaotti