「要件定義をやめよう」の真意、普通にやると金と時間が無駄になるだけ
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX（デジタルトランスフォーメー
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ | 書籍・刊行物 | IPA 独立行政法人 情報処理推進機構
編集・発行元 独立行政法人情報処理推進機構（IPA） 社会基盤センター 発行日 2019年12月20日 サイズ B5変形判 ページ数 498ページ ISBN 978-4-905318-72-9 定価 2,500円（税込） 書籍概要 概要 デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタル・トランスフォーメーション（DX）」が注目を集めるなか、従来のようなITベンダやシステム部門が中心になって要件定義をすすめるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性が増しています。 システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています。しかしながら、システム開発の遅延の過半は要件定義の失敗にあると言われるように、要件定義においては、その過程で様々な問題に直面します。 そこでIPAでは
「要件定義」のまえに、「要求定義」｜しょーてぃー/ Experience & Prompt Designer
多くのアクセスがあったので無料化しました 要求定義テンプレも記事内でDLできます。 はじめにはじめましてUX プランナーのShoty(@shoty_k2)です。 今回は「要求定義」をつかった、UX デザインについてご紹介します。 実践用テンプレートも記事内にて配布しておりますので、参考にしてください。 「要求定義」とは要求定義とは、「事業や施策によって実現したいこと」です。ユーザーにどのような状態になって欲しいのか・何をしてほしいのか、ビジネスで何が必要なのかなどを取り決めることです。 要求定義という言葉は、もともとはシステム開発の現場では頻繁に使われている単語で、非技術者の企画者がシステムに求める仕様を定義することです。 「要件定義」と「要求定義」の違い多くの方が「要件定義」という言葉を聞いたことがあるかと思いますが、「要件定義」と「要求定義」の違いについてご存知でしょうか？ ★要件定義
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて (2023/04/28 19:30〜)
zoomを使ってのリモート開催です。zoomのURL等は、当ページの「参加者への情報」欄に記載されています。別途、参加者にメールにてお知らせします。 DX（Digital Transformation）の浸透に伴い、ビジネスの中心にITが位置する現代では、システム開発において要件定義はますます重要になっています。 ビジネスの中心にITが位置するようになり、ビジネスプロセスやサービスをITを用いて効率化・最適化することが求められるようになったからです。 ビズリーチの2022年のレジュメ検索トレンドの1位※に「開発要件定義」が選ばれたように、要件定義はシステム開発において欠かせないスキルであり、求められる人材として注目されています。 今回のBPStudyでは、要件定義をテーマに開催します。 要件定義とはそもそも何か？、ChatGPTを活用したRDRAによる要件定義、シフトレフトを用いた見積り精
要件定義のシフトレフトで見積り精度向上に挑戦！プロジェクト成功への一歩
BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて https://bpstudy.connpass.com/event/281289/ にてお話した際のプレゼン資料です。 みなさん、プロジェクトは順調ですか？ システム開発プロジェクトにおいて、要件の不明瞭さやリソース不足などの課題はつきものですよね。 我々は要件定義をシフトレフトして見積りすることで、そういった課題にアプローチしてプロジェクト精度向上ができないかと挑戦しています。 実施している取り組みを紹介し、皆さまのプロジェクトにお役立ちできればと思います。 今回は、イベントタイトルに「ChatGPTを添えて」と記載されたので、 いつもとはスライドの雰囲気を変えて、高級フランス料理店をイメージしてみました。 さて、伝わるクオリティになったかどうか。 #要件定義 #RDRA #コアドメイン #設計 #ChatGPT #BP
「怠惰・短気・高慢」であれ、ChatGPTを使って業務効率化しよう(要件定義編)
例として読書記録アプリをつくります！ 筆者が欲しいサービスを作ろうと思い、今回は「読書記録アプリ」をつくります。 最低限の要件は、次のように設定しました。 デモアプリの要件（読み飛ばしてOK） 読書記録アプリを作る目的 読書が苦手なエンジニアが読書記録をし、記録を共有することで、継続して技術本を読めるようになること ターゲット 新人、中堅のWebエンジニア おおまかな要件 ユーザーは新規登録することで、読書記録アプリにログインできる ユーザーは読む本を登録できる ユーザーは本を何ページ読み終えたかを記録できる ユーザーは本を読み終わったら次の本を登録できる ユーザーは他の人がどの本を読んでいるのか、また何ページ読み終えたかを閲覧できる 質問する前に... また、ChatGPTに業務で使用するコードを渡す場合、環境キーやサービスを特定できる情報を送信しないでください。入力内容が他の人に渡って
ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO
架空の営業管理システムを作ってもらう前提で、ChatGPTに要件定義をお願いしてみました。 実験として軽く試すレベルで始めてみたのですが、予想を超えるクオリティでしたので、一部始終を皆様にもご紹介します。 ChatGPTとのやりとり まず、ざっくりと必要な機能の洗い出しをお願いしてみました。 あっという間に必要な機能を網羅的にリストアップしてくれまた。私自身、SFA/CRMをいくつか触った経験がありますが、適切な内容だと思います。 中には、「データのインポート・エクスポート機能」のように、検討初期段階ではつい忘れそうな機能も含まれています。さらに頼んでもいないのにオススメの検討プロセスまで教えてくれました。気が利いてます。 機能ベースだと要件の妥当性が判断しにくく思ったので、画面ベースで要件定義してもらことにしました。 「図で教えて」とできないことをお願いしたところ、やんわり断りつつ、意図
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7d131e38e26f54466aece3306435a4c09990de8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01MjE0ZDhhMTY1ZjE1ODIxNGE5NzU4Njc3MTNjOTBmNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzeWFudGllbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTc4MmM0MTlmNzhiYTJjNTk0ODYwZmExZDc0OWYzNjQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db088349e276a1ebcdb9dcf1e2d753094)
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
要求定義と要件定義の違いを考える - Qiita
要求定義と要件定義についての記事というのは需要があるようですね。 検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。 役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。 ##最近の近況 バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。 ##はじまり はぁ… なんでシステム開発が失敗するんだろう… 仕様の変更が多くて… 言った言ってないのトラブルから避けたい… システム動かしてみても全然使えない… 実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をして
3つの決めつけから見る失敗の要件定義
## 今回発表したイベントについて PeerQuest Inc. （ https://peer-quest.jp/ ）様主催の、#開発PM勉強会（ https://twitter.com/search?q=%23%E9%96%8B%E7%99%BAPM%E5%8B%89%E5%BC%B7%E4%BC%9A&src=typed_query ）の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。 株式会社Speee プロダクトマネージャー 塚本尚 https://peer-quest.connpass.com/event/229463/ ## 発表した内容について 結局行き着いたのは、（あるある話だとは思いますが）**whyとwhatの定義をしっかりす定義すること** でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表し
要件定義とは？仕様書との違いや記載すべき項目、作成の進め方を解説 | Backlogブログ
システム開発などの現場で必須となる要件定義。当たり前のように使っている言葉ではあるものの、要件定義書の記載事項や具体的な要件定義の進め方についてあらためて問われると、返答に困ってしまうという人も多いのではないでしょうか。 今回は、要件定義の概要や要件定義書に記載すべき項目、要件定義を進める際の基本的な流れについて解説します。要件定義を適切に行うために必要なスキルにも触れていますので、ぜひ参考にしてください。 はじめに、要件定義に関する基本的な知識を整理しておきましょう。「要件」と「要求」の違いや、要件定義と仕様書の違いを押さえておくことが大切です。 要件定義の位置づけ 要件定義とは、開発者の視点で発注者の要求をまとめ、解決するための具体的な方法を決めることを指します。何をどうシステム化するのか、ドキュメント形式で可視化することが要件定義のゴールと捉えてください。 さまざまな開発プロジェクト
システムの要件定義とは 進め方や必要な準備をわかりやすく解説
システムの要件定義とは、そのシステム開発を行う上で実施すべき業務の内容を整理してわかりやすく文書化することです。基本の考え方や要件定義書を作成するまでの進め方、必要な準備について、IT業界経験10年以上のシステムエンジニアが説明します。 システム要件定義とは システムの要件定義とは、システム開発を行う上で実施すべき業務内容をあらかじめ想定し、わかりやすく文書化するプロセスです。 実際にシステム開発プロジェクトを進めていく上で、目的や内容はもちろん、スケジュールや開発予算、開発に関わるメンバーなど、想定しておくべきことはたくさんあります。 こうした各要素をあらかじめ具体的に想定し、文書化しておけば、プロジェクトを計画通りに進められる可能性が高まります。計画通りにプロジェクトが推進できれば、事業を成功に導くことができます。 つまり、要件定義の成否によって、プロジェクトを計画通りに進めることがで
RDRA学習ロードマップ
RDRAが広まってきているので情報源を充実させたい リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。 RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。 要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。 RDRAで可視化されたビジネスルール（バリエーション・条件・状態モデル）をビジネスロジックとして実装しています。 ドメイン駆動設計の実装例としても参考にしてください。 https://t.co/UyFscwKMPi#CCSR手法 — 増田 亨． (@masuda220) May 26, 2020
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
要件定義とはそもそも何か
超上流から攻めるIT化の原理原則17ヶ条
要件定義に関わる人は３億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
