コタツモデル・アンチパターンズ(2)

システム開発の要求開発・要求定義フェーズにおける人間関係のメタファー「コタツモデル」。そのアンチパターンについて考えるエントリの第2回です。


■オーナー不在(Owner Absence)
別名：誤った現場主義
挿話証拠：「トップは現場(業務)をわかっていないから」

ア ンチパターンの一つ目は、「オーナー不在(Owner Absence)」パターンを取り扱います。
図にあるように、「E(Engineer)：システム担当者」と「U(User):ユーザ、つまり業務担当 者」がコタツに入って、仕様を検討しています。ここで重要なのは、ビジネスオーナーが不在である、ということです。 ただしい コタツモデルでは、「E(Engineer)：システム担当者」「U(User):ユーザ、つまり業務担当者」「O(Owner):ビジネスオーナー」が 一つのコタツに入って合意形成をすることが良いとしています。それでは、ビジネスオーナーが不在の場合には、どのような問題が発生するのでしょうか。

■症状と結果
ビジネスオーナーは、次のような視点を持っています。

• 俯瞰的な業務構造やあるべき姿についてのイメージ
• 現場担当者や、システム担当者が知らない社内外の動き
• 実施事項がどのようにビジネスに影響するか

オーナー不在パターンでは、これらの視点が欠如する、または不足することによって次のような結果を引き起こします。

(1)現状業務にあわせてシステム化をしてしまい、業務の効率化や標準化、最適化がされない。

業 務担当者は通常、現在の業務を適切に遂行することが主な仕事となっています。その中で発見した課題や問題を中心にシステムの要求や仕様を検討するため、個 別の問題の解決は達成できます。しかし、あくまで現状の業務を中心に考えてしまうために根本的な(真の)改善点について、意識せずに回避してしまったり、 見落とす可能性があります。
たとえば、製造業の業務改善として有名なトヨタ生産方式(かんばん)では、商品の欠品を無くす為 に在庫を無くすという逆転の発想から生まれました。しかし、もしこの「欠品を無くす方法」の検討が、生産管理担当者によって行われたら、本当に「在庫を無 くす」という発想が出来たでしょうか。「欠品を無くす為に在庫を持つ」という常識に捉われてしまい、おそらく異なった結論に達するでしょう。
(参考：職場の「かんばん」方式)

(2)あまり重要ではない、些末な機能に大きく労力とコストを割いてしまう。

システム要求や仕様の検討は、必ず優先順位と取捨選択を伴います。この際に、ビジネス上の効果の視点が不足すると、本質的ではない機能について長い時間を割いて検討や開発をする事になりかねません。

• 特定の担当者しか利用しない機能に、非常にいろいろな使用頻度の低い付加機能を作ってしまう。
• 先進的だが実験的で、長期的に利用するかわからない機能に注力し、普遍的かつ長期的に利用する機能についての検討が不足する。
• 画像、アイコン、レイアウト、配色、その他ビジネスの本質とは関係の無い要求を多数盛り込んでしまう。

このような検討のムラとムダが、オーナー不在の場合に発生します。

(3)中途半端なシステムを作ってしまい、すぐに再修正が必要となってしまう。

中 途半端というのは2つの意味があります。一つはビジネス環境の変化に対する追従性です。業務担当者が知らない、または知らされていないビジネス環境の変化 というのは存在します。例えば法規制やビジネス戦略の方向性などは、内容によってはビジネスオーナーだけが知っている場合があります。また、業務の合併や 統廃合などについても同様です。
もう一つは、現場目線の検討によって、自社内の他のシステムと目的や機能が重複するシステム を、もう一つつくってしまうという問題です。特にユーザー部門が主導してシステムを構築する場合に、他の部門で検討中のシステムや、既に構築済みだが情報 共有されていないシステムと重複する場合があります。全社的なシステム部門の担当者が参加していれば防止する事もできますが、システム部門の参画も限定的 で、ユーザー部門と社外ベンダがシステムを構築する際にこういった問題が引き起こされることがあります
(参考：シャドーITって何？)

