まりぴよこのブログ

日々の日記。技術ネタでまとまりきってないものの記録、伝わる文章の書き方を練習とか。

間違っているのはビジネスモデルなんじゃないか

典型的ダメダメプロジェクトに対する思い(グダグダ)

最初にグダグダを書くのもどうかと思いますが・・

  • 1年開発が続いても顧客の欲しいものができてない
  • 私の立ち位置:末端の開発会社、最終的に動くものを作るプログラマの位置
  • 要求定義する別会社のSEさんが間に入っている
  • 間のSEさんが顧客の「いつ出来るの!?」に答えきれなくなった結果、1年経って初めて顧客に会った
  • 今すぐ欲しいもの聞いた。全然時間ない・・(←今ココ)

情報伝達

  • お客さん:○○を△△してここにばーんとぼーんと!
  • 間のSEさん:わかりました。そう伝えます!
  • 現場:それだと、×××の場合、どうします?どうしようも無くないですか?あと、それを実現すると3ヶ月前に作った部分に影響が出ます。大丈夫ですか?
  • 間のSEさん:・・・・大丈夫です。この機能は・・えーっと・・□□用のプロジェクトにしか使いませんから。×××は・・・持ち帰ります。(その後×××に対する回答は戻ってこない)

いろんな機能で×××ペンディング、が相次ぎ、現場で勝手に仮説を立てて進める。 間のSEさんは目の前の状況に翻弄されているので、次々忘却される×××達・・

(月日流れ・・)

  • お客さん:いつできんの〜〜!
  • 現場:いつ終わるの〜〜!
  • 間のSEさん:きゅーーーxxx

私たちは敵対したい訳ではない。。一緒に問題を解決したい・・

システム開発の難しさ

成功する要求仕様 失敗する要求仕様

成功する要求仕様 失敗する要求仕様

  • システム開発を進めると、必ず要求は変化する
  • 要求を満たせば満たすほど、顧客は新たな要求を思い出すもの
  • 新たな要求が出たということは、現在のシステムが実際のニーズを満たしているから(むしろ喜ぶべきこと)

何故開発者(我々)は要求が変化することを嫌がるのか

  • 要求が変化しても、締め切りは変化しないから
  • 締め切りが変化しないのは、締め切って、納品しないとお金が発生しないから
  • 一定のお金と決まっているプロジェクトを、長くやればやるほどもうけがなくなるから

何故顧客は要求が変化してもスケジュールを変更しないのか

  • 納品されないとシステムが使えないから
  • 使えないものを作っている期間(顧客は利益を受けていない)のにお金を払いたくないから

変えるには・・?

  • その時点の要求に沿ったものが顧客の手に都度届いて使える→顧客ハッピー
  • 顧客の要望をどんどん叶えて、欲しいシステムを継続的に渡せば、ずっとお金が入る→開発者ハッピー

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

そういうものにわたしはなりたい。。