業務アプリ量産時代のデータ戦略 ― アプリは増えても、データの置き場は増やさない

分析の相談をいただくとき、最初に詰まるのはたいてい分析の手前です。

「そのデータ、どこに置きますか」。

社内の基幹システムには入っているけれど外から触れない。ファイルサーバーには置けるけれど集計できない。クラウドの分析基盤は用意したけれど、写真やPDFや音声は行き場がない。この「置き場所」が決まらないまま、分析の話だけが先に進んでしまう。

そしてこの問題は、これから確実に増えます。現場ごとの小さな業務アプリが、どんどん作られる時代になったからです。AIの力で入力画面はすぐ作れる。でも画面だけ作ると、データはアプリごとに散らばります。散らばったデータは、あとで取りに行って、形を揃えて、初めて分析に使えます。この「裏側のコスト」は、アプリが増えるほど膨らみます。

だからうちは方針を決めました。データ基盤を1つに集めて、その上に業務アプリを作っていく。 アプリは増えても、データの置き場所は増やさない。

今回、その基盤を自社のAWS上に作りました。表もファイルも同じ場所に置ける基盤です。自社のデータを1か所に集め、これから社内で作る業務アプリはすべてここに載せます。何を考えて作ったかを書きます。

1. 表とファイルは、同じ場所に置けたほうがいい

データには大きく2種類あります。

形の決まっているもの。売上、顧客、在庫。行と列に並ぶので、そのまま集計できます。これはデータベースに入れます。今回はPostgreSQLというデータベースを使いました。

形の決まっていないもの。写真、PDF、音声、機械が吐き出すログ。行と列には収まりません。これはファイルの置き場所（AWSのS3）に、そのままの形で置きます。

分けて持つと、必ずどこかで突き合わせる作業が発生します。「この売上データに対応する納品書のPDFはどこか」を人が探す時間が、じわじわ効いてきます。

同じ基盤の中に両方あれば、この探す時間が消えます。写真のファイル名を表の列に持たせるだけで繋がるからです。

そしてもう一つ。形の決まっていないものを、そのままの形で残しておけるのが効きます。あとから「あの列も欲しかった」となったとき、元のファイルが残っていれば作り直せます。相手のシステムが過去にさかのぼって出してくれるとは限りません。取ってきた瞬間の姿を1つ残しておくかどうかで、半年後にできることが変わります。

2. 「読む」だけでなく「書き込める」

分析基盤はふつう読む専用です。基幹システムから吸い上げたものを集計して、グラフにする。データを増やすのは元のシステムの仕事で、分析基盤側から書き足すことは想定していません。

今回はそこを外しました。この基盤の上にアプリを載せて、そこから直接データを登録できます。

たとえば現場で紙に書いている点検記録。基幹システムに入れる項目ではないけれど、集計はしたい。こういうものは行き場を失いがちです。基盤の上に入力の画面を作ってしまえば、書いた瞬間から集計の対象になります。

「分析のためにデータを集める」から「業務ごと載せる」に変わります。集計のために毎回どこかから吸い上げる必要がなくなるので、そもそも吸い上げる仕組みを作らなくて済みます。

逆の作り方——アプリを先に作って、データはそれぞれのアプリの中——だと、2本目3本目と増えるたびに置き場所も増えます。5本のアプリの数字を横断で見たくなった日に、5か所からの吸い上げと5通りの形の変換が待っています。アプリは使い捨てでも作り直しでもいい。データだけは最初から1か所。これが今回の設計のいちばん芯にある考えです。

3. 費用の形が、使い方を変えてしまう

ここが今回いちばん大きい判断でした。

クラウドのデータ基盤の課金には、大きく2つの形があります。

使った量で課金される形。動かした分だけ払う。大量のデータを扱うときに、使っていない時間の分を払わなくて済みます。データが何億行という規模なら、必要なときだけ大きな計算力を借りられるこの形のほうが、むしろ安くて速い。

月額がほぼ固定の形。置いてあるだけで一定額がかかるかわりに、何回読んでも何回書いても増えません。

これまで使っていた基盤は前者でした。それ自体は優れた仕組みで、大規模なデータを扱う会社で広く使われているのには理由があります。

ただ、うちの請求の内訳を見てみると、保管している分はほとんどゼロで、ほぼ全部が「動かした回数」でした。そしてうちの使い方は「量はそれほど多くない、けれどアプリから頻繁に読み書きしたい」。大量データ向けの仕組みを、少量・高頻度の使い方で借りていたことになります。道具と使い方が噛み合っていなかったのは、こちらの側です。

