筆者は,SIerの立場で様々なITシステム開発プロジェクトに参加しています。常に思い知らされるのは「ITシステム開発は難しい」という事実です。特に要求開発・要件定義といったコンセプトを決める工程では,以前に成功したプロジェクトで採用していた方法を使用しても,同じように成功するとは限りません。

 「どうやったらプロジェクトを成功させることができるのか」──これは筆者に限らずITシステム開発にかかわるすべての人の悩みではないでしょうか。

書籍『要求開発』には書かれていない秘訣がある

 要求開発アライアンスでは,同じような悩みを持つ人々が,ユーザー企業やシステムベンダーの垣根を越えて集まり,月例勉強会や合宿を開催してシステム開発についての悩みを議論しています。「要求はあるものではなく,開発するものである」──このコンセプトに共感する参加者の発表や意見には,刺激的なものが少なくありません。

 要求開発アライアンスの議論の成果は,2006年に『要求開発 価値ある要求を導き出すプロセスとモデリング』(日経BP社 発行)という形で書籍にまとめられました。この書籍には,要求開発を実践するためのプロセス(進め方)とテクニック・手法が詳細に記述されています。本書を参考にすれば,誰でもが要求開発を実現することができるようになったのです。

 しかし,冒頭に述べたように,要求開発・要件定義といったコンセプトを決める工程では,決められた方法や手順を実施するだけで同じように成功するとは限りません。要求開発も,書籍に書かれた通りに実施したからといって,必ず成功するというわけではないのです。

 実は,書籍には書かれていない秘訣が存在しています。今回は,要求開発アライアンスの会員にしか知られていない,プロジェクト成功のための秘訣をご紹介します。この秘訣は要求開発アライアンスの中では「コタツモデル」と呼ばれています。

「コタツモデル」とは

 「コタツモデル」は,ITシステム開発プロジェクトにおける,主要な三つのステークホルダーの関係性を表すメタファーです。ビジネス戦略を決定するビジネスオーナー(経営者や高位の責任者),実際のビジネスを遂行しているユーザー(現場担当者),そしてシステム開発担当者の三者によってシステムの目標を決定する=一つのコタツに入って議論する状況を,「コタツモデル」と呼んでいます。

 なお,一般的なシステム開発ではビジネスオーナーが参画することは少ないため,この点については違和感があるかもしれません。これは,要求開発の狙いが「ビジネス上の目的と整合性のとれた,価値あるシステム要求の導出」にあることによるものです。

 「コタツモデル」では,単にビジネスオーナー,ユーザー,システム開発担当者が会議をすれば良いということを示しているのではありません。三者がこれから構築しようとするITシステムについてのイメージを明確にし,合意形成をする必要があります。要求開発アライアンスでは,この合意形成のためのツールとしてビジネスモデリングを採用していますが,他の手法を適用しても問題はありません。

図1●「コタツモデル」のイメージ
図1●「コタツモデル」のイメージ

なぜ「コタツモデル」が必要なのか

 先ほど触れましたが,要求開発アライアンスでは「ビジネス上の目的と整合性のとれた,価値あるシステム」の構築を目指しています。逆に言えば,世の中にはビジネス目的と整合性の取れないシステムが多いと感じているのです。そこで,まず要求開発で避けたい三つの失敗パターンについて説明し,それぞれの失敗原因を「コタツモデル」で分析します。

◆失敗パターン1:あるべき姿を追い求めた結果,使われないシステムに!

 他社の事例などを見て,経営者が思い立ちます。「ウチの△△業務はIT化しなければならない!」。この経営者は叩き上げで,各業務についてもある程度精通しています。そこで,システム部門の担当者や情報ベンダーを呼び,ホワイトボードに新しい業務像を書き上げ,システム開発のスタートを宣言するのです。

 しかし,完成したシステムは先進的ではありますが,現在の業務とは大きくギャップがありました。トップからの指示により,現場担当者はなんとかシステムを利用しようとしますが,システムだけでは業務が回らないため,結局システムの多くの機能は使われなくなってしまいました。

◆失敗パターン2:現場の声を収集した結果,スケジュールが大幅遅延!

 業務効率化のために構築することが決まった△△業務システム。さっそく現在業務を担当している現場担当者を呼び,システム開発担当者からのヒアリングがスタートします。様々な問題意識を持っていた現場担当者は,様々な業務上の課題や効率化のアイデアを提示します。

 しかし,しばらく経ってみると,できあがったのは膨大なバリエーションに対応した,非常に巨大なシステムの設計書でした。すべてを実現するには,当初想定していたシステムの利用開始日を大きくずらす必要が出てきました。加えて,当初の目的だった「業務効率化」も,細々とした現場担当者の作業軽減にとどまってしまいそうです。

◆失敗パターン3:最新技術の特性を無視した設計の結果,品質に問題が!

 新規ビジネスのためのシステム構築。しっかりとした設計を,業務担当役員を筆頭に現場の業務担当者が詰め,細かい仕様まで決定しました。設計書をシステム開発担当者に渡し,さっそく開発に着手することになりました。

 しかし,設計書を見てみると,最近主流の技術で実現するには非常に困難な要求ばかりが記載されています。「最近主流の方法で実現するのであれば,もっと低コスト・短期間で実現できるのに」。開発担当者はボヤきながら開発を進めることになります。結果として,かなりムリな開発を実施したため,カットオーバー当初は品質が悪く,様々なトラブルが発生することになりました。

 ……いかがでしょうか。どのパターンもITシステム開発の現場では聞いたことがある,ありそうなパターンです。筆者も書いていて胸が痛くなりました。この三つの失敗パターンはそれぞれ,要求開発/要件定義の工程で「現場担当者が不在」「ビジネスオーナーが不在」「システム開発担当者が不在」であることが,失敗の原因となっています。それぞれの失敗原因と防止方法は,次の通りです。

表1●三つの失敗パターンの原因と防止方法

失敗のパターン失敗原因どうあるべきか
失敗パターン1:あるべき姿を追い求めた結果,使われないシステムに現場担当者の視点が抜けていた。業務の現状を無視してシステム開発に着手した現場担当者も参加し,あるべき業務像を検証。実行可能なものにすべきだった
失敗パターン2:現場の声を収集した結果,スケジュールが大幅遅延ビジネスオーナーの視点が抜けていた。トップダウンの視点でシステム化方針を定め,取捨選択すべきビジネスオーナーが参加し,現状業務を確認。不要な業務や,スリム化すべき手順を示すべきだった
失敗パターン3:最新技術の特性を無視した設計の結果,品質に問題が開発担当者の視点が抜けていた。現代のITの特性の考慮観点が無かった開発担当者が参加し,利用容易なIT技術の活用を提言すべきだった

 これらの事例は極端すぎるかもしれません。しかし,程度の大小の違いはあれども,「ビジネスオーナー」「ユーザー」「開発担当者」の視点のバランスが崩れば,そのシステムは歪なものになってしまいます。

 ビジネス目標と整合する,実行性のある要求=「ただしい」要求を導くためには「ビジネスオーナー」「ユーザー」「開発担当者」の三者が適切なバランスで要求を検討し,合意していくことが重要です。世の中には様々なシステム開発方法論や,専用ツールがありますが,まずその前に,「コタツモデル」な関係が形成できているかどうかが,ITシステム開発プロジェクトの成否を定めるポイントではないでしょうか。

 今回は「コタツモデル」の概要説明でずいぶんと長くなってしまいました。次回は,実際に「コタツモデル」を形成する方法やテクニックについて説明します。


(石沢 健人=要求開発アライアンス 執行委員)