 |
|
| 経験が物語る実践型プロジェクト管理 |
第６回：あらゆることをプラスに導く顧客業務の徹底理解
著者：イマジンスパーク 深沢 隆司 2006/4/26
|
|
|
| 前のページ 1 2 3
|
|
| 稼働後の不満を解決する顧客業務の徹底理解
|
表2の2は「徹底的な顧客業務理解」を目指す最も直接的な理由です。例えばB6版の小さな手書き伝票（伝票1枚には5行の情報があり、一番右は「備考欄」です）があります。これを対象として入力フォームをつくる際に、初期段階で顧客側担当者に各項目に関して聞いたところ、「備考欄」は文字型で全角文字が8つ入ればよいとのことで、誰に聞いても特に問題はなさそうでした。
しかし実際に徹底的な業務分析を行ってみると、1日に1枚ぐらいは「備考欄」に小さい字で20文字も書いている伝票が見つかりました。実際にその伝票のスキャンを提示しながら打ち合わせをして、はじめて「30文字は必要」となるような場合があります。
同様なことは様々な要素を対象として起こってきます。特に「手書き伝票」の業務をシステム化するような場合は、伝票に項目名がなくても自由に書き加えられますし、欄外にいくらでも書き加えることができるということも考慮しなくてはなりません。
つまり外部の人には伝わっていない当事者同士の記入ルールがあったり、手書きでなくても入力の仕方に当事者同士の例外ルールがあるようなケースは当然発生してきます。顧客業務の現場で伝票や行動を直接見ないとわからないことが沢山あるのですが、実は顧客側担当者はそのような情報を一切持ち合わせていないことも多いのです。
顧客業務の現場で必要とされる細かい要求のすべてを考慮して、可能であればより快適な方法でシステム化を実現できないといけません。これが実現できないと、顧客側の担当者がいくら承認してシステムが重要な機能は満たしていても、じわじわと顧客業務の現場からの不満の声が高まってきて、最終的に顧客側全体としての開発側に対する評価は極めて低くなってしまいます。
表2の3は2と似ています。実際にできてきたものを見てはじめて、「もっとここは沢山書いています」とか「独自のルールができなくなっている」などの理由で仕様変更となることもあります。
これら3つの例はすべて実作業者への大きな負担を強いるものばかりです。そして、しっかりと業務分析を行いさえすれば、その多くは事前に抑えられるはずなのです。
|
| あらゆることをプラスに導く顧客業務の徹底理解
|
安易に行われてしまう「憶測の会議」などによって、いくらでも問題は発生してきます。その問題点を克服するためには、開発側が実際にシステムを作るという切実感を持って実際の業務の現場を自分たちの目で見聞きすることです。そして時には業務を実際に行ってみるとよいでしょう。また過去のデータにも遡って徹底的に情報収集や理解を行い、事前にすべてを潰していくことを目指します。
「顧客業務の徹底理解」はマイナス要因の防止だけでなく、あらゆる所で影響力を発揮します。画面上の項目配置やコントロールのタイプの選定、フォーカス順などのよりよいアイデアを提示できますし、顧客側の判断ミスなども未然に指摘できる場合が多くなるなど、様々な面で大きなプラスをもたらすものになります。
|
前のページ 1 2 3
|
|
|
|
|
著者プロフィール
株式会社イマジンスパーク 深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。
|
|
|
|
|
|
