リアーキテクチャことはじめ～事業成長を最大化するための技術選定と登り方～
https://flexy.connpass.com/event/259853/
に参加してきたので、そのときのレポートです。
レガシーの定義とは？
今回のレガシーの定義では
と定義します
ここで大事なのが４で、簡単な機能追加に時間がかかってしまうことがある。
そこで、リアーキテクチャが必要になってくるが、
単に「このシステムは今ここがよくないのでこうすべき」というのは誰でも言えるが
将来の事業成長や拡張性を見据えてどうするか、ということも考えられるのが必要になる。
そこで、今日はリアーキテクチャをどのようにやってきたとかの話を事例を交えてする。
各社サービスの背景からみるリプレイスの事例
事例1
バージョンアップしたいが、なかなか難しく、負債が高まっていっていたため、リプレイスを検討した。
リプレイスを検討していると
現状のシステムを分析した結果、複数の境界線を跨っていることがわかった
そこで、記載しているような設計にした。
稼働年数10年とあるが、システムをリプレイスするのは稼働年数と同じくらいかかる。
今1.5年ほどリプレイスを進めているが、まだ序の口。
とある業務フローがあり、
伝統的なシステムだと、とあるデータを同じデータとして扱いたいが
業務フローを精査してみると、違うデータとして扱う必要がある。
例えば、セブンイレブンにあるお弁当とかは、全部同じものではなく、店舗によって近い工場で造られている
お弁当の申請をするとそれはパートナーが登録したデータだが、申請されたデータを承認するのは別の工程で行う。
それを処理するには、申請されたイベントから派生させて行うのが良いとなり、そうしている。
事例2
最古の commit が 2012 年だが、それ以前にも何かあったらしい。
一番社歴が長い人でも5年前で、その人に歴史を確認しながら進めることもある。
中身を見ていると、名前がおかしなものもちょいちょいある。
改修の際に調査が長引いてしまいデリバリーが遅くなることがあり、リプレイスを検討した
1日30分くらいつかって地道にLaravel に載せ替えることもしていたが、長続きせず頓挫することもあった
現在は本腰をいれてリプレイスを進めている。
いま進めているリプレイスも何年かかるか分からないが、進めている状態
リプレイスする際に、ちゃんと技術選定していかなければならない。
Rust を採用した理由は？と聞かれて「流行ってたからです」となると
未来で困る人がその理由は聞きたくないだろう。
事例3
読み取りと書き込みは別要件なので、それぞれ別個に最適化したような設計をした
事例4
内部事情を知らないといけないので、入った人が戦力になるまで時間がかかる
コードベースでモジュラーモノリス化した
事例5
マイクロサービスアーキテクチャ化をすすめている
マイクロサービスアーキテクチャにするとビジネスが推進されますよという見出しの記事がよくあるが
それを行うには何年単位という時間が必要になる
ドメインを分析したり、業務フローを精査したりなんなら業務フローを変えたりする必要もある
もろもろ全部考えた上で、決断する必要がある。
なんのためにマイクロサービス化するのか、技術ファーストではなく、ビジネスのためにどうするのか、というのを考える必要がある。
Q&A
Q1
リプレイス後のアーキテクチャはどのように決められましたか？トップダウン、ボトムアップなど。また、ボトムアップの場合で、メンバー間で意見があわない場合はどのようにアーキテクチャを決定されましたか？
A1
あらたまさん
トップダウンだった
現場で、どうすればいいか分からないという状態だったので、トップダウンで行った
また、リプレイスというのは向こう数年にわたって投資をしていくという判断なので、経営判断が必要になる
のでボトムアップだけだとうまくいかないと思う。
経営的に、いまここに投資するべきか、という判断をしている
ytakeさん
トップダウンだけでいくというのはあまりやっていない
メンバー間で意見が合わないばあい
スキルセットが合わない人ももちろんいるので、ディスカッションはする。
が、技術レベルを下げることはあまりしない。そこを下げてしまうと、周りが面倒をみる必要が出てくるし、会社の技術レベルが下がってしまう。
ので、習得してもらうようにしている
Q2
言語やフレームワークを大きく変更したとき、メンバーに対するキャッチアップはどのように実施されていますか？（ex. 週1で学習時間を設けているなど）
A2
あらたまさん
輪読回をしたりしている
ytakeさん
技術習得が難しい人もいるし、本だけだとわかりづらいところもあるので、質問があれば自分が噛み砕いて答える、ということをやっている
エンジニアだけに限った話じゃないが、技術習得のアップデートというのは当たり前ではあるので、そういうのを自主的にやっていけると良い
Q3
リプレイス中に仕様変更がある場合、どのように取り込んで開発していますか？
A3
あらたまさん
リプレイス中の使用変更はブロックするようにする
ytakeさん
やらないといけないことあやるようにしている
Q4
退職者が多いことによる辛み=技術的負債とした時に、リプレイスに時間が数年かかるとなると今作っているものを以下に負債にしづらくするかというのが大事だと思っています。そこに対する取り組みとかありますか？(ドキュメントは工数がかかりすぎたり、陳腐化する懸念がありどう考えているか伺いたいです)
A4
あらたまさん
ドキュメントはコンフルエンスとかにたくさん書くだけではなくて、コードコメントとかも大事なドキュメント
細かくドキュメントを残していけるかが、システムの寿命にもなると思う
ytakeさん
陳腐化するのか防げないので、定期的に確認する必要がある。
書いた人の考えていることの一部を読んだ人が得られるので、劣化した情報が伝わっていくので陳腐化は防げない
ので、定期的にメンテナンスする必要がある。
まとめ
ytakeさん
作るものだけを考えるのではなく、技術ファーストではなくビジネスのことも考えよう
あらたまさん
サービスや事業に対する理解を社内の人とたくさん話をして解像度を上げていく必要がある
自分の考えた最強のシステムを作りたくなる気持ちもあるが、そこを抑えて考えていく必要がある
参加しての感想
イベントの中でも出てきましたが、リプレイスはしなくて良いのであればしないほうがよく
日頃の業務の一部をリプレイスに投資するという判断をしなければならないので
ある程度ストレスがかかることもあると思います。
また、リプレイスをするというのは現状の負債と立ち向かうものなので、作業自体にも結構な負荷がかかると思います。
全体的にですが、そんな話を笑いも交えながら話をしてくれてとても安心しながら聞けました。
また、リプレイスは単発で終わるものではなく、数年かけて行うこともあるので
何をどうするということをしっかり決めたり、どういうプロセスでやっていくのかという計画を立てたりすることが重要だとあらためて感じました。
何度か出てきましたが、技術ファーストで考えるのではなくビジネスのことも考えていこうというのはとてもうなづけました。
いまのレガシーなシステムでつらいことを感じることもありますが、それだけの理由でリプレイスしたいというのは目線が自分に向いているので、ビジネス目線でどうなのか、ユーザー目線でどうなのか、ということまで考える必要があると、改めて感じました。（つらいのを許容するべきという意味ではない）