システム開発によくある失敗はなぜ繰り返し起こるのだろう？

現在進行形の案件をリリースしてただいま本番走行確認まっしぐらなカツオです。仕事がなかなか収まりきらずいつトラブルの電話が鳴るかと戦々恐々とする日々を送っております。

毎日が多忙で息つく間もなく次の案件の見積もり依頼がきました。次の案件の見積もり依頼がきました。

通例なら案件と案件の間には若干のゆとりが発生するので中型の連休を作って旅行にいくのが習慣だったのですが今回は上手くいかなさそう。。。

すでにリリースしている案件の品質が非常に低いため、対応を常に要求されいる現状が続いてる。

そこでチームとして振り返りを要求されたのでいい機会なので自分なりにも整理して原因を追求したいと思いました。

どのような問題点が多発したのか

今回の案件については客先との交渉の時点からまずかった。いったん決めてかかったことを仕様書に書き落とさず工数がなかったためすべてプログラムを作成して先行製造してしまったことから失敗した。

問題点①：仕様のコミットが定まらず質問しても回答が遅いため開発先行してものを先に作っていった。だが出力したものに対して確認を行う約束はするものの返答は遅いうえに何かと細かな要求を返してきて相当な労力を使った。

反省点：システム開発はゴールを設定しなければいけないことを痛感した。すなわち仕様の固まっていないのは泥んこ遊びしてるのと一緒で練ろうが捏ねようが固まるわけがない。ここはもっとクライアントに食らいついてでも仕様回答をもっと要求するべきだった。

問題点②：タイトなスケジュールが続くもリーダーである自分が仕様固めに奔走してしまいメンバーが作業に行き詰まっているもヘルプすることもできずに無駄な時間（仕様回答待ち、レビュ待ちなど）が多発してしまい、待つ側も待たされる側もストレスとなることが多かった。

反省点：仕様回答については課題表作成や質問票などそのままクライアントにスムーズに確認できるような仕組みづくりを先にやっておくべきだった。個々が口頭で質問したり、そもそもの質問がなんなのかわからずに聞くだけ聞いて結局何？っという時間もかなりできてしまった。

問題点③：要件定義をクライアントにできるメンバーが自分しかいないことのもう一つの問題として、開発メンバーの仕様伝達が極端に鈍化していた。また設計者、製造者と今回は別れて開発していたが設計者はプログラマからまだ仕様検討などできるスキルになっていないメンバーが設計をしたことで仕様考慮漏れが多発する羽目になった。

反省点：今回はどうしてもスキルおよび業務に対する知識が少ないメンバーで設計することとなったのだが仕様の理解、どのように試験を実施するかのイメージを持たせながら開発するような方針で時間をかけてもよいのでやるべきだった。※開発スタート当初からスケジュールがタイトであることからはじめから焦りがでておりレビュが手薄なままリリースしていることも重大な問題点

問題は収まらないのか？

今回はタイトなスケジュールということからスタートしており全てを軽く薄くレビュしてしまったことがそもそもまずかった。

要するにメンバーが少しでも仕様がわからない素振りを見せればそれはもう警告のサインであり、任せてはいけない状況になっていることを悟るべきだった。

もっと言えばコミュニケーションの取り方、方法をもっと模索することに力を使いたかった。メンバーはひっきりなしに質問してくるのだけれどそれをすべてリアルタイムで受け答えしており結果的に答えはクライアント聞くのが早い事案でも無駄な打ち合わせを内部でやったり自分たちで答えを出そうとしたり、正直に言うと正気ではなかった。

問題の収まりどころをつけるならばどの状況においてもシンプルに問題を切り出し、仕様決済のできる相手にもっていって相談し即回答を求めるようにするか質問自体は手持ちにせず、相手に常にボールを渡した状態を保つことが大事だった。

まとめ

今回を通して自分で学べたことは開発のスケジュールがどうであろうと基本原則である「目的を知り、何をどのようにアウトプットするか」その結果を確認し合う作業を怠らずどの工程であっても相互に理解しながら工程を進めていくことをしっかりやっておけばもう少しマシな開発になったのではないだろうかと思う。

こちらのブログも合わせてどうぞ↓↓

パパエンジニアの野望