2015/04/21

Excel ブックを開かずに複数ブックの数値を集計する - SharePoint ドキュメント ライブラリ列との連携

複数の Excel ブックの数値を集計する作業を自動化したい、という要望は昔からの鉄板ネタです。Excel VBAを使うことで実は比較的簡単に他のブックからデータを読み取ることは可能ですが、Office TANAKA/実践ワークシート協会 代表理事 田中曰く、「ユーザーがつまづく問題はそこじゃない」とのこと。

オブジェクトの階層構造を理解して、適切にブックや行・列、セルを指定できれば、画面がちらつくこともなく、複数ブックからデータを集約することが可能ですが(一方で、本来ちらついてはいけない画面のちらつきを防ぐという鉄板QAもある)、問題はフォルダー名やブック名で、その命名規則にブレがあったり、そのためファイルやフォルダーが見つからなかった場合のエラー処理の扱いが Excel VBA ユーザーを悩ませる大きな原因とのことです。

実は SharePoint Server の文書ライブラリ(ドキュメント ライブラリ)の機能のひとつとして、Office 文書のドキュメントプロパティと SharePoint のドキュメント ライブラリ列の連携というものが昔からあります。最新の Office 365 の SharePoint Online のドキュメント ライブラリでも同様です。

簡単にいうと、セルの情報(文字でも数値でも、日付でも)を SharePoint のドキュメントライブラリー列に表示して、ブックを開くことなしに、SharePoint 上で参照や集計ができる、という機能なのです。

Excel ユーザーにとっては 夢のような機能 だと思えますよね。

でも、いつものように、いくつか落とし穴があります。SharePoint Server / SharePoint Online をある程度勉強しないと理解するのが難しい仕組みがあるので、そのあたりも今回は紹介します。

SharePoint ドキュメント ライブラリの列

SharePoint のドキュメント ライブラリは Web ベースの共有フォルダーのようなものですが、そこにある「列」は、通常ファイルの「名前」や「更新日」、「更新者」くらいしか意識していないのが普通でしょう。
r2co20150420a
この列にユーザーが作成したカスタム列を追加して、Excel のブックにあるセルの内容を表示させよう、というのが、ドキュメントライブラリ列と Excel ブックの連携です。たとえば以下のようになります。

ブック/ワークシートの支店名と合計のデータ

r2co20150420b

ドキュメント ライブラリ列連携後のドキュメント ライブラリの表示

r2co20150420c
赤の部分は、ブックをドキュメント ライブラリに保存することで、ブックのセルのデータを参照して、ドキュメント ライブラリの列として表示しています。

もちろん、「数値」属性の列であればドキュメント ライブラリ内で合計も可能です。

r2co20150420d

この機能を使えば、ドキュメントライブラリに Excel ブックを保存したり、アップロードするだけで集計してくれるわけです。

Excel の観点からすれば「名前」と「内容にリンク プロパティ」がポイント

Excel 側での設定は、比較的シンプルなものです。

表示させたいデータが入っているセルに「名前」を付ける、ブックの詳細プロパティの [ユーザー設定] で名前にリンクしたプロパティを追加するだけなのです。

r2co20150420e

ブックのプロパティとしてワークシートのセルの内容を参照できようにして、SharePoint がブックを開かずにプロパティを参照し、その参照先がセルのデータである、という仕組みになります。

このように Excel 側の設定は非常にシンプルですが、SharePoint 側に設定はこれほどシンプルではありません。

この連携を可能にするためには SharePoint の「コンテンツ タイプ」を理解しないといけないのです。

コンテンツ タイプとは

コンテンツ タイプが難しいのは、コンテンツ タイプを使わなくても通常 SharePoint で文書共有や管理ができるからだと思います。必須の機能ではないことと、かなり概念的な部分もあるため、設計や運用が難しいと考えられます。

理想論的に考えると、企業や組織で扱う業務上必要な書類・ドキュメントは管理されなければなりません。そのため、どんなドキュメントが、何種類存在しているか、そのドキュメントはどんな項目を含んでいるか、といったことを包括的に管理するための「ドキュメントの単位と種類」を扱うために「コンテンツ タイプ」があると言えるでしょう。

マイクロソフトの開発者向けサイト MSDN のコンテンツ タイプの説明で以下のような文章があります。

「たとえば、業務で、経費明細書、発注書、および請求書という 3 種類のドキュメントを使用するとします。この 3 種類のドキュメントは共通の特性がいくつかあります。その 1 つは、これらのドキュメントはすべて財務関係のドキュメントで、通貨の値を使用したデータを含んでいます。ただし、各ドキュメントはそれぞれ独自のデータ要件、ドキュメント テンプレート、およびワークフローがあります。このビジネス問題に対する解決策の 1 つは、4 つのコンテンツ タイプを作成することです。 1 つ目のコンテンツ タイプ財務関係のドキュメントでは、組織内のすべての財務関係のドキュメントに共通するデータ要件をカプセル化します。残りの 3 つのコンテンツ タイプ経費明細書、発注書、請求書では、財務関係のドキュメントから共通の要素を継承します、、、、」
(MSDN Office デベロッパー センター SharePoint リスト データ モデル - コンテンツ タイプより引用)

財務JPG

コンテンツ マネジメントの書籍などを読むと、まるで図書館司書のような役割を持った人が組織内の「ドキュメントとデータの種類」を管理してコンテンツ タイプとしてまとめていくようなことが紹介されています。実際、そのような事例として SharePoint のサイト コンテンツ タイプ(そのサイトで使うコンテンツ タイプ=コンテンツの種類)の「ドキュメント コンテンツ タイプ」にある Dublin Core 列(ほとんど使う状況にはならないはずです)では 17 のデータ要素(列)を定義していますが、その定義は WWW(ウェブ)上のリソースに関する情報を定義するために作られた ISO 15836 といった国際標準規格です。(Wikipedia – Dublin Core)

と、難しい話になりましたが、要は、ドキュメント ライブラリの列として、Excel ブックのプロパティを連携させるには、利用する Excel ブックというコンテンツの種類(コンテンツ タイプ)を作成して、そのコンテンツ タイプ(ブック)にはどんなデータ要素(プロパティ)が含まれるかを定義して、はじめて利用可能になる、と言えます。

Excel 連携用のコンテンツ タイプを登録(作成)する

ドキュメントの「種類」を登録すると理解して、「Excel 各支店XXXレポート」といったコンテンツ タイプを SharePoint に作成します。
Excel ブックを保存したいドキュメント ライブラリを作る予定のサイトに移動して、画面右上の歯車アイコンから [サイトの設定] を選び、サイトの設定を表示します。
[Web デザイナー ギャラリー] の [サイト コンテンツ タイプ] を選択します。

サイトの設定1

[サイトの設定 > サイト コンテンツ タイプ] の [作成] をクリックします。
ここで行う作業は実はあまりありません。変数の宣言のようなもので、「使いますよ」と言っているだけです。
[親コンテンツ タイプ] の指定は、Excel ブックなので [ドキュメント(文書)] だと考えて、ドキュメントのものを使ったほうがいいでしょう。

コンテンツタイプ1

