不安5「プロジェクトマネジメントの進め方は従来通りで大丈夫か」を解消する

ビッグデータ活用は「探索型」が中心、ウォーターフォール型が不向きなケースも

日経BPイノベーションICT研究所
上席研究員
田中 淳

この連載では、ビッグデータ活用に関わる「不安」をいかに取り除き、ビジネスの価値を最大化するかについて説明しています。取り上げているトピックは以下の通りです。

既に不安1から不安4までを取り上げました。簡単におさらいしましょう。第1回ではビッグデータへの取り組みはむしろこれからが本番、第2回ではOSS(オープンソース・ソフトウエア)の活用が有効、と説明しました。

ビッグデータ周りでいまホットなキーワードは、AI(人工知能)とIoT(Internet of Things、モノのインターネット)です。第3回ではAIやIoTを見据えた活用シナリオを考える必要がある点を取り上げました。第4回ではクライアント環境を例に取って、ビッグデータを活用する際に既存システムを生かせるとお話ししました。

今回のテーマはプロジェクトマネジメント、プロジェクトをどう運営するかです。ビッグデータ活用プロジェクトを進めるうえで、どのような点に留意すべきでしょうか。従来のやり方を変える必要があるのでしょうか。

結論としては、従来のプロジェクトの進め方を見直さざるを得ない可能性が高いと言えます。まず、ユーザー企業A社の例を紹介しましょう。

ビッグデータ活用システムを作るに当たり、既存システムとの関係をどう考えるべきか。これが今回のテーマです。

「日本のITベンダーに依頼するつもりはなかった」

連結売上高が約1000億円の製造業であるA社は、IoTの活用を狙ったプロジェクトを立ち上げました。同社がIoTを採用するのは今回が初めて。どの分野にどう適用すればいいのか、解は見えていません。

そこでA社は、パートナー企業と共にIoTの活用方法を探っていく方針を採りました。その際に「日本のITベンダーに依頼するつもりはなかった」と、A社の担当者は話します(図1)。理由として、今回のプロジェクトは日本のベンダーが得意とする「要件定義を積み重ねてシステムを開発するスタイルに適していない」点を挙げます。

170322_01.jpg

A社はパートナーを探す際に、「トライ・アンド・エラーを繰り返してシステムを開発する作業を、スピード感をもって実現できるかどうか」を重視しました。結果的に、同社が選んだのは米国のITベンダーです。

このエピソードは何を意味するのでしょうか。ビッグデータ活用では、「探索型」のプロジェクトが珍しくないということです。特に、AIやIoTといった最新の技術を取り入れてシステムを開発する場合が当てはまります。

システムを少し作って実際に試し、修正する作業を繰り返す

IoT導入のノウハウを持つベンダー担当者は、「IoTに関わるプロジェクトのほとんどは、システム開発に入る前に要件が決まっていない」と指摘します。こうした探索型のブロジェクトに、従来の進め方は必ずしも適していません。ここが大きな問題となります。

従来の進め方とは、いわゆるウォーターフォール型を指します。要件定義、基本設計、詳細設計、開発(実装)、テスト、運用といった、システム構築の工程を順を追って実施する手法で、日本では現在も主流です。日本のシステムインテグレータの多くは、ウォーターフォール型によるシステム開発を得意にしています。

「システムで何を実現したいか」が当初から明確であれば、ウォーターフォール型の開発で大きな問題はありません。しかし探索型プロジェクトでは、単純にユーザーにヒアリングを重ねていけば要件が見えてくるわけではありません。ユーザーと共に要件を作り上げていく姿勢が大切になります。

ウォーターフォール型の開発のように、あらかじめ計画をしっかりと作ることを目指すのではなく、システムを少し作って実際に試し、その結果を見て修正や追加をして試す、という作業を繰り返す。この作業を通じて、ユーザーとパートナーが「何を実現したいか」を探っていく。こうしたアプローチのほうが適しています。

探索型に向くアジャイル開発

探索型のプロジェクトにより適するのは、反復型のシステム開発手法です。その代表格はアジャイル開発(アジャイル・ソフトウエア開発)手法でしょう。ユーザーにとって価値のあるソフトウエアを素早く作るのが狙いで、スクラム(Scrum)やエクストリームプログラミング(XP:eXtreme Programming)などが有名です。

アジャイル開発は、要件定義から設計、実装、テストまでの作業を短いサイクルで繰り返し、このサイクルの中で動作可能なソフトウエアを開発します。一つのサイクルは2~3週間程度で、1週間の場合もあります。

一つのサイクルを2週間で回すのであれば、2週間後に動くソフトウエアが出来上がります。このサイクルを繰り返して、目標とする機能を備えるソフトウエアを段階的に(成長させていく要領で)実現していきます。短い周期で繰り返すので、軌道修正にも容易に対応できます。

欧米をはじめとする海外では、既にアジャイル開発は一般的な存在になっています。米バージョンワン(VersionOne)が2015年に実施した調査では「所属する企業・組織でアジャイル開発を利用している」との回答は95%に上っています。その中で57%は3年以上の経験を持つと答えています。

