【事例】福岡地所株式会社
当社監訳書籍『アジャイルデータモデリング - 組織にデータ分析を広めるためのテーブル設計ガイド』の寄稿事例をWEB掲載しています。
- 本書における寄稿事例の位置づけについては寄稿事例について を参照してください。
- 本ページに掲載している画像および図表については、いずれも同書籍からの引用となります。
福岡地所株式会社
寄稿者：DX推進部 寺師岳陽
福岡地所グループは九州を代表する不動産総合デベロッパーです。福岡地所では各部署がファクトデータを、DX推進部がディメンション（マスタ）を整備しています。マスタデータの整備にあたっては、業務支援SaaSやクラウドデータウェアハウスの導入選定から始まり、業務フローの見直しや管理職向けの研修まで行っています。
風音屋では2年以上にわたって福岡地所を支援してまいりました。企業がデータモデリングを始めるにあたって、必要なファクトやディメンションのデータを整備しなければいけない場面は多々あるかと思います。福岡地所の取り組みが参考になることでしょう。
福岡地所グループは「福岡をおもしろく」を目指し、不動産総合デベロッパーとして街づくりに邁進しています。成長著しい福岡市において、天神・博多エリアを中心にオフィスを供給しており、近年では天神ビッグバンや博多コネクティッドといったプロジェクトに深くかかわっています。また、キャナルシティ博多といった福岡の象徴となるような商業施設の運営やFORZAというビジネスホテルブランドを全国に展開しています。ビルマネジメントと呼ばれる領域では、建物の運用保守事業を行っています。そのほかにも物流事業やエネルギー、創業支援施設運営などさまざまな活動を行っています *1。
*1 https://fukuokajisho.com/
DX推進部はグループ全体のITシステムを統括しながら、これらの事業を支援しています。また、「ITを使って意思決定のスピードと確度を継続的に向上させる」という目的を掲げ、会社全体をデータドリブンな組織に変革するために日々活動しています。
担当者が業務に習熟していけば、いわゆる勘・経験・度胸（KKD）だけでも意思決定のスピードと確度は十分な水準になりますが、そのままでは担当者個人のノウハウや暗黙知の域を出ません。データを活用し、再現性を高めることで、組織全体がより早く正確に意思決定ができるようになると考えています。
あらゆる社員がデータを使って意思決定できるように、社内のデータを活用・整備してきました。特に、マスタデータ（ディメンション）の整備については、グループ全体を巻き込み、システムや業務フローを抜本的に見直すことが必要でした。どのようにプロジェクトを推進していったのか、弊社の事例をご紹介することで読者の皆様に少しでも参考になれば幸いです。
図1 データ利活用テーマ設計シートの様式
弊社では図1の「データ利活用テーマ設計シート」を用いて、データをどのように意思決定に活用するのかを明記し、いつでもビジネス目的に立ち返ることができるようにしています。ダッシュボードを見せたときに上司から「それで？」と言われてしまったり、「AIを導入する」「データサイエンスで分析を行う」など手段ありきの話ばかりで意思決定につながらない、といったアンチパターンを回避するための仕組みです。
データ利活用テーマは「○○ごとに××を見て、××を増やす（減らす）ために△△する」という形で表現します。○○がディメンション、××がファクト、△△が施策の意思決定となります。これがビジネス要件とデータ要件をつなぐための架け橋となります。例えば、「取引先（ディメンション：Who）ごとに売上（ファクト）を見て、売上を増やすために営業効率の良い業種や規模にアプローチ（施策）する」といったテーマを設計することができます。
シートの項目はシンプルですが、初めて記入するときは苦戦することが多いです。「××を増やす、減らす」の部分を「最適化する」と書き、「△△する」の部分を「検討する」「確認する」と書くなど、曖昧な記載に逃げてしまいがちです。どの指標をどのくらいの目標値に近づけたら最適化できたと言えるのか。検討・確認によってどのようなアウトプットにつながるのか。なるべく具体的に言語化・文書化することがデータドリブンな意思決定に向けたスタートラインだと考えています。
すべての部門でこのシートを活用するように取り組みを始めました。各部門長、経営企画部門、DX推進部が内容をレビューし、経営戦略と現場ニーズに齟齬がないようにフィードバックを行います。弊社の経営戦略はBSC（バランススコアカード）というフレームワークで全社員に共有されているため、シートの冒頭に「BSCのこの項目と連動しています」と書くだけで、スムーズに社内の認識が揃います。
シートの内容をダッシュボードで表現するにあたって、BIツール「Tableau」を利用します。ディメンションとファクト（Tableauではメジャーと呼びます）はシート記入時に明確にしたので、後は必要なデータが揃えば簡単に可視化できます。「地域ごとに物件を見る」といったディメンションが定まっていれば、ドリルダウン（地域の粒度を細かくする）やフィルター（この地域に注目する）の活用について、DX推進部から現場チームに提案しやすくなります。
図2 データ整備に関する社内案内
必要なデータが揃っていない場合は、データ整備から始めます（図2）。ファクトテーブルを整備した例としては「管理施設の来場客アンケート」を挙げることができます。アンケート用紙を回収した後、紙のまま管理するのではなく、PCでデータを入力するように運用を見直しました。その結果、施設の集客イベントの費用対効果をBIツールで比較するなど、マーケティング施策の改善に向けてデータを分析できるようになりました。ファクトテーブルの整備は各部門の管轄となります。
ディメンションテーブルの整備は、グループ全体に影響を与えるため、主にDX推進部が担います。代表例としては取引先、組織、社員、商品、科目といったマスタデータになります。弊社DX推進部ではこれらを「経営資源データ」と呼んでいます。現代においてマスタデータは経営資源の1つだからです。
マスタデータの統合は容易ではありません。「顧客データを一元管理しよう」「顧客マスタを作ろう」と検討を始めると、個人（ToC）と法人（ToB）、物件のユーザー（利用者）とオーナー（保有者）など、顧客の属性が異なっていることに気付きます。家族でホテルに宿泊するときはプライベートのメールアドレス、出張でホテルに泊まるときは会社のメールアドレスで登録するでしょう。それぞれのデータを管理しているシステムも異なります。個人情報保護のために分けて管理しなければいけないケースもあります。
そこで「事業Aの顧客データ」と「事業Bの顧客データ」を統合できるかどうかを図3のマトリックスに書き出しました。データを統合できる組み合わせには「◯」を、統合できない組み合わせには「✕」を、一部のレコードしか統合できない場合や何らかの工夫が必要になる場合は「△」を記載しています。このマトリックスを「現在はどうなっているか」「既存データで名寄せを行う案」「システム改修案A」「システム改修案B」で比較し、マスタデータ統合後の状態を明らかにします。
図3 顧客データの統合可否チェック（内容はダミー）
このマトリックスを応用すると、縦軸をマスタ（ディメンション）ではなく1つ1つのデータ利活用施策に書き換えることができます。「事業Aのデータ」を「事業Bのマーケティング施策」に使える場合は「◯」を、使えない場合は「✕」を記載します。どの様な施策が実現可能で、どの事業にインパクトを出せるかがわかるようになります。
今回は法人（ToB）データのマスタ、つまり「取引先マスタ」に注目します。福岡地所グループ全体の取引先ごとの売上について、手元のデータを用いてTableauで可視化しようとすると、次のような課題が生じます。
- システムや用途によって、取引先名が、得意先、仕入先、請求先、支払先といったデータに細分化されていました。データを統合する必要があります。
- 取引先IDはシステムごとに個別で採番されており、データはサイロ化していました。また、オフィス賃貸とビルマネジメントでは業務システムも異なります。法人名で一致しないケースがありました。「福岡地所株式会社」が「福岡地所㈱ 」と省略されている、未記入で「福岡地所」になっているなど、イレギュラーが次から次へと出てきました。法人名を名寄せする必要があります。
- 住所での名寄せもうまくいかないことがありました。請求書の送付先が必ずしも本社とは限りません。その場合、同じ取引相手であっても登録住所は異なることになります。業務特性に応じて住所を保持するか統制範囲を決める必要があります。
- 商業施設に入居しているテナントの中には、契約している法人名ではなく、店舗名が登録されているケースがありました。これでは会社単位で分析できません。事業所単位でIDを管理する必要があります。
- リースで取引した場合、営業先の企業は直接支払うのではなく、リース会社を経由することになります。システムによってはリース会社の入金データしか取得できず、営業活動に活かすことは難しいでしょう。得意先（発注元）と請求先は分けて考える必要があります。
- 企業名の変更や合併、分割が起きると、データ修正や集計対象の引き継ぎが必要となります。
個々の事情や制約を読み解き、「取引先マスタ」と呼ぶデータの構造を整理すると、図4のER図（概念モデル）となりました。企業ごとのIDだけではなく事業所ごとにIDを持つ、親会社や関連会社のIDを持つといった特徴があります。このER図を見ると、取引先マスタという言葉を安易に使っていましたが、本当に「取引先」単位のデータが必要なのか、それとも企業や事業所を集計単位にすべきかなど、ディメンションの要件がより明確になるでしょう。
図4 取引先マスタのER図の例
取引先マスタの実現にあたって、業務支援SaaSで個々のデータを入力・生成し、AWS（アマゾンウェブサービス）で横断的にデータを集約・管理する構成としました。一般的にはマスタデータ管理（MDM：Master Data Management）と呼ばれる活動になります。図5の左側がデータの取得元、右側がデータの利活用先となります。
図5 取引先マスタを生成するデータ基盤のシステム構成
スクラッチでのITシステム構築を最小限に抑えることで、費用対効果を最大化し、短期間でマスタを整備しました。SaaSはカスタマイズ性に乏しいため、業務要件や分析要件を踏まえて必要な粒度のデータを扱える製品を選定する必要があります。IT部門の腕の見せ所と言えるでしょう。
取引先データの入力場所には名刺管理ツールのSansanを選びました。
SansanはCRM（顧客管理）基盤としての機能が豊富で、企業名の名寄せや属性情報の付与が自動でなされます。企業データベースのuSonarと組み合わせると事業所レベルで名寄せした上でIDを付与することが可能です。任意のプログラムを実行できるAWS Lambdaでこれらのデータを取り込みます。
取引申請・決裁稟議に用いるワークフローシステムにはkickflowを選定しました。WebAPIやWebhookで他システムとデータを相互に連携できることが決め手の1つです。AWS LambdaでSansanとuSonarのデータを取得し、kickflowのデータベースに書き込みます。決裁稟議を出すときには、いちいち取引相手の情報を調べて記入せずとも、kickflowの検索画面から対象を選ぶだけで、必要な情報がすべて入力されるように自動化しています。Sansanで登録しないとkickflowの検索結果に出てこないため、データ入力を徹底させるねらいもあります。
Sansan（取引先）、uSonar（事業所）、kickflow（稟議）データをAWS Lambdaで取得した後、複数の業務システムを経由して、ストレージAmazon S3にファイル形式で保存します。一部の経路ではデータ処理ツールAWS Glueによる加工を挟んでいます。S3のデータはデータウェアハウスAmazon Athenaに連携し、BIツールTableauはAmazon Athenaに接続して一連のデータを分析・可視化します。本稿執筆時点ではAmazon Athenaから高性能なデータウェアハウスAmazon Redshiftに切り替えを進めているところです。
システム構築後には、業務手順の切り替えや過去データの移行作業が必要になります。各事業で使っている販売管理システムの取引先情報を、SansanやAWSの取引先データと連動させなくてはなりません。なるべく現場の負担や混乱を抑えるには、既存の業務フローに乗せて、自然な流れでデータを連携できるのが理想です。取引先管理では定期的にリスクチェックがなされており、図6のように台帳データベースを更新する形で、洗い替えを行っています。台帳の更新時に取引先マスタを同期するように統制をかけることで、徐々に取引マスタに統一されていくようになります。
図6 取引先管理の台帳更新フロー
ルールを決めるだけでは必ずしも現場に浸透するとは限りません。運用を徹底し、データ入力の不備を減らすには、部門長・管理職がデータ入力業務やマスタデータの意義を認識し、厳しく目を光らせなければいけません。そこで管理職向けにデータマネジメント研修を実施しました。ヒト・モノ・カネと並び、情報（データ）は経営資源です。人材や予算を同じように、マスタデータを正しく維持・運用することが重要です。
研修で多くの管理職に伝わりやすかったのがExcelデータの管理方法です。「セルを結合しない」等のノウハウを展開しました。来場客アンケートのようにデータをExcelで管理するケースは多々あります。Tableauで他のデータと組み合わせるには、物件マスタや取引先マスタを正しく入力しなくてはいけません。研修参加者からは「もっと前から知りたかった」「データ整備の重要性を理解できた」といった前向きなコメントが出ており、今後も継続的に実施していく予定です。
本稿では、弊社の事例をもとに以下のようなノウハウを紹介してきました。
- データ分析の前に、ディメンション、ファクト、分析後のアクションを決めて、シートに明記する。
- 必要なデータが揃っていなければ整備する。ディメンション（マスタ）は会社横断で、ファクトは各部署が担当する。
- 「◯◯マスタが欲しい」を深く掘り下げていくには、影響範囲や粒度を整理しながらER図に落とし込む。
- データ入力箇所では業務支援SaaSを導入し、それらのデータをクラウドデータウェアハウスに統合する。
- データ入力を徹底できるように、既存の業務フローに組み込み、管理職向けの研修を実施する。
このような取り組みを通して、組織全体でデータ活用に対する解像度を上げていくことが、意思決定のスピードと確度を継続的に向上させていく方法であると考えています。今後も「福岡をおもしろく」を目指し、DX推進の旗振り役としてデータドリブンな組織づくりに邁進してまいります。