140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（後編）

1月12日と13日に行われたスクラムのイベント「Regional SCRUM GATHERING Tokyo 2017」では、日本経済新聞社でモバイルアプリケーションの開発チームを担当する武市大志が登壇。内製化やアジャイル開発を実現するために改革と改善を繰り返してきた背景と事情を詳しく解説してくれました。

本記事はその講演内容をダイジェストで紹介します。

（本記事は「140年の歴史を持つ日本経済新聞社が、日経電子版アプリで内製化とアジャイル開発に挑戦した理由と現実、そして課題とは（前編）」の続きです）

バケツを大きくするためにリニューアル

次は、バケツを大きくしましょう。という話です。

なにをしたかというと、日経電子版のアプリを全面リニューアルしました。

2015年4月にリニューアルしたのですが、スクラッチで内製開発をし、UI/UXを変えるだけでなく、コンテンツを増やしたり、使えるユーザーを増やしたりしました。

深津さんと一緒に3カ月かけて紙のプロトタイプを丁寧にしあげていって、インフラもオンプレからクラウドへ移行して柔軟に対応できるようにしました。

リニューアルすると、AppStoreのベスト新着Appになりました。ここに載るとインストール数がすごいですね。

ただしバケツを大きくする作業はとてもつらいです。リニューアルすると体験が変わるので、反発する既存ユーザーもいます。そのため辛辣なフィードバックもたくさん来ます。胃に穴があきそうで、とてもつらい作業です。

おかげでインストール数は増えましたが、アクティブユーザー数が増えたかというと、そうではありませんでした。つまり、バケツには穴が空いていたんですね。

小さな改善の繰り返しでバケツの穴を地道にふさぐ

この穴をふさぐ必要がある。つまりリテンションを改善する必要がある。

穴をふさぐ作業というのは地道なグロースハックで、地味な改善の繰り返しです。なのでほかのチームからはなにをやっているのか見えにくい。

ある日、社内のプロモーション担当とこんな会話をしました。

内製で機能をどんどん追加していくんじゃないの？ という誤解というか期待みたいなのがあって、でもそうやって機能をどんどん足していくとどうなるか。

これは深津さんがよく説明に使う百徳ナイフ、こういうものができますよと。あなたは日経電子版をこうしたいんですか？ 違いますよねと。

穴をふさぐ作業というのは、チーム内でできることと、社内のほかのチームと連携することの2つがあります。

最初はアプリ開発チームが自分たちでやりやすいことからやります。ダウンロードの高速化や、画面がさくさく動くようにする、アプリがクラッシュしないようにするなど。

こうしたことを隔週くらいでリリースするようになりました。

ほかのチームと一緒に、伝統的な全角英数を半角へ

ほかのチームと一緒にやらなくてはいけない改善は、例えばほかのチームが担当しているAPIを改修するとか、記事の内容そのものの改修などがあります。

例えば、新聞の英数字は全部全角なんですよ。新聞は縦書きなので。これがスマホのアプリでもそのまま表示されていました。

このことは新聞社の伝統みたいになっていたので、そうした記事の見え方をいじるのは割とタブー視されていました。それを内製化のあとで半角英数に変えました。

これを実現するためにどんなステップが必要だったかというと、われわれは「編集」と呼んでいるコンテンツ担当者、記事を書く人に個別に相談をします。いきなり会議で言うと集中砲火を浴びるので（笑）

で、ある程度相談したあと、しかるべき会議で提案していくと。

そもそも技術的に変換可能なのか、別のチームが担当している分野なので相談をして、確認用のプロトタイプのアプリをわざわざ作って、それをインストールした実機を用意して、コンテンツ担当者に渡して、数日間使ってもらいます。

で、気になる点や問題があったら対応しますと言って、丁寧にデモをして信頼を得ていくと。

で、やっとOKが出たら、APIのチームと要件を詰めて実装をしてもらって、最終テストをすると。

こういうプロセスが必要でした。

半角英数にするのは当たり前と思っていたのですが、Twitterなどで話題になって、記事にもなりました。

こういう細かいところ、必ずしも数字に直結しないけれど、そういう改善を愚直にやっています。

例えば、左と右ではタイトルの改行位置が違います。左だと読みにくいことがあったので、いい感じで改行を入れられるように、あるロジックで改行をするようにしました。

上から降ってくる案件は、徹底的に削ぎまくる

こういう地道な改善とは別に、上から降ってくる案件、というのがあります。上司やほかの部局から「こういうことをやってくれ」というのが降ってきたりするのです。

そういうのに対応すると隔週の改善リリースが止まってしまうので、どうするかというと、依頼内容を削いで削いで削ぎまくる。

「ここにこういうボタンを出したいんだけど」「それは本当にユーザーのためになりますか？」とか「本当に使いますか？」とか「全部必要ですか？ 最初に一部だけ実装して、あとはフィードバックを待ちませんか。2週に一回リリースできますから、アジャイルですから」と。

削ぎ落とすことで要件がシンプルになり、仕様もシンプルになる。するとユーザーにも使いやすいはずなんです。

こういうことを一年間続けた結果、リニューアル直後はアクティブユーザーが増えていなかったのですが、いまは1.9倍になって、レビューもいい評価を得られるようになりました。

改善を続けていくためにしていること

当然、課題もまだたくさんあります。

