Quantcast
Channel: モダン Excel を業務で使うブログ (旧Road to Cloud Office)
Viewing all 82 articles
Browse latest View live

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

$
0
0
今回も Excel 2007 以降の重要な機能追加である「テーブル機能」を使った話である。

ピボットテーブルの参照先としてテーブルを使う

すでにテーブルを参照先範囲に指定することでデータの増減に自動的に対応する恩恵を受けることは入力規則や関数で紹介してきた。
同様にピボットテーブルの参照先範囲としてテーブルを指定すると、動的にデータの増減(参照先範囲の変化)に対応する。ただしピボットテーブルの「更新」はこれまで同様押す必要はある。


元データの行の追加だけでなく、列の追加にもピボットテーブルは対応する。


ピボットテーブルを使うユーザーはすでに参照先データがきれいな「表」になっているはずである。その表をテーブルに変換して、ピボットテーブルの参照先としてテーブルを指定するだけでこの恩恵を受けられるのである。これを使わない手はない。

ただ、残念なことに、この「ピボットテーブル」の結果の表は「テーブル」機能で実装されていない。テーブル機能が出る前からピボットテーブルは存在し、その実装は同じ「テーブル」という用語を使っていても違うのである。ピボットテーブルの参照が構造化参照のようになれば、、、と思いがちだが注意してほしい。

そのかわりと言ってはなんだが、Excel 2013 以降でこのピボットテーブルとテーブルの組み合わせでさらに強力に業務を支援する機能が追加された。それが「リレーションシップ」である。

VLOOKUPはもう使わない?Excel 2013 から実装されたリレーションシップ

上記で使ったテーブルには商品コードが記入されていて、商品名はない。このようなデータの持ち方の場合は、商品テーブルが別に存在して、そこから商品名を VLOOKUP でこれまでは検索してきた。
(注釈するが、この図のようなデータの持ち方、ピボットテーブルの配置はお勧めではないどころかやってはいけない。テーブルを使う場合は混乱を避けるために1ワークシート1テーブルとすべきである。すべてのデータを見せるためにこのような配置をしている。)


2つ程度であれば、列を追加して VLOOKUP を使ってデータを参照してもいいが、基幹業務システムからデータをインポートしたり、何等かの形でそのデータを利用しようとすると複数のテーブルに分けられた「正規化」されたテーブルであることが多い。

これに対応するために Excel 2013 では「リレーションシップ」という機能が追加された。

それぞれの参照データ範囲は「テーブル」に変換されている必要がある。
テーブルに変換されていると [データ] タブの [データ ツール] セクションにある [リレーションシップ] の [リレーションシップの管理] ダイアログで参照・テーブル間の関連付けが可能になる。


以下の3つのテーブルの関連付けを行ってみる。

個人売上テーブル


商品テーブル


地域テーブル


欲しいデータは個人売上テーブルの商品コードである A や B が商品名になったものや、その商品の地域名である。そのため、まず、個人売上テーブルと商品コードを関連づける。ブック内のテーブルは「リレーションシップの管理」ダイアログのプルダウン リストに表示されるのでシートを移動して範囲指定するようなことはない。個人売上テーブルで A, B, C... がある [商品] 列と、商品テーブルで A, B, C... がある [商品コード] を関連付けてやる。
続けて、商品テーブルと地域テーブルを関連付ける。今度は 001, 002, 003... がある列をそれぞれ関連付ける。



今は以下のような関連付けになっている。


ここまで設定したらピボットテーブルでこの関連付けが利用可能になる。
個人売上テーブルを参照先として指定したピボットテーブルを作ってみる。この時重要なのは、このリレーションシップを利用したい場合は必ず [複数のテーブルを分析するかどうかを選択] の [データモデルに追加する] をチェックすることだ。


これで作成したピボットテーブルのフィールド リストにはこれまでなかったタブが表示される。その中の [すべてのフィールド] をクリックすると、個人売上テーブルに関連付けられたテーブルが表示され、それを展開すると列名が表示される。


この各テーブルの列名を使ってピボットテーブルを作成することが可能だ。

このフィールド リストを使って、商品名別と地域名別の売上のピボットテーブルを作成してみる。


複数テーブルを使ったシンプルなピボットテーブルであれば、このリレーションの機能をどんどん活用すべきだが、その反面、実はこれまで Excel のピボットテーブルでできていたこと(それも重要なこと)がいくつかできなくなっていることに注意しなければならない。(もちろん、その対応方法は存在する)それを以下に紹介する。

データモデルとは

ところで、ピボットデーブルを作成するときに [複数のテーブルを分析するかどうかを選択] で [このデータをデータモデルに追加する] にチェックを入れた。一体データモデルとはなんだろうか。

このブログで Excel 2007 以降のテーブル機能を紹介する発端となっているのは Office 365 との親和性であった。 http://road2cloudoffice.blogspot.jp/2014/10/excel-office-365.html

Office 365 の SharePoint Online や Access アプリ、クラウドや社内にあるサーバーのデータと、Excel との橋渡しをするのがテーブルである、と紹介したが、さらに正確にいうとテーブルとデータモデルによって連携できる、と言える。

そもそも、このデータモデルという実装方法は Excel から発生したものではなく、マイクロソフト社のデータベースサーバーである SQL Server で Excel との連携のために開発された Excel アドインから来ている。

2007 Office リリース用 SQL Server 2005 データ マイニング アドイン
http://office.microsoft.com/ja-jp/excel-help/HA010225754.aspx

そのため、データモデルとなった「データの集まり」は Excel の機能を使うことができない場合もある。

このリレーションシップ機能を使ったピボットテーブルとして実際に見ているデータはデータモデルから取り出しているものである。それは [データ] タブの [接続] の [ブックの接続] ダイアログから確認できる。ThisWorkbookDataModel はピボットテーブルの範囲を示している。


そして、このデータモデルのリレーションシップを使ったピボットテーブルでの代表的な制限は以下である。
[追記] Excel 2016 からはこの制限はなくなっている。詳しくはこちらを参照のこと

・ グループ化ができない
・ 集計フィールド、集計アイテムを追加できない

グループ化はシリアル値である日付を月や年にまとめるためにピボットテーブルではよく使うだろう。集計フィールドもデータに単価と数量があり、そこから金額を計算するときに使うことが多い。

これらが使えないとピボットテーブルによる分析はできないも同然である。しかし、そもそも「SQL Serer 2005 データ マイニング アドイン」から発展してきた実装方法である。このアドインはデータの分析のための機能である。

Excel が本来持っていた機能はデータモデルによりデータの持ち方が変わってしまったため利用できないが、その代替は当然用意されている。

それがデータモデルに追加する「セット」であり、そこで利用する MDX 言語だ。
(MDX : the MultiDimensional eXpression)

上図「ブックの接続ダイアログ」で ThisWorkbookDataModel を選択した状態で [セットの管理] ボタンを押せば、新しいセットの追加や MDX 編集画面がでる。

ただ、公開されている日本語の情報が非常に少ないのと、Excel 側からの観点よりも、SQL Server のアドイン(Analysis Services)側からの情報に偏ることが多い、さらに SQL 構文などのデータベースの知識を必要とするため、Excel ユーザーにとっては習得は厳しいかもしれない、というのが現状だろう。

このような状況を打破し、Excel ユーザーにも直感的にわかりやすく、Excel の操作性に近い設定を提供するのが PowerPivotである。 PowerPivot の対象はクラウドやサーバーのデータだけでなく、Excel ブック内のデータモデル化したテーブルも対象にできる。つまり「テーブル」であれば、PowerPivot からの利用が可能なのだ。

PowerPivot で日付グループ化、集計列追加でピボットテーブルを作った例

ただし、PowerPivot を使うには「エディション」に注意しなければならない。
Personal エディションや Home & Business エディションでは PowerPivot を利用することができない。利用するには Office 2010 以上の Professional や Solo、Office 365 Pro Plus が必要となる。

[追記] Power Pivot で日付のグループ化
http://road2cloudoffice.blogspot.jp/2014/11/powerpivot.html

テーブルのすすめ Office 365 連携 SharePoint リスト

$
0
0
Excel 2007 以降で「テーブル機能」が重要になることを紹介してきた。

ピボットテーブルの参照先や、グラフの参照先にテーブルが指定されていれば、同様に元のデータの増減に自動的に対応する。元データの増減への自動対応は Excel 2003 以前では複数の関数を組み合わせることで対応できた場合もあったが、テーブル機能を使えばそのようなテクニックを使わなくても簡単に実現することがわかったと思う。

このような「参照先データ」は、通常「マスターデータ」と呼ばれるものや、ある条件の集計結果データであることが多い。(月次締めなど)それらの多くは個々人の PC に入っている Excel のワークシートで管理されていることは稀であり、小規模でも Access のデータベース、大規模になれば SQL Server や Oracle といった基幹システムのデータベース サーバーにある。

そのため、それらの参照データを「CSV形式」のファイルで入手し、Excel にインポートし、分析作業や、報告書作成のための集計作業をしているユーザーが今でも多い。

もし、それら元データの取得を Excel で取り込み、分析・集計作業が一連の流れの中で止まることなくできたら、、、と思うのは当然である。

Office 365 とは、Office 365 Pro Plus (Excel, Word, PowerPoint など) と、サーバーサービスである Exchange Online (メール サービス)、SharePoint Online (ポータル/ドキュメント共有サービス)、Lync (メッセージ サービス)を組み合わせた総称である。(Office 365 のプランによっては Office 365 Pro Plus が含まれないものもあるので注意すること。)

サーバーサービスが持っているデータと Excel を連携させるために、ここでも Excel の「テーブル機能」が重要な役割を担うことになる。いくつかご紹介しよう。

1) Excel のテーブルからリストを作る

SharePoint Online は「リスト」という機能を使って、データの蓄積が可能である。リストを使うためにはリストの設定をしなければならないが、このリストの基本設定は Excel を使ってできるのである。

以下のような「コースマスター」テーブルを使って SharePoint リストを作ってみよう。


コースリストのデータ列は「文字列」で書式設定されている。日数は数値、講師は文字列、開始日は YYYY/MM/DD のシリアル値だ。

SharePoint Online の詳細な説明はここではしないが、SharePoint で他の社員と共有するようなスペース(サイトと呼ぶ)を作成し、そこにこのコースマスターを元にしたリストを作ってみる。

SharePoint Online チームサイト 作成直後の初期状態トップページ

このサイトのトップページの URL を控えておき、Excel でコースリストのテーブル内にアクティブセルをおいて、リボンの [デザイン ツール] の [デザイン] タブの [外部のテーブル データ] セクションにある [エクスポート] の ▼ をクリックする。


[テーブルを SharePoint リストにエクスポートする] をクリックする。


アドレスに SharePoint のサイトの URL を入れる。ここでは読み取り専用接続を作成せずに、名前と説明を適宜入力する。なお、名前は英語で入力しておき、あとで日本語に変更することをお勧めする。 URL が最初に入力した英語で簡略化できるからである。


データ型についての確認ダイアログがでる。問題が無ければ [完了] をクリックする。
Excel のテーブルが正しく SharePoint のリストとしてエクスポートが成功すれば以下のダイアログが表示される。


ダイアログの URL をクリックすると、作成された SharePoint リストのページがブラウザで開く。


これで Excel テーブルの SharePoint Online のエクスポートが完了した。
勘違いしないでいただきたいのは、これは Excel のテーブルを「ひな形」として新たに SharePoint にリストを作成したものである。ここではなんの連携機能もない。コピーしたようなものである。

運用的に、今後は SharePoint Online のこの「コースリスト」がマスターデータとなって、データの追加や修正はこの SharePoint のコースリストで行う。このコースリストを参照する Excel ブックは、コピーを自分のブック上に持つのではなく、データ接続を使ってリアルタイムに SharePoint 上のコースリストを参照して、Excel で処理を行う、というものだ。

では、SharePoint のコースリストを新しい Excel ブックと連携させてみる。

SharePoint のコースリストのページにある [リスト] タブをクリックして、[Excel にエクスポート] をクリックする。


IE の下部に以下のダイアログが表示される。[ファイルを開く] をクリックする。





Excel が立ち上がり、データ接続をしようとするためセキュリティの確認ダイアログが表示される。[有効にする] をクリックする。


データのインポート方法を選択する。[テーブル] で、新規ブックで作成してみる。


SharePont Online のリスト「コースリスト」からテーブルが作成されたことが確認できる。


元の Excel のテーブルと比較すると [アイテムの種類] や [パス] が列として追加されている。

データ接続による SharePoint から Excel へのデータ エクスポートは SharePoint → Excel の一方通行である。Excel 側にあるテーブルはあくまで「参照用」であって、この Excel ブックのデータを変更しても SharePoint のリストが更新されることはない。

逆に、SharePoint 側のリストが変更されると、その変更はデータ接続をしているすべてのテーブルに反映される。ただし、その反映のタイミングは Excel ブックで [データ] タブの接続の更新もしくは [すべて更新] をクリックしたときである。(手動設定の場合)

一度データ接続を設定すれば、あとは明示的にデータ接続情報を消さないかぎり再利用可能だ。

以下は SharePoint 側で新たにデータを追加した手順である。

SharePoint のリストが更新された状態だけでは Excel ブックに変更は反映されていない。
以下、[すべての更新]をクリックした動きである。


このように SharePoint からのデータは「テーブル」となって Excel ブックで利用可能になる。
よって、Excel 側ではテーブルの利用方法、活用方法、さらにテーブルに対応したブックを作成しておくことで、Office 365 SharePoint との連携が現実となってくるのである。

なお、SharePoint Online のリストの制限(件数など)などが気になるだろう。
以下が SharePoint Online のリストの制限である。参照されたい。

