• はてなブックマーク
  • 暮らし
  • 要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
  • Twitterでシェア
  • Facebookでシェア

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

暮らし カテゴリーの変更を依頼 記事元:togetter.com
適切な情報に変更
1404 usersがブックマーク コメント102

    記事へのコメント102件

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    kobito19
    kobito19 はじめからそんな"要件定義で滅茶苦茶詰め"ることは人類には不可能だとようやく気づけた(のでスクラムとかそういう方向で行こうとしてる)のが進歩だと思ってたのに、また逆行するの？

    2022/12/05 リンク

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

    2022/12/10 リンク

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

    2022/12/09 リンク

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

    2022/12/09 リンク

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

    2022/12/06 リンク

    その他
    fujikiseki21
    fujikiseki21 発注者責任 責任自分論

    2022/12/06 リンク

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

    2022/12/06 リンク

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

    2022/12/06 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    sagami3
    sagami3 ブコメ1200超とか久しぶりに見た。

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    robeht
    robeht 読む

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    nori6810
    nori6810 3億分の2読みました！！

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    roomrii
    roomrii ( ..)φメモメモ

    2022/12/05 リンク

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

    2022/12/05 リンク

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

    2022/12/05 リンク

    その他
    pmint
    pmint IPAって時点でアレ。「プロジェクト要件」とか独自用語を使わずに普通に「要件」でいい。何を作るのかあやふやなまま運用までの費用を決めてしまうのがまずいわけで、要するに自分らの問題を相手に丸投げしてる話。

    2022/12/05 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

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

    ✨nori @00oichan SES→金融系SIer→外資SaaSエンジニア ServiceNow／生成AIプロンプトフェチ／ITIL運用設...

    ブックマークしたユーザー

    • yshz2025/01/28 yshz
    • ni-sukensu2024/12/19 ni-sukensu
    • remixed2024/12/14 remixed
    • V-82024/09/25 V-8
    • hamati6662024/09/20 hamati666
    • kotakotakaikai2024/08/24 kotakotakaikai
    • atoh2024/07/29 atoh
    • wa_oga2024/07/24 wa_oga
    • chopwave2024/07/06 chopwave
    • shion2142024/05/05 shion214
    • takan0ri02024/05/04 takan0ri0
    • lemon5552023/10/29 lemon555
    • techtech05212023/07/26 techtech0521
    • phain2023/06/28 phain
    • donotthinkfeel2023/03/24 donotthinkfeel
    • sota3442023/01/18 sota344
    • sawarabi01302023/01/15 sawarabi0130
    • lugecy2023/01/07 lugecy
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - 暮らし

    いま人気の記事 - 暮らしをもっと読む

    新着記事 - 暮らし

    新着記事 - 暮らしをもっと読む

    同時期にブックマークされた記事

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2025 Hatena. All Rights Reserved.
    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy