body { -ms-overflow-style: scrollbar; overflow-y: scroll; overscroll-behavior-y: none; } .errorContainer { background-color: #FFF; color: #0F1419; max-width: 600px; margin: 0 auto; padding: 10%; font-family: Helvetica, sans-serif; font-size: 16px; } .errorButton { margin: 3em 0; } .errorButton a { background: #1DA1F2; border-radius: 2.5em; color: white; padding: 1em 2em; text-decoration: none; } .errorButton a:hover, .errorButton a:focus { background: rgb(26, 145, 218); } .errorFooter { color: #657786; font-size: 80%; line-height: 1.5; padding: 1em 0; } .errorFooter a, .errorFooter a:visited { color: #657786; text-decoration: none; padding-right: 1em; } .errorFooter a:hover, .errorFooter a:active { text-decoration: underline; } #placeholder, #react-root { display: none !important; } body { background-color: #FFF !important; }

JavaScriptを使用できません。

このブラウザではJavaScriptが無効になっています。引き続きtwitter.comを利用するため、JavaScriptを有効にするか、サポートされているブラウザに切り替えてください。サポートされているブラウザのリストについては、ヘルプセンターをご覧ください。

ヘルプセンター

利用規約プライバシーポリシー Cookieのポリシー Imprint 広告情報 © 2022 Twitter, Inc.

「いま」起きていることを見つけよう

Twitterなら、「いま」起きていることをいち早くチェックできます。

アカウント作成

スレッド

会話

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

午後0:23 · 2022年12月3日

件のリツイート

件の引用ツイート

件のいいね

返信先:

さん

ipa.go.jp/files/00000510 リンクはこちらです。

1

23

60

要件定義フェーズでちゃんと出せたのは「要件」で後続フェーズで後出しジャンケンしたのは「仕様変更の要求」だからな！ amzn.to/3Fk2SSf 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書 amzn.to/3H6Fv0G だまし絵を描かないための要件定義のセオリー

図解即戦力要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書

図解即戦力要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書

1

17

80

言うても、私たちが「家を作りたい」って思ったとき業者に「全部発注者の責任です」って押し付けられるのは辛いよね　プロじゃないから。つまり、業務要件（発注者の願い）と製品仕様（プロが責任持つところ）が重なったところが「プロジェクト要件」になるわけです

20

90

一個アイデアとしては小さいプロジェクトの場合作業工程に要件定義（お客様作業）要件確認（弊社作業）と明確に書いて理解してもらうってのも手です。まあ作業工程を確定する前に書き直しさせられる場合もありますが

2

20

返信先:

さん

発注者が読まないところに書いても…中学校の男子便所に「スカートの丈は…」と書いても意味ないでしょう

1

1

5

返信先:

さん

確かに！よけい溝は深まるばかり

1

@ShibuyaGirl0203

返信先:

さん

つまり、富士通もNECもIBMもなんの責任も負わなくていい！！！！！

1

1

2

返信先:

@ShibuyaGirl0203

さん

ベンダーはお金もらってなんの責任を追うの？って言う真面目な話は置いといて、これをTシャツにして街を歩きたい！これをリモート会議で画面共有したときの壁紙にしたい！伝われ〜　って思います

1

2

返信先:

さん

本当にね…。自社の業務ぐらい把握してから見積もり依頼しろよなぁ…「本当によくそれで発注の稟議通りましたね」って案件、あるからなぁ。

1

1

2

返信先:

さん

（あえて）敵側の情シスは、業務やってるわけじゃないので要件を出しきれない。システム制約について業務部門を説得しきれない。結果、ベンダーに強く当たるしかない。あなた達はなんのためにいるの？？ってなります。

1

3

返信先:

さん

要求が曖昧なのに受け入れが厳しいとゴールポストが動くのでもう悪夢でしか無い

受注側が定義するのは自衛って意味合いも有ると思います

1

1

2

返信先:

さん

動くゴールポスト！この例え大好き！　動いて逃げるゴール、迫る納期！

2

うみんちゅ＠中受2025進学くらぶ

返信先:

さん

なんか古き良き日本のレガシーなシステム開発現場が想像できますね～　指針作成者がほぼすべてSIer

. SaaS入れる時はまた違う切り口な気もする。いずれにせよ諸悪の根源は事業会社のインハウスのシステム部門のほうだが、日本の経営者のIT調達スキルが低くてどうしようもない。

1

2

3

うみんちゅ＠中受2025進学くらぶ

返信先:

さん,

さん

もっと最悪なのは、この一見正論っぽい持論を、システム部門が開き直って事業会社内で持ち込んで社内のDX化を阻害してるケースが散見。この指針はSIer対事業会社の話であり、事業会社内は部署間でそりゃスキルの濃淡あるしさ。

2

2

5

返信を表示

返信先:

さん

それを発注者に理解してもらう方法が知りたい

1

3

13

返信先:

さん

私は要件定義書の冒頭に、発注側は業務要件を出し切る。開発側はシステム要件、制約、仕様を出し切る。2つの円が重なったところが今回の「プロジェクト要件」って定義するようにしています。それでも伝わりません！！

6

33

返信先:

さん

発注側の情報部門がクソ過ぎて現状分析や要件定義が出来ないからそこら辺の工程では自称コンサルを名乗るシステム屋が発注企業に入り込み適当に時間つぶして金をふんだくるその後、そこら辺の開発会社に「要件定義までは終わってますんで～」と放り投げるもちろん要件定義などほとんどされておらず

1

1

7

返信先:

さん

作り逃げのほうがまだいいですね。作ってもいない！！笑

1

返信先:

さん

昔、言われたなぁ。「請負契約」は請けた時に勝負は着いているなので、なんとかしろ。「委託契約」は丸投げなんだから、何故発注側が考えないとだめなの？って。

1

1

6

返信先:

さん

自分たちができないことをお金を払ってまでお願いしてる。っていう気持ちを持ってほしいですよね。缶ジュースも130円の価値と考えるのか「この容器やこの味が自分で130円で作れるか？」って思ったらもっとお互い謙虚になれる気がします

1

11

返信先:

さん

その通りなんですが自分が何をしたいかは結構分からないんですよねー。それを一発で表現できる人は5%ぐらいな印象です、

1

2

8

返信先:

さん

そのとおりですよねー移動手段を「馬」しか知らない人に要件定義したら「もっと速い馬がほしい」しか言わないですね目的をしっかり明確にすれば「車」も提案できるのにって思いますまあそれも出てこないですよね！

1

3

9

返信を表示

ゴリラ系ITコンサルタント

返信先:

さん

発注者の責任であることは間違いないが、それはつまり受注側はぶん投げていいを意味するわけではない。抽象的な発注側の要件を、受注側は具体化させる責務はある。その中で、あまりにも要件が膨れ上がる場合はコストや納期の調整をする、そんな当たり前ができるPMがあまりにも少ないのが悲しい現実。

1

1

返信先:

さん

そのとおりですね。双方の役割分担、責任範囲を明確化して安全にすすめられるPMが増えるのを願うばかりです

うぃんうぃん♬

返信先:

さん

これは分かるのですが、真実は受注までのプリセールスである程度、受注者側がやってる雰囲気になるので難しいんですよね

なので、しっかり工程(今、なにやってるか)を切って意識合わせをする様に心掛けてます

1

1

1

返信先:

さん

素晴らしいですね！工程しっかり切っても、まだ追加の要件出してくるひとって多いですよね。最悪丸投げでもいいから、仕事のルールは守ってほしいですよねー

返信先:

さん

「それは（要件定義）、あくまで発注者の仕事であり」かぁ～。ずいぶんと、発注者に代わって要件定義書、作ったなぁ。

1

1

返信先:

さん

深みある感想！！業務のプロ（顧客）とITのプロ（ベンダー）が必要なところを書くのが理想ですよねー

1

佐々木⋈和守

返信先:

さん

なるほどワイは悪くねぇ…。

1

1

返信先:

さん

悪くないです！きっと！助け合いましょう

返信先:

さん

「IPA…？聞いたことないから無視してええやろ！、17項目とか読ませる気ないしな

1

1

返信先:

さん

「IPAの基準では...」で説得できる顧客と、「は？何それ？」みたいな顧客がいますよね

1

1

返信を表示

@kigurumisabrina

返信先:

さん

当たり前なんだけど、発注者の後出しジャンケンが多すぎるもん！しかも、当然のように（＝追加費用なし）言ってくるから、タチ悪い。

1

情シスマン__情シス一筋14年

返信先:

さん

うっ。理解してますが、情シスからすると要件依頼だして、一緒に要件定義してくれて、システム設計はこちらにも分かりやすいのを作ってくれる。そんな業者を選びますね。丸投げする気はないんですが、今の人員で他の案件、業務しながら、漏れなく要件定義はできないです。業者さん感謝してますよ。汗

1

1

返信先:

さん

板挟みな立場ですねー

経営側がリソース配置をもっと考慮してくれたらいいんですけどねー開発側としてはとにかく「実現したい業務」を教えてほしいですね。何がやりたいか。なぜやりたいかそれさえ業者に伝われば、きっといいシステムを一緒に作れるはずです

@migratoryfish2

返信先:

さん

顧客「んーそんなこと聞かれてもよくわからんからいい感じで！」僕「」顧客「納期はなるはやね！」僕「」(昇天)

1

1

返信先:

@migratoryfish2

さん

大泉さん「僕に魔法を使えってぇのかい？」

返信先:

さん

システムを「銀の弾丸」だと考えている経営者と、「私、こういうの苦手なんですよね〜」と前置きする担当者があいも変わらずたくさんいます。結果、使われないシステム・動かないシステムが生産され続けてます。

1

1

返信先:

さん

システムのことはプロに任せていいので「御社は何がやりたいか」と「なんのためにやりたいか」は、ベンダーでは答えられないので、そこは考えてほしいですねー

ｻﾓｲﾀ@VBAって凄すぎ

返信先:

さん,

さん

「要件定義は発注者の責任である」なので要件定義までやると儲かります。皆さん「客の仕事だ」と言ってやらないから。ニッチな部分←ここが儲けの源泉だと思います。

1

1

テレワーカーY

返信先:

さん,

さん

要件定義のお手伝いをするするコンサルも、けっこう儲かりそうではあります。自分で頭使うべき所を外注すると、それ相応の費用はかかりますね。

1

Twitterを使ってみよう

今すぐ登録して、タイムラインをカスタマイズしましょう。

Appleのアカウントで登録

電話番号またはメールアドレスで登録

アカウントを登録することにより、利用規約とプライバシーポリシー（Cookieの使用を含む）に同意したとみなされます。

トレンド

いまどうしてる？

音楽

ライブ

BTS・ジンさんの誕生日

スポーツ · トレンド

WBC辞退

1,573件のツイート

日本のトレンド

兄弟愛重すぎ

トレンドトピック: #水星の魔女、エアリアル

エンターテインメント · トレンド

座布団10枚

1,731件のツイート

日本のトレンド

国民栄誉賞

トレンドトピック: 官房副長官

さらに表示