entry-header-eye-catch.html
entry-title-container.html

entry-header-author-info.html
Article by

事業計画を立てる上で必要なプロセスをシステム化し改善した話

こんにちは。プラットフォーム開発部兼財務データ企画部のshigeniiと申します。

普段はデータ基盤の運用保守、および、全社的なデータ活用やデータ駆動推進を担当しています。

今回は、財務に関する情報の収集からその可視化までの過程をシステム化することで、事業計画や予算策定のプロセス改善に結び付けた我々の取り組みについて、システム化に焦点を当てながら書き綴りたいと思います。

この記事がバックオフィス業務において、同じような課題を抱えている方に少しでもご参考になれば幸いです。

経緯

これまでは、経理部が各部門別の損益をスプレッドシートで作成し、各部にそれを提供していました。しかし、この運用には次のような課題がありました。

  • 深堀りした分析が容易にできない
  • 配布に手間がかかる
  • データの集計、および、そのチェックなどに時間を要している

スプレッドシート自体の利用が悪いものではないと考えていますが、ほぼすべてをスプレッドシートで管理していたため、運用や保守に多くのリソースが割かれるのが実態でした。

また、昨今のデータ量の増加により、スプレッドシートにそのものに限界が来ました。

そこで、事業計画を立てる上で必要な財務情報(ここでは損益に関する情報)をデータウェアハウス化し、BIツールを用いることで分析情報を可視化、さらに可視化までの工程は効率化の観点からできるだけシステム化をするように努めました。

財務レポート可視化プロジェクト

以上の経緯から、我々は事業計画および予算策定の際のプロセス改善に向け、下記を目標としました。

  • 管理職向けに必要な損益情報をわかりやすい形で提供する
  • 経理部の負荷を軽減する
  • 最終的には経営向け資料の作成に繋げる

これらの目標のもと、本プロジェクトは部署をまたいだ全社的な形でスタートしました。

システム化にあたっての具体的な取り組み

Before

  • ワークシートでの手作業によるデータ収集や集計、およびチェックに時間を要している
  • 数字のみの提供となり、分析に繋げられるような提供が実現できていない
  • 問い合わせの都度、必要情報を追加で作成する必要がある
  • レポート配布に手間がかかる

After

  • 会計データを元に、事業計画や予算策定に必要な財務レポートを自動生成
  • 損益に関する情報を、BIツールでやグラフを用いて可視化し、容易に分析可能な状態で提供(収益・費用の推移、構成要素の分析、予実分析等)
  • 情報が一元管理され、閲覧者は自身の権限に応じ必要な範囲のレポートが参照可能
  • レポート内でドリルダウンによる深掘り調査が可能
  • データを追加することで配布レポートの内容を即座に更新

システム化にあたっての課題

  • 限られた期間の中で、どこまでをシステム化するかという検討
  • 社内秘となる部署ごとのデータ閲覧権限をどのように制御するかの解決

まず、今回のプロジェクトは事業計画の策定に関するプロセスを改善するためのものでした。 そして、来期の事業計画の策定までに対応が迫られていたため、対応期間があまりない状態でした。 そのため限られたリソースの中で「どこまでをシステム化するか」を検討する必要がありました。

また、財務レポートの元となるデータは部署ごとの情報となるため、それらの閲覧をどのように権限管理するか、具体的にはどのように必要なメンバーのみに必要な情報のみを提供するかを検討する必要がありました。

今回の対応

全体的なシステム構成

ピクシブでは、データ基盤は主にGoogle Cloudのプロダクトを利用しています。

各業務管理システムからデータをBigQueryに連携し、BigQuery上でデータウェアハウスとデータマートを構築、それらをBIツールから参照する構成としています。

下記は今回構築した仕組みの全体像です。

財務レポートを作るまでのながれ

下記に財務レポートを作成するまでの主なながれを記載します。
※説明は「全体的なシステム構成」の番号に一致します。

説明1.各業務システムのデータを取得

各業務管理システムで決められているフラットファイル形式のデータをエクポートし、そのまま編集などはせずにBigQueryに取り込みます。データの加工はこの後のステップで取り扱います。

主なデータは、実績に関する情報(会計データ)と組織図に関する情報になります。

説明2.マスタ情報の取得・作成

ここでは、主に勘定科目、財務レポート向けに数字を集計するための定義情報、予算に関わる情報など定期的に経理部門にて更新が必要になる「マスタ」の情報を取り込みます。

これらの情報はワークシートで管理し、それらを外部テーブルとしてBigQuery上に定義の上、そこからデータウェアハウスを生成しています。

説明3.データの加工・突合機能

BigQueryに取り込んだデータは各業務システムのRAWデータのため、このままでは財務レポートに利用できません。そこで、会計のルールに即した形にデータを加工した上で、データウェアハウスを作成し、さらにそこから用途に応じたデータマートを作成しています。

これらのデータ加工処理には「dbt(data build tool)」を利用しています。
RAWデータの正しさの検証、加工したデータの検証も合わせてここで行います。

弊社のdbt導入実績につきましては、ぜひ下記の記事も合わせてご覧ください! inside.pixiv.blog

説明4.データに対するセキュリティの担保

