業務システム開発になぜユーザの参画が必要か

残席わずか！満席にさせてくださいm(__)m
4/20に、またキャリッジウェイ主催で「経営IT総点検」セミナーを実施します。IT資産の評価には、定性的な指標がつきものですが、それってどうやるのか疑問の経営者、企画担当者、コンサルタントは必見です！前回受講者の声もあります。
今回はさらにブラッシュアップしたセミナーにしますので、乞うご期待！

------

システム開発に限った話ではないが、「丸投げ」はいけないとよく言われる。この言葉の本当の意味が分かっている人は、ぼくの周りにはあまりいない。

たいていの人の理解は、管理をきちんとやればいいというものだ。

業種・業態によっては、正解かもしれない。しかし、業務システム開発に限って言えば、それだけでは必要条件にもなっていない。

業務システムというものは、コンピュータも当然含まれるが、人・モノ・金・情報etcを含めた業務の総体である。

よく顧客に機能不足を指定されたが予算が足りないというときに、開発業者側は「そこは運用で、なんとか」とお願いしたりするが、その「運用」の部分も当然業務システムの範囲内だ。

手書きのメモ、電話、業務のための会議体、そういったもの全てが業務システムの中には含まれている。

さて、業務システムを仮に開発ベンダーに丸投げすると何が起こるかというと、業務システムのごく一部であるコンピュータシステムに彼らは焦点を当ててしまうのである（図）。

例えば、要件定義でも業務設計でもいいが（こういう用語は人や会社によって呼び方が違うので、ふんふんあれだなと自分の言葉で解釈していただきたい）、こういう局面で重要な成果物に「業務フロー」と「概念データモデル」と言われるものがある。

業務フローとは、業務システム全体の人・組織とデータ・情報の流れの関連図であり、概念データモデルとは、データの観点での業務システムの説明図と思っていただきたい。

あくまで「業務システム」なのである。ところが、開発業者は、これに関して悪意は全くないのだが、どうやってもコンピュータシステムのフロー（これは本当はデータフロー図という）とコンピュータシステムのデータモデル（これは本当は論理データモデルという）を作ってしまうのである。

これは仕方がない。彼らが請け負っている範囲はコンピュータシステムの構築だから、そこにしか関心がいかないのは当たり前である。

しかし、当然のことながら、業務システムが定義されていないのに、その部分であるコンピュータシステムが正しく定義できるわけがないのである。

開発業者がよく「早く要件を決めてくれないと、納期に間に合わない」と顧客に迫るのは、顧客側で業務システムがまだ定義できていないという場合が殆どである。

業務システムを定義するには、絶対的にユーザの参画が必要である。ユーザにしか現行の業務は分からない。

システム部門が業務仕様などをきちんと考えて業者に発注することを称して、「ユーザ主導」と勘違いしている向きもあるが、システム部門は得てして業務を知らない。
必ずユーザを参画させるべきである。後々、ユーザからのクレームの嵐で苦しまないようにしたいのならば。

「正しい」業務だけなら、コンサルタントでも作れるかもしれないが、こういうのは絵に描いた餅になりがちだ。現行の業務を知るユーザと正しい業務について見識を持つコンサルタントの両方がいるのがベストの体制かもしれないが、実は正しい業務もユーザは知っているのだ。

コンピュータの素人とバカにせず、必ずユーザを参画させて欲しい。コンサルタントを雇うのであれば、業務のプロよりもファシリテーション（合意形成）のプロを呼んだ方が、ユーザ主導でやるときにはいい。

------

ご意見、ご感想がありましたらコメントかメールをください。

このような事業をしております。

メルマガよろしくおねがいします。
→　歴史上の人物に学ぶプロジェクトマネジメント

「賢者は歴史から学ぶが、愚者は経験から学ぶ」です!!

コンサルマインドを持ちたいSEさんはこちらのコミュニティに是非いらしてください。
→　ITコンサルになる！　（いよいよ始動！勉強会企画中！)

※応管理人の許可は要りますが、どこでも登録する「コミュあらし」防止のためだけです。

他にもブログやってます。こちもよろしく！

SEのための孫子

突破口訳徒然草