【b→dash #11】b→dashにおけるリファクタリング、1年後に差が出る運用保守３つのポイント

b→dashの導入・運用に対してお悩みをお持ちの  マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。

第11回は、「b→dashの導入、ようやくちょっと一息ついたなぁ」という方に向け『b→dashにおけるリファクタリング* 1年後に差が出る運用保守３つのポイント』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。
*リファクタリング：外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること

1年後に差が出る運用保守のポイントを解説するにあたり、本ブログのサムネイルにもなっている「リファクタリング」について説明していきます。

そもそも「リファクタリング」とは、外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること、などとGoogleを検索すると解説されています。

みなさま、『ハウルの動く城』という映画をご存知でしょうか？（ちなみに私は観たことがありません）。システム開発を行っていると、あのハウルの動く城のようなシステム（細い足腰に対して不安定でいびつな上層部）ができあがることが往々にしてあります。特に、最近のWEBサービスの多くは、初期にコアとなる機能を実装し、その後ユーザーの要望に応える形で機能を充実させていくことが多いため、悪く言えば「継ぎ接ぎ（つぎはぎ）だらけのシステム」になりがちなのです。また、外資系のツールにありがちなのが、コア機能の周辺機能をM&A（合併・買収）によって補完していくケースです。この場合も継ぎ接ぎだらけのシステムになりがちです。

こうなってくると何が起きるかというと、「どっかをいじったらあっちこっちでエラーが起きる」みたいな事件です。どこのコードの修正がどこのコードに影響を与えるかなどがわからなくなります。また、開発当時にいたエンジニアが退職してしまっているケースもあり、「このコードは一体何をするためのコードなんだろう...」ということも起こりえます。

そこで必要になるのが「リファクタリング」です。主な目的は、（１）コードの可読性向上（誰もが理解しやすいコードにするための変更）、（２）冗長なコードの削減（必要以上に長たらしい記述をされたコードや、重複しているコードの削除や簡潔化）、（３）設計の改善（より良い設計パターンやアーキテクチャ（構造）に変更）、（４）技術的負債の返済（後回しにされてきた改善点の処理）、などです。机の中の引き出しを整理整頓するようなイメージです。

これと似たような役割を果たすのが「マイナーアップデート」です。よくスマートフォンのアプリで「最新のバージョンがあります。更新してください」みたいに出てくるあれです。目的としては、小規模な機能追加やバグの修正、パフォーマンスの改善などがあります。リファクタリングとマイナーアップデートは、それぞれソフトウェア開発において重要な役割を果たしますが、その目的とアプローチが異なります。

少し前段のお話しが長くなってしまいましたが、それではb→dashにおけるリファクタリングを見ていきましょう。

b→dashを長く活用する上で考えなければならないのが、『増え続けるデータ量』です。

b→dashには、基本的には2種類のデータが存在します。1つ目は、『ビジネスデータ（Bizデータ）』と呼ばれる、企業が基幹システム上で保持している顧客データや売上データなどです。2つ目は、『WEBデータ』と呼ばれる、企業が持つWEBサイトの閲覧データです。

前者については、大企業になればなるほど大量のデータを保持しています。特に、店舗のPOS（レジ）データや、クレジットカードなど生活において日々何回も利用される取引データは、億単位のレコード量*となり、そのデータ容量はペタバイト*を超えます。
*レコード：データベース内のテーブルを構成する単位のひとつで、一行分のデータを指します。顧客データであれば1人1レコードが基本で、売上データであれば、1人に対して複数の売上データのレコードが存在します。
*ペタバイト： 1,000テラバイト（=1,000,000ギガバイト）

後者も同様に、大人気のメディアサイトなどでは、WEBデータの量もとんでもない量となります。例えば、人気経済メディアNewsPicksは月間4億PV*を超えると言われており、年間では50億PVにも及びます（b→dashにおいて、1PVは基本的には1レコードなので1年間で50億レコードのデータが生まれるということです）。
*PV（ピーブイ）：ページビュー=ページの閲覧数

以上のように、このような膨大なデータをb→dash内ですべて毎日・毎回処理をしていたらとてつもなく時間がかかってしまいます。そのため、1レコードあたりのデータ量を削減したり、使用するレコード量を削減したり、不必要なデータを削減する処理を組むことが求められるのです。

次に考えなければならないのが、『データのガバナンス』です。

ガバナンスとは、「統治（とうち）」という意味です。つまり、データを管理・監督するということです。どういうことかというと、b→dashの利用者が社内で増えれば増えるほど、独自のデータを作る人たちが現れます。その際に、ある人は「売上」を「税込」で集計し、またある人は「税抜」で集計していた場合、両社が作成したデータはアップルトゥアップル*に比較することができません。
*アップルトゥアップル：同一条件で比較すること。由来は、比較できないものを比較するという意味の「compare apples to oranges」「apples and oranges」の表現から

そこで、「b→dashにおいて、『売上』とは、税抜・送料抜・値引き後の金額である」というのを予め決めておかなければなりません。そして、予めそういうデータを用意し、「売上を集計する時は、必ずこのデータを参照してね」という取り決めをしなければいけません。これにより、データの一貫性と管理が容易になります。万が一、売上の定義を変えたくなった場合も、ある一カ所の売上計算処理を変更すれば、他の集計すべてで定義を変更することができるようになるからです。

最後に考えなければならないのが、『データの処理順序』です。

これまで見てきたように、どれだけデータや処理をスリム化したとしても、「これ以上はどうしようもできない」という限界がきます。※b→dashの限界というよりは、目的から照らし合わせた時に、「これ以上スリム化したらやりたいことができなくなってしまう」という意味です。

そうなってくると、あとできることは「いつ処理を行うか」を決めることです。b→dashの処理能力も無限ではありません（これはどのサービスにも言えることです）。従って、『処理の分散』を行う必要があります。例えば、「このデータは週1回しか使わないから、週に1度最新化すればいいよね」とか、「このデータは毎日配信しているメール配信に使うデータだから、毎朝8時には最新化されてないと困る」など、データがいつ最新化されてほしいのか・どれくらいの頻度で最新化されてほしいのかは目的によって異なります。それらの目的を考慮し、全体の処理時間から逆算し、「このデータはこのタイミングで処理を動かせばいい」「逆にこっちは後回しでいい」といった交通整理が必要となるのです。JRさんが時刻表を作るようなイメージですね。

そして、これらのメンテナンスは定期的に行うよう、業務プロセスに組み込まねばなりません。何でもできるb→dashですが、流石にこれらの最適化を自動化することはできないからです。正直、これらの業務は本質的な業務ではないため、専任者を配置するというよりはアウトソーシングも検討された方がよいかもしれません。

いかがでしたでしょうか？全12回の連載のうち、今回は『b→dashにおけるリファクタリング 1年後に差が出る運用保守３つのポイント』というテーマでお伝えさせていただきました。「とりあえず何とか分析・施策はスタートさせたけど、一旦色々整理したいなぁ...」と感じていらっしゃる方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。

最後までご覧いただきありがとうございました。

「問題はわかったけど、じゃあどうしたらいいの？」と思われたかと思います。続きが気になる方は以下の資料で「明日から使える３つのアクション」を解説しています。ご興味を持っていただけた方は、ぜひお気軽に資料請求をしてみてください（しつこい営業は一切行いません。※同業他社の方からの資料請求はお断りしておりますので予めご了承ください）。