＞　普段からユーザ要望のあるシステム開発を
昔は私もそうでした　今はパッケージソフトになってしまったのでやっていませんが．．
自前のシステムでは何をどのように組むかは自分で決めることになります　そのときに基本は「ユーザのためになること」ですが、ユーザは必ずしも「自分にとってよいシステムはこういうものだ」ということは言ってくれません　そこでシステム屋が「こういうのがよいシステムだ」と提案することになります　この提案が「攻めの開発」になります。
「攻めの開発」をするためには日ごろから時間を作って「こういう仕組みはどうだろう」と研究してきました。
ウチのような中規模の製造会社では相反する条件が多くあります　中途半端に多い生産数のため、量産効果は出にくいが、希少価値もないため価格を上げられないですし、部品・材料の手配も長い手番のものが多く、でも生産計画はそんなに先までないので見込みで発注することになり、在庫管理に気を使います。
それまでは手作業でやっていましたが、それを「各種のパラメータにして６か月先までの生産計画（予想）を作り出して長手番のものまで確定注文書を出す　が引き当て状態を一目で見れるようにして、ＭＲＰを頻繁に回して、在庫・注文の過不足を補う」というシステムを作りました。
これが「攻めのシステム」といえるのではないかと思います
システムができるとユーザからの要望も具体的に出てきますが、自前システムなのですぐに取り入れることができました。　その結果、かなりよいシステムになったと思います

次にやったのが営業のシステム
”コンピュータ上で条件をみんな入れて管理、表示してしまおう”というコンセプトを前述のシステムからひきついで
・営業が”受注しそうだ”という情報を入れる
・受注したら”確定した”と入力する
・在庫があれば指定日に出荷する
・在庫がなければ生産計画から出荷予定日を算出する
・種々の出荷の形態に対応できる体制をとった（まとめて・個別に・全部揃ったら・．．．）
・それらを画面ですぐにわかる状態にした
これも自前なのでユーザの要望も取り入れよいシステムができました
これを作るまで営業マンは「受注前情報が知りたい」とか「出荷の指示を自動でやりたい」とは誰も言いませんでしたからこれも「攻めのシステム」と言っていいでしょう

情シスというのは特定の部門に属すわけでなく、会社を俯瞰的にみる立場が可能だと思います。そういう視点（全体最適/個別最適の選択など戦略を考えるような）でのアプローチが攻めかなと思ってます。

例えばアプリ開発であれば、特定の部門の事だけを考えなく会社全体の物/金の流れ、ISMSの観点やセキュリティ、他システム連携などを考えるなどが該当するかと

当然アプリ開発はコストを負担する部署にメリットがないとおかしな事になりますが、それでも全体のビジネスを考えると調整をしないといけなケースが多々あるわけで、もっというと全社企画みたいな場合は、利益を削って開発する為何が目的なのか明確にするアプローチが必要だったり、そもそもコスト負担はどこがすべきかという議論から始まるケースもあります。

そして、攻めの情シスとはそういったプロセスやアプローチを整備するのがそもそもでは無いかとも思います。なので日々の業務改善か手順化、効率化みたいな些細なことも攻めだと思います。

なのでアプリ開発自体が攻めではなく、アプリ開発/運用を含めよいプロセスが回るように整備していくのが攻めではないかと考えています。

ご意見ありがとうございます。
「開発」もやり方によっては十分な攻めになるということがわかりました。
「アプリ開発/運用を含めよいプロセスが回るように整備していくのが攻め」というのも納得です。
大変参考になりました。