行先ボードでも作ってみるか④ – 要件定義(機能一覧)

今回は機能一覧を作っていきます。
IPAの中で探してみたのですが僕にとって良さそうなのはありませんでした。

一応参考にしたページを貼っておきます。
IPA – 超上流から攻めるIT化の事例集:要件定義

今回はこちらを改変して使用しています。
IPA – 【財務会計・経費精算】機能一覧(リンク切れ)

今回の成果物

機能一覧のイメージ(抜粋)

機能一覧のイメージです。

勢いで書きましたが作成約2時間です。ただただ、面倒くさい。
しかし、見積もりの根拠になりますので重要です。
ここで漏れてたら見積からもれますし、工数は大幅に足りなくなります。

レビューしてもらったところで、
誤字や言い回しのような枝葉末節の指摘しか来ません。
逆に、的を射た指摘されると
画面定義も合わせて変更する必要があったりするので抵抗してしまいます。

以下の本にはその辺のことが書かれていて面白いです。
いわゆるレビューあるあるです。


見積段階で設計みたいなことをしなくてはなりません。
世の中、「見積は無料」が当たり前で「相見積もりはとる」が常識ですので、
あまり見積に時間をかけることはできません。
なんだろ。このもどかしさ。

予め成果物を定義することで不都合が生じます。

①機能一覧で合意した機能は"いらないもの"であっても削れない
僕「この機能いらなくなりました」
客「じゃあ、代わりにこの機能追加して。(削る機能にもお金払ってるんだから当然でしょ?)」

②一度確定した金額は仕様追加があっても変わらない
僕「見積段階では予見できなかった内容ですが、運用にのせるにはXXの機能が必須です」
客「その機能、無いとソフト自体使えないんでしょ?使えないものにお金は払わないよ?」

機能は増えることはあっても減ることはありません。
とはいえ、予め成果物を定義しないと定額の機能詰め放題プランになってしまいます。


一括の請負契約を危険視し情報処理技術者試験では分割契約を推奨しています。
要件定義と基本(外部)設計までを準委任、詳細設計以降を請負契約という形にするのが理想ですね。
しかし、現実問題としてユーザー企業側は支払い総額に見通しが立たないことを嫌います。
準委任契約が中々成立しないのも事実です。
難しいですね。

何も解決しないまま
次、僕が一番きらいな見積です。

おわり

PR

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です