読者です 読者をやめる 読者になる 読者になる

アーキテクチャをスマートに。

株式会社ネオジニア代表。ITアーキテクトとしてのお仕事や考えていることなどをたまに綴っています。(記事の内容は個人の見解に基づくものであり、所属組織を代表するものではありません)

「工数をもらう」ってよく聞くけど(2)

考え方

「工数をもらう」という表現の裏にある意識

さて、「工数をもらう」とはどういうことか、改めて考えてみる。

「工数をもらう」を、もっともっと具体的に言うと、

顧客都合の仕様変更や要望対応により、エンジニアが作業した時間に応じて、かかったコストを計算し、顧客(または親請け会社)に対価を請求する

という意味だ。

その発想がそもそも間違っている。

要するにこれは、現場のエンジニア自身が、自分たちの作業した時間を売っているということに他ならない。

あなたが一生懸命に努力し、他の人よりも短い工数で多くの仕事を終わらせるほど、「工数をもらえない」のですよ。

誰がどう考えたっておかしい。

では正しい考え方は?

情報システムの価格を「ユーザにとっての価値」で考えるとは、どういうことか。

顧客にとって情報システムは、いまや単なる業務効率化ツールではなく、ビジネスを展開していく上での重要なソリューションへと進化してきている。

例えば、仕様変更やバージョンアップによって情報システムを改変するということは、「顧客にとってのITの価値」をアップさせるということであり、それは顧客にとってコストダウンや売り上げ増加につながるはずだ。

エンジニアは、その「顧客にとってのITの価値」に対する費用をもらう、という考え方に改めるべきだ。

このままでは、一生懸命に少ない工数で仕事をこなしてきた “あなた” がかわいそうだ。

工数がいくらかかるかは、エンジニアの腕次第。

エンジニアは、工数を出来るだけ減らすべく最大限の努力を尽くす。

工数がいくらかかったかは、開発会社の社内管理上必要なだけであって、顧客には全く関係ない。

顧客は、開発工数を参考にするのはよいが、それに対して支払うのではく、成果物を見て対価を支払う。
もっとわかりやすく、誤解を恐れずに言うならば、顧客売り上げ増加量の何%とか、削減できたコストの何%とか。ビジネス戦略上のIT投資の価値をベースに考えるとか。そういうイメージ。


このことに、僕はやっと気づいた。


僕たちに出来ること

そうは言っても、この業界はいきなり変わらないです。
いろいろな大人の事情もあり、なかなか変えられないこともあります。

人月見積もりの問題は、ユーザ企業とITベンダー、双方の理解がなければ解決しません。
それどころか、問題認識すらされておらず、いままでやってきているのです。

では、我々が出来ることは何でしょうか?

まずは現場のエンジニア達がこのことを理解し、問題を認識することです。
そして現場からの声をもっとあげていくべきです。

いきなりは変わらないけど、ユーザ企業にも少しずつ理解が広まりつつあり、変わっていきています。
今こそエンジニアの意識改革を!


僕はこんな風に考えています。