BIツール「Amazon QuickSight」の紹介

実務でBIツール「Amazon QuickSight」の導入を支援する機会がありましたので、ツールの紹介をします。

【BIツールとは】

BIとは「ビジネスインテリジェンス」の略であり、事業上の意思決定のために、情報を収集・加工し、分析し、知見を得ることを指します。

ここで言う「情報」とは、売上や費用等の自社の利益に関するデータ、及びそれを左右する競合他社や経営環境に関するデータのことを指します。
データの形式としては、CSVファイルやリレーショナルデータベース等の表形式を思い浮かべるとわかりやすいでしょう。

上記のデータに対し、集計を行い、グラフや表や図の形式に加工することで、「どの地域でどの商品の売れ行きが良いのか」「自社の製品と競合他社の製品の価格差は自社の利益にどのような影響を及ぼすのか」「猛暑の年と冷夏の年で自社製品の売上がどの程度変わるのか」といった有益な知見を得ることができます。
その知見は、「どの分野に集中的に投資すれば良いのか」「自社の製品の価格はどのように決めれば良いのか」「毎年の生産量はどのように決めれば良いのか」といった、経営上の意思決定を行う上で役に立ちます。

BIツールは、上記の活動を支援するための各種ツールのことを指します。
身近な所で言うと、表形式のデータの取り扱いと関数を用いた集計、グラフの表示をサポートする「Microsoft Excel」はBIツールとみなすことができるでしょう。

【Amazon QuickSightとは】

「Amazon QuickSight」(以下「QuickSight」)はBIツールの一種です。
BIツールには様々な種類がありますが、QuickSightは、グラフや表や図を一画面で一覧できる「ダッシュボード」を作成するツールに分類されます。

QuickSightで作成できるダッシュボードは強力なものであり、例えば以下のような機能を備えています。

  • 表示のドリルダウンとドリルアップ(表示されるデータの粒度の細分化・集約化)
  • データのフィルタリング(プルダウンやチェックボックスを用いたデータの抽出)
  • マップビジュアル(地図の上にデータの大小を視覚的に表現する機能)

QuickSightはローコードで上記の機能を備えたダッシュボードを作成することができ、アプリケーション開発の専門的な知識が無くとも少ない工数でBIを実現できます。

【Amazon QuickSightで扱うデータ】

QuickSightはダッシュボード作成を支援するツールですので、その元となるデータは自分で用意する必要があります。

QuickSightは様々な形式のデータに対応しており、例えば以下のような形式のデータに対応しています。

  • CSV形式やTSV形式等のファイル
  • 各種リレーショナルデータベース(Amazon RDS、Oracle、SQL Server、MySQL、PostgreSQL等)
  • Amazon S3(オンラインストレージ)や、S3へのSQLでのクエリをサポートするAmazon Athena

QuickSightでは、SQLの集計関数で実現できる集計機能は一通りサポートしており、集計元のデータと集計後のデータを連動させた形で表示(例えば、各店舗のデータの一覧表と、一覧表上の全店舗の平均売上高を同時に表示)させることが多いので、用意するデータは集計する前のものとし、集計はQuickSight上で行うとスムーズに実装が進みます。
例えば、以下のようなデータを用意すると良いです。

チュートリアル_ 準備完了済みの Amazon QuickSight データセットを作成する – Amazon QuickSight
 web-and-social-analytics.csv.zip

【Amazon QuickSightのデモ】

QuickSightのデモが公式に公開されています。
このデモを操作することで、QuickSightがどのようなツールなのかイメージがつくと思います。

DemoCentral

【Amazon QuickSightのチュートリアル】

QuickSightのチュートリアルが公式に公開されています。

このチュートリアルをこなすことで、QuickSightを使用した簡単なダッシュボード作成を行えるようになります。
チュートリアルで基礎を学んだ後に、高度な機能を調べたり、QuickSightを実際に使用しながら学ぶことで、より難しいダッシュボードも作成できるようになります。

Amazon QuickSight – Visualization Basics (Japanese)


今回は、実務で導入を支援したツールの紹介をしてみました。
なお、実際に導入した際は、データベース上のデータが日々更新されるようにシステムを構築し、それをQuickSightから参照することで、ダッシュボードが自動的に更新されるようにしていました。

これからも、実務で学んだことを記事にして共有したいと思います!

Git系ホスティングサービスが広まる前に見られたソース管理手法

Git系ホスティングサービスやCI/CDツールが広まった現在のシステム開発の現場では、以下のようなソース管理が一般的です。

しかし、それが広まる前の昔のシステム開発の現場では、以下のようなソース管理が見られました。

この記事では、昔のソース管理の問題点を挙げていきます。


昔のソース管理によって発生する具体的な問題は、主に以下の二つです。
①商用環境に配置される実行ファイルがどのように作られたのか不明
②最新のソースコードが適切に管理されない可能性がある

以下では、それぞれの問題点について説明します。

①商用環境に配置される実行ファイルがどのように作られたのか不明

現在のソース管理では、Git系ホスティングサービスの中でビルドが行われます。
このビルドの作業は、Git系ホスティングサービスの管理者が実施する、もしくはCI/CDツールの設定に基づき実行されるため、開発者任せになることがなく、どのソースファイルがビルドされたのかも明確です。
しかし、昔のソース管理では、開発者がテストのために開発環境でビルドした実行ファイルがそのまま商用環境に持ち込まれることがしばしばありました。
そのため、ビルド作業が開発者任せになりますし、どのソースファイルがビルドされたのかも不明になります。
(開発者の環境を見に行って推測したり、開発者の申告を信じたりするしかありません)
昔のソース管理では、この問題により、意図しないソースファイルがビルド時に含まれてしまうことによるデグレードが起こりやすくなります。

②最新のソースコードが適切に管理されない可能性がある

現在のソース管理では、商用環境向けにビルドを行ったソースファイルをそのまま世代管理します。
そのため、商用環境向けのビルドに使用したソースファイルの紛失は起こりにくいです。
しかし、昔のソース管理では、リポジトリへのソースファイル格納と商用環境への実行ファイル配置が別作業になることがしばしばありました。
このような運用を行った場合、リポジトリへのソースファイル格納を忘れても本番運用には影響がない、という状態が起こり得ます。
このことにより、ソースファイルの世代管理の作業が漏れやすくなり、ソースファイル紛失の原因になります。
例えば、リポジトリへのソースファイル格納を忘れ、かつ開発環境のリプレースが発生した場合、リプレース前の開発環境にのみ存在していたソースファイルは失われてしまいます。


前回の記事に引き続き、過去の作業手順について触れた記事を書きました。

今回の記事で紹介した昔のソース管理とその問題点は、何れも私が実際に経験したものです。
現在では信じられない話かもしれませんが、私が経験した現場では、デグレードやソースファイル紛失が問題となることがあり、それを防ぐために重厚長大なルールが制定され、開発効率が落ちていました。

現在は、Git系ホスティングサービスやCI/CDツールにより、少ない労力でこういった問題の発生を未然に防げる運用を行えるようになりました。
良い時代になったと思います。

CDツールを使わない場合のデプロイ手順のイメージ

現在の開発現場・運用現場では、CD(Continuous Delivery)ツールを使用したデプロイ(サーバーへの資材配置)が一般的になっています。
CDツールの設定を行うのは一部の技術者のみであることもあり、CDツールを使用しない場合の原始的な手順でのデプロイ手順は、経験の浅い技術者にはイメージしにくいものであると感じています。

そこで、この記事では、CDツールを使用しない場合のデプロイ手順のイメージを書いていきます。
デプロイ手順を知ることで、CDツールを使う理由やそのありがたさを理解しやすくなると思います。


開発した機能を本番サービスに反映させるためには、開発環境で開発を行った資材(プログラムの実行モジュールやスクリプト、設定ファイル等)を商用環境に配置する必要があります。
配置を行うためには、最低限下記の作業が必要になります。
(コマンドのイメージも併記します)

1.商用環境のサーバーへのログイン

