精度と大容量の壁を、
越える基盤をつくる。
顧客課題は、車両から届く大容量のGPSデータに誤差が含まれ、そのままでは業務に使えないこと。設計基準は、ビジネスインパクトからの逆算。
データから、どう意味を
引き出すか。
車両から送られてくる位置情報は、日々膨大な量が蓄積されていました。しかしその生データは、そのままでは業務判断に使える状態にありませんでした。
GPSの座標には誤差が含まれます。そのため「この車両が今どの道路を走っているのか」を機械的に判定しようとすると、並走する高速道路と一般道を取り違えたり、交差点付近で走行経路が飛んだりします。データはあるのに、そこから確かなことが言えない状態でした。
同時に、扱うべきデータ量は車両台数の増加とともに膨らみ続けていました。精度を上げようとすれば処理は重くなり、インフラコストは膨らみます。リアルタイム性を求めれば求めるほど構成は複雑になり、運用は属人化していきます。「精度」「速度」「コスト」「運用のしやすさ」が互いに引っ張り合う状況で、どこに着地させるかが決まらない。それがプロジェクトの出発点にあった問いでした。
技術ではなく、
ビジネスインパクトから決める。
この領域には「唯一の正解」がありません。インフラはオンプレミスでもクラウドでも実現でき、ストリーム処理エンジンにも複数の選択肢があり、位置判定の推論方式にいたっては幾何学的手法から確率モデル、機械学習ベースまで幅広い方式が存在します。どれを選んでも技術的には成立します。
だからこそ、技術の優劣から入らず、「業務にどれだけのインパクトが出るか」を先に定義し、そこから逆算して構成を決めるという順序を取りました。
具体的には、次の問いを技術選定より先に置いています。
- この判定結果は、どの業務判断に使われるのか
- その判断に必要な精度・鮮度はどの水準か
- その水準を超える精度に、追加投資する価値はあるのか
- 構築後、誰がこれを運用し続けるのか
この問いに答えた時点で、必要な技術構成の輪郭はほぼ決まりました。
低レイテンシの処理と大規模分析を、
同じ基盤に載せない。
業務インパクトを整理した結果、求められる処理特性が一つではないことが明確になりました。
車両ごとの走行状態を保持しながら逐次的に道路を判定する処理は、リアルタイム性が業務価値に直結します。ここは車両単位で状態を管理できるストリーム処理エンジン（Flink）に載せました。
一方、携帯電話のGPSデータを使った人流の拡大推計は、サンプルから母集団を推計する分析的な処理であり、求められるのは鮮度よりも大規模データを捌く能力です。こちらは大規模データの分析に適したSpark Streamingで処理しました。
収集はFluentd、メッセージングはKafkaが受け持ちます。ひとつのエンジンにすべてを背負わせるのではなく、業務価値の性質ごとに適した技術を配置する構成です。
最高精度ではなく、業務要件を満たす
最小限の複雑さを選ぶ。
推論方式には、より高精度な選択肢も存在しました。しかし精度を1段上げるために構成の複雑さが跳ね上がり、運用が属人化し、インフラコストが膨らむのであれば、投じたコストに見合うインパクトは得られません。「業務要件を満たす最小限の複雑さ」を評価基準の中心に置いたことが、この案件における技術的な核心でした。
大容量ストリーミングの上限を決める、
物理制約。
ストリーミング基盤では、アルゴリズムやエンジンの選定よりも先に、物理層のボトルネックが処理性能の上限を決めます。車両ごとの状態をディスクで持てばその読み出し速度が、大容量データを中継すれば複製やノード間の移動で消費するネットワーク帯域が、それぞれ実質的な天井になります。だからこの案件では、収集・メッセージング・処理・書き出しという経路のどこが一番細いかを実装前に見積もり、上流で不要なデータを落として量を減らしてから構成を確定させました。ここを詰めずに実装へ進むと、負荷試験の段階でアーキテクチャそのものの作り直しになります。
何が変わったか。
生データが、業務判断に使える情報になった
「位置座標の羅列」だった状態から、「どの車両がどの道路を走っているか」という業務で直接使える情報に変わりました。データの存在そのものではなく、そこから判断が下せることに価値があります。
コスト対効果で構成を選び、投資が過剰にならなかった
最先端・最高精度を追う構成ではなく、業務要件から逆算した構成を選びました。結果として、インフラコストと実装コストの両方を抑えながら、必要な業務価値を獲得しています。
運用が属人化しない形で残った
設計した仕組みを実際に回すのは現場です。属人化しやすい部分を抑え、運用側が持続的に扱える形に落とし込んだことで、構築後も継続して価値を出し続ける基盤になりました。
複数のデータソースを、ひとつの基盤で扱えるようになった
車両データと携帯電話のGPSを、ひとつの基盤で受け止め、位置判定と人流の拡大推計という別々の用途に活かしています。データソースや用途が増えても、要件に応じた処理を後から足せる構成そのものが、将来の拡張余地として残りました。
物理制約から逆算し、実装後の作り直しを回避した
ストレージI/Oとネットワーク帯域という物理的な上限を実装前に見積もったことで、負荷試験の段階でアーキテクチャを作り直すという、最もコストの大きい手戻りを避けられました。
技術は入れ替わっても、
順序は再現できる。
技術は数年単位で世代交代します。しかし「業務インパクトを先に定義し、そこから技術構成を逆算する」という順序そのものは、技術が入れ替わっても再現できる方法論です。
高性能な技術を選ぶことと、業務に効く構成をつくることは、必ずしも同じではありません。
ENGORGIOが提供しているのは、インパクトの精度と、実現のスピードです。どこに効くのかを見極める精度と、それを実際に動く形にするまでの速さ。この二つが揃ってはじめて、データは業務の成果に変わります。
サイロ化を止め、
全社の基盤へ組み直す。
顧客課題は、共有できる土台のないまま案件単位で基盤を作り続け、データが部門ごとに分断されたこと。設計基準は、ビジネスインパクトの大きい一点から小さく始め、全社の標準へ育てること。
基盤はあるのに、
全社では使えない。
各事業部門は、それぞれにデータ基盤を持っていました。案件が立ち上がるたびに、その案件にとって最適な形で基盤が作られてきたのです。
個々の基盤は、それぞれの目的には十分に機能していました。問題は、それらをつなぐ全社のアーキテクチャがなかったことです。案件ごとに設計思想が違い、権限の持たせ方も、データの置き場所も揃っていない。同じ会社の中にありながら、部門をまたいでデータを使おうとすると途端に手が止まる。そういう状態が生まれていました。
サイロ化は、部門が非協力的だったから起きたのではありません。小さく作ったこと自体が悪いのでもありません。問題は、後で全社へ広げる前提も、共有できる土台もないまま、案件ごとの最適化を重ねたことです。
いきなり全社標準ではなく、
小さく始めて成長させる。
最初から完璧な全社標準を定義しようとすると、動き出す前に時間切れになります。現実の業務に合わない標準を敷いても、使われません。だから全社標準は、最初に敷くものではなく、育てて到達するものとして扱いました。
始め方はビジネスインパクトから逆算します。どの事業に、どれだけの価値を生むか。そこで最も効く一点から、小さく始める。ただし、その場しのぎの一点ではありません。後で全社の標準へ育てられる土台の上で小さく始める。ここが、かつてのサイロ化との分かれ目です。
具体的には、次の問いを技術選定より先に置いています。
- この基盤は、どの事業のどの意思決定を支えるのか
- 部門をまたいでデータを使う場面は、どこで生まれるのか
- 全社で揃えるべきものと、部門に委ねてよいものの境界はどこか
- 小さく始めた構成を、どの順で全社へ広げていくか
これらに答えた時点で、最初に着手する一点と、そこから全社へ広げる道筋が決まりました。小さく始めた構成が、実証を経て全社標準の核へと育っていきます。
基盤を、
部門が自分で使えるように。
小さく始めた基盤が実証され、標準の核ができると、次は事業部門に開放する段階に入ります。中央が作って配り続ける形を、各部門が自分たちで使える形へと変える。これがセルフサービス化です。
ただし、開放すると新しい壁が現れます。この案件で解消したのは、主に次の二つでした。
環境提供が、また属人化する
基盤を開放しても、新しい環境や権限の払い出しが特定の担当者への申請頼みになれば、その担当者が新たなボトルネックになります。案件単位の属人化を解消したはずが、環境提供という別の場所で同じ症状が再発する。申請から払い出しまでの流れを標準化し、部門が待たされずに基盤を使い始められる形にしました。
利用者のスキル差
事業部門の利用者は、データの専門家ばかりではありません。同じ基盤を渡しても、使いこなせる部門と、そうでない部門の差が出ます。テンプレートと最小限のガードレールを用意し、専門知識がなくても標準の使い方に乗れる形にしました。
壁を解消し、利用が広がっていくと、今度は別のことが起きます。使う人が増えるほど、当初の設計意図から外れた使われ方が現れてくる。悪意ではなく、それぞれの部門が自分の都合で最適化した結果です。ここで必要になったのが、次のガバナンスでした。
全社で守ることと、
部門が決めること。
逸脱を止めるために全社で一律に縛れば、セルフサービス化で得た速さが失われます。かといって各部門に任せきりにすれば、サイロ化に逆戻りします。そこで、ルールを二つの層に分けました。
全社ルールは、戦略子会社が中央で定めます。部門をまたいで守るべき最低限を、一箇所で決める。事業部ルールは、各部門が自分たちで定めます。自部門の中でどう使うかは、その部門がいちばんよく知っているからです。
カタログ構成 / 命名規則 / 環境分離 / 監査・アクセス統制
スキーマ設計 / 部門内の権限付与 / データ品質 / 利用ルール
全社のカタログ構成と権限体系
全社層のルールは、Unity Catalog のカタログ構成として実装しました。部門ごとにカタログを分け、命名規則と環境分離を全社で統一。監査とアクセス統制は中央で一元的に効かせています。
部門に委ねた管理権限
事業部層は、各部門に管理権限を委譲する形で実装しました。自部門のカタログの中では、スキーマ設計も権限付与も部門が自分で行える。全社の枠は守りながら、部門の中の自由度は残す。二層の境界を、権限の設計として落とし込みました。
何が変わったか。
小さく始めた基盤が、全社の標準に育った
ビジネスインパクトの大きい一点から始めた基盤が、実証を経て全社標準の核になりました。部門をまたいでデータを使うことが、特別な作業ではなくなっています。
中央がボトルネックにならない開放を実現した
セルフサービス化により、各部門が自分たちの速さで基盤を使えるようになりました。環境提供の属人化を解消したことで、中央チームが全部門の窓口になる構図を避けています。
速さと統制を、両立させた
二層型ガバナンスにより、全社で守るべき最低限は保ちながら、部門の中の自由度は残しました。一律の統制でセルフサービスの速さを損なうことなく、サイロ化への逆戻りも防いでいます。
ガバナンスが、仕組みとして残った
ルールを人の運用に委ねるのではなく、Unity Catalog の構成と権限体系として実装したことで、構築後も同じ基準が持続的に効き続ける形になりました。
二層のガバナンスを、
初日から動かす。
この案件で設計した二層型ガバナンスを、どの組織でも再現できる形にしたのが LakeShepherd です。
組織・権限・環境分離・監査を、ひとつの再現可能な運用モデルとして実装する。全社層のカタログ構成と権限体系を初日から用意し、部門への権限委譲もその枠の中で行える。ガバナンスを後から足すのではなく、基盤の立ち上げと同時に動かす。それが LakeShepherd の役割です。
まずは、将来への意思を共有してください。
最初の会話は、変革の起点を一緒に探す場。何を変えたいのか、何が変えられていないのか——そこから。