要求開発とコタツモデル(2)－－アンチパターンを活用する

2008.06.17

　前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。「コタツモデル」とは，ITシステム開発プロジェクトにおける，主要な三つのステークホルダーの関係性を表すメタファーです。

　ビジネス戦略を決定するビジネス・オーナー（経営者や高位の責任者），実際のビジネスを遂行しているユーザー（現場担当者），そしてシステム開発担当者の三者によってシステムの目標を決定する＝一つのコタツに入って議論する状況を，要求開発アライアンスでは「コタツモデル」と呼んでいるものです。

　今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。

「コタツモデル」形成に王道なし，アンチパターンの活用

　「（要求開発・要件定義などの）上流工程は異種格闘技戦である」──これは筆者の持論です。ITシステム開発の下流工程，すなわち設計・プログラミング・テスト・移行といった作業は，しっかりとした計画を行えば意図した通りに物事が進み，コントロールすることも容易です。これに対して要求開発や要件定義といった上流工程は，参加者のスキルや経験などによって作業の内容が大きくブレるためコントロールしにくいという特性があります。

　そこで，要求開発・要件定義フェーズでは「定められた手順で作業をする」のではなく，状況や相手のアクションに対して臨機応変に対応していくことが必要となります。SIerの立場でITシステム開発プロジェクトに参加する筆者は，常に未知の相手と対戦することが多いため，相手にあわせて臨機応変に「異種格闘技戦のつもり」で立ち望んでいるのです。

　「コタツモデル」の形成では，特にフレキシブルな対応が必要とされます。通常のITシステム開発プロジェクトでは，参加メンバーを自由に選んだり途中で変更したりすることはできません。できることは「不足を補う」「関係性を調整する」などの受身の対策に限られてしまいます。

　つまり「コタツモデル」を形成するには，問題状況（コタツモデルではない状況）別に，状況に応じて様々なテクニックを駆使することが重要となります。そこで筆者は，ソフトウエア開発のアンチパターン（べからず集）を参考に，コタツモデルで陥りやすい問題状況と対策を整理してみました。

■コタツモデル・アンチパターン(1)　オーナー不在

症状：ビジネスオーナー（経営者や高位の責任者）が参加していないため，システムの方針や要求の取捨選択が適切に行われない

　本来ビジネスに役立つシステムを作るためには，オーナーの立場での方針決定や取捨選択を行うべきです。オーナーの視点があれば，「1年に1回しか利用しないムダな機能」「特定担当者だけの利便性向上しかできない要求」などを削減し，ビジネスに対するシステム開発の効率を向上することができます。

　しかし，現代のITシステム開発は，過剰に「専門家」「選任担当者」のものとして扱われています。「ITはシステム部門にまかせる」として，ITシステム開発プロジェクトに参加しないビジネスオーナーはたくさんいます。

対策1：プロジェクト・メンバーに代役（オーナー役）を割り当てる

　もっとも簡単なのは，プロジェクト・メンバーの一人に「ビジネスオーナー役」を割り当ててしまうことです。このメンバーは必ずレビュー時に「ビジネスオーナー」としてレビューをするようにしてもらいます。この対策は非常に安易なものですが，それでも意外と機能するので試す価値は十分にあります。

対策2：マイルストーン・イベントを活用し，オーナーの参画を計る

　ITシステム開発プロジェクトでは，節目にいくつかのイベントがあるのが一般的です。「プロジェクトキックオフ」や「フェーズレビュー」などの重要なイベントを活用し，ビジネス・オーナー（経営者や高位の責任者）に，プロジェクトへの参画をお願いするのです。

　そして，イベント時には，次のような点について挨拶などの中で触れてもらうように事前に依頼をしておきます。

私がこのプロジェクトに望むこと
私がこのプロジェクトに望まないこと
こんな問題が発生したら，私に声をかけてほしい

　この程度であれば，日頃ITに無縁のオーナーにも抵抗なく参加することができます。そして，プロジェクトの方向性やオーナーの視点を得ておけば，その後のプロジェクトでの判断に活用することができ，オーナー不在の不利益を軽減できるのです。