2.ファイル共有サーバーからの資材取得

3.資材(圧縮ファイル)の解凍

4.解凍後の資材の配置

上記の作業を行うだけでも、コマンドの誤り・漏れによる作業ミスの可能性がありますし、入るサーバーを間違えてしまうことすらあります。
作業を引き継ぐことにも困難さを伴い、作業手順書のようなものが必要になります。

加えて、下記のような作業を伴うことも多く、実際の手順はより複雑になります。

  • デプロイ時のサービス停止や機能制限、それに伴う設定変更(サーバー毎に設定が異なることも多い)
  • デプロイ前のバックアップ取得
  • デプロイ後の定型的な確認作業

作業ミスを防いだり引継ぎを容易にしたりする上で、CDツールの利用が有効になります。
CDツールでは、コマンドや設定を登録し、複数のサーバーに対して画面からGUIベースで作業することができるようになります。

イメージとしては以下のようなものになります。
(以下は、CircleCIのチュートリアルの一部です)

Hello World – CircleCI


今回の記事は、社内の勉強会で私の方から補足説明したことを記事に残したものとなります。
「CI/CD」という言葉の説明や、CI/CDツールの具体的な使用方法に関する記事は多く見つかりますが、ツールが使われるようになった経緯(過去の作業手順)に触れた記事は少ないと感じましたので執筆しました。

何かの参考になれば幸いです。

C#:ファイルのデータを置換する簡易ツールの作成

文字列置換はサクラエディタを使用すると楽ですが、サクラエディタを使用した場合は大量データの処理ができないという問題があります。

そこで、C#をプログラムにより置換を行うというのが有効になります。
プログラムでのファイルのストリーム読み込みであれば、高速に処理することができ、大量データにも対応することができます。
また、C#のコンパイラはWindowsOSに標準で搭載されているので、環境設定が不要なのも便利な点です。

サンプルコードは以下です。
サンプルコードでは文字列の”hoge”を”fuga”に変換しているだけですが、バイナリファイルとして読み書きしている上に変換する文字は16進コードで指定しているため、ASCII文字以外の置換にも対応可能です。
また、ロジックを書き変えれば、より複雑な条件での置換も可能になります。

また、この記事に限りませんが、ソースコードをコピペする場合は、「[」を「[」、「]」を「]」、「<」を「<」、「&」を「&」に変換するようにお願いします。

【フォルダ構成】

【ソースコード】

・execute.bat

・replace.cs

【入力ファイル】

・input.txt

【出力ファイル】

・output.txt


今回も小ネタの紹介でした。
C#のプログラムはサクラエディタのマクロよりも複雑なことができる上、Windiows OSであれば環境構築不要ですぐに使用でき、文法もJavaプログラマーであればとっつきやすいものです。
ちょっとした作業自動化で用いると便利だと思います。

C#:自ユーザーのダウンロードフォルダーのパスの取得方法

C#(正確に書くと.Net)では、以下のように、WindowsOSで定められる特殊なフォルダのパスがEnumで定義されています。
https://learn.microsoft.com/ja-jp/dotnet/api/system.environment.specialfolder?view=net-8.0&viewFallbackFrom=windowsdesktop-8.0

自ユーザーのダウンロードフォルダの直接のパスはEnumに登録されていないようです。
しかし、ユーザーのプロファイルフォルダ(C:\Users\(自ユーザー名))のパスは登録されていますので、そのパスを起点にダウンロードフォルダのパスを定義することができます。

試しに、ダウンロードフォルダ上のファイルのパスを定義し、そのファイルを読み込んで出力するサンプルコードを書きました。
具体的な使用例は以下のコードを参照してください。
(ソースコードをコピペする場合は、「[」を「[」、「]」を「]」に変換するようにお願いします。)

【サンプルコード】

・Program.cs

【用意するファイル】

・C:\Users\(自ユーザー名)\Downloads\test.txt

【実行結果】


今回はちょっとした小ネタの紹介でした。
ダウンロードしたファイルに対して加工を行うツールを作る際に便利だと思います。