こんにちは！ ケップルで VPoE を務めている池浦（ @pr1v4t3_ ）です。
2024年12月19日に日本経済新聞社 CDIO室主催のもと、株式会社アドウェイズ、株式会社ケップル（以下、日本経済新聞社、アドウェイズ、ケップル ）の3社でオンラインイベント「NIKKEI Tech Talk 未来の事業戦略を見据えたシステム改善の最適解を探る」を開催しました。
今回の記事では、イベントの流れをおさえつつ、登壇者それぞれの発表ポイントをまとめてレポートします。「レガシーシステムをどのように改善するか」「技術的負債をどのように解消しつつ持続可能な開発を回すか」といった、多くのエンジニアが日々悩むテーマに対して、各社ならではの視点が示されていて、とても学びの多いイベントになったと感じています。
イベントの概要
開催の背景とテーマ
今回のイベントテーマは「未来の事業戦略を見据えたシステム改善の最適解を探る」です。ここには以下のような狙いがありました。
- レガシーシステムが持つ課題を解消し、モダナイゼーションへと舵を切るためにはどうするか
- システム改善のアプローチを、未来視点や事業戦略との連動を踏まえて考える
- 技術的負債の可視化や、継続的な改善を行うための組織・文化づくり
これらのテーマに沿って、日本経済新聞社、アドウェイズ、ケップルの3社が事例を共有しました。
参加者属性と雰囲気
参加者の属性はバックエンドエンジニアやフルスタックエンジニア、プロジェクトマネージャー、アーキテクト、システムエンジニアが多く、約5割を占めたとのこと。そのほかにもプロダクトマネージャーやインフラエンジニア、セキュリティエンジニアなど多岐にわたり、総じて「既存システムの改善や新規プロダクトの開発を担うエンジニア」が集まっていました。
ここからは主に、スピーカーごとの発表内容を中心にまとめます。
各スピーカーのトーク内容
スピーカーは以下の 3 名です。（トーク順）
- アドウェイズ 大曲 智久 さん
テーマ: 「事業貢献を考えるための技術改善の目標設計と改善実績」 - ケップル 芹田 悠一郎
テーマ: 「技術的負債と向き合うカイゼン活動を1年続けて分かった "持続可能" なプロダクト開発」 - 日本経済新聞社 伊東 洋一郎 さん
テーマ: 「歴史と現在から考えるスケーラブルなソフトウェア開発のプラクティス」
アドウェイズ 大曲 智久 さん – 事業貢献を考えるための技術改善の目標設定と改善実績
最初のスピーカーは、アドウェイズの大曲さん。
事業貢献を見据えた技術戦略の策定
大曲さんは、初めにアドウェイズにおける組織体制と技術戦略の位置づけを紹介しました。同社では、プロダクトチーム（新機能開発）と改善チーム（レガシーシステムなどの技術負債を解消、サービス運用）を切り分けているとのこと。
- 技術戦略
- 会社や事業の戦略を踏まえ、エンジニアとしての行動指針を定める
- 組織メンバーのスキル状況や最新の技術動向を反映し、「どこに技術投資するのか」を選定する
- 指標（KPI）を設定し、半年スパンで進捗を可視化する
- プロダクト技術戦術
- プロダクト戦略×技術戦略を融合させたもの
- PdM（プロダクトマネージャー）にも理解・共感を得ながら、何を優先して改善するかを整理する
- 結果的に「単なる技術改善」ではなく、「どのようにプロダクトの価値向上に貢献するか」を明確にしやすい
たとえば、レガシーシステムとして約20年稼働している広告システムがあるそうですが、単にコードを置き換えるだけではなく、「今後どのようなビジネス展開が想定されるか」を踏まえたイベントストーミングを行い、新たなアーキテクチャを検討しているとのこと。こうした「将来的な事業展開を意識しつつモダナイゼーションを進める」姿勢が特に印象的でした。
改善実績と今後の展望
- トラッキングのモダナイゼーション
既存のPerlベースの広告トラッキングをGolangなどへリプレイスしはじめており、将来の拡張に備えた設計を模索中。今すぐの事業インパクトは出ないが、「いつでも大規模な改修や新技術の導入が可能」という土台づくりが狙い。 - 古い認証システムの刷新
Perl依存だった認証フローをモダンな手法に移行。結果的に管理画面開発の幅が広がり、新しい機能のプレスリリースにもつながった。 - 開発文化の改善（ペアプロ推奨など）
長年積み重なった負債だけでなく、「エンジニア同士がどのように開発を進めていくか」という文化面でも改善を重ねているそうです。リモートワークが多い中でも画面共有しながら5～7時間ペアプロを行うなど、コミュニケーションを強化する取り組みを実施。結果的にレビュー効率の向上や、エンジニアのモチベーション向上が図れているようです。
大曲さんは、「すべてが事業貢献に直結するわけではないが、そこを意識して動くことでより良い結果を引き寄せやすい」と結んでいました。
2. ケップル 芹田 悠一郎 – 技術的負債と向き合う改善活動を1年続けて、分かった持続可能なプロダクト開発
続いてのトークは、ケップルの芹田。スタートアップと投資家向けのさまざまなプロダクトを開発しており、中でもスタートアップや投資家、最新ニュースなどの情報検索サービス「KEPPLE DB」の改善事例を共有しました。
持続可能なプロダクト開発と技術的負債
芹田は、プロダクトが長く使われ続けるためには「将来への拡張性を意識しつつ、負債を解消できる体制づくりが大切」と強調します。
- 技術的負債の解消
リリースペースを上げるだけでなく、負債が増えるリスクを常にコントロールする必要がある。
「借り入れ（大胆な手抜き）」と返済のバランス感覚を養うことが持続可能なシステム開発に繋がる。 - カイゼン活動の立ち上げ
毎週金曜日を負債解消デーとして設定したが、1日で終わらないタスクが多く、徐々にうまく回らなくなってきた。そこで「毎月1週間をカイゼンウィークに充てる」という変更を行った。
これにより、大きなモダナイゼーション（UIライブラリのバージョンアップなど）も計画的に進められるようになった。 - 得られたメリット
- 設計議論が活発化し、新機能追加時のコードがより洗練される
- 技術的負債の総量を把握しやすくなる（可視化される）
- 「必要に応じて素早く借り入れし、後から返済する」流れが確立し、リリースを前倒ししやすくなる
特に3点目の「仮説検証段階での大胆な手抜き」は興味深いポイント。負債を適切に管理できる体制があるからこそ、時には不完全な実装を先行させて早期にリリースし、ユーザーの反応を確かめることができるわけです。こうした柔軟さはスタートアップのサービス開発において大きな強みになりうると考えています。
3. 日本経済新聞社 伊東 洋一郎 さん – 歴史と現在から考えるスケーラブルなソフトウェア開発のプラクティス
最後に登壇したのは、日本経済新聞社の伊東さん。長い歴史をもつメディアプロダクトを維持・拡張する中で、技術的な複雑さがいかに生まれているか、そしてマイクロサービスの原理・原則とどう向き合っているかを解説しました。
歴史あるプロダクト特有の課題
2010年に日経電子版が創刊されてから十数年。モバイルアプリやデータ分析基盤なども並行して作られ、その後もさまざまな新サービスが派生しているため、システム全体は多数のレイヤー・サービスに分割されています。一見マイクロサービスアーキテクチャのようにも見えるものの、「内部の実装を隠蔽しきれていない」「サービス間の仕様変更を統制する仕組みがない」といった問題があるようです。
- 具体的な問題例
伊東さんによると、「チーム内の生産性」が上がったとしても、「チーム間全体」で見た時に大きな負債を抱えるケースがあるとのこと。マイクロサービスの理想的な原理（自己完結、疎結合、明確なAPI仕様など）を満たせていないため、将来的な変更が困難になりやすいと述べていました。
マイクロサービスの原理とプラットフォーム化
そこで重要なのが、仕様を先に決めて実装に先立たせるという考え方。具体的にはスキーマレジストリを活用し、API仕様を機械可読な形で管理しながら、コード生成による横断的な処理を挟むなどが有効といいます。
- 仕様ドキュメントを整備し、マイクロサービス間の約束を明示する
- 仕様ベースでコード生成し、依存関係の把握や変更通知を自動化
- 各サービスは独自技術を使ってもよいが、インターフェースだけは統一する
ただし、歴史ある企業・プロダクトほど、あとからこれを導入するのは困難。かつて便利だった機能を利用者が手放したがらない、既に実装に依存している箇所が多いなど、現実的には段階的な取り組みになるそうです。
それでも日本経済新聞社のエンジニアリング組織では、評価の仕組みや20％ルールなどを取り入れ、こうした中長期的な改善を継続できる環境を整えつつあるとのこと。伊東さんは「大規模かつレガシーなシステムに手を入れるのは大変だが、技術的負債を解消しながら持続可能なサービスへ近づけたい」と締めくくりました。
本テーマのまとめ
3社の事例を一通り聴いて感じたのは、「技術的負債の解消と事業戦略の両立が、いかに難しく、かつ重要か」ということです。各社がそれぞれの立場で次のようなキーワードを強調していました。
- レガシーシステムとモダナイゼーション
- 既存資産をただ捨てるのではなく、将来的な価値を再確認しながら再設計（イベントストーミングやスキーマ定義）していく
- 事業戦略との連動（事業貢献）
- 改善チームとプロダクトチームを分けている例でも、最終的には「事業に貢献するか」が重要
- 改善施策に対して指標（KPI）を設定し、プロダクトのマネージャーやビジネスサイドと対話することで、成果を見える化する
- 継続的な改善（持続可能なプロダクト開発）
- 改善チーム、月1週間、20%ルールなど、明確にリソースを割り振ることで定期的に負債を返済する
- ただし枠に収まらないタスクもあるため、組織規模やプロダクトの特性に応じた工夫が求められる
- 負債を計画的に返済できるからこそ、時には大胆な「借り入れ（手抜き）」でリリースを前倒しし、市場の反応を得られるメリットもある
各社とも目指すところは共通していて、短期的な機能追加・リリースだけではなく、将来のビジネスの成長にも耐えうるシステムを作りたいという姿勢が伝わってきました。レガシーシステムに痛みを抱えているのは珍しいことではありませんが、そこを「どうやってモダン化しつつ、ビジネスに貢献させ続けるか」が、大きなポイントになっているようです。
おわりに
エンジニアなら誰しも「負債が溜まってきて困っている」「レガシーシステムを置き換えたい」「モダナイゼーションへ踏み出すタイミングを逃している」などの悩みを抱えやすいと思います。各社の例が、自分の職場の状況に合う改善策を考えるきっかけとなれば幸いです。
会の後半にはQ&Aやディスカッションも行われ、各社へ多くの質問（KPI設定の人数や期間、どのように維持しているか等）が寄せられました。登壇者の皆さんからもいろいろと具体的な回答が挙がりましたが、最終的には「技術的負債を単なる開発者の都合にしないで、ビジネスの成功に直結させる」という姿勢が重要という結論に落ち着いたように思います。
以上、「NIKKEI Tech Talk 未来の事業戦略を見据えたシステム改善の最適解を探る」イベントのレポートでした。技術的負債やレガシーシステムへの向き合い方に悩むエンジニアの方は、ぜひ各社の事例を参考にしていただき、持続可能なプロダクト開発を実践してみてください。
最後に、各社の採用情報を載せます。
日本経済新聞社のエンジニア採用サイト：https://hack.nikkei.com/
アドウェイズの採用サイト：https://www.adways.net/career/