　なお，経営者などのビジネス・オーナーのプロジェクト参加については，GEの組織変革手法「ワークアウト」が非常に参考になります。詳しくは，『GE式ワークアウト』（日経BP社発行）をお勧めします。

■コタツモデル・アンチパターン(2)　ユーザー不在

症状：エンドユーザー（業務担当者）が参加していないため，現場の実業務に適用できないシステムを構築してしまう

　経営者や責任者が現場の叩き上げなどで「業務がわかって」おり，かつ大きな目標・目的を持ってシステム開発プロジェクトに参加するときに陥りやすいパターンです。

　「ITシステムで業務を変革する」「業務をあるべき姿とする」といった目標は重要なものです。しかし，要件の検討時に現場の視点が欠けてしまった結果，「発想は良いけど使えないシステム」が仕上がってしまうことがあります。

　また，ここまで極端ではなくとも，「実際の業務をおこなう支店の声を聞かず，本社部門のメンバー中心でシステム検討を行う」ことや，「（ネットサービスなどで）顧客の声を聞かずに，企画部門中心で開発を進める」というのも，ユーザー不在パターンの一種と言えます。

　過去のITシステム開発は「業務の電子化」「機械的事務自動化」が中心であったために，ユーザーの参画度合いが薄くてもプロジェクトを成功させることができていました。しかし，現代のITシステムでは，人間系とシステム系が非常に密に結合するようになっているため，ユーザー不在の要求開発・要件定義は非常にリスクが高まっています。

　ビジネス・オーナーよりは，ユーザー（現場担当者）のプロジェクト参画を図ることは難しくはないでしょう。それでも，何らかの事情でユーザーの参加が望めないのであれば，次のような対策を実施したほうが良いでしょう。

対策1：「現場見学」

　「現場見学」とは文字通り，現場担当者の仕事場に出向き，実際の業務を観察することです。検討しているシステムを適用する場所に出向き，現在どのように業務が行われているかを確認し，検討チームが考える「現在の業務」と実際の業務に違いがないかの確認を行います。

　「現場見学」のポイントは次の2点です。

目的を明確にすること（例：△△業務のボトルネックは○○であることを確認する）
見学の背景を現場担当者に伝えておくこと（例：△△業務のシステム化検討のために，○○から△△までの手順を見学したい）

対策2：ペルソナを作る

　システムの実際の利用者が組織内にいない場合には，ユーザーのペルソナを作成することによってユーザーの視点を獲得することができます。ペルソナとは「架空のユーザー像」であり，最近マーケティングなどで注目されている検討手法です。

　検討するシステムの利用者像について

年齢
経歴
興味のあること，興味のないこと
好きなこと，嫌いなこと

などを具体化し，作られた「ペルソナ」の立場で要求や要件の良否を判断します。

■その他のアンチパターン

　今回は，特にコタツモデル形成で陥りやすいアンチパターン「オーナー不在」「ユーザー不在」について取り上げました。

　これ以外にも，要求開発や要件定義といった上流工程では，いくつかのアンチパターンがあると筆者は考えます。簡単に，要求開発アライアンスの定例勉強会で発表した他のコタツモデル・アンチパターンを紹介します。

表1●その他のコタツモデル・アンチパターン

アンチパターン名	状況	対策
寒い！	プロジェクトを推進する熱意が無く，コタツが冷えている	オーナーによるプロジェクトの再キックオフ
ミカンが無い	コタツを囲んでみたものの，検討材料が無いため盛り上がりに欠ける	議論を始めるための仮説ビジネスモデルを作成してから集まる
ミカンが不味い	検討するビジネス戦略が不味い	オーナーへのエスカレーション，目標の再検討
鍋奉行	特定の参加者が議論を誘導してしまっている。議論に不満が残る	問題のステークホルダーとの交渉，交代の要請
密約	コタツの外で，特定の参加者間で決定がなされている	オーナーへのエスカレーション，決定内容の点検
コタツじゃない	会議や議論がフォーマルすぎて，活発な意見交換がされない	インフォーマルな活動も取り組みに追加する