今回は、Pentaho 社が提唱するアジャイル BI というプロジェクト手法について、紹介します。

従来型の開発手法

今までの BI プロジェクトの手法としては、数か月かけてユーザーと話をしながら要件を固め、固めた要件に基づき設計し、開発、本番リリースするという形でした。

基本的に、要件定義で固めた要件は、設計・開発のフェーズでは変更しません。

また、ユーザーは設計・開発の途中段階では、成果物（レポート）を確認することはなく、本番リリースの際に、初めてできあがったものに触れることになります。

個々の BI レポートに対して、業務上の使用目的（何のために使うか）や対象ユーザー、業務フロー（レポートを確認してどのようなアクションを採るのか）やレポートに表示する KPI、表示する形のイメージが、明確に存在するユーザーにとっては、上記の開発手法は、非常に効率的で理にかなった方法であると言えます。

一方で、上記のようなイメージがぼんやりとは存在しているが明確になっていないので、プロジェクト内で一緒に明確化していってほしいといったユーザーや、そもそもぼんやりとしたイメージもないので、ゼロから作り上げていってほしいといったユーザーには、最初の数か月で要件を固め、その後変更はせず、完成イメージを見るのは本番リリースの際という上記手法は、非常にリスキーなものになっていました。

アジャイル BI

Pentaho 社が提唱するアジャイル BI という手法は、要件定義をしている最中のぼんやりした要件の状態でプロトタイプを作成し、完成イメージをユーザーと共有して、ユーザーと共にそのプロトタイプを作り上げていき完成をさせていく手法です。

基本的に、どのタイミングでも要件の変更を受け付け、プロトタイプを繰り返し修正していくことで、求めている形に近づけていきます。

この手法では、もともと BI システムを使った業務のイメージがぼんやりしているユーザーや、そもそも業務のイメージがなかったユーザーでも、いつでも何度でも要件を変更し、修正していけるので、「想像していたものと違う」となるリスクが軽減できます。

しかしながら、この手法では初期の段階でプロトタイプという形あるものを作りあげてしまうため、『どのように変更したらデザインが美しくなるか』や『こう変更した方が見やすい』といった見た目やデザインにフォーカスしてしまい、本来の『何のために使うのか』といった使用目的や『何を見て、どのような判断をし、どのようなアクションを取るのか』といった業務要件という一番重要なファクターへのフォーカスが薄れる傾向があります。

Pentaho 社は、以下の理由で、自社のツール（Pentaho）がアジャイル BI に適したツールだと語っています。

• BI を行う上で必要な機能（ETL、レポーティング、BI プラットフォーム等）を全て 1 つのプラットフォームに備えている
• ユーザー数に制限がない

BI 導入における注意点

上記で挙げたいずれの手法においても、BI 導入プロジェクトでは、BI 導入企業における各組織のミッションや役割、各職位階層のミッションや役割、指示命令系統などの組織マネジメントを明確化し、どのような組織のどのような立場の人が、どんな情報を見て、どのように判断し、どんなアクションを採ることを期待するのかを明確に定義した上で、個々のレポートの形を決めていくことが重要であると思います。
また、それらのことが明確になれば、プロジェクトも自ずと期待した方向に進んでいくのではないかと考えています。

以上、今回は Pentaho 社が提唱するアジャイル BI という開発手法を通して、Pentaho を紹介しました。

Pentaho の詳しい情報は、株式会社 KSK アナリティクスの製品ページをご覧ください。
http://www.pentaho-partner.jp/

 

※ Pentaho は、Pentaho Corporationの登録商標です。
※ Microsoft、MS、Windows、Windows Server、Excel、AccessおよびPowerPointは、米国 Microsoft Corporationの米国およびその他の国における登録商標です。
※ Windows の正式名称は、Microsoft Windows Operating System です。
※ その他の会社名、製品名は各社の登録商標または商標です。
※ 記事の内容は記事公開時点での情報です。閲覧頂いた時点では異なる可能性がございます。