要件定義の基本的な「5ステップ」
要件定義の手順を大まかに言うと、下記のようになります。順番は若干前後することがありますが、よくできた「要件定義書」の目次を見ると、大体こうした順番で書かれています。
【要件定義の5ステップ】
(1) IT導入の背景と目的
(2) 業務要件
(3) IT化の方針
(4) IT化の前提と制約
(5) システム要件(機能要件・非機能要件)
これらのうち、IT導入プロジェクトを任されたシステム担当者が決めるのは、主に、(3)のIT化の方針と、(5)のシステム要件です。
(1)や(2)は、そもそもITを導入しようと決めた人たち(経営企画部や経営陣など) が決めることで、システム担当者は、それらを確認することが主な仕事になるはずです。また、(4)のIT化の前提と制約については、導入担当者が自分で決めるものとそうでないものが混ざっているようなイメージを持っておいてください。
では、1つずつ簡単に見ていきましょう。
以下ソース
http://diamond.jp/articles/-/143840?page=2
実は発注者が自分の業務プロセスを理解していない。
揉める原因はこれに尽きる。
で終了だな
SIerとは名ばかりで、経営トップ層にはコンサル面するくせに、現場では「顧客の要望
だから」と、コンサル機能放置したあげく、もめると「お宅様の現場の要望ですから」と
逃げに入る営業しているからだろ。
これですな
これだな
まさにこれ
自分達の欲しいものを理解してない
これ
正解出すの早すぎだろw
実は受注者が業界の業務プロセスを理解していない。
揉める原因はこれに尽きる。
>>6
そもそも発注しなくてよくね?
競争力の源泉になるなら自組織で人抱えるなり子会社作るなりしてやった方がいいよ
発注者は自分のビジネスプロセスはわかっている
発注者は自社内のビジネスプロセスをわかっていない
>>5
しかし現場の人間は商談出来ないからな。
いやホント、作る人間ってのは作る側の論理を押し付けるからね。
絶対に他人と揉める。
じゃあ客と揉めるのと社内で揉めるのと、どちらがいいかと言うと、社内で揉める方がまだマシって事だよ。
まぁ現状が最適解って事だよ。
実は受注者が自社のパッケージを押しつけてくる。
揉める原因はこれに尽きる。
実は発注者が自らに対する期待役割を認識していない。
揉める原因はこれに尽きる。
SE歴28年の俺が教えてやる。
日本人にシステム構築は無理。
つまりそういうことだ。
お前は28年間で何も学べなかった無能ということか
日本会社で出世するような人間にシステム構築は無理、だな
顧客「に」本当に必要だったもの
顧客「が」本当に必要だったもの
顧客が説明した要件
これを発注者がごっちゃにしてるから。
わからないなら自らの業務をパッケージソフトに合わせるのが無難
ので、受注者に業務プロセスについて聞かれても適当に応対して、その結果使えないもの
ができて、発注者が仕様変更をかける、受注者はその前に仕様はこれでいいですねと念を
おしてフィックスしてるものだから、責任になる担当者がどなりちらして揉め事になる。
と思ってる上が多すぎる
こっちの言ったとおりにやればいいのにワケワカランルールやら意図しない使い方をして、後でこれができないとダメと言う
これはビジネスプロセスのキーマンが要件定義にがっつりコミットしないと実現出来ない
いつまでもトラブルは続く
ベンダーに要求定義をさせるのが間違い
いやー平気で仕様変更してくる姿勢?
それがある限りだめだろ
仕様変更は無くならないよ
システム構築で仕様変更、試行錯誤、手戻りは避けられない
ていうか試行錯誤しないといいものは作れない
契約がそれを見越した契約になってないだけ
定額でなんでもやらせようとするからな
平気じゃなくて必死だと思うよ
仕事が立ち行かなくなる
ベンダーが要件定義するから
平気で仕様変更してくる
自分で書いたものなら
平気で仕様変更は出来なくなる
これを法制化すべき
それだと自分でやる利点が見当たらない
誰が作ったものにせよ
一旦判子押したら契約遂行中は変えさせんなって話だよな
そう思う。
はんこを押しても変更するじゃん
ねじ込みは法律違反にしないとあかん
一回システムできると仕様なんか誰も覚えないからな
建設なら、「その要望を入れると、構造設計からやり直しですが、良いですか?」
という決め文句があるからな。
いやIT案件だってその要望入れたら基本設計から…
って言えるはずなんだが
>>38
この判決を最高裁も支持したら言えるようになるかもな
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/
>>53
おそらく最高裁は上告棄却すると思う
民事の場合、最高裁は高裁の法解釈に疑義があれば受理するが、
このケースは失敗原因の特定が争点なので
つまりユーザ側の全責任ということでそのまま決着すると思う
まともな要件定義書を書かなくなったなぁ…
お前らちょっとは現実を見ろよ
要件定義で全て仕様をFIX出来るか?
出来るわけが無い
客なんて完成品を触ってはじめてあーすればいいこーすればいいという具体的要求がいろいろ出てくるもんだ
完成イメージが見えるまでは漠然とした要求しか出せないんだよ
それが客ってもんだ
だから要件定義で要件の受け入れをFIXしたようなシステムなんてとても使えたものじゃないゴミシステムにしかならないんだよ
要件なんて使い始めてイメージが湧いてくるから
請負契約でアジャイル開発(死語?)
残念ながら規模がでかいと効果がなさそうだし、顧客にも理解がないと使えないし、プロトタイプに金を出すなんてありえないだろうな
あとは自分たちのビジネスに合わせたツールを作るのではなくて、ツールやベストプラクティスに合わせたビジネスに移行するとかだな
>>46
アジャイル開発
って、何か会社ごとに言うこと違くね?
単に好き勝手に仕様変更して、開発時間がやたら伸びて
社員の稼働時間が変に長くて
ゴールも無くたいして収益もあげれて無い会社が多いように思う
あ、いや こんなのもいる やっぱりさっきの無しで
ベンダーじゃなくて発注側企業の担当者なんだよね。
ここが理解できてない人が(発注側に)多いw
安物買いの銭失いって言葉がピッタリだな
先方が役員に言うのが面倒
というかこっちも巻き込まれて面倒
いわれたことすら出来ない虚業の雇われ事務屋がずいぶんと偉そうだな
出したカネの分だけ働いて納期守ってちゃんと使えるものを納品してから文句をいえ
使えないゴミ渡されてカネだけ払えとか詐欺犯だろ
底辺の無能なんだからせめて言われたことを守れるようにしろよ
>>63
大体予算がクソ
見積もり描いたやつがクソな事例も稀にあるが
値切るだけ値切った挙句、予算品質納期の三両立を抜かしやがる
ゲームのキャラメイクで10パラメーターを力素早さ体力に割り振れるとして、
力10素早さ10体力10を要求する客が多すぎる
知るかボケ
自分から営業掛けてその値段でやれますっつって請けてんだろが
出来ないことは契約すんじゃねえ
決められた商品を決められた期限に納品するだけすら出来ないのならもはや経済社会に不要
>>63
金ケチったか開発会社の選定ミスってるだけだな。
後、中韓の出来ますやりますのような営業に騙されたか。
それと出来ると思うなら、出来ると思うお前がPMや要件定義とかきちんとやっとけ
その方が確実で安く出来るだろう。
それと、
>>64
の言う事も真実で、後から変え様とし過ぎ、それを見越して余裕のある予算と納期を準備しないで
~でないと使えないから変えろと、金と納期固定したままで変えようとし過ぎ。
>>64はそう思うならそういう開発で作れるように追加予算と時間を用意しとけって話。
見かけだけのモックアップで運用をシミュレーションとかして要件定義までおけば変更が減る。
どの時点で発見するのが一番無駄がなくコスパが良いかを考えるべき。
金と時間をかけて良いなら後から出た要求でも頑張ってくれるでしょうね。
変更に次ぐ変更だと概ね出来の良くないプログラムソースになるけどな。
お前らちょっとは現実を見ろよ
要件定義で全て仕様をFIX出来るか?
出来るわけが無い
客なんて完成品を触ってはじめてあーすればいいこーすればいいという具体的要求がいろいろ出てくるもんだ
完成イメージが見えるまでは漠然とした要求しか出せないんだよ
それが客ってもんだ
だから要件定義で要件の受け入れをFIXしたようなシステムなんてとても使えたものじゃないゴミシステムにしかならないんだよ
どうぞどうぞw
ご自分でなさってくださいw
>>1
ダメな会社
(1) IT導入の背景と目的
→上司が言ってる
ITベンダーにコンサル能力が求められているんだろ
それもそうだし、そのプロセスをどうシステム化できるかの現実的感覚もない。
要件定義するうえで必ず知っておかないといけないことは
「発注者は要件を正確に理解していない」
「そもそも、最初から要件を明確に詰めることなど困難」ということ
まあ、頑張れや
同業他社の最新システムをパクって安く使いたい
引用元
http://anago.2ch.sc/test/read.cgi/bizplus/1507425708/
管理人からひと言
この記事へのコメントはありません。