「PoC」の進め方──メンバー選定、環境構築、データ収集と活用、評価まで：「ビッグデータプロジェクト」の進め方（2）（1/4 ページ）

本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくためのナレッジアーカイブです。今回は、導入前検証である「PoCの進め方」全8工程を解説します。

[嶋内翔，Cloudera株式会社]

連載バックナンバー

今回の主な内容

• はじめに
• 第2章-1：PoCのプロセス（1）　チームの編成
• 第2章-2：PoCのプロセス（2）　ゴールの設定
• 第2章-3：PoCのプロセス（3）　対象データの選定と検証
• 第2章-4：PoCのプロセス（4）　環境の構築
• 第2章-5：PoCのプロセス（5）　データの収集
• 第2章-6：PoCのプロセス（6）　データのETL処理
• 第2章-7：PoCのプロセス（7）　データの活用
• 第2章-8：PoCのプロセス（8）　評価
• 次回予告

　「ビッグデータプロジェクトを始めることになった」ら、何をすればいいのか──。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくための導入指南です。

　前回は、ビッグデータおよびビッグデータ基盤の概要について、そしてその第一歩として「小さくても、確実な成功を収めることが重要である」と説明しました。今回はこの第一歩を踏み出すに当たって必要となる、「PoC」（Proof of Concept：導入前実機検証）を、具体的にどう進めていくかを説明します。なお前回も触れましたが、本連載におけるビッグデータ基盤の説明には、業界標準であるオープンソースの分散処理基盤「Apache Hadoop（以下、Hadoop）」を用いることとします。

　PoCとは、新規システムの本番導入に先駆けて、小規模なシステムを試験的に導入し、ビジネスにおける有効性を調査／検証することです。「フィジビリティスタディー」などとも言われます。ビッグデータ基盤は大抵の場合、大規模なシステムとなってしまうため、導入のための投資の正当性を証明するためにもPoCの実施は不可欠です。しかし、ビッグデータ基盤の導入前に誤ったPoCを実施してしまうケースが多くあり、せっかくビッグデータ基盤を導入しても期待した成果を得られなかった、という失敗もよく聞かれます。

　PoCは、プロトタイプであると誤解されます。プロトタイプは「既にコンセプトの方向性が決まっている段階のもの」です。対してPoCは、「そのコンセプトそのものの検証を行う調査」です。意味は大きく違います。方向性が決まっていないということは、すなわちPoCの結果次第では、その後のプロジェクトの方向性を変更することもあり得るということです。

　しかし現実のプロジェクトにおいては、「PoCが成功する前提でプロジェクトの計画が進んでいる」ことが多いようです。これでは、方向修正が難しくなってしまいます。PoCはあくまでコンセプトの検証であり、軌道修正が行われるものであるということをステークホルダー全員が理解する必要があります。

　これを踏まえて、ビッグデータプロジェクトにおけるPoCの進め方を順に解説していきます。

PoCのプロセス（1）：チームの編成

　最初に、PoCを担当するチームを編成します。

　チームには、必ずビジネス側の責任者を参加させてください。ビッグデータ基盤は技術的に複雑なシステムなので、技術に明るいIT担当者や情報システム部門の社員だけでPoC担当チームを作ってしまいがちです。しかし、IT担当者だけでは「ビジネス課題を本当に解決できるか」を検証できず、ビジネス上、間違った結論を導いてしまうリスクが高くなります。最初から最後までビジネス側の担当者をチームに参加させましょう。

　続いてIT担当部署からは、インフラ担当者と開発担当者を別々に参加させるのがいいでしょう。PoCの段階では、インフラ／開発ともに必要最低限の機能を用意すればよいので、Hadoopについての高度な知識や経験はこの時点では必要ありません。基礎技術を修得した上でPoCに挑み、その中で必要な技術を修得をしていくのでもいいでしょう。

　インフラ担当者は、Hadoopクラスタの構築、起動／停止などの基本的な運用オペレーション、障害発生時の基本的な対処方法などのスキルが必要となります。本番環境にビッグデータ基盤を導入する段階では、リソース管理やセキュリティなどのスキルも要求されますが、こうしたスキルはPoCの段階では取りあえずなくても問題ありません。

　開発担当者は、データの収集、ETL（Extract／Transform／Load：抽出、変換、ロード）処理からデータの活用まで、幅広い開発項目をこなしていく必要があります。それぞれのプロセスにおいて必要なスキルが異なるので、まずはHadoopに関連するツールを一通り習得しているメンバーが適任でしょう。また、1人では手が回らない可能性があります。その場合はもう1人追加して、データの収集とETL処理の部分を別担当者に分担するとよいでしょう。

　PoCの内容によっては、さらに追加の人員が必要になる場合もあります。例えば、BIツールの活用を目的とするプロジェクトの場合は、BIツールの管理担当者や、実際にBIツールを活用する現場の担当者が必要になります。もっとも、この段階であまりに大きなチームにするべきではありませんが、役割分担を適切に行えるだけの要員は確保するようにします。

　実際の案件で作成されたPoCチームの一例を示します。

テーマ：「R＆Dの研究成果」を本番適用で実証実験するためのPoCチーム

構成メンバー例（A）

• チームリーダー：ビジネス・IT両面の責任者
  • 研究者出身のマネジャーで、ビジネス／技術の両面に明るい
• インフラ担当者：1〜2人
• アプリ担当者：1〜2人
  • R＆Dのチームから参加

構成メンバー例（B）

• チームリーダー: ビジネス・IT両面の責任者
  • マネジャーだが、ITの知識は豊富
• アプリ担当者：1人
  • R＆Dの研究成果の実装担当者
• アプリ・インフラ両方の担当：1人
  • Hadoopに非常に詳しい技術者
• インフラ担当者：1人
  • 若手を抜粋
• ユーザー部門の担当者：数人

　構成メンバー例（A）では、現場のユーザーはチームにこそ参加していませんが、チームと現場のユーザーが密にコミュニケーションを取っており、フィードバックをもらう体制にしていました。

　構成メンバー例（B）では、Hadoopに非常に詳しいエンジニアを主軸に、アプリ担当、インフラ担当にそれぞれ1人ずつ招集しました。そして、特定の部門にのみ先行適用する初期の目的から、そのユーザー部門の担当者とも連携して評価を行いました。

「今回の主な内容」に戻る