【IT】要件定義でモメないための発注者「5つの決め事
■ このスレッドは過去ログ倉庫に格納されています
要件定義の基本的な「5ステップ」
要件定義の手順を大まかに言うと、下記のようになります。順番は若干前後することがありますが、よくできた「要件定義書」の目次を見ると、大体こうした順番で書かれています。
【要件定義の5ステップ】
（1） ＩＴ導入の背景と目的
（2） 業務要件
（3） ＩＴ化の方針
（4） ＩＴ化の前提と制約
（5） システム要件(機能要件・非機能要件)
これらのうち、IT導入プロジェクトを任されたシステム担当者が決めるのは、主に、（3）のＩＴ化の方針と、（5）のシステム要件です。
（1）や（2）は、そもそもＩＴを導入しようと決めた人たち（経営企画部や経営陣など） が決めることで、システム担当者は、それらを確認することが主な仕事になるはずです。また、（4）のＩＴ化の前提と制約については、導入担当者が自分で決めるものとそうでないものが混ざっているようなイメージを持っておいてください。
では、１つずつ簡単に見ていきましょう。
以下ソース
http://diamond.jp/articles/-/143840?page=2 実は発注者が自分の業務プロセスを理解していない。
揉める原因はこれに尽きる。 実は受注者が業界の業務プロセスを理解していない。
揉める原因はこれに尽きる。 実は受注者が自社のパッケージを押しつけてくる。
揉める原因はこれに尽きる。 そもそも、要件定義は発注元が行って、それを元に開発規模や作業工数、予算を見積もる
のに、要件定義よりも先に、未来予測で予算や納期を出せとか言う馬鹿が権限を持っている
のが間違い。
使う開発言語やミドルウェアが決まっていることも多い。
しかも、そんな仕事をテキトーな口約束で取ってくる営業。 丸投げの中抜き偽装請負業が
横行していて、そんな業者がフリーランスの心得なぞを騙り、そんな広告記事をメディアが
タレ流しているのも一因だと思う。 こんなのとか。
ttp://internet.watch.impress.co.jp/docs/column/freelance_jobs/1082904.html 実は発注者が自らに対する期待役割を認識していない。
揉める原因はこれに尽きる。 SE歴２８年の俺が教えてやる。
日本人にシステム構築は無理。
つまりそういうことだ。 >>1
>（2） 業務要件
>背景と目的がわかったら、今度は、
>「目的を実現するためには、今の業務をどう変えたらよいのか？」
これでもう無理
そんなのが分かるなら、とっくにやってる
コンサルに投げたら泥沼一直線
仮に決めても、状況が変わったら決めなおさないといけない→仕様変更 顧客「に」本当に必要だったもの
顧客「が」本当に必要だったもの
顧客が説明した要件
これを発注者がごっちゃにしてるから。
わからないなら自らの業務をパッケージソフトに合わせるのが無難 発注者が業務プロセスを理解してないし、発注すれば自然とできるものと勘違いしてる
ので、受注者に業務プロセスについて聞かれても適当に応対して、その結果使えないもの
ができて、発注者が仕様変更をかける、受注者はその前に仕様はこれでいいですねと念を
おしてフィックスしてるものだから、責任になる担当者がどなりちらして揉め事になる。 とりあえず人ぶっこめば何とかなんじゃねーか？
と思ってる上が多すぎる >>4
>>6
そもそも発注しなくてよくね？
競争力の源泉になるなら自組織で人抱えるなり子会社作るなりしてやった方がいいよ 現場死ねよ
こっちの言ったとおりにやればいいのにワケワカランルールやら意図しない使い方をして、後でこれができないとダメと言う >>4
発注者は自分のビジネスプロセスはわかっている
発注者は自社内のビジネスプロセスをわかっていない 法律論と同じでこれはもう日本語自体の問題だからどうしようもないだろ ユーザー情報系担当者と要件定義を進めて、要件定義レビューで初めて現場担当者を連れてくる。
ここは運用が違う。これは無理。○○が足りない。画面が変わるとやりにくい。
情シス担当者から「じゃあ今回は1度仕切り直しで。もう一度社内調整して報告します。」その後要件定義で追加機能が怒濤のごとく。
無能営業は料金据え置き納期据え置き。
要件定義が数ヶ月遅れても納期は変わらず。何度も経験した。 システムの導入は、ビジネスプロセスをどうしたいのかとセットで考えなければらない
これはビジネスプロセスのキーマンが要件定義にがっつりコミットしないと実現出来ない 発注側が要求仕様をかけるようにならないと
いつまでもトラブルは続く
ベンダーに要求定義をさせるのが間違い >>23
いやー平気で仕様変更してくる姿勢？
それがある限りだめだろ >>24
仕様変更は無くならないよ
システム構築で仕様変更、試行錯誤、手戻りは避けられない
ていうか試行錯誤しないといいものは作れない
契約がそれを見越した契約になってないだけ >>24
平気じゃなくて必死だと思うよ
仕事が立ち行かなくなる >>24
ベンダーが要件定義するから
平気で仕様変更してくる
自分で書いたものなら
平気で仕様変更は出来なくなる
これを法制化すべき >>10
お前は28年間で何も学べなかった無能ということか >>28
誰が作ったものにせよ
一旦判子押したら契約遂行中は変えさせんなって話だよな >>23
一回システムできると仕様なんか誰も覚えないからな 日本人はワープロとファックスで仕事するのがお似合いw >>2
SIerとは名ばかりで、経営トップ層にはコンサル面するくせに、現場では「顧客の要望
だから」と、コンサル機能放置したあげく、もめると「お宅様の現場の要望ですから」と
逃げに入る営業しているからだろ。 >>33
建設なら、「その要望を入れると、構造設計からやり直しですが、良いですか？」
という決め文句があるからな。 >>37
いやIT案件だってその要望入れたら基本設計から...
って言えるはずなんだが >>41
はんこを押しても変更するじゃん
ねじ込みは法律違反にしないとあかん 最近は社内向け開発ばかりで
まともな要件定義書を書かなくなったなぁ… お前らちょっとは現実を見ろよ
要件定義で全て仕様をFIX出来るか？
出来るわけが無い
客なんて完成品を触ってはじめてあーすればいいこーすればいいという具体的要求がいろいろ出てくるもんだ
完成イメージが見えるまでは漠然とした要求しか出せないんだよ
それが客ってもんだ
だから要件定義で要件の受け入れをFIXしたようなシステムなんてとても使えたものじゃないゴミシステムにしかならないんだよ 【 ど な た か 教 え て く だ さ い 】
【拡散希望】
先日ドコモショップでこんな対応をされ、泣き寝入りするしかないのかと悩んでいます。
どなたかお知恵をお貸しいただけないでしょうか。
スマホに不慣れな方が家族にいる方の注意喚起にもなれば…。
よろしくお願いします…！
https://twitter.com/3269torihiki/status/915963863085891584
女 性 の 方 が お っ ぱ い を 挟 ん で
「４０歳以上の女性の方がおっぱいを挟んで
癌があるか検査するマンモグラフィーについて、
実は一般のレントゲンの１０００回分の放射能を浴びるそうです。
このことを細川先生も一生懸命うったえておられます。
こういうことをやるようになって日本人の癌患者が、
２倍も３倍も増えていっているのですって、アメリカなら即逮捕らしいです。
どうせマンモグラフィーをやったあとに超音波検査もやるくせに、
そちらを何故しないんだとおっしゃってます。」
視聴回数 6,199 回
乳癌検査 本当は危ないマンモグラフィー 間違いだらけの医療、医学
【ネット ＴＶ ニュース.報道】国家非常事態対策委員会 2017/08/31
https://www.youtube.com/watch?v=aYtCwRlsUnI
暴 動 が 起 こ る の で
水俣病の被害者は1万5000人を越え、現在もなお被害者は増え続けています。
この水銀が、実は私たちの口の中に詰められていることをご存知でしたか？
日本人に入っている銀歯の正体は高濃度水銀、アマルガムだった。
http://doclabo.jp/contents/709
いわゆる”銀歯”は欧米では使われていません
「できるだけ早い時期に金合金に移行すべきである。」（歯科用金属規格委員会報告 ）
それから50年以上経ちました。当時とは比べものにならないくらい豊かな現代の日本ですが、
報告書の言う「できるだけ早い時期」は未だ到来せず、今日も代用合金を使い続けています。
http://chicchic8.exblog.jp/25698475/
このような詰め物を保険で認可している厚生労働省は、当然のように事実として知っています。
ではなぜ放置したままなのでしょうか。
当医院の院長が保険への適応を提出したとき、その答えが返ってきました。
その答えとは暴動が起こるのでここでは公開できません。
●アメリカではアマルガムを摘出する時、 防護マスクを使用している写真（中）
http://wakitani.com/treat_2.html 👀
Rock54: Caution(BBR-MD5:f70dfdc711a7c6ae6accccb939f27fbf) 要件なんて使い始めてイメージが湧いてくるから
請負契約でアジャイル開発（死語？）
残念ながら規模がでかいと効果がなさそうだし、顧客にも理解がないと使えないし、プロトタイプに金を出すなんてありえないだろうな
あとは自分たちのビジネスに合わせたツールを作るのではなくて、ツールやベストプラクティスに合わせたビジネスに移行するとかだな こんな感じで やっぱりこうした方がいい
あ、いや こんなのもいる やっぱりさっきの無しで >>10
日本会社で出世するような人間にシステム構築は無理、だな システム構築で一番のキーとなるのは、
ベンダーじゃなくて発注側企業の担当者なんだよね。
ここが理解できてない人が（発注側に）多いｗ >>2
まさにこれ
自分達の欲しいものを理解してない >>53
おそらく最高裁は上告棄却すると思う
民事の場合、最高裁は高裁の法解釈に疑義があれば受理するが、
このケースは失敗原因の特定が争点なので
つまりユーザ側の全責任ということでそのまま決着すると思う >>5
しかし現場の人間は商談出来ないからな。
いやホント、作る人間ってのは作る側の論理を押し付けるからね。
絶対に他人と揉める。
じゃあ客と揉めるのと社内で揉めるのと、どちらがいいかと言うと、社内で揉める方がまだマシって事だよ。
まぁ現状が最適解って事だよ。 >>8
同意
何も決まってないのに、見積出さされる
発注元が要件定義すべき 費用は増大しますが要件定義の後でモックアップ組んでそこから細かい部分を詰めていきましょうかって言うと大体の会社は費用が増えるのは嫌だって言う
安物買いの銭失いって言葉がピッタリだな 億の金だと
先方が役員に言うのが面倒
というかこっちも巻き込まれて面倒 >>2
これの原因の一つが、既に古いシステムである程度実現されているのだけれど
使い方しか知らない状況になっていて、
開発依頼はリプレース+改修なのにその仕様を理解していない状況に有る事。
効率化するのはいいけど使うだけになった人々が悪い。
ブラックボックス化してしまっている。 ・本来あるはずのレアケース、例外に関する要求が出てこない
・顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない
・顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手段がない
・ステークホルダーによって要求が異なったり、ステークホルダー間で要求が矛盾したりする
・複数の要求提供部門が存在し、一方の要求を満足しようとすれば他方が成り立たない
・業務用語知識の欠如
・IT動向や他社事例を参考に、自社システムの実態とは乖離した要求をされる
・システム化の目的よりも手段が重視され、顧客の真の要求が引き出せない
・画面の細部に顧客の注意がいってしまい、本質的な要求でないことに発散
・顧客予算に限りがあり、設計書を作成し仕様を確定してから実装をしては間に合わない
・計画段階での要求発散や確定漏れ
・経験者によるレビューを受けずに要件定義書を作成し、統合テストの段階で仕様にはない日機能要件を要求されて大きな手戻り
・要求を獲得した段階で開発規模を示す必要があるが困難である。顧客側にとってもその良否を判断するための手段がない
・ユーザのビジネス要求の優先順位と要求に対するシステム化の優先順位が異なる
・利害関係者からシステム化に伴う費用対効果を求められる
・課題に対する原因を検討する方法がわからない
・要求の分析が不十分であるにも関わらず、予算や納期が先行している
・顧客のシステム導入経験があまりない
要件定義なんてそもそも無理なんだよ いわれたことしか出来ない、いや違うな
いわれたことすら出来ない虚業の雇われ事務屋がずいぶんと偉そうだな
出したカネの分だけ働いて納期守ってちゃんと使えるものを納品してから文句をいえ
使えないゴミ渡されてカネだけ払えとか詐欺犯だろ
底辺の無能なんだからせめて言われたことを守れるようにしろよ お前らちょっとは現実を見ろよ
要件定義で全て仕様をFIX出来るか？
出来るわけが無い
客なんて完成品を触ってはじめてあーすればいいこーすればいいという具体的要求がいろいろ出てくるもんだ
完成イメージが見えるまでは漠然とした要求しか出せないんだよ
それが客ってもんだ
だから要件定義で要件の受け入れをFIXしたようなシステムなんてとても使えたものじゃないゴミシステムにしかならないんだよ >>8
役所を筆頭に年度内に予算消化の論理で世の中回ってるからしゃあない >>63
大体予算がクソ
見積もり描いたやつがクソな事例も稀にあるが
値切るだけ値切った挙句、予算品質納期の三両立を抜かしやがる
ゲームのキャラメイクで10パラメーターを力素早さ体力に割り振れるとして、
力10素早さ10体力10を要求する客が多すぎる >>64
どうぞどうぞｗ
ご自分でなさってくださいｗ >>66
知るかボケ
自分から営業掛けてその値段でやれますっつって請けてんだろが
出来ないことは契約すんじゃねえ
決められた商品を決められた期限に納品するだけすら出来ないのならもはや経済社会に不要 >>63
金ケチったか開発会社の選定ミスってるだけだな。
後、中韓の出来ますやりますのような営業に騙されたか。
それと出来ると思うなら、出来ると思うお前がPMや要件定義とかきちんとやっとけ
その方が確実で安く出来るだろう。
それと、
>>64
の言う事も真実で、後から変え様とし過ぎ、それを見越して余裕のある予算と納期を準備しないで
〜でないと使えないから変えろと、金と納期固定したままで変えようとし過ぎ。
>>64はそう思うならそういう開発で作れるように追加予算と時間を用意しとけって話。
見かけだけのモックアップで運用をシミュレーションとかして要件定義までおけば変更が減る。
どの時点で発見するのが一番無駄がなくコスパが良いかを考えるべき。
金と時間をかけて良いなら後から出た要求でも頑張ってくれるでしょうね。
変更に次ぐ変更だと概ね出来の良くないプログラムソースになるけどな。 >>1
ダメな会社
（1） ＩＴ導入の背景と目的
→上司が言ってる 会社の中に、業務プロセス全部を理解している人なんていないから、
ITベンダーにコンサル能力が求められているんだろ >>74
それもそうだし、そのプロセスをどうシステム化できるかの現実的感覚もない。 企業内でシステム開発していた時代には、どこの会社にもいたんだけどな。 要件定義するうえで必ず知っておかないといけないことは
「発注者は要件を正確に理解していない」
「そもそも、最初から要件を明確に詰めることなど困難」ということ
まあ、頑張れや わいが人月100万で、よう書いておる(^。^)y-.。o○
人んちの話やからな
毎度毎度、ちょー適当に >>77
同業他社の最新システムをパクって安く使いたい >>46
アジャイル開発
って、何か会社ごとに言うこと違くね？
単に好き勝手に仕様変更して、開発時間がやたら伸びて
社員の稼働時間が変に長くて
ゴールも無くたいして収益もあげれて無い会社が多いように思う ☆ 私たち日本人の、日本国憲法を改正しましょう。総務省の、
『憲法改正国民投票法』、でググってみてください。
2017年10月22日（日）の衆議院選挙は、ぜひ投票に行きましょう。
平和は勝ち取るものです。お願い致します。☆☆ ■ このスレッドは過去ログ倉庫に格納されています
