次はIT産業の受託における開発手法を考えてみましょう。
お客さんから開発依頼があるとシステムエンジニアが出向き、開発要件をヒアリングします。そして見積を作成して金額やスケジュールをお客さんと相談します。
話がまとまれば開発となる訳ですが、今までは詳細なヒアリングを行って仕様書を作成しました。紙ベースの仕様書をお客さんに見せて確認をいただき、それからひたすらプログラミング。そうです、ソフト開発を行いました。そして完成間近になってからお客さんに操作してもらって不具合がないか最終調整をします。
この流れはある程度こなれた業務ソフトなら問題が起きないのですが、お客さんも完成イメージができないWebアプリケーションとなると、完成間近に見せられても揚げ足を取る材料にしかなりません。
これではトラブルになり、使えないシステムと成り下がります。
そう、イノベーションの時代には開発手法も見直さないといけないのです。
今までの開発手法はウォーターフォール型と言って、分析・設計・実装・テスト・運用と行程を明確に分けて行程毎に進めていきます。ある程度、完成しないとお客さんは評価することができません。また、お客さんとの完成イメージが異なった場合は最初の行程まで戻ることがあります。この場合、最初にスケジュールが決まっていますので、徹夜の突貫工事に突入しないよう、システムエンジニアは必死の説得をします。
開発案件にも寄りますが、ウォーターフォール型はとても楽しく開発して使ってもらう可能性が低そうですね。コンピュータが好きだから開発をしている人達は避けたい開発手法ではないでしょうか。
次は楽しく開発して使ってもらう人に喜んでもらう。これにはどうするかです。
0 件のコメント:
コメントを投稿