The Dragon Scroll

Be just and fear not.

この旗を倒したのは誰だ?

SI企業は、請負開発の場合、顧客から案件を受注し、人月ベースで
見積もりを行い、開発を行っていく。
当然、原価を抑えることができたら、その分収益は増える。
如何にして、原価低減を行うかが、肝になる。
開発のコストは、ほぼ人件費である。
そのため、コストを抑えるために、自前のリソースを使うのではなく
外部からの調達を行う。開発企業からの要員の調達、派遣社員
あるいは、オフショアの利用。
もっと言えば、外部へ丸投げしてしまえばいい。
自分たちは作る必要すらない。
だから、システムエンジニアを新卒で採用するときに、
"スキルの有り無しなんて、どっちかというとどうでもいい"という
乱暴な説明がなされるわけだ。
実際、私が就職活動していた頃からこのフレーズはよく聞いた。


一方で、発注者も開発側と同じようなことを考える。
最初の見積もりの合意から、如何にして、開発側に余分な
作りこみを行わせるかが肝になる。
だから、開発の現場では、開発側のプロジェクトリーダーと、
発注側の情報システム部門の担当者の間で、駆け引きが
毎日のように行われる。
お互いが持つ下心が、両者に対立軸を与える。
この駆け引き、交渉に注がれる労力たるや、自分が
エンジニアであることを忘れるのには十分なものである。


しかし、こんなことが本当に、やりたいのだろうか?
こんなことをやる必要があるのか?
答えは否だ。


システム開発をやりたいのか?開発のコスト削減をやりたいのか?
目的はいったい何なのか。
発注者も開発者も、価値を生み出すシステム
作り上げることが、共通の目的のはずだ。
システム開発という経営計画の一環である施策に対して
なぜか別の目的も盛りこんでしまっているだけの話ではないか。
最初に決めた大きな目的に、果たしてそれは必要な観点なのだろうか。
コスト削減は最初に決める枠で実現するべきではないのか。
それに対して、開発側ができるかできないかというジャッジする
だけの話ではないか。


砂山に立てた旗が倒れないように、砂をお互いがかき集めて
自陣に沢山の砂をあつめた方が勝ち、というゲームがあるが、
SIerと発注者は、これと同じ状況下で開発を行ってきた。
程度の差はあれ、どのようなプロジェクトでも本質は
変わらないだろう。
私は、二度とこんなゲームをやりたいと思わない。
旗が倒れたら、結局、両者とも負けなのだ。
この旗が倒れないためにはどうすればよいかを
一緒に考えるプロジェクトをやるんだ。