コンテンツ タイプを作成すると、詳細について設定する画面に移ります。

コンテンツ タイプは、上の MSDN の例でいえば個別の発注書を作るときに参照する「テンプレート」のようなものです。この考え方は Excel にも当てはまり、たとえば、Excel のブックで名前とユーザー定義のカスタム プロパティの設定をしていないブックを保存したところでなにも起こりません。このコンテンツ タイプと関連付けられている「テンプレート」を登録することで、SharePoint のサイトでそのテンプレートを使った個別のドキュメントが SharePoint で作成できるようになります。(この作成手順は後で紹介します)

その指定を [設定] の [詳細設定] ですることができます。[詳細設定] をクリックすると [ドキュメントのテンプレート] を指定する項目があります。予め名前やカスタム プロパティの設定を行ったブックを xltx 拡張子でテンプレートとして保存しておき、ここで指定することができます。

コンテンツタイプxltx指定

これでサイトへのサイト コンテンツ タイプの設定は終わりました。この設定により、この例では [Excel 各支店レポート] コンテンツ タイプを指定することで、[各支店レポート.xltx] テンプレートを使って Excel のブックを作成できるようになりました。

次は、この Excel ブックを扱うドキュメント ライブラリの設定になります。

ドキュメント ライブラリで Excel のプロパティ~列連携の設定する

Excel ブックを保存するドキュメント ライブラリに列を追加して、Excel のプロパティを表示させるように設定します。
そのために、まずこのドキュメント ライブラリでコンテンツ タイプを使えるようにします。

ドキュメント ライブラリの画面でリボンの [ライブラリ] タブにある [ライブラリの設定] を選び、設定画面を表示し、[全般設定] の [詳細設定] をクリックします。
[設定 > 詳細設定] の画面で、[コンテンツ タイプ] で管理を許可するで [はい] を選びます。

doclibsetting1

この時、[ブラウザーで開くドキュメント] の既定の表示方法は [クライアント アプリケーションで開く] にしておきます。
セルにリンクされたプロパティを持つ Excel ブックは Excel Online で編集できないからです。

次に列の追加をします。

この連携は単純に Excel のプロパティ名と、SharePoint の列名の「文字列比較」しかやっていません。タイプミスに注意してください。

ドキュメント ライブラリの設定の [列の作成] を選びます。

doclibsetting2

Excel のプロパティ名と同じ名前の SharePoint の列を追加します。
事前に作成した Excel のプロパティは以下です。

各支店レポートプロパティ

  • 支店名 テキスト
  • 合計金額 数値
  • 計上月 テキスト

と同じ名前、同じ属性で列を追加します。途中の Conten...はコンテンツ タイプのテンプレートとしてアップしたブックに自動的に追加されるものです。

[列の作成] の [列名] や [この列の情報の種類] を Excel ブックのプロパティに合わせてそれぞれ作成します。
この時、[すべてのコンテンツ タイプに追加] のチェックを必ずはずしてください。これをはずさないと、変更・保存したときにセルの新しい内容が列に反映されません。

doclibsetting3

列の追加後

doclibsetting4

まだ終わりではありません。

最後にサイトのコンテンツ タイプ登録で指定した xltx テンプレートを使った Excel ブック作成をこのドキュメント ライブラリでできるように指定します。

ドキュメント ライブラリの設定の [コンテンツ タイプ] の [既定のサイト コンテンツ タイプから追加] を選び、このドキュメント ライブラリで使用するコンテンツ タイプを追加します。

doclibsetting5

これで基本的な設定が終わりました。

それではドキュメント ライブラリの画面を見てみましょう。

ドキュメントライブラリ列

支店名、計上月、合計金額が「列」として追加されているのがわかります。

[新しいドキュメント] をクリックすると、コンテンツ タイプのテンプレートとして登録した xltx が表示されます。

ドキュメントライブラリ列2

この [Excel 各支店レポート] をクリックすると、Excel が立ちあがり、Excel各支店レポート.xltx を使ってブックが作成・表示されます。

ブックを保存するときは、[名前を付けて保存] を選び、[現在のフォルダー] であるドキュメント ライブブラリを指定します。
保存するときの名前は一意の名前とします。命名規則などを工夫して一意になるようにしてください。

ブックが保存され、ドキュメント ライブラリを見るとテンプレートから作成されたブックのプロパティの値が列に表示されていることが確認できます。変更がないようだったら F5 でブラウザをリフレッシュしてください。

ドキュメントライブラリ列3

一度、ドキュメント ライブラリに登録・保存したブックを再度開いて編集、上書き保存しても、その変更内容は SharePoint の列に反映されます。
以下では 20150001.xlsx をドキュメント ライブラリから開き、Excel で編集し、上書き保存した結果です。

ドキュメントライブラリ列4

なお、集計などを追加するには列の [ビュー設定] から行います。

SharePoint のドキュメント ライブラリやリストは「ビュー」という機能を持っています。
合計を表示するビュー、支店ごとにグループ化したビュー、計上月ごとにグループしたビューを作成することで、報告書ブックを保存する「だけ」だったドキュメント ライブラリがちょっとしたダッシュボード(現状を確認するための情報提供画面)に変わります。それも VBA を使わずに複数ブックの集計を自動的に、リアルタイムにしてくれます。

既定の列の並び順などもビューで変更が可能です。

ドキュメントライブラリ列5

サンプルデータを入れて、いくつかのビューを作成したものが以下になります。

既定の[すべてのドキュメント]ビューに合計をいれたビュー
すべてのドキュメント合計

月別にグループ化したビュー
月別

支店別にグループ化したビュー
支店別

Excel エクスポートで集計ブックを作成

ここまで来て、「いや、SharePoint で確認できるメリットはわかったが、複数ブックから必要なデータを集計する「ブック」が欲しい」という人もいるかもしれません。

こうやって SharePoint 側にデータがあれば、[Excel にエクスポート] を使えば、列の情報を「テーブル」として Excel に取り込むことが可能になります。

Excelエクスポート

この機能により、SharePoint の列データをテーブルとして取り込んだ結果が以下になります。

エクスポートテーブル

良いことづくめのようですが、ちょっとした落とし穴もあります。最後はそれを紹介します。

日付でグループ化したいがドキュメント ライブラリで年月にならない

Excel で日付(シリアル値)のセルを表示形式で「2015/01」のようにしても、SharePoint の列には表示形式で設定した結果ではなくシリアル値もしくはシステム設定の日付表記の文字列が入ります。

よって、年月などでグループ化したい場合は、2つの方法があります。

1) Excel 側で TEXT 関数を使ってシリアル値を YYYY/MM などの文字列にしておく。もちろん、プロパティや列の属性は「文字」「テキスト」です。

2) Excel 側ではなにもせず、SharePoint 側で列属性を日付で取り込み、集計列を追加し、TEXT 関数を使って YYYY/MM を取り出し、集計列でグループ化する。

SharePoint の日付の扱いは「シリアル値」です。集計列の数式では Excel と同じような関数が使えます。

参照 Excel ユーザーのための SharePoint リスト「集計値」列

ドキュメント ライブラリにある Excel ブックを開いて更新、上書きしてもドキュメント ライブラリの列の値が変化しない

