僕の日記をお気に入りにして頂いている方の中でも、SE・プログラマーと呼ばれる職種の方が多くいらっしゃいます。
その方々の日記でも垣間見えるとおり、システム開発にはその開発工程に応じて様々な方が携わる訳ですが、その役割同士は非常に軋轢が生じやすい構図が存在します。
特に営業・開発・運用という見方でそれを俯瞰するとその軋轢が顕著になります。
営業の意見
「開発のやつらはさー、2言目には『技術的に難しい』だの『工数が膨らむ』だの言いやがるじゃん。もっと大きな目線でお客様の成功を考えて欲しいよな。俺たちが仕事取って来てるんだから仕事できるって事を解ってないよなー。」
開発者の意見
「営業は(お客様に)夢見させすぎだよ。技術も知らないくせに無理いうなって。安定稼動するシステム作る為には、それなりに要件を満たす以上の工数がかかるっていうのに…。『出来るか?』じゃなくて、やれるだけの金を持って来いよな、値引きばっかりしてないでさ。」
運用者の意見
「開発は作りっぱなしでいいけどさ、メンテナンスする身にもなってみろよ。ろくに仕様書も作らないで、挙句にシステムはバグだらけかよ。それを始末するのは誰だと思ってんだよ。24時間稼動?俺らはロボットじゃねえんだよ。」
システムも車と同じようにProduct Lifecycleが存在します。当然その各ステージ毎に担当者が居て責務を全うする事で、システムが初めて安定稼動するのです。逆にこういう状態が起こるのは、
?責務の範囲が明確でない(業務の完了基準が明確でない)
?それぞれの立場での(成功と定義されたマイルストーン到達の)チェックポイントが明確でない
?コミュニケーションが上手く取れていない
という辺りが主要因となっているようです。
システムに携わる会社は大抵この担当者が別の部署に居る事が多く、?は非常に難しい問題といわざるを得ません。しかし、?・?に関して言えば、「共通言語」の確立と、明確な権限責務の定義は急務であるといえるでしょう。
うちの会社はおおむね、その辺に関しては良好な関係を保てる体制と方法論を備えているのですが、やはりこの構図から抜ける事の出来るレベルまでは至っていません。
しかし、それを最小化するべく、外部設計レベルから運用担当者を交えて定期レビューを実施する等、自分のレベルで出来る範囲の事を心がけています。
こんな人も居ますので、アプリ側の人をいぢめないでくださいね(笑)
その方々の日記でも垣間見えるとおり、システム開発にはその開発工程に応じて様々な方が携わる訳ですが、その役割同士は非常に軋轢が生じやすい構図が存在します。
特に営業・開発・運用という見方でそれを俯瞰するとその軋轢が顕著になります。
営業の意見
「開発のやつらはさー、2言目には『技術的に難しい』だの『工数が膨らむ』だの言いやがるじゃん。もっと大きな目線でお客様の成功を考えて欲しいよな。俺たちが仕事取って来てるんだから仕事できるって事を解ってないよなー。」
開発者の意見
「営業は(お客様に)夢見させすぎだよ。技術も知らないくせに無理いうなって。安定稼動するシステム作る為には、それなりに要件を満たす以上の工数がかかるっていうのに…。『出来るか?』じゃなくて、やれるだけの金を持って来いよな、値引きばっかりしてないでさ。」
運用者の意見
「開発は作りっぱなしでいいけどさ、メンテナンスする身にもなってみろよ。ろくに仕様書も作らないで、挙句にシステムはバグだらけかよ。それを始末するのは誰だと思ってんだよ。24時間稼動?俺らはロボットじゃねえんだよ。」
システムも車と同じようにProduct Lifecycleが存在します。当然その各ステージ毎に担当者が居て責務を全うする事で、システムが初めて安定稼動するのです。逆にこういう状態が起こるのは、
?責務の範囲が明確でない(業務の完了基準が明確でない)
?それぞれの立場での(成功と定義されたマイルストーン到達の)チェックポイントが明確でない
?コミュニケーションが上手く取れていない
という辺りが主要因となっているようです。
システムに携わる会社は大抵この担当者が別の部署に居る事が多く、?は非常に難しい問題といわざるを得ません。しかし、?・?に関して言えば、「共通言語」の確立と、明確な権限責務の定義は急務であるといえるでしょう。
うちの会社はおおむね、その辺に関しては良好な関係を保てる体制と方法論を備えているのですが、やはりこの構図から抜ける事の出来るレベルまでは至っていません。
しかし、それを最小化するべく、外部設計レベルから運用担当者を交えて定期レビューを実施する等、自分のレベルで出来る範囲の事を心がけています。
こんな人も居ますので、アプリ側の人をいぢめないでくださいね(笑)
コメント