独立して暫くした時、ある会社からシステム開発の案件があった。
先に言っちゃうとコレがもう揉めに揉めて、予算以上に工数使うわ、見積範囲外の作業までさせられるわ、体力的にも精神的にもすごい追い詰められた。
もちろんこれは開発サイドの意見で、クライアント側からしたら当方の仕事ぶりに不満が残ったと思う。
それもこれも、案件の進め方を誤ったこちらのミスなので、二度とこんな仕事はするまいと心に誓い、反省点と今後の対策をまとめておく。
案件概要
まずは当該案件の内容について簡単に説明する。
作ったのはWindows用のアプリケーション。
目的は業務の効率化。主な機能は以下の２つ。
- 既存システムAと他のシステムB、Cを連携させるためのデータ変換機能
- データ表示機能
※ ここで出てくる既存システムAと他のシステムB、Cは客先端末でしか動作しないため、マニュアルとデータシートをお借りして、動作をシミュレーションすることになった。
開発ボリュームは小規模アプリケーションというか便利ツールといったレベルなので、各種仕様書等の作成は省略して進めることにした。
実際に進んだ案件の流れ
- 初回訪問＆ヒアリング
- サンプルプログラム作成＆見積提出
- 要件定義書作成＆見積確定
- 既存システムの調査
- プログラミング
- 客先テスト
- 納品（１回目）－納品時に問題発生
- 納品（２回目）－定時スケジュールから3週間遅れ
- 試用期間
- 完了
揉めたポイント
システム案件で揉めるのは結局『認識のズレ』が原因である。
今回のケースで発生したズレは以下の通り。
- 見積り範囲
- 不確定要素の発生率
「見積り範囲」は、今回の作業の内容、つまり何をどこまでやるかと、それ以外は別途費用がかかることを確実に理解・納得してもらう必要がある。
「不確定要素の発生率」は、運用開始後の初期不具合の発生率である。
特に未知の仕様のライブラリ、他システムを使用する場合、大げさ以上に伝えておいて、理解・納得してもらう必要がある。
具体的には運用開始後から実用レベルになるまでこれくらい時間がかかりますよとスケジュールに書いておくと伝わりやすい。
初めてシステム案件を受ける前に確認すべき6つのこと
上記失敗をもとに、案件受注前に確実に確認しておくことをまとめておく。
-
システムの仕様を確定しているか？
未確定の仕様が残っている場合は、状況に応じて多めに予算を積んでおくか、別途調査費用を請求するか、事後請求の理解を得ること。
-
未知のシステム・ライブラリを使う場合、仕様書や問合せ先を入手しているか？
仕様書は必須。サポートなどの連絡先など、問合せに必要な情報も入手できるならば入手しておくこと。
-
客先環境を借り受けできるか？
出来ない場合は、多めに予算を計上しておき、現地での確認作業の時間を多めに確保しておく。
または客先に試用してもらう形での試験とすることに確実に納得してもらうこと。 -
客先作業の内容は明確か？
客先作業を行う場合、何を行うかとその時間を明確にしておき、現場でも予定外作業は頼まれても行わないこと
-
納品条件は明確か？
作業の完了条件を明確にし、クライアントに理解・納得してもらうこと。
-
追加費用の発生条件は明確か？
どこまでやるかを明確にしておき、他は追加費用が発生することを理解・納得してもらうこと。
さいごに
開発サイドもクライアントも気持ちよく仕事できるよう、最初に必要以上くらいの気持ちで意識のすり合わせを行うことが大事！