例えば、どんどん課題を消化していくと、じゃあ次のリリースではなにをしようか？ ということもあります。

それを考える上で、インプットを増やしましょうと。

ご意見要望フォームを設けてユーザーの要望を聞きます。このフォームも投稿しやすいように改善していきます。

投稿があるとSlackでリアルタイムに通知が来たり、Backlogにタスクとして積まれるようにして、全部対応するわけではありませんが、一覧でもリアルタイムでも見られるようにしています。

こうした要望を実装すると、「神対応に感謝！」とか、いいフィードバックももらえます。

AppStoreのレビューもそうですし、チーム内、社内からもインプットを増やすのは大事です。

あとは、過去の自分たちがやってきた施策を振り返ってみようと。

日経電子版を認知してもらい、競合と比べられて、使い始めてもらい、継続利用してもらい、解約まで、それぞれの施策はこのどこにあたるのかを位置づけると、継続利用のところばっかりやってきました。

そろそろ初期利用のところとか選考のところの施策に踏み出してもいいかもしれないね、という話もします。

こうしてやるべきタスクを書き出して、重要度とやりやすさを軸にプロットします。縦軸が重要度、横軸がやりやすさで、右上にあるものを優先的に実装していくと。

他チームへの横展開が難しい

次の課題として、内製開発やアジャイル開発を社内のほかのチームにも横展開したいのですが、これがすごく難しいのが現状です。

新しいプロダクトの開発やリニューアルのタイミングは、体制やプロセスを変えるのに向いていますが、現在進行形のプロダクトでは、体制やプロセスを変えるのがすごく難しいです。

そこで、本当のスモールスタート、例えば朝会だけやってみるとか、そういう提案もあるかもしれないなと。

あるいは事故や問題があったときに、それを解決する手段として提案するのもありかなと思っています。

チームによってはソースコードをGitHubも使わずに手で管理しているところもあって、そうすると間違ったコードを使っちゃったという事故もあって、そういうときにGitHubでコード管理しませんか、お手伝いしますよと、そういう流れで広げていくことも必要かなと思っています。

そして育成と評価。

エンジニアを育てて評価することも必要になってきますが、いまのところ新卒エンジニアの育成プログラムは整備されていません。また、エンジニアの評価制度も整備仕切れていないのも課題です。

エンジニアを増やすぞといっても、こうした受け入れ体制が整わなければ回らないので、育成と評価の体制は見直していかなくてはと思っています。

僕らのチームの内製化が回り始めているので、それを見たほかの部署もやりたいと思い始めているのですが、エンジニアさえ雇えばプロセスの改善も含めて全部彼らがやってくれると思っているところがあって、そういうわけじゃないので、そういうことも含めて体制が必要だなと思っています。

まとめとこれから

まずは体制作りをして、スモールスタートでアプリのフロントエンドから内製化を始めました。

穴の空いたバケツは、実行の順番が大事ですよと。

で、地味な改善、穴をふさぐことを絶対にやめちゃいけないと思っています。アプリがいい感じになって、もうやることがないと思っていても、トレンドや周囲の環境はつねに動いているので、気付いたら新しい穴が空いていたりします。

そしていい人材が定着する土壌作りをして、そろそろ蛇口を広げてもいい頃かと思っているので、そのためにできることをこれからも探して実行していきたいと思っています。

Ｑ＆Ａ

会場から　開発は速くなっても、それをリリースするために誰それさんに説明して、承認をもらって、というところで時間がかかるともったいないと思うのですが、そこはどうやって改善しているのでしょうか。

武市氏　おっしゃるとおり、僕らも2週間に一回リリースできるのに、実装もテストも終わっているのでリリースしていいですかとスタッフに聞かれて、僕が「ちょっと待って、まだ部長に言ってないんだよ」というのはあります。

さっき重要度とやりやすさという話をしましたが、やりやすさには技術的なやりやすさと、調整などのしやすさというのがあります。

なので、調整のやりにくいものは早めに仕掛ける。担当者に早めに言ったり、ひたすらデモをして見せます。小さな変更であっても。

そうやって信頼を得ていく、変更によってどんな変化があったのかも担当者とシェアしていく。そうやって信頼を得ていくと、まあ武市が言っているから大丈夫だろう、という状況になりつつあります。そういう地道な活動をしていますね。

会場から　日経電子版というアプリが会社にとって重要になってくると、アプリの方針が経営判断などに左右されることになってくるのではないかと想像するが、どこまで経営とにぎっているのでしょうか？

武市氏　リニューアルした当初は、日経電子版のアプリはそれほど社内での存在感はなくて、やりたいことがやりやすかったのですが、確かにいまはユーザーが増えてきて、会社の方針に関わってきつつあります。

ただ、そうした要望が来たときでもひたすら要件をそぎ落とすということをしてきたので、いまは上から降ってくる案件でも、かなり整理した状態で持ってきてくれるようになりました。

自分が上層部の会議対に入っているかというと、そこまでは参加していません。僕の上とか、その上から情報を下ろしてくれて、それで回っていると思います。

ただ、そういう会議に出なくてはいけなくなることもあるかもしれないので、そういうときどうするか。自分の代わりにプロダクトを見る人材を育てなくてはいけないですし、そこは課題だなと思っています。

ご静聴ありがとうございました。