続 atsushifxの七転八倒

ウツ、発達障害の闘病記とIT関係のつれずれを書いていきます

要求をマネジメントする

デフォルメしまくってますけど、客先に常駐して直接実際に使うユーザにヒヤリングして開発までやってきた立場でいうと、ありがち、って感じですね。いや、ほげ君同情するよ、マジで。昔の俺なら机蹴っ飛ばしてるね。このクソ上司!ってなもんでしょう。すんまそん(^^; 誤解しないで欲しいのは、アジャイルプロセスを揶揄するつもりは全くありません。あ、あと、大阪人はこんなにえげつなくないです(w それはさておき、このような状況を解決するには、私がオンサイト顧客になるんですか? ってことになっちゃいかねないな、と。そんな暇ないです。で、この流れの中で、「顧客とは誰か?」「要件とは何か?」ってことが、問題意識にになるわけです。私が欲しいのは、人件費を3分の1にできる契約管理の仕組みです。その私の思いをほげ君が正確に把握しない限り、

そう、そのとおり。
というか、この部分がソフトウェア開発で一番問題になっている部分じゃないでしょうか?
日経コンピュータ 2/23号にも書いてありましたけど、はやりのプロジェクトマネジメントをいれても失敗プロジェクトが増えているそうですし、問題は開発フェーズじゃないんでしょう。

そういう意味で、

◆プロジェクトマネジメントにおける営業マネジメントの重要性 プロジェクトマネジメントの中で、  プロジェクトが始まっている前に結果が決まっているというをよく聞く。例えば、受注の際に無理をして受注し、低価格で受注した案件で、いくら(外注)調達マネジメントをうまくやっても結果は見えている、どんな要求でも受けますといって受注してきた案件でいくらスコープマネジメントを一生懸命にやってみても結果は見えているなど、例は枚挙にいとまがない。 しかし、PMBOK流のプロジェクトマネジメントを導入したプロジェクトがレッスンズラーンドを行ってみてもこの部分は「営業に伝える」という一言で済ましてしまうことが多い。せいぜい、開発部の部長から営業部に申し入れをしてもらうといったことで終わるケースが多い。 この問題を本質的に解決するには、営業マネジメントにプロジェクトマネジメントの考え方を導入し、開発マネジメントとの整合性を図っていくしかない。具体的な方法としてはスコープの拡張でもよいし、プログラムマネジメントのような考え方を導入し、アカウントベースでプロジェクトを管理していくのでもよい。他にも方法はあるかもしれない。いずれにしても、開発プロジェクトマネジメントとの連携が不可欠だ。

に結構期待してたり。