筆者は、コンサルタントのように、BPRを大上段にかざして「To-Be」「As-Is」を熱く議論することはしない。システムは、効率化のための道具に過ぎない。議論に多くの時間を割くよりも、小さな改善を積み重ねた方が、ずっとよい道具になると考えている。
「ITmediaエグゼクティブ」の記事に「ユーザがどれほど自分たちの業務を整理できているのか、自ら持つ潜在的な要求をどれほど整理して表現できるのか、はなはだ疑問だ。経験豊富なベンダーが上手にリードしていった方がいい」とあった。この記事の意図するところは「納期厳守が大前提なんだからグダグダとシステム化検討会議をしてられない!! 開発に移ろうぜ!!」ということなのだろう。ほとんどの自治体や企業では「最初に、企画部門もしくはシステム部門が素案を作成し、次に業務部門を交えシステム化検討会議を行い要求仕様をまとめ、最後に開発へと移行する」という手順で進める。しかし、この手順そのものが間違っているので、先の記事となるのではないかと筆者は考える。
まず、次の課題がある。
(1) 現場を熟知していない、もしくは良く知らない部門が素案を作成している。
(2) 現場は日常業務をこなすことに専念しているため、身近な課題には気付いても、根源的な課題になかなか目がいかない。
そこで、「現場を熟知しかつ指導力のある者がリーダとなって開発を進めるべし」ということになるが、そのような者をシステム部門に配置することは現実的にはない。組織がそのような配置をしようとしても、本人が嫌がる。出世の早道とは思えないし、リスクも高いからだ。
ゆえに筆者は、手順に無理があると考え、画面デザインから始め担当職員がシステムを理解した後、業務部門と「具体的な相談」をするという手順を選んだ。この後はDB設計へと続くが、その話は次回に。
しまむら・ひでよ 1963年3月生まれ。長崎県総務部理事(情報政策担当)。大手建設会社、民間シンクタンクSE職を経て2001年より現職。県CIOとして「県庁IT調達コストの低減」「地元SI企業の活性化」「県職員のITスキル向上」を知事から命じられ、日々奮闘中。オープンソースを活用した電子決裁システムなどを開発。これを無償公開し、他県からの引き合いも増えている。「やって見せて、納得させる」をマネジメントの基本と考える。
Copyright © ITmedia, Inc. All Rights Reserved.