ついに連休も終わりました。
新型インフルエンザ、高速道路渋滞などの影響で出掛けるのにも躊躇することが多く、今回の連休はおとなしく過ごしました。
遊びすぎなかった連休というのも、体調だけでなく精神的にもいいものだと実感しました。
さて、連休前に私が出した質問、覚えていらっしゃるでしょうか。
システム開発を行う場合の工程別のコストの割合についてです。
今の私自身の考えは
1）客先での打ち合わせと外部設計 20
2）内部設計 20
3）開発（プログラム作成とテスト） 50
4）納品 10
ということもお話しました。
本当に残念というか・・・仕方がないというか、開発の比重が大きくなることが気になります。
開発の比重を小さくするためには、今や開発部分を切り分けてオフショアして単価を下げることが当たり前なんですね。
しかし、オフショアもいつまでも単価が安いままが続くのでしょうか？
安いというのは、日本が他のアジア諸国に比べて先進諸国であるという理由だけで感じる相対的物差しのはずです。
システム会社としては、この内訳の比率の意味を理解し、常に見直すことが必要です。
私の経験からお話しましょう。
出来の悪い、もしくは進捗がうまくいっていないシステム開発があるとします。あくまでも仮定ですが。
こういったシステム開発の場合、目に見えてわかることがあります。
外部設計、内部設計、開発、納品が工期としてダブることが多いのです。
ひどい場合には、隣り合わせの工程がダブるだけでなく、仕様が戻ってしまい、「 1）客先での打ち合わせと外部設計」と「 3）開発」が同時に行われていたりするのです。
理想の開発では、1）→ 2）→ 3）→ 4）と順番に進むものが、「 3）開発」の段階で未だ 1）のヒアリングが終わっていなかったりするのです。
それは、開発途中で、ユーザー企業のおかれている状況が変わり、否応なしに仕様修正が入るということもあるかもしれません。
しかし、もともとの仕様を開発側とユーザー側でしっかり確認していなかったために「 4）納品」になってから発覚したという場合があります。
これが最悪のパターンです。
しかも、ウォーターフロー開発の場合開発途中で誰かが気づくということが非常に少ないのです。
また、開発途中で気がついたとすると、開発期間が延長になってしまいます。
開発期間は、その期間だけ人員増加することが常識ですので長期戦に持ち込むことが、そのままコスト高の理由になってしまうのです。
そこで、プロマネの重要性や上流工程の価値が再評価されるのですね。
やり直しが許されるのであれば、開発に入る前までをやり直したいとシステム会社が思うのは当然のことといえます。
ただ、私個人としては、もっともっと開発のコスト率を下げる方法が他にあるのではないかと思っているのです。
Vol.00190