架空の営業管理システムを作ってもらう前提で、ChatGPTに要件定義をお願いしてみました。 実験として軽く試すレベルで始めてみたのですが、予想を超えるクオリティでしたので、一部始終を皆様にもご紹介します。 ChatGPTとのやりとり まず、ざっくりと必要な機能の洗い出しをお願いしてみました。 あっという間に必要な機能を網羅的にリストアップしてくれまた。私自身、SFA/CRMをいくつか触った経験がありますが、適切な内容だと思います。 中には、「データのインポート・エクスポート機能」のように、検討初期段階ではつい忘れそうな機能も含まれています。さらに頼んでもいないのにオススメの検討プロセスまで教えてくれました。気が利いてます。 機能ベースだと要件の妥当性が判断しにくく思ったので、画面ベースで要件定義してもらことにしました。 「図で教えて」とできないことをお願いしたところ、やんわり断りつつ、意図
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
要件定義とはそもそも何か
BPStudy#188〜要件定義を学ぼう。ChatGPTを添えて( https://bpstudy.connpass.com/event/281289/ ) の登壇資料です。 2023年4月28日(金)に開催。
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
GPT-4時代のエンジニアの生存戦略 ※ この記事の内容の一部はこちらのイベントでお話したことと重複します。 はじめに 2023年3月1日にOpenAI社よりChatGPTのAPIが公開されました。 さらに14日にはGPT-4が登場し、その翌々日にはMicrosoft 365 CopilotでGPT-4をOffice製品に搭載することが発表されるなど、AI領域で大きな変化が起きています。 変化の速度の速さと変化量の大きさにより、私自身も追いつくのが精一杯な状態です。 個人的には、iPhoneの登場時以上の衝撃を受けています。 人類の歴史上、過去3回AIブームがありました。Generative AIが4回目のブームになります。 そして、特に日本においては顕著なのですが、AIへの過度な期待とそれへの失望の繰り返しがここ数十年にわたって繰り返されてきました。 直近だと数年前のDeep Learn
コード書く以外の仕事上暗黙的に必要とされている様々なスキルについてブレストしてみる - stefafafan の fa は3つです
前提 僕は新卒からいまの会社に入って以来ずっとWeb系アプリケーションエンジニアとして仕事してきました 自分がWeb系のエンジニアとして成長するにあたって必要なスキルについて考えたときに、ただコードが書けるだけでは評価されないだろうなということだけ何となくわかっているつもりだけど、言語化しないとどういうスキルがあるのか何が自分に足りないのかがわからない気がするので一旦ブレストしてみる 出来上がったリストを元に次にどこを集中的に伸ばすべきかというのがわかるのではないか ここでいう暗黙的とは、僕が学生の頃「Web系のアプリケーションエンジニアに必要なスキルはこれだろうな」と考えたときにきっと思い浮かばなかったもののことですが、人によってはこんなこと当たり前だろうと思うかもしれません ブレスト結果 いくつかブレストした結果をグループごとにわけてみた。（ブレストといってもただパソコンに向かって箇条
要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
Merpay Advent Calendar 2020の20日目は、メルペイProduct EngineeringチームのVP of Engineeringを担当しているnozaqがお送りします。 2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。 取り組んだこと 決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご
エンジニアは顧客の要望をちゃんと聞こう 〜「うちの店でカレーを出したい」と言われたら？〜｜Katsuma Narisawa
こんにちは。SALESCOREのCTOの成澤です。 今日は、Webサービス開発に携わる方向けに「要望を正しく聞くのは大事だよ」という話を、飲食店の例え話で紹介します。 「うちの店でカレーを出したい」と言われたら飲食店のオーナーから「うちの店のメニューにカレーを加えたい。カレーを作る体制を整備してほしい」と相談されたとします。 敏腕料理人のあなたは何を考えるでしょうか？ 普通に考えたら「野菜と肉とルーを仕入れて、あとは鍋と包丁を用意して…」と考えるでしょう。 カレー作りに知見がある人なら「スパイスから手作りした方が美味しく作れる！スパイスを独自ルートで調達しよう！」なんてことも考えるかもしれません。 しかし、ここであなたがするべきことは、オーナーへの追加ヒアリングです。 どんな店なのか？ → 喫茶店かも 店内の調理設備は？ → 狭い厨房がちょっとあるだけ。調理器具もほとんどない スタッフの体
結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
BEMANI特許（あるいはビートマニア特許）と俗称される特許がある。KONAMI（現・コナミアミューズメント）が1997年にリリースし、音楽ゲームブームの基礎となった「beatmania」の基本システムを請求、KONAMIがBEMANIブランドで展開する音楽ゲームビジネスの柱の一つとなっていた、日本国特許第2922509号のことだ。 この特許は1998年7月31日に出願、1999年4月に登録。日本の特許の権利期間は出願から最長で20年間と定められており、2018年7月31日をもって失効している。 BEMANI特許は音楽ゲーム分野の工業所有権（産業財産権とも。特許権、実用新案権、商標権、意匠権の総称）の代表格であり、これまでの約20年間にわたり、ゲームファン界隈の巷間でたびたび語り草となってきた。 しかし、本特許の権利範囲はしばしば誤解され、不十分な理解に基づいた語りが多く展開されてきた実情
ITプロジェクトのはじめ方 / How to work around software project
事業会社が今よりも事業を成長させるために、ITシステムの構築や導入を成功させるために、どうやってプロジェクトを立ち上げて、どんな中間生成物や検討が必要で、どうやって要件を決めるべきかを解説した資料です。 私の経歴やブログは以下の通りです。 https://quality-start.in/about https://gothedistance.hatenadiary.jp https://note.mu/it_planning/
お前たちの仕様の伝え方は間違っている！
仕様を伝えるときには、ストーリーテリングでも伝えよう。
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
「要件定義をやめないといかんね」――。ある勉強会が終盤に近づいた頃、隣席の参加者がこうつぶやいた。それを聞いた周囲の参加者がうなずいた。驚いたことに自分も「おっしゃる通り」と同意してしまった。 なぜ驚いたかというと、「要件がすべてを決める」「じっくり時間をかけるべき」と教わってきたからだ。日経コンピュータ編集部に配属された1985年以降、取材先の情報システム部長やソフトハウスの幹部を取材した際、「情報化で重要なこと」を問うと、たいていこう言われた。だから「いわゆる最上流工程が大事」という記事をたびたび書いてきた。 勉強会に登壇した講演者たちが「要件定義をやめよ」と言ったわけではない。しかし隣に座っていた参加者は、講演の趣旨を「要件定義をやめよ」という一言に集約した。同じ話を聞いてきた筆者を含めた参加者はすんなり納得したわけだ。 失敗につながる要件定義の実態 DX（デジタルトランスフォーメー
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
本記事では、ソフトウェア開発手法の一つであるDDD（domain-driven design）を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 （書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。） DDD とは？ DDD（domain-driven design）は日本語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し（DDD では、後
現状把握のために実施したこと じゃあ、これを基に実際にどういうふうに考えてどういうところをやってきたかをこれからお話しできればなと思います。 まず現状把握です。（スライドを示して）今見てもらっているのが、これまで自分が体験してきたり、ほかの企業の方との情報交換とかで出てきた、製品開発におけるよくある問題だと思ってもらえればと思います。みなさんもたぶん、これまでの経験の中で、こんな声や課題は、かなりあったんじゃないかなと思っています。 前職のECの経験でもこのあたりはありました。例えばシステムが肥大化して品質維持のためにかかる工数が多くて、「新規機能開発になかなか時間がかかりますよ」となったり、事業部とかから要望、HOWの指定がけっこう多くて、顧客の課題がぼんやりしていたり。 あとは、ビジネス側からすると、思ったとおりのタイミングでリリースできないことがあるとか、もっと多くの要望を実現したい
はじめに ソフトウェア開発において、エンジニアが開発対象のドメインの業務に精通していない場合、書く内容やかける時間に程度はあれど 業務分析 や 要件定義 が必要になります。しかし、要件定義の方法論についての話題がネット上に上がることも少なく、書籍などもあまり話題になっていない印象があります (私の観測範囲では)。なので、私の場合、要件定義の実務では公の方法論を体系的に学ばずに、実務で見てきたものを自分なりにアレンジして対応してきました。 そんなとき、モデルベースの要件定義の方法論として リレーションシップ駆動分析 (RDRA) というものがあることを知りました。モデリングはずっと取り組んできていることなので、興味が湧いて少し調べてみると PlantUML でも表現できるというではありませんか！ PlantUML Example for RDRA 2.0 ハンドブック そこで、RDRA2.0
2022/1/28 Harajuku.ts Meetup #2 にて使用した資料です。 11ページ目はString#join()ではなくArray#join()の誤りでした。お詫びいたします。
設計書・仕様書の書き方が分かる！
弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。 各工程で必要なドキュメントを定義しましょう 下記のように工程ごとにドキュメント成果物、内容を定めております。 どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。 ※業務系のシステム開発に照準を当てております。 要求分析（要件定義） システム開発は要求分析（要件定義）というプロセスから始まります。要求分析（要件定義）は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性／定量） 体制図
カスタマーマニアになろう 😍
顧客を知り尽くしている「カスタマーマニア」になるための顧客インタビューの方法、現場に行くことの重要性などについて解説しています。 東京大学 FoundX の各種リソース •FoundX Review - 起業家向けノウハウ情報 •FoundX Resource - 整理された記事の紹介 •FoundX Online School - 30以上の学習ビデオ教材 •FoundX Founders Program - 個室の無償提供とコミュニティ •FoundX Pre-Founders Program - 起業準備プログラム •FoundX Fellows Program - アイデア探しの支援プログラム 更なる文献 •顧客インタビュー入門 •The Mom Test •Talking to Humans •リーン顧客開発 •東京工業大学 EDP Toolkit •たった一人の分析から事業は成
再考 - ドメインサービス - まっちゅーのチラ裏
自分が大規模システムで組むアーキテクチャは基本的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ
ユーザーは⾃分が本当にほしいものを⾔葉にできない！UIデザインとUXデザインは別もの！先入観の罠！目からウロコなUIデザインの勉強会
羽山 祥樹＠日本ウェブデザイン @storywriter 明日7/15（金）の夜にUXデザインの無料セミナーするんだけど、ネタスライドしかアップしてないので、中身があるか不安に思われている気がしてきたw ちゃんと中身もあるよ！ ということでスライドチラ見せ！ セミナー申し込み（無料） → creativevillage.ne.jp/111762 pic.twitter.com/wJl3jUyz3b twitter.com/storywriter/st… 2022-07-14 18:04:25 リンク connpass 【UXデザイン基礎】「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 (2022/07/15 19:00〜) ## 【UXデザイン基礎】「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 UXデザインの根幹を理解するための無料セミナーを開催し
「要件定義」がうまく機能しない「3つの壁」
はじめに 「ユーザーエクスペリエンス(UX)デザイン」という言葉を、よく耳にするようになりました。UXデザインの分野には、エンドユーザーのニーズをつぶさに拾いあげることで、プロジェクトやビジネスを成功に導くためのノウハウが集まっています。 UXデザインの基本のひとつは「エンドユーザーにインタビューにいく」ことです。 本連載を通じて、ユーザーインタビューの「はじめの一歩」を体験していきます。第1回、第2回では、「そもそもユーザーニーズはどのようにすればわかるのか」について解説します。 「エンドユーザーにうれしいものづくりをしよう」と考える UXデザインでは「私たちは、誰を『しあわせ』にするために、ものをつくっているのだったか?」を強く意識します。 UXデザインの根本的な思想は、「エンドユーザーにうれしいものづくりをしよう」と考えることです。エンドユーザーにうれしいものをつくり、ビジネスがうま
そもそも、アジャイル開発とは何か。片山氏は「正解がわからない状態で、正解に近づくためのアプローチであり、手法としてはインクリメンタル（徐々に増加する）とイテレーティブ（反復）、つまり、少しずつ繰り返しながらビジネス価値を上げて提供するアプリケーションを開発する点が特徴です。その考え方は複雑だったり、難しかったりするわけではありません」と説明する。 また、ウォーターフォール型開発との違いについて、片山氏は「ウォーターフォール型開発では決められたゴールを目指して直線的に進んでいくのに対して、アジャイル開発では試行錯誤を繰り返しながらゴールに近づくことを目指します」と解説する。 「ある程度の規模を持つシステムを開発する場合、アジャイル開発のほうが工数もかかることがあります。アジャイル開発の特徴が決して『早い』『安い』ではないと理解しておくことが非常に重要です」（片山氏） 片山氏によると、実際のア
合同勉強会 in 大都会岡山 -2020 Winter Online https://gbdaitokai.connpass.com/event/189232/ --- 開発者が事業活動に関心を持ち、ビジネスルールに基づく計算・判断ロジック（ビジネスロジック）を軸にアプリケーションを組み立てる、「CCSR」というソフトウェア開発手法をご紹介します。 参考: 要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法 https://masuda220.hatenablog.com/entry/2020/05/27/103750
私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます：「訴えてやる！」の前に読む IT訴訟 徹底解説（88）（1/5 ページ） 連載目次 この連載を始めて、7年になる。長くご愛読いただいている読者の皆さまに感謝の念が絶えない。このように長くIT紛争を見続けていると、同じような問題、同じような言葉に何度となくぶつかることがある。街中にある主要な交差点のように、気が付くとその場に立っていて「さて今日はどの方向へ曲がればいいか」と考える場所。そんな言葉である。 「契約の目的とシステムの要件」――IT紛争の勉強や著述などをしていると、いつもこの言葉にぶつかる。「定義されていない要件であっても、それなしには契約の目的を達成できないものであれば、事実上定義されていたと考えなければならない」「たとえ要件通りでも、契約の目的に資することのないシステムを作れば、債務不履行に問われる危険も
Developers Summit 2022の登壇スライドです。 https://event.shoeisha.jp/devsumi/20220217/session/3647/ 俺のプロダクト開発用語辞典 https://www.youtube.com/channel/UCnUdhofhFN2RotPou4a55_w オーバーエンジニアリングとは？ https://www.youtube.com/watch?v=6XQOSj7rutI オーバーエンジニアリングとは（ブログ版） https://i2key.hateblo.jp/entry/2021/12/25/101957Read less
実例マッピングで要件のレビューサイクルを回してる話 / Example Mapping Review Cycle
[JaSST nano vol.18](https://jasst-nano.connpass.com/event/263810/) 引用 The secrets of effective collaboration : https://docs.google.com/presentation/d/1uunQ8Md8p52rC_D6Adhgib8jH6B9YLAuFJhXDLGCgEw 今日から始める「実例マッピング」 : https://speakerdeck.com/rikasato/how-to-use-example-mapping-number-pmconf2022 参考 Agile Testing Condensed Japanese Edition : https://leanpub.com/agiletesting-condensed-japanese-edition Th
何のため？ たまたま「予定通り進まないプロジェクトの進め方」を読んでいたら、レストランの注文をうまくユーザーの要望・要求・仕様に例えていて分かりやすく、もう少し掘り下げて整理したいと思ったのと、システム開発の上流工程周辺（企画とか詳細設計含める）は工程やドキュメントの種類が多く自分自身よく混乱するので、改めて勉強して、まとめておくためです。 主観も混ざっていますので、参考程度にしていただければと思います。 そもそもなぜ混乱しやすい？ 概ね下記のような理由だと考えています。 同じような言葉が多い 要望/要求/要件 設計/仕様 仕様書/定義書 各組織の文化的な要素もあり、会社、メンバー、業務委託構造によって、各工程やドキュメントの呼び方が若干異なることがある。 要求仕様書なのか、要求定義書なのか、要件仕様書なのか、要件定義書なのか、など 機能仕様書、機能要件定義書、など レストランの注文例 ち
ユーザーからの希望や願いは、しばしば「要求」や「要件」という用語で表現されます。多くのＩＴ企業ではどちらかしか使わず、しかもどちらの意味で使っているのかがあいまいなことが多く散見されます。 ですが、実際にはこれら「要求」と「要件」という言葉はまったく異なる意味を持っているものと定義して開発に向き合わないと、プロジェクトの失敗比率が数割上昇します。 要求とは 漠然とした希望や願い、思想、経営上期待している成果など 要件とは 機能・非機能を含めたシステムに対する実現すべき定義 のことを意味しています（ちなみに英語ではすべて「Requirement」で統一されており、「要求」と「要件」の厳密な違いを意識することはありません）。 なぜ「要求」と「要件」の区別が重要なのか。 それは、そもそもビジネスとＩＴには根本的矛盾があるため、まずビジネスとＩＴの２つの側面から、ユーザーの要望を切り分けることが必
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO
見積・提案書に書いておくと不幸を減らせる前提条件
要件定義～システム設計ができる人材になれる記事 - Qiita
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
要件定義～システム設計ができる人材になれる記事 - Qiita
GPT-4時代のエンジニアの生存戦略 - Qiita
決済サービスを閉じるときのやることリスト | メルカリエンジニアリング
個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
KONAMIの「BEMANI特許」とは何だったのか 失効から3年のいま振り返る、近代音楽ゲームの基本特許
「要件定義をやめよう」の真意、普通にやると金と時間が無駄になるだけ
Agile and Requirement : アジャイルな要件定義について考える
DDDでの要件定義〜実装までの流れについて解説します
要件定義以降の工数は50%減少、開発ボリューム・件数は増加 PM組織立ち上げの「現状把握」「目標設定」「問題特定」で得られた効果
PlantUML で始めるリレーションシップ駆動要件分析 (RDRA) - Qiita
コードには型アノテーションよりも要件アノテーションを増やせ！/harajukuts2
アジャイル開発はなぜ失敗するのか？ ガートナーが絶対押さえるべき6つのポイント解説
ビジネスルールを軸とした ソフトウェア開発手法 「CCSR」
私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます
オーバーエンジニアリングって何？ #devsumi #devsumiA
要望、要求、要件の違いとか、基本設計、詳細設計の違いで迷わないようにするためのまとめ - Qiita
「要求」と「要件」の違い｜Takashi Suda / かんた