Power BI の今年、2025年に向けてちょっと未来のお話

# Power BI Advent Calendar 2024 のオオトリです
**Happy Holidays**🎄🎉✨
この記事は [Power BI Advent Calnedar 2024](https://qiita.com/advent-calendar/2024/powerbi) のシリーズ 1 Day 25 の記事です。

今年は [須藤さん](https://qiita.com/akihiro_suto) が Advent Calendar のホストを務めてくださいました。まずは須藤さん、ありがとうございました🫡

さて、2024 年は皆さんにとって、どんな年になりましたか？
Microsoft のイベントは、良くも悪くも生成AI、Copilot づくしでしたね。Data Platform では Fabric づくしでした。

- Power BI に出会った人
- Power BI の有償ライセンスを付与された人
- Fabric を使い始めた人
- 所属組織において、Power BI を中心とした取り組みを始めた人
- Power Query の勉強を始めた人
- DAX の勉強を始めた人
- 魅力的なビジュアルってどうあるべきだろうと考えている人
- Copilot があるんだから、勉強しなくていいんじゃないかなと思っていたが、やっぱり勉強が必要だと気づいた人

さまざまなステージの人がおられることでしょう。
どんなステージにいても、気にすることはありません。やることはひとつ。
次のステージを定め、愚直に目指すだけです。

組織に言われてやるもよし。自分で決めてやるもよし。
どちらにせよ、やると決めたら、やるだけです。

やると決めていない人は、ここでブラウザの右上の × をクリックして、回れ右をしてください。

やると決めている人は、ぜひ 1 年前のご自身と比べてください。
昨年の自分よりもできることが増えていますか？

よく他人と比較する人がいますが、はっきり言って、無意味です。比較は常に自分とするべきです。なぜなら、スキルは自分にあるからです。また過去の自分と比較すると、嘘が付けないんです。自分の中の話ですからね。誤魔化せない。ここ、大事です。

できたことはできた。できなかったことはできなかった。
反省の第一歩はここから始まる。そしてそれが成長になる。

**BI (Business Intelligence)** という観点で言えば、組織において、必要なことができていますか？
ビジネスデータを基にして、ビジネスを加速するのが、最大の目的のひとつでしょう。

- 明日何をすれば、目標に近づくのか？
- 何か異常なことは起きていないか？
- 今期、あといくらお金が使えるのか？
- 目指すべき場所に対して、現在地はどこなのか？

こういったことに答えられる状況にありますか？
きちんと BI をやっていれば、答えられるでしょう。
答えられないのであれば、やることがあるということです。できれば、年内に明らかにして、来年に備えておきたいとことですね。

ということで、仕事で Power BI の研修やコンサルティングをしていて、**Microsoft MVP** を受賞している私が Power BI の今年を振り返りながら、来年に向けて徒然なるままに語っていきましょう。

:::note warn
Microsoft MVP は Microsoft 社員ではありません。社員以外の人を対象にしたアワード制度です。詳細は [公式の MVP サイト](https://mvp.microsoft.com/ja-JP/faq?section=mvp#mvp-program-information-0)をご覧ください。ここから書いていくことは、現時点で私が勝手に思っていることです。あしからず。
:::

# [投稿者の皆様へ] お疲れ様でした🕊️
毎年恒例のことですが、やはりこれは言っておかなければなりません。
Advent Calendar に投稿された皆様、お疲れさまでした。とても為になる記事をありがとうございました。

師匠ですら走るという師走に、コミュニティのために自らの時間を使い、ボランティア活動をされた皆様には、きっと近いうちに良いことがあるでしょう。神様は見ていますからね。そう考えなければ、不公平です。

初めてブログを書いた人はもちろんのこと、ブログを書くことに慣れている方でも、多忙な時期にご自身の知見や経験をまとめ、発信する。これは賞賛されるべきことです。読まれた方はぜひとも いいね! やコメント、SNS での共有でその賞賛を示してあげてください。

# Power BI をやっているとやはり無視できない Fabric？
2023年から今年にかけて、Power BI ユーザーの皆さんは Microsoft Fabric を気にしてきたことでしょう。来年2025年を考えるうえでも、Fabric に言及しないわけにはいきません。

ここからは Fabric について、私が思うことを書いておきます。

## Fabric をやらないとダメなの？ - 私の本音を書いておこう
**Microsoft Fabric** が登場してからというもの、Data Platform の分野では Microsoft はすっかり Fabric の話ばっかりになりました。Build や Ignite で、"Power BI" というキーワードで検索しても、該当のセッションが見つからない始末。

「Fabric をやらないとダメなの...？」
「そうはいっても、うちの組織じゃ、そんな予算出ないよ...」
「仮に予算があっても、そんな人的リソースないよ...」

実際そういう声も聞きますし、質問もされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/152946/6bee9504-2a16-ab77-f536-534fb2bc2d20.png)

https://learn.microsoft.com/ja-jp/fabric/get-started/microsoft-fabric-overview

ご覧の通り、Power BI は Microsoft Fabric の中にあります。Fabric では、それぞれをワークロード (Workload) と呼んでいます。

## Fabric が出てきた背景
2015年にリリースされた Power BI は、十分にサービスとして成功しています。リリース以来、多くのユーザーに受け入れられて、継続的に利用されているからです。事実、ユーザー数は右肩上がりだと Microsoft のイベントでも発表されています。

Fabric に含まれる他のワークロードは、もとは Microsoft Azure に存在していたサービスです（現在も存在しています）。Data Factory は Azure Data Factory、Data Warehouse は SQL Data Warehouse ⇒ Azure Synapse、その他 Data Engieering は Azure Notebook、Data Science は Azure Machine Learning などです。

それらが PaaS (Platform as a Service) として Azure 上で提供されていたわけですが、ものによっては、成功とは言えない利用状況にありました。そこで、サービスとして成功していた Power BI の UI を利用して、ひとつのサービス群にし、リブランディングしたように見えるのが Microsoft Fabric です。また、Azure 上で提供されていたそれらサービスは、その利用用途を考えると、組織内で完結するシナリオが多かったのではないかと推測されます。これもまた、Microsoft Fabric として SaaS (Software as a Service) という形態で提供するに至った理由なのではないかと、考えられます。

もちろんこれは、いい流れだと言えます。グローバルでの反応を見たとき、多くのユーザーに受け入れられているからです。ひとつの組織において、Data Platform を構築する際に、ひとつのサービスで完結することは望ましいことです。All-in-one であることは、サポートや請求の観点から、歓迎される傾向にあります。

## 【私の答え】必ずしもすべてを使う必要はない
ただ、Power BI が Fabric の一員になったから、Fabric のすべてを使用しなければならない、ということではありません。自組織に必要なものだけを使えばいい。これが先ほどの質問に対する私の答えです。

## Power BI は単独で Power BI です
Fabric の一員になったとしても、Power BI は Power BI です。単独でひとつのサービスであり、それだけで組織の課題を解決できているのであれば、決してそのことは否定されるものではありません。

## OneLake は素晴らしい
Fabric の最大の利点は、**OneLake** です。これは OneDrive for Data (データのための OneDrive) という表現で説明されています。通常の OneDrive は **ドキュメント** のために存在することから、対照的に **データ** のためと表現されているわけです。組織に必要なデータを OneLake にすべて集めておくことで、一元管理が可能となります。これは2次的データで問題ありません。つまり、OneLake にしかそのデータがないという状態からはじめるのではなく、元のデータは現在存在する場所 (DB やどこかのクラウドストレージ) にある状態で、そのコピーを OneLake に定期的に持ってくればいいのです。幸いなことに、データ元が更新されたら、OneLake に差分データを持ってくるという機能が搭載されています。つまり、手動でデータを同期する必要はありません。

:::note info
Microsoft Ignite で SQL database in Fabric が発表されました。これにより、1次データを Fabric の中に保存できるようになります。が、現在はまだプレビュー機能ですので、本番運用は GA されてからでしょう。

https://learn.microsoft.com/ja-jp/fabric/database/sql/overview

また、Fabric 内に1次データが保存できる機能が提供されたとしても、必ずしもそうしなければならないということではありません。あくまでも選択肢が増えたということです。自社で独自に作っているシステムのデータベースを SQL database in Fabric にすることができる（つまり OLTP として利用可能な）わけですが、1次データは別に分けておきたいと思うことは、エンジニアであれば、当たり前に考えることです。将来的に移行しなければならなくなった場合のことが頭にチラつくからです。
:::

## Fabric はエンタープライズ向けだが、どんな企業にとっても必要なもの含んでいる
加えて、Fabric はライセンス的に Power BI Premium の後継を担っています。Power BI Premium はエンタープライズ向け（大企業向け）に提供されていたライセンスです。使える機能もエンタープライズ向けです。したがって、ある程度以上の企業規模であれば、Fabric の利用を検討するべきでしょう。個人的には、きちんとした企業であれば、その規模にかかわらず、必要になるはずだと思っています。ただ、最初から Fabric に手を出すと、なにをどうすればいいのかわからないということになります。ですので、ゆくゆくは Fabric を利用することを目指して、Power BI Pro から始めて、順にステップアップしていくというのが、よいと思います。

## Power BI ユーザーは BI に必要な部分を利用すればよい
Fabric には既述した通り、多くのワークロードがあります。ですが、最初から「全部使ってやる！」なんて意気込んでしまうと、一向に活用できないということになりかねません。私が Power BI ユーザーにお勧めしたいのが、まずは BI に必要な部分だけ使いましょうということです。

Power BI Pro の範囲でやっている場合、データをセマンティックモデルにインポートして、レポートを作成。さらにセマンティックモデルを共有して再利用しているかもしれません。さらに Power BI dataflows を利用して、データを取得する部分をより細分化および最適化しているかもしれません。その場合、データはセマンティックモデルかデータフローに存在していることになります。

Fabric を使用すると、まずはそれらのデータを OneLake に持ってくることになります。そうして、OneLake にあるデータからセマンティックモデルを作成し、レポートを作成する。こうするだけでも、価値があります。データは OneLake に集約され、インポートモードと DirectQuery のいいとこ通りをした DirectLake モードでアクセスできるようになるかもしれません。

## その先に Fabric 特有の利点が待っているかもしれない
Fabric ライセンス (キャパシティ) があれば、Copilot も使えるようになります。

今年の Ignite で Power BI Pro ユーザー向けに Power BI 用の Copilot キャパシティをライセンスとして提供する計画があるよーと発表されました。つまり、Power BI Pro ユーザーは今後 Copilot キャパシティを追加購入すれば、Fabric キャパシティがなくても、Copilot が使えるようになるということです。

これは私の予想ですが、それなりの価格で提供されることが予想されます。おそらく十分に「高っ！」と思う価格です。相対的に使える機能を鑑みると、Fabric の方がお得に感じられるのではないかと思います。とはいっても、Fabric で Copilot が利用できるのは F64 以上なので、1か月動かし続けると、約 90 万円/月 以上となります。

ご利用は計画的に、と言わざるを得ません😇

https://azure.microsoft.com/ja-jp/pricing/details/microsoft-fabric/#pricing

SaaS のクラウドサービスですから、その利活用はユーザーにかかっています。それには十分に習熟したユーザーになることが求められます。ですので、十分に計画をして、段階的にステップアップしていくことが必要となるでしょう。

そう、約 90 万円/月が特別高いと思わないくらいに習熟すればいいのです✨

また、社内を探せば、Python ユーザーがいるかもしれませんし、統計学に精通しているユーザーいるかもしれません。学生時代に機械学習を研究していた人がいるかもしれません。そういったユーザーがいれば、これまでできなかったことが、Fabric でできるようになります。

## BI を広めるときと同様に求められる役割はたくさんある
Fabric には組織として Data Platform に求める機能が提供されており、現在もまだ進化中です。たくさんの機能が提供されており、使える状態にあるということは、それだけの役割（ロール）が必要だということになります。

間違っても、すべてを把握しているひとりのスーパーマンがいれば、なんとかなるというものではありません。ひとりのスーパーマンよりも、それぞれの専門家が必要となります。逆に言えば、専門家がいないワークロードは、すぐに使う必要はないわけです。十分に試用してから、実運用に乗せる。それには、十分な余裕（予算と時間）が必要となります。余裕を生む計画を立てましょう。

https://learn.microsoft.com/ja-jp/power-bi/guidance/fabric-adoption-roadmap

## Power BI ユーザーへのお勧め
Fabric の利活用は Power BI が使えるようになってからで十分です。Power BI さえも利活用できないのであれば、Fabric の利活用は難しいでしょう。その際に意識するのは、データの流れ、そしてその仕組み（アーキテクチャ）です。機能ベースで考えるのではなく、組織として、

- 課題は何か？
- どうやったらその課題は解決するのか？
- その課題に対して必要なデータはどこにあるのか？
- そのデータから何がわかればビジネスが加速するのか？
- 2年後、3年後、5年後、10年後、どうなっていたいのか？

これらを十分に考える必要があります。ポイントは走りながら、考えることです。今できることは今やりましょう。検討が終わってから、なんて言ってると、数年間ずーっと検討しているなんてことになりかねません。（←よくあるんだ、これが😇

また、継続して Power BI そのものを学習することも大事です。ひとりでも多くの人が Power BI でレポートを作成できるようにしましょう。そういう役職にない人には、ワークショップを実施してください。一度でも経験しておくと、レポートを作成することがどれだけ多くのことを考えなければならないか、理解できます。

他にもデータそのものについての学習も効果的です。

- データとは何か？
- どうあるべきか？

これは組織内の Excel ユーザーさんにも考えてほしいことです。

# 最後に
Fabric に振り回されないでくださいね。皆さんにとって、組織にとって、必要なものを選びましょう。BI は組織で取り組むものです。ひとりで担当するものではないですし、ひとりでできるものでもありません。組織において、チームを構築し、社内コミュニティを構築しましょう。

:::note info
Microsoft は来年も Fabric を当然、推してくるでしょう。提供元ですから、最新のもので夢を見せる必要があるからです。それ自体は、提供元としては至極当然です。ユーザーに求められるのは、その中から自分に必要なものを選択するチカラを身に着けることです。これは Copilot にも同じことが言えます。

デモを見て「すげー」「やべー」なんて言っていると、活用はできません。まずは「自組織に必要なものか？」を冷静に考えてください。
:::

というわけで、2024 年の **Power BI Advent Calendar** は以上です。

:::note info
Power BI を組織として、基本から学びたいぞ！って人は、お仕事のご依頼、お待ちしております。お気軽にご連絡ください！
:::

**皆様の来年がよりよい **Power BI Year** になることを心より願っています。**
Yugo でした🫡👋