バージョンワンはアジャイル開発を支援するブロジェクトマネジメント・ツールを販売しており、調査の値は高めに出ている可能性はありますが(回答者3880人のうち、同社の顧客は28%にすぎないとしています)、欧米でアジャイル開発が広まっているというのはほぼ共通の認識と言えるでしょう。

日本はどうでしょうか。プロジェクトマネジメントの普及団体であるPMI日本支部の調査「2016年度 アジャイルプロジェクトマネジメント意識調査報告」では、「自部門でアジャイル開発を導入している」と回答したのは37%。前年度(2015年度)の31%より伸びていますが、95%には遠く及びません。回答者(185人)の大半はPMI日本支部会員なので、企業全体では数字がより下がる可能性もあります。

探索型プロジェクトでは、アジャイル開発のほうがウォーターフォール型よりも適しているとみなせます。「アジャイルの壁」を乗り越えて、実プロジェクトに適用できるか。これがビッグデータ活用プロジェクトの運営を成功に導く鍵の一つとなります。

ただ、今後は日本でも状況が変わるかもしれません。調査会社のガートナージャパンは、「2019年までに、日本の大企業におけるIT部門の60%が、バイモーダル型アプリケーション開発に取り組むようになる」と予想しています。バイモーダル型開発とは、ウォーターフォール型と、アジャイル開発をはじめとする非ウォーターフォール型を使い分けるアプローチを指します。

ツールを活用してプロジェクトを「見える化」

ビッグデータ活用のプロジェクト運営を考えるうえで、もう一つ大切な要素は「見える化」です。探索型プロジェクトは方向を修正しつつ進める必要があるので、プロジェクトの状況を見える化して、進捗をきめ細かく把握することが欠かせないからです。複数のサブプロジェクトが同時に進むケースもよくあるので、複数プロジェクトをまとめて見える化できるのが理想です。

先ほど紹介したバージョンワンの調査は、興味深い結果を示しています。アジャイル開発で利用しているマネジメントツールを尋ねたところ、1位はマイクロソフトの表計算ソフト「Excel」で回答者の60%が挙げました(複数回答)。アジャイル開発でも、Excelを使うケースが多いのが実情ということです。

Excelは優れたツールですが、プロジェクトの見える化に使おうとすると、手間がかかったり、十分な精度が得られなかったりするおそれがあります。そこで、代わりにプロジェクトマネジメント・ツールを採用するという選択肢が考えられます。オープンストリームが販売する「EPM Base」を例に取りましょう。

EPM Baseはプロジェクトマネジメントに必要なデータを収集し、グラフなどでブロジェクトの状況を見える化するツールです。最近のプロジェクトでは、チケットという単位でプロジェクトで行うタスクを管理するオープンソースソフトウエア「Redmine」がよく使われます。EPM BaseはRedmineやソースコード管理ソフトウエアの「Subversion」などから情報を収集し、ダッシュボードで状況をビジュアルに表示します(図2)。

170322_02.jpg

ダッシュボードを見ると、プロジェクトの進捗や工数、障害、課題などの状況を一目で把握できます。オープンストリーム プロダクト事業部製品開発部製品グループでテクニカルエンジニアを務める大和田裕氏は、「Excelでグラフを一つひとつ作っていくのは時間がかかる。データを活用するためには、分析のノウハウも必要だ。EPM Baseを使うと、データ収集・分析の手間を削減できる」と話します。

データを一元管理するので複数プロジェクトを管理できる点も、EPM Baseのメリットです(図3、図4)。

170322_03.jpg

170322_04.jpg

「Excelを使う場合、各プロジェクトのリーダーにファイルを送ってもらい、集計する必要がある。その手間も馬鹿にならない」(大和田氏)。ツールを使うと、この作業を効率化できるというメリットが得られます。

今回のまとめです。ビッグデータ活用プロジェクトは「探索型」になるケースが少なくありません。その場合、従来のプロジェクトマネジメントの進め方が適切ではなくなる可能性があります。

開発手法としてウォーターフォール型の代わりにアジャイル開発を、Excelの代わりにプロジェクトマネジメント・ツールをそれぞれ採用することを検討してみるのが効果的です。こうした手法やツールを利用した経験が豊富なパートナー企業の協力を仰ぐのも有用でしょう。

次回は本連載の最終回です。ビッグデータ活用を担う人材育成に焦点を当てます。

こちらの記事を読まれたお客様は以下の記事も読まれています

  • 2017/03/22

    定量的プロジェクト管理ツール 「EPM Base Ver. 2.0」

  • ねこもに

    2017/03/20

    NHKニュース「おはよう日本」で紹介!

  • 2016/08/04

    「EPM Base Ver.2.0」メジャーバージョンアップ

次回の記事掲載をメールでお知らせ!

お申込いただいた方には次回からの記事掲載をメールでお知らせします。お気軽にお申し込みください。

OPEN STREAM TIMESについてのお問い合わせ

お電話でのお問い合わせ

03-4589-8800