列数: 列の要素によって制限が異なる。1行テキストの場合は最大 276 列を使用できる。
行数: 数千が実用範囲。数万もいけるがパフォーマンスを考慮すべき。数万の場合は Access アプリ(データベースエンジンは SQL Azure を使用)などを考慮。

アイテム数が多いリストとライブラリを管理する
http://office.microsoft.com/ja-jp/sharepoint-server-help/HA102771361.aspx

PowerPivot で日付のグループ化

$
0
0
PowerPivot は強力な Excel のアドインであることは以前に紹介した。


ここで紹介したのが PowerPivot はデータモデルを採用しているため、これまでの Pivot テーブルの機能で使えていたものが使えなくなる、その代表が「グループ化」と「集計フィールド、集計アイテム」の追加だ。

コンテキストメニューのグループ化がグレイアウトされ選択できない状態

集計フィールド、集計アイテムがグレイアウトされ選択できない状態

特に日付のグループ化はデータを分析するためには必須である。この対応方法を今回は紹介する。なお、そもそも PowerPivot はマイクロソフト社の SQL Server のデータを Excel で分析するためのアドインとして開発された。そのため、Office や Excel から PowerPivot のテクニックを探すのは正直まだ情報が多いとは言えない。そのため、情報サイトなどで Excel を駆使して代替案を提示している場合が多いのだが、PowerPivot の機能として参照・検索するのであれば、SQL Server 側からの情報として探すと見つかる場合が多い。

日付のグループ化は「階層」を使う

Excel はシリアル値というすばらしい仕組みを内蔵しているため、こと日付に関する処理・操作は非常に簡単に複雑なことができるようになっている。Excel の Pivot テーブルで日付をグループ化する機能などはシリアル値の恩恵を受けている。

一方、シリアル値を持たない通常のシステム、サーバーで日付を扱うには「年」や「月」といったデータを日付形式のデータから抜き出してレコードの別フィールドとして持たせる必要がある。Excel から見れば非常に面倒な処理をしているように思えるが、これは仕方ないとあきらめるしかない。

同様にデータモデルである PowerPivot では日付形式のデータから「年」や「月」を抜き出す必要が出てくる。

[PowerPivot] タブから [管理 データモデル] をクリックして、PowerPivot ウィンドウを開く。
そうするとそのブックに含まれているデータモデルを参照することができるので、該当するテーブルをデータシートビューで開く。


このデータモデルには「日付」があるので、このフィールドから「年」と「月」の列を新たに追加する。PowerPivot の場合はなるべく Excel ユーザーにも使いやすいように Excel に似た UI と関数が用意されている。(ただし、Excel の関数ではない。この PowerPivot で使う Excel のワークシート関数に似た関数を DAX 関数と呼ぶ。)

YEAR関数を使って年を抜き出す。データシートビューはワークシートではないので、関数の入力は直接セル(のようなもの)にできない。関数入力ボックスから行う必要があるので注意されたい。


MONTH関数を使って月を抜き出す。


列名は上書きで変更できるので、年、月とする。
次にこの「年」と「月」を使って、「年月」の階層を作成する。

データシートビューからダイアグラムビューに切り替える。
データモデルにある「年」で右クリックでコンテキストメニューを開き、「階層の作成」を選ぶ。


階層が作成されるので名前を「年月」にする。


「月」をドラッグして「年月」の「年(年)」の下にドロップする。


これで「年月」の階層が作られた。

これで PowerPivot ウィンドウから Pivot テープルを作ると、サンプルとして使った個人売上テーブルに「年月」フィールドが別の枠として追加されているのがわかる。


この「年月」の階層を使えば、日付のグループ化、グルーピングと同じことができるようになる。

以下がその操作だ。



まずは、PowerPivot の使い方などの情報は SQL Server の自習書としてマイクロソフトが公開しているので、本家の情報に目を通していただきたい。

SQL Server 2012 自習書シリーズ
PowerPivot for Excel によるセルフ サービス分析

MSDN PowerPivot for Excel チュートリアル
http://msdn.microsoft.com/ja-jp/library/gg413497(v=sql.110).aspx

PowerPivot で計算列を作る

$
0
0
PowerPivot や Excel 2013 以降の新機能である「リレーションシップ」を使いテーブルをデータ モデルに追加するとピボットテーブルの「グループ化」や「集計フィールド」、「集計アイテム」が使えなくなることはすでに紹介した。

http://road2cloudoffice.blogspot.jp/2014/11/powerpivot.html

結論から言えば「データ モデル」を使った場合は PowerPivot を併用しないと、これまでピボットテーブルで行っていたことができないと思ってもいいだろう。前回は「階層」を使ったグループ化を紹介したが、今回は集計フィールドや集計アイテムに相当する「計算列」と「計算フィールド」について紹介する。

なお、繰り返しになるが、データ モデルを使うことで「グループ化」や「集計フィールド」や「集計アイテム」が使えなくなり、「新しい Excel 使えない」と早合点しないでほしい。そもそも PowerPivot は SQL Server や SQL Server Analysis Services と Excel を使った「データ分析」のために作られた Excel のアドイン機能であり、そのような分析のための機能は当然持っている。
そして、わざわざデータ モデルを使う理由はある。一つの例として巨大なデータを扱えることだ。データ モデルにすることでワークシートの制限がはずれ、100万行をゆうに超えるデータを扱えるようになるからだ。PowerPivot で扱う元データが数千万件であっても問題ない。そして、何件まで扱えるかは PC に搭載されているメモリーに依存する。そのため、そのような巨大なデータを扱う場合は Windows は 64bit を使い、Excel も 64 bit 版のものを使うことが推奨される。

計算列はすべてのレコードを対象に計算する

計算列や計算フィールドは PowerPivot ウィンドウで設定する。ここで設定をすることで、Excel のピボットテーブルのフィールドリストに表示され利用可能になる。そこからはこれまでのピボットテーブルと同様の操作性を提供することになる。

以下のようなリレーションのテーブルを例にして説明する。


個人売上テーブルのデータは「日付」、「名前」、「商品」、「個数」しかない。ここに売上金額の計算結果を追加したい、というケースだ。

個人売上テーブルの PowerPivot ウィンドウのデータビューが以下になる。


欲しいのは商品の単価と、個数と単価を掛け合わした金額である。
すでに個人売上テーブルと商品テーブルは「商品コード」(A,B,C,,,)でリレーションを張っているので、商品テーブルから「単価」の列をこの個人売上テーブルに追加する。
そのときに使うのが DAX 関数の RELATED 関数である。RELATED 関数を使うことで、関連付けられているテーブルから該当する「単価」が参照できる。Excel の VLOOKUP 関数のような働きをすると考えれば理解しやすいであろう。
以下がその操作である。Excel 同様に数式オートコンプリートも使える。非常に簡単なのがわかると思う。


次に個数と単価を掛け合わせた金額の計算列を追加する。これは Excel の数式とまったく同じ操作性だ。しかし、1点注意しなければならないのは Excel のテーブル同様、構造化参照の数式のように、最初の行に数式を入力することですべての行に対して同じ数式が入力されることだ。


これで金額の計算列が追加された。ここからピボットテーブルを作ってみよう。
そうすると、先ほど追加した計算列の「単価」と「金額」がフィールドリストにも表示されていることが確認できる。


個人売上テーブルには「商品名」はなかったが、商品テーブルとリレーションを張っているのでピボットテーブルでは参照可能だ。このためわざわざ商品名を RELATED 関数で参照する必要はない。


計算列ではほぼワークシート関数と同じものを使用することができる。
IF なども利用可能なので、単純な数値演算だけでなく、論理演算も可能だ。
Excel をすでに使いこなしているユーザーであれば、PowerPivot の計算列をすぐに活用できるだろう。

長くなったので、次回で「計算フィールド」について紹介したい。計算列がすべてのレコードを対象にして計算するものであり、計算フィールドは「ある条件で絞られたレコードを対象に計算する」と考えれば理解しやすいだろう。

マイクロソフトの記事
PowerPivotの計算列
https://support.office.com/ja-jp/article/PowerPivot-%E3%81%AE%E8%A8%88%E7%AE%97%E5%88%97-a0eb7167-33fc-4ade-a23f-fb9217c193af?ui=ja-JP&rs=ja-JP&ad=JP

PowerPivotの自習書
SQL Server 2012 自習書シリーズ
PowerPivot for Excel によるセルフ サービス分析

PowerPivot で計算フィールドを使う

$
0
0
Excel の Pivot テーブルの集計アイテムや集計フィールドを使いこなすのはなかなか難しいが、もし使いこなしているとすれば、PowerPivot で同様に機能を提供する「計算列」や「計算フィールド(メジャー)」の考え方は問題ないであろう。

PowerPivot で「集計アイテム」や「集計フィールド」がグレイアウトされて選択できない状態になるが、これはこれまでの制限の裏返しでもある。

以下の Excel のピボットテーブルの Office Online の記事「ピボットテーブル レポートで値を計算する」を読むとわかるが、ことあるごとに「OLAPデータベースサーバーのデータは使えない、OLAPの管理者の問い合わせてください」というくだりが出てくる。

Office Online 「ピボットテーブル レポートで値を計算する」
http://office.microsoft.com/ja-jp/excel-help/HP010096323.aspx

逆に、PowerPivot を使えば、これまでの「集計アイテム」や「集計フィールド」は使えなくなるが、PowerPivot の「計算列」や「計算フィールド」を使うことで、データソースの種類に関係なく、Excel のピボットテーブル レポートを作成することができる、と言える。OLAP のデータも、Excel のテーブルもデータ モデルとして扱うことで、それが可能になるのである。

データ モデルという仕組みが、どんなデータであろうと Excel に対して共通のインターフェースを提供し、Excel 側では単一のツールでさまざまなデータソースのデータを利用できるメリットは大きい。

特に Office 365 と Excel の組み合わせでは、このデータ モデルによるデータソースの多様化の恩恵を PowerPivot や PowerQuery を使うことで最大限に受けることが可能になる。

話が逸れてしまったが、あらためて Excel はエンドユーザー側のフロントエンドのツールとして、レポート作成に使われたり、分析に使われたりする機会が多くなるだろう。そのため、PowerPivot などの機能を習得することは無駄にはならないはずである。

計算フィールド(メジャー)を定義する

計算列はすでに紹介したが、実際のところ計算列は理解するのにそれほど苦労はないだろう。ワークシートのような PowerPivot ウィンドウのデータビューの「列の追加」での操作は、ポイントとなる DAX 関数さえ知っていれば Excel ユーザーとっては慣れたものであろう。


一方で計算フィールドは計算列ほど単純ではないと感じるユーザーも多いかもしれない。
一番わかりやすいのは、数量などの合計をピボットテーブルでも計算するが、=SUM() などの計算式を入れずに「値フィールドの設定」から選択して使うことが多いだろう。これを PowerPivot では「暗黙的な計算フィールド」と呼んでいる。ピボットテーブルのフィールドリストの「Σ 値」のエリアに配置されるものだ。


計算フィールドの作成方法は2つの方法が存在している。ひとつは Excel の PowerPivot タブの計算にある [計算フィールド] を使う方法。もうひとつは PowerPivot ウィンドウのデータ ビューで「計算領域」に記入する方法である。

PowerPivot タブの[計算フィールド]

PowerPivot ウィンドウの計算領域での計算フィールドの設定

計算フィールドそのものの解説や、計算フィールドの利用方法や設定方法、計算フィールドと計算列の違いなどは以前紹介した自習書やピボットテーブルの解説を参照してほしい。重要なのは PowerPivot を使ったからといってピボットテーブル レポート内で数式を使った計算(集計アイテム)ができないことはない、ということだ。

PowerPivot 自習書
SQL Server 2012 自習書シリーズ
PowerPivot for Excel によるセルフ サービス分析

Office Online - ピボットテーブル レポートで値を計算する
http://office.microsoft.com/ja-jp/excel-help/HP010096323.aspx

Office Online - PowerPivot での計算フィールドの作成
https://support.office.com/ja-jp/article/PowerPivot-%E3%81%A7%E3%81%AE%E8%A8%88%E7%AE%97%E3%83%95%E3%82%A3%E3%83%BC%E3%83%AB%E3%83%89%E3%81%AE%E4%BD%9C%E6%88%90-D3CC1495-B4E5-48E7-BA98-163022A71198?ui=ja-JP&rs=ja-JP&ad=JP

特に通常の Excel であれば条件付き書式を使ったデータの可視化、データ分析では KPI と称されることが多いが、これを集計フィールドの KPI アイコンとして設定することができる。この方法も自習書シリーズで解説されているので参考できるだろう。

Excel ユーザーのための Office 365 SharePoint Online

$
0
0
Office 365 というサービスは今後のマイクロソフト社の主流のサービスと位置付けられていると考えてよい。多くの製品開発はまず Office 365 というクラウドサービスを対象に行われ、その後、オンプレミスと呼ばれるサーバー製品にフィードバックされることが、マイクロソフトの開発責任者によって明らかにされている。

Office にしても、Office Premium や Office 365 Solo といった商品・サービスが登場し、クラウドや Office 365 の存在を無視し続けることがデメリットになりつつある。まして、企業で Office を利用しているユーザーであればあるほど、Office 365 の恩恵を受ける可能性が高いのだ。

その Office 365 の中でとりわけ利用・活用に頭を悩ませているのが SharePoint Online であるというユーザーも少なくない。SharePoint Online は「なんでもできる共通基盤」として紹介されてしまうため、逆に何をやっていいかのイメージがつきづらいサービスである。


