需要量の算出が1～2時間から20～30秒に、バルブメーカーのデータ基盤刷新

2015年に導入されたデータウェアハウス製品は、扱えるのが構造化データだけで、受注や発注、実績といった会計につながるデータを分析に載せきれない状態にありました。さらにデータの収集や加工の中身が見えず、項目をひとつ追加するにも開発ベンダーへの依頼が必要。大量のデータを扱おうとすると、BIツール側の制約で処理が止まってしまうこともありました。

ここで効いていたのは、処理が遅いという表面的な事象よりも、分析の仕様を自分たちの手で変えられないという構造のほうだったと考えられます。依頼して待っている間にも市場や受注の前提は動きますから、できあがった時点ですでに別のものが必要になっている。現場から出てくる「こんな切り口で見たい」という問いが、形になる前に賞味期限を迎えてしまう状況です。つまり、一回あたりの処理時間の問題というより、問いを立て直せる回数が絞られていたことが本質だったのではないでしょうか。

約半年をかけて複数のクラウドを実際に動かして比べ、評価の軸を3点に絞り込んだ選び方が、この取り組みの起点になっています。挙げられたのは、クエリの内容に応じて柔軟かつ迅速に処理能力を伸ばせること、提供元自身の社内利用を含めて10年以上の運用実績があること、そしてコストを抑えて小さく始められること。将来の拡張余地と初期の身軽さという、通常なら相反しがちな条件を同時に満たす前提で候補を評価した点に、この選定の性格が表れています。

データを一段階ずつ整えて置き直す設計も、実運用を支える柱になっています。基幹システムや各種データベース、手元のファイルまで含めた業務データを、Compute Engine 上のETLツールで Cloud Storage のデータレイクへ集め、そこで加工したうえで分析用の標準化データとして BigQuery に蓄積し、さらに用途ごとの目的別データへと分類していく。この標準化された中間の層があることで、新しい問いが出てくるたびに元データの取り込みからやり直す必要がなくなります。

パートナーの置き方と、到達点の描き方も見逃せません。設計から構築までは、メーカーである京セラのデジタル変革を支えた経験を持つ KCCS が伴走し、やりたいことを踏まえた構成を一緒に組み立てる形をとりました。そのうえで、データの収集と取り込みを当面はシステム部門とパワーユーザーが担い、将来は分析の担当者自身が集めて加工して可視化する、という段階的な移行像を先に置いています。外注か内製かを二者択一にせず、移行の途中経過そのものを設計に織り込んだ進め方です。

旧分析システムでは部品表から需要量を算出する処理に1～2時間かかっていましたが、BigQuery を採用した K-DAP では同じ処理が20～30秒で完了するようになりました。操作の負担が下がったことで分析改善の内製化も進み、1年で200以上のテーブルが新たに作成され、現場から寄せられる分析の要望にも迅速に応えられる状態になっています。一方、複数のクラウドを集約することによる年間数億円のコスト削減は、現時点では期待される効果として示されている段階です。