【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を０から自力で作ろうと思うと４０時間はかかるが、chatgptを使う事によって４時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全
失敗しない要件定義、3つのポイント
ITシステムに求める要件が多様化、複雑化の一途をたどっている近年、要件定義の難易度もいっそう増している。そうした中でも、確実かつ効率的に要件定義を行うためには具体的にどうすればよいのだろうか？ プライスウォーターハウスクーパースの耵岡充宏氏に話を聞いた。 難易度が増している要件定義 かつてITは、企業の業務を効率化してコストを削減するための手段として用いられていた。システム化の対象となる業務は、会計や人事など、ある程度定型化されたものがほとんどだった。だが今日、ITに求められる役割は効率化だけにとどまらない。ビジネスの「スピード」「精度」「利益」の向上に直結するような効果、ひいては経営戦略により深くコミットしたITの在り方が求められている。ITが担うべき役割は広く、そして複雑になっているのだ。 こうした中、さらに重要性を増しているのがシステム開発における「要件定義」だ。むろん、かねてから指
「要件定義書のアウトライン作成」完全マニュアル
他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
第23回「要件定義（システム要件）」｜株式会社エグザート
インターネットビジネスの本格的参入 第23回「要件定義（システム要件）」 これまでに３回にわたり要件定義について書いていますが、本メールマガジンはユーザ側の視点から書いていますから、システム側の方には十分な情報ではありませんのでご注意ください。 ────────────────────────────── □ 要件定義で定義すること（システム要件） ────────────────────────────── ５．システム要件 システム要件については、業務要件に基づいてシステム開発の委託先がリードしてくれるべきものです。 システムに明るい方であれば自分で定義することもできるかもしれませんが、コンピュータシステムは新しい技術への変化が激しい分野ですので、やはり、その道のプロに任せることが懸命です。 ゆえに本メルマガにおいて、詳細は書きませんが、どんなことを定義するのかということを例を挙げて簡
第1回 要件定義作業を容易にするシステム化企画書の意義 | IT Leaders
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML（統一モデリング言語）で定めるユースケース図を用いると分かりやすい。 要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。 それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。 しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。 この連載では、シ
要件定義フレームワークを使う | system-enablers日記
私の今のお仕事は、ひとつのインスタンスを複数のユーザが利用する「ASPサービス」の保守・運用・開発です。 ですが、最近はこの「共用仕様」に飽き足らないお客様のために、個別にインスタンスを立ててカスタマイズする案件が複数並行しています。 そういうわけで、最近は営業やユーザからのヒアリング内容をうまくまとめて、「要件定義」として記述するという作業シーンが多くなっています。 — そもそも要件定義って、みなさんどうしていますか？プロジェクトが終わった後で、 「要件定義があいまいだったために、多数手戻りが発生した」 なんて反省をしていませんか？ 私見ですが、要件定義が失敗しやすい理由としては、 ユーザからのヒアリングが上手にできない（対機械の作業ではなく、対人間での「情報を引き出す力」が問題） スケジュールがタイトで、気づいたら要件定義のフェーズを終了させられた。（まだできてないってば。） そもそも
図3●ビジネス要件とシステム要件
日経クロステック登録会員になると… ・新着が分かるメールマガジンが届く ・キーワード登録、連載フォローが便利 さらに、有料会員に申し込むとすべての記事が読み放題に！ 有料会員と登録会員の違い
要件と機能の関連を保つテンプレート
品質の鍵は上流工程にあり SIer業界において、生産性向上は永遠のテーマです。そのための施策としてよく行われるのがドキュメントの標準化です。もちろん、弊社においても実践しており、その一環として業務システムの開発ドキュメント標準テンプレート「DUNGEON（ダンジョン）」を作成しています。DUNGEONは現場主体で作成しており、そのノウハウが凝縮されているのが特徴です。2005年に連載「即活用！業務システムの開発ドキュメント標準化」（http://www.thinkit.co.jp/free/project/4/1/1.html）にて紹介したところ、大変好評でした。 その後もこのDUNGEONは、現場で鍛え続けて進化しています。そこで、再度そのノウハウを「すぐに使えるテンプレート」として紹介することになりました。対象は業務システムをウオーターフォールで開発するSEを想定しています。今回は、そ
価値ある要件定義の成果物|中堅企業・中小企業における パッケージ導入の手引き
【ページ構成】 ■ 要件定義書の失敗事例と原因 ■ 目的達成へと導く「要件定義書」 ■ 価値ある成果物を創るための条件 ■ 要件定義作業でのベンダ力量のチェックと判断 情報システムの検討を意味するパッケージ導入（クラウド導入）プロジェクトの失敗の多くは、要件定義書（FIT&GAP/要求定義含む）の成果物に起因しています。その原因は「対象範囲のカバー漏れ、具体性の欠如、曖昧表現、スキル不足、ストーリの無いまとめ方」など多岐に渡っています。また、ユーザとベンダ共に企業環境の変化に対応すべき情報システムの活用方法を提示できない成果物の内容にもあります。システム要件が経営方針、取引条件、業務効率、管理内容及び情報技術などが関連しあって決まるという中堅・中小企業の経営ニーズへの基本的な理解不足です。 失敗した要件定義書の成果物事例を通して、どこに問題点と原因があるかを明らかにします。つぎに、あるべき
非機能要件を見極める【後編】：ひな型を使い漏れ防止
非機能要件は，ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏（オブジェクトフレームワークディヴィジョン テクニカルコンサルタント）は「経験上，非機能要件の中でも，許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし，信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。 ◆どう洗い出すか？ ひな型を使い漏れ防止 要件をテンプレート化しておく 非機能要件は機能要件と異なり，項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など，どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し，非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上流工程-要件定義---目次：ITpro