PR

 前回は,ユーザーとともに課題に取り組むうえで,開発サイドの得意分野を活かす方法について紹介した。その例として抽象化スキルを挙げた。今回は具体的な課題分析の進め方の例として,ボトムアップビジネス分析の手法である問題分析ツリーを紹介する。

問題分析ツリー ──トップダウンとボトムアップの課題をリンク

 問題分析ツリーとは,ビジネスの現場における問題を,業務担当者の視点から解決策を抽出するためのツールである。問題分析には,ビジネス課題や戦略に対する解決策を検討するトップダウンビジネス分析の手法と,現場業務の解決策を検討するボトムアップビジネス分析の手法がある。Openthologyでも,トップダウンやボトムアップのビジネス分析手法がいくつか紹介されている。

 今回紹介する「問題分析ツリー」はボトムアップビジネス分析の手法として実装されている。この手法では,トップダウンビジネス分析を行った結果との接点にフォーカスすることで効果的な問題解決を測ることを目的にしている。

 問題分析ツリー(図1)は,以下のモデリング手順にそって行われる。

(1)問題の列挙

 付せん紙に問題を列挙してもらい,ホワイトボードなどに貼り出す。

(2)問題のグルーピングと優先度の設定

 付せん紙を同類ごとに分類し,グループ分けする。この際,トップダウンの課題と共通していて解決策が提示されていないものを最優先課題として扱う。

(3)問題点,解決策の具体化

 優先度の高い問題からディスカッションしながら本質的な問題点を具体化する。
 具体的な問題が出てきたら,その解決策を貼り付ける。
 解決策も具体化するまで続ける。

(4)リスクの設定

 解決策に対してのリスクを設定し,ツリーに貼り付ける。

(5)解決策への優先度の設定

 重要または改善効果が高いと思える順に優先度(A,B,C)を記入する。

図1●問題分析ツリーの例
図1●問題分析ツリーの例
[画像のクリックで拡大表示]

 一見すると,いわゆるブレーンストーミングのなかで問題を列挙して構造化する作業手法と同じように見える(皆さんも付せん紙をホワイトボードに貼り付けたりした経験があるのでは?)。

 しかし,Openthologyの特長は,プロジェクトを段階的に詳細化,具体化を行っていくなかで,各フェース間で検討される要求や解決策のトレーサビリティを確保していくところにある。

 問題分析ツリーでも,業務担当者の課題単体で検討するのではなく,前述したようにトップダウンビジネス分析の結果との接点にフォーカスをあて,その個所の優先度をあげるところにポイントがある。また,リスク分析を行う点もポイントである。

 この手法を使う場合に,開発サイドの分析力を活かすにはどのような姿勢が必要だろうか。

姿勢その1──個々の問題に引きずられない

 最初に,問題分析ツリーの手順のはじめに行う「問題の列挙」に着目して説明する。

 ここで挙げられる問題,課題のレベルには非常にばらつきがある。はじめから的をついた問題点を挙げる人もいれば,単にユーザーのクレームに困っているといった,「問題点」というよりも問題の結果として起こった「事象」に過ぎないことを挙げる人もいる。

 また,その部署で積極的に発言する人や立場の強い人がたくさん意見を挙げて,ほかの人の意見が吸い上げにくいような環境要因もある。状況はその場によって様々であるため,個々の問題に目を奪われてしまうと議論が思わぬ方向へずれてしまう。そこで,問題の列挙とグルーピングでは以下のような点に気をつけることをお勧めする。

●問題を書いてもらう際は時間をとってじっくり

 できれば1時間ほど考えてもらうと,腰を落ち着けて考えることで整理できるため,うっかり意見を出し忘れることがぐんと減る。会議のまえにあらかじめ問題点を記入しておいてもらうのも良い。あらかじめ書いてもらうことで部署内の人間関係に左右されない意見収集ができるという効果がある。

●ファシリテータは開発サイドが行う

 業務に精通した人間よりも,先入観が無く,業務における利害関係に左右されない中立的立場である開発サイドの人間が議論のファシリテータとしてふさわしい場合が多い。

 次にグルーピングと優先度の設定について説明する。

●グルーピングの指標はあらかじめ用意しておく

 議論を進めやすくするためにも,グルーピングの指標はあらかじめ参加者間で共有しておいたほうが良いだろう。具体的には以下のような指標が挙げられる。

・トップダウンビジネス分析の課題との距離はどの程度か

優先度を決める上で大切な指標。ツリーの中から,トップダウンビジネス分析の課題と接点のあるものの優先度を高める。

・事象なのか原因なのか

事象である問題は,原因が何なのかを突き止めるまで続ける。

・具体性はあるか

抽象的な問題は具体化させて解決策が見えるようにする。

 指標を基準にディスカッションを行うことで,参加者も課題を分析しようと頭を働かせるため,局所的な問題にこだわって前に進めなくなる状況がぐんと減る。また,指標が問題を階層化できるため,優先度が見えやすくなる利点もある。

姿勢その2──場当たり的な解決策に走らないブレーキになろう

 優先度が固まると,問題点を具体化し,解決策まで掘り下げる。ここで気をつけたいのはユーザー側から提示される場当たり的な解決策である。例えば,現状のシステムに関する問題点が挙がった場合,ユーザー側からはそのシステムに対する改善案件へと解決を進めがちになり,目先のさまつな議論に陥りやすい(図2)。

図2●場当たり的な解決策に走らない
図2●場当たり的な解決策に走らない

 トップの課題を意識して場当たり的発想や安易な解決策に落ち着かないようにブレーキをかけるべきである。トップダウンビジネス分析手法の「BSC戦略マップ」や「ビジョン分析ツリー」があれば,それらとグルーピングした問題を比較してトップの意向と現場の接点を探すように心がけて欲しい。

 問題分析ツリーは現場担当者と一緒に行うため,ボトムアップ的視点に偏りがちだが,常にトップダウンの視点からの課題の重要性は見失わないようにしたい。

 また,具体的な解決策を練る場合に注意したいのはシステムにこだわった解決を求めないことである。ユーザーの問題点がシステムに起因していたとしても,その解決策もシステムにのみ求める必要はない。

 システムを使わなくても,業務の運用を変えることで済むのであればそれに越したことはない。IT化する対象を検討するのが目的であって,IT化が目的ではないことを忘れないようにしよう。

姿勢その3──リスクを踏まえて優先度を設定しよう

 具体化された解決方法が明示されたら,かならずリスク分析を行う。実現可能性を抜きにした解決策は絵に描いたもちになってしまう。リスクを踏まえたうえで改善効果が高いと判断できる順に優先度をツリーに記入しよう。

 また,最終的にまとまった解決案の具体化はできるだけ細かく,ユーザーが頭に描けるレベルまで具体的に提示するようにすべきである。

 ディスカッション中心の打ち合わせによくあることだが,なんとなくな解決案がでて終わりになると,あとで思い出せない場合や,実現性の低い解決案である場合が多い。

 業務を運用している姿を具体的に思い描ける解決策も示して確認するようにすべきである。リアルな状況を考えることでリスクも具体的に浮かび上がってくる。

姿勢その0──本質を見抜く姿勢を大切に

 2回にわたって開発サイドの得意分野を活かす方法について説明してきた。本文で紹介したように,開発サイドのスキルがビジネス課題の解決に貢献できるシーンはよくある。

 課題の本質を見抜く姿勢を大切に,これからも,より良いシステムを作るため,ユーザーとともに課題に取り組んでいきたい。

(大浦 史仁=要求開発アライアンス 執行委員)