外部仕様を華麗に策定するための１０のポイント
新規案件の外部仕様を決めるのは本当に難しいです。
ちょうどそういうことに頭がフル回転しているので備忘録としてメモします。
既に継続開発が入っていて毎月お小遣いもらえるならいいですが、基本的には着手前に仕様を決めないとずるずるいって炎上となるので、基本的に仕様を固めてから開発スタート、という方針を前提として考えます。
１）クライアントの業務を確実に押さえる
基本です。どんな場合もかならずやりましょう。
２）最初に要望ぜーんぶ出してもらう
とりあえず要望をぜーんぶ出してもらってぜーんぶ見積もりして要らないところを相談の上で切ってもらうのが吉です。着手後に先方から「あれもくれ」といわれる事が減ります。
３）外部仕様策定の予算を捻出する
大規模開発では出るでしょうが、私がやるような、大きくても1000万くらいの案件だと仕様策定に予算つくことはなかなかないです。工数見積→テスト工数見積→ドキュメンテーション工数見積 の総額を見積として、ドキュメンテーション工数内で外部仕様が収まるようにしましょう。内部仕様書は自動ドキュメンテーションツールを使いましょう。
４）工期を気にする
５）クライアントの、仕様策定に対する姿勢を意識する
こっちがある程度提案資料を作成してあげると、それを元に勝手にUIをつくってきて「これでつくってくれ！」とか言ってきたりします。
クライアントは自社の業務についてはプロですがシステムやUIデザインについては素人です。
-
- オールUnicode前提のシステムなのに、粋がって「この項目は100バイト」とか指定がある
- わざわざ「最大50件まで登録できる」とか指定がある
- マスタ管理画面の正規化、非正規化が業務の運用に最適化されていない
勝手に訂正すれば先方の信頼度が下がりますし、毎回やりとりをして修正すると時間の無駄が膨大になります。悩みどころです。
素人の作成したUIデザインはもっともっと合理化が可能なことがほとんどです。このとき顧客の反応としては
-
- よりよい提案をされると怒る（ケチがついたように思う）
- おお！ もっともっと提案してくれ！
という担当者に別れます。ほとんどは後者だと思いますが、前者だと前途多難です。
後者の場合、工期が有る場合は問題がありませんが、時間が切羽詰まっている場合は困ります。
６）ユーザのITリテラシを正しく把握する
７）クライアントのレスポンスの早さを意識する
よい対応をしてくれるクライアントでも、社内のまとまりが悪かったりして返事が遅いと、仕様策定に時間がかかりすぎて後が大変なことになります。こういう場合は、デフォルトであろう機能なんかは勝手に決めて仕様書に記載しちゃったりしたほうが知らぬが仏的な平和が訪れます。
