日経電子版開発内製化の取り組み #bpstudy

スライド

speakerdeck.com

自己紹介

  • 鈴木陽介
  • 2001年入社
  • 元々は編集の仕事をしていた

アプリ内製化の話がバズりました

  • 新聞業界の反響がすごかった
    • 伊藤直也さん紹介してください」と言われた

日本経済新聞について

  • 1876年12月に創刊
  • 最初は物価についての話だった
  • 3000人ぐらいの社員のうち、1000人ぐらいが記者
    • 日経に入社すると説明が面倒くさい
    • 入社したというと、「記者なの?」と聞かれる

日経電子版について

  • 2010年3月スタート
  • 40万人が登録
  • モバイルサービスを強化
  • 開発部隊は40人ぐらい

NIKKEINET時代(1996年頃)は結構内製してた

  • 英文記者出身の人がVBで作ったCMSを結構使っていた
  • Parlでアクセスログ集計・解析ツールを開発
  • 使う人が限られていた

日経電子版の開発(創刊頃まで)

  • 超大手SIerが沢山入って開発
  • 性能(レスポンス)は良い
    • お値段並みの性能
  • 変更コストは増大

内製化の流れ(2010年3月頃)

  • ちょっとしたことにも手間と時間とお金がかかる
  • 企画を上げても実現しない
  • 「こんなにお金がかかるのか」と個人的には思った

ほぼ勝手に2人で開発を始めてみた

  • 最初はPHP+RubyAPIMySQLで社内サーバに作った
  • 性能はイマイチ
  • お倉入り

スマホブラウザー版(β)を開発

  • インフラ面も含めて(GAE)2人で作った
  • 当時のGAEはJavaPythonしか使えなかったのでPython
  • 地下鉄は電波が届かなかったので、オフラインにも対応
  • GAEはすごい
    • 勝間さんに告知してもらったら大量のアクセスが
      • →GAEがインスタンスを10個から40個まで勝手に増大してくれて耐えた

内製化したサービスが正式版に

  • 2012年にWindows8のアプリを開発
    • Windows8のアプリ自体流行らなかった…
  • 2013年にスマホブラウザ版を公開
    • AWS
    • 新人が開発
    • 今も別の新人が開発
  • 常駐のSEさんが社内で開発するように

もっとモダンな開発をしたい

  • 伊藤直也さんにとある技術顧問をお願いしたらOKに
  • 伊藤直也さんに顧問をお願いしている会社は大体は技術の問題じゃない
    • 日経もそうだった
  • まずチーム体制の変更から行った
    • 目が潰れそうなエクセルのアサイン表をなくした
    • チームをまたいだ兼務を極力解消した
  • 内製の範囲を絞る
    • まずはフロントを中心に
  • CIやGitなどのカイゼンチームを作った
  • 情報共有をした

伊藤直也さんは色々と怒ってくれる

  • 打ち合わせのアジェンダをちゃんと時間をかけて作る
  • 打ち合わせの人数は絞る
  • メンバーに自分事感が足りない

  • 「怒ってくれた」とTwitterで褒めておいてもらえると本人は喜んでもらえると思う

カイゼンチームの仕事

  • 情報共有
  • エンジニア採用
  • Github&プルリク
  • デプロイ自動化
  • 自動テスト

コミュニケーションツールの導入

  • Slack
    • 270人超
    • 私の建替え金額も膨大に
  • Qiita:Team

    • 社内メンバー100人超
    • 累計1000投稿突破
  • 最初はなかなか使ってもらえない

    • 粘り強く伝えた

合宿を開始

  • 3,4ヶ月に一度、合宿を開催
  • ロードマップを共有
  • 実際には宿泊せず、日帰りで

技術面も進めている

  • GitHub

    • デザイナーもプルリクしている
      • 「コミットが壊れたんだけど」みたいに言われることもあるけど、根気強く対応
      • 「今までリネームして、とかしてたんで便利だなと」
  • CIと自動テスト

    • GithubからpushでCircleCIと連動

