お客さま先の情シスの新規メンバーへの教育、自分の再確認のためになると思い、開発における失敗について
書いてみます。
■システム開発の失敗とは
——————————————————————————————-
大きく分けると、
・休日稼働を視野に入れて開発スケジュールを立てても完成の見通しが立たない
・開発チームに欠員が出てしまい、エンジニアの不足が続いている
・予算不足に伴いシステムに必要な機能が搭載できない
また、開発側が意図を理解しないまま仕様を決めてしまい、結果として発注者の意図をまったく汲んでいない
成果物が完成した場合も失敗となると考えます。
そこで、失敗を招かないよう、事前にリスクを考えておく必要があります。
・認識的リスク：受注側と開発側で認識がズレたまま開発が進むリスク
・金銭的リスク：開発の途中で予算が不足してしまうリスク
・技術的リスク：技術的に機能の実装が難しくなるリスク
●認識的リスク
システム開発における大きな壁は、コミュニケーションギャップによる「勘違い」のリスクです。
失敗時のダメージが大きいので、優先して回避すべきリスクだと考えます。
●金銭的リスク
システム開発でトラブルになりやすいのが、開発費の算出です。
システム開発は「まったく新しいものを作る」という特性上、正確な費用を割り出すのが難しいです。
詳細が決まらない状態で開発費を算出しないようにすべきだと考えます。
●技術的リスク
企画段階では開発可能に思われても、技術的に実装が困難なケースに直面することがあります。
開発中に「実装が困難」と判断された場合、クライアントと交渉をして機能を調整する必要があります。
プロジェクト失敗の多くは特に「認識的リスク」を回避しなかったことに起因していると考えます。
根底にあるのはコミュニケーション不足だと考えます。
・目的が曖昧なままシステム開発をスタートさせた。
・プロジェクトの軸となる認識が不統一だった。
・工程の優先順位が曖昧だった。
・見積もりが不明瞭だった。
■コミュニケーション不足によるシステム開発の失敗
——————————————————————————————-
実際の失敗例として、「成果物に対して大幅な修正を余儀なくされた」ということがあります。
期日通りにシステムを受け取ったクライアントから「まともに動かない」というクレームが入ってしまう
ケースです。
この場合、システムの「作り直し」を余儀なくされます。たとえ納期どおりに完遂してもシステムの
パフォーマンスが理想とかけ離れているとクレームへと発展しやすく、追加工数が発生してしまいます。
原因としては、
・1つ目は発注側の問題で「開発知識がなく、希望を伝える努力を怠った」こと。
・2つ目は開発側の問題で「希望を鵜呑みにし、確認しないまま実装した」したことです。
「こちらが言わなくても知識があるなら察してほしい」という思いで、希望や妥協点を詳細に伝える努力を
しなかった。
希望を鵜呑みにし、言われるがままに確認しないまま実装した。「希望」は「命令」ではありません。
■システム開発を成功させるためには
——————————————————————————————-
お互いの思いをぶつけ、擦り合わせ、妥協点を見つけていくことが大事だと考えます。
意識してコミュニケーションの量を増やすことが重要だと考えます。
相手が言ったことを理解できているか、図を用いたり、自分の言葉でまとめ、先方に見てもらい、
認識にズレがないか確認することが重要だと考えます。
そして、発注側の経営者や現場で使う人が満足するものを作り、感謝されたいものです。
入会申込
ログイン
