要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」

nori @00oichan お気軽にフォローいただけると嬉しいです。 神奈川県在住／運用設計が得意／外資系企業のSaaSエンジニアです。 好き： servicenow、UiPath、Power Automate Desktop、PowerBI … ServiceNowの眠らぬPDIを持っています。 ぜひ下記の短縮URLからご覧ください。 onl.la/SMiY8gL

[findup]

他コメにあるけど、わざと要件をふんわりしか言わず受注後にあれこれ押し込むのを意図的に狙う人多いんだよね。納期とか金額確定した後で。そして費用交渉で揉めるが、そこでも受注側に飲ませるのが実力、みたいな。

[mak_in]

超大手のお客様で担当者が全員東大卒の超エリートの案件やったことあるが、要件定義で滅茶苦茶詰めて、要件定義が倍くらい膨らみ大炎上、しかしリリース後は超平穏だった。こりゃ一般人には到底無理だ、と悟ったよ。

[sgo2]

「要件定義に関わる人」ではなく「経営者」に読ませるべき

[kagehiens]

富士通の人にこれ書かれてもな……。

[toria_ezu1]

なお、一回一秒で読んだとして、3億回読むのに100年かかる

[az1za]

要件定義できない会社とやる時は機能リスト作ってそれ以上は今回の開発でやらない、またはやるとしても有料って契約書まけばモメても大炎上になりにくいよ。こんなの読んでくれる訳無いので自分の身は自分で守ろう

[TakamoriTarou]

IPAはキラキラしたWeb屋界隈の情報は出てこないけど、こう言うわりと一般人でも分かるように作った泥臭い文章をきちんと作ってくれてあってありがたいよね。いうても読まんやつは読まんけども。

[sun330]

発注側になるとどこまで後出しで突っ込んで貰えるかが勝負みたいなのをよく見る…

[Andrion]

こういうフワッとした概念ではなく、契約書のテンプレや、裁判で揉めた事例をまとめてくれた方が助かる

[lorenz_sys]

自分は凡庸な業務システム屋でしかないが現場感覚としては「要件定義は発注者と受注者の合意」であると思ってる。"発注者の責任" と言いきってしまえるところがいかにも F の人っぽいね。

[nao_cw2]

喩えはわかるが３億回読むのに何年かかるかしってる？笑／1回1秒で読めないし寝ないで読めないのでたたき込む時間込みで10秒。一日8時間読み続けて2880回／日なので285年だよ／まて17ヶ条だった

[rck10]

権力勾配に触れないべき論は役に立たないのでは。これを発注側に見せたとて「こういう面倒なこと言わない所に発注するわ」って言われて困らないつよつよ開発会社がどれだけあるのか。

[Silfith]

発注者は自分の要求の定義すらできない　を前提にしている自称コンサル胴から首落ちないかな。それはお前が小賢しく飯の種にしているだけで出来ない発注者が悪い話なので

[toribard]

人に提示するためじゃなく自分のチェックリストとしてしか機能しないだろうな

[fujikiseki21]

発注者責任 責任自分論

[poipoi3]

ちゃんと計算したら、1回1秒で読むと3億回読むのにかかるのは10年だったので100年かかるというブコメはデマ（60x60x24x365x10=315,360,000）

[ohayo0]

痛い目に会いまくってる富士通さんが主査なので信用できる

[OrionB312]

コメント欄にある要件時はわざとふんわりとしか言わないユーザーって…そんな人いるのか…まだまだ自分は綺麗な面しか知らないのか…

[prjpn]

内製するのが一番良いということがよく分かる

[coper]

「要件定義は発注者の仕事である」を繰り返し発注者に読ませても解決しない。発注者に要件定義をさせる術を考えるか、金を貰って定義した要件を発注者に意思決定させる術を考える方が生産的。

[akikonian]

システム業界に入って25年だけど要件定義できる会社なんてないよ。25年のうち5年はユーザー企業の情シスで要件定義やったけど要件定義の手順や定石、論点を分かってないとなかなかできないもんだわ。

[sagami3]

ブコメ1200超とか久しぶりに見た。

[wasai]

うちのとこもそうだけど 最初にぼかして作ってあとから仕様押し込んでくるユーザいるんだよなあ（なおじちたい）

[kappa9]

DDDとかアジャイルとか、業務担当者と開発エンジニア（中間管理職やコンサルではなく）が協力して良いソフトウェアを作るとかいうストーリーはおとぎ話なの？

[ryotarox]

機能ならこの考えで行けそう。情緒的な品質はどうか。広告のアイデアとか役者の芝居の質とか。試行錯誤して正解を探すというフロー。「振り向く芝居だけ何十回もリテイク」の世界。／共創は、共に行う要件定義とも。

[panoramaafro]

完全に世界に遅れてるんだと認識した。やりたいことがあったら外注するのではなく、既にサービスを始めているところを買うべき。要件から始めるから微妙なものが出来るんだけど、みんなそうじゃなさそうでビックリ。

[queeuq]

率先して3億回読んでその様子を毎日YouTubeに上げ続ければ読む人増えると思うんで今日からやってくれ

[robeht]

読む

[khtno73]

とはいえお客はIT素人、SIerはお客のビジネスの素人だから設計やテスト段階で要件漏れは見つかる。それが本稼働に不可欠だったり要件外は有償でも予算取れなかったり。納期と予算は変動するという事前認識共有が肝。

[ghostbass]

責任は依頼側だけど作れって書いてなく無い？

[misochige]

「３億回」という無責任かつ無根拠な要件定義をするような人が褒めている時点で読む価値を感じなくなってしまう。

[uva]

「あくまでも発注者の仕事であり、発注者の責任で行うものです」「その責任を受注者に負わせることはできません」

[sabinezu]

金払ってる方がエラいって文化をまず無くすべき。

[nori6810]

3億分の2読みました！！

[outroad]

日本では貸し手責任の話はあまり出ないけど、発注者責任の話は出ているところから見ても、金融よりもITのほうが進んでいるね。

[Lat]

私の場合は要求定義と検収条件（暫定）も合わせて準備する。要求定義をちゃんと書かないと検収条件（暫定）も曖昧になってしまい結果として検収時に困るので検収条件（暫定）も事前に社内で許可を取ることにしている

[nyokkori]

俺が要件定義で一番大事だって言ってた事が出来るって言うから頼もうとしたのに、何回か打ち合わせして出来ないって言うからやめた。

[roomrii]

( ..)φメモメモ

[fcqpy455]

発注側も受注側も設計も開発も、コアなところは自分1人でつくるのが一番手っ取り早い。それであれば管理もいらん。途中でやめたい機能があればやめれてもいい。ポイントは優秀な人間を雇い信頼してまかせるかどうか

[yfukuda827]

大事なこと。要件定義に関わる人は、業務と事業の両方知っていることと決裁権を持っておいてもらいたいです。