年末にウクライナ国立バレエを見て、最近とみにバレエに興味があります。 なので、まずはバレエ漫画を色々と調べて、読んでみようかなとリスト化してみました。
ジョージ朝倉
山岸 凉子
槇村 さとる
星合 操
- ユニコーンの恋人 合冊版1 (少女宣言)
- ユニコーンの恋人 (1) (宙コミック文庫)
- ユニコーンの恋人 (2) (宙コミック文庫)
- ユニコーンの恋人 (3) (宙コミック文庫)
- ユニコーンの恋人 (4) (宙コミック文庫)
- ユニコーンの恋人 (5) (宙コミック文庫)
年末にウクライナ国立バレエを見て、最近とみにバレエに興味があります。 なので、まずはバレエ漫画を色々と調べて、読んでみようかなとリスト化してみました。
ITコンサルタントの仕事をするうえで、改めてデータをどう取り扱っていくのか、下記の記事に触発されて書いてみました。
なかなか、ざっくりとした内容なのでこういう視点で考えている、という目安ぐらいにしてもらえるとありがたいです。
週末の日曜日。たまにはのんびり過ごしたいと思って部屋に閉じこもっていると、妻がガラッとふすまを開けて入ってきた。何事かと思ったら、何度も呼んでいるのに反応がないと怒っていた。集中したいのは分かるけれど、ただでさえよく聞こえないのに、ふすまを閉めて、窓は開けて外の音が騒がしくて、どうやって反応するのと。確かにそうだなと、集中したいというのもそうだったけど、ふすまを開けて、また部屋で過ごしていた。
しばらくすると、また妻から声がかかり、確かにふすまを開けていれば聞こえるなと思い、妻の部屋へと移動した。ひとしきり雑談をして、日本の現状を憂い、さて部屋に戻ってまた集中しますか、と思っていたら、妻が部屋にやってきた。さて、今度は何かなと思ったら、今、そういう気分になった。今からバドミントンをしないか、との提案。運動が嫌いな妻が運動に誘うタイミングは確かに貴重だから、そう思って素早く準備をした。
妻はさて何を準備したらいいだろうと尋ねてきて、確かに運動に後ろ向きな姿勢だと、何を準備すればいいのかも自分で決めきれないのだなあと納得した。一番大事なのは水分補給のための飲み物。それと汗をかくと思うからタオル。自分は足を痛めるといけないから靴を履くので、靴下を用意する、と伝えた。私はサンダルでやるから、といってそそくさと準備をしていたが、玄関に来るときには靴下をちゃんと履いていた。
外は暑くもなく、ちょうどいい空気でバドミントンをやるには最適だよね、といつも以上に饒舌な妻。たぶん、運動が嫌いだからこそ、いっぱい喋って気分を盛り上げているのか、もしくはごまかしているのか。自分はさっさと公園に行こうと、妻を尻目にさくさく歩き、家の向かいの公園に入る。公園には子どもたちや親子連れ。レジャーシートをひいたうえで上で団らんをする若者。そこそこにぎわっていた。ラケットを取り、シャトルを出すと、妻はこのシャトルはプラスチックではなく、鳥の羽を使っている良いものだとしきりに伝える。しゃべってないで、早くバドミントンを始めようとせかしたい気分になった。
公園はそこそこ広いので、他の人たちに干渉しない場所を見つけて、妻と向かい合う。シャトルを叩き、妻の上や横、時には足元に打ち、互いに少しづつラリーができる。二人とも、特にうまいほうでもなく、自分が若干身長と手の長さで有利に進めているような気になる。5分ぐらいやって、疲れる前に休憩を取る。飲み物を飲み、汗を拭く。妻に疲れていないかと声をかけると、全然大丈夫とのことで安心する。それだったら毎朝仕事前にできるのでは、といったがそれは無理だと妻。
AppleWatchで運動の時間を測り、ゲーム再開。風が少し吹くだけで、シャトルは勢いをなくしたり、逆に勢いがついて驚く。休憩の後のほうが少し、体が重く感じたりするので、時折足を延ばしたり、足首を回したりしてごまかす。途中、飛んできたシャトルが自分の足元にきて、思わず踏んずけてしまった。慌てて元の形に戻して、ドキドキしながらやってみると、踏んだせいなのか、疲れているせいなのか、どちらとも分からず、とりあえず真っすぐは飛ばない。妻は途中でラケットの曲がりぐわいが気になり、やはり2本セットで千円のものより、1本千円のほうが良いものであると話していた。
何回か休憩をはさんで、日も少しづつ暮れたころ、そろそろ終わろうかと言って、自分が最後に1セットと言ってラリーをして終える。たくさんの汗をかき、一生分の運動したという妻と家に帰った。良い運動したととても満足気で、自分もとてもうれしい。
この前、知人とTableauやPowerBIといったBIツールの話をしたのが最初。 そこでふと今のBIってどうなんだろうと考えました。
BIツールを使うと、データを取り込んで自分で分析することができます。 例えば、社員ごとの売り上げの一覧のデータがあれば、一覧をそのまま見ることも、合計や平均を計算したり集計ができます。 ツールの操作が、マウスや簡単なキーボード操作で出来るのも、メリットです。
業務でより高度な分析が必要になると、データを組み合わせが必要になります。 例えば、社員ごとの売上の内訳、どの商品が売れたのか。またその商品の原価はそれぞれいくらか。 社員が営業のそれぞれどの組織に所属しているか。組織ごとに特徴があるか。 組み合わせるデータがまるでレゴのブロックのように、パーツが増えるとできることが増えます。 そうやって組み合わせを、分析したい人自身が行うことがセルフBIです。 組み合わせができるデータがあれば、誰もがデータができます。
そんなセルフBIですが、問題も抱えています。 問題が起きるのは、業務の規模が大きくなる時。 業務ごとにデータの種類が増えたり、時間とともにデータの量が増えたり。 そのためには、どう組み合わせるのが良いのか、高いレベルが求められます。 いわば、BIツールを使う人みんなが、データを組み合わせるプロである。 そんなプロを目指していくのはとても大変です。
また、個人がレポートを一人で作りこむことの問題もあります。 BIツールの中でどのような組み合わせをしたのか、作った人の暗黙知になりがちです。 もちろん作ったレポートの中身を見て確認もできますが、その作業も大変です。 セルフBIができるデータの民主化は、その人自身で終わりがちです。
そのため、データの組み合わせをレポートを作るユーザではなく、データを提供する基盤で行う。 そのような流れがあります。 個人で管理をするより、共通の管理をした方がいいのは間違いないですね。
昔は確かにシステム側でデータを取りまとめて、ユーザは貰ったデータでレポートを作る。 だからユーザのデータ分析のできる範囲が限られていました。 では、そこに戻るだけなのか、たぶんそうではないはずです。 セルフBIの先でユーザは何をするのか、考える必要があるのでは。 そんな話がきっかけでした。
セルフBIの先で必要なものは何か。 ユーザの視点で考えていきました。
ユーザにとってデータ活用の目的は何か。 簡単にいうと、業務の課題を解決するためです。 業務の課題をどう解決するか、分析とは何か。 それを考えていくとよさそうです。
分析をするためにBIツールを使うとしたら、今まではどうだったのか。 BIツールが生まれる以前から仕事の中でデータを活用しているはず。 そう思って、BI以前のデータ活用を振り返ってみました。
まだPCも無かった時代。 紙の書類で手書きをするか、ワープロで印刷した紙を使っていた時。 そろばんを使う人もいたかと思いますが、電卓を使っているイメージ。 職場がWindows95のPCが発売されるまでは本当にそんな環境でした。 ただ、そんな中でも紙には項目を一覧で書くこともできました。 電卓で四則演算を駆使して、合計や平均も出してデータを使っていました。
それからPCが職場に普及してくると、MicrosoftのExcelのような表計算ソフトが使われます。 縦と横に項目があり、数値の組み合わせがとても柔軟になってきます。 そしてPCを使う最大のメリットとして、ファイルで保存をして再利用もできるようになります。 業務事態もPCを使うようになると、業務システムが導入されます。 データの分析は業務システムからデータをファイルでもらうこともできるように。 もらったファイルはExcelに取り込んで使うことができます。
ファイルでデータをもらうっていたものが、データ活用をするための分析システムに変わります。 分析のデータをとりまとめるためのシステムが整備されていきました。 Excelを使っていたユーザは、直接分析システムのデータを使うことが便利になりました。 そのツールこそがBIツールになります。 またデータのファイルも、メールや様々なメッセージアプリでのやり取りができるように。
ここまでBI以前を振り返ってどんな仕事の環境だったのか。 イメージしていくと、なんとなく整理できた気がします。 では、次の世代のイメージはどうなのか。 今キャッチアップした最近のトレンドから探ってみます。
LookerはセルフBIの次の形だと言われています。 具体的にはデータマートを抽象化して管理しやすくしたものです。 DatabricksはデータレイクとDWHのいいとこどり。 データのストレージを抽象化したデータレイクと、DBの構造をクエリエンジンで扱いやすくしたもの。 dbtはSQLでのデータ管理を抽象的かつ構造的にしたもの。 それぞれはツールやプラットフォームですが、データを抽象的、メタとして扱いたい感じです。
VscodeはテキストエディタをベースにしたIDE環境。 プログラミング言語での開発に役立つ機能拡張やGit、Markdown、CSV、ターミナルさえも使えます。 コマンドパレットと呼ばれるコマンドを呼び出しての操作も可能。 Windosターミナルは、コマンドプロンプトやPowerShellだけでなく、WSLなどのLinuxも使えるます。 このタイミングでテキストで処理をさせるためのターミナルソフトをMicrosoft純正で提供。 wingetも純正のコマンドベースのインストーラーです。 これらの一式はWindowsがGUIでの操作だけではなく、テキストによる操作を一方で推奨しているのです。
データをどう取り扱うのがよいか。 DMBOKでも記載がありますが、それがデータガバナンスとデータマネジメントです。 これらはデータを使うユーザこそデータがちゃんとしていないことの影響を受けると説いています。 そのため、データを主体的にユーザが管理することが重要です。
それらを踏まえると、まずテキストベースでのデータの取り扱いが考えられます。 例えばSQLのようにコードを書いて、コードベースでデータを取り扱うこと。 PythonやRのようにプロットやグラフもコードで表現するのもイメージできそうですね。 また、紙からファイル、メールといった流れから、クラウドでの仕事と言ってよさそうです。 クラウドを使うというのは、URLをシェアしたり、APIで連携したりといったイメージになります。
ここまで世代を振り返り、次世代をイメージしてきました。 その世代ごとに何が変化したのか、データとの向き合い方が進化したのでは。 そういった視点で考えていきます。
データとの向き合い方を考えるうえで、参考までにデータのイメージがあるといいかもしれません。 例えば、ある事業の課題の解決のデータ活用です。 その業務の「目標を定めて」「所定の期間で」「現状から実績を積み上げます」。 目標値、期間、実績値。 他にも、費用や担当者といったデータがありそうですね。
電卓を使うことで、計算を駆使することができるようになりました。 平均、割合、比率。 どれぐらいのペースで実績を出しているのか。 費用が効果的か。 統計的な考え方ができるようになったといってもいいでしょう。
表計算を使うことで、データは値からリストに、リストから表になっていきます。 すると、クロス集計やピポットといった表計算でお馴染みの比較ができます。 グループ分け、フィルター抽出、結合などもあります。
BIツールを使うことで、グラフや図によるデータの可視化。 操作がさらに直感的にできるようになったインタラクティブ性。 さらにデータの自動更新が可能になり、レポーティングとしての機能も重視されます。 大局的に特徴を捉えること、試行錯誤を伴うPDCAを回していくことが可能になっていきます。
では、コードを使うことがデータ活用になった場合。 コードで実現できることは、型、条件、範囲、命名、分岐といった定義になります。 定義を行うことでデータ活用に必要な要素を定める。 それが一番重要になります。 要素が定まれば、あとはその範囲の中で変化する値としてパラメータを調整します。
データの向き合い方が進化からセルフBIの次を考えました。 もう一つの視点として、データ活用をその結果をどのようにアウトプットするのか。 アウトプットの進化から考えていきます。
紙の一番の役割は記録ができることです。 計算した結果、収集したデータ。 それをすべて紙に記録することで結果を別のところにアウトプットすることができます。 まず結果を残そうというのは今でももちろん重要です。
PCでファイルを取り扱えるというのは、デジタルであるということです。 デジタルとしての特徴。同一性が担保していること、再利用ができることです。 アウトプットとして、データの品質にかかわる重要なところです。
メールやメッセージアプリの役割は、アウトプットの相手とやり取りがしやすくなったということです。 アウトプットを別の利用者に展開できることで、価値がさらに高まっていきます。
クラウドでのアウトプットとは、同時に複数の利用者と利用できること。 人だけではなく、APIがつながるあらゆるシステムとその先の利用者をつなぎます。 アウトプットの利用の広がりを最大化していく、そのような進化になっていくでしょう。
BIによるデータの分析は、次の世代ではコードによるデータの定義が重要になると予想します。 それは業務のこれまでの変化と、さらにデータの取り扱い方の進化を踏まえたものです。 ついでにクラウドといった環境により、アウトプットが進化し、よりスケールしていきます。 それは、セルフBIの先により主体性を持ってデータ活用をする利用者であるということにつきます。
PowerShellでsqlファイルをimport
$testCaseFilePath = "./unique.sql" $testCaseFile = (Get-Content $testCaseFilePath) -as [string[]] $targetModelFilePath = "./target_model.sql" $targetModelFile = (Get-Content $targetModelFilePath) -as [string[]] $targetColumnFilePath = "target_column.sql" $targetColumnFile = (Get-Content $targetColumnFilePath) -as [string[]] $outputFile = $testCaseFile.replace('%%target_model%%',$targetModelFile).replace('%%target_column%%',$targetColumnFile) Write-Output $outputFile > ./output.sql
unique.sql
WITH target_model AS( %%target_model%% ) SELECT CASE WHEN COUNT(%%target_column%%) = COUNT(DISTINCT %%target_column%%) THEN True ELSE False END AS result FROM target_model
target_model.sql
/* メンバーの一覧 */ SELECT id ,member_name ,team_id FROM sample_scores.members
target_column.sql
id