財務レポートは、閲覧するメンバーやその役職、そしてメンバーの所属部署に基づき、より細かくデータの閲覧権限を制御する必要があります。

BIツールで可視化するレポートの元データに対して、この権限設定を行います。
こちらにつきまして詳しくは後述いたします。

説明5.BIツールによる可視化

BigQuery上に作成したデータマートを、Looker Studioから参照しレポートを作成します。レポートコンテンツの管理は、Looker Studio Proを利用しています。

今回のシステム化では見送りとした対応

システム化を行うまでの期限が限られていたため、検討の結果、一部のシステム化を見送りました。

  • RAWデータのアップロード自動化はしない
  • マスタ管理向けのUI(いわゆる管理画面)は作成しない
  • LookMLを用いたモデリングは行わない
その1:RAWデータのアップロード自動化はしない

各業務管理システムからのデータ取得を自動化する方法としては、それらのシステムが持つ「API」を利用する方法などが考えられます。

今回この対応は見送り、各業務管理システムのデータはフラットファイルの形で取得し、それらをBigQueryにアップロードする方式としました。

今後、APIの利用やデータパイプラインサービス(Saas)の利用などを考えています。

その2:マスタ管理向けのUI(いわゆる管理画面)は作成しない

マスタをメンテナンスするための管理画面UIの作成は、行いませんでした。

マスタの情報は、ワークシートで管理することにした上で、外部テーブルとしてBigQueryに定義、それを元にDWHの生成に利用するようにしました。

ワークシートの手作業による修正は不整合データを生みやすいですが、それらを抑止するためにデータを加工する途中にチェック機能を盛り込みました。dbtを利用することにより、ソースデータからDWH、およびデータマートを生成する過程において、それらの依存性のチェックやデータ不整合のチェックが容易に可能となります。

その3:LookMLを用いたモデリングは行わない

弊社では、BIツールとして主にLooker、およびLooker Studioを利用しています。

全社的に利用するレポートとなるため、その保守性を考えてLookMLでモデリングの上、Lookerでのダッシュボード作成も検討しましたが、今回は見送りました。

LookMLで実現していたセマンティクレイヤーについては、dbt上でモデリングを行うことによって集計しやすいデータへの変換やファンアウト(または、ファントラップ)といったデータウェアハウス、データマート構築上の問題の解決をしています。

今後、Looker、および、Looker Studioはさらなるプロダクトの進化が期待できますので、それらも見据えてレポーティング方法の改善をしていきたいと考えています。

データの閲覧権限に関する課題の解決

秘密情報に対するセキュリティポリシーは、下記のように「フィールド」に対して行うことが一般的かと思います。

例えば、下記は「email(メールアドレス)」フィールドにポリシーを適用する場合の例です。

BigQueryにおいては、「列レベルのセキュリティ」を利用することでこの問題が解決できます。
列レベルのアクセス制御の概要  |  BigQuery  |  Google Cloud

今回は、「レポートの閲覧者に対して、所属するsection(部門)のデータのみを参照できるようにする」という要件がありましたので、フィールドではなくレコードに対してポリシーを適用する必要がありました。

こちらもBigQueryの機能を利用することで解決できます。今回はこの方式を取り入れました。
BigQuery の行レベルのセキュリティの概要  |  Google Cloud

行に対するセキュリティは下記のDDLにより容易に実装が可能です。詳細は公式のドキュメントをご確認ください。

CREATE ROW ACCESS POLICY ポリシー名 ON 対象テーブル名
  GRANT TO (対象ユーザー) FILTER USING (対象フィールド IN (値));

具体的には、「労務管理システム」から取得した会社組織の情報と、経理部門で作成した部門損益を集計をするための情報を合わせて判断し、「このメンバーにはこの部署のレコードの参照許可を与える」という権限設定を実現しています。

今回の対応を終えて

結果、下記のようなレポート群をBIツールで可視化、閲覧権限を持つメンバーのみが閲覧し、分析を容易にする状態を実現することで、当初抱えていた課題を解決することができました。

  • 損益推移、損益構造のドリルダウン
  • 予算達成率、および予算消化率
  • 単月予実分析、過去平均・トレンド分析

昨今は、各種データウェアハウスやBIツールの進化、またデータビルドツールなどの存在により、データの加工からレポーティング、分析までの仕組み作りが非常に容易となりました。

今回は、財務レポートとして主に損益のレポーティングを対象としましたが、今回の事例を元にバランスシートやキャッシュフロー計算書のBIツールによる可視化にも、既に着手を開始しております。

おわりに

今回は、財務に関する情報の収集からそのレポートを可視化するまでの過程をシステム化し、事業計画や予算策定のプロセス改善に結び付けた我々の取り組みについてお話させていただきました。

今後は、さらなる業務改善やより効率的なシステムの構築に取り組む所存です。

ピクシブでは一緒に働いていただける仲間を大募集しています。

財務やデータにご興味のある方は、ぜひ以下をご覧ください!

hrmos.co

20220927102812
shigenii
2022年1月に中途入社。全社を横断したデータ基盤の運用保守や改善、データ活用の推進、データマネジメント業務を担当しています。お酒、海外旅行、手芸、ギターが大好きです。