SE歴5年ぐらいの若造です。 最近会社でカスタマブルなパッケージソフトウェア導入のための設計書を書く仕事が増えて来たの…

Question

SE歴5年ぐらいの若造です。
最近会社でカスタマブルなパッケージソフトウェア導入のための設計書を書く仕事が増えて来たのですが、いずれも要件定義書がなく、お客様にヒアリングしながら設計するという作業を行なっています。
この形だとどうしてもプロジェクト期間末期に「あれもやって欲しい」みたいな後出し要望が出てきて工数が逼迫するというのを繰り返していました。
そのためPMに「お客様に要件定義書を出してもらえないか」と聞いたのですが「そんなことした事ない。無理」と言われてしまいました。

要件定義書というのは、理想論ではあるべきだけど、実際には作られないものなのでしょうか。
それともソフトウェア開発以外では用いられないものなのでしょうか。

Answer 1

SE15年やってる者です。

＞＞ソフトウェア開発以外では用いられないものなのでしょうか。

そんな事はありません。

・政府主導の建築物建造に関わる要件書
・軍事兵器製造及び保守に関する要件書
・医療機器開発、製造に関する要件書

など、これら業種は違えど、要件定義書を基に、各製造メーカーに発注をかけます。
規模が大きくなればなるほど、業者選定会議（国の場合は公募入札など）という段階を経て、メーカーが決定します。

恐らく、あなたの会社は中小、もしくはスタートアップかベンチャーか…。

だとすると、大手企業が当たり前のようにやっている、
経営会議⇒企画⇒立案⇒社内での要件定義⇒
RFI作成・配布⇒RFP受領⇒業者選定会議⇒
ベンダー確定⇒ベンダーへの要件定義書提出⇒合意

という順序を踏んだ事がないのかな？とお見受けします。
（ここまでが超上流工程、上流工程の一部です。）

その後の工程で、要件が増加する場合は別途見積が必須です。
逆も同じで、要件が減少する場合、ベンダーは費用を減額する場合もあります。

後は感覚でわかると思いますが、

基本設計
（画面設計、DB設計（論理、物理）、コード定義、帳票設計、外部IF設計など）
（可能であれば結合テスト設計もこの時期にやる）
↓
詳細設計
（イベント設計、画面間連携設計、単体テスト設計）
↓
プログラム製造
↓
単体テスト
（桁数制限、ホワイトボックステストなどの基本テスト）
↓
結合テスト
（テスト計画、ユースケーステスト、ブラックボックステスト）
↓
総合テスト（システムテストとも言う）
（テスト計画、シナリオテスト、負荷テスト、現地環境テストなど）

大手企業へ導入する場合は、この後、
結合テスト（総合テスト）結果報告会議⇒切替判定会議などの手順を経て、
ようやく導入、切替段階の準備に入ります。

切替時の失敗に伴う切り戻し手順もここで確定させます。

その後、切替のリハーサルなども入念に行い、いざ本番…。

という流れです。

と、ざっくりと書いては見たものの、これをきっちりとできている会社、私も数社しか知りません。

皆さんご存知一般家電製品大手向けの
オンプレクラサバシステム導入の際ですら、
ここまでの細かい工程は無く、結構、アバウトな時代もありました。

今は、IPAからの指針も発表されている事もあり、
「ソフトウェア開発とは！？」
という概念を、発注側（お客様側）も勉強しているようですね。

多分、その先輩も、ここまでの工程を経験した事がないから、
あなたに教える事もできないのでは？と推測します。

実際は作れるマンパワーが足りないにせよ、
メモ書き程度の要件定義内容を
メールでやり取りするだけでも効果はあります。

会社を、自分を守る為には大事な作業という事を覚えておきましょう。
そして、その先輩にも目を覚ましてもらいましょう。

Answer 2

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

ごめんなさい。
ありえない！！！！！！！

そのプロジェクトのゴールがわからない。
その設計書（基本設計書だと思うが）の根拠は？

普通でてこないなら、こちらが作ってそれを承認してもらう形
当然、こちらが作ってもその要件定義の出し元はお客様側にする。
お客様が作って提示した形にする。
それはそもそもの契約書に記載する。

それがないと、何を根拠に仕事しているのか不明になる。
顧客にしたらやりたい放題

正直言って申し訳ないが、バカげた進め方。
自分たちがトラブルのもとを作っているに他ならない。
原価管理とか予算とか、どうやっているつもり？

スクラムならないのかな（でも、全体像はあるはず）
ただ、それならプロダクトバックログがあり、「プロジェクト期間末期に「あれもやって欲しい」」というのはあり得ない。
それはまた別に立ててバックログに入れればいい。
そして、金額だして云々となる。
その記載なら、アジャイルじゃないんでしょう。

ウォーターフォールでそれはあり得ない。

Answer 3

＞そのためPMに「お客様に要件定義書を出してもらえないか」と聞いたのですが「そんなことした事ない。無理」と言われてしまいました。
＞要件定義書というのは、理想論ではあるべきだけど、実際には作られないものなのでしょうか。
＞それともソフトウェア開発以外では用いられないものなのでしょうか。

ソフトウェア開発の場合しか知りませんが、理想論ではなく、作成する場合の方が多いものだと思います。
また、クライアントが作成するのではなく、SEが聞き取りを行った結果、要件定義書にまとめて、クライアントの承認を得るものだと思いますよ。

クライアントが情シスなどを持っている場合、自ら作ってくれるクライアントがいない訳ではありませんが、そういった作業を行える部署が無い場合は、SEが作成するのが一般的だと思いますし、なれない方が作った要件定義書では情報が足りな過ぎて前提条件を明確化出来ないので、却って手戻りが発生すると思います。

質の高いヒアリングを行えば、ある程度のリスクは除けると思います。
先にお客様の求める理想を聞いておいて、費用の関係で排除していく形にしておくと、追加する場合にも費用が掛かることを説明し易いでしょうし、作りについても変更し易い余白を作れると思います。

以上のことから、要件を聞き出した後、きちんと要件定義書にまとめて、承認を頂くという作業を入れた方が良いと思いますよ。

Answer 4

御社の営業方針によると思います。
「お客様にヒアリングしながら設計する」段階で、自分自身で「要件定義書」を作成し、お客様に確認していただ、承認していただく。

ここで作成された「要件定義書」に他の機能を付加する場合は、別途見積もりとすればよいのだと思います。事前に御社内のＰＭ、営業その他の関連する方の了解が必要なのはゆうまでもありません。

仕様が後から変わるってのは、ＳＥが誕生してから、ずぅーっと悩まされている問題です。半世紀以上前からだと思います。

ソフトウェアに限らず、各種の物を作成する場合に、発注の段階で顧客の要望を明記した仕様が決まるのが普通だと思います。その後の顧客の要望で追加変更があり、費用・工数などが余計にかかる場合は、顧客の負担である場合が多いと思います。