ソーシャル経済メディア「NewsPicks」の運営・開発を行う株式会社ニューズピックスは、近年、DX(Developer Experience:開発者体験)の向上に注力しています。CPO、CTO、VP of Eと、3名のエンジニアがボードメンバーに名を連ねる同社のDXへのこだわりは徹底しており、「DX向上」は経営における重要項目としても取り扱われています。
背景にあるのは、エンジニア組織をスケールさせる、という強い意思。近年、同社の開発組織は著しく拡大していますが、今後、さらにエンジニアを迎え入れるためには、良質なDXが得られるシステム、組織であることが不可欠だと考えているといいます。では、肝心要のDX向上はどのようにデザインされ、実行されているのでしょうか。
本稿の読者も含め、世のエンジニアの方々に向けて同社のDXをプレゼンテーションし、応募を促進するべく、CTOの高山温さん、そして最前線でDX向上にコミットするエンジニアの武藤雅幸さん、桐畑数寿さんに、DX改善のデザイン、システム改修、マイクロサービス化、そして組織文化をキーワードに、同社の描く「良好なDX」の具体的な姿を語ってもらいました。
※ この記事は、株式会社ニューズピックス、およびホールディングカンパニーである株式会社ユーザベースによるSponsoredContentです。
- 「デプロイ回数を3倍に増やす」というCTOの宣言
- 2時間かかっていたデプロイ作業が、“Botに話しかけるだけ”で済むように
- 課金システムをマイクロサービス化し開発効率を向上させる
- サービスの“核”を中心に設計し、他の部分は交換可能にする
- アイデアや技術を持っている人が、思う存分活躍できる環境
- ■ Amazonギフト券500円分が当たるプレゼントのお知らせ!
「デプロイ回数を3倍に増やす」というCTOの宣言
──高山さんが2020年2月にCTOとして就任された際に、前任の杉浦正明さんから最初のミッションとして「DX Criteria*1を参照し、DX向上を実現すること」を託されたとお聞きしました。DX Criteriaは日本CTO協会の発行している指標で、「ソフトウェア開発のベストプラクティスに沿った組織になっているか」を複数の項目で測定するものです。なぜ、この指標の改善が重視されたのでしょうか?
高山 ニューズピックスの開発組織の変化が影響しています。ソーシャル経済メディア「NewsPicks」が誕生したのは2013年で、そこから5年ほどは少数精鋭のエンジニアで開発を続けてきました。しかし、直近2~3年ほどはサービス改善の速度を向上させるため、エンジニア採用を加速し、10人ほどだったエンジニアが一気に50人ほどに増えたのです。
エンジニアの増加は喜ばしいことですが、一方で徐々に課題も出てきました。また、システムに蓄積した技術的負債や運用における属人性など、恒常的な課題もあり、改善すべき部分がたくさんありました。
こうした課題を解決し、今後さらに開発組織が拡大したとしても、開発効率を落とさずエンジニアが快適に働ける状態をつくることが、なによりも重要だったのです。それにあたり、開発組織の改善度合いを定量的に測る指標があったほうが的確に組織改善を進められると考え、DX Criteriaを用いることを決めました。
──DX改善のため、ニューズピックスではどんな施策に取り組みましたか?
高山 私がCTOに着任してすぐに取り組んだのは、デプロイ回数の計測でした。デプロイの頻度は企業ごとに大きな差があります。半年に1回しかデプロイしない企業もあれば、1日に何十回もデプロイしているところもある。どのようなプロダクトをつくっているか、あるいは企業文化の違いなども影響していますが、効率の良いデプロイができている企業とそうでない企業とでは、その回数に指数関数的な差が生じます。
そして、デプロイに関連する業務はサービス改善や開発者体験に大きく影響します。デプロイ頻度が増えることでPDCAサイクルを高速で回せますし、一度のリリースに含まれるコード修正が少なくなるため障害発生数やエンジニアの負担も減る。デプロイ改善がさまざまな改善の起点になってくれるのです。そこで、全社的に「デプロイ回数をこれまでの3倍に増やす」というアナウンスをしました。
武藤 高山から宣言があったとき「よくぞ言ってくれた」と思いましたね。以前から私もシステム運用における多くの課題を感じており、自発的にさまざまな改善を進めていました。そんななか、高山がCTOに就任してDX改善を目標として掲げたことで、会社としての方針と自分の目指していた方向性が重なった。水を得た魚のような気持ちになりましたね。
2時間かかっていたデプロイ作業が、“Botに話しかけるだけ”で済むように
──武藤さんの取り組んできた施策についてご説明ください。
武藤 私が入社したのは、高山より前の2018年冬です。その頃のニューズピックスでは属人性の高いシステム運用が行われていました。例えば、Linuxサーバーにインストールされている各種ミドルウェア・ライブラリのバージョンアップや、アプリケーションのデプロイ作業などが手作業で実施されていたのです。入社当初からなんとかして改善したいと考えていました。
2019年にまず着手したのはAWS CDKを用いたインフラ管理のコード化の推進です。さらに、アプリケーションのビルドからデプロイまでのプロセスでAWS CodeBuildとAWS CodeDeployを用いる形に変え、エンジニアが手作業でオペレーションする必要がなくなりました。
──高山さんの就任後である2020年からは何に取り組みましたか?
武藤 デプロイ可能な時間の制約をなくすことです。かつて「NewsPicks」には午前中にデプロイできないという制限がありました。午前中はAmazon EC2上でデータ集計のためのバッチ処理が動いているのですが、デプロイするとモジュールが上書きされバッチのプロセスがkillされてしまうためです。さらに「NewsPicks」にはプッシュ通知の機能があるのですが、その処理の最中もデプロイできないという制約もありました。
──なぜでしょうか?
武藤 ブルーグリーンデプロイメントを行っていることが、プッシュ通知中にデプロイできない一番の原因でした。プッシュ通知時には、負荷対策のためにサーバー台数が増えます。さらに、ブルーグリーンデプロイメントはその特性上、ブルーとグリーン両方のサーバーを用意するためサーバー台数が通常の2倍になります。これらの要因からデータベースへのコネクション数が増えてしまい、パフォーマンスに課題が生じるのです。こうしたデプロイの制約をなくすために、アーキテクチャ改善を行いました。
──改善した内容をそれぞれ教えてください。
武藤 午前中にデプロイできない制約は、バッチ起動時の処理を工夫することで解決しました。現在は、バッチ起動時にモジュールを特定のディレクトリにコピーし、コピー後のプログラムを用いて処理を実行する流れになっています。そのため、もしもバッチ処理中にデプロイを行っても、実行されているプログラムには影響せずプロセスもkillされません。
プッシュ通知中にデプロイできない問題については、ブルーグリーンデプロイメントではなくローリングアップデートを用いる形式に変えることで対処しました。ローリングアップデートならば、デプロイ中にデータベースへのコネクション数が激増することはないので、プッシュ通知中でも問題なくデプロイ可能になりました。
また、現在はデプロイ作業そのものをChatOps化しており、Slack Botに特定のテキストを含めてメンションするだけで、デプロイの自動実行が可能です。かつ、デプロイ後にはE2Eテストが自動的に走るようになっており、テスト結果もSlack上で通知されます。つまりデプロイ作業を行う場合でも、エンジニアの時間はほとんど奪われません。
──デプロイの煩雑さが大幅に解消されていますね。
桐畑 かつて手作業によるデプロイを行っていたときは、エンジニアが2時間くらい拘束されていました。その頃と比較すると、デプロイプロセスは相当に改善されましたね。
ニューズピックスのDX向上をともに進めてくれるエンジニアを募集中
課金システムをマイクロサービス化し開発効率を向上させる
──他にシステム改善のために取り組まれたことはありますか?
桐畑 課金システムのマイクロサービス化が挙げられます。前提として「NewsPicks」が立ち上がったばかりの頃はiOSアプリのみでサービスを提供しており、課金の仕組みも月額プランしかありませんでした。ですがAndroidアプリやWeb版が追加され、年割や学割など課金プランなどが増えていく過程で、課金まわりのロジックが徐々に複雑化していったのです。
課金処理とそれ以外の処理が密結合になっており、かつ何年にもわたり継ぎ足しで改修が行われたため、いわゆるスパゲッティコードの状態でした。その状態を解決するために、課金システムを単体で再実装して、「NewsPicks」本体のシステムとは疎結合なマイクロサービスにするプロジェクトが立ち上がったのです。ロジックの全体的な見直しを行い、より適切な設計を用いることで改修が容易なアーキテクチャへの刷新を目指したんです。
──マイクロサービス化にあたり、プログラミング言語やフレームワークは何を選定しましたか?
桐畑 「NewsPicks」本体はJavaで実装されていますが、単体で切り出した課金システムではKotlinを用いました。フレームワークは本体側と同様にSpringを採用し、O/Rマッパーなど一部のライブラリを変えています。Goで実装する案もありましたが、課金システムの開発に割ける人的・時間的リソースに限りがあったことから、開発効率を考えて本体側と同じJVM言語を用いる方針になりました。
──他に工夫した点はありますか?
桐畑 トラブルなどが生じた場合を想定して、新システムから旧システムへと容易に切り戻せるように本体側のコードを事前に整備しています。もともとのシステムは課金処理とそれ以外の処理が密結合になっていたのですが、特定のインターフェースに課金まわりの処理を集約させることで、システム切り替えの影響を最小限に抑えています。
──マイクロサービスでは、API呼び出しに失敗した場合などにデータ整合性をどう取るかも重要です。
桐畑 現在は、万が一データの不整合が生じた場合に、復元させるためのバッチが30分ごとに稼働しています。「NewsPicks」本体側で購入処理のキャッシュを保持しており、キャッシュ情報と課金システム側のデータに差分がないかをチェックしています。マイクロサービス化したことで、課金システム単体で機能修正やデプロイが可能になり、開発効率が圧倒的に向上しました。
サービスの“核”を中心に設計し、他の部分は交換可能にする
──他にマイクロサービス化されている機能はありますか?
高山 課金サービスだけではなく、レコメンド機能もマイクロサービス的なつくりになっています。レコメンド機能は機械学習などを活用する必要があるため、データストアはAmazon SQSやAmazon Kinesisなどを採用し、プログラミング言語はPythonを用いてシステムを構築しています。
「NewsPicks」本体側のシステムがレコメンド機能を使用する場合には、学習時にAmazon Kinesisへログ情報を送り、推論時にWeb APIを呼び出すつくりになっています。レコメンド機能はこれまで、システムのパフォーマンスを向上させるため、何度かアーキテクチャ変更を行ってきました。
──どんな方法で改善をしてきたのですか?
高山 システムのさまざまな数値をモニタリングし、どの箇所がボトルネックになっているのかを発見しながら、アーキテクチャ改善を継続してきました。最も大がかりだったのは、推論処理でしょうか。従来、AWS LambdaとAmazon DynamoDBを利用していましたが、これをAmazon ECSとMySQLを用いる設計に変えています。
──コンポーネント修正の意図について教えてください。
高山 レコメンド機能で実施されている機械学習の推論処理では、大量のベクトル演算が必要で、かつ膨大な量の演算結果データをデータストアに格納する必要があります。このまま「NewsPicks」のユーザー数が増加していけば、将来的に1日で処理しきれなくなることが想定されました。さらに、この処理は毎日実行されるため、設計の見直しを行わなければ運用に支障が出てしまいます。
ボトルネックになっていたのはデータインサートの部分で、Amazon DynamoDBは大量データの一括書き込み処理を苦手としていたため、全データを投入し切るまでに時間がかかっていたのです。ここをMySQLで代替することでパフォーマンス改善につながることが見えてきました。
──AWS LambdaからAmazon ECSへの変更は、どのような意図で行いましたか?
高山 MySQLを用いる場合、数時間かけて推論処理を実行しつつ、できあがったデータを順次データベースにインサートしていく方針で設計を進めました。この場合、実行時間に制約のあるAWS LambdaよりもAmazon ECSの方が適しているだろうと考えたのです。
──システムを常に改善していこうとするニューズピックスの社風がうかがえますね。
高山 私はシステムのアーキテクチャ設計において「長期間変わることのない、システムの“核”となる要素を設計の中心に据えて、その他の要素は取り替えが容易な状態にしておく」という考え方を大切にしています。そうすることで、システムの堅牢性を保ちながら高速に改善を進められる、変化に強いアーキテクチャになりますから。
武藤 私が担当しているSREの業務でも、全く同じことが言えますね。余談ですが、私たちは今、「NewsPicks」本体を動かすためのサーバーを、仮想マシンからコンテナへと移行するプロジェクトを進めています。
このケースで言えば、アプリケーションにおいては「どんなロジックが動いているか」こそが核であり、「どんなインフラで動いているか」は取り替え可能な要素です。アプリケーションとインフラとの結合度を疎にしておき、インフラに依存せずどんな環境でも動かせる構造にしておくことは重要だと思います。
ニューズピックスのDX向上をともに進めてくれるエンジニアを募集中
アイデアや技術を持っている人が、思う存分活躍できる環境
──最後に読者であるエンジニアの方々に対して、ニューズピックスの開発組織に参画する醍醐味を教えてください。
高山 私は常々、開発組織の総合的な技術レベルを向上させるには、誰かが明確な指針を打ち立てて、全員がその方向に向かって走っていく必要があると考えています。もしも各メンバーが向いている方向がブレてしまうと、組織の力は最大化されません。特定のビジョンに向けて数年単位で注力し続けるからこそ、確固たる技術力が会社に蓄積されていくわけです。
その体制を実現するには、CTOのような旗振り役が「自分たちはこの領域に注力します」と宣言して、全員が向かうべき方向性を示す必要があります。今回お話ししたなかでいえば、デプロイ頻度の向上がそれです。
こうした積み重ねによって、開発組織全体の技術力は底上げされていきます。今後も変わらず、なにが普遍的で重要な要素なのかを見極めながら、CTOとして開発組織全体を改善するための活動を続けていきます。そして、改善を実現しえる開発体制が整ってきていることが、現在のニューズピックスに参画する醍醐味だと思います。
桐畑 現在のニューズピックスは企業として非常に勢いがあります。2021年2月に行われた、グループ母体である株式会社ユーザベースの12月期・通期決算説明会では、2022年から毎年30%の売り上げ成長率を目指すことが発表されました。企業としての成長ステージで、技術を活用しながらビジネスに貢献していけるのは、エンジニアにとって魅力的なポイントです。
──ビジネスへの貢献意識の高さは、今日のみなさんのお話からも感じられました。
桐畑 ニューズピックスはビジネスサイドとエンジニアの距離感が近く、かつボトムアップ的にさまざまな施策を実施しやすい環境だと感じています。もちろん、私自身も、ビジネスサイドと一緒に仕事をすることが多いです。いま携わっているアプリの解約率を下げるための施策を検討・実施しているプロジェクトも、「ビジネスサイドとエンジニアの密接なコラボレーション」の一例です。
このプロジェクトは、部署やユニットの垣根にとらわれず有志が集まって推進されていて、参加メンバーが意見を出し合いながら、解約率を下げるためのさまざまな方法を検討しています。プロジェクトを通じて新しいプランが生み出されたり、プランの登録導線の改修が行われたりと、いくつもの改善案が実施されています。
エンジニアは決して「開発するだけ」ではなく、より良いサービスにするためにプロダクトオーナー的な動きもできるわけです。これは、エンジニアに裁量が小さい会社や縦割りの組織になっている会社、誰かが策定した仕様を実装するだけの体制では、味わえない魅力だと思います。
──エンジニアの裁量の大きさは、ニューズピックスの大きな魅力ですね。
武藤 ニューズピックスは全体的にボトムアップな気質があります。実際、エンジニアが考えたアイデアが、プロジェクト化するケースもかなり多いと感じています。私自身も過去に自発的に改善案を出したことがきっかけで、プロジェクト化した事例もたくさんあります。課金システムの改善がその好例です。
かつて「NewsPicks」のシステムでは、クレジットカードで課金した人が誤ってApp内課金をしてしまうようなケース、いわゆる二重課金の検知を強化せねばならない状況がありました。ユーザーに大きな影響を与える部分ですから、精度の高い検知システムが絶対に必要だと考え、迅速な対応を私が提案し、実際に改善にいたっています。
このように、指示のあったものをただ開発するだけではなく、システム改善のための施策を自発的に提案して、サービスを向上させる醍醐味を味わえる。スキルの高いエンジニアにとっては面白い環境でしょうね。良いアイデアや技術を持っている人であれば、思う存分力を発揮でき、事業を前進させていけるのですから。
■ Amazonギフト券500円分が当たるプレゼントのお知らせ!
※アンケート、プレゼントは終了いたしました。たくさんのご回答、ありがとうございました。
この記事を読んでアンケートにご回答いただいた方の中から抽選で40名様に、Amazonギフト券500円分をプレゼントします。アンケートは全部で7問、所要時間は約1分となりますので、以下の応募要項をご覧いただき、ぜひご応募ください!
■応募期間
・2021年4月26日(月)から2021年5月17日(月)まで
■賞品と当選人数
・Amazonギフト券500円分×40名様
■応募方法
・以下のアンケートにご回答ください
・※はてなアカウントをお持ちでなくても応募できます。
■ 抽選と発表
・応募期間終了後に厳正な抽選を行い、当選ユーザー様のメールアドレス宛に送付先情報等を確認するメールをはてなからお送りします(取得した情報は本賞品送付用途以外には使用いたしません)。なお、送付先は国内に限らせていただきます
・発表は賞品の発送をもって代えさせていただきます
Amazon.co.jp は、本キャンペーンのスポンサーではありません(株式会社はてなのキャンペーンです)
Amazon、Amazon.co.jp およびそのロゴは Amazon.com, Inc. またはその関連会社の商標です
[SponsoredContent] 企画・制作:はてな
取材・構成:中薗 昴
撮影:小野奈那子
*1:DX Criteriaは日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドライン。5つのテーマ×8カテゴリー×8項目のチェックリストで構成されており、合計320個の観点から詳細にDX進捗度を評価できるのが特徴。