完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita

ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれません。気になる章をピックアップしてお読みいただければと思います。 目次 1. はじめに 2. 要件定義とはなにか 2.1. ソフトウェア開発ライフサイクルの全体像 2.2. 要件定義の役割 2.3. 要件定義が肝である 3. 完璧な要件定義など幻想である 4. なぜ要件定義は不完全なのか 4.1. 要求は変化し続ける 4.2. 時間軸を考慮する必要がある 4.3. 一人の力には限界がある 5. 良い要件定義とは 5.1. UXから逆算する 5.2. 削ぎ落とす 5.3. 個ではなく、チームで作る 5.4. レビューを徹底する 5.5. 3つのシナリオを想定する 6. おわりに 1. はじめに 株式会社じげんの廣瀬です。 企画マーケティングユ

[kuni530]

Qiitaのコメント欄に書いてあることが深い「一番の問題はお客の要望が間違っている場合が意外と多い事」

[turanukimaru]

また「誰」が抜けてる要件の記事だ…ユーザだのUXだの言ってるけど「ユーザとはいったい誰なのか？」の話をしてないじゃん。「誰」の要件か分からなきゃチームで相談しても「なんとなくこう思う」しか出てこないよ。

[jacoby]

そもそも要件は時間とともに変化するから完璧な要件定義は無理です。ただ要件に優先順位つけて大まかなアーキテクチャはできるだけ固めた方がよい。

[circled]

お客様「チェーンソーが欲しい」コンサル「お前が欲しいのは正確なサイズに切られた木材だ。俺に金を払えばそれを最適な方法で手に入れてやろう」ニトリ「それで作りたい家具をお値段以上で提供しております」

[sato0427]

完璧な要件定義などといったものは存在しない。 完璧な絶望が存在しないようにね。

[jiro68]

これもエンジニアサイドの発想。WhyとWhatはとても重要なのだが、担当者の理解レベルではなく、その根源まで遡ると Why も間違っている事が多い。時間があるなら会社の方針や5年計画レベルまで辿って整合性を見ると良い

[daruism]

タイトルみて「要件定義ってのはバカ」ってイーロンの言葉を思い出したが普通に記事の中に出てきたわ

[tanority]

現場ではいいから作れ！としか言われてないような

[eichisanden]

要件定義のWhyやWhatが間違った上でさらに念のため必要と機能モリモリされるのが1番最悪

[morimarii]

ユーザーと顧客の区別ついてますか？

[style_blue]

コメントにあるお客の要望が間違えてるという件、今やってる業務をシステム化ってのが顧客の要求で、システム化ってのはそーじゃないんだよというのがシステム屋の仕事ってやつだね。

[diveintounlimit]

チームでいい感じに仕事した感を出して及第点を弾き出す感じ。微妙。暇なんかな。

[queeuq]

書いてることあんま違和感無い。完璧を目指すより不完全であるという前提でそれのマネジメントをしたほうが良い。

[rgfx]

良い / これを思い出す→"不確実性を人間の能力に押し込んで見なかったことにするのがアジャイル/プロセスに押し込むのがスクラム/計画に押し込むのがウォーターフォール" https://twitter.com/tokoroten/status/1473169587374272512

[sorosoronemui]

確かに、一番始めにお客の本当にやりたいことがお客の言う要望と合っているのかを確かめることを先にするね。

[yukimi0721]

そして何も決まらなくて時間だけが過ぎた

[gcyn]

仕事は開始してるんだけどある時点で全体にgoを出すのが大事で、そのタイミングや言い方で後のリズムや遠達力も違うというものです。関わる人が気持ち良く「よし来た」と言えるような要件で踏み出したいのが仕事〜。

[hevelo]

“ ”

[mayumayu_nimolove]

できないやつの言い訳に聞こえる

[himikko]

わ

[kagehiens]

"完璧にはならないことを受け入れ、ベストを尽くす姿勢"システム開発に於いてこれこそが唯一の正義。／「ライト、ついてますか」を読めと言う話かな。

[dmr]

責任

[ko-ya-ma]

良いこと書いてる

[yasu-osu]

拙記事を引用頂いてます。イーロンマスクの記事は参考になりました。