0480_開発案件の落とし穴

開発のスケジュールはなぜ遅れるのか?

開発の仕事をしていて、一番の悩みはスケジュールです。お客さんにとっては新規開発にしろ、機能開発にしろ開発内容は新規サービスの場合が多く、エンドユーザーにも告知している以上、絶対にスケジュールを譲れないのです。ですので、当然のことながら、予定通りリリースできないと大問題になってしまいます。

以前メーカーで営業をしていた時もスケジュール管理は大変だったのですが、基本的には試作から始めて段階的に量産にもっていくので、「もう無理だ!」ということはありませんでした。工場の方の懸命な異常な努力と調整によってなんとかなることが多かったです。しかし、開発の場合は少しわけが違います。開発案件は何かと予見予測できない要因が非常に多いです。

落とし穴が多い

開発の場合、数週間のバッファをもうけていても、何かの落とし穴にはまってしまうとバッファも一瞬で溶けてしまいます。プログラミングコードの落とし穴、ライブラリ・モジュールの依存関係の落とし穴、ロジック自体の落とし穴、運用の落とし穴、規約改定などの落とし穴などがあります。

こういった落とし穴は単純にリソースを投入して解決するものではありません。殆どの場合、そのシステムを熟知していて、原因を特定できるエンジニアが1名いれば一瞬で直る事が多いです。

落とし穴が多い理由

じゃあ、システムに熟知している人を1人用意すればいいじゃんと思いますが、それが難しいのです。作った人は往々にしてもういないのです。エンジニアは基本的に流動します。

人が足りないと言っているシステム会社は、作った人がいなくて困っているパターンが多いです。拡張性を考慮せずにシステムが作られ、いわゆるスパゲッティーコードのような状態から手をつけられないというのもよく聞きます。

また、今のシステムに至るまでに複数社のシステム会社を経てできたものや、複数の会社が作ったシステムを一個にがっちゃんこしたというものもあります。上記のような事情を考えると本当に落とし穴の要因が多いというのもおわかりいただけるかと思います。

そんなことは関係ない

が、しかし、お客さんからするとそんなこと関係ありません。「できないスケジュール組むなよ!」と言われるのです。「なんで解決できないんだ!?」となるのです。近年では、みずほ銀行のシステムが大きな問題を起こしていましたが、他人事ではないので、本当に笑えないです。

おっさん
■開発案件は難しい。

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA


日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)