« XEAD製品がJava1.8に対応 | トップページ | 「プログラミングの専門家」でも「ツールの専門家」でもなく »

2015.05.08

ベンチマークとしてのレファレンスモデル

 業務システム開発では、ユーザの要望にどこまで応えるかの見極めが肝心である。要望を取り込み過ぎても高コストで複雑なシステムになるし、拒否し過ぎても使いにくいシステムになる。どこで線引きすればいいのかは難しい問題だが、開発者側に手練手管がないわけではない。

 まず、取り込む必要のない要望の例を見よう。「このパネルですべての情報を眺められるようにしてほしい」といった要望が典型的な「わがまま」だ。この種の要望は、特定ユーザにしか使えないわりに高コストなUIを生み出してしまう。ところがユーザとしては組織での自らの雇用意義を強化できるため、悪意もなくそういうものを求めてしまいがちだ。こういった要望に開発者はどのように対処すればいいのだろう。

 まず重要なのは、ユーザの業務上の役割(role)を意識することだ。ヒアリング相手のユーザが鈴木さんで、彼/彼女が「営業アシスタント」のroleを担っているとしよう。この場合、鈴木さんの語る要望が個人的なものか、営業アシスタントにとって必要なものかを見極める必要がある。「鈴木さん」と「営業アシスタント」のどこが違うかというと、鈴木さんは営業アシスタント以外のroleに配置転換される可能性があるし、来月からは山田さんが営業アシスタントを担う可能性もある。つまり、roleに宛がわれた職掌は変わらないが、roleを担う要員は変化し得るのである。

 そこらへんを意識しつつ、鈴木さんの要望がroleに固有かつ必然的なものであるかどうかを評価すればいい。仮に鈴木さんがずっとひとりでそのroleを担当してきて、これからも担当し続ける見込みだとしても、この視点は必要だ。なぜなら鈴木さんは不死身ではないが、そのroleは永続的だからだ。ある日突然に他の要員がそのroleに配属されたとしても攪乱が生じない。そのように業務体制は設計されなければいけない。かくして「鈴木さんにしか使いこなせない複雑なUI」は却下される。

 もっと効果的なのが「レファレンスモデル」を利用するやり方だ。この業務ではこのようなオペレーションやUIや帳簿組織が基本、といったモデル(典型)を業種・業態別に用意しておくのである。そして、モデルに対してどれだけの追加要望があったかを部署別に集計して、コストを「見える化」する。そのことをあらかじめ伝えておいたうえで、ユーザにヒアリングすればよい。自分の発言が追加費用としてダイレクトに反映されると理解してもらうことで、ユーザの「わがまま」を効果的に抑止できる。また、手作業を前提にした古いやり方も見直しやすくなる。

 その態勢で収集される追加要望の多くは、ユーザ企業の競争力の源泉を成していると解釈していい。どんな業界であっても、それぞれの企業はニッチ(棲みやすい狭い場所)を見つけることで存続できている。その独特な「棲み方」は、経営者が意識的に強化・洗練していきたいところで、レファレンスモデルをベンチマーク(基準点)とすることでそれが明らかになる。

 もちろん、そういったモデルをあらかじめ用意しておくことは簡単なことではない。しかし、業務システムの開発事業を10年も続けてきてそういった知識を体系化できていないとしたら、開発組織としてはあまりに芸がないというものだ。言い換えれば、そういったノウハウを整備することで、開発企業は「最新ITに詳しいだけの御用聞き」から「システム開発もやれるコンサルティング会社」にレベルアップできる。モデルをまとめるために便利なXEAD Modelerのようなツールもいろいろある。それらを使って、まずは自分の開発経験に形を与えることから始めてみてはどうだろう。

|

« XEAD製品がJava1.8に対応 | トップページ | 「プログラミングの専門家」でも「ツールの専門家」でもなく »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: ベンチマークとしてのレファレンスモデル:

« XEAD製品がJava1.8に対応 | トップページ | 「プログラミングの専門家」でも「ツールの専門家」でもなく »