IT業界でプロとして活躍するには何が必要か。ダメな“システム屋”にならないためにはどうするべきか。“システム屋”歴30年を自任する筆者が経験者の立場から、ダメな“システム屋”の行動様式を辛口で指摘しつつ、そこからの脱却法を分かりやすく解説する。（毎週月曜日更新、編集：日経情報ストラテジー）
ユーザー企業への提案で悩む“システム屋”
先輩“システム屋” 「どうした？浮かない顔して」後輩“システム屋” 「あ、先輩！実は、ユーザー企業への提案書が通らないんですよ」
先輩 「というと？」
後輩 「前回もそうだったんですが、ユーザー企業の現場では高く評価された提案書なのに、ユーザー企業の幹部に上がった時に、通らないんです」
先輩 「どれどれ、その提案書、ちょっと見せてくれるかな」
後輩 「これです。かなり具体的ですし、自信作だったんですけど・・・」
先輩 「ふーむ、beforeとafterを比較して、課題解決策を示したわけだね」
後輩 「はい」
先輩 「この提案書、ユーザー企業の現場部門しか出て来ないね。事業全体の中でこの現場の課題を位置づけた説明はないのかな？」
後輩 「あ、それは抜けているかもしれないですね」
先輩 「短期的なbeforeとafterは良いのだけど、長期的な経緯や、将来の方向性の説明もないのかな？」
後輩 「ないかもしれません」
先輩 「絵はたくさんあるけど、『問題点の拡大図』『ある日の出来事のようなエピソード』も欠けているようだね」
後輩 「はい。そうかもしれません」
先輩 「問題点に気づいたかな？」
後輩 「いや、まだはっきりとは・・・」
先輩 「この提案書の中の時間と空間は、かなり限定されたものだよね？」
後輩 「・・・」
先輩 「広範囲を見渡した図がないから課題の相対的重要性が見えにくく、拡大図がないから現実性に訴えるところも弱いんじゃないかな」
後輩 「全然ダメですか？」
先輩 「いや、そんなことはないよ。ちょっとした工夫なんだ。じゃ、最初からおさらいしてみようか」
後輩 「はい！」
ダメな理由：スコープに柔軟性がない
前回（第25回）は「なぜ」を考えない“システム屋”の話は面白くないと書きました。今回は登場する後輩“システム屋”は、まじめで真剣に考えているにもかかわらず、提案書が評価されないようです。これはどうしてなのでしょうか。
ユーザー企業の現場担当者から高く評価された提案書が、その上の幹部レベルではあまり評価されないということはよくあります。「ユーザー企業の責任だ」と言ってしまえば簡単ですが、そう言ってしまった途端、“システム屋”は成長機会を自ら捨てることになります。
ユーザー企業の現場は、とにかく目の前の業務効率を上げたり、ミスをなくしたりと、課題を解決したい気持ちでいっぱいです。その気持ちが“システム屋”にも乗り移り、ついつい現場と同じ立場に立ってしまいがちです。