セルの値を変更するとブックのユーザー定義のプロパティは更新されているのに、その変更が SharePoint の列に反映されない場合があります。
これは SharePoint の列の作成の際に [すべてのコンテンツ タイプに追加] のチェックボックスにチェックが入ったまま列を作成したためです。このチェックがオンになっていると、SharePoint 側に登録しているコンテンツ タイプ(ドキュメント プロパティ サーバー として Excel でもドキュメント情報パネルで表示・編集できる列)が優先されるため、Excel ブックのユーザー定義のリンク プロパティの変更が SharePoint 側で反映されないためです。

r2co20150420f

Excel ブックの変更をドキュメント ライブラリの列に反映させたい場合は、[すべてのコンテンツ タイプに追加] をオフにして列を作成します。

Excel Online で Excel ブックの編集ができない

メッセージの通り、これは仕様です。ローカルの Excel で編集するしか今は無いようです。

ExcelOnlineで編集できない

サイト コンテンツ タイプのテンプレートは使いたくないが、集計やグループ化はしたい

ユーザー設定のリンク プロパティが設定されたブックをそれぞれが持ち、指定された SharePoint のドキュメント ライブラリに保存、列で集計するだけでよい、という要望もあるでしょう。

その場合は、上記手順の「Excel連携用のコンテンツ タイプを登録(作成)する」を飛ばし、「ドキュメント ライブラリで Excel のプロパティ~列連携の設定する」から始めることで可能です。その時、一番最後の「既定のサイト コンテンツ タイプから追加」をやる必要はありません。

これで、列だけを追加し、ブックをアップロード、ドラッグ&ドロップすることで同様の結果を得ることができます。

ただし、サイト コンテンツ タイプは最初はとっつきにくいですが、多くのメリットがあります。ひとつは「テンプレート」です。細かな修正が入る度にテンプレート ブックの再配布や、共有フォルダーからのダウンロードをお知らせしていませんか?サイト コンテンツ タイプで登録した xltx ファイルは直接修正・保存することが可能です。これにより、大元のテンプレートを修正するだけで、次から作成されるブックはそのテンプレートを参照するのです。これは大きなメリットです。

テンプレート編集

かなり長いブログの投稿になってしまいましたが、最後の最後、この連携は SharePoint のスキルの有無ではなく Excel のワークシートをどうつくるか、という知識やテクニックの問題になります

Excel 側で「入力・計算・出力」といったデータの流れ、処理の流れを意識したワークシートを作っていれば、比較的 SharePoint 連携の Excel 側の作業は簡単でかつシンプルなものでしょう。出力の役割のセルに「名前」を付け、プロパティ登録するだけです。SharePoint 側の設定は簡単ではありませんが、その仕方さえ覚えてしまえば、それを繰り返すだけです。方や Excel のワークシート設計は業務によって変更せざるを得ません。

よって、Excel ユーザーの培ってきた知識、スキル、テクニックは Office 365 / SharePoint Online でも十分使えるどころか必須だと考えています。

加えて、ドキュメント ライブラリ~Excel 連携は、コンテンツ タイプの考え方がないと迷うことが多くなります。
ドキュメント ライブラリへのコンテンツ タイプの登録は複数可能です。どの種類のブックをひとつのドキュメント ライブラリにまとめるか、どのデータを列として表示させるか、といった「設計」はコンテンツ タイプの考え方なしではかなり難しいでしょう。

この投稿が少しでもお役に立てば幸いです。


参照 マイクロソフトのブログより

2006年2月 Excel のセル内容をドキュメントライブラリに表示する
(MSDN Blog - GroupBoard Blog  情報が古いが今でもほぼ同じ内容)
http://blogs.msdn.com/b/groupboard_blog/archive/2006/02/24/538561.aspx

2014年6月Excel 2013 セルと SharePoint ドキュメント ライブラリ列の連携方法
(TechNet Blog - Japan SharePoint Support Team Blog)
http://blogs.technet.com/b/sharepoint_support/archive/2014/06/27/excel-2013-sharepoint.aspx

2014年7月 Excel のドキュメント プロパティと SharePoint ドキュメント ライブラリ列の連携方法
(TechNet Blog - Japan SharePoint Support Team Blog)
http://blogs.technet.com/b/sharepoint_support/archive/2014/08/01/excel-sharepoint.aspx

MSDN より

2010年11月1日 コンテンツ タイプについて
https://msdn.microsoft.com/ja-jp/library/office/ms472236%28v=office.14%29.aspx

2015/03/25

Excel ユーザーのための Power BI 系インストールのお話

[追記] Power Query のシステム要件が v2.22 以降で変わりました。こちらを参照ください[追記終わり]
[追記] Power BI Desktop や Power BI といった Excel アドインではないサービス、製品との比較はこちら。[追記終わり]

以前、実践ワークシート協会でユーザー主催の勉強会に呼ばれた時の話を思い出して、あらためて Microsoft が現在 Excel 周りで推し進めている Power BI のアドインである Power Query、 Power Pivot、 Power View そして Power Map のインストールについて纏めてみたいと思う。

実は Power BI を使う以前の状態だった

一般の現場であった事実をご紹介する。
これは昨年の夏のことであるが、6人ほどの小規模なユーザー勉強会に協会代表理事の田中亨(Office TANAKA)と私が招待された。
このユーザーグループのメンバーは Excel のことは標準ユーザーレベル以上によくご存じであり、業務で Excel VBA も使いこなしている方々である。

Power Pivot や Power Query といった Power BI 系のアドインは、Microsoft SQL Server/Analysis Services 側の Excel アドインから派生した経緯もあり、また、Office 365 クラウド サービスの一部的な扱い方をされている関係で、PC にインストールされた Excel を主に利用しているユーザーが全くその存在を「知らない」ことが多い。これは実践ワークシート協会主催の Excel VBA セミナー の受講者の皆さんの現状を聞いても「知らない」と言うユーザーが多いことである程度は予測していた。

とはいえ、勉強会に参加するメンバーに Power BI を紹介したいと思い、事前に利用している Excel のエディションを聞いたところ、6人中、以下のような回答であった。

  • Home and Business 5人
  • Professional 1人

これでは、Power Pivot や Power Query を紹介しても、まさに「絵に描いた餅」でしかない。
なぜなら、多勢を占める Home and Business や Professional エディションでは Power BI のアドインはインストールできない、利用できないからだ。
以下が Power BI アドイン Power Query の使用前提条件である。

Power Query のシステム前提条件

マイクロソフトの office online のヘルプには2つのバージョンがあるとしている。1.5 と 2.1 (2015/3 現在の最新は 2.2)が紹介されている。

Microsoft Power Query for Excel のヘルプ

普通に Power Query のダウンロードを検索するとダウンロードセンターでヒットするのは最新版の 2.X 系である。

Microsoft Power Query for Excel (microsoft download center)

2015年3月のバージョンは 2.20.3945.242 であり、公開日は 2015/03/04 である。
このバージョンのシステム要件、特に Office のエディションは以下と明記されている。

  • ソフトウェア アシュアランス付きの Microsoft Office 2010 Professional Plus
  • Microsoft Office 2013 Professional Plus
  • Office 365 ProPlus
  • Excel 2013 スタンドアロン

