今時の開発は企画に足を踏み込み過ぎている
逆に言えば、企画が仕事をしていない。これでは将来はないなと思ったのは、某所で企画部門の人が、
『編集業なんですよ。ベンダ（含む情報子会社）に資料を作らせてステープルするのが仕事』
と言っているのを耳に挟んだとき。この人は将来ないだろうし、ベンダとしてもそこそこ付き合いやすい（数字のロジックを擦り合わせて毎年提案できれば）のだろうな、と。
ところで『アジャイルソフトウェア宣言』と『アジャイル宣言の背後にある原則』を読み返すと、強調しようとか一緒に働こうと言っている。
契約交渉よりも顧客との協調を、
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
最近（前からか）エンジニアの開発手法の１つに過ぎないのに、ビジネスに持ち込もうとしているのはどうしてなのだろうか。
事業者の立場で仕事をした経験がある人であれば（それがエンジニアであっても）、事業そのものが不確実性の中での仕事であるし、計画は立てるがいくらリスクマネジメントをしても識別しきれないリスクが突発的に起きるので臨機応変に対応することになる。結果、自然と俊敏に対応せざるを得ない。嫌な言い方をすれば事後対処ではあるが、何分、リスクを識別できない時点でその手段しか残されていない。
もちろん、中期計画などので事業目標を公開しているとトップマネジメントからの圧力は首に掛かってくるので計画に柔軟性は無いように思えるが、実現可能な（willとして、少しストレッチするテーマを忍ばせておく）計画づくりをしておくのも企画部門としての生存戦略である。
実務では内製化するか外注業者に出すかはリソースの問題で、内製化したとしても自組織でなければ工数の壁（外注業者なら契約として）は存在するし、同じ組織であっても予算とリソースの取り合いをするから資源の追加は容易ではない。つまり、固定化しやすい。リソースの観点で言えば、企画部門は兼務が多い（運用している事業と新規事業の立ち上げなど）ため、ますますリソース不足を自ら招いているのも現状である（褒められた環境では無い）。
ただ、上手にやっているところは従来からそれなりに乗り切っているので、企画部門の担当者の仕事のスタイルや組織に根ざしている文化に寄るところが大きいのだろう。
ところで、ウォーターフォールでもそれなりにやってきているプロジェクトが存在するのは、あくまでもそれはシステム開発手法としての１つのフレームワークとして、道具として使えているからであって、その手法を神様として見ているわけでは無い。ウォーターフォールもアジャイル開発もこうしなければいけないというステップバイステップのプロシージャがこと細かく決められているわけでは無い。
＃ウォーターフォールでそんなもの見たことないのだが、勉強不足であれば後学のため教えて欲しい。
概念しかないものをそれっぽく導入するとどうなるかは想像に難くない。本質を理解できず、都合よく解釈され、周りにいるものがその割りを食う。前述のステープルな企画担当は、アジャイルだから柔軟にやってくれと碌に要件をズルズルと先延ばししてくるだろうからいいことは微塵もない。
本来、アジャイルに仕事をしているのが事業会社側で（そうれはそうである。システム開発は業務の一部を自動機械化しているだけに過ぎないのだから）、事業会社側の意思決定の速度が速くなったから、それに合わせらせる道具で機械化しよう、というだけでの話である。
シンプルに企画部門が事業を小さく、早く意思決定すればだいぶ変わると思うし、やるところはやっているし、やれていないところにそれをやろうと近づいてもソフトウェア開発者は部分を手伝うしかできないのだから、ストレスしか得られないのではないか（エンジニアを犠牲にして商売はできるだろうが）。
