2022年12月4日

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

620
nori @00oichan

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

onl.la/SMiY8gL

nori @00oichan

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

2022-12-03 21:23:56
拡大
nori @00oichan

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

2022-12-04 05:59:47
nori @00oichan

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

2022-12-04 06:16:57
nori @00oichan

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

2022-12-04 12:49:02
zip_pod @zip_pod

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

2022-12-04 01:22:54
nori @00oichan

@zip_pod 確かに! よけい溝は深まるばかり💦 👼👼👼

2022-12-04 07:56:32
ShibuyaGirl @ShibuyaGirl0203

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

2022-12-04 01:46:52
nori @00oichan

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

2022-12-04 07:54:34
isoo @isoo_

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

2022-12-04 03:20:46
nori @00oichan

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

2022-12-04 07:51:30
どるけん @doruken1795

@00oichan 要求が曖昧なのに受け入れが厳しいとゴールポストが動くのでもう悪夢でしか無い😭 受注側が定義するのは自衛って意味合いも有ると思います

2022-12-04 04:02:48
nori @00oichan

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

2022-12-04 07:48:34
うみんちゅ@中受2025進学くらぶ @umichu2522

@00oichan なんか古き良き日本のレガシーなシステム開発現場が想像できますね~ 指針作成者がほぼすべてSIer😀. SaaS入れる時はまた違う切り口な気もする。いずれにせよ諸悪の根源は事業会社のインハウスのシステム部門のほうだが、日本の経営者のIT調達スキルが低くてどうしようもない。

2022-12-04 04:20:12
うみんちゅ@中受2025進学くらぶ @umichu2522

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

2022-12-04 04:45:24
hale626 @hale626

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

2022-12-04 04:46:18
nori @00oichan

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

2022-12-04 07:42:49
K3_14 @K3_14

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

2022-12-04 05:01:40
nori @00oichan

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

2022-12-04 07:39:36
ひらがな @hiragana_sugi

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

2022-12-04 06:07:08
nori @00oichan

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

2022-12-04 07:38:01
ジラフ🦄🦒✝️ @Giraffe20201

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

2022-12-04 08:02:39
nori @00oichan

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

2022-12-04 08:25:56
ゴリラ系ITコンサルタント @5umerag1

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

2022-12-04 10:18:22

コメント

かえる @Ein_Frosch 2022年12月4日
何か作る際の発注者になることは絶対あるので全人類百遍読みましょう 素人だがらわからなかったじゃないんだ、わかるように説明して納得したのに無かったことにしてるだけなんだ
47
みなせ ★C101 コミケお疲れさまでした @Ton_beri 2022年12月4日
システムわかんなくて、要件定義できない発注者は、別途コンサル入れてくだしあ。 おう、要件定義まで受注者にやらせるんじゃやねーぞ!!!!! 何が「そっちで代わりに仕様書書いて」だよ
64
サカソウ @suckaso 2022年12月4日
責任分界点の共通認識を作るのは大切ですね ただそんなことができる発注者は、問題があっても自力救済ができるんじゃないでしょうか 要件定義もできない顧客がいるからこそ、コンサルやプロジェクトマネジメントのビジネスチャンスだと思います
22
. @shichinan 2022年12月5日
発注者の脳内にある曖昧なイメージを聞き取りして具体的な仕様に落とし込んでいく所からSEの仕事だと思う。だからこそSEにはコミュニケーション能力が必要とされている訳で。ITに限らず受注業務なんてこんな物ですよ。要求仕様すらほとんど固まってなくて受注側が提案する必要がある事など日常茶飯事。
20
Hacchi @2mocccck 2022年12月5日
だまし絵を描かないための~は大して役に立たないから読む必要ない。要件定義がいかに低レベルな人材によって行われてるかという視点では勉強になるかもしれないけど。よほどの第一人者が書いてるならともかく、具体例も挙げない引用もない技術書なんて技術書とは呼べない。「モデルベース要件定義テクニック」とかのほうが推せる。
2
Done @dan_ren_youxi 2022年12月5日
発注者は何が作りたいかはっきりしてるけど、現場の希望確認しないまま使いにくいシステムを沢山開発してくるのもあるからな 弊社のことなんだけど
31
うらっち🇺🇦 @TKHLR 2022年12月5日
お客様に「要件定義書作成」を請け負った某ITサービス会社についてwww
1
YOGAKUTIME @YOGAKUTIMEMAN 2022年12月5日
「みずほ」の三文字で決着がつく問題よね。現場のスタッフは3行のシステムをチャンポンにして入れ子細工な構造にするのを最初から反対していたわけでね。
4
あるウソつき @akiyo_s_jp 2022年12月5日
そんなんわかってる。でも、ユーザは頑なに「動かしてみないとわからん」と言うのよ。で、実際そうやと思う。SEはトライ・アンド・エラーの果に、めっちゃ詳しくなれるけど、こんな初期の段階で要望に対する問題点とか補足しておくのは無理。結局「責任を取らされるところはどこやねん」の問題なんだよね
8
犬だよ @yaju5123 2022年12月5日
書いてる事はごもっともだけど、顧客側がカッチリ要件定義出来る会社なら、そもそもこの手のトラブルにはならんと言うね。
21
NOWAR🦑🔫🐙 @NOWAR_ika 2022年12月5日
昨日のテレビの新海誠と野田洋次郎のメールやり取りみたいなやつか。そう考えると新海誠監督は的確な要件定義だったんやな。
0
山の手 @Yamano_te 2022年12月5日
suckaso 「でも要件定義のやり方なんてわからない。どうすればいいんだよ」という会社のために、ITコンサルが存在するんですよね。腕のいいコンサルって「顧客が本当に必要だったもの」を明確化、文書化できる。腕の悪いコンサルや悪徳コンサルになると、現場の声の吸い上げや顧客の方針を無視して、売りたいものを押し付けるための口八丁手八丁になるんでしょうけど。
1
寺33 @tera3333 2022年12月5日
数年前の独立行政法人案件は担当者が「仕様書にできないと書いていないことは全てやる義務がある、やれ」とかむちゃくちゃなことを言い出してたな。独立行政法人全てダメとは言わないけど典型的な政治力に全振りした無 能な働き者が散見される魔境なので諸々慎重に関わった方がいい。
8
ettolrahc @ettolrahc2015 2022年12月5日
Yamano_te そのクソコンサルが圧倒的に多いから困りもの
13
山の手 @Yamano_te 2022年12月5日
ettolrahc2015 それが否定できないことが悲しい
3
PECMM🍼♣️🐶🎈🐥🤞@副菜勢 @HNST_PECMM 2022年12月5日
IPAのITパスポート試験が技術者向け入門試験ではなく、『どのような業種・職種でも、ITと経営全般に関する総合的知識が不可欠』であり『ITを利活用するすべての社会人』向けを謳っているのは、こういう理由もあるんでしょうねー。 ITシステムの利用者側もちゃんと知識つけておけよ、と。 (それにしてはシラバス見る限りわりと技術者寄りというか、テクノロジ系の比重そこそこ高めって気がしなくもないが……)
5
ねこぶみ 可愛らしいおつむ @neko_bumi 2022年12月5日
Yamano_te 期待されているコンサル「業界で長く培ってきた経験を活かして道筋を立てます」実際に触れ合えるコンサル「よーしはじめての業界だけど頑張るぞ!もしもし協力会社?この技術入れてやりたいんだけど技術検討お願いできる?」
2
いるーか @iruka12go 2022年12月5日
「動かないゴール」これほんと大事
4
たらった @taratta 2022年12月5日
最近はみんな忙しいから発注者側も自社の業務把握してないところ多いからなぁ。
0
databeing1357 @databeing1357 2022年12月5日
Ton_beri クソコンサル「コードを書くなどの単純作業に要件定義は不要」
0
フ一口 @fu_hitokuchi 2022年12月5日
本当に業務を知っている発注元の社員は業務を回さないと会社が破綻するので要件定義に参加できないので、半端な人が出てくる。コンサルはよく知らない人から半端な知識を聞いただけなので見た目だけそれっぽいけど役に立たない資料しか作れない。受注側は当然ITの仕事しかしたことないので発注元の仕事なんて分からない。終わりです。
8
笹かま @voyageur105 2022年12月5日
潜在的ニーズも掘り出して商機につなげたりもするからなあ。
1
月岡師水 TSUKIOKA Shisui @CommandWater 2022年12月5日
こんなの読んでくれるような発注者がこの世にいるのか?発注書すら書かせるようなゴミばっかやのに
1
らぃりる @Liriru 2022年12月5日
家を建てるときーって言ってる人いるけど、家の場合であれば「何人が住む想定なのか」「風呂、トイレはどこにいくつほしいのか」「部屋数とその割り振りはどうするのか」「台所と食堂はつなげるのか」とかそういう話を整理していくのが「仕様の要件定義」なわけで、家を建てるプロでなくてもこれはできるでしょ?現在のシステム業界はこれをシステム屋にやらせて、形ができたものに文句をつけて金は積みなおさず修正させるのが普通になっているという問題。
11
k9cycle @__hage 2022年12月5日
要件定義は発注者の責任ではあるんだけど、作るこっちとしても前もって齟齬がないようにしたいので定義の場に参加して質疑したりとかすることは全くやぶさかではない。完全にそっちで作ってからよこしてね、なんて横着はしないっすよ。入札案件ならまだしも。ただし口出ししたという点を人質にとってこっちに責任かぶせてくるのはやめてねって話っすよ。
5
不可思議$ @fukashigidollar 2022年12月5日
まあこれはそのとおりですわ  そこをなんとかして調整するからお仕事もらえてるってのはあるんだけどさ、それにしても前提として発注者責任の意識はないと困る。 せめてわからんことはわからんと自分の責任で言ってほしい。「こういう点がわからないから力を貸してください」ならお互いいい仕事になる。でも「わからんのはそっちの責任で全部うまくやってくれ」が多いんだよなあ・・・
3
不可思議$ @fukashigidollar 2022年12月5日
あと逸れた愚痴になるけどさ・・・ 一番ひどかった例は「部署の新年度の目標作って」だったな・・・  こちとら「外注の」「技術者」やぞ 要件定義どころかなんでそんな部署の向く方向まで作ってやらなあかんねん・・・(なおいろいろあって結局作った) 要件定義ですらよそ任せはおかしいってのに、もっとひどい例に出くわすとは思わなかったよ・・・
5
nekora2520 @nekora2520 2022年12月5日
そうは言っても畑違いのコンピュータシステムの要件とかおいそれと作れるわけがないのだから、準委任契約でSIerに任せれば万事解決。
2
掛居明彦 @KakeiAkihiko 2022年12月5日
そもそもSIは発注者の事業であって、発注者が素人面するのはおかしい。家を建てる比喩も少し違っていて、発注者の自社ビルを建てる方が近い。
1
neat @neat2103 2022年12月5日
えっ?要件定義って受注側が作るものじゃなかったんですか!?
1
ぱらりらぱらりら @eCA9xbdW4twS6Eb 2022年12月6日
まだ「紙で書いてるのをシステムにしたい」ならワンチャンフローの洗い出しと紙の帳票を全部出してくれればやれんこともないけどね
1
う"るすと @wurst20821 2022年12月9日
Liriru 構造力学上最低限必要な耐力壁の位置や量、ガスや上下水道の配管、臭いや熱気や湿気の空間的対策、家人に要介護認者や小さな子供が要る場合の安全対策や導線確保、...etc.を全無視して、良くて最悪の、悪くてそもそも物理的に成立しない「ぼくのかんがえたさいきょうのいえ」のラクガキを「要件定義」と呼ぶなら、プロじゃなくても”出来る”だろうけど…
0
ファング・リウ @FangRyu 2022年12月10日
HNST_PECMM 昔、初級シスアド試験があらゆる企業内の情報システム要望に対しベンダーなどの間に立って要望を伝える者が持っておく試験、で始まったのにその内容からパソコン初級試験みたいになってしまって結果ITパスポートって出来たんだわ…orz だからこんなことになったのも自明の理でな。
1
あるウソつき @akiyo_s_jp 2022年12月11日
neat2103 多分元ツイの人はわかってて前提を隠していますが、要求定義も要件定義もエンジニアの仕事です。ただ、基本設計以降を別会社へと「発注」するケースが、規模が大きければよくあります。
0