採用ブランディング

  • 勉強会で話す
  • 勉強会の会場ホスト
    • Gocon
    • Rebuildfm
    • AnsibleMeetup
      • 日経としてもAWSに200台規模に移行した話をしたりする予定
  • ハッカソン
    • 学生限定でクックパッドと共に

振り返って大事だったもの

熱意とビジョン

  • ビジョンをかかげ、底に向かってチームを変革していく
    • 140年の歴史があると、階層構造があると、動きが悪くて邪魔も入ってきたりする
    • みんなが効率悪いことをやりたいわけじゃない
  • 考え方は色々違う、繰り返し情報発信する
    • Qiitaとか色々書くとちゃんと読んでくれる人もいる
    • 技術的にとかモダンとかも大事だけど、それをみんなのためにやることが大事

とにかくやる

  • いつまでも考えているばかりじゃダメ
  • 他社がやっているんでウチもじゃなく、実績を作り上げることは重要
    • コードが多少汚くても、まずは動くことを証明する
    • 最近はテストをしないといけないことを実感しているが、まずは書いてみる
  • あんまり細かい事情を知らないからこそできることもある
    • 変なバイアスが入らない

なぜ内製するのかきちんと考える

  • 目的と手段は逆転しがち
  • PDCAサイクルを早く回せるのが強み
    • ユーザーからダイレクトに意見がくるフロントから
  • 社内にノウハウが残る
  • 取引コストを下げる
    • しっかりと仕様を決めてから発注するのは生産的じゃない

メンターを呼ぶ

  • 自力で全部は無理
  • naoyaさん「外部の人の意見は聞いてくれる」
    • 自分の意図に載っている時は特に助かる
  • UIや技術についてもメンター役を呼んでいる

やることはまだ道半ば

  • フロントからやる
    • 特にモバイル系
  • 新しいところからやる
  • 作りなおすところからやる
    • インフラのAWS移行時にAnsibleを導入
  • 採用を強化
    • ブランドイメージを上げる
  • 上層部とイメージを共有する

質問

Q. SlackやQiita:Teamなど有料サービスを納得させるためにやったことは?

    1. 有料よりも外に情報を持つことが大変だった
  • 稟議書を大量に書かなければならなかった→現在は1枚に
  • お金の面は五月雨式に増えていくので、最初はあまり文句を言われなかった

Q. SlackやQiitaはこっそり始めたのか、みんなで使っていたのか?

    1. Slackは外部の人が「イイネ」と言っていた
  • 実感していることは大事

Q. 使いましょうとなった時に、他の人が反応してないとかなかったのか?

    1. メールで来たものをSlackで返してみるとかで取り入れてもらう
  • 若手には「いつQiitaに書いてくれるの?」とプレッシャーかけてみるとか
  • 最近は技術的な人が少なくなってきたので、
  • 100人中20人ぐらいが投稿している
  • イイねしている人が半分ぐらい
  • アイコンがデフォルトのままの人が多かった
    • アイコンの変え方というエントリを書いたりしていた

Q. チャットって感情が伝えづらかったり、後から入った人が入りづらかったりしなかったのか?

  • 元々はMLだった
  • 座席はチームで背中合わせだったので、直接話していた
  • リアルとチャットを組み合わせて使っている
  • 昔は変な席だったが、訴えたら良くなった

Q. 少人数で初めて、チームになったという話だったが、ポシャったりすることなく、社員数名まで説得できるためには?

  • 「新しいことやっといて」というような依頼が来たが、企画だけでやっても実現しなかったので自分で最初は20%ルールみたいな感じで作った
  • 最初のVersionはポシャった
  • 次のVersion(スマホブラウザ版)は当時のアプリがしょぼかったのでイイねという反応をもらえた
  • 1年に1個ぐらいは内製のアプリを作って、伊藤直也さんのアドバイスなどを貰って作っていって広めた

Q. チームが100人とか、外合わせて270人とかチームが大きいが、どういう編成で?

  • 3つのグループ
    • フロント
    • 課金・認証
    • プロモーション
  • 周辺の人
    • 法務
  • 社員自体は60人ぐらい
  • エンジニアは10数人
  • まだまだ駆け出し。最初のシステムの保守とかは外部の人に任せている