社内共通システムをリプレイス
鈴木就斗 氏：それでは「システムリプレイスで事業を変える開発戦略」ということでお話させていただきます。エイチームのグループ会社である株式会社エイチームフィナジーの鈴木就斗です。ちなみにみなさん、エイチームという会社を知っていますか？ 聞いたことある方は手を挙げてほしいんですけど……。
（会場挙手）
ありがとうございます。パラパラいらっしゃいますね。その中でエイチームがどういう事業をやっているかをご存知の方はいらっしゃいますか？
（会場挙手）
やっぱり、けっこう少なくなりますよね。本日お話しするのはエイチームグループの中でも金融メディア事業で運営しているWebサービスのお話をさせていただきます。
金融メディア事業は、5年ほど前にサービスを開始しました。今ではグループの中でも大きな売上を誇るなど、非常に成長しているサービスです。それだけやっていると、いろいろな問題が出てきます。
Webサイト上にコンテンツを掲載しているんですけど、提携事業者様の詳細な情報は正確に管理・更新することがシステムの完全性の1つになってきます。それが管理画面上でいったい何が管理されているのかが正直わからない。担当者がどんどん入れ替わっていって、よくわからない仕様や誰も知らない画面などがどんどん出てきてしまっている。
そのうえ使われている技術も古いものを使っているなど、メンテし続けることにコストが掛かってしまう状況になってしまいました。
こういう状況は一定期間サービスを運営していれば、他の企業様でもよくあることなのではないかと思います。
「Webサイト上のどこに何が書いてあるのか分からない」「管理画面上で何を変更したらどう変わるのか、誰も知らない」といった状況になっていました。テンプレートファイルがすごくたくさんあるんですけど、Webサイト上の表記を修正するためにデザイナーがそれを片っ端から探していって、夜遅くまで残業することも何度かありました。
果たして、このシステムをこのまま保守し続けるべきなのかを考えたんですけど、エンジニアの問題はエンジニアが解決しないと変わらないんですよ。システムに問題があるんだったら、エンジニアがシステムを変えないと事業が変わっていかないんです。
リプレイスする上でのポイント
そこで今回、事業上の問題を解決するために私たちはシステムリプレイスという決定をしました。本日はいかにしてコードを自分たちの手に取り戻したかをお話します。リプレイスについては、話したいことはいろいろあるのですが、今回は赤字の社内共通ライブラリについてお話をします。
今回リプレイスをする上でのポイントは大きく2つありました。1つは成長したサービスであるということ。つまりできるだけ失敗したくない……失敗したい人なんていないと思うんですけど、失敗したくない。
もう1つは人員・期間に限りがあるということです。実際、リプレイスチームは最初は自分1人だけで、そこから人が増えて2～3人のチームになったんですけど、そこで既存の事業の運用と一緒にやりながらリプレイスを行っていたので、基本的に人手が足りない状況になっていました。これも人が足りないことは他の企業様でも一緒なのではないかと思います。
ですが、そんな中でもシステムに問題があるので、システムを変えて事業を変えたかった。失敗のリスクをできるだけ小さくして、少ない人員でリプレイスを行っていきたかった。
そして今回システムリプレイスのカギを握ったのが共通システムの存在でした。5年前にサービスを立ち上げたあと、事業が成功したため、同様のビジネスロジックを持つさまざまなサービスを展開していきました。異なる事業・異なるシステムでもWebサイト上に掲載するコンテンツなどのビジネスロジックは類似していました。
次々に事業が立ち上がっていく中で、共通する処理をどう扱っていくのか、ビジネスロジックをこのままどんどん増やしていっていいのか、実際にいろんなやり方の試行錯誤がありつつ、最終的に1つの結論にたどり着きました。
それが社内ライブラリ群の開発と運用です。Ruby on RailsでそれぞれのWebサービスを開発していって、その中の共通するビジネスロジックをRuby gemのライブラリとして各サービスにインストールして利用するという開発の戦略を取りました。
ここ数年、弊社の中では複数の新規事業で共通する処理をRuby gemライブラリとして開発しています。ライブラリには何が入っているかというと、例えばWordPressのようなCMS（Contents Management System）、Webサイト上に表示するコンテンツを管理するシステムを社内製で開発していくイメージです。
今回リプレイス対象となったシステムが、そもそもPHPで開発されていてこのライブラリが使えない状態で、使いたいと思っていました。
ここでRuby on RailsのプロジェクトとRuby gemのライブラリの棲み分けについて簡単に説明します。この図のようにプロジェクトの本体とRuby gemのライブラリがあったときに、汎用処理というのはRuby gemのライブラリが……例えば社員が使うための管理画面はどの事業でも一緒なので、ライブラリ側で開発します。逆に事業ドメインに特化した処理、お客様に見せる画面はどの事業でも基本的には変わってくるので、こういうものはプロジェクト側で実装していきます。
社内ライブラリ群は「みんなで作る」
ここからはこういうライブラリを具体的にどのように開発していったかをお話しします。社内ライブラリ群は「みんなで作る」が成功のカギだと思っています。弊社はライブラリの開発に専属のチームはいません。各事業組織の担当エンジニアが権限を持っていて、必要な機能を適宜開発していきます。
具体的には、まず「みんなでコードレビュー」。まず事業のエンジニアがある機能を開発したら、別の事業組織のエンジニアにレビューを依頼していきます。こういったことが普通に行われています。こうするとコードが各プロジェクトメンバーに知り渡っていって、特定の人しか仕様を知らないといった事態が起こりにくくなります。結果、1人の人が仕様を把握していなくても「この機能だったら〇〇さんと〇〇さんが詳しい」のような状態になります。
そして「みんなで機能追加」。Ruby gemのライブラリというのはインストールをすれば動くんですけど、当然新規機能がほしいとなったら追加の開発をしないといけません。たとえば「管理画面にあの表示がほしい」とか「このボタンがほしい」とか、そういったイメージです。
この機能追加にはプロジェクトの上位側で実装するか、ライブラリ側で実装をするか2択の選択を強いられます。より汎用的で他のプロジェクトにも利益をもたらす内容であれば、積極的にRuby gemに実装していくことで多くのプロジェクトがその機能を追加できるんですけど、一方でRuby gemライブラリの開発は抽象度が高いですし、普通のRailsでWebサービスを作っていくよりも若干難易度が高くて開発のコストも掛かってくるものになってきます。
「この機能だったらプロジェクト側に実装して早くリリースをしたほうが良いかな」とか、「この機能だったらRubyのライブラリ側に実装して他のプロジェクトに展開したほうが恩恵があるよね」とか。どちらに実装しても間違いではないんですね。
ですけど、他の事業組織からさまざまな機能追加が実際に行われていって、結果的にそのライブラリをみんなで成長させていくことができます。
そしてこれらのライブラリを数年掛けて開発をしてきた結果、ライブラリを用いて既存のPHPシステムをRuby on Railsにリプレイスすることに成功しました。参考としてリプレイスにどれだけライブラリを開発したかを見ていきますが、スライドのグラフがリプレイスの前と後との各Webシステムのモデルクラスに実装されているコードの行数の比較です。
もちろんPHPとRubyでは言語も違いますし、フレームワークも違いますし、実際にリプレイスで必要なくなって消したコードとかもあるんですけど、既存のシステムには1万行を超えるモデルクラスがあったんですけど、リプレイス後のシステムでは10分の1以下にすることができました。
じゃあ、削除したコードはどこにいったかというと、共通システムであるライブラリの中に行ったわけですね。みんなで開発してきた社内ライブラリを活用することで、多くの処理を他の事業と共通化して、結果少ないコードの実装でシステムのリプレイスを実現しました。
共通システムは、使う人「みんな」で作る
リプレイスするポイントは2つあったんですけど、いずれも「社内ライブラリをみんなで開発していった」ということによって、システムのリプレイスが成功しました。既に他の事業で実績のある枯れたライブラリなので、不具合や想定外の挙動は少なかったです。リプレイス専属のチームは限られた人員であっても、リプレイスを成功させることができました。
リプレイスをすることでコードを自分たちの手に取り戻すことができました。実装がわからない機能などが、リプレイスされて今のメンバーで仕様を把握できるようになりました。
ライブラリをみんなで開発しているので、事業組織を超えて、みんなが仕様や中身を把握できるようになりました。当然、使用している技術も新しくなって、メンテできる人が増えました。
まとめますと、エンジニアの問題はやっぱりエンジニアが変えないと変わらないです。なので技術を変えることで問題を解決できるならば、エンジニアがまず最初に動き出しましょう。そこで「使いたい技術が使えていないよ」とか、今使っている技術が古くていろいろ問題が起きているならば、どうやったらリプレイスができるか、使う方法はないかを考えていきましょう。
そして共通システムというのは使う人「みんな」で作ることが成功のカギです。つまり、あなたが作るんです。
以上、株式会社エイチームの鈴木就斗でした。ご清聴ありがとうございました。
（会場拍手）
