要件定義について言語化できる様に整理してみた - Qiita
はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義フェーズの新しい案件に入る予定です。過去何回か対応したものの、対応手順や内容、要件定義に関わる用語について上手く言語化出来ない箇所があったため、振り返り兼ねて整理してみました。 要件定義とは 要件定義は、システム開発の初期段階で、ユーザーの要求やニーズを具体的な開発内容に落とし込む工程です。要求定義がユーザー視点で 「何を必要とするか」 を定義するのに対し、要件定義は開発者の視点から 「どのように実現するか」 を明確にします。このプロセスでは、システムの機能や性能、利用する技術などを具体的に定め、ステークホルダーと合意形成を行います。 プロジェクトの目的やゴールを明確にし、開発範囲や実装すべき機能を確定するため
「詳細な見積もり根拠を示せ」と要求するIT部門の無能と無用
ユーザー企業のIT部門は、システム開発案件で料金を提示したITベンダーに対して「詳細な見積もり根拠を示せ」と言う。一見、当然の要求のように思えるが、実は多くの場合、IT部門がこんな要求を出すことは「我々は無能で無用の存在です」と言っているに等しい。しかも、その要求に応えてITベンダーがその根拠を示したところで、見積もり自体は“嘘八百”なのである。 嘘八百と書いたが、ITベンダーで見積もりを担当する技術者は、真面目に仕事をしている。詳細な根拠を示す以上、本来なら「見積もり根拠の提示料」をもらわなければいけないのだが、無償でその無茶な要求に応えようとする。「ちょっと待て！ 見積もりの根拠を聞くぐらいで、なぜ料金を支払わなければならないのか」。そんな読者のあざけりが聞こえてきそうだ。 私はこれまで「ユーザー企業はITベンダーに提案料を支払うべきだ」と主張してきた（関連記事： ITベンダーに「提案
糞システムにしないため、私ができること『はじめよう！ 要件定義』
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
ソフトウェア開発における多能工の問題 - 勘と経験と読経
ソフトウェア開発の現場では、特定作業に特化した専門家による分業開発から、個々人が幅広い作業をこなす多能工による開発といった方向に変わりつつある。アジャイル開発プロセスそもそも多能工を前提としている。また、全般的なソフトウェア開発プロジェクトが大規模より中小規模・短工期にシフトしていることが、専門家(単能工)による開発を難しくしつつある状況も、開発エンジニアの多能工化を後押ししている。しかし、多能工によるソフトウェア開発はベストプラクティスかというと、そうではないと思う。多能工アプローチの問題点について考察して望まないと、思わぬところから足をすくわれる事がある。 なぜ多能工なのか？専門家(単能工)はなぜだめなのか？ ファクトリー型アプローチは一時期流行し、いまなお一定の価値をもってはいるが、ほとんどのアプリケーション・ソフトウェアの開発には、現在これよりも有効な手法が存在している。 ソフトウ
要件定義を得意ワザにしよう
「システム開発で、何が一番難しい？」と尋ねられたら、「要件定義」と答える人が多いのではないか。ユーザーが何を望んでいるのか的確につかみ、ときとして関係者間で対立する要望を整理し、システムの要件にまとめて関係者の合意を得なければならない。技術者からは「いろいろ神経使うし、大変だよね…」という声が聞こえてきそう。 要件定義のスキルを磨くには「知識＋実践」が不可欠だ。ここでは要件定義に関する好評連載・特集をピックアップした。これらの手法やノウハウを使って、より良い要件定義ができるよう、実践に役立てていただければ幸いである。 認識のズレや要件の抜けを防ぐ「詰めの質問術」 システムの出来が見違える コツ1●言葉の定義を聞く コツ2●言い換えて聞く コツ3●タイミングを聞く コツ4●なぜ必要なのかを聞く コツ5●そうではないケースを聞く コツ6●順番が逆のケースを聞く コツ7●状態の変化に注目して聞く
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
1500枚の要件定義書に困惑、リスト化し設計レビューを進める
1. 1日の処理量が1000万件にも達する株式売買システムを新たに開発 2. 要件定義書から要素を洗い出したチェックリストを作り，設計書をレビュー 3. 取引結果の書き込み処理時間が想定外の長さ。処理の分散を図って乗り切った 2010年1月4日，稼働を開始したシステムがある。東京証券取引所の株式売買システム「arrowhead（アローヘッド）」だ。「ITエンジニアとして20年以上のキャリアがあるが，こんな“静かな”カットオーバーは初めてだ」。こう語るのは，arrowhead開発プロジェクトのリーダーを務めた，東京証券取引所の宇治浩明氏（IT開発部 株式売買システム部長）である。 開発プロジェクトには，東京証券取引所側から最大で70人，開発ベンダーである富士通側から最大500人が参加。初期投資だけで130億円に上る大規模なプロジェクトである。 arrowheadは，100社ほどの証券会社から
要件定義の丸投げを防止
顧客もBABOKを活用し始めた。東京都は既に今年4月から、BAを前提にしたシステム開発プロジェクトに着手している。対象は、水道局や下水局などが個別に構築していた電子調達システムの統合プロジェクトである。 「発注者こそ、BAのスキルを高めなければならない」と、東京都の菊地副参事は話す。「業務要求を要件定義書に落とし込むのは発注者である我々の仕事だが、ITベンダーに頼ってきたのが実情だ。従来型のあいまい開発によるリスクを少しでも抑えるために、BAが重要だと考えた」と、菊地副参事は続ける。 取り組みの中核となるのは、各局からの業務改善やシステム化への要求を行政改革推進部が取りまとめ、業務改革を進めるうえで必要かどうかを検証するアセスメントである。これまでは要件定義フェーズだけだったが、システム計画フェーズでも実施するように変えた。 アセスメントの際には、業務改善を目的とするシステムの導入・評価や
エンジニアがはまりやすい要件定義の失敗パターン | 情報・通信 | nikkei BPnet 〈日経BPネット〉
記者の眼 エンジニアがはまりやすい要件定義の失敗パターン 少し前のことだが、あるシステム・インテグレータの社内研修に1日だけ参加させてもらった。研修のテーマは要件定義。ユーザー企業の利用部門からヒアリングした業務上の問題や要望を分析し、解消すべき根本的な課題を見いだす要求分析の進め方を学ぶのが目的である。 その研修は、講義より演習が主体だった。素人の記者にはハードルが高かったが、無謀にも「ほかの方と同じように受講させてください」と頼み込んだ。要件定義の記事は何度か書いたことがあり、ちょっとした自信を持っていたのである。 演習の手始めに、架空の利用部門からヒアリングした結果という10数個の業務上の問題が題材として与えられ、他の参加者と同じく記者もその分類を試みた。「すべての問題をカバーする“巧みな分類”を考えなくては」と記者は思った。問題が起こっている場面や原因が共通する問題同士をくくり、「
ID管理システム、要件定義から基本設計まで － ＠IT
第3回 ID管理システム、要件定義から基本設計まで 徳毛 博幸 京セラコミュニケーションシステム株式会社 BPO事業部 副事業部長 2009/6/19 いまからID管理システムを導入するならば、先人の知恵や実例を踏まえた形で設計すべきです。第3回では過去の事例を基に、要件定義フェイズ以降で注意すべき点を解説します（編集部） 第2回「いま、あなたの会社にID管理システムが必要な理由」では、ID管理のシステム化の目的・目標・効果・ゴールを考えてきた。今回からはいよいよID管理のシステム化プロジェクトをスタートしよう。第3回では要件定義からシステム構築までを述べてみたい。 要件定義フェイズで決めるべきこと 要件定義フェイズにおいて検討・決定すべき事項の柱となるのは、以下の3点である。 ID管理の対象となるシステム アカウント変更のトリガーとなる、入社、退職、部署異動、昇格／降格、休職、復職、出向
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata @takehora もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている。 そして、経産省の契約モデルにあるとおり、要件定義は、準委任契約であるのが妥当。 引用ツイート nori @00oichan · 2022年12月3日 要件定義に関わる人は３億回くらい読んでほしい
要件定義工程の進め方