RDRA学習ロードマップ
RDRAが広まってきているので情報源を充実させたい リチャード 伊真岡です。最近私はRDRAという要件定義手法についてじっくり勉強しています。 RDRAは株式会社バリューソースの神崎善司さん(@zenzengood) が提唱している要件定義の手法です。日本のドメイン駆動設計コミュニティからも注目を集めているようで、ビジネスのルールをきれいにソフトウェアに反映しようとすると、要件定義に目が向くのは自然な流れです。 要件定義手法 RDRA 2.0のハンドブックのサンプル「図書館システム」の実装例です。 RDRAで可視化されたビジネスルール（バリエーション・条件・状態モデル）をビジネスロジックとして実装しています。 ドメイン駆動設計の実装例としても参考にしてください。 https://t.co/UyFscwKMPi#CCSR手法 — 増田 亨． (@masuda220) May 26, 2020
要件定義で得た学び・気づき
ふりかえりでふりかえることしかできなかったジュニアチームが、次の打ち手を出せるチームになるのにやったこと
早稲田大学 早水桃子研究室 on Twitter: "プレゼンの予定がある全ての大学生に役立つ素晴らしい無料のPDFテキスト📙私の研究室の学生にも熟読を勧めました✨／大学生のためのプレゼンテーション基礎 千葉大学大学院 人文社会科学研究科 教育・学修支援研究会 千葉大学 人文社会科学… https://t.co/41xE0plA5s"
プレゼンの予定がある全ての大学生に役立つ素晴らしい無料のPDFテキスト📙私の研究室の学生にも熟読を勧めました✨／大学生のためのプレゼンテーション基礎 千葉大学大学院 人文社会科学研究科 教育・学修支援研究会 千葉大学 人文社会科学… https://t.co/41xE0plA5s
「Google Things to do」連携リリース - アソビューでの機能開発の流れ - asoview! Tech Blog
こんにちは! アソビューでバックエンド アプリケーションエンジニアをしている山野です。 アソビューは7月にGoogleとの連携機能「Google Things to do」のリリースをしました。 今回はこの機能開発について紹介したいと思います。 Google Things to doとは Googleがアクティビティやアトラクション分野で導入した予約検索表示機能です。 これにより世界中のゲストが世界中のアクティビティやアトラクションを見つけ、 Google上で価格を比較することができます。 またゲストは体験したいアクティビティ・プランを見つけた場合は、 Google上からサービス事業者のWEBサイトへのダイレクトにアクセスでき、予約に進むことが出来ます。 google things to do 開発体制 プロダクトオーナー・プロダクトマネージャーとエンジニア(私)の３人体制で開発を行いまし
「要求を仕様化する技術・表現する技術」から学ぶ要求仕様書作成テクニック - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、west-cです。 業務にて要件定義を行う機会があり、その成果物である要求仕様書の書き方を学ぶために『【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術』という書籍を読みました。今回はその内容をご紹介します。 【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？ 作者:清水 吉男技術評論社Amazon ◆ 関連ブログ 仕様書 とは 【まとめ】 おすすめの読者層 要求仕様書の目的・ゴールが曖昧な方 自身が作成した仕様書において、仕様漏れや仕様の衝突が後工程で発生したことがある or 発生しないか不安を抱えている方 依頼者から要求を引き出す方法の糸口を掴みたい方 要求仕様書とは 書籍では、要求仕様書を「要求について、関係者がその内容について認識を特定できている文章」と定義しています。 要求（今回の機能で実現したいこと）は曖昧なものを含
「マンモスプロジェクト」を提供するパラダイスウェア株式会社のYouTubeチャンネル「プロマネ道場ラジオ」。新規事業やプロジェクトについてのあるあるや、明日から使えるノウハウについて語ります。今回のテーマは「要件定義のコツ」。要件定義のあるあるや、うまくいくコツについて話しました。 要件定義でぶつかるジレンマ、トリレンマ 橋本将功氏（以下、橋本）：みなさんこんにちは、パラダイスウェアの橋本です。 中島大輔氏（以下、中島）：中島です。 古長谷莉花氏（以下、古長谷）：古長谷です。 橋本：「だれプロラジオ（「誰も教えてくれないプロマネのコツラジオ」）」第33回は……。 古長谷：「こうすればうまくいく！要件定義のコツ」です。 橋本：要件定義はみんな悩んでるポイントかなと思いますが、要件定義のコツって何ですか？ 古長谷さん。 古長谷：今、本当に困っている。 橋本：リアルタイムに（笑）。 古長谷：うわ
【要件定義】いきなり内容説明しない！業務フローを説明するまでの「長い道のり」をまとめました。 - Qiita
要件定義をしているときに、お客さんに資料を説明することがあります。ITを専門にしていないお客さんにどのように説明するのがよいのでしょうか。まずは、資料の中身を説明する前に、前提を話す必要があります。資料の作り方は書籍やネットの記事でよく目にしますが、資料説明の仕方はあまりないようにみえます。ので、資料を丁寧に説明する流れを検討し、自分なりの言葉でまとめました。 本記事では、 ①紙媒体で行っていた業務をシステム化するプロジェクト ②「要件定義フェーズ」 ③「業務フロー」を「お客さん（ITを専門にしない方）」に説明する と仮定して、セリフと解説を記載してきます。 説明の流れ 1.ウォーターフォールモデルにおける要件定義の解説 2.使用する資料の概要説明 3.近々のスケジュールの確認 4.資料の見方と説明の流れの提示 5.資料の説明開始！
この連載では、開発現場で実践できるカイゼンのやり方と考え方について、お伝えしていきます。下敷きになっているのは、「カイゼン・ジャーニー」という書籍です。「カイゼン・ジャーニー」も、現場のカイゼンがテーマになっています。この新たに始める連載は、内容としては書籍を補完するもので、チームが現場でこのWebページを開きながら、実際にふりかえりをしたり、カンバン作りをしたりできるように作っています。本を開きながらより、Webページをモニタに映す方が、ワークショップもやりやすいですよね :) また、読者の皆さんが実際の状況を重ね合わせられるよう最初にストーリーがあり、その後解説が続く、といった構成にしています。ストーリーでは、カイゼンを実施するにあたってどんな背景や課題を想定しているかを描いています。よく知らない手法については、ストーリーに目を通すようにしてください。
不確実性に立ち向かう各社のアジャイル開発のリアルについて話す「『不確実性』にどう立ち向かう？アジャイル開発現場のリアル【BASE・DMM】」。ここでBASE株式会社の炭田氏、植田氏、櫛引氏が登壇。まずは、不確実性に振り回される5つのパターンと、その対策法を紹介します。 炭田氏の自己紹介と本日のアジェンダ 炭田高輝氏（以下、炭田）：それでは、「アジャイルで不確実性に向き合うための開発タスクの切り方」の発表をします。よろしくお願いします。 はじめに自己紹介をさせてください。BASE株式会社でネットショップ作成サービス「BASE」のエンジニアリングマネージャーをしている炭田高輝といいます。BASEには2020年に入社して、エンジニアリングマネージャーはかれこれ1年くらいやっています。 （スライドを示して）本日のアジェンダはこちらです。最初に「不確実性とは何か」について説明して、次に「受け渡し型開
システムの要件定義をやってると、「これ、そもそも業務を整理した方が良くないですか？」みたいな場面に遭遇することが良くある→様々な要因で結局整理できない
ℍ𝔸𝕃＠猫と個人開発 @HAL1986____ システムの要件定義をやってると、「これ、そもそも業務を整理した方が良くないですか？」みたいな場面に遭遇することが良くある。 で、いろいろ話を聞きながら、あるべき形を模索してみるんだけど、「ここはこういう事情が」「ここは顧客が対応出来ない」「ここは法律でこうなってる」とか、結局大して整理できずに終わることが多々ある。 「なぜこの業務に落ち着いたのか」と言うところは、周りから見ただけでは分からないので、安易に批判するのは良くないなと感じている。 2024-06-04 06:57:54
開発における認知負荷を低減するためにオープンワークで実践していること7選 - OpenWork Tech Blog
Webアプリチームの西川です。面談でよく話題に挙がることをうまくまとめたいと思っていたところ、「認知負荷」というキーワードである程度まとめられそうだったのでまとめてみました。 認知負荷とは 「ワーキングメモリで利用される心理的労力の総量」として提唱されたものであり「課題内在性負荷」、「課題外在性負荷」、「学習関連負荷」に分類されます。 課題内在性負荷：課題を解決するにあたり必要となる基礎的な知識（例：プログラミング言語、フレームワークなど） 課題外在性負荷：タスクが実施される環境の知識（例：デプロイ、リリース手順など） 学習関連負荷：特別な注意が必要な知識（例：SEO、業務知識など） （参考：チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計） 認知負荷を低減するために実践していること 1. ペアプログラミング 低減する負荷：課題内在性負荷 当社ではリモートワークが主体の
技術選定、してますか？ こんにちは！エンジニアリングマネージャーの佐藤（@unsoluble_sugar）です！ 今回は開発関連のライブラリやアセットを導入する際に、個人的に見ている技術選定過程のポイントについて書き残してみることにしました。 エンジニアであれば様々な場面で技術選定の判断を求められるかと思います。フロントエンドやサーバサイド、ネットワーク・インフラ構築、CI/CDといった開発領域。OS、言語、フレームワーク、開発ツール、SaaS、プラットフォームetc... 挙げだすとキリがないですよね。 個人開発等でユーザーの母数が小さかったり、運用期間が短く影響範囲が軽微な場合はそれほど気にしなくて良いかもしれません。一方で、企業としてシステム・アプリ開発をする上では、開発して終わりではなく中長期での運用保守が前提となりますので、サービス継続のための様々な点に注意しなければなりません。
ひと昔前のシステム開発では「どのように開発を行うか（How）」に重点を置き進められていましたが、その進め方では不備や失敗が多く、ひととおり経験したのちに、現代のシステム開発の関心事は「どんなシステムが必要か（What）」に変わりました。 このように、よいシステムを開発するには、考え方や進め方、成果物の書き方に至るまで、目的や環境に合わせて常に変化していく必要があります。しかし、ただ一つ変わらないことがあります。品質は顧客が決めるということ、つまり「品質＝顧客満足度」という図式です。 今回は、システム開発の超上流工程の要求定義と品質をテーマに、要求定義の進め方や書き方、要件定義書やRFPとの違いに至るまで網羅的に解説していきます。どうぞ最後までお付き合いください。
筆者「失敗は実際にやらかすとダメージが大きい。この本で失敗を疑似体験して、役に立てて欲しい」→こうしてできあがった失敗本『ソフトウェア開発現場の「失敗」集めてみた。』
出石聡史@『ソフトウェア開発現場の「失敗」集めてみた。』発売中！ @sdeishi #ソフト開発失敗本 ができるまで総集編。2/8 その1「事件はビアバーで起こっている」 その2「ビビリものの選択」 その3「投稿をレビューしてもらう」 その4「心の準備は出来ていないけど一歩踏み出す」 #開発 #エンジニア pic.twitter.com/yygAZVERrD 2024-06-12 12:57:18
「心理的安全性を高めたい」という企業からの依頼 安斎勇樹氏（以下、安斎）：ここまでお互いの書籍の概要をお話ししてきました。ここからは少し石井さんとディスカッションをしながらやっていければなと思っています。 石井遼介氏（以下、石井）：安斎さんのおっしゃっていた、「なるほど、わかった。うちがだめなのは心理的安全性がないからだ！ すっきり」というのは、本当にあるんですよね。 安斎：今日はこれを掘り下げましょうよ。僕、困っているんですよ。 （一同笑） 安斎：先に困っていることを言っていいですか。 石井：もちろんです。 安斎：僕、『問いかけの作法』で講演の機会をたくさんいただけて、ありがたいなと思っていて。呼んでいただいたところに「過去にどんな方が登壇されたんですか」と聞くと、だいたい石井さんが登壇しているんです（笑）。石井さんが登壇した会社の社内セミナーに、僕が数ヶ月後に行くパターンが多くて。 『
アルプの開発チームがどのように開発手法を試行錯誤しているかを残しておく。振り返ることでこれまでどのようなことを、どのようなチームで、どのようなアイデアで解決してきた*1のかを整理できる。 改めて振り返ってみると「開発手法に銀の弾丸などない」という一言に尽きるくらい、変化が激しい。それでもやってこれたのは、より良い開発にこだわり続ける情熱を持ちつつ、変化に寛容なチームだからだろう。 なお、これは古いドキュメントを辿った断片的な情報の集約であり正確ではないため、チームからのレビューなどでアップデートされる可能性が高い。 「誰かのために〜」とは考えていないが、あえて言うならば、これから入る未来の仲間へ向けていると言えるかもしれない。歴史は文化として残るか、文章になる。文化は僕らが行動で示していくが、理由を知りたい人もいると思う。そんな人はこのブログを読むのをお勧めする。 これを読まなくても困らな
要求定義とは？要件定義との違い、進め方のポイント
要求定義はシステム開発の用語で登場しますが、要件定義と混同したり、中身を決めるときの方法や内容が違ったりして、さまざまな失敗やトラブルを引き起こします。 システム開発をベンダーに依頼する場合には、システム開発を依頼する担当者も要求定義や要件定義の違いを理解した上で、要求定義や要件定義を進めていく必要があります。 本記事では、要求定義と要件定義の違いをわかりやすく解説した上で、要求定義の重要性や陥りやすい失敗事例、進め方のポイントについて解説していきます。 要求定義・要件定義の違いは？ システム開発会社ごとやシステム開発に関わる企業担当者によって「要求定義」と「要件定義」の言葉の指す範囲や意味が異なる場合があります。しかし、両者の定義を不明瞭に開発を進めることは、後述するようにさまざまな問題を引き起こします。本章では、要求定義と要件定義の違いについて、わかりやすく解説していきます。 要求定義
アジャイルテスティング問答 - 千里霧中
先日、「人類よ！これがアジャイルテスティングだ！QAテックリードが語るアジャイルQAの実践とは何か？ - connpass」というイベントに登壇させていただきました。 インタビュー形式だったので講演資料などは特に残ってないのですが、内容の記録のため公開に差し障りのない問答についてまとめたいと思います。念の為、一般的な定義というより、あくまで自分なりの考えになります。 Q. アジャイル開発におけるQAエンジニアの役割と責任は? QAエンジニアの定義に幅があるので難しい問いですが、今回はプロダクトの品質を保証する役割の人を、QAエンジニアという前提で話します。 まずアジャイル・ウォーターフォールなどプロセスを問わない役割として、QAエンジニアは、様々な品質を保証する手段を直接担当したり、支援したりして、総体として品質を保証する仕組みを構築する役割だと考えています。 直接担当の役割としてはQAテ
こんにちは。Leaner Technologiesの小久保(twitter:@yusuke_kokubo)です。 これはなに Leanerでは「Leaner見積」と「Leaner購買」という二つのプロダクトを開発提供しています。 ここでは「Leaner見積」の開発プロセスをざっくり説明します。 開発プロセスはプロダクトや事業、組織のフェーズによって日進月歩で変わっていきますので、あくまで執筆時点のスナップショットとしてご覧ください。 この開発プロセスの狙い 顧客フロントに立っているセールスや、カスタマーサクセスのメンバーと共同でプロダクト開発をするにあたり、以下の課題を設定して考えました。 （ビジネス側とDev側で）開発粒度の認識をいい感じに合わせたい （ビジネス側とDev側で）開発するうえでの難しさの認識をいい感じに合わせたい 今の開発プロセスになる前は、ここの認識が上手く合っていなかっ
変化の速い現代において、臨機応変に対応しやすい開発手法として「アジャイル開発」があります。この記事では、アジャイル開発について詳しく解説します。 あらゆる業界で変化のスピードが速まり複雑化している現代においては、将来を正しく予想し、それに基づき計画を立ててプロダクトを開発していくことが難しくなってきています。場合によっては計画段階で見込んでいた条件や状況が、実行段階には変化していることもありえます。そういったケースにも臨機応変に対応しやすいのが「アジャイル開発」です。この記事では、アジャイル開発について詳しく解説します。 agile（アジャイル）には、「機敏な」「素早い」「迅速な」などの意味があります。アジャイル開発は、その名の通り、ソフトウェアの開発をスピーディーに、そして柔軟に行うことができる手法のひとつ。要求や要件定義、計画、設計、開発、テストといった一連の開発工程を短期間で反復的に
Webサイトのデザインや設計を行うとき、昔は工程によっていろんなツールを使い分けていました。今はそれを（私の愛してやまない）Figma一つでブラウザ上だけで完結できます！ 【目次】 私の愛してやまないFigma Webサイトの制作フロー ヒアリング（オリエン） 要件定義 サイトマップ ワイヤーフレーム デザインラフ デザインカンプ プロトタイプ フローチャート 実装段階もシームレスに 最後に 私の愛してやまないFigma 私の愛してやまないデザインツールFigma、ブラウザ完結のツールです。このブログ上の図もほとんどFigmaで作っています！ ※参考：Figma: the collaborative interface design tool. 操作感はAdobe XDなんかと似た感じです。イラレのようにベクターデータのパスを描ける！ ※参考：4-5. ペンツールと鉛筆ツールの使い方 |
なまぬるいおにぎり🍙 @onigiritan ユーモアとものづくりが好きなおにぎり🍙 IT系の笑いを時々届ける、スタートアップのUIデザイナー（女性です）｜変な制作物はモーメントに👇最近作ったサービスは👉 #ITおみくじ （現在停止中🙏）有益ツイートしたい人生だった（皆無） amazon.jp/hz/wishlist/ls…
bwin·必赢(中国)唯一官方网站
Webシステム／Webアプリケーションセキュリティ要件書 Ver.4.0 (2022年6月) 2022年6月に、「Webシステム/Webアプリケーションセキュリティ要件書 Ver.4.0」に更新しております。 【WG1】 ISOG-JセキュリティオペレーションガイドラインWGとOWASP Japan主催の共同ワーキンググループである「脆弱性診断士スキルマッププロジェクト」は、『Webシステム／Webアプリケーションセキュリティ要件書 Ver.3.0』を公開しました。 本ドキュメントは、Webシステム／Webアプリケーションに関して一般的に盛り込むべきと考えられるセキュリティ要件について記載しています。また、開発言語やフレームワークなどに依存することなくご利用いただけます。(2019年1月)
新人Webディレクター必見！要件定義とは
更新日: 2017年3月21日公開日: 2016年10月27日新人Webディレクター必見！要件定義とは Web ディレクターにとって必須工程となる要件定義。 なんだか面倒くさそう、難しそう、と思って後回しにされていませんか？ 自己防衛の意味でも 要件定義 は重要なファクターとなりますので、頑張って基礎知識だけでも習得しておきましょう！ 新人Webディレクター必見！要件定義とは要件定義とは img:IPA 要件定義とは、Web サイトやアプリケーションなどの開発初期段階において、発注者と受注者の情報共有のために、実装すべき機能や満たずべき性能を第３者でも分かるように明確化しておく作業のことです。 要件定義は、Web サイトやアプリ開発において非常に重要な役割を担っていて、要件定義のでき次第で開発の成功が左右されるとも言われています。 一般的に要件定義の主導権は受注側（開発側）のディレクターが
「トヨタ流 勝ち残る設計」
連載趣旨 トヨタ自動車はなぜ強いのか。その理由は「トヨタ生産方式（TPS）」にあると、これまで頻繁に語られてきました。生産現場のムダ・ムラ・ムリを徹底的に追及して改善するゲンバの方法は製造業の模範となり、競合他社のみならず、他の業界までが導入する取り組みとなっています。 しかし、TPSに勝るとも劣らない、いや、それ以上に高い競争力を磨いたものがあります。それが、設計です。設計力が伴っていなければ、いくら生産現場でムダを削っても、優れた製品を形にすることはできません。 では、トヨタの設計は何が違うのでしょうか。まず、トヨタは「トヨタ車を選ぶお客様は安全と安心を購入する」と考えています。そのため、安全と安心を最優先した上で、品質と性能の目標を立てていきます。前段がなく、いきなり品質と性能の目標を立てる多くの企業とは一線を画す考えを持っていると言えるでしょう。これは、「トヨタらしさ」とは何かと、
『継続的デリバリーのソフトウェア工学』は、『継続的デリバリー』の共著者として著名なDavid Farley（デイビッド・ファーリー、ファーレイと表記する場合もある）による「もっと早く、もっと良いソフトウェアを作るための」書籍です。 本書が力を入れて説明しているのは特定の手法ではなく、高品質なソフトウェアを迅速に開発する際に役立つ10個のスキルとその関係です。 本書で説明されるテスト可能性、デプロイ可能性、スピード、変数の管理、そして、継続的デリバリー（Continuous Delivery）といった最終的な目標を目指せば、開発プロセスが逆算されて結果的に高品質なソフトウェアを迅速に開発しやすくなるでしょう。本書ではこの目標に到達するために、「学びのエキスパート」であることと「複雑さ管理のエキスパート」であることが求められるとし、それぞれに必要な5個ずつ合計10個の重要なスキルが具体的、かつ
「上司・部下のぎすぎす」を一発解決したすごい一言
テキサス大学オースティン校を卒業後、Thinkwell社を共同創設、ハーバード・ビジネス・スクールでMBAを取得。現在はデューク大学ビジネススクール社会起業アドバンスメントセンター（CASE）でシニアフェローを務めている。兄チップとの共著に『アイデアのちから』（日経BP）、『スイッチ！』『決定力！』（ともに早川書房）、『瞬間のちから』（ダイレクト出版）がある。著書は世界300万部以上を売り上げ、33言語に翻訳されている。米国ノースカロライナ州ダーラム在住。 上流思考 私たちは「ちょっと変えればいいだけ」のことをしていないために、毎日、膨大な「ムダな作業」をくりかえしている。全米最注目著者ダン・ヒースが、何百もの膨大な取材から生み出した話題作『上流思考』から、一部を特別掲載します。 バックナンバー一覧 『上流思考──「問題が起こる前」に解決する新しい問題解決の思考法』が刊行された。世界150
要件定義書テンプレート｜システム開発を成功に導く進め方
要件定義書テンプレート(サンプル付) 要件定義書のサンプルテンプレートを紹介します。要件定義書は進めるプロジェクトによって実際に記載する項目はことなるので、フォーマットのサンプルとして必要部分を参考にしてください。 エクセル版 エクセル版の要件定義書のサンプルテンプレートです。表紙と目次、各項目のフレームだけが使用できます。エクセルの場合、図や表を作成するのは容易ですが、目次を作成するのが大変なのでワードと併用するといいでしょう。
Pipfile/Pipfile.lockの必要性 -requirements.txtを用いる手法と比較して- - Qiita
Pythonの開発環境構築にPipenvをつかっていると、ライブラリのバージョン管理のためにPipfile/Pipfile.lock（以下、両者の総称として"Pipfile"と呼びます）が使われます。 一方、Pipfile以前から使われてきたバージョン管理のファイル形式として、requirements.txtがあります。 なぜPipenvでは、既存のrequirements.txtでの管理を捨て、Pipfileを用いたバージョン管理を行うのでしょうか。 requirements.txtでのバージョン管理の問題点についてPipenvの開発者が触れている記事があったので、この内容を元に、Pipfileのメリットについて確認しようと思います。 https://www.kennethreitz.org/essays/a-better-pip-workflow tl;dr Pipfileを用いたバー
GitHub における PR レビュープロセス - conversation の活用 | 豆蔵デベロッパーサイト
GitHub の PR(Pull Request) レビューのプロセスは、開発チームによってバリエーションはあると思いますが、おおよそ次のようになると思います。 flowchart TB subgraph レビューイ ブランチ作成-->コード修正-->PR作成-->レビュアーアサイン subgraph レビュー対応 コメント箇所修正-->rep[conversation リプライ] end レビュー対応-->再レビューリクエスト end subgraph レビュアー レビュー-->CH{Conversation<br>がない or<br>全て resolved}-->|yes|approve-->マージ CH-->|no|RC[Request changes] subgraph レビュー cv[インラインコメント<br>conversation 開始] end subgraph 再レビュー
コードレビューのスピード
コードレビューのスピード なぜコードレビューは素早く行うべきか？ Google では開発者のチームが協力してプロダクトを高速に開発するために最適化しており、開発者個人がコードを高速に書くための最適化はしません。 開発者個人のスピードは確かに重要ですが、チーム全体のスピードと比べると同等の重要性があるわけではありません。 コードレビューが遅滞するとさまざまなことが起こります。 チーム全体の開発速度が減少します。もちろん、レビューに素早く反応しなくても個人としては他の仕事を終わらせられます。 けれども、チームの他のメンバーが書いた新機能や不具合修正は、CL がレビュー待ち、再レビュー待ちになると何日も何週間も遅れることになります。 開発者がコードレビューのプロセスに不満を持ち始めます。 レビュアーが数日おきにしか返信しないのに毎回 CL への大きな変更が要求されると、開発者はストレスをためるし
大まかな前提条件はじめに要件定義、要件開発に関する記事、書籍は多くありますが（当然ながら特にシステム開発関連が多いですが）、ここではWebサイトのリニューアルに限定した要件定義の内容や進め方について、これまでの経験を元に、私なりにまとめていきたいと思います。 Webサイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。 また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては３ヶ月から１年程度の期間で行うリニューアルを想定した内容となります。 受託案件（発注側からは外注する）の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側（制作者側）の内容として記載していきます。 対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。 Webサイトリニューアル
sebook-ind.dvi
15 9 11 1 5 1.1 5 1.2 5 1.3 7 1.4 8 1.5 8 2 11 2.1 11 2.2 11 2.3 12 2.4 14 2.5 15 2.6 18 3 21 3.1 21 3.2 21 3.2.1 21 3.2.2 23 3.3 24 3.3.1 24 3.3.2 25 3.3.3 26 3.4 27 3.4.1 27 3.4.2 28 3.4.3 28 3.4.4 29 4 UML 30 4.1 30 4.2 30 4.2.1 30 4.2.2 31 4.3 32 4.3.1 32 4.3.2 32 4.3.3 33 4.3.4 34 4.3.5 34 1 4.4 UML 35 4.4.1 35 4.4.2 UML 36 4.5 36 4.5.1 37 4.5.2 38 5 39 5.1 39 5.2 40 5.3 Demarco 41 5.4 42 5.5
ある日突然上司から、「例の案件の要件定義を、至急作成してくれ」と頼まれたらどうしますか？ まずすべきことは、お客さんの要望を把握する「要求分析」とそれをベースにシステムの全体像を決定する「要件定義」の2つのステップがあることを把握した上で、そのプロセスを上司と共有し、顧客ニーズに関する資料を集めるべきです。 そして顧客（エンドユーザー）は何をしてほしいのか、そのためにどのような機能を実装し、どのように進めていくのかをヒアリングし、決定することです。それを文書に落としたものが、要件定義書です。 IT分野で発生するトラブルの実に40％は、要件定義の不十分さに起因すると言われています。 要件定義は、文章を作成する時の「5W1Hの法則-Who（誰が）、When（いつ）、Where（どこで）、What（なにを）、Why（なぜ）、How（どのように）」に似ています。 本記事では初心者の方向けに、要件定
要件と機能の関連を保つテンプレート
要件定義で使用するドキュメント 上流工程は、主に要件定義フェーズと基本設計フェーズに分けられますが、基本設計フェーズは次回お話しますので、今回は要件定義フェーズでのドキュメントについて述べていきます。 要件定義フェーズで使用するドキュメントにはどのようなものがあるでしょうか？ 要件定義の進め方としては、顧客の行っている業務、例えば「見積業務」「調達業務」「請求業務」単位で打ち合わせ日程を決め、それに従って構築するシステム要件のヒアリングを進めていきます。 顧客とのヒアリング時に打ち合わせ内容を記録する「議事録」や、出てきた課題をリスト化して管理する「課題一覧」などももちろん必要です。ただ、こちらはいずれ「プロジェクト管理」について紹介する機会があれば、その時に説明させていただくこととし、「開発ドキュメント」という切り口では、「要件一覧」「機能一覧」についてクローズアップします。 要件一覧は
ユーザーからの希望や願いは、しばしば「要求」や「要件」という用語で表現されます。多くのＩＴ企業ではどちらかしか使わず、しかもどちらの意味で使っているのかがあいまいなことが多く散見されます。 ですが、実際にはこれら「要求」と「要件」という言葉はまったく異なる意味を持っているものと定義して開発に向き合わないと、プロジェクトの失敗比率が数割上昇します。 要求とは 漠然とした希望や願い、思想、経営上期待している成果など 要件とは 機能・非機能を含めたシステムに対する実現すべき定義 のことを意味しています（ちなみに英語ではすべて「Requirement」で統一されており、「要求」と「要件」の厳密な違いを意識することはありません）。 なぜ「要求」と「要件」の区別が重要なのか。 それは、そもそもビジネスとＩＴには根本的矛盾があるため、まずビジネスとＩＴの２つの側面から、ユーザーの要望を切り分けることが必
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こうすればうまくいく“要件定義のコツ” プロジェクトの牽引役・PMにとって大事なスタンスと心構え
「1on1」はただの面談ではない～メンバーが気づきを得るためのカイゼンの場を作ろう
サービス開発における5つの“不確実性”パターン 曖昧さをコントロールするために、ユーザーストーリーを活用する
エンジニアリングマネージャー目線で見るライブラリ技術選定の勘所 - Activ8 Tech Blog
要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説
「心理的安全性が低くて心理的安全性が上げられない」？ できない理由を探し続ける「ラベル貼り」問題の打開策
Alp開発日誌 Day10 「開発手法史2020」 - 道産子エンジニア
〜2023年11月版〜 Leaner見積の開発プロセス
アジャイル開発とは？プロジェクト推進からチームビルディング、見積もりのコツまでを完全解説
Figmaで完結する！Webサイト設計の流れ - クモのようにコツコツと
要件定義「ここは俺に任せてお前たちは先に実装しに行け！俺も後で追いつく！」→「あかん」「別人になってるやつ」
活動成果｜ISOG-J：Webアプリケーション脆弱性診断ガイドライン
https://twitter.com/tweeting_drtaka/status/1461994920575651849
酒匂寛が推す「より速く、より高品質なソフトを作るための良書」
https://www.agilejapan.org/2018/session/d2_APPRESSO.pdf
/blog/2020/05/solving-uninitialized-stack-memory-on-windows/
Webサイトリニューアルにおける「要件定義」の勘所 vol.1
要件定義とは？全体の流れ、メリット、書き方まで、解説します - 企画書作成.COM
「要求」と「要件」の違い｜Takashi Suda / かんた
mainichi.jp
satotarokarinona.blog.fc2.com
koubodatabase.com
hanarejima.com
kitadekeiei.jp
gekirock.com