この「Excel 2013 スタンドアロン」をみて多くの Excel ユーザーが自分の Excel は使えると(たぶん)勘違いするだろう。
Excel 2013 スタンドアロンとは「エディション」の名前であり、わかりやすく言えば「Excel だけパッケージされた(割高な)製品」のことだ。

英語ブログ Yes, Excel 2013 Standalone Now Includes Power Pivot.(For real, normal people have it)
Power Pivot が無ければ、Amazon から Standalone download 版の Excel を購入してみては?という記事。

Office スィートに入っている Excel、そこから、たとえ Excel のみインストールして、それを「単体」で使用しているからと言っても、それは Excel 2013 スタンドアロン エディションではない。

言えば、「個人・家庭向けの Office スィート エディションに入っている Excel は対象外」である。Solo、Personal、Home and Business、Professional エディションは個人・家庭向けの Office エディションだ。マイクロソフトの製品紹介では「ビジネス向け」に Solo、Home and Business、Professional がリストされているが、それは「日本において業務上で利用が可能」という条件の元で「ビジネス向け」といっているだけなのだ。

http://products.office.com/ja-JP/buy/compare-microsoft-office-products

Professional エディションについても勘違いしてはいけない。システム要件には 2010 も 2013 も「Professional Plus」エディションと表記されている。Plus があるのとないのとでは大きな違い(として扱われているの)だ。

OfficeProfessionalPlus2010

Office2013ProfessionalPlus

office365proplus

結局、Office の Professional Plus というエディションは法人向けの販売店・リセラーから購入した Office のエディションであり、ProPlus は Office 365 として購入しインストールした Office のことになる。

ところが、そこでも「?」となるものがある。Office 365 に含まれている Office には上記のシステム要件に「ない」エディションがある。
それが Office 365 Business である。

Office365Business

このエディションに Power Query 2.x のインストールはできない。

Office365BizPQinstall

つまり、企業向けの Office 365 だからといって使えるわけではなく、システム要件に書かれているように「Professional Plus か ProPlus」が絶対条件としての前提なのだ。
ちなみに Office 365 Business Premium という Office 365 もあるが、それも Office のエディションは Office 365 Business だ。

もちろん、つい最近利用可能になった Solo も上記の条件に当てはまらないため、システム要件を満たしていないことになる。

なお、Power Query の 1.5 についてはすでにマイクロソフトのダウンロードセンターからダウンロードができなくなっているので、この選択肢は正式にはすでにない。

ProPlus を含んでいる Office 365 は Office 365 Enterprise と呼ばれ、E3、E4 というサブスクリプション プランのみである。

http://www.microsoft.com/ja-jp/office/365/plan.aspx

前回の投稿で Excel 2016 を紹介したが、2016 では Power Query はアドイン扱いではなくなっている。
今後、これがどのような形で各エディションに展開されるかはまだ不明だが、これまでのマイクロソフトの動きを考えると、Power Pivot のように利用できるエディションのみ選択可能で、そうでないエディションはタブに表示されないか、グレイアウトされるなどの処置が施される可能性が高いと思われる。もしそうでなければその英断を称えたいところだ。

Power Pivot/Power View のシステム要件

Power Query よりはエディションの混迷度合が若干マシなのが Power Pivot だ。アドインであるには変わりないが、現在では最新の Power Pivot をダウンロードセンターからダウンロードできない。
ダウンロードできるのは Excel 2010 用のものだけだ。若干マシ、としたのは、アドインとしてダウンロードするのではなく、すでに Excel 2013 の「オプション」として Power Pivot があるか、ないかで判断可能だからだ。なお、Power View も同様である。

よって使える Excel 2013 のエディションの条件は「Power Pivot が COM アドインとして登録されているか」で確認可能だ。無ければ利用できないと判断できる。
この COM アドインに Power Pivot が含まれているエディションは Professional Plus か ProPlus のどちらかだ。

ExcelComアドイン
Office Professional Plus 2013 の COM アドイン ダイアログ

Power Map のシステム要件

実は Power Map については私自身も嵌ったクチだ。
通常は Office Professional Plus 2013 を使っているのが、Power Map をアドインとして追加しようとしたのだが、過去にできていた Power Map のアドインのダウンロードがない。いや、正確にいうと、Preview 版はあるが、Preview がはずれた正式版がない。

検索をすると Office Online の以下の記事を探し当てた。

Power Map for Excel

つまり、Power Map は Office 365 ProPlus のみ提供になったということだ。今後、Power Map Preview for Excel 2013 の更新は無い、と明記されている。
Power Map も Power Pivot や Power View 同様に、COMアドインになければ利用できない、という提供の仕方になっていたのだ。

PowerMapCOMAddIn
Office 365 ProPlus の COM アドイン ダイアログ

まさか、Professional Plus 2013 で Power Map の正式版アドインが使えなくなるとは思っていなかった。

Power BI サービスの一部だから...

上記のアドインは Power BI サービスの一部だから、、、と言われれば仕方ない。
クラウドやビックデータを扱わない Excel ユーザーにとっても、Power Query や Power Pivot はいろいろと使い道がある非常に有用な機能なのだが、これらのアドインの最終的な目的は Power View による「Power View シート」を作成し、Office 365 の Power BI サイトで組織内で共有する、というものだ。

なお、Power BI のライセンスは Power View シートを作成し、アップロードしたり、BI サイトでデータ マネジメント ゲートウェイを設定する管理者だけが持っていればよい。
共有されるシートの閲覧は、Power BI ライセンスがなくても可能であり、その閲覧のみの「ストアアプリ」がある。

Microsoft Power BI ストアアプリ

ストアアプリのみならず、iPhone/iPad 用の閲覧アプリもすでに公開されている

Microsoft Power BI アップストア

たしかに、このような使い方を前提とすれば、全 Office ユーザーがこの機能を使う必要はなく、限られたユーザーだけに絞っても問題ないという判断もできよう。
しかしながら、実践ワークシート協会の「田中メソッド」による Power BI アドインの区分けを行うと

入力・機能: Power Query
計算・機能: Power Pivot
出力・機能: Power View / Power Map / Power BI サイト

となり、ビックデータを扱うことのないユーザーでも活用の可能性があるだけに残念である。

データ分析の機能については Microsoft が力を入れているエリアであるため、今後またエディション利用条件の変更があるかもしれない。これに懲りずに興味あるユーザーはウオッチしておいて損はないと思う。

2015/03/20

Excel Preview (Office 2016 Preview for Business - Excel 2016)

Office 2016 Preview (for Business) の公開およびダウンロードが開始された。

CNET|Japan
マイクロソフト、「Office 2016」とビジネス向け「Skype」のプレビュー版をリリース

現段階の Excel では以下の変更点がトピックだろう(Preview 版であるため、今後変更が加わる可能性はまだ多いにある)
なお、この Preview 版はいわゆる「Office 365 ProPlus」であり、Office 365 ユーザーが利用できる Office であることに注意されたい。特に Power BI 系についてはエディションにより使える機能が変わる。2016 でもその制限が継承される可能性が高いかもしれないからだ。

[追記] Power Query のシステム前提条件が v2.22 以降かわりました。こちらを参照ください[追記おわり]

[データ] タブに統合された Power Query

現バージョンまでは Power Query はマイクロソフト ダウンロード サイトからダウンロードするアドインの扱いだが、2016 からは [データ] タブに統合されている。
アドインからもなくなり、Excel に完全に統合された形になっている。

2016PowerQueryRibbon

xl2016A

xl2016B

xl2016C

xl2016D

なお、Power Pivot や Power View は現時点でのプレビューではアドイン扱いで、Excel 2013 と大きな違いはなさそうだ。

xl2016E

ただし、オプションの [詳細設定] – [データ] に「データ分析機能をオンにする」というチェックボックスが追加されており、このチェックボックスで Power Pivot のリボンのタブの表示・非表示が可能になっている。

xl2016F

データモデルでもピボットテーブルの 日付のグループ化 が可能に

このタイミングで、この機能が利用可能になったのは、相当ユーザーからの要望が多かったのか、最初から計画されていて技術的目処がついたのか、いずれにせよ Excel ユーザーにとっては非常にうれしい機能追加である。

以前の投稿の「リレーションシップとデータモデル」で、データモデルから作成されたピボットテーブルでは「日付のグループ化」や「集計アイテム」、「集計フィールド」が使えないことを紹介したが、集計アイテムや集計フィールドは Power Pivot と使うことで代用が可能であるが、日付のグループ化は Excel でありながら日付=シリアル値の操作性とは全く異なるため違和感(というか、使いづらい。。。)を感じていた。

リレーションシップを張ったテーブルをピボットテーブルにして、日付のグループ化はもちろん、SharePoint データ接続でデータモデルから直接ピボットテーブルを作成しても日付のグループ化が可能であることは確認できた。SharePoint リストは日付をシリアル値として持っているので、DateTime 型の SharePoint Access アプリ テーブル(SQL Azure テーブル)からデータ接続でピボットテーブルを作成し試してみたが、同様に日付のグループ化は可能だった。今後は「階層」を使わずグループ化ができるのは大きなメリットであろう。

xl2016G

この数日触ってみた感じでは 2013 と 2016 では大きな違いは見当たらない。What’s New を見ても現時点では Excel においては違いはあまりないと言ってよさそうだ。

What’s new in Office 2016 Preview (office online 英語)

ただ、やはり BI まわりの機能強化が多い。

英語ブログであるが、以下は Excel に関する新しい機能を紹介しているので、参照されたい。

Chris Webb’s BI Blog – What’s New The Excel 2016 Preview For BI?

ユーザーが利用するデスクトップ版については、正直のところあまり大きな変化がないのかもしれない。
Office 2016 についてはタッチ版ユニバーサル アプリである Office for Windows 10 のほうが今後話題になることが多いだろう。

Office for Windows 10 と Office 2016 の発表(2015/1/23)

2015/02/26

重複したデータをチェックする - ピボットテーブルの応用

前回は入力されたデータが正しいか、正しくないかをピボットテーブルを使ってチェックする方法を紹介した。今回は「重複したデータのチェック」をピボットテーブルで行う方法を紹介したい。
重複行の削除
以前の投稿で重複行の削除を行ったユニークデータ リスト(テーブル)の作成方法を紹介した。
Power Query を使った重複行の削除
しかし、そもそも入力した段階で「重複してほしくない」というケースは多々ある。Access や SQL Server などを利用するデータベース アプリケーションであればデータベースのテーブル設計で「ユニークなキー」や「一意のデータ」として列に制約をかけて、同じデータを入力させないようにするだろう。
しかしながら、田中メソッドの「入力-計算-出力」の入力でこのような重複データ入力の禁止を Excel で実現するにはいろいろなテクニックを駆使しなくてはならない。
たとえば、Excel の入力規則でユニークデータの制約を行う場合、テーブル、名前、入力規則を組み合わせることで以下のようなチェックが可能になる。
・ 表をテーブルにする(データ増減に対応させるため)
・ 対象となる列を「名前」登録する(入力規則で構造化参照が直接できないため、名前を使う。詳しくはこちらを参照。)
・ 入力規則の [ユーザー設定] の数式を使い、その列でのカウントが2未満の場合だけ入力可能にする
そのほか、条件付き書式を使って重複したら色を変えるなどでチェックする方法もある。
r2co20150226B
一方、入力において SharePoint リストを使っている場合は、いくつかの列の種類の追加設定の [固有の値を適用する] でユニークなデータの列として設定が可能だ。
この追加設定がされた列で重複の列データを入力しようとすると、以下のように「この値は既にリストに存在しています。」と表示されアイテム保存ができなくなる。
SharePointリストユニーク列
実務はもっと複雑だった
実践ワークシート協会の業務で、この重複チェックの必要性が発生するのは複数のスタッフによるセミナー申込登録だった。
複数の人が Office 365 の同一の申込用の共有メールボックスをみて未登録のお申込みを SharePoint リストに登録する業務で、同じお申込みの多重登録を避けたい、という要件だ。
処理をはじめたメールアイテムに Outlook 上で「フラグ」を付けるなどの運用上のルールは設定したが、それにより絶対多重登録がない、とはいえない。
加えて、一意(ユニーク)なデータにする条件が上述の「ユニークキーの設定」で対応できるほど単純ではなかった。
現在、協会の Excel VBA セミナーは「ベーシック」と「スタンダード」の2種類がある。たとえば A さんがこの2つを同時に申し込むと「セット割引」が適用されるため、2つ同時に申し込むことが多く、その時、A さんの名前やメールアドレスはお申込みテーブル上、複数存在することになる。おともだち割引などもお申込みいただいた方のメールアドレスが一意にならないケースがある。同じコースを別の日に受ける再受講といったケースもある。
一意になるのは、受講するコースの、受講する日の、受講者の名前、という組み合わせになる。同じ名前の人が複数人同じ日の同じコースを受講することはない。(同姓同名はカバーできないが)
この制約を実装する方法はいくつかあるが、協会としては 1) SharePoint リスト構造はなるべくシンプルにする 2) SharePoint 開発は行わない と考えていたので、あくまで 1つのお申込み登録リストを使い、入力後に Excel Services / Excel Web Access でチェックする方法を選択した。
この重複チェックにも Excel のピボットテーブルを使っている。
ピボットテーブルで重複データをチェックする
これも入力チェック同様ピボットテーブルの機能を使った実にシンプルな方法である。ただし、Excel のピボットテーブルは単にクロス集計表を作るだけのものではない、という認識が必要だろう。
ピボットテーブルの「値フィルター」を使うことで、受講するコース、受講する日での重複登録された受講生の名前を確認することが可能だ。
以下が、その設定方法と考え方である。
1) ユニークなキーになるための条件である [実施日]、[コース名]、[名前] の順で行を構成し、カウントするために値に [名前]を指定したピボットテーブルを作る
2) ピボットテーブル レポートの [名前] の上で右クリックでメニューを出し、[フィルター] – [値フィルター] を選択する
3) フィルター条件として「2以上だったら」を設定する
この値フィルターは [名前] の上で設定するのがポイントだ。そうすることで日付けとコース名で絞られた後の [名前] の集計に対してフィルターをかけることができる。
コース名や日付の上で [値フィルター] を設定すると、それぞれの集計数に対してのフィルターになるので違った意味になることに注意する。
以下のアニメーション GIF は、岡田さんの登録が多重になっている状態でのピボットテーブルの設定と、多重登録のレコード(行)を削除して、ピボットテーブルを更新するまでの流れである。
r2co20150226A
あとは、このピボットテーブルを Excel Web Access を使って SharePoint の受講申込サイトに貼り付け、入力した後でデータ更新をかけることで、重複登録されているかどうかのチェックが可能だ。
繰り返すが、このような入力業務を数十人でやる場合はお金、時間をかけて入力チェックを組み込んだ入力フォーム、SharePoint アプリを開発すべきだが、10人以下、同時使用も数人という規模であれば、Excel を使うことで対応可能だ。それも VBA を使ったプログラミングではなく、ピボットテーブルと SharePoint と Excel Services の機能を使うことで目的を短期間・低コストで達成できることは中小規模の企業や組織にとっては大きなアドバンテージになると思う。
この投稿がなんらかのヒントになれば幸いである。


[PR] VBAセミナー受講後は、これさえあれば何もいらない

2015/02/24

入力されたデータをチェックする - ピボットテーブルの応用

Excel であったり、SharePoint リストであったり、なんらかの方法で入力されたデータのチェックをする必要が出てきた場合のピボットテーブルの使い方を紹介する。

入力値のチェック

本来、入力時に入力されたデータが正しいかどうかのチェックを行い、もし、間違っているようであれば再入力を促すのが正攻法であろう。Excel ではそのために「入力規則」という機能が用意されている。

[Office Support] セルにデータの入力規則を提供する

また、SharePoint リスト入力でも簡単な入力値のチェックの設定(入力されるデータの「型」の指定など)は可能だ。さらに条件によって入力値のチェックをするのであれば、InfoPath を使ったり、JavaScript/CSS/HTML によるリスト フォームの変更、SharePoint アプリの開発が必要になる。いわゆる「入力フォーム」を作成することになる。

しかし、このフォーム カスタマイズのためのサードパーティーのツールがいくつか提供されているという現状から、すぐに素人が標準機能で作成できるものではなく、それなりにトレーニングを受け、実務で OJT を通して経験を積まなければ、思い描く入力フォームをすぐに作成できないのが現実だ。

アンク様 SharePoint ソリューション

データ入力フェーズとして SharePoint リストや SQL Azure を利用する Office 365 Access アプリといったクラウドサービスの場合は、複数人による利用、入力を前提としている。これらを利用することで Excel 単体のみで「入力ー計算ー出力」の実務データの流れを実装するより、はるかにファイル(ブック)のロックや「他の人が使用中」といった問題、または入力用ブックを多数配布した後の集計をどうするか、といった考慮すべき点が少なくなる。

反面、データの型(文字か、数値か)やデータの範囲の入力制限、ユニークキーといった一意の値の列のみ入力などは容易に設定できるものの、ロジックや条件によって正しいか正しくないかを判定することは、その設定(アプリケーション作成)のハードルがやや高くなることは否めない。

もちろん、この入力業務を数十人以上といった大規模で行うのであれば、お金と時間をかけてでもバリデーションチェックを組み込んだ入力フォームを作るべきだが、3~5人の業務であれば 「注意して入力して!」 と担当者にお願いするのが関の山だ。それでも「誤入力」は起こる。

この誤入力を Excel 側で発見して対応するのが今回の目的である。

VBA は使わない

誤解しないでほしいのは、VBAを使えないわけではない。VBAを使えば、ほぼやりたいことはできる。しかし、VBAは最後の手段としてとっておきたい。理由は「業務上の引継ぎ」での「メンテナンスのためのスキル」からだ。機能や関数はわかっていても VBA はちょっと、、、というユーザーが多いためだが、もうひとつ、その他の要素として Office 365 SharePoint Online との親和性の問題がある。SharePoint Online 上の Excel Online で VBA を動かすことができないからだ。VBA を含んだブック (.xlsm) は一度 PC にダウンロードして、PC 側の Excel で開くことで利用が可能だが、できれば Excel Online だけで完結する方法をまずは検討してみたい。

入力された値が正しいかチェックする

ピボットテーブルというと「クロス集計表」を作るためのもの、と認識されるだろう。ピボットテーブルの主たる目的はそのためであり間違いではない。ただ、ピボットテーブルの「可能性」を認識してもらえば、さらに応用がきく使い方ができる。そのひとつが入力値のバリデーションチェックだ。
バリデーションチェックのパターンとして入力された値が正しいかどうかのチェックをしたい場合がある。 たとえば以下のようなケースだ。

・ 入力された価格が価格テーブルのものと同じかどうか

以下は実践ワークシート協会の VBA セミナーのお申込み管理の事例だが、VBA セミナー(ベーシックコース、スタンダードコース)の標準受講料は 49,800 円である。ただし、割引制度がいくつかあり、割引によって受講料が変わる。

・ 標準受講料 49,800円
・ サポーター割引 39,800円
・ 継続割引 39,800円
・ セット割引 35,000円
・ おともだち割引 35,000円

このような入力の場合は、通常、選択した割引タイプから該当する授業料をもってくるように入力フォームを作成する。Excel であれば、VLOOKUP 関数やリレーションシップを使うことになるだろう。

r2co20150223_001

SharePoint リストの入力でも同様の設定が可能だ。それが 「参照」 列だが、VLOOKUP との大きな違いとして、VLOOKUP は参照した値(49,800 や 39,800)そのものを入力しているのに対し、参照列は値ではなく ID を参照している。たとえば、継続割引を 39,800 円から 35,000 円に変更しようとした場合、もし割引テーブルを参照している状態でテーブルの価格を変えると、新規入力のものだけではなく、過去のデータもすべて変わるという動きをする。この件は過去の投稿で紹介している。

Excel ユーザーのための SharePoint リスト 「参照」 列

そのため、実践ワークシート協会の申込情報入力では、少しでも入力業務を楽にするために、割引タイプをドロップダウン リストから選択し、対応する受講料もドロップダウン リストから選択する形にした。ドロップダウン リストからの選択は「値」の代入となるからだ。

r2co20150223_002

割引タイプに対応する受講料は入力画面の受講料の例に追記しているが、それでも間違って入力(選択)することがないとはいえない。
協会では、そのチェックを SharePoint 側の開発で行わず、Excel それも Excel Services (Excel Web Access) を使って、SharePoint 上で確認している。そこで使っている機能が「ピボットテーブル」である。

ピボットテーブルとリレーションシップを使った値の比較

実は仕組みはいたって簡単だ。入力されたデータと、本来マスターから取得したかったデータを比較し、同じであれば “OK”、違う値であれば “NG” と表示する数式をいれた集計列を追加して、その集計列の OK と NG をピボットテーブルで表示するだけだ。

第1のポイントは「本来取得したかったデータ」をリレーションシップを使って関連付けし、参照していることだろう。協会の仕組みでは、データ接続タイプは Excel Online 上でのデータ接続更新を可能にするため [データ] タブの [その他のデータ ソース] の [OData データ フィード] を使い、リレーションシップと集計列の追加は Power Pivot を使い、最終的にピボット テーブルを作成した。

r2co20150223_003
データ ダイアグラムによるリレーション

r2co20150223_004
集計列 [金額チェック] を追加し、数式を挿入

r2co20150223_005
ピボットテーブルで [金額チェック] の結果を集計する

第2のポイントは、このピボットテーブルを Excel  Services (Excel Web Access) を使い、入力業務ページの SharePoint 上で即時に更新可能に設定していることだ。こうすることで、わざわざローカル PC で Excel ブックを開くことなく、SharePoint 上でピボットテーブルの更新が可能だ。

問題がなければ、つねに「OK」のみの件数が表示され、問題がある場合のみ「NG」が表示され、NG件数がわかる。通常は、入力した直後にこのデータ更新によるチェックをかけるが、もし、複数件の NG が発生した場合は、ピボットテーブルをローカルPCで開き、NG件数をダブルクリックすることで該当データの詳細が表示される。残念ながら Excel Web Access 内でピボットテーブルからのドリルダウンはできないが、ドリルダウンによる分析が主ではないため、それほど問題にはならない。

r2co20150223_006

なお、Excel Web Access / Excel Services によるデータ接続の更新については以下の記事が参考になるだろう。

http://road2cloudoffice.blogspot.jp/2015/01/excel-online-excel-web-access-excel.html

SharePoint 上での Excel Web Access データ接続更新が可能になったおかげで、多くの確認処理を SharePoint サイト上のピボットテーブルで実装することが可能になり、Excel のスキルのみで業務を遂行することが可能になったのは非常に大きな効果である。
上記がなんらかの参考になれば幸いである。

2015/02/18

SharePoint リスト列の選択肢がExcelで計算されない

SharePoint リストの [接続とエクスポート] の [Excel にエクスポート] (SharePoint リスト接続)でリストを Excel のテーブルとして抽出することで、Excel 側で加工・計算できることを紹介してきた。

通常の使い方であれば、エクスポートした後のテーブルを参照してピボットテーブルを使い、さまざまな視点でデータを集計することで、おおよその業務目的は達成できるが、SharePoint リスト接続で問題になるのが列の種類で「選択肢(メニューから選択)」を選び、選択肢として「数字」をいれた列の扱いである。

r2coリスト列定義

この列への入力はドロップダウン メニューから該当する数字を選択する。アイテム入力後のリストは以下のように表示されている。

r2coリスト2

この状態(選択肢から数字データを選択した状態)は数字に見えるデータは「文字列」であり、現に SharePoint リストの [集計] でも個数の集計しかできず、「数値」としての合計はできない。

一方、Excel は通常手入力でセルにデータを入れた場合は、全角であろうが数字が入ると半角に直し「数値」としてセルにデータが入力される。SharePoint リスト接続によるエクスポートでもこのような動きを期待したいところだが、実際は、エクスポートしたテーブルからピボットテーブルを作成しようとすると、セルに数字が入っているにもかかわらず、リストの [集計] と同様個数のカウントしかできず、数値(金額)の合計ができない。

r2coPivot 

Excel のテーブル上では以下のようになっている。こちらでも集計行を使って計算はできない。

r2coテーブルSharePoint

[文字列] であるセルの書式設定(列の書式設定)を [数値] に変えただけではこのデータは数値にならない。各セルで編集モードにして Enter を押してはじめて [数値] になる。数十、数百のリスト アイテムがあるテーブルの場合はさすがにこの対応はない。

この SharePoint リスト接続を使用したエキスポートの場合の対応方法は2つだ。

1) SharePoint 側で数値データに変換する

・ 集計値を使ってデータを変換する

SharePoint リストの集計値の列で VALUE 関数を使い文字列を数値にする。見た目も3桁カンマが挿入される。ただし、SharePoint リストの集計値そのもの集計することができないのが難点(もう一歩)である。

r2co数値化列2

r2co数値化列1

SharePoint リストの集計値については以下の投稿も参照されたい。

Excel ユーザーのための SharePoint リスト 「集計値」列 (2015/12/5)

2) Excel 側で数値データに変換する

・ VALUE関数を使って数値列を追加する

SharePoint リストの集計値同様に VALUE 関数を使って Excel のテーブルで文字列を数値に変換する。SharePoint リストのデータはテーブルとしてエクスポートされるので、最初に変換する列を追加しておけば、アイテム(レコード)が増加しても数値変換用の追加列はそのまま有効だ。
一度ブックを作成して、データ更新して使う場合などは有効だが、新規作成となると、この列追加・数式追加を必ずやらなくてはならない。

なお、ピボットテーブルの集計フィールドで VALUE 関数は使えないので注意が必要だ。

SharePoint リスト接続にこだわらなければ以下がある。

・ Power Query を使ってエキスポートし、データ変換を入れる

Power Query が使える環境であれば、データ取得時に文字列から数値へのデータ変換を [受講料] の列で行うことが可能だ。Power Query のクエリ編集は必ずやるので、その段階で行えばよい。

Power Query と SharePoint リストについては以下の投稿も参照されたい。

Excel ユーザーのための Power Query (2015/12/19)
Power Query を使った重複行の削除 (2015/1/18)
Power Query を使って絞り込んだデータを取得する 日付編 (2015/1/27)

運用していて感じるのは元データがおかしい(処理に不向き)であれば、なるべく元データ側で直すのが、最終的に手間がかからなくなる。
Excel でも当然処理・加工はできるのだが、元データ側で直せるのであればそちらを選択したほうが良いだろう。
上記の数字選択肢~文字列のケースは SharePoint のビュー設定で既定のビュー設定を変えることで、入力のときは [選択肢]、通常見るアイテムは [集計値による数値データ] に切り替えることが可能で、データ エキスポート用のビューの設定も可能だ。

r2coテーブル2

2015/02/03

リレーションシップとデータ モデル

以前の投稿でも Excel 2013 から新機能として追加されて「リレーションシップ」を紹介した。

テーブルのすすめ ピボットテーブルとリレーションシップ

このリレーションシップはテーブル間のリレーションを設定した上で、ピボットテーブル作成時に「複数のテーブルを分析するかどうかを選択」の「このデータをデータ モデルに追加する」のチェックを入れることで、ピボットテーブルのフィールド リストで利用可能になる。

またリレーションシップと同様の機能として Power Pivot の「計算列」の紹介で RELATED 関数を使った列の追加と複数テーブルの分析を可能にするピボットテーブルの作成も紹介した。

Power Pivot で計算列を作る

さらに、Power Query でも「マージ」という機能でリレーションシップ同様の結果(マージされたテーブル)を得る方法も紹介している。

Excel ユーザーのための Power Query


Excel 単体のみで利用する環境であれば、実際のところリレーショナル データベースのようなテーブルの「正規化」をすることはあまりないが、マスターデータがサーバーやクラウドといった他のシステムにある、もしくは日々のトランザクション データを他のシステムからインポートする、となると、VLOOKUP 関数や MATCH/INDEX 関数を使って複数のテーブルや表を参照しなければならないケースが出てくる。このようなケースが多くなると「リレーションシップ」の機能の利用を検討したほうが良い場合がある。

Power Pivot や Power Query という Power BI のアドインによってさまざまな可能性が提示されているが、上記のように「似たような機能」が複数あり、その選択に悩んだり、特徴を理解するのに時間がかかるのも事実である。

さらにデータ モデルを使ったピボットテーブルでは「集計フィールド」、「集計アイテム」、「日付のグループ化」ができなくなる(もちろん、それを実現するための代案もある)ということも無視できない。
[追記] 日付のグループ化はデータ モデルに追加しても可能になりました。
そこでその特徴をまとめてみた。上述のような「リレーションシップ」や「マージ」を行うと、その後工程でピボットテーブルを利用することが多いため、ピボットテーブルの利用という観点からまとめてみる。ただし、あくまで実践ワークシート協会の業務の中で実際に利用した経験上からの示唆である。

データ モデル利用の有無がポイント
上述のように似たような結果が得られる様々な機能が存在している。リレーションシップという複数テーブル間の関連を設定する方法では Excel 2013 リレーションシップとデータ モデルを使ったピボットテーブル、Power Pivot、そして Power Query のマージ機能がある。
最終的に Excel のピボットテーブルを使いたい場合、この3つの機能の関係は以下のような図で表すことができる。
DataModelExcel
Power Pivot はデータ モデルを前提とする。扱うデータは必ずデータ モデルでなければいけない。
Excel 2013 リレーションシップを設定した複数テーブル分析可能なピボットテーブルもデータ モデルを作成しなければならない。
データ モデルを使って、複数テーブルを関連づけたり、列の加工を行ったりして、そのデータを Excel のピボットテーブルに渡している、と考えられる。
データ モデルはさまざまなサーバーやクラウドを前提としているため、Excel のためだけのデータではない。そのため、本来 Excel のデータ(テーブルまたは表)を前提として用意された機能・オプションが使えなくなっていると考えると妥当だろう。
データ モデルを使ったピボットテーブルでは制限がでる、ということだ。(何度も書くが、その代替策はきちんと用意されている)

日付データのグループ化も可能な「リレーションシップ」環境
さまざまなデータ ソースを扱うことを目的としたデータ モデルは今後も拡張、発展すると考えられる。しかし、製品・サービスとしては必要だが、実務ではそれほど多様なデータ ソースを扱ってはいないのも事実だ。(今後はわからないが、少なくとも現状は多くても2~3種類だろう)
これまで同様のピボットテーブルの操作感で、リレーションシップを使って複数テーブル、複数のデータ ソースの分析をしたい、となれば、上図の構成から Excel テーブルからピボットテーブルを作るしかない。そこで出てくるのは Power Query のマージ機能だ。
Power Query のマージ機能により、複数のテーブルやデータ ソースを1つの Excel のテーブルにし、そこからピボットテーブルを作れば、これまで同様の操作性を維持することができる。
以下のような Excel のテーブルを例にとって検証してみよう。
TableSample
Excel 2013 のリレーションシップを使ったピボットテーブルや、Power Pivot から作成したピボットテーブルでは、日付のグループ化、集計フィールド、集計アイテムの利用はできない。
relationPivotNoGrouping
ここでサンプルの3つのテーブルを「マージ」したテーブルを Power Query でまず作成する。
Excel のテーブルを参照するクエリを作成するとき、同じテーブルを作成する必要はないので、「接続の作成のみ」を選ぶ。もちろん、ここではデータ モデルは作成しない。
PQ_Connection_Only
それを3つにテーブルで繰り返し、3回のマージにより1つのテーブルにする。
PQMarge
この最後のマージ(Merge3)によって出来上がったテーブルからピボットテーブルを作る。このピボットテーブルは Excel のテーブルを参照している通常のピボットテーブルなので、日付によるグループ化などが可能だ。
PQPivot
Power Pivot の意義
それでは Power Pivot の意義はないのかというと、Power Query のブック クエリのウィンドゥを見てわかるように、複雑なことをやろうとすると、クエリ、マージ、追加といった操作の繰り返しになる。Power Pivot であれば Power Pivot ウィンドゥのダイアグラム ビューを使ってビジュアルに操作が可能だ。
PowerPvVisual
テーブルの数が多くなり、リレーションシップの項目も多くなれば、Power Pivot ウィンドウによる設定の容易さは計り知れない。基幹系アプリケーションが利用しているデータベースなどは多くのテーブルが存在するため、このようなビジュアルツールでなければ設定や管理が煩雑になるだろう。

データ モデルはいつ必要になるのか
よって、Excel を中心としているユーザーにとってはデータ モデルが必須となるシーンはあまりないのが現実だ。Excel のテーブルであったり、SharePoint Online の SharePoint リストからそれほど多くないリストのインポートを Excel にして利用するのであれば、データ モデルを前提とする Power Pivot や、データ モデルを作成する Power Query のモデル OLE DB 接続にする意味はあまりない。SharePoint リスト接続や Power Query の OLE DB 接続を使い、Excel 上に展開されたテーブルを扱うことでおおよそのことができるだろう。

実践ワークシート協会の業務で唯一データ モデルが必要になるのが、Excel Online / Excel Web Access といった、Excel ブックを SharePoint Online 上で活用するときである。まだ、活用しきれていないが、Power BI もデータ モデルの Excel ブックを前提としている。
いますぐは必要ないかもしれないが、データ モデルについては今後のキーとなるので引き続きウォッチが必要だろう。

[2016/5 追記]
今後、Excelブック内でのデータ モデルは必要になります。それは Power BI service でレポートやダッシュボードを他のメンバーと共有する際に、データ モデルをベースとした処理が前提となることからです。Excelの中だけで閉じるのであればデータ モデルを作成する必要はありませんが、Power BI service などのExcel以外のサービスを利用することを考えると、データ モデルが前提となるからです。これが1年以上前と 2016年の上旬との大きな違いです。
Powered by Blogger.

自己紹介

自分の写真
1989年新卒で日本IBMに入社しダウンサイジング担当としてホストコンピュータと繋げるオフコン、UNIX、PCサーバーのプロジェクトを担当。1997年 MSKK(現日本マイクロソフト)入社、NT4出荷に伴い企業向けサポート部門のビジネスマネージャーとして Excel 使いとなり、2002年 にMSMVPなどをサポートするユーザーコミュ二ティ部門を設立、部門をリード。2006年にMSKK退職後、企業向けのITトレーニング会社・団体に携わり、2014年頃よりPowerBI勉強会主催メンバーの一人として参画、そのコミュニティ活動で MSMVP for Data Platform PowerBI 2017受賞。https://mvp.microsoft.com/ja-jp/PublicProfile/5002635 同年にMVP Awardを返上し、アマゾン ウェブ サービス ジャパンに入社、コミュニティプログラム担当として現在に至る。