PR


要件定義におけるエンドユーザーの不在。(ベンダーまかせ)の情報システム部の暴走。現場との乖離。
(ベンダー)


情報システム部のエンジニアの一方的な思いで,ユーザーの意見をほとんど聞かずに作ったシステム。
(ユーザー)


・組織内業務や組織間業務をそのまま作りこむ。・業務の一つの決定事項について,複数人が同じような立場で決定する場合があり,システム的な矛盾が起きる。・いつも全体最適を言うが全体の仕事が分からないシステム部門が自分たちの存続のためにシステムを作る。・トップにシステム上の欠点をきちんと説明しないままで進める。
(ユーザー)

 現場の意向を捉えることのできないシステム部門が存在するのはなぜしょうか。その背景として,以下のご意見にあるようなシステム部門の力量不足を指摘することもできると思います。


私の会社は製造業です。社員はパートを含め,かなりの数がいますが,ITにかかわる人間はほんの数人です。元々他社からの転職者が少なく,入社してこの会社一筋という人間が多いので,システムをIT企業に依頼することに慣れていません。つまり,我がままが言えない状況(正確には,どこまでお願いしていいものか分からない)です。こちらが客なのに,IT企業の言いなりの上司を見ると悲しくなります。
(ユーザー)

 システム部門がどうあるべきかについては,日経コンピュータでも何度となく取り上げていますが,なかなかこれといった回答は出せないのが現状です(最新の2005年1月24日号では悩めるシステム部長とシステム部門を対象とした大規模な調査結果を掲載しました)。しかし,システム部門の力量不足が質の低いシステムを招くのは間違いのない事実です。この問題を解決するためには,地道な取り組みしかないのかもしれません。

動かすことよりもその後が重要

 三つ目の原因は,システムを完成させることだけ意識して,いかにシステムを使うかという視点でのチェックが足りなかったというものです。以下の2件のご意見をお読みください。


完成することを優先させてしまった部分があると感じられるし,完成すればすべての問題が解決すると信じている社内の雰囲気も問題であろう。

「システムの完成」はベンダー側では,ひとまずプログラムの完成やら完成図書などの「納品」を示しているが,ユーザー企業側では,それを使って運用しなければならないことを忘れてしまっているのではないか。確かに,コンピュータに不慣れだから,外部委託してシステム構築を依頼するのだが,両者が打ち合わせることと言えば,当然,プログラムの仕様が中心で,「使い方」については二の次だ。もちろん,業務分析を行い,適切にシステム構築へと橋渡しするSEの介在があるが,ユーザー企業が求めているのは,むしろ,SEではなくコンサルの域であろう。この時点で,既に認識のズレが生じていると思っている。システムを作ればおしまいと考える業者と,システムができればおしまい,と信じているユーザー企業。動かないコンピュータは,こういうところで生まれるのではないか。ユーザー側の啓蒙と,システム屋のコンサル能力向上が,ある意味カギではないだろうか。

(ユーザー)


「作る側と使う側の様々なカベ」が原因の一つだと思っております。「システムは作る事が目的ではない」は,正しい指摘です。しかし,システム構築の立場の人間にとってみれば,「作る事が目的」です。職務/職責としても,そうです。そうすると,「作る側/使う側」という意識のカベから,どうしても「意識その他のカベ」が生じます。これは社内外問わずにそうです。使う側としても,構築側から業務改善のような領域に踏み込もうとすると「あなたたちにそこまでの権限があるのか?」となります。そのようなやりとりのなか,特にシステム側が「作って動けばオッケー」という意識になり,真の目的である「いかに活用するか」まではとても意識が行かない,というのが我が社の現状です。
(ユーザー)

 システム部門のあり方とも関係するのですが,業務に対する理解不足や開発能力の不足ではなく,システムという手段を完成させることが目的化してしまうことが,不要なシステムを生んでしまうということです。このご指摘は重要だと思います。