要件定義でお客様にプログラミング言語や開発環境を確認する意味は？

要件定義の段階で、
クライアントサイドはHTML、
サーバサイドにはPHP、
データベースはMYSQL、
開発環境はXAMPPを使用する
というように、お客様に知らせる必要があるみたいなんですが
それってどういう意味があるんでしょうか？
特にPHPなどのプログラミング言語を知らせる意味は何でしょうか？

つたない質問ですみません。。
お答えいただければ幸いです。
よろしくお願いします。

行動規範の内容に同意します

回答8件

お客様の中にも社内SEや、システムに詳しい人がある程度面倒見るということもあります。
依頼側もシステムを知っている必要があるのです。

開発後の保守や運用も含めてiiiさんやiiiさんの会社が行い
脆弱性やセキュリティリスク、インフラ障害などもあわせて完璧に対応するので
「内部のことは心配なさらずお任せください！御社は知る必要はありません！」
と自信を持って言えるのであればそれでもいいかもしれません。

でも、知りたいですよね。
自分が発注側だったら知りたくないですか？
システム開発って安くないですよね。

実はクラシックASPとVBScriptでした！なんて後から分かった日には倒れちゃいますよね。

システム開発以外の例を出すとすれば、
レストランで食事をするときに使用されている食材について、
産地知りたいですよね。

投稿2017/08/29 01:46

編集2017/08/29 01:49

Tak1016

総合スコア1408

契約の形態が関係します。

出来上がった後の、完成したものを納入し、メンテも開発者が請け負うなら、言語や開発ツールの情報は不要かもしれません。
ソースを納入して、開発者はそれでおしまい、となると、将来のメンテや改良は発注元でやることになるため、「そんなマイナーな、特殊な言語・ツールを使われても、ウチじゃメンテできないよ!」となります。
将来的なメンテナンス、改良などのしやすさを客に知らせる意味があります。

また、要求している性能に対して「その言語やツールでは心配だ」と客が感じることがあり、そういう不安を取り除く意味もあると思います。

投稿2017/08/29 01:48

nob.

総合スコア711

まずはみなさんが回答してる内容が最も重要なことですね。
作ったあとの保守を、開発元が引き続き行うのか、クライアントが行うのか。
クライアントが行う場合、その会社のスキルセットに合うものが要件にのっかってくるのは当然のことです。

そもそも開発言語などのソフトウェアの部分に限らず、
システムのアーキテクチャは要件定義で説明する必要があります。

例えば扱うデータ量が大きいため、DBを有料のSQLServerにしました、Oracleにしました、
って勝手に決めていいわけないですよね。
お金払うのお客さんですし。

DBは無料のMySQLにしましたが、データ量とアクセス数を考慮して、
サーバー３台構成にしておきました。
通常は２台が同時稼働して、１台がホットスタンバイで待機しておきます。
とか勝手にやられたら困るわけですよ。
開発コストもランニングコストも変わってくるため、お客さんへ大きく影響するところです。

こういうのは全て要件があってからです。
２４時間３６５日稼働の止まらないシステムでお願いしますと言われて、
ではこういう構成でいかがでしょうかってのが要件定義でやるべきことです。

開発言語の選定においても根拠があるはずです。その根拠は説明すべきでしょう。
システム規模と、想定アクセス数、想定データ数などから、
PHPで問題ないパフォーマンスを発揮できます。みたいな。
また、PHPだと自社にノウハウたくさんあるので、開発工数も少なくすみますとか。

おそらく、相手がなーんにも分かってないのに、わざわざ言う必要あるか？
言ってもわかんないのに。みたいな感じや、
分からないので全てお任せしますと言ってきているなどの状況なんだと思いますが、
それでも文書化して、説明する必要はあるでしょうね。

あとあと問題が起きて、PHPじゃ全然ダメだったみたいな状況になった時に、
「いや、そちらが何でもいいって言うから、こっちでいいようにしたんじゃないですか」
って言っても、裁判で負けちゃいそうですね。

家買う時とか、不動産に関してすっごい量の説明がされます。
身内が事故死した時とか、遺族は医者から検死結果などを知らされます。
聞いてもわからないような専門用語もたくさん出てくるでしょう。

まぁこれらは説明義務があるので、一概に本件と同じとは言えませんが、
何も分からない人にでも、なるべく分かるように、
納得してもらえるように説明するのがプロなんだと思います。

そして双方納得のうえに成り立っていることのエビデンスの確保も大事なことです。

投稿2017/08/29 03:18

編集2017/08/29 03:20

root_jp

総合スコア4666

ドキュメントには２つの側面があります。
一つは、共有の文書として合意をとる。
一つは、下流工程へのインプットとする。

要件定義としては、お客様との合意を取るというのが大きな目的で、他の方も説明しているので、割愛しますが、下流工程では、環境は何？とか、言語は何使う？とかのインプットとして要件定義を参照します。

上記を目的としていると、大体雛形（書式）が出来上がっているので、お客様が必要としない項目などもあるかもしれません。

逆に、雛形には無いけど、重要な要件があれば追記などを行う必要があります。

投稿2017/08/30 03:43

sazi

総合スコア25195

他の方の回答でおおむねいいのですが、仮に現在の契約が「開発＋保守」であったとしても、保守契約がそのシステムが続く限り無期限でと言うことは普通無いです。普通は1年以下の契約。
保守規模縮小とか、コストダウンなどで、保守を別の会社に変えようとしたときに、特殊な言語やミドルソフトを使われていると、あなたの会社に囲い込まれる、もしくは会社選択肢が限られることになってしまいます。それは発注者側からすると、困った事態です。

親会社とシステム子会社の契約の場合だと、保守を別会社にすることは普通ないので、おまかせというケースもあるでしょう。ただ、この先どうなるか怪しい技術を使われるのは、将来的に保守コストが増える可能性が高いので、ちゃんとした親会社ならチェックするでしょうね（責任を子会社に押しつける意図であえてチェックしないかも）。

投稿2017/08/29 16:42

otn

総合スコア84553

サーバサイドにはPHP、
データベースはMYSQL、

開発環境はどうでもいいとは思いますが、サーバー環境は重要じゃないですか？

新規でサーバーを建てるのか、それとも以前から使っているサーバー環境を使うのかとか、どこまで自由に決めれるのかで使えるモノ（言語含む）はガラリと変わります。
それと、とんでもなくマイナーな言語で作られたとしたらその会社としか保守契約を結べないっていう問題も発生します。お客さんが製作会社に保守してもらうつもりでも、会社ってのは潰れる可能性もあるわけで、その場合のリスクもちょっとは考えるわけですよ。

作ったものが実際動くかどうか、そして、保守性っていう２つの点から、お客さんとの意志の共有をしておかないと、納品後に揉めることになりかねませんよ。

（説明なし）
「動かないじゃないかどうしてくれる、そもそもちゃんとした説明がなかった。お宅の責任だ！」
「そんなこと確認されなかったじゃないですか。知りませんよ！」
「ふざけるな！訴えてやる！(# ﾟДﾟ)」

（説明あり）
「動かないじゃないかどうしてくれる！」
「開発する前に環境の確認をしましたよね？約束した環境と違うので動かないのですよ。ちゃんと約束した環境で動かしてください。それなら動きますから。」
「（ぐぬぬ...正論だ。動かさないと私の責任になってしまう）...しかし、動かないのでは困る。動く環境を作ってくれないか？」

って言う風になります

投稿2017/08/29 17:27

oskbt

総合スコア1895

Tak1016

2017/08/30 04:17 編集

>「（ぐぬぬ...正論だ。動かさないと私の責任になってしまう）きちんと瑕疵責任を認めてくれるお客様だといいですよね。決めたことを全部ひっくり返して「作り直さないとびた一文払わないぞ」っていう脅しをかけてくるお客様もいます（実際いた）。で、実際に作り直したら、「納期が遅れたから減額だ」ってね。甲乙の力関係はどこにでもあるんでしょうけどね。話題からそれました。