プロジェクトサルベージ 1/20

 適当な名前が思いつかないので勝手にプロジェクトサルベージ って呼んでますが、ようは今まで自分がやってきた中でも、比較的大きめなプロジェクトは結構最初から無理だと思われていたり、受けたときに無理だと判断できるような場合が多いです。

  1. メーカーの仕事で新規商品開発、予算も商品イメージが曖昧だったため、こちらから提案を行う必要があった。
  2. 専用機用のソフトをPC上に移植する、プログラムは全面的に書き換える必要があったが、移植元のソフトの仕様が不明確だった(仕様書も当初作成していた担当者いない状態)
  3. 構造解析系のソフトで、専門業者に依頼したところ、2〜3億かかるといわれたソフトを2〜3千万で開発
  4. 基幹系業務ソフトの開発、業務フローがない、運用方法が不明確、そもそも運用するかどうかは担当部署の裁量 という話からはじまり、さらに最低3年かかるとみられるところを2年までの予算しかない

問題プロジェクトで主だったところをあげてみましたが、やはり問題は予算と要求仕様です。解決方法はそれぞれ

  1. メーカー担当者が実際は何をイメージしているか理解するまでで徹底的に話し合いを行い、その上で自分がなにをほしいのかを考えて提案を行った。さらに、プロトタイピングで開発途中でも動作を見せながら仕様変更をおこなっていった。
  2. 移植元のソフト開発の部署へ何度も足を運び、仕様書さがしをいっしょにおこない、顧客が重視している仕様を営業さんにもヒヤリングを行い、最低限納得できそうな仕様を作成し、仕様変更に対応できるように各種パラメータを持たせた。
  3. 顧客側と全面提携し、計算仕様と試験部分は顧客サイドがメインで行ってもらうことと、開発体制を新人君メインにし、プログラムは出来るだけ再利用可能な形で開発をおこなった。
  4. そもそもなぜそんな無理なスケジュールなのかを確認したところ、「退職者が一挙に増え従来の情報が消えてしまうので、その前に集めておく仕掛けが必要である」また、「業務フローがないのでシステムを導入させることで、逆に業務フローを作成しなければいけないような立場に追い込みたい」という2点がこのプロジェクトの隠された目的であるとのことだったので、この目的を達成するため無茶を承知で引き受けた

他にも細かい話はいろいろありますが、今回はここまで。