今回のプロジェクトの難しさ(#2)
先日の続きです。前回は、みなさんも十分に感じている「お客様体制」に
ついて書きました。今日は、私的に、2つめの大きなテーマと感じている
「システム利用部門の範囲」について書いてみます。システム利用予定
部門が広範囲に拡大している事により発生している問題です。
「システム利用部門の範囲」
問題点:システム利用部門の予定がお客様セクションの広範囲にわたる。
システム利用部門が広範囲になっている事で何が問題か?具体的には
以下を認識しています。
1.今回のシステム化対象業務の統一ガイドライン・運用基準がない
各部門は、現状当該業務に対して独自の運用・管理を行っています。
企画策定のタイミングも違えば、投入商品の選定基準や店舗との分担
レベルも違います。また、衣料品については、そもそも商品管理手法から
違っていますし、特売の位置づけも違うように感じています。
ですが、そのような実態を完全に把握している人間が、社内外に1人も
いないのが現状です。このような状況下において、お客様企画立案部門は
全部門に対してほぼ同等のサービスレベルを実現したいと考えています。
私自身は、まずそれは不可能な事だと考えています。そこには、予算が
あり、スケジュールがあるからです。現状においての、運用の統一化の
検討をお願いしておりますが、商品管理の性質や、商品そのものの特性が
違う以上、完全な統一化は望めないと考えます。その結果として、次々と
仕様変更、追加が発生している現状があるように思います。
大切なことは、無理に業務運用をあわせる事を強いる事ではなく、
あわせる事ができる所がどこで、オリジナルな部分を残さざるをえない所が
どこかをしっかり整理する事だと考えます。その上で、統一化できる部分を
中心にシステム化を進めていく事が有効と考えています。そこから
はずれている業務が何かをあらかじめ把握しておきさえすれば
対処はできるはずです。我々が、お客様から提出される仕様変更依頼を
検証する時には、そういう視点が必要と考えます。
また、設計において大切な事は、各部門に対する提供機能が
同一レベルにある事を意識する事です。
例えば、「衣料品向けの画面には、昨年実績を参照する機能があるが
食品向けの画面にはない」こんな状況を作らない事です。お客様から
変更要求が発生した場合、こんな視点でもその変更を承認すべきか
どうかを確認する必要があると思っています。
2.本格的なシステム化やシステム利用を行った経験がないセクションがある
システム化企画、システム利用を行った経験がないセクションは、システム化を
行う上で、どんな情報が必要か? どこまで我々に伝えておけば良いのか?
などの判断が出来ないことが普通です。「我々に伝えきれている部分だけが、
システムになる。」という事も、わかっていないかもしれません。
もしもそのような状況を誰も省みず、要件定義が完了したとしたら、
完成したシステムは全く使えないものになってしまう可能性すらあります。
この状況を回避する為には、エンドユーザとシステム化要件について
直接話をする場合、また、情報部門にエンドユーザへのヒアリングをお願いする
場合、必要以上に具体的な話をしなければいけません。
「何が実現できるのか」「どのような運用をしなければいけないのか」は
もちろんですが、大切なことは上手くいかない事を具体的に伝える事です。
余計な心配と思われるくらいに心配して丁度良いかもしれません。
もう1つ気にとめておかなければいけない事があります。それは、エンドユーザ
は、自分が今話をしている業務要件の追加が、システム化に対してどれだけ
インパクトがある内容であるかを判断する事ができないという事です。
実現が難しい話であるとか、コストがかかる話であるとか、そんな事は、
全く判断基準にはないはずです。つまりコストパフォーマンを基準とした判断
にはなっていない事が多いという事です。ですが、それをそのまま受け止めて
実現案を検討し、見積りを作るのも我々の仕事としては間違っています。
我々は、コストについての問題をストレートに伝える事なく、エンドユーザが
機能を選別する手伝いをしなければなりません。その機能をシステム化の
対象外とした場合、運用にどれだけの負荷が残るのか?整理して考えて
もらうように仕向ける事が大切です。ゆっくりと冷静に考えてもらえば、
実は全くシステム化の必要性はなかったなどという話もあるはずです。
「必要ですか?」と聞けば、「必要!」との答えが帰ってくるはずです。
なかったらどうなるか?を聞く事が重要です。そして、それがなかった時の
運用をしっかりイメージしてもらって下さい。
お客様との要件確認、定義は現状主には私の責任範囲ですので、
今回の話は、どちらかと言えば、自分向けの話という気もしますが、
この難しさは最近大いに感じている部分でもあり、テーマとしてあげてみました。
私としては、DWHや発注システムを開発してきた時と同様に、
まずは、部門を絞ってシステム化を行い、それをブラッシュアップした後に
各部門への適合を意識した改造を行い横展開する事が最善策と考えています。
今までのシステムが成功してきたのは、この手法による所が大きかったと
感じております。ところが、お客様は、残念ながら、過去の成功の重要要素
の1つが、この手法にあった事を認識されていない様子です。私は再三
この件についてお話をしてきたつもりですが、現状を見るとこのように
認識せざるを得ません。そういった意味でも、この問題をしっかり意識して
処置しておかなければ、カットオバー後に、今までにはなかった問題が
発生する可能性あり!と懸念する次第です。