プロジェクトにおける可視化（見える化）の必要性(2)

2007.04.19

　前回は，ロジカルに成功指標を持ってゴールを「見える化」することが重要というところまで説明した。今回はその続きである。

　ユーザー企業の方々の意見を集約すると，ゴールの指標化をロジカルなやり方で設定できているところは少ない。お題目的にそれらしいゴールは出すものの，実際のところは，「経営層がそこそこ納得している」「プロジェクトに影響を受けた人たちがおおよそ納得している」という状態をプロジェクトの成功と認識しているようである。

　現実的には，利害関係者，影響を受ける現場など，みなが諸手を挙げての大成功などというプロジェクトはまずありえない。立場の違う人たちそれぞれが，プロジェクトのことをあまりひどくは言っていない，とか，感想を聞けば「まあ，こんなもんじゃないの」とかのコメントが返ってくる，というぐらいがかなりの成功のレベルだという。

　これは成功指標だけでは語れないプロジェクトの重要な側面であろう。ポジティブに表現されなくても，ひどい文句を言われていなければ成功なのである。

　これを逆手に取ると，常に文句を言わせないような状態を作ることが，プロジェクトの成功戦略といえなくもない。つまり，それぞれが，それなりに片棒を担いだとか，自分の決定に基づいて今の結果がある，という形にプロジェクトをデザインすれば，少なからず自分のせいだからひどくは言えないという状況にすることができる。

　情報システムの導入という流れに沿って，どういう点で納得感を得るべきかを整理すると，以下のような合意ポイントがある。

現状の認識で合意
現状の問題意識で合意
問題解決手段で合意
情報システムの必要性とその期待する役割で合意
導入にかかわる種々のコスト（直接の経費や導入することによる業務インパクト）で合意
結果として事前のイメージから大外れなし
全体を通じてのものごとの決定プロセスで合意

　ここまでを，はずさずに最後までたどり着けば，まずあまり文句は出ないはずだ。

　ただし，これらの合意を得るためには，様々な方法で対象の「可視化（見える化）」が必要になる。例えば，「現状の認識で合意」ということに関して言えば，まず業務の全体の流れが共通に認識されていなければ，その効率化の議論は虚しいものになる。

　先にも述べたように，現場ではそれぞれの担当は自分の周りの業務は知っていても，隣が何をやっているのかはよくわかっていないのが普通だ。それぞれの立場でぼんやりとイメージしていることをベースに話し合っても話は噛み合いようがない。まずは業務フローを描いて，みなが一連の流れを眺め渡せるようにしたうえで，具体的に指をさしながら話を始めなければならない。

　また，議論にのぼる様々な業務の言葉も部署や担当ごとにその意味やニュアンスが微妙に違っていたりする。同じ土俵に関係者がのぼらなければ，ロジカルに議論を進めることができない。そのために，随所で様々なモデリングを行い，可視化を行うのである。

　全体が正しく見えなければ，自分の部署の事情だけが優先しがちだ。自部署に不利な話には当然のりたくない。しかし，全体が見えて，他部署の事情もわかれば，自部署が全体のために多少の不自由を引き受けざるを得ないこともおのずとわかってくる。ここへきてやっと大人の議論ができるようになるのである。

ビジネスを検証するためのモデリング

　要求開発では，情報を整理し，共通認識し，判断を行うために随所でモデリングという手立てで可視化を行う。そこで使うモデルは，ある種のテンプレートでフォーマットされた文書，ツリーやグラフで問題や解決手段を構造化したもの，UMLで業務やシステムを表現したものなどである。

　UMLは，一般的にはシステムの構造や動作を図式的に表すものであるが，要求開発ではこれを業務というシステム（いわゆる情報システムより一段上位の人や組織などを含むシステム）を表現するために使用する。

　業務というと臨機応変に人が対応しているものというイメージがあり，システムとして表すということに違和感を感じるかもしれないが，事業体があるサービスを滞りなく提供する場合には，システムとしてそれが実現できることを静的モデルと動的モデルで保証されている必要がある。

　そうでなければ，属人性なくサービスが継続できるとはいえない。そのモデルが正しく動作することやサービスの内容が変わったときにどのようにすればその変化を受け入れることができるのか，などをモデル上で十分に検証しておけば，後の憂いはない。

　逆に，決め事（ビジネスルール）が不備だったり，毎回やり方が変わるなどで，このモデルが適切に機能しないとすれば，この段階で正しく業務が回るように，決着をつけておかねばならない。

　業務のところで共通化しておくべきことや，白黒付けておかなければならないようなことを，あいまいにしたままシステム開発の段階まで先送ってしまうと，多数の例外処理に対応する肥大化したシステムになってしまったり，業務に適合せず，大々的な手戻りが発生したりして，大きなしっぺ返しを受けることになる。

　このように業務の領域をシステムととらえてモデル化し，分析，検証，設計するために，UMLを適用して，サービスをユースケース図，そのサービスを実現する活動を業務フロー図（UMLの場合はアクティビティ図），そこに登場するモノ，コトを概念モデル（クラス図）で表現するのである。

　モデリングの詳細は，ボリュームの大きな話題なので，ここでは深く立ち入らないが，実施時に注意すべきは，モデリングをする元々の目的を見失わないことである。モデリングそのものは，目的ではなく，手段であり，要素技術にすぎない。

　ともすると，モデリングすることが主役になってしまい，細部にこだわって，貴重なプロジェクトの時間の中で余計な深堀をしてしまいがちだ。常に「どのような局面で，どういう立場の人が，何を理解し，何を判断するためにモデリングを行うのか」ということを意識して，ほどよいリズムで先に進めていかなければならない。

　いまだに，世の中のプロジェクトの中では，必要以上に凝りすぎたり，目的を見失ったモデリング・セッションを見聞きすることがある。モデリングという武器を持つと，つい振り回したくなるのもわかるが，モデリングを行うときは明確な目的と終了条件を掲げて着手し，くれぐれも上位目的を見失わないように注意していただきたいものである。