それで今回は後者に移しました。頻繁に読み書きしても月額が変わらないので、「ちょっと試してみよう」に値段がつきません。

大事なのは、どちらの形が優れているかではなく、自分の量と使い方に費用の形が合っているかです。同じ判断を他社に当てはめると逆になることも普通にあります。まず請求の内訳を見て、何にお金がかかっているのかを確かめるのが先です。

4. 長く使う場所だから、気をつけたこと

1か所に集めるということは、壊れたとき・消えたときの影響も1か所に集まるということです。動くだけでは足りません。作るときに意識した点を4つ書きます。

① 案件ごとに分ける。ただし名前は案件名ではなくID

ファイルの置き場所は、いちばん上のフォルダ名をデータベース名と揃えました。案件1つにつきフォルダ1つ、データベース1つです。

そしてフォルダの名前は、案件名ではなく機械的に振ったIDにします。

s3://（置き場）/
  ├ cl_x7k2/   → データベース「cl_x7k2」に入るもの
  └ cl_m4p9/   → データベース「cl_m4p9」に入るもの

権限は1行で書けます。「このプログラムは cl_x7k2 のフォルダにだけ書ける」。フォルダとデータベースが1対1なので、どのプログラムがどの案件のデータに触れるかが、構成を見れば分かります。

案件名にしない理由は、万一置き場を覗かれたときのためです。フォルダ名が案件名だと、どの取引先の何のデータかが一目で分かる案内板になってしまいます。IDなら、それだけでは何のデータか分かりません。IDと案件の対応は、置き場とは別の場所で管理します。

権限は細かく書くほど安全に見えますが、細かくすると今度は「何のためのこの1行か」が分からなくなり、増やすたびに事故ります。案件単位という分かる粒度で切るほうが、結果的に守られます。

② 消してしまったときに、戻せるようにする

作りはじめの時点では、上書きしても誤って消しても戻す先がありませんでした。ここが実はいちばん大きな穴でした。

版を保存する設定を入れて、上書き・削除しても前の状態が残るようにしました。古い版は一定期間で自動的に消えるので、保管料が増え続けることもありません。

③ 止まったときに、止まったと分かるようにする

これは今回いちばん考えさせられた点です。

引っ越しの作業中に、失敗しているのに「成功」と報告していた処理がいくつも見つかりました。外部からデータを取ってくる処理が、エラーになっても正常終了を返す。予定表の上では毎晩きれいに緑が並びます。中身は空でも。

さらに、置いたファイルの中身を確かめていませんでした。見出しの行だけの空ファイルでも「成功」です。

直したのは4つです。

• 失敗したら、失敗として落とす（例外をそのまま投げる）
• 置いたあとに読み直して、中身があることを確かめてから成功にする
• 一時的な通信エラーは数回やり直し、それでも駄目なら記録に残して落とす
• 「静かに消える」タイプの不具合は、毎晩の検査で機械が見張る

止まらない仕組みを作るより、止まったときに分かる仕組みのほうが先です。

そして、その先に目指しているものがあります。止まったら、自動で復旧する仕組みです。まだそこまでは作り込めていませんが、順番として「隠れて止まる → 止まったと分かる → 自動で戻る」の階段だと考えています。「気づける」が土台にあって、初めて「自分で戻る」が作れます。

④ 引っ越しの前後で、数字が変わっていないと言えるようにする

「たぶん同じです」で済ませると、あとで数字を疑う日が来ます。

新しい基盤と古い基盤を同じ日に並べて動かし、出てくるファイルを1バイト単位で突き合わせました。57種類のうち55種類が完全一致。残る2種類は、外部サービスが毎回変える署名付きのURLと、もともと順番が決まっていなかった並び順だけでした。

毎月配信しているレポート画面についても、古い基盤で作ったものと新しい基盤で作ったものを、出来上がったHTMLごと比較しています。

引っ越しで数字が変わらないことは、宣言ではなく手順で示すものだと考えています。

5. できるようになったこと

整理すると、こうなりました。

この基盤は、これから社内で作る業務アプリの土台です。アプリが何本増えても、置き場所は1つ。分析したくなったとき、データはもう揃っています。

次に作る社内アプリから、この上に載せていきます。増やすのはアプリだけ。データの置き場は、ここから増やしません。

おわりに

引っ越しそのものの記録は、X記事のほうに書きました。請求の内訳を見て方針を決めたところから、取得プログラム9本を1本にまとめ、数字が変わっていないことを確かめるまでの実録です。

引っ越しの実録はこちら：データ基盤を、自社のAWSに引っ越した（X記事）

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。