【b→dash #11】b→dashにおけるリファクタリング、1年後に差が出る運用保守３つのポイント
b→dashの導入・運用に対してお悩みをお持ちの マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。
累計50社以上のb→dashプロジェクトを支援。クライアントは、金融・不動産・アパレル・食品・スポーツ球団・化粧品・人材・店舗ビジネスなど業界業種を問わず、企業規模も創業まもないベンチャー企業から大手上場企業まで幅広く担当。多種多様な観点からの助言や、豊富な経験をもとに先回りした提案を強みに、b→dash初心者がつまずきがちなポイントを強力にサポートしています。
第11回は、「b→dashの導入、ようやくちょっと一息ついたなぁ」という方に向け『b→dashにおけるリファクタリング* 1年後に差が出る運用保守３つのポイント』をテーマにお届けします。ぜひ最後までご覧ください。
*リファクタリング：外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること
前書き
1年後に差が出る運用保守のポイントを解説するにあたり、本ブログのサムネイルにもなっている「リファクタリング」について説明していきます。
そもそも「リファクタリング」とは、外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること、などとGoogleを検索すると解説されています。
みなさま、『ハウルの動く城』という映画をご存知でしょうか？（ちなみに私は観たことがありません）。システム開発を行っていると、あのハウルの動く城のようなシステム（細い足腰に対して不安定でいびつな上層部）ができあがることが往々にしてあります。特に、最近のWEBサービスの多くは、初期にコアとなる機能を実装し、その後ユーザーの要望に応える形で機能を充実させていくことが多いため、悪く言えば「継ぎ接ぎ（つぎはぎ）だらけのシステム」になりがちなのです。また、外資系のツールにありがちなのが、コア機能の周辺機能をM&A（合併・買収）によって補完していくケースです。この場合も継ぎ接ぎだらけのシステムになりがちです。
こうなってくると何が起きるかというと、「どっかをいじったらあっちこっちでエラーが起きる」みたいな事件です。どこのコードの修正がどこのコードに影響を与えるかなどがわからなくなります。また、開発当時にいたエンジニアが退職してしまっているケースもあり、「このコードは一体何をするためのコードなんだろう...」ということも起こりえます。
そこで必要になるのが「リファクタリング」です。主な目的は、（１）コードの可読性向上（誰もが理解しやすいコードにするための変更）、（２）冗長なコードの削減（必要以上に長たらしい記述をされたコードや、重複しているコードの削除や簡潔化）、（３）設計の改善（より良い設計パターンやアーキテクチャ（構造）に変更）、（４）技術的負債の返済（後回しにされてきた改善点の処理）、などです。机の中の引き出しを整理整頓するようなイメージです。
これと似たような役割を果たすのが「マイナーアップデート」です。よくスマートフォンのアプリで「最新のバージョンがあります。更新してください」みたいに出てくるあれです。目的としては、小規模な機能追加やバグの修正、パフォーマンスの改善などがあります。リファクタリングとマイナーアップデートは、それぞれソフトウェア開発において重要な役割を果たしますが、その目的とアプローチが異なります。
少し前段のお話しが長くなってしまいましたが、それではb→dashにおけるリファクタリングを見ていきましょう。
1年後に差が出る運用保守のポイントとは？①
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レコードあたりのデータ量を削減したり、使用するレコード量を削減したり、不必要なデータを削減する処理を組むことが求められるのです。
1年後に差が出る運用保守のポイントとは？②
1年後に差が出る運用保守のポイントとは？③
記事の続きは、非エンジニアのためのテクノロジー活用メディア『umbrElla』でご覧ください。
もし少しでも自社のマーケティング組織が当てはまっているな...と感じてしまった方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。
この記事が気に入ったらサポートをしてみませんか？