【No.65】実績のない機能要件に対する開発の失敗例

こんにちは。

今回、2度目のプロマネ日誌を書かせていただきます、
t.h.です。

1回目は私が初めてPLとして一つのプロジェクトの管理を実施した時のエピソードを書きました。
今回は私自身がマネジメントしていたわけではありませんが、サブリーダとして大きな失敗をした時の話です。

１．プロジェクトの概要

要件の概要

法人向けのISPサービスは相対取引が多く、ほぼ取引単位でサービス要件を決めている。しかし、取引単位でアプリに改修をかけることはできないため、画面項目やデータベースの管理項目をテーブル定義して動的に規定できるようにしてほしい。

設計方針

サービスの内容そのものが顧客とエンドユーザ間の契約単位に決定され、契約毎に管理する項目や数、選択肢が異なる。
しかし、要件の概要にあるように契約発生に伴うシステムの改修は実施しないという要件のため、下記のような設計方針とした。

• VBで定義できる画面Control属性をテーブルに持たせ、項目属性を動的に定義可能とする。
• 項目の繰り返し数は可変として、こちらもテーブル定義可能とする。
• 項目名もテーブルで規定可能とする。
• 画面項目に対するチェック処理は、基本的なものはテーブルで規定するが、複雑なものは必要な都度OCXとして開発し、オブジェクトとして動的に取り込み可能とする。

２．発生した問題

開発状況

• 画面コントロールの入力制御や入力チェック、通常のテキストボックスとリストボックスの切り替え、文字コード変換機能の動的な切り替えなど、当初技術的にはそれほどネックにならないと考えていた機能の開発時に発覚した問題の解決に時間がかかり、実装完了が1w以上遅れ。
• IT（結合テスト）がスケジュール通り終わらず、テスト完了前にPT（総合テスト）着手。
• 当然ながらPTでバグが多発。
• PTと平行して実施されたOT（お客様受け入れテスト）でもバグ発生。
• ITバグ対応とPTバグ対応に追われ、徹夜続きでも開発が完了しない。

３．対応策

絵に描いたようなデスマーチですが、最終的には下記のような形で収束しました。

• ITもPTも一旦止め、1日実装に集中する。
• 実装完了後、ある程度ITが進むまではPTの打鍵を止める。

結果的には、実装は予定より1日多い2日間頂くことにより品質を安定させることができました。
当時の開発体制では、PTは専門チームが実施していたため、これを止めるとPTチームの稼働に空きが発生します。
それを踏まえた上でPTの実施を止めてくれた当時のPMの判断には、今でも感謝しています。

４．真の原因の分析

今回の直接の失敗原因は下記のようなものだと考えています。

• 要件に対して技術的には問題なく実現できるとの思い込みがまずあり、技術的な検証を実施する工数を見積に盛り込まずに開発に着手したこと。
• 特定の要件に対応するのではなく、あくまで汎用的な機能を作成すると言うことで、開発着手時点で明確な機能要件ができあがっていなかったこと。

上記を踏まえ、真の失敗原因としては、下記の通りと考えています。

• 自分のスキルを過信し、技術的な検証を怠ったこと。これに尽きますね。。。

５．対策

対策というか、本来実施すべき事を

• 実績のない機能を作る際は、技術検証の工数をもらい、プロトタイプを作成して開発の工数を見積もる。
• プロトタイプを使用して、ユーザと機能要件を確定させる。

６．終わりに

今回のプロジェクトの救いとしては、最終的にできあがった機能は非常に使い勝手が良く、リリースしてから8年ほどたった現在でもよく使われており、「あの機能は良かった」と褒められることでしょうか。
この開発が終わった後、ブリッジSEとして客先常駐でシステム企画の担当をさせていただきましたが、そこでようやく本当にお客様が求めていたものが見えたような気がします。
いずれにしても苦い思い出です。