要件定義の成功に向けて

今日は業後、社内の要件定義の勉強会に参加した。
勉強会といっても、これから勉強会を始めるので
どんなことをしようか相談といった感じだった。

そこで、気付かされたことが何点か。

1つは仕事に対する心構えというか、プロ意識というか。
会社が何かを用意してくれてないからできないとか、
自分以外の××が△△だから、自分は困ったとか
それだけになってしまったら、自分が仕事する意味ないなと。

そうならないように、自分から仕事をしにいく、
仕事を作りにいくってならないと。
何かわからないことがあれば自分で勉強する。
一夜漬けでもよいから、何かを持って
それでお客さんのところに行く。

仕事で一夜漬けっていうのは自分の中で持っていなかった概念だった。
全然なかったわけじゃなくて、その言葉が思いついてなかっただけかもしれないけど、
意識してなかったということは、あまり積極的に使えてなかったのだと思う。
(決して一夜漬けがよいわけではないけど、必要なときはやらないといけない)

もう1つ、大きなというか気付いてはいたけど
あまり認めたくなかったこと。

それは、去年から手がけている仕事の一部に
自分として入り込めない、積極的になれないところがあったということ。

お客様のために、お客様の声をよく聞いて、
お客様の気持ちになって要件定義をしないといけないはずなのに、
お客様とはどちらかといえば対立関係になる部分があった。

対立関係になったのは、以下のブログで書いているような状況だから。
http://d.hatena.ne.jp/h_gomi/20080401/1207062099

自分がシステム作る側じゃなく、使う側になったとき、
お客様(=システムオーナー=隣の部)のそもそもの考え方、
そのシステムの位置づけ、意義などに疑問を感じていた。

そこで、自分の役割を分離しきれず
お客様と対立関係になり、システムのその部分は手を引きたい
できれば自分の手元から離したいと思っていた。

後ろ向きに中途半端に携わる、
それでは当たり前のように要件定義は失敗する。

このままでは、だめだ。

ひとまずエンドユーザの立場はおいておいて、
SIerとして、システムオーナーの身になって積極的にシステムを作る。

とはいえ、このプロジェクトの外で、
もしそんな社内の施策に対する注文があるなら、
どこか正々堂々と言う場を作るようにする。

両方中途半端じゃなくて、どっちもちゃんと向き合っていかないといけないんだ。

またくじけそうになることもありそうだけど、
そのときは今日の日記を思い出したい。