ユーザはＤＰ部門であることを期待する
ユーザの多くは，情報システム部門を高く評価しています。ところがその評価は，定例的な日常業務を正確に迅速に処理することにより，自分たちを無味乾燥な業務から解放してくれていること，必要に応じていろいろな情報を提供してくれること，パソコン操作などのトラブルに対処してくれることなどのＤＰ部門としての評価なのです。
ＩＴ部門としての評価はよくありません。そもそもユーザ部門は，情報システム部門のＩＴ部門化を望んでいるでしょうか？ あなたが営業部門で，その関係のシステム化を情報システム部門に要求しているとしましょう。ＤＰ部門であれば，技術的な理由や開発費用での制約についてはなにかいうでしょうが，その業務をシステム化すること自体については，あなたの要望をそのまま受け入れるでしょう。
それに対して，自部門の業務改革や組織変更なども提案するＩＴ部門としては期待していません。むしろ，そのようなＩＴ部門になることには否定的なのです。
あなたが営業部門だとしましょう。営業活動を通して経営戦略を実現しているのは自分たちであり，その実現を推進するために情報化要求をしているのだから，その要求に迅速に応えるのが情報システム部門の任務であると考えます。
情報システム部門からの提案は歓迎するが，それは我々の要求をどう実現するかというＨＯＷに関する提案です。「営業部門だけの部分最適化ではなく，生産部門や流通部門も加えた全体最適化をするべきだ」などという提案は，論理的には正しいかもしれないが，そんなことをしていたら，いつになっても我々の要求は実現されない。まして，「業務の仕方そのものが不合理なので組織から改革してしまおう」などというのは，あなたに対する反逆ですね。
基幹業務系システムにおける利用部門の行動
利用部門は上のような発想をするので，意識せずに自部門のエゴを情報システム部門に押し付けることが多く，それが情報システム部門でのＤＰ業務を多忙にして，ＩＴ業務に傾注するのを阻害しているのです。
要求定義での利用部門
情報システムは利用部門のためのものです。大きな費用，人材，期間を使うのですから，利用部門が主体になるのが当然です。それなのに，利用部門はその任務をはたさないどころか，むしろ逆の行動をしていることが多いのです。
次のグラフは，「日経ＩＴプロフェッショナル」（２００４年１月）が，システムインテグレータ，ソフトウェアベンダ，ユーザ企業の情報システム部門など，情報システムの提供側の人たちを主体にしたアンケートです。「要求定義に関して，困っていることや問題を感じていることは何か」については，利用部門に起因することが上位を占めています。
このアンケートでは，利用部門というよりもユーザ企業全体として「経営者，情報システム部門，利用部門間での意見が異なる」というような意味でしょうが，社内で情報システム部門が開発する場合でも「利用部門の人たちの間で意見が異なる」ことが多くみられます。
これを文章にすれば，次のようになるでしょう。
本来，利用部門の要求によるシステムのはずなのに，「利用者自身が何をしたいのか分かっていない」し，しかも，忙しいとか面倒だとの理由で「利用者が十分にヒアリングに協力してくれない」。「利用者の間で意見調整ができておらず，求めてくる要求が大きく異なる」し「利用者の要求がめまぐるしく変わる」ために，いつになっても仕様が決定できず，開発期間が極度に短縮されてしまう。
要求仕様書を作成しても「利用者が要求定義書をきちんとレビューしてくれない」ので，後工程になってから，誤りや不十分なことが判明し，大きな手戻りが生じて，時間や労力がかかってしまう。
不適切な人選による阻害
本来ならば，流通部門で経験が深く，問題意識があり，部内で統率力のある人が参加するべきなのですが，そのような人は日常業務でも重要ですので，流通部門の管理者はプロジェクトに出すのを渋ります。それで，あまり経験のないパソコン坊やを推薦します。情報システム部門は，長年の地盤沈下により「ユーザ主導」をモットーとし「ユーザの声は神の声」とする文化になっています。パソコン坊やの意見すら金科玉条として素案を作り現場に説明するのですから，その段になって担当部門からどっと異なる意見が出されるのは当然です。このような不適切な人選による失敗は，昔はよくあったものです。
現在ではこのような人選の誤りはせず，利用部門の精鋭を送り込んできます。ところが，その精鋭にもいろいろあり，マジメなバカが参加すると致命的な失敗になります。マジメな彼（彼女）は，徹底的に現状の改善点を探し「発見」すらします。その結果，膨大な要求事項が列挙されます。
その要求事項には，絶対にやるべき（ｍｕｓｔ）のものもあれば，やったほうがよい(better）程度のものもあります。重要度や効果の大きいものから順に並べれば，下図の青線のようなパレート分布になります。
また，システムの開発や維持に要する費用は，下図の赤線のように規模に対して指数的に増加します。このシステムによる利益は，青線と赤線の差（緑の部分）ですから，それが最大になる点が最適規模となります。
ところが，これを理解できない（しようとしない）バカは，マジメに自分が発見したbetter部分（実はbrtterにすらならない趣味的なものもある）事項までを実現することを主張し，ときには青線のグラフをことさらに上へ引き上げようと努力します。その結果，システム規模は極度に過剰になり限界規模を超えるようにもなります。このプロジェクトが失敗するのは確実です。
実はこのようなマジメ・バカの参加が，現行の情報システムを不必要に巨大化・複雑化しているのですし，使われない機能ばかりのシステムにしているのです。ＥＲＰパッケージの導入ではカスタマイズを極力抑えることが成功の秘訣であるといわれていますが，実はマジメバカの要求事項発見を阻止することができるのが最大の効果なのです。逆にいえば，このことを利用部門が認識していたら，あえてＥＲＰパッケージなどを導入しなくても，もっと安価で品質がよく，改訂にも柔軟に対応できるシステムが構築できるのです。
「わからない」ことへの弁護
ここで「利用者自身が何をしたいのか分かっていない」ことについて考えてみましょう。
例を流通システムにします。昔ならば，「いつ，何をどれだけ，どこからどこへ，どの輸送業者がどの輸送機関で」運んで「いくらかかったか」を正確に迅速に計算すれば十分でした。そのようなシステムならば，しかるべき人が参加すれば，仕様をまとめるのは比較的簡単です。
ところが現在のシステムでは，顧客満足とコストダウンを同時に実現するシステムが要求されます。しかも，単純な対策はすでに行われています。残されている課題は，ある部分を解決しようとすれば，他の部分に副作用が生じるし，それぞれの関係者の利害に影響するような性格のものですから，解決方法がわからないのは当然ですし，意見調整ができないのも当然だともいえます。
さらに，ここでの要求事項は，現在の要求ではなく将来のシステム稼動時での要求事項でなければなりません。経営環境は激変しています。現在の状況を過去に予測できなっかったから（誤った予測をしたから），システムを開発あるいは改訂しようとするのですから，おそらく将来の状況は予測できないと考えるのが妥当です。利用部門が真剣に要求事項を検討すればするほど，「何をしたいか分からな」くなるでしょう。これは経営者が参画しても解決しないでしょう。
すなわち，具体的には「利用者自身が何をしたいのか分かっていない」が，「顧客満足とコストダウンを同時に実現するシステム」を構築する必要があるのです。だからこそ「戦略的システム」なのであり，「経営戦略に合致した」システムなのです。このことを経営者自身が認識しなければなりません。それなのに，自分のことは棚にあげて，開発者側（情報システム部門）を非難するのは筋違いです。
情報検索系システムにおける利用部門の行動
本質的に要求定義が不明確なので，あまりにも利用部門の意見にがんじがらめになったシステムにすると，開発費用がかかるだけでなく，改訂が困難なシステムになってしまいます。
その一つの解決として，情報検索系システムを普及することにより，利用部門の多様な情報入手要求に応えながら，基幹業務系システムを簡素化することができます。
この場面でも，利用部門の「過剰体裁愛好症」や「情報システム部門への過度依存症」などがその普及を阻害しています。これらに関しては別シリーズ「ＥＵＣ（エンドユーザ・コンピューティング）の光と影」でとりあげています。
ここでは情報システム部門の開き直りのような利用部門批判をしましたが，これらは適切なＩＴガバナンスを実現できなかった情報システム部門の責任でもあります。それに関しては別章「情報システム部門はこれまで自部門をＤＰ部門化してきた」で検討します。