(4)開発プロジェクトメンバーのモチベーション低下

ビ ジネスオーナー不在のシステム開発プロジェクトでは、ビジネスとシステムの関係が明確でないままに進められてしまいます。システム開発メンバーも、自分の 開発するシステムが「何のために」作られ、結果として「どんなビジネス効果が出る」のかわからずに作業を行うこととなります。厳しいコストやスケジュール の制約の中で、自分達の参加するプロジェクトが、ビジネスオーナーから認識もされず、目的も不明確であればモチベーションも下がってしまうでしょう。

■典型的な原因

• ビジネスオーナーが、システムを単なる道具として捉え「ビジネスの屋台骨」ととらえていない
• ビジネスオーナーが、ITを苦手なもの、理解しにくいものとして避けている
• 業務担当者、システム担当者がビジネスオーナーの参画を面倒ごととして避けている

■解決策
システム開発プロジェクトへの、ビジネスオーナーの巻き込みは組織文化なども関係するため容易ではありません。しかしこの「オーナ不在」パターンにあるような問題が発生する懸念があれば、次のような方法を実施することを検討すべきです。

(i)儀式的イベントを活用する

プ ロジェクトのキックオフや開発フェーズの終了のタイミングは、ビジネスオーナーの参画を促せる絶好のタイミングです。特にキックオフについては次のような 視点でビジネスオーナーに発表をしてもらうことによって、検討期間中にビジネスオーナーが参加できなくとも、オーナー不在の不利益をかなり軽減できます。

• 検討するシステムのビジネス上の意義
• 検討の中で大いに検討してもらいたいこと、期待すること
• 望まない結果は何か

こういったイントロダクションの進め方については、GEが行う組織変革の手法「ワークアウト」が参考になります。ワークアウトでは組織横断的なチームが一 定期間のうちに問題解決のための議論を行います。その際には最初と最後だけ、ビジネスオーナーが参加を行い目的の明確化と、検討結果の是非の即決を行いま す。これはシステム開発の要求開発・要求定義フェーズにも適用できる考え方です。
(参考：GE式ワークアウト)

(ii)ビジネスオーナーへのインタビューをスケジュールに組み込む

キックオフやエンドポイントミーティングの実施の実績が無く、文化的にも受け入れられない場合は少なくともシステム開発の要求開発・要求定義フェーズで複 数回ビジネスオーナーへのインタビューを行えば良いでしょう。目的は、オーナー不在モデルで抜け落ちる「ビジネスオーナーの視点」を補うことです。なお、 ビジネスオーナーは忙しく、なかなか時間の確保をすることも難しいかもしれません。コンサルティングファームの技法の一つに「3分で行うエレベータープレ ゼンテーション」というものがあります。これはエレベータで移動する間の3分間で役員にプレゼンをすることなのですが、極端な話3分でも十分に確認や意見 を得ることは可能です。

■小話
ビジネスオーナーをプロジェクトに巻き込むのは最初はかなり躊躇します。ビジネスオーナーは、悪く言えば丸投げ、よく言えば権限を担当者に委譲しプロジェクトからは距離を置くのが一般的です。しかし、最終的に「ビジネス価値の高いシステム」を構築する上で、ビジネスオーナーは避けるわけにはいかない重要なプロジェクトメンバーの一人なのです。

プロジェクトは3ヶ月ほどの短期のものもあれば、数年間に渡る長期のものもあります。その期間たくさんのメンバーがシステムのために作業を行います。途中に苦しい時期もあるでしょう。そうやって作るシステムが「使えない」「使いにくい」「ポイントを外している」というのは、非常に悲しいことです。

オーナー不在プロジェクトに安住せずに、勇気をもってプロジェクトからアクションをするのが、大切ではないかと私は考えるのです。