実際、コラボレーションというキーワードから「社内ポータルサイト」および「共有文書管理のファイルサーバー」として使うユーザーもいれば、Notes からの移行でワークフローの機能を使い、社内のプロセスをワークフローでまわそうとする企業もある。

そこに独自の開発を入れる、もしくは開発を入れないと要件が満たされないということから、開発を依頼する会社も多い。


しかし、反面、SharePoint は Excel ユーザーにとっては「長年の課題」をお手軽に解決する可能性があるサービスであることはあまり語られない。

Excel ユーザーが長年課題として持っているもの、それは情報の収集・集約方法である。

複数のユーザーに対して Excel ブックで入力シートを作成し、それを配布、記入後にメール添付で返信、というような使い方をしているユーザーは多いだろう。そして、それら返信されたブックを開き、集約する作業、コピーする作業などを手作業でやるか、VBA でマクロ機能を使うか、といったものである。

そこで、SharePoint の「リスト」である。
SharePoint の「リスト」という機能は Excel との親和性が非常に高い。

以前に Excel のブックをそのまま SharePoint リストにする方法を紹介した。
http://road2cloudoffice.blogspot.jp/2014/11/office-365-sharepoint.html

実際、このようにすんなりいくことは稀であり、SharePoint リストの構造、リストでやれることやれないことを理解することで、この Excel エクスポートを使いこなすことも可能になる。

そこでおさえておきたい SharePoint リストの機能を紹介したい。ただ、この活用のポイントは SharePoint 側で「あまり凝ったことをやりすぎない」であることは最初に述べておく。そのかわり我々には Excel があるのだから、Excel でその補填をすることを考えると幸せになれるかもしれないということだ。

SharePoint のリストはワーシートみたいなもの

以下を見てほしい。これは SharePoint のリストをデータシートビューでみたものである。


このように1行が1件分のデータとして表示されているのを見るとワークシートの表に近いことがわかると思う。すでに紹介しているが、SharePoint リストは Excel へのデータ エクスポートが容易であることから、もし、データ入力が SharePoint 側で行われれば、その後の集計や分析は Excel のみで実施することができるのである。

SharePoint リストの1件分のデータを構成する「列」はどのようなものからなるか。始めから Excel にエクスポートすることを念頭において構成することで、その後の作業効率が大きく変わることは言うまでもない。

列作成で選択可能な種類

・ 1行テキスト
Excel にエクスポートすれば「文字列」になる。

・ 複数行テキスト
Excel にエクスポートすれば「標準」になり、データ(アイテム)のどれかに改行が入ったものがあれば「折り返して全体を表示する」のチェックがついた状態になる。いずれも文字列扱い。

・ 選択肢(メニューから選択)
Excel では文字列になる。選択肢は列の設定で候補を入力して、そこから選択した文字列が入る。

・ 数値(1, 1.0, 100)
Excel にエクスポートすると「通貨」分類の記号「なし」に設定される。パーセンテージの設定の場合は、「50.5%」とリスト表示され、Excel 側では表示形式「パーセンテージ」の 50.5% となる。

・ 通貨
あまり使わないが、リスト側で「\2,000」と表示され、Excel では表示形式「会計」の記号「\日本語」になる。

・ 日付と時刻
SharePoint リストのアイテム入力ではカレンダーコントロールを使うことができる。また、直接文字の入力も可能である。Excel にエクスポートすると、日付として認識されシリアル値としてエクスポートされる。

・ 参照
SharePoint リストの列の参照は、他のリストのデータを参照して、そこからドロップダウンなどで選択できる。Excel 側では文字列として設定される。

・ はい/いいえ(チェックボックス)
SharePoint リストでの入力画面はチェックボックスのオン/オフだが、入力後の表示は「はい、いいえ」になる。Excel にエクスポートすると「TRUE/FALSE」となり、標準セル扱い。


おおよそ上述の種類から選択することになるだろう。
うれしいことは日付のデータを「シリアル値」として Excel 側にエクスポートしてくれる点。( Excel が日付と判断してシリアル値にしていると思ったが、SharePoint リストの集計フィールドの数式でシリアル値を扱うことができるのでシリアル値をエクスポートしているかもしれない。) 他についても表示形式を設定して文字は文字、数値は数値として Excel 側で認識することが可能である。

ちなみに、文字列(1行テキスト)として定義した列の「001」は当然文字列の「001」としてエクスポートされ、「1-1」が「1月1日」になることはない。

なお、これらの列定義をしてリストを作成すると、入力画面は以下のようなものになる。
カレンダーコントロールや、ドロップダウンリスト、チェックボックスでシンプルな入力支援が可能だ。
必須入力の設定やちょっとした入力規則のような設定、IMEのオン/オフの設定も可能なので、ユーザーが入力しやすい、誤入力を避ける設定を検討すると良いだろう。


ビューやオートフィルターを使って「表形式で編集」する

SharePoint リストの画面では、特に設定をしなくても Excel と同じように「オートフィルター」による絞り込みが可能である。オートフィルターをうまく使って「リスト編集」によるデータシートビューでデータを確認、変更するのは Excel を使ってデータを操作する感覚に似ている。

ここで、入力されたデータの整合性のチェックなど、あるロジックを追加したい場合、手作業・目視で1件1件調べるか、SharePoint のアプリケーション開発となるが、このリストデータをそっくり Excel 側にエクスポートすれば、Excel ユーザーはワークシート関数やピボットテーブル、または VBA を使ってチェックが可能である。 Excel を使いこなしていれば、ここに開発のコストをかけることなく、整合性チェック程度は可能になるのだ。

もちろん、レコード件数を意識することになるが、数千件程度であれば現在の Excel と PC 能力をもってすればそれほど時間のかかる重い処理にはならない。

SharePoint リストはテーブル形式でエクスポートされる

SharePoint リストのデータはテーブル形式で Excel 側にエクスポートされるので、行数が変わっても構造化参照やピボットテーブルから参照していれば、「データ更新」するだけで最新のデータを参照・利用することが可能である。

テーブルのすすめ 構造化参照
http://road2cloudoffice.blogspot.jp/2014/11/blog-post.html

おおよそ、このようにテーブル形式でエクスポートされたデータを Excel で扱うのはピボットテーブルが使いやすい。このエクスポートされたテーブルは iqy ファイルを使ってデータ接続し、ワークシート上のテーブルのデータを更新するタイプで、前回まで紹介した「データ モデル」を使っていない。よって、データ モデルで話題となった集計フィールドや集計アイテムはこのテーブルを参照したピボットテーブルで使える。

なお、このようなデータ接続は SharePoint から Excel への一方通行のデータ接続である。Excel 側でテーブルを修正しても、その修正結果は SharePoint には反映されない。あくまで参照用であることを心に留めてほしい。

よって、Excel 側で整合性のチェックをし、その情報を元に SharePoint のリストのデータを修正、さらにデータ更新をかけて、整合性のチェックを行うことを繰り返すことになる。

また、そのチェック用の Excel ブックは SharePoint に保管して、他のユーザーと共有にしてもよい。他のユーザーもリストがあるサイトにアクセスが可能であればブックの接続プロパティにあるプロバイダとコマンド文字列の情報から、PCにある Excel でブックを開いてデータソースの更新が可能になる。

問題は Excel Services と Excel Online

上記の方法の問題点は Excel Services と Excel Online で iqy ファイルを使ったデータ接続の更新ができないことである。

ただし、SharePoint リストと Excel のデータ接続は iqy ファイルを使った接続だけではない。
このあたりの情報が整理つき次第紹介したいと思う。

[追記] OData データ フィード接続による Excel Online データ接続更新可能の記事が以下になります。
http://road2cloudoffice.blogspot.jp/2015/01/excel-online-excel-web-access-excel.html
[追記終わり]

ポータルだ、サイトだ、と考えずに

全社/部門ポータルを作る、などのアプローチから SharePoint に触れるケースも多いだろうが、現状 Excel でやっているこまごまとした業務を「入力」「計算」「出力」のロールやフェーズにわけて、入力の部分を SharePoint リストで行い、計算や出力の部分を Excel で行ってみてはいかがだろう。

SharePoint リストの場合はリスト アイテム単位のアクセス権の設定はリストの詳細設定から可能だが、込み入ったデータの扱いではリスト側で一工夫必要になる。それでも、単純な集計や申込み・申請業務などは SharePoint リストと Excel データ接続による Excel の処理を検討してみる価値はあるだろう。


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

$
0
0
SharePoint リストと Excel の親和性については前回紹介した。

Excel ユーザーのための Office 365 SharePoint Online
http://road2cloudoffice.blogspot.jp/2014/11/excel-office-365-sharepoint-online.html

この中で「あまり凝ったことをやらないほうがよい」と述べたが、その意味は、意外なところで「落とし穴」があったり、便利だと思って使ってしまうと業務上問題がでることに気づくのが遅かったりする可能性があるためだ。

システム開発のような要件定義、設計、テストといったフェーズを踏めば、そして、そのために SharePoint の良質なトレーニングを事前受けていれば、そのような問題や落とし穴を回避できるだろうが、エンドユーザー側が主となって活用するとなると、システム開発経験やデータベースの知識が十分あるとは言えない。

そこで、SharePoint リストの活用でありがちな落とし穴やはまりポイントを紹介する。もちろん、Excel との連携を考えた上での「ポイント」である。

入力規則的な使い方で「参照」に注意

Excel の入力規則で「リスト」を指定してドロップダウン リストから選択させる機能がある。
同様の機能として SharePoint リストの列設定で「選択肢」と「参照」がある。

選択肢は Excel の入力規則で選択されるアイテムを直接ダイアログの「元の値」に入力する方法と同じだ。



エンドユーザーの使い勝手、入力効率を考えれば、なるべく選択可能なものはドロップダウン リストから選択させたい。また、選択することで誤入力を抑えることができる。

この「選択肢」の列は、SharePoint から Excel にエクスポートすると、選択したものが「文字列」として処理され、Excel で利用可能になる。

一方、SharePoint リストの列の「参照」は Excel の入力規則でいうところの「元のデータ」が範囲やテーブルになったものと考えるといいだろう。参照先を変更すれば、ドロップダウン リストの内容も変更される。(最新のものになる、と理解しているだろう)


入力規則でテーブルを使う方法は以前紹介しているのでそちらも参照いただきたい。

http://road2cloudoffice.blogspot.jp/2014/10/blog-post.html

この方法は、元のデータの追加にもドロップダウン リストが対応できる点がテーブルを使うメリットだが、もし、「青」を「青色」と変更した場合、どうなるか。以下のアニメーション GIF を見ていただきたい。


ドロップダウン リストは参照先のデータの追加(黄)に対応し、修正(青→青色)にも対応した。
この動きを SharePoint リストの「参照」に期待すると業務上大きな問題がでる場合がある。

ワークシート上で最初にドロップダウン リストで選択した「青」は青のままだったことを覚えていてほしい。(A1セル)

SharePoint リストで参照先となる色のリストを作る。

他のリストの列で、この色のリストを参照する「列」を作成する。


そうするとリスト アイテム入力時に以下のように選択が可能になる。


Excel で行ったように黄を追加すると、ドロップダウン リストにも黄が追加される。


では、参照先リストの色のリストにある青を青色する。すると、参照している列に青色が追加されるが、その前に入力していた1行目の青も青色に変わっていることがわかるだろう。

この動きが Excel の入力規則 リスト 参照先テーブルとの違いである。
Excel の入力規則のリストのドロップダウン リストからの選択は、ドロップダウン リストは参照先から作成されるが、選択した場合、セルに入るのは「文字列」である。

一方、SharePoint リストの参照は、ドロップダウン リストは参照先のリストにより更新され、選択して入力されるのは文字列ではなく参照先のリストのアイテム「ID」なのだ。

そのため、参照先のデータが変われば、リスト上のデータも変更される。動きとしてはリレーショナルデータベースにおけるリレーションと同じである。

もちろん、過去にさかのぼってデータが一斉変更されたほうが良い場合もある。

しかし、過去のデータや一度入力したデータを変更したくないケースも業務上あり、その場合、安易に参照を使ってはならないのがわかるだろう。

参照先データが可変する場合は参照による追随は非常にありがたいのだが、もしアイテムそのものの変更が発生する可能性がある場合で一度入力したデータを変更したくない場合は、参照ではなく「選択肢」を使うべきだ。もちろん、選択肢はデータの増減に追随できないため、変更が発生したら、それを列設定で反映させなければならない。

Excel のワークシートと SharePoint のリストは親和性が高く、連携すると様々なことができるのは事実だが、このような違いがあり、そこに気が付くのに時間がかかることも多い。

この参照する列を含むリストを Excel にエクスポートすると以下のようになる。


参照列は文字列としてエクスポートされていることがわかるだろう。

上記の話はデータベース設計の経験があればすぐに気が付くと思うが、Excel でこなしている業務を SharePoint リストで補完し合うといった場合ではなかなか最初からは気が付かない。
参考になれば幸いである。

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

$
0
0
Excel ユーザーであれば、SharePoint リストを活用できるという話だが、リストの Excel へのエクスポート機能もさることならが、SharePoint そのものの「Excel 的な要素」を実感するのが「集計値」の列である。


列の情報の種類で「集計値」を選択すると、その列に「数式」を入れることが可能になる。また、リストで定義されている列を数式で使うことができる。まさに Excel の数式に近い。

そして、この数式で利用できる「関数」も用意されている。

Excel でもそうだが、単純な四則演算の他で入力されたデータを行単位で処理するパターンとしては、
  • 文字列操作
  • 日付の操作・計算
が主だろう。
もちろん、Excel にエクスポートしてしまえば、Excel だけで処理可能であるが、SharePoint リストのビューのグループ化などをする場合に、グループ化の列を入力されたデータから加工して作るケースも考えられる。

Excel ユーザーであれば「ニヤリ」とする場面も多々あることから、SharePoint リストでの数式、関数を覚えておいて損はない。

しかし、いつものように「落とし穴」もあるので注意してほしい。それらも含めて紹介する。

文字列の結合

"姓"と"名"を別々に入力させて氏名にするなどは "&"を使う。姓名の間に半角スペースを入れることも可能だ。アイテム入力にはこの集計値の列は表示されない。リスト表示の際は「氏名」だけを表示するビューを作成すればよい。CONCATENATE 関数も使える。


文字列のチェック/抜出し/置き換え

文字列操作では Excel でおなじみの LEFT、RIGHT、MID 関数、FIND、SEARCH 関数、REPLACE、TRIM、CLEAN 関数が使える。私が試した範囲だと全角を半角にする ASC 関数は動いていないようだ。半角を全角にする JIS 関数はない。(構文エラーになる)
TEXT 関数と VALUE 関数もある。特に TEXT 関数は日付の表示形式でも使う。
UPPER, LOWER, EXACT 関数もある。

もちろん、関数を組み合わせて使うことも可能だ。入力されたコードの "-"より前半部分を抜きだす数式は以下になる。

=LEFT(コード1,FIND("-",コード1)-1)



ただ、数式入力ボックスは狭く、数式オートコンプリートによる入力支援機能はない。よって、引数についてはワークシート関数と同じだと思って入力するか、SharePoint リストで利用できる関数のヘルプをみて入力する必要がある。

日付はシリアル値で保存されている

Excel ユーザーにとっては「!?」という事実なのだが、SharePoint リストで日付をシリアル値で扱っていることは Excel ユーザーにとっては大きなメリットだ。つまり、シリアル値が使えることで、若干 Excel の数式/関数とは違うがほぼ Excel と同様のことができる。

年、月、日、曜日を表示する

YEAR関数、MONTH関数、DAY関数を使えば、年、月、日を抜き出すことができる。ただ、これらの関数を使うと、「返されるデータの種類」を「一行テキスト」していても数値になる。(2014なら 2,014 といったように) 
ここで TEXT 関数を使えば =TEXT([日付データ], "YYYY") で文字列として年を取り出すことができる。 Excel 同様に1月を 01 と取り出したいのであれば、=TEXT([日付データ], "MM") となる。
残念ながら "g"や "ge"で元号はとれない。
曜日は若干数式が違うので注意してほしい。
Excel であれば、=TEXT([日付データ],"aaa") で「水」になり、=TEXT([日付データ],"aaaa")で「水曜日」になる。 "ddd"で「Web」になり、"dddd"で「Wednesday」となるが、SharePoint の場合は以下になる。

=TEXT([日付データ], "ddd")   「水」
=TEXT([日付データ], "dddd") 「水曜日」

"aaa"はなく、逆に Fri や Friday と表示させたい場合は、関数で工夫するしかない。

期間/時間の計算

シリアル値を使っているので、日数計算は単純な加減計算となる。
シリアル値で計算後の時間の表記については TEXT 関数を使う。特に TEXT 関数の  "[h]:mm"で24時間を超える数値の表記が SharePoint リストの数式でも指定可能だ。

[追記]
Excel でもそうなのだが、1日はシリアル値「1」なので、1をプラスすればよいが、時間になった場合は、12時間だから 0.5 と考えてはいけない。もし、11分だったら 11/60/24 で 0.0076333333.... と循環小数になる。安易に小数点による計算を勧める記事が多すぎるのは Excel のシリアル値操作での失敗例もしくは正しい使い方をご存じないからだろう。

時間の計算はシリアル値を直接操作せずに、文字列 "h:mm:ss"を加算するだけでよい。
たとえば、開始時間をリスト アイテムとして入力させて、集計値の列で予定終了時間を 4 時間後にする場合、入力する式は以下になる。

=TEXT(開始時間+"4:00:00","YYYY/MM/DD h:mm")

TEXT関数を使わなければ、集計値の列ではシリアル値が表示されてしまうため表示形式を関数で指定している。
もちろん、シリアル値として計算するので、60分を超えれば1時間繰り上がる、24時間を超えれば1日繰り上がる。(減算もしかり)

注意点は "h:mm:ss"は時刻表記であることだ。 h は 23 を超えることをはできない、mm や ss は 60 を超えることができない、という点だ。 70分を追加したいのであれば、 "1:10:00"である。26時間を指定したいのであれば、まずシリアル値に 1 を足した後で "2:00:00"を加算してほしい。


その他(日付関連)

シリアル値を使っているので、月末の日は翌月の1日から1を引けばわかる。その時、翌月の1日を作成するには DATE 関数を使って文字列の年月日表記をシリアル値してから1を引く。

=DATE("2014","3","1")-1

上記を応用すれば、うるう年の判定も可能だ。上記式の日付が "29"だったらうるう年である。

[注意] 四則演算結果の集計値の列を SharePoint リストで集計できない

これはできると思ってしまう「落とし穴」だが、たとえば、[数量] * [単価] で金額を計算する集計値の列を作り、SharePoint リストの「集計」を使ってその合計を出そうとしたくなるだろう。
しかし、残念ながらこの集計はできない。

あまり凝ったことは SharePoint リストでやらないほうがいい

ここまで紹介して、最後の結論がこれだとがっかりくるだろう。上述した計算結果を集計できない、また、[h]:mm の時間も集計できない。[h]:mm はTEXT関数で文字列になっているからである。Excel のセルの表示形式はセルの実体は変えずに見た目だけを変更しているが、SharePoint リストの列には表示形式という機能はない。なにより、入力するエリアの横幅がせまく、数式オートコンプリートも効かないため、長い数式は鬼門である。
あくまで、入力するユーザーにとって、または、リスト表示上最低限必要なものに限って数式を使ってデータの表現方法を変えるにとどめ、複雑な計算式は Excel にエクスポートしてからおこなったほうが無難だと言える。ここでも Excel のワークシート作成テクニックである「入力」-「計算」-「出力」の考え方は活きてくる。

注意してほしいのは、データ接続によって Excel 側に出された Excel の計算結果は元の SharePoint リストに標準の機能として反映されないという点だ。

それでも、Excel の計算結果を SharePoint のページ上でみたい、(つまり、「出力」)となれば、Excel Services である。次回は Excel Services を紹介したい。

[参考]
Office デベロッパー センター 「集計フィールドの数式」
http://msdn.microsoft.com/ja-jp/library/office/bb862071%28v=office.14%29.aspx

Office Online 「データ計算の説明」
http://office.microsoft.com/ja-jp/windows-sharepoint-services-help/HA010379914.aspx?CTT=1

Office Online 「列のタイプおよびオプション」
http://office.microsoft.com/ja-jp/office365-sharepoint-online-enterprise-help/HA010302193.aspx

Excel ユーザーのための Excel Services - Office 365

$
0
0
Excel ユーザーが Excel Services を全く知らない、というケースは往々にしてある。もちろん、Office 365 の E3 や、SharePoint Online の Plan 2、オンプレミスの SharePoint Server それも Enterprise 版でなければ使えないのだが、Excel を日々業務で使っているユーザーにとっては、Excel Services で何ができるかを知っておいて損はない。

Excel Services で何ができるのか

データ集計を Excel で行い、グラフと表を駆使してレポート用のワークシートを作るケースは多いと思う。その作成したワークシートを印刷して、上司なり管理担当者に渡したときに「これを社員全員で共有したい」と言われることも多いのではないだろうか。

ブックをメールに添付して関係者に一斉送信する、共有ファイルサーバーに保存してその場所を伝えると、「Web のページに貼り付けてみられるようにしてほしい」と言われる。そこでグラフを画像にして Web ページに <img src> タグを使って張りつける。

月に1度の月次集計の結果であればまだしも、週次、日次となるとその手間はかかる。そこでデータ集計結果をデータベースから C# を使って、Javaを使ってとりだし、JavaScript でグラフ表示ライブラリーを使って Web 開発をして、、、

「経営状況を可視化するダッシュボードを作成し、KPI を管理しましょう」

ここにいくらの投資をしているのか。また、しなければならないのか。

すでに Excel でグラフと表でレポート(=ダッシュボード)を作っているのであれば、それを公開したほうが早いと思うであろう。

Excel Services はブックそのもの(タブでワークシート選択可能)、名前(named range)で指定した範囲だけを SharePoint のページに表示させる機能である。

ブックを表示(タブでワークシートの切り替え可能)

グラフのみ表示

名前で範囲指定を表示

表示させるだけでなく、操作も可能

実務で使う分析シートは、部門別、製品別、担当者別などなど、データの切り口を変えてみたくなる場合が多い。この時、Excel ではピボットテーブルを使い対応することがもっとも効率的だ。
Excel Services は単にワークシートを表示させるのではない。Excel Online のように、SharePoint のページの中の Excel を操作させることも可能だ。(この Web パーツの実態は Excel Online のビューのようなものである)

これによりピボットテーブルを Excel Services で SharePoint ページに表示し、各種切り口で分析結果を変えて確認することが可能だ。

また、Excel 2010 で追加されたスライサーなど新しい機能も活用できる。操作性を考えれば、今までのフィールドリストでの選択や、ドラッグアンドドロップに比べて、ボタンを押すだけで切り口を変えるスライサーのほうが圧倒的に使いやすい。



表示方法を指定・保存した Excel ブックを SharePoint の Web パーツとして貼り付ける

使い方はいたってシンプルである。
通常の利用との違いは、表示させたい範囲や、グラフ、ピボットテーブル、テーブルがあれば、Excel ブックを保存するときに「ブラウザーの表示オプション」を設定し、SharePoint のドキュメント ライブラリーに保存するだけだ。


もちろん、このオプションはブラウザー表示(=Excel Online と Excel Services)でのみ有効で、ローカルPCの Excel で開けばすべてのワークシートを参照することが可能だ。

全員分の E3, Plan 2 ライセンスは要らない

とはいえ、この Excel Services を使うには E3/SharePoint Online Plan2 以上が必要だ。Office 365 E1 と E3 の一人当たりの月額ライセンス料はかなり違う。しかし、E3 が必要なのは Excel Services を使って SharePoint のページを設定するユーザーのみであり、参照するだけのユーザーは E3 である必要はない。

実務上 E3 までを有するべき人は現場の担当、責任者だけで、皮肉的だが参照するだけの経営層はそれほどの高機能のサービス/ライセンスを与える必要はない。もちろん、参照だけしかしない一般ユーザーも E3 を付与する必要はないのだ。

それでも落とし穴がある

Excel ユーザーにとっては、自分が作成したブックの出力結果を会社・組織全員と共有できる夢のサービスのように感じられると思うが、いつものように落とし穴が存在する。
  • VBAは動かない
  • シェイプやオブジェクト、SmartArt は表示されない
  • セルのコメントは表示されない
  • 外部ブック参照数式は再計算されない
また、最初の画像でわかるように凡例が文字化けしている。このような細かい調整はこれからだろう。


そして、大きな落とし穴が SharePoint リスト - Excel 連携で存在する。それは以下だ。
  • クエリ テーブル(外部データ範囲)は Excel Services から更新されない
があげられる。これはこのブログで紹介している SharePoint リストを Excel エクスポートしデータ接続(iqyファイル)から作成したテーブルも含まれる。

http://road2cloudoffice.blogspot.jp/2014/11/office-365-sharepoint.html

よって、SharePoint のページで共有できる状態は、ローカルPCの Excel でデータ更新をした時点のものに限られる。

できれば、Excel Services 上で更新、または、自動更新の機能を使って、最新情報をみたい、と思うだろう。

実は、SharePoint リストと Excel を連携させる方法は iqy ファイルを使ったデータ接続以外にもある。そして、Excel Services をさらに使いやすくする、上記の更新情報を提供する機能がある。それは PowerQuery と Power BI for Office 365 (有料別サブスクリプション)である。
これについては別の機会に紹介したい。

[参考]
Excel Online, Excel Services, Excel Web App の比較
http://office.microsoft.com/ja-jp/excel-help/HA102832426.aspx

Excel Services を使用して共同作業を行う
http://office.microsoft.com/ja-jp/excel-help/HA010108088.aspx

Excel と Excel Services のビジネスインテリジェンス
http://office.microsoft.com/ja-jp/excel-help/HA102915300.aspx

Excel Services で外部データを操作する
http://office.microsoft.com/ja-jp/excel-help/HA102830785.aspx

Excel で入力・計算・出力をイメージする ~ Office 365 との付き合い方

$
0
0
Excel ユーザーであれば、Office 365 とうまく付き合うことができる、という話である。

Excel を中心に位置付けてクラウド、Office 365をどのように活用できるか、という話題になるわけだが、これまで「テーブル」機能や「データ モデル」によるデータ接続先としての「SharePoint リスト」、さらにデータを効率的に操作するツールである「PowerPivot」を紹介してきた。

エクセル方眼紙がクラウド導入の邪魔をする

しかし、そもそも実務で使っている Excel ブック、ワークシートが「エクセル方眼紙」ばかりだと、Office 365 や SharePoint は単純な「ファイル共有サーバー」か OneDrive for Business による「ファイルの退避先、バックアップ先」という使い道しかないだろう。

一般社団法人実践ワークシート協会 代表理事の田中亨 (OfficeTANAKAサイトの管理者といったほうが知っている人が多いだろう)が提唱している Excel ブック活用のための考え方 ~ Excel 活用のための5つの原則 ~ の中に「入力・計算・出力」がある。

Excel 活用のための 5つの原則 (実践ワークシート協会サイトより)
http://www.pwa.or.jp/%E4%B8%8A%E9%81%94%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE5%E3%81%A4%E3%81%AE%E5%8E%9F%E5%89%87/

Excel にデータを入力する、入力されたデータを処理・計算する、処理・計算した結果をレポートや印刷として出力する、その「役割」や「フェーズ」をワークシート作成の際に「入力・計算・出力」として意識せよ、ということだ。

エクセル方眼紙は、この役割が入れ子になっている。まず最初に「出力用の表」を作成し、そこに計算・処理のためのワークシート関数を入れ、そのワークシートにデータを入力させ、その結果を印刷する、もしくは回収する、といった具合だ。エクセルブックで配られる「申請書」や「登録届」的なワークシートを目にすることは多いはずだ。

マイクロソフトがオンラインで提供しているテンプレートから作成
はじめから印刷をし、押印をして提出するようなものは Excel の印刷機能のメリットを十分に享受できるが、ブックで返信するような申請書などは、いったい回収した後でどう「集計」やデータの「再利用」をするのだろう。
選択肢などで図形の○を使っているものなどは、人間は目視で何を選択したか判断できるが、Excel は判断できない。(これをマクロで判断したい、などという無理・無駄・無茶な話も実際ある)

最悪なのは Excel 初級や入門コースなどで例題として出される「クロス集計表」だ。

よくある手で作成するクロス集計表
そのセルに入力するデータはいったいどこからもってきたのか?(このセルにデータを入力するために電卓を使っているユーザーを何人も目撃している)元のデータが変わったら、項目が増えたら、そのクロス集計表はどう直すのか。そもそも何故クロス集計のために用意されている最強機能である Pivot テーブルを教えないのか。事実、Pivot テーブルは「上級者編」として扱われることが多いが、ビジネスの現場にいる Excel ユーザーはクロス集計を使う場面が多いはずである。ワークシート関数などを覚える前に Pivot テーブルを覚えた方がはるかに効果的であると感じる人も多いだろう。このようなクロス集計表を手で作ってしまうと、そのワークシートに入力されたデータも、そのワークシート自体も「再利用」されないのは明白だ。

なぜこのような表を作ってしまうのか。その理由はワークシート作成時に「入力・計算・出力」を意識していないからである。また、意識せよと誰からも教わっていないからである。

クロス集計表が Excel 入門コースで使われる理由は「分析に便利なクロス集計」を教えることではない。罫線の引き方、SUM・SUBTOTAL関数の使い方、グラフの作り方、場合によっては実務で使い道が少ないアウトラインの使い方などを解説するためだけだ。さらに、入力・計算・出力の考え方からすれば、この表は手作業で作ってはいけない表なのだ。

入力・計算・出力から Office 365 の役割が明確になる

Office 365 特に SharePoint は「何でもできる魔法の箱」のような紹介をされるが、Exchange Online(メール)や Lync Online(メッセンジャー)に比べると、何をしてよいかがわかりづらいサービスである。しかし、Excel ユーザーからすると、この SharePoint Online こそ、Excel ユーザーが長年感じていた課題を解決してくれる場面が多い。

その課題とは「入力」である。

前提となるのは今扱っている表やテーブルが「1行1データの原則」に基づいて設計がされていることだ。

それができていれば SharePoint リストを入力で使えば以下が可能だ。
  • だれがその「行」をいつ作成したか、さらに最終更新者はだれでいつかがわかる
  • 簡単な集計やグループ化、並べ替えであれば SharePoint だけで可能である
  • 入力や更新・修正はあくまで「行単位」であり、ブック全体をロックする必要がなくなる
  • SharePoint リストのバージョン管理機能を使えば、バックアップを数世代とることができる
そして何より入力されたデータは SharePoint リストとして SharePoint に存在し、リストに対してアクセス権を持っている Excel ユーザーであれば複数人同時に SharePoint リストを元データとして自分の Excel でデータの処理ができるようになる。
ただ、何度も書くか、SharePoint リストに対して過大な期待は禁物だ。
Excel で現状やれていることは SharePoint リストでも可能なことが多いが、そこから「もっと便利に」と期待して作りこむと難易度が急に高くなる場合が多い。
最初は、Excel で行われている「入力」の部分を SharePoint リストにまかせる、と割り切って付き合い始めるのが良いだろう。

そうやって、SharePoint リストより収集されたデータを「テーブル」という形で Excel にエクスポートすれば、「計算」のフェーズである。四則演算だけではなく、文字列操作や、フラグによる論理演算なども「計算」だ。この計算は「出力」のための下準備である。ワークシート関数を使う、VBA を使う、Pivot テーブルを使うなどなど、様々な方法が考えられる。

そして最後は「出力」だ。

この出力のフェーズでは「エクセル方眼紙のテクニック」を存分に使ってよい。なるべく参照のみの数式にしたいところだが、どうしても論理演算からそのセル(または結合セル)を「空白」にするなど一部の関数・数式による処理も入るだろう。重要なのは出力では「見た目のための処理」に留めるべきであり、データそのものの加工や計算は印刷のための出力シートでは可能な限り避けることでメンテナンス性の高いワークシートになる。

実践ワークシート協会でも、VBA セミナーの受付はメールでいただき、そのデータを SharePoint リストに複数人で登録している。(もちろんメールボックスは共有メールボックスを使い、複数の人がメールを確認できるようにしている)アイテムを登録する時点で各開催日の申込み人数や、登録した受講者への受付、お断りといったステータスを管理している。受講者によっては「請求書」や「領収書」を希望する場合があり、その時は、SharePoint リストにデータ接続された Excel から氏名や宛先、受講コースや金額といったデータを抜出し、エクセル方眼紙テクニックで作成された「請求書ワークシート」や「領収書ワークシート」からデータを参照し、印刷している。

今後は Excel だけではない「入力・計算・出力」の考え方

前回紹介した Excel Servicesなどはまさに「入力・計算・出力」の「出力」の部分で活用される機能だ。
このように、実践ワークシート協会の田中が提唱している「入力・計算・出力」も、Excel だけの要素で考える時代が終わりつつあると感じている。(まだ、Excel の世界だけでも浸透していない考え方であり、今後も実践ワークシート協会はこの考え方を Excel ユーザーに啓蒙していかなければならないが。)

Excel + Office 365 で「入力・計算・出力」の考え方を使って、今利用しているブックを見直し、適切な機能をそれぞれのフェーズで使うことが今後ますます求められることになるだろう。そして、それを適切に見極め、利用できるユーザーが本当の意味で Office 365 のメリットを享受することができるのではないだろうか。

その可能性を一番持っているのは Excel を使いこなしているユーザーであると考える。

入力としての Excel アンケート

$
0
0
Excel ユーザーが「入力・計算・出力」の考え方で Excel や Office 365 のサービス/仕組みを適所適材で使うことが Office 365 の活用の早道である。

Excel Services が出力Office 365 SharePoint リストが入力で活用できることはすでに述べたが、もうひとつ Excel ユーザーとしてぜひ知っておきたいクラウド機能がある。

それが、Excel アンケート機能だ。

Excel アンケートとは

実は Excel アンケート機能は Office 365 だけの機能ではない。マイクロソフトがコンシューマー向けに提供している OneDrive でも Excel アンケートを利用できる。

OneDrive の Excel アンケート

企業向けの Office 365 OneDrive for Business さらには外部共有を許可した SharePoint Online のドキュメント ライブラリーでも Excel アンケートを作成することができる。外部共有を許可していないサイト コレクションのドキュメント ライブラリーでは作成からメニュー表示されないので注意していただきたい。

SharePoint ドキュメント ライブラリーの Excel アンケート

この Excel アンケートは、アンケートをお願いしたいユーザーに Excel を送るようなものではない。
アンケートを作成すると、そのアンケートは Web ページとなる。Excel アンケートの URL を受け取ったユーザーが Web を通してアンケートに答えると、その結果が OneDrive や SharePoint ドキュメント ライブラリーの Excel に入力される、というものだ。

アンケートを作成するのはいたって簡単だ。Web ページを作るといった感覚は全くない。

アンケートを作成する

OneDrive でも SharePoint Online ドキュメント ライブラリーでも Excel アンケートの作成方法は一緒だ。Excel アンケートを選ぶと「アンケートの編集」画面が表示される。「タイトル」や「説明」の入力欄がある。


さらに質問項目のエリアをクリックすると質問設定入力のエリアが表示される。


回答のタイプとして7種類用意されている。「段落の内容」はわかりづらい表現だが、「テキスト」が一行テキストであり、「段落の内容」は複数行テキストボックスである。

数値タイプでは書式が選択可能だ。「通貨」は自動的に日本の場合は円(\)が設定される。

選択肢タイプでは選択項目を入力・設定することが可能だ。

こうやってアンケートを完成させると、質問が列名の Excel ワークシートができあがる。


アンケートを共有する

作成されたワークシートのリボンのテーブルのセクションに「アンケート」がある。▼ を押して「アンケートの共有」を選択する。

アンケートの共有ダイアログに URL が表示される。これをコピーしてアンケート対象者に送る。SharePoint Online の場合は、URL がかなり長いので URL 短縮サービスを使うことをお勧めする。コンシューマー向けの OneDrive には共有リンク作成の際に URL 短縮機能がついている。


URL を開くと以下のような Web ページが表示される。


このアンケートの各質問項目に答えて [送信] をユーザーが押すと、その内容が Excel に反映されるのだ。

一度作ったアンケートの修正も可能だ。また、アンケートの URL を無効にすることもできる。

注意点はまだ微妙な実装があるところだろう。致命的ではないが、たとえば、[Yes/No] はアンケートでは [はい/いいえ] になるが、入力される値は既定値のままだと英語で、ドロップダウンリストから選択すると日本語になったり(この対応は選択肢タイプで「はい/いいえ」を作ればよい)、数値で書式をパーセンテージにして 10 と入れると 1000% になる。 0.1 といれれば 10% といったものだ。日付の入力などはYYYY/MM/DD を入力させるよりは日付ピッカーが欲しいところだ。このあたりは実際に試して確認することをお勧めする。

ピボットテーブルで計算、Excel Services で出力

このアンケート機能によって入力部分におけるメリットはすぐに理解できるだろう。アンケート結果は自動的に Excel に入力されるが、本質は「集計」である。この集計をピボットテーブルで行うことを前提として質問項目を設定するのがポイントだ。(フリーでなるべく入力させずに、選択肢から選択させることでデータを集計しやすくする、など)もちろん、アンケート結果は「テーブル」形式であり、ピボットテーブルは元データの範囲を指定しなおすことなくデータの増減に対応する。さらにピボットテーブルからグラフを作成し、ダッシュボード的なシートを作って Excel Services で表示することで、即時に結果を確認することが可能になる。(ただし、現状(2014/12)確認している限りでは Excel Services からのピボットデータ更新は不安定なときがある。(更新されない)ローカルの Excel で開いてピボットの更新、保存で対応する必要がある。)

まだ安定しているとは言えないが、今後のクラウドにおける Excel の方向性と可能性を感じることができるサービスであることは間違いない。コンシューマー向けの OneDrive でも利用可能なので、是非体験してほしい。

残念ながらできないこと

Excel アンケートは匿名アクセスを許可しているようなものなので「だれが」入力したかをシステム的に知ることはできない。そのため名前や ID などをアンケートの質問項目として自己入力してもらう必要がある。

さらに、「いつ入力したか」を知る術も現在のところない。Excel には TODAY() や NOW() などの関数があるが、アンケートからは関数を既定値として入力することができず、また、Excel ユーザーであれば気づくと思うが、この関数を使ってしまうと「常に再計算」される可能性があり、入力時点の日付や時間ではないことに気が付くだろう。

これらを解決したいのであれば、SharePoint の外部ユーザー招待を使って SharePoint リストでアンケートを実施するしかない。しかし、そうなると匿名アクセスはできず(だれが、を知るには当たり前だが)、必ずマイクロソフト アカウントもしくは Office 365 の組織アカウントでサインインしてもらう必要が出てくる。Office 365 ユーザー同志であれば問題ないが、一般ユーザーがアカウントの使い分けを熟知しているケースは少ないため、実際問題としては広く活用することはないだろう。

[参照] SharePoint Online 環境の外部共有を管理する
https://support.office.com/ja-jp/article/SharePoint-Online-%E7%92%B0%E5%A2%83%E3%81%AE%E5%A4%96%E9%83%A8%E5%85%B1%E6%9C%89%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B-c8a462eb-0723-4b0b-8d0a-70feafe4be85

Excel ユーザーのための Power Query

$
0
0
Excel 2007 以降、機能強化面で明らかに重点施策となっているのが「外部データの取り込み」である。[データ] タブの [外部データの取り込み] により、さまざまなデータソースからデータを取り込むことが可能になった。


しかし、マイクロソフトの SQL Server を導入していなければそれほど気にする Excel ユーザーはいないと思われる。使うとしても Access データベースが多かったのではないだろうか。(Web クエリも使えそうに思うのだが、それほど活用できるシーンは多くないのが実状だろう)

クラウド サービスが台頭するに従い、参照するデータが社内のサーバー(これを最近はクラウドと対比して オンプレミス と呼ぶ)だけではなくなり、また、そのデータ接続の形態も多様になってきた。

そのような流れのなかで Power Queryと呼ばれる Excel アドオンがマイクロソフトのダウンロードセンターから無料で利用可能になった。注意点としては、システム要件で Excel のエディションは Professional Plus, 365 Pro Plus の企業向けエディションに限られ、Home and Business / Solo などの個人向け Excel にはインストールすることはできない。また、インストールできたとしても、Professional Plus, Pro Plus 以外ではネット上に公開されているデータのみ参照といった制限が加えられる。

この Power Query は PowerPivot を含む Power BIと呼ばれるサービスブランドの主力製品の1つであり、これまでリボンの [データ] タブにあった [外部データの取り込み] を完全に置き換えるものである。

ところが、このブログの Office 365 SharePoint リストとの連携などで、Power Query を一度も使っていない。 Power Query を使わなくても SharePoint リストをテーブルとして Excel に取り込むことはできる。現在のところ、このあたりの機能は「移行期」であり、同様の結果をもたらす機能がいくつかあるが、明らかにマイクロソフトは Power BI を軸にして、Excel をデータ分析のツールとし、クラウドでも重要なポジションとなるように拡張している。

では、クラウド以外では Power Query は使えないのか?というとそうではない。
あえて今回の投稿のタイトルを「Excel ユーザーのための」としたのは、クラウドを使っていない環境でも Power Query の活用シーンが多いからである。

CSV データの取り込み

従来の 「テキスト ファイル ウィザード」(データ タブのテキスト ファイル)を使って CSV データを Excel に取り込んでいるユーザーも多いだろう。CSV データ ファイルはマイクロソフトが Excel に関連付けしているためダブルクリックでも取り込むことができるが、鉄板ネタの「001 が 1 になる」「1-1 が1月1日になる」といったユーザーが期待しない変換をする。このため、このウィザードは必須であった。


Power Query の CSV 取り込みでは、上記のウィザードでできることはもちろん、様々な強化がされている。

取り込み条件を設定するクエリ エディターのホーム画面

Power Query は単純にデータを取り込むだけでない。取り込む「列」の指定や列の順番の変更を[ホーム] タブの [列の管理] で指定できる。取り込む行数の削減や並べ替え、さらには列内の文字を置換したり、区切り文字を指定して列の分割も可能だ。また、[カスタム列の追加] も可能で、その列には数式により、他の列を参照したり、Power Query 関数を使って計算が可能だ。

以前 PowerPivot で紹介した DAX 関数とは表記方法が違う。PowerPivot の DAX 関数は Excel のワークシート関数に非常に近かったが、Power Query 関数はワークシート関数とは表記法が違うので戸惑うこともあるだろう。しかし、このようにデータ取り込み時に計算までしてしまえば、取り込んだあとのワークシートがシンプルになるのはメリットと言える。

Excel データの取り込み

さらに、ローカル PC やファイルサーバー上にある Excel ブックからデータを取り出すこともできる。それも、そのブックを Excel で開くことなしに取り込むことができるのだ。

また、ブックに複数のワークシート、そしてテーブルがある場合は、それらを判断してナビゲーション ウィンドウで選択することができる。


取り込みたいデータを選択すれば、上述の CSV で行った加工が同様に可能である。
しかし、これだけだと Power Query を使って Excel のデータを取り込むメリットが実務面ではわからないだろう。

Power Query は「クエリ」という単位で取り込む条件を記憶する。データ取り込み先の情報にはじまり、クエリ エディタで設定した条件などを保持することができる。

そのクエリを使って、さらにデータの加工が可能なのだが、特筆すべきはクエリによる結果データ(テーブル)の「追加」と「マージ」ができることだろう。


クエリによるデータ(テーブル)の追加 (Append)

実務では同じ列の表(データ)を追加するという業務も少なくない。
そのような場合、手作業で範囲をコピーして、コピー先にペーストするか、自動化するために VBA を使うなどが考えらえる。

このデータ追加の作業も Power Query を使うことで可能だ。

蓄積している表(またはテーブル)を取り込むクエリと、追加するデータを含む表(またはテーブル)を取り込むクエリを作成し、双方のクエリを「追加」結合させることで、双方のテーブルを結合した新しいテーブルを作ることができる。データベースの世界ではユニオンと呼ばれる機能である。

たとえば、過去のデータは Excel のブックのワークシートに保存されており、今期のデータは CSV や Excel ワークシートとして更新されているようなケースでは、過去のデータのクエリと、現在進行中のデータのクエリを「追加」結合させることができる。もし、列順が違う、今期から列名に修正が入った、、、などの事態が発生した場合は、クエリ エディターを使って追加結合できるように修正すればよい。

そして、この方法の最大のメリットは、一度作ってしまえば、そのクエリは再利用が可能なことである。もちろん、実務では参照先のファイル名が変わるケースもあるだろうが、もし、上書きでファイルが更新されるような場合は「データ更新」するだけで最新のデータを参照して結合することができるのだ。

結合できるクエリの数には上限はない。(扱うデータによってメモリの上限はあるはずだが。)
2つのクエリを結合するクエリは既定で「Append1」のような名前のクエリになる。さらに結合させたいクエリがあれば、この Append1 にそのクエリを使って追加結合させる。これを繰り返すことで3つ以上のクエリを結合させることができる。

CustmerList クエリと CustmerList1 クエリを追加結合する Append1 クエリ

クエリによるデータのマージ

かたや、マージは Excel 2013 以降に追加されたリレーションシップ、もしくは PowerPivot のリレーションと同じことができる。


さらに、PowerPivot で行った RELATED 関数を使わずに参照先の欲しい列を挿入することができる。


一般的には一度ワークシートに取り込んでから加工をするのがわかりやすいが、件数が多いときなどは、上記の追加結合やマージ結合を含むデータの加工処理のためのクエリ作成で、ワークシートに参照先の全データを取り込む必要がない。

表・テーブルの読み込み先の指定の「データを表示する方法」で「接続の作成のみ」を選択して、クエリを作ることで、全データを読み込むこと無しに、そのクエリを使って加工、追加結合、マージ結合が可能になり、そのクエリ結果だけをワークシートに書き出すことが可能だ。


そして、この操作をする上で PowerPivot のように「データモデル」に追加する必要がないのも、Excel のピボットテーブル ユーザーにとってはうれしいことだろう。

「機能」への拡張

Excel は「機能」、「関数」、「VBA」の3要素から成り立っている、というのは実践ワークシート協会 代表理事 田中 亨の主張であるが、その中でもとりわけ最近のマイクロソフトは「機能」面における拡張を推し進めている。確かに、新しいバージョンの Excel でできることは昔の Excel とそれほど差がないかもしれない。上述のようなデータの操作も、もし、VBA に精通しているユーザーが多くいれば、わざわざ新機能を使って同じことをする必要はない。

しかし、現実は、そのように VBA を使いこなせるユーザーが多いわけではない。ワークシート関数はブックのメンテナンスという観点からみると VBA 以上にやっかいなものであることを多くのユーザーが気づいていない。複雑なワークシート関数を使ったブックにはコード(数式)の一覧性がなく、そのワークシートを作った本人ですらメンテナンスができるかどうかあやしいのだ。

その状況を顧みれば、いままで VBA でやっていたこと、複雑なワークシート関数を駆使して実施していたことを「機能」だけで実現できるのは「組織にとって」大きなメリットであり、マイクロソフトはそちらのほうに向かってユーザーの利便性を高めようとしている。

そう理解して新機能、新バージョンと接することが、本当の意味で業務の効率化や、効果的な Office の活用ができると考えている。

OneDrive/SharePoint ドキュメント ライブラリーは使えない

[追記:2015年6月版 2.23.4035.242 で HTTPS 経由でのアクセスが可能になりました]

と、いつものパターンの落とし穴だが、最後にできないことを紹介しておく。

Power Query でローカルPCや LAN 上のファイルサーバーにある Excel ブックからデータを取りだすことを紹介したが、残念ながら現在の Power Query のバージョン(2014年11月版 2.17.3850.242)では https 経由で OneDrive、OneDrive for Business、さらに SharePoint のドキュメント ライブラリーにある Excel ブックからデータを取り出すことができない。

ただ、同期ツールを使ってローカル PC のエクスプローラーにある OneDrive / OneDrive for Business フォルダーから Excel ブックを利用することは可能だ。現在、OneDrive は無制限になっているのでオフライン同期するフォルダー選択には注意が必要だ。

Power Query そのものは2~3か月に1度に更新されるような頻度であり、どんどん機能拡張・追加されてきた。OneDrive や SharePoint ドキュメント ライブラリー内の Excel ブックにアクセスできる機能拡張の早急な実装を期待したいところだ。これが可能になると Excel 中心で実務を動かすユーザーにとってはさらに Office 365 の利用シーンが広がるだろう。


[参照]

(英語) Power Query formula categories (Power Query で利用できる関数一覧)
https://support.office.com/en-us/article/Power-Query-formula-categories-125024ec-873c-47b9-bdfd-b437f8716819

Office Online - Microsoft Power Query の概要
https://support.office.com/ja-jp/article/Microsoft-Power-Query-for-Excel-%E3%81%AE%E6%A6%82%E8%A6%81-6e92e2f4-2079-4e1f-bad5-89f6269cd605

Excel Online / Excel Web Access (Excel Services) - データ接続の更新 SharePoint リスト

$
0
0
Office 365 SharePoint Online に Excel ブックを保存して他のユーザーと共有する、という使い方でもメリットがあるが、できれば保存したブックの中を簡易的に確認したい、編集する必要はなく参照だけで良い、という使い方もあるだろう。
 
このような場合、Office 365 SharePoint Online では以下の使い方が用意されている。
 
・ Excel Online で Excel ブックを開く
・ Excel Web Access Web パーツ(Excel Services) でサイトのページに貼り付ける
 
いずれの場合も「現時点での最新データを見たい」という目的であることは明確だ。
 
ブックで扱うデータがワークシートへの手入力の場合、Excel ブックの SharePoint に保存した状態を参照できる。ある意味、それが最新であり問題はない。問題になるのは「データ接続」している場合である。
 
Excel はさまざまなデータ ソースに外部データ接続機能を使って接続できるが、今回は SharePoint リストに接続したブックを Excel Online や Excel Web Access Web パーツで扱う場合を紹介したいと思う。
 
注意点としては、一部 TechNet や MSDN に明確に書かれていない方法を紹介することになる。米国マイクロソフトの英語版 Office ブログやフォーラムで Microsoft の担当者からの情報などを参考にしているが、私自身はそれを元に TechNet/MSDN といった公式技術文書で同様の記述をまだ見つけ出すことができていない。その点は留意されたい。
 
1つではない SharePoint リストとのデータ接続方法
 
SharePoint リストのデータを Excel にインポートする方法の代表格は SharePoint リストの「リスト」タブにある「Excel にエクスポート」だろう。
 
 
通常業務でリストのアイテムを Excel に取り込んで PC で集計・分析・レポートを作るのであれば、このエクスポートでほとんど問題がない。
 
ところが、この接続方法を使ったブックを SharePoint に保存し、それを Excel Online で開こうとして以下のようなメッセージを見たことがある人は多いだろう。
 
 
[詳細の表示] ボタンをクリックすると以下のダイアログが表示される。
 
 
このメッセージを見れば、多くの人は「SharePoint リストを使った Excel ブックは Excel Online で使えないのか」と思っても仕方ない。この接続方法を含んだブックのデータ接続は Excel Online で使えない、サポートされていないことは事実である。
 
実は SharePoint リストのデータを Excel にエクスポートする方法は数種類ある。区別を明確にするために、「接続のプロパティ」の「接続の種類」で使われている名称を使って分類したものが以下だ。
 
a) 接続の種類 : SharePoint リスト
SharePoint の [リスト] タブの [Excel にエクスポート] を使ったデータ接続。
 
b) 接続の種類 : Office データ接続
Excel のデータ タブの [その他のデータソース] の [OData データ フィード] を使ったデータ接続。
データ モデルは強制的に作成される。
 
c) 接続の種類 : OLE DB クエリ
PowerQuery の [その他のデータソース] の [OData フィードから] を使ったデータ接続。
ただし、データモデルの作成はしていないタイプ。
 
d) 接続の種類 : モデル OLE DB クエリ
PowerQuery の [その他のデータソース] の [OData フィードから] を使ったデータ接続。
データ接続作成の際、データモデルの作成も指定。
 
Excel と Office 365 SharePoint Online との接続という意味では上記の4つがある。
 
「SharePoint リスト」という接続の種類を含んだブックは Excel Online では利用できないが、MSDN や TechNet、Office Online などを調べると、OData フィードによる接続は Excel Online で利用可能、という記述を見つけることができる。
 
 
ところが、OData フィードによる接続も上記のように「Office データ接続」、「OLE DB クエリ」、「モデル OLE DB クエリ」の3種類存在し、かつ、そのまま利用しても、いずれの OData フィードのデータ接続でデータ接続の「更新」(refresh)ができないのが現状だ。

結論からいえば、ある「設定」をすることで、Excel Online や Excel Web Access Web パーツでもブックのデータ接続を更新して最新のデータを見ることが可能だ。その手順およびそれに対応した接続方法を紹介する。
 
Office データ接続で SharePoint リストをエクスポートする
 
Excel Online や Excel Web Access Web パーツ(Excel Services) での利用を考えているならば、SharePoint リストからのデータ取得は接続の種類「Office データ接続」を使うべきと言える。この接続方法であれば、ある設定(アプリ権限の付与)をすることで Excel Online 上でデータ接続更新が可能になる。
 
では、Office データ接続による OData データ フィードの構成をしてみよう。
 
1) エクスポートしたい SharePoint リストの URL を控える。
 
たとえば、以下のようにブラウザで SharePoint リストを表示した時、控えておきたい URL は "_layouts/15/start.aspx#/Lists/Seminar/"の前にある "https://jpwa.sharepoint.com/sites/r2co/"を控えておく。

 
2) Excel のデータ タブ - その他のデータ ソース の OData データ フィードで接続を構成する。
 
データ タブの [OData データ フィード」を開く。
 
 
データ接続ウィザードのダイアログが開く。
控えておいた URL の後に "_vti_bin/listdata.svc"と入力して [次へ] をクリックする。
このサンプルの場合は、"https://jpwa.sharepoint.com/sites/r2co/_vti_bin/listdata.svc "と入力する。
 
 

[追記] ここで Office 365 へのサインイン画面が表示される場合がある。一度、接続に対してアカウントとパスワードを登録することで、接続情報を削除しない、パスワードを変えないかぎり、接続の際のサインイン画面をスキップすることが可能になる。
[追記終わり]

テーブルの選択をする。ここでのテーブルは SharePoint の「リスト」を指している。
取り込みたいリストにチェックを入れて [次へ] をクリックする。
 
 
ファイル名や説明を変更できる最終ダイアログが表示される。Excel Services などの認証は変更せずにこのまま [完了] ボタンをクリックする。
 
 
データのインポート ダイアログが開く。表示方法の選択肢があるが、テーブルとしてインポートするのであれば、そのまま [OK] をクリックする。ここで [このデータをデータ モデルに追加する] オプションがチェック済みになっていてグレイアウトされている。強制的にデータ モデルを作成していることがわかる。
 
 
SharePoint Online のリストが Excel のテーブルとしてインポートされた。
 
 
この素のままのテーブル データを見るより、ピボット テーブルを使ってレポート形式にした方が実用的だ。このテーブルを利用してピボット テーブルを作成する。もちろん、この前の処理でのデータ インポートで「ピボット テーブル レポート」を選択して、素のテーブルを取り込まないことも可能だ。
 


OData データ フィード接続を含んだブックを SharePoint に保存する

このブックを SharePoint Online のドキュメントライブラリに保存する。
一旦ローカルに保存したものをアップロードしてもよいし、直接 SharePoint Online のドキュメントライブラリーを指定してもよい。この時、上で作ったピボットテーブルだけを Excel Online で表示・参照させたい場合は、ブラウザーオプションでピボットテーブルだけを指定しておく。
 


ではこのブックを SharePoint Online から Excel Online を使って開いてみる。
SharePoint リスト接続と違うのは、ブックを開いたとき、SharePoint リスト接続のような警告メッセージは表示されずに、指定したピボットテーブルが表示される。
 

なお、この状態でピボットテーブルのフィールドリストを操作してデータの分析が可能であり、これだけでも使い道は多いにあるだろう。

しかし、まだ、これだけでは SharePoint とのデータ接続のデータ更新は成功しない。Excel Online でデータ更新しエラーになる状況をアニメーションGIFでとったものが以下である。なお、データは上記とは別のブックで、データ接続更新設定をしていない別のテナント(Office 365) で実施したものになる。


SharePoint リスト接続とは違う以下のエラーメッセージが表示され、データ更新に失敗している。

----
外部データの更新が失敗しました。
ブック内のデータ モデルを処理しているときにエラーが発生しました。もう一度やりなおしてください。

このブックに指定されている1つ以上のデータ接続を更新できません。
以下の接続を更新できませんでした:
----

接続名はデータ接続ファイルを保存した時に指定したものが表示される。

Excel Online でデータ接続更新を可能にする設定(アプリ権限付与)を行う

冒頭に述べたように私自身が Office Online/TechNet/MSDN 内で公式な技術文書として探し出せていないのが、この設定である。ただし、この情報ソースは米国マイクロソフトの英語による社員ブログやフォーラムでマイクロソフト社員より提供されているものである。

(参照)
Office Blogs - Project Online and Excel Web App: Cloud data improves reporting
Project Online の OData フィードを Excel Web App で利用しデータ更新を可能にする設定について書かれたブログ(2013年3月29日)
http://blogs.office.com/2013/03/29/project-online-and-excel-web-app-cloud-data-improves-reporting/

[SOLVED] Excel service refresh issue
SharePoint リストを OData データ フィードで Excel 2013 で取り込み、Excel Online でデータ更新できない件について、MSFT Support から、この設定を提示しているフォーラムの投稿(2014年12月20日)
http://community.office365.com/en-us/f/172/t/284523.aspx

もし、Office データ接続 OData データ フィードを使った Excel Online でのデータ更新が成功している場合、すでにこの設定が他の管理者権限を持っているユーザーによって行われていると考えられる。この設定登録はサイト コレクションレベルでの登録だが、設定そのものはOffice 365 の「テナント」レベル(契約している Office 365 全体)にも登録される。そのため、例えば、テスト用のサイト コレクションでアプリ権限付与設定を行い、テスト終了後にサイト コレクションに登録された権限付与設定を削除しても、テナントレベルの登録を削除しない限り、テナント全てのサイト コレクションで有効状態になっている。そのため、該当するサイト コレクションで登録していなくてもデータ接続更新が可能になっている場合がある。

[追記] 上記の表現は正確でなかった。リンク先の記事の XML で「テナント」範囲での指定をしているからだ。スコープの指定がサイト コレクションであれば、登録したサイト コレクションのみ有効になる。サイト コレクションのみ有効になる XML は追記した。
[追記終わり]

登録するアプリのプリンシパル ID は "00000009-0000-0000-c000-000000000000"である。現在このプリンシパル IDのアプリ名は "Power BI"もしくは "Microsoft Power BI Reporting and Analytics"となっているはずだ。上述の Office Blogs では "Microsoft Azure Analysis Services"だった。(2013年3月末)
今後もアプリ名(Title)が変わる可能性があることに注意されたい。

1) テナントでの権限付与状態の確認

上記のプリンシパル ID のアプリへの権限がテナントに登録されていないことを一応確認する。
この確認は全体管理者権限を持っていないとできないのでユーザーの権限に注意すること。

管理ポータルを開く。


もしくは、以下から管理ポータルを開く



SharePoint 管理センターに移動する。


SharePoint アプリの管理へ移動する。左サイドバーの [アプリ] をクリックする。


アプリの権限をクリックする。


アプリの表示名に「Power BI」もしくは「Microsoft Power BI Reporting and Analytics」が無い、もしくは、「00000009-0000-0000-c000-000000000000」を含んだアプリIDが無いことを確認する。


なお、登録されているアプリはそれぞれのテナント環境で違うので上記図と同じにならない場合もあることを留意されたい。

2) サイト コレクションレベルでの確認とアプリの登録

登録は管理センターからはできず、サイト コレクションから行う。どのサイト コレクションから登録しても結果としてテナント レベルの登録になるが、一応、Excel Online で使いたいブックを含んだサイトから登録する。

[追記] テナントレベルの登録になるのは、後述する XML によるアプリの権限要求でテナントレベルを指定したためだった。
参考: http://msdn.microsoft.com/ja-jp/library/office/fp142383(v=office.15).aspx
追記したアプリの権限要求 XML で登録作業をしたサイト コレクションのみ有効にすることが可能。
[追記終わり]


SharePoint サイトに移動して右上の「歯車アイコン」から「サイトの設定」を選択する。


[サイト コレクションの管理] の [サイト コレクションのアプリの権限] をクリックする。
サブサイトのサイトの設定画面を開いている場合は [トップ レベルのサイト設定に移動] をクリックして、[サイト コレクションのアプリの権限] をクリックすること。


Microsoft Power BI Reporting and Analytics が無いことを確認する。



次はアプリの登録とアクセス権の設定をするのだが、これまで行ってきたメニューからの操作が現状ではできない。登録画面の URL を直接入力することになる。

現在、[サイトの設定 > サイト コレクションのアプリの権限] の画面を開いている。その URL は以下のようなものだ。/_layouts/ より前の部分はそれぞれの環境で違うが、/layouts/ 以降は同じだ。

https://hogehoge.sharepoint.com/sites/hoge/_layouts/15/start.aspx#/_layouts/15/appprincipals.aspx

この appprincipals.aspxappinv.aspxに変更して Enter キーを押す。

すると以下の画面が表示される。


アプリID: に 00000009-0000-0000-c000-000000000000 を入力し、[参照] ボタンをクリックする。
タイトルに [Power BI](違う場合もある)、アプリ ドメインに [analysis.windows.net] が表示される。タイトルはテナントの SharePoint Online のリリースによって違う場合があることを確認している。

アプリの権限要求 XML に以下の XML をコピーして貼り付け、[作成] ボタンをクリックする。

<AppPermissionRequests><AppPermissionRequest Scope = "http://sharepoint/projectserver/reporting" Right="Read"></AppPermissionRequest><AppPermissionRequest Scope = "http://sharepoint/content/tenant" Right="FullControl"></AppPermissionRequest></AppPermissionRequests>

[追記] http://msdn.microsoft.com/ja-jp/library/office/fp142383(v=office.15).aspxを参考にして、必要ない projectserver の AppPermissionRequest Scope を除き、サイト コレクションでの権限にしたものが以下になる。

<AppPermissionRequests>
  <AppPermissionRequest Scope = "http://sharepoint/content/sitecollection" Right="FullControl"></AppPermissionRequest>
</AppPermissionRequests>

この XML で Excel Online のデータ接続更新が可能を確認している。
[追記終わり]


タイトル名のアプリを信頼しますか?という確認画面がでるので、[信頼する] ボタンをクリックする。



サイトの設定画面にもどるので再度[サイト コレクションのアプリの権限]を開いて登録されていることを確認する。繰り返しになるが、アプリのタイトルはテナントのリリースによって違うことが確認されている。重要なのはアプリIDであることに留意されたい。


この状態で、(追記: アプリ権限要求の XML で Scope をテナント指定していれば)再度テナントレベルを確認すると以下のようにアプリが登録されていることがわかる。


なお、上記の操作でアプリのタイトルが「Power BI」になっているが、この操作をしたテナントでは Power BI for Office 365 のサブスクリプションは購入していない。

もし Power BI for Office 365 をすでに購入していた場合は、テナントレベルでのアプリの権限で「Power BI」というアプリの表示名が表示されるが、そのアプリ ID は 00000009-0000-0000-c000-000000000000 ではない。これで判別ができるだろう。

3) Excel Online でデータ接続更新の確認

Office データ接続 OData データ フィードによるデータ接続を使ったブックをアップロードし、レポートのアプリ ID を登録してアクセス権を付与した状態で、はじめて Excel Online 上でのデータ接続更新が可能になる。実際に試してみよう。

以下は、上述でアニメーションGIFで失敗例としてあげた使ったブックと同じものである。
上記手順でアプリの登録と権限付与を行い、データ ソースである SharePoint リストでアイテムを追加登録した状態で Excel Online でデータの更新をした。


Excel Web Access Web パーツをサイトに貼り付け、データ更新を実行したのが以下だ。



いつものお約束 - 注意点

実務で実際にこの機能を運用すると、以下の事にすぐ気づくはずだ。

1) データ更新しても、その状態でブックは保存されていない

よって、次に開いたときやブラウザを F5 でリロードすると「元のデータ」に戻る。

これは、通常のローカル PC の Excel のピボットテーブルを考えてもらえれば想像に難くない。データ更新しても、ブックを保存しないで Excel を終了させているようなものだ。

ただ、この設定をすることで、[Excel Online で編集] においてもデータ接続の更新が可能になるので、編集モードにしてデータ接続の更新をすれば「保存」したことになり、データも最新になった状態になる。

結局、参照のみの Excel Online でのデータ更新や、Excel Web Access Web パーツでのデータ更新より、Excel Online の編集モードでデータ更新、そして保存、という運用になってしまう。PC の Excel で更新、アップロード、という手間がなくなった、ということだ。

2) データ接続の自動更新はできない

データ接続のプロパティで自動更新のオプションがあることを知っている人も多いだろう。


これは使えない。設定してもなんの変化もない。
理由は、データ モデルが更新されていないためである。データ モデルはピボットキャッシュのようなものだと考えれば理解できる人もいるだろう。実データはデータ モデルを介してサーバー側からとりこむため、データ モデルを更新しないかぎり、ピボットテーブル レポートのデータは更新されない。そして、データ モデルの接続プロパティの [定期的に更新する] オプションはグレイアウトされて設定不可能になっている。


3) Office データ接続のみ有効で PowerQuery によるデータ接続の更新はできない

PowerQuery のデータ モデルを使った接続 (モデル OLE DB クエリ)であっても、上記のアプリ ID とアプリ権限設定後、Excel Online や Excel Web Access Web パーツ内でのデータ更新はできない。

以下のメッセージが表示されエラーになる。

外部データの更新が失敗しました
ブック内のデータ モデルを処理しているときにエラーが発生しました。もう一度やり直してください。
このブックに指定されている 1 つ以上のデータ接続を更新できません。
以下の接続を更新できませんでいた:
Power Query - List01
接続: Power Query - List01
エラー: OnPremise エラー:問題が発生しました。もう一度やり直してください。
テーブル "List01"の処理中にエラーが発生しました。
トランザクションの別の操作が失敗したため、現在の操作は取り消されました。


もう一度やりなおして、、、とあるが、何度やり直してもデータの更新はできない。
Power Query によるモデル OLE DB クエリ / OData フィードは Power BI for Office 365 の Power BI サイトで使用する。

現状、複数あるデータ接続が、使用する機能別に用意されているため難解になっていることは否めないが、ここは過去の資産の蓄積と将来のために追加された新機能として理解するしかないかもしれない。

まとめ

Office 365 SharePoint リストと Excel 連携を最大限に活用するならば、SharePoint のリスト タブにある「Excel へエクスポート」(SharePoint リスト接続)を使わず、Excel のデータ タブにある「OData データ フィード」(Office データ接続)を使ったほうが便利になりそうなことは理解できたと思う。

しかし、ものすごく便利になるか、といえば微妙であるのは否めない。
ローカル PC の Excel で集計・分析し、それを SharePoint にアップロード、アップロードした時点での情報を Excel Online/Excel Web Access Web パーツで表示、という運用で多くはカバーできるのも事実である。

Office データ接続の OData データ フィードで、Excel Online / Excel Web Access Web パーツのデータ更新が可能になるメリットを享受できるが、たぶん、実務でこの機能を求めるのであれば「自動更新」というニーズがあるはずだ。
残念ながら、Excel Online と OData データ フィードだけでは自動更新のニーズを満たすことはできない。

この自動更新のニーズを満たすのが Power BI だと考えている。

事実、Power BI には以下の設定オプションがある。


残念ながら PowerBI はサブスクリプション購入したばかりで実務運用のレベルまで使っておらず、かつ、その設定も確実に理解していないため、これ以上の紹介はできないが、近いうちに紹介することができるだろう。

非常に長いエントリーになってしまったが、マイクロソフトによる日本語ドキュメントがまだ整備されていないようなので、何等かの参考になれば幸いである。

Power Query を使った重複行の削除

$
0
0
重複行の削除もしくはユニークなデータのリスト作成も実務で Excel を使うユーザーにとっては往々にして直面する課題である。

いくつかある重複行の削除

現在、重複行の削除で Excel 2007 以降に追加された データ タブ - データ ツールにある「重複行の削除」がもっとも紹介されている機能だろう。


表の重複している項目を削除する(Microsoft atLife)
http://www.microsoft.com/ja-jp/atlife/tips/archive/office/tips/002.aspx


たしかにこの機能により重複行を削除し、ユニークデータのリストの作成が可能なのだが、元データが更新されれば、同じ作業をし直さなければならず、この機能を活用するシーンは私自身はあまりない。正直、単純で汎用性が乏しく実務では応用した活用が難しいのだ。


一方、ピボットテーブルを使うことで元のデータが更新されても重複行を削除した表/リスト作成が可能だ。この方法であれば、元データが更新されてもピボットテーブルの「更新」をすることで対応できる。



ただし、注意したいのは、ピボットテーブル レポートのピボットテーブルは構造化参照可能なテーブルではない。ユニークデータリストを作って終わり、ではなく、そこから何らかの集計・計算・データ利用において、構造化参照によるテーブルの利用ができないため、他への再利用が難しい。テーブルではないことから、データの増減が発生したときの構造化参照テーブルのメリットも使えない。



上記の例ではデータカウントを取ることが目的ではない。逆にピボットテーブルなのでカウントの取得は簡単だ。しかし、このブログでも再三紹介しているように、現在そして今後 Excel はテーブル機能をベースにして拡張、新機能が追加されている。なるべくテーブルを使った課題解決方法を手にしておきたいところだ。

参考までに、もちろん、VBA を使った重複行削除のテクニックもある。

重複行を削除する(OfficeTANAKA)
http://officetanaka.net/excel/vba/tips/tips14.htm

VBA を使えば、重複行削除をしたユニークデータのリストを作成し、それをテーブルに変換することができる。

ただし今では VBA プログラミングをせずに「機能」だけで上記を実現できる。 それが Power Query だ。

Power Query を使った重複行の削除

Power Query については以前にも一部の機能を紹介しているが、そこでも述べたように Power Query はサーバーやクラウドからデータを Excel に取り込むことだけを目的としたアドインではない。Excel のテーブルもデータ ソースとして指定が可能だ。

そして、Power Query のクエリ エディターの「列の削減」で「重複部分の削除」の機能があるのだ。
これを使うことで、「重複行の削除」と同様のことができる。


もちろん、Power Query で取り込んだデータは Excel のテーブルとなる。構造化参照可能なユニークデータの「テーブル」となる。これでピボットテーブルの重複行削除でできなかったことが可能になる。

Power Query が Excel をデータ ソースに変える

しかし、本当に重要なのは、重複行の削除ができることではない。

データを Excel のテーブルとして持ち、Power Query を使うことで、Excel をまるで「データベース」のように扱うことができる、ということが重要なのだ。これが Power Query をすべての Excel ユーザーに勧めたい理由である。 重複行の削除はほんの一例でしかない。

蓄積されたデータの中から必要なデータを抜き出し、それを加工したい、分析したい、集計したい、というニーズは Excel ユーザーにとっては「通常」のことだと思う。

そしてその作業を「繰り返して」はいないだろうか。更新されたデータ(ワークシート、テーブルといったデータの固まり)を対象に、同じ条件で抜き出す、加工する、レポートを作る、といったことだ。

手作業でデータを抜き出すのであればオートフィルターを使っているだろう。そこから絞り込んだデータを他のワークシートやブックにコピーしていないだろうか。

実践ワークシート協会の VBA セミナー スタンダードを受けた受講者であれば、それら一連の作業を VBA で行うことができるだろう。

Power Query を使うことで、Excel のテーブルをデータ ソースとして指定し、抽出するための複数条件をクエリ エディターを使って設定し、結果を Excel のテーブルとして出力する、それらすべての設定を「クエリ」として保存し、再利用が可能なのだ。

そして、Power Query は条件を設定し抽出するだけではない。カスタム列の追加も可能なのだ。ピボット テーブルの集計フィールド、Power Pivot の集計列と同じだ。データ型の変換までできる。

以下のアニメーション GIF では、Data2 列の数値を文字列変換し、ゼロパディングで 1 を 001 にして Data 列の文字列と結合させ、文字列の Data3 を数値に変換している。列の順番も変更可能だ。このようなデータの操作・加工も Power Query で可能で、ある意味、元のテーブルからまったく別のテーブルを作っているようなものだ。


Power Query のクエリ エディタの式で使える関数はワークシート関数でもなく、Power Pivot の DAX 関数でもない。しかし、マイクロソフトが公開している記事を参考にしながら Excel のワークシート関数の知識で試してみればその使い方はわかると思う。重要なのは全く別のものでなく、かぶっていることが多い、だから、Excel ユーザーであれば「わかる」だろう、想像してみよう、ということだ。

上記のアニメーション GIF でも、関数の Number.ToText の引数として、"000"を入れたのはワークシート関数の TEXT 関数の知識からだ。それで期待通りの動きになるのはさすがマイクロソフトと言わざるを得ないだろう。

少しでもこの情報が参考になれば幸いである。

Power Query を使って絞り込んだデータを取得する - 日付編

$
0
0
SharePoint リストなどからデータを取得し、Excel で加工、集計をする場合、おおよそ全件データを取得し Excel のテーブルにデータを展開してから、ピボットテーブルを使ったり、ワークシート関数を使うことが多いと思う。現在 Excel は百万行を超えるレコード(行)を扱うことができるため、実務上はほぼ問題ないが、場合によっては、絞り込んだデータのみを扱いたいときがある。

過去のデータは一切関係なく、たとえばセミナー申込みの管理などで今日(または指定日)以降に実施される予定コースの登録者アイテムのみが欲しい、といったケースだ。後工程でデータの加工、集計をするのだが、そこで絞り込みを行うのではなく、必要なデータ「だけ」がテーブルに存在していたほうが都合がよい場合だ。

SharePoint リスト接続は全件データをテーブルもしくはピボットキャッシュに取り込む。Office データ接続は上記に加えてデータ モデルに全件データを読み込んでから、Excel 側での処理が行われる。

OLE DB クエリ接続もしくはモデル OLE DB クエリ接続の Power Query の場合も、基本的には全件データを Power Query に取り込んでいる。しかし、Power Query の場合は、Power Query エディターを使って、データの絞り込みや、並べ替え、カスタム列の追加を行ってから Excel に渡すことができる。

(注) SharePoint リスト接続、Office データ接続、OLE DB クエリ接続、モデル OLE DB クエリ接続については、こちらの投稿を参考にしていただきたい。

Power Query のクエリ エディターの画面で絞り込みを行っているところ
絞り込んだデータをどうしても欲しい場合は、Office データ接続によるデータ取得ではなく、Power Query を使わざるを得ない。2015年1月の段階では、Power Query のモデル OLE DB クエリ接続は Excel Online でのデータ更新ができない制限があるが、この制限の実務上の問題がなければ、Power Query を使うことになる。

日付による絞り込み

絞り込みの条件はさまざまあるが、今回は上述のように「日付」に注目して、その絞り込み方法を紹介したい。
とはいえ、Excel ユーザーのとっては有難いことに、Excel のオートフィルターを使った絞り込みと同等の操作を行うことで実現が可能だ。

Power Query エディターの「日付/時刻フィルター」
Excel オートフィルターの「日付フィルター」
Power Query の場合、このオプションに加えて関数を使って指定することが可能なのが特徴だろう。特に「今日」より~ という指定が可能なことだ。

Excelのオートフィルターでも今日より後、といった「今日」という指定は可能だ。
しかし、この「今日」のボタンを押すと、「2015/1/25」といった今日の文字の値が入力される。Excel のオートフィルターという使い方では問題ないが、データ接続のデータ更新により SharePoint リストなどのデータ ソースからデータを抽出する場合は「今日」は「その日」でなければ困る場合が多い。
Power Query エディターの日付/時刻フィルターの「今日」や「明日」の扱いは、Excel のオートフィルターとは異なる。
「今日」を指定しても Excel のように日時を指定するのではなく、Data.IsInCurrentDay([実施日]) という関数を使って配列(複数件データ)を取得して、それをテーブルに展開するのだ。

Power Query エディターの日付/時刻フィルター オプションの「今日」
「今日」を指定したときの式
この指定であれば、データ更新をすると「その日」のデータを持ってくることができる。

関数を使った指定

上図のように、Power Query エディターで絞り込みなどをすると、その操作はすべて「式」として記録さている。

たとえば、「今日より以降(後)のデータ」を指定するときは、オプションのダイアログから「次の値より後...」で「今日」を入力することができない。
Power Query 行のフィルター選択
 ここで日を指定すると数式は以下のようになる。

今日よりも後を指定したいのであれば、赤い線の部分が「今日」になればよい。
ワークシート関数の Today() や Now() に相当するものが入ればよさそうなことは想像に難くない。
それが、DateTime.LocalNow() 関数だ。

実際に数式を直接書き換えてみた結果が以下だ。
ダイアログからは DateTime.LocalNow() 関数はバリデーションチェックによって入力ができないが、数式バー(のようなもの)では直接入力、修正が可能なのだ。

シリアル値ではない日付形式

Excel における日付や時間(時刻)の扱いは「シリアル値」を使っている。Excel ではないプラットフォームではシリアル値が使われていないため、日付・時間の扱いには注意が必要になることが多い。

Power Query では「DateTime」型が基本である。 DateTime 型は Date 型と Time 型から成り立っている。たとえば既出の DateTime.LocalNow() は DateTime 型を返す。

DateTime.LocalNow()  ->  2015/01/07 11:47:45

ここから日付だけを抜き出したい場合は、Date プロパティを参照する。

DateTime.Date(DateTime.LocalNow())  -> 2015/01/07

時間だけを抜き出したい場合は、Time プロパティを参照する。

DateTime.Time(DateTime.LocalNow())  -> 11:47:45

年や月や日を抜き出す場合、ちょっとしたテクニックが必要になる。
DateTime 型に含まれる Date 型からプロパティ参照する。そして、Year や Monty、Day プロパティを参照すると、その戻り値は「数値」になる。

Date.Year([申込日])  -> 2015
Date.Month([申込日])  -> 1
Date.Day([申込])  -> 7

ゼロパディングしたい場合、1月は 01、7日は 07 の場合はテキストに置き換える必要がある。戻り値は「数値」なので、以下のようにする。

Number.ToText(Date.Day([申込]), "00")  -> 07

もちろん、12 や24 の場合も問題ない。

ならば、DateTime から ToText を使えばよさそうだと思うだろう。
しかし、en-us, ja-jp などのカルチャが関係しそうな記述がヘルプにあるのだが、 フォーマットオプションについては期待する動きを見つけられていないので注意されたい。(現状、私は使用していない)

DateTime.ToText([日付], "yyyy")  -> 2015 (文字列)
DateTime.ToText([日付], "yy")  -> 15 (文字列)

DateTime.ToText([日付], "d")  -> 2015/01/07 (文字列)


最後にシリアル値であれば 1 をプラスすることで1日後となるが、DateTime の場合は、AddDays メソッドを使う。

Date.AddDays([申込日], 2)  ->  2015/1/9 (申込日が 2015/1/7の場合)
Date.AddDays([申込日], -30)  ->  2014/12/8 (申込日が 2015/1/7の場合)

Power Query で利用できる関数は以下のページにある。解説が親切ではないので、いろいろと試して確認するのがいいだろう。

Power Query fomula categories
https://weu-odcsup.office.com/en-SG/article/Power-Query-formula-categories-125024ec-873c-47b9-bdfd-b437f8716819

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

$
0
0
以前の投稿でも 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 ブックを前提としている。
いますぐは必要ないかもしれないが、データ モデルについては今後のキーとなるので引き続きウォッチが必要だろう。

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

$
0
0

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

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

$
0
0

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 のスキルのみで業務を遂行することが可能になったのは非常に大きな効果である。
上記がなんらかの参考になれば幸いである。

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

$
0
0

前回は入力されたデータが正しいか、正しくないかをピボットテーブルを使ってチェックする方法を紹介した。今回は「重複したデータのチェック」をピボットテーブルで行う方法を紹介したい。

重複行の削除

以前の投稿で重複行の削除を行ったユニークデータ リスト(テーブル)の作成方法を紹介した。

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 の機能を使うことで目的を短期間・低コストで達成できることは中小規模の企業や組織にとっては大きなアドバンテージになると思う。

この投稿がなんらかのヒントになれば幸いである。

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

$
0
0

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)

Viewing all 82 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>