2020/01/12 12:18
teppei-884
メモメモ
2020/01/12 13:27
shufflingpixie
Qiitaには珍しい上流工程の記事。開発者側の知識だが、発注者側も理解して手を動かせると圧倒的にコストが安くなる。
2020/01/12 13:39
otihateten3510
最近ますます要件定義フェーズが存在感をなくしていると思う。要件定義工数ってちゃんと取れるんだろうか？工数取れないとこういうことできないんだよね。　まあ俺の観測範囲の問題か。
2020/01/12 15:12
turanukimaru
良くも悪くも伝統的なやり方。これが出来れば最悪でもgdgdにはならない。何を作ればいいのかお客さん自身が実のところ分かっていないってのがシステム開発の最大の難所なのでやり方は有れどなんとか形にするしかない
2020/01/12 15:47
swdrsker
上流工程の話
2020/01/12 16:08
Yoshikawa
記事のように要件は要望や要求がある程度明確になっていれば定義可能。が、実際には「困っているからどうにかしろ」「何でも良いから解決しろ」程度の願望や愚痴のことも多く、その場合まず課題整理や構想策定が必要
2020/01/12 16:20
lorenz_sys
"のどが渇いた時に「飲み物買ってきて！」とお願いするでしょうか？" システム開発のお客さんは「なんか買ってきて！」とか「ロマネコンティ買ってきて！千円しか出せない！いくら飲んでも減らないやつな？」とか。
2020/01/12 16:22
saruzo69
“要件定義～システム設計ができる人材になれる記事”
2020/01/12 16:50
tossy_yukky
とてつもなくウォーターフォール臭がするけど、一人で作るんでも脳内でこれやってるわけだから、これができないとダメってのはそうなんだろな。
2020/01/12 17:02
kazkaz03
python関係なくね
2020/01/12 17:24
hiroomi
”勉強してもプロダクトが作れない”
2020/01/12 17:27
findup
レガシーかもしれないけど、今ドキの開発なら単にプロダクトオーナーがこのあたりをお膳立て済みだから開発者が意識しなくて良いだけになってるからでは。誰かがやらないといけないことだと思うけど。
2020/01/12 17:39
thesecret3
なぜうまくシステムができないのかがよくわかる。
2020/01/12 17:45
omega314
どうでもいいが、「客に言われたものをそのまま作ったらダメ」と言う奴が自分ではお客さんに説明や説得する気は無さそうに見えた回があってちょっとイラッとしたのを思い出した。
2020/01/12 17:50
ippatsu2009
要望、要求と要件の違い、初めて知りました。
2020/01/12 18:12
hara_boon
あー、こういうのが欲しかったんだよな。上流やったことないからイメージわかなくて、調べると詳細資料しかないからこれくらいざっくりしたものから入るとイメージしやすくていいな。
2020/01/12 18:29
Soraneko
要望・要求定義が難所
2020/01/12 18:37
lochtext
こういう記事ってなかなかないよね。
2020/01/12 18:54
cameraojisan
なんでもそうやな、と思ったけどよく考えたらシステム自体がソフトウェアエンジニアリングだけのものではなかった
2020/01/12 18:59
tsutaken
（発注者）と書くと受託開発限定っぽく見えるので（オーナー）とした方が良いのかも。
2020/01/12 19:15
PrivateIntMain
お客さんが「企画」「業務設計」まで済ませられればいいが、基本お客さんがは困っていてそれどころではないのでその時点から携わることになるし、お見積り無料でしょみたいな雰囲気で来るのでしんどいことはあった。
2020/01/12 19:18
lacucaracha
パッケージ導入が主流になった現在、要件定義なんて形式的なものに過ぎず、ほぼ要求分析（つまり発注される前）に決着をつけておくべき事例が増えている可能性がするのね。
2020/01/12 19:39
shunt_i
要件定義
2020/01/12 19:56
kkoiro
素晴らしい
2020/01/12 20:22
testedquality
これをお金出す人も一緒に作って理解するのが、一番確実にシステムができる方法だと思ってる。そして往々にして早く安くなる。コード書けなくても欲しいものの判断はしてくれ。使うのはあなただ。
2020/01/12 20:33
monster-energy-zx14
残念だけど要件定義に携われることは元請け企業しかできないから、SIerヒエラルキートップか、事業会社に入社するかしないと意味無いで
2020/01/12 20:41
airj12
いきなり開発依頼してくる顧客候補に対して、要件定義→要求開発→課題と要望の整理、と遡れるかどうかで成否が決まる
2020/01/12 20:44
uefi
「要件定義」って、元請けの大手さんがピンハネの根拠にしてる謎の行為のことですよね？
2020/01/12 21:00
sai0ias
自社サービスとかだとサービスデザインやら売上目標やら事業計画みたいな話も絡んでくるのでややこしい。
2020/01/12 21:11
hamlet-r
画面から先に入って、データベース後とか本当？確かに現場の顧客には、UIのインパクトが大きいんだけど、後で予算に権限を持つ経営陣に必要な情報が充足しておらず、落第点をもらったシステムを聞いたことあるけど。
2020/01/12 21:17
odakaho
下流に設計書をぶん投げて６割ハネるお仕事は美味しいですね。
2020/01/12 21:24
table
発注者側のアイコン数が足りない。少なくても5人は並べて欲しい
2020/01/12 21:28
oceantug
要件定義の成功条件は、①発注者側に業務だけではなくITにも詳しい人間を１名、②受注者側にITだけでなく業務にも詳しい人間を１名準備すること。この二人を個室に閉じ込め差しで要件定義をやらせる。
2020/01/12 21:33
tmae
分かりやすい
2020/01/12 21:38
heica
知ってました？システム開発って本当に二度と同じ開発がないので、経験が伴わないと何にもできませんよ。理論だけで頑張るなんてことはできないのです。
2020/01/12 21:46
kantei3
ソフトウェア工学なら一回分の授業にしかならない。
2020/01/12 21:57
sakana1022
金を払う側は要望しかなくシステム要件になっていない。要件を明確にしないまま開発を進めると『認識の不一致による手戻り無限ループ』が発生し、言った言わない金払う払わない問題発生。要件定義、めっちゃ大事。
2020/01/12 22:12
yug1224
各画面にはどんな項目が存在しているのか。どんなユーザ操作があり、システムはどんな反応をしなければならないのか。そのためにはどんなデータが必要になるのか。ってことをちゃんと上流工程で握っておきたい。
2020/01/12 22:13
tpircs
自分はアジャイルソフトウェア開発信者だけど、この記事はとても良い記事だと思った。やり方は違えどこういう順序だてた考え方は大事だと思う。
2020/01/12 22:14
aves_ramphastos_toco
画面から入るならWeb系か小規模やろね。メタ要件というか「社長がやれって言ったからとりあえずやってるけどワイらは社長のご要望知らん、いい感じでオネガイ！」みたいなヤバみが深いやつもたまにある（蹴ろう）。
2020/01/12 22:23
halix
うっ…WordかExcelで作られた要件定義書…頭がっ…！
2020/01/12 22:31
ducktoon
プログラム書けない、興味ない、やりたくない、絶対やらない、ような人は設計すんなよ
2020/01/12 22:34
carrier_pigeon
非機能要件蔑ろにしすぎ感があるなぁ。性能、セキュリティ、メンテどうするとかリカバリとか。オペレーション重要。むしろそこに見積もり載せる説明できないと、機能要件だけで金取るとあとで死ぬ。
2020/01/12 22:38
beh1st
要件定義から基本設計までの概略
2020/01/12 23:23
tydk27
転職しなかったら、ガッツリこの道に進んでいたのかなぁと。
2020/01/12 23:31
diveintounlimit
あぁSaku731の人か。この人の書く記事は懇切丁寧で好感が持てる。
2020/01/13 00:57
toro-chan
最近全く使わない知識なので、懐かしい感じで眺めた(読んでない)最近は、アジャイルで、プロトタイプ開発(流用予定)なので、まず作ってしまう。当然、文書はすべて後回しだ。。
2020/01/13 01:09
tfurukaw
よくまとまってて良記事だとは思うが、コレを読んだら要件定義～設計ができるようになるかと言われると、そんなに甘くないとしか言えない（＾＾；でも調整事・駆け引きは実践で学んでいくしかない。
2020/01/13 01:12
yamadadadada2
脱線しちゃうけどそもそも企画が駄目なのにとにかくリリースしまくって負債だけ溜まっていくけど企画した人は責任とらない現象つらい
2020/01/13 01:13
papapaaaanda
これ、意外とできない人多いよね
2020/01/13 04:04
nyan-nyan-nekoga-one
大手の開発は、この内容通りだね。小さい開発だと設計を端折るので、この考え方が見に付くと自分が製造する時、戻りが少なくなるので楽。。
2020/01/13 04:42
mottii-cocoa
ためになる話
2020/01/13 06:46
sohelrana24q
support.google.com
2020/01/13 07:47
arakik10
システム発注する側が読むべき資料かな
2020/01/13 07:50
defsa34
あとで読む
2020/01/13 08:02
mmr1203
これこそ発注者側に読んで欲しい。お互いが知っていればスムーズにことが進むし。（理想論
2020/01/13 08:07
t-murachi
実際の仕事に置かれましてはお客様の方で勝手に練り上げられた設計のようなものに対し、ヒアリングを重ねた上でそれではお抱えになっている問題を解決できないことを懇切丁寧に説明しご納得頂くところから始め文字数
2020/01/13 08:54
yuki_2021
重要な話だよな。最近勉強したいと思ってる。
2020/01/13 09:39
azuk1
この辺は自分の経験を通して形にしていかないといけないので、触りだけ教育されて現場に放り込まれた新人PMの案件は大体火事になる。もっと抽象度減らしていかないと誰でもできる仕事にはならないんだよな。合掌
2020/01/13 09:58
braitom
実装の前に必要ないわゆる上流工程について解説した記事。要件定義の必要性やプロセス、画面設計/機能設計/データ設計などの基本設計の作り方などがまとめられている。
2020/01/13 10:24
masakitk
患者さんが自分の病気の病名と原因と対処法を知らないように、お客さんが自分が欲しいものを知っている前提で進めてしまうと大体あとでもめる。
2020/01/13 11:52
hasefumi23
sd
2020/01/13 13:52
pikio
端折ったWhatのとこ、重要だと思うけどな
2020/01/13 15:37
frozen_faithjp
“まとめる”
2020/01/13 15:54
kat21
ほぼ網羅されててとても良い。あとは非機能要件があるともっとうれしい。
2020/01/13 17:13
kdmsnr
羽生さんの本のパクりっぽいので、参考文献に載せたほうがよさげ（Qiitaだから仕方ない感はあるけど。。。）
2020/01/13 19:28
piroshiii
例題のER図はヤバい。購入履歴に価格や商品名は入るべきで、その時点のスナップショットであるべき。商品値下げしたら履歴から追えないぞ。
2020/01/14 15:31
yojik
羽生さんの「はじめよう要件定義」の丸パクりなんだけど、Qiitaの規約的にどうよ。