[B! 要件定義] hiroaki256のブックマーク

hiroaki256 id:hiroaki256

要件定義に関するhiroaki256のブックマーク (8)

【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画
1. はじめよう!要件定義 ~ビギナーからベテランまで︵難度‥★☆☆︶ 1-1. 本のポイント要件定義のプロセスが平易な言葉で解説されている内容がコンパクトで図解も多いため読みやすい中級～上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。ちなみに、本書は﹁要件定義のプロセスと勘所を知れる﹂という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。・はじめよう!プロセス設計 ~要件定義のその前に・はじめよう!システム設計 ~要件定義のその後に本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた
hiroaki256 2023/09/19
本

書籍

要件定義
リンク
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 202218日目の記事です。ソフトウェアエンジニアの池澤です。ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA︵ラドラ︶について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA︵ラドラ︶とは？概要 RDRAのバージョンこれまでの要件定義でよくある問題期待される要件定義の姿公式サイトおすすめの学び方実際のRD
hiroaki256 2022/12/19
要件

業務

モデル

要件定義

rdra
リンク
見積・提案書に書いておくと不幸を減らせる前提条件
はじめにちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。おことわりこれを書いておけば、すべての不幸を避けられるというものではありません提出先との関係性次第では、書かないほうがいいこともあるかも私自身が普段提案している内容が、すべて記載されているわけでもありません︵うろ覚えで書いてたり、大人の事情︶これを流用しておこったすべての事項について、何らかの責任をとることはできません本稿では請負による開発を想定していますでも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。前提条件を書く目的見積・提案書通りに、実施するために必要な条件を明確にする条件を逸脱したときに、どうなるのかハッキリさせる上記は概ねつぎのとおり実現が不可能になる
hiroaki256 2022/08/01
見積

要件

プロジェクト

要件定義
リンク
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにかエンジニア、ビジネスサイドの方に向けた、﹁良い要件定義の作り方﹂について書いた記事です。長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、﹁あの人が作ったんだから大丈夫﹂と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定するということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
hiroaki256 2021/12/23
要件

チーム

開発

ux

設計

要件定義
リンク
工務店という稼業#2 (なぜ業者は相見積を嫌がるのか? 本音)｜いのっち@現役・工務店の中の人
ー　⌛この記事は約8分で読めます。ー相見積だと伝えると工事業者に嫌がられる。または急にリアクションが薄くなりやる気ない感じになる。といった経験をした方は少なくないと思う。それは、なぜだろうか？社会の競争原理に従って相見積もりするのは普通の事なのに。﹁ちゃんと仕事してくれよ、せっかく頼んでいるのだから。﹂﹁仕事になればおたくも儲かるんだからさ。﹂そう思ったに違いない。あなたを信用して1社に絞っていたのに、いちいち催促しないと無い返事、LINEは既読がつかない︵絶対読んでるはず︶夕方電話しても出ないし、どうなってるんだよ！！極めつけは、﹁うちではできない﹂と回答。いまさらか！だったらはじめから言ってくれ！とにかく途中報告がないし、まともなコミュニケーションがとれない。あいつらのペースに合わせていたら機会損失だらけだ！そんな過去の経験から相見積するも、業者からは嫌がられる。ほんと
hiroaki256 2021/05/06
見積

仕事

要件定義

業界
リンク
DDD with RDRA, ICONIX
DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血…
hiroaki256 2017/05/15
DDD

RDRA

要件定義
リンク
先生じゃなければ奴隷、客に代わり要件を定義するSIerの愚
ユーザー企業のIT部門がシステム開発で満足に要件定義もできなくなった。だから、SIerがIT部門の要件定義を代行する。多くのユーザー企業でIT部門の劣化・素人化が進んだこともあり、SIerの技術者が要件定義を代行するのは、今ではごく普通の話。だが、これは二重の意味で大きな間違いであることを、IT部門やSIerはきちんと自覚しているのであろうか。読者の皆さんは当然お分かりかと思うが、新人などピンと来ない人もいるかと思うので少し説明する。要件定義とは﹁何をどのように作ってもらいたいかを明確にする﹂作業だから、本来なら客しかできないはずである。さらにこの場合の﹁客﹂は、IT部門ではなく、システムを利用する部門。﹁何をどのように作ってもらいたいかを明確に示す﹂のはIT部門の役目ですらなく、利用部門の役目である。だから、﹁SIerがIT部門の要件定義を代行する﹂というのは二重の意味で間違いなのだ
hiroaki256 2017/05/12
先ほどの要件定義の代行や、SIerの間で一時流行した「ソリューション提案」の類いと本質的に変わりはない。本物のコンサルとは客が自ら課題に気付き、解決策を考え、実行できるようにしてあげるコーチのような存在だ

受託開発

SIer

要件定義
リンク
ペロリ流開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流開発要件のまとめ方開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？パワポですか？ spreadsheet ですか？流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。ちなみに、ペロリはカオスを楽しめる人を求めていますw開発要件のまとめ方って色々あって難しい私が学生の時に所属していたベンチャー企業では、数十MBもあるパワポに画面イメ
hiroaki256 2016/07/22
スコープ

要件定義

ドキュメント
リンク
1