2016-07-27-002_001

1: ノチラ ★ 2017/10/08(日) 10:21:48.72 ID:CAP_USER.net
要件定義の基本的な「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

2: 名刺は切らしておりまして 2017/10/08(日) 10:33:10.93 ID:JSVFOnVl.net
実は発注者が自分の業務プロセスを理解していない。

揉める原因はこれに尽きる。

引用元:http://anago.2ch.sc/test/read.cgi/bizplus/1507425708/

13: 名刺は切らしておりまして 2017/10/08(日) 11:40:37.22 ID:SGT22Iq1.net
顧客「に」本当に必要だったもの
顧客「が」本当に必要だったもの
顧客が説明した要件

これを発注者がごっちゃにしてるから。
わからないなら自らの業務をパッケージソフトに合わせるのが無難

15: 名刺は切らしておりまして 2017/10/08(日) 12:02:20.96 ID:k7QZOB4q.net
発注者が業務プロセスを理解してないし、発注すれば自然とできるものと勘違いしてる
ので、受注者に業務プロセスについて聞かれても適当に応対して、その結果使えないもの
ができて、発注者が仕様変更をかける、受注者はその前に仕様はこれでいいですねと念を
おしてフィックスしてるものだから、責任になる担当者がどなりちらして揉め事になる。

52: 名刺は切らしておりまして 2017/10/09(月) 22:23:15.66 ID:JodwFR6T.net
システム構築で一番のキーとなるのは、
ベンダーじゃなくて発注側企業の担当者なんだよね。
ここが理解できてない人が(発注側に)多いw

21: 名刺は切らしておりまして 2017/10/08(日) 14:11:04.99 ID:KdWosvBh.net
ユーザー情報系担当者と要件定義を進めて、要件定義レビューで初めて現場担当者を連れてくる。

ここは運用が違う。これは無理。○○が足りない。画面が変わるとやりにくい。

情シス担当者から「じゃあ今回は1度仕切り直しで。もう一度社内調整して報告します。」その後要件定義で追加機能が怒濤のごとく。

無能営業は料金据え置き納期据え置き。
要件定義が数ヶ月遅れても納期は変わらず。何度も経験した。

48: 名刺は切らしておりまして 2017/10/09(月) 17:09:15.19 ID:FGDl771N.net
こんな感じで やっぱりこうした方がいい
あ、いや こんなのもいる  やっぱりさっきの無しで

22: 名刺は切らしておりまして 2017/10/08(日) 14:12:11.06 ID:YORFOgJj.net
システムの導入は、ビジネスプロセスをどうしたいのかとセットで考えなければらない
これはビジネスプロセスのキーマンが要件定義にがっつりコミットしないと実現出来ない

33: 名刺は切らしておりまして 2017/10/08(日) 17:35:34.72 ID:da616bU6.net
建築なら取り掛かったらやり直しきかないんだろ

37: 名刺は切らしておりまして 2017/10/08(日) 20:08:50.72 ID:eod8na/F.net
>>33
建設なら、「その要望を入れると、構造設計からやり直しですが、良いですか?」
という決め文句があるからな。

38: 名刺は切らしておりまして 2017/10/08(日) 22:26:09.39 ID:k5zWG1bF.net
>>37
いやIT案件だってその要望入れたら基本設計から...
って言えるはずなんだが

53: 名刺は切らしておりまして 2017/10/09(月) 23:18:52.04 ID:+tgzU6ZR.net
>>38
この判決を最高裁も支持したら言えるようになるかもな

失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/

44: 名刺は切らしておりまして 2017/10/09(月) 11:49:58.89 ID:JF7OS/3d.net
お前らちょっとは現実を見ろよ

要件定義で全て仕様をFIX出来るか?
出来るわけが無い
客なんて完成品を触ってはじめてあーすればいいこーすればいいという具体的要求がいろいろ出てくるもんだ
完成イメージが見えるまでは漠然とした要求しか出せないんだよ
それが客ってもんだ

だから要件定義で要件の受け入れをFIXしたようなシステムなんてとても使えたものじゃないゴミシステムにしかならないんだよ

59: 名刺は切らしておりまして 2017/10/10(火) 11:14:44.31 ID:SMSzTErJ.net
費用は増大しますが要件定義の後でモックアップ組んでそこから細かい部分を詰めていきましょうかって言うと大体の会社は費用が増えるのは嫌だって言う
安物買いの銭失いって言葉がピッタリだな

46: 名刺は切らしておりまして 2017/10/09(月) 14:48:48.75 ID:/3yokcdW.net
要件なんて使い始めてイメージが湧いてくるから
請負契約でアジャイル開発(死語?)
残念ながら規模がでかいと効果がなさそうだし、顧客にも理解がないと使えないし、プロトタイプに金を出すなんてありえないだろうな

あとは自分たちのビジネスに合わせたツールを作るのではなくて、ツールやベストプラクティスに合わせたビジネスに移行するとかだな

16: 名刺は切らしておりまして 2017/10/08(日) 12:04:39.74 ID:PtE2+2dQ.net
とりあえず人ぶっこめば何とかなんじゃねーか?
と思ってる上が多すぎる