V字モデルの底に位置する「プログラミング」と「コードレビュー」プロセスを取り上げ、ソフトウェア開発の品質を根本から支えるその重要性を解説します。プログラミングは設計で定義された仕様をコードとして具現化し、ソフトウェアの価値と品質を最も直接的…

V字モデルにおける「詳細設計」と「単体テスト」の関係を解説します。詳細設計は、画面・API・機能などのコンポーネントや、それらを構成するモジュールの構造・処理を実装可能なレベルまで具体化する工程です。一方、単体テストはその設計をもとに、各モジ…

V字モデルにおける「基本設計」と「結合テスト」の関係を解説します。基本設計は、ソフトウェア全体の構造を明確にし、画面・API・バッチ処理などのコンポーネントの責務や連携方法を定義するプロセスです。一方、結合テストは、基本設計で定義したコンポー…

この記事では、V字モデルにおける「要件定義」「運用テスト」「システムテスト」プロセスの関係を体系的に解説します。 V字モデルでは、左側で定めた要件を右側のテスト工程で検証する構造になっており、要件定義は“何を作るか”を定めるプロセス、運用テスト…

本記事では、システム開発における要件定義と設計の関係を体系的に解説します。要件定義で整理された「何を作るか（What）」をもとに、「どのように実現するか（How）」を設計へと具体化する流れを、ソフトウェアアーキテクチャ設計、クラス設計、データベー…

要件定義を成功させるには、流れを体系的に理解し、必要な成果物を正しく準備することが欠かせません。本記事では「要件定義とは何か」を整理し、要望から要求・要件へとつなぐ三層構造の考え方、業務フロー図やユースケース、ロバストネス図による具体化の…

システム開発では、事業・業務・システム要件に加え、現行環境から新環境へ円滑に切り替えるための移行要求（移行要件）を定義することが不可欠です。国際的なビジネス分析ガイド BABOK では、この移行要求を「一時的に必要となる要件」として位置づけていま…

要件定義の学習や実務に役立つおすすめ書籍を厳選して紹介するまとめ記事です。入門者向けの「はじめよう！要件定義」から、業務要件定義を深く学べる「はじめよう！プロセス設計」、中級者向けの名著「ソフトウェア要求 第3版」、USDMを提唱する「要求を仕…

本記事は「非機能要件」をわかりやすく解説します。性能・可用性・セキュリティ・保守性など、機能要件では語れない“どう動くか”の品質を定義し、システムアーキテクチャ／ソフトウェアアーキテクチャへの具体的な落とし込みを紹介します。

本記事では、システム開発における「要件」とは何かを、日本の現場特有の「要望→要求→要件」という三段階の整理と、事業・業務・システムといった階層構造の視点から解説しています。英語圏では Requirement という一語で包括されるのに対し、日本では合意形…

バッチ処理設計と要件定義の関係を解説します。バッチ処理は売上集計や在庫更新、帳票作成などに不可欠な仕組みであり、リアルタイム性よりも業務開始前までに正しく完了していることが求められます。記事では、機能要件としての入力・処理・出力の整理方法…

API（Application Programming Interface）は、異なるシステムやアプリケーションをつなぐ重要な仕組みです。本記事では、特にWeb APIを対象に、要件定義とAPI設計の関係を解説します。外部公開APIの特性やRESTful APIの設計手法を取り上げ、機能要件を「入…

TRACERY開発メンバーの清水川が、Podcast「terapyon channel」にゲスト出演し、AIコーディングやMCP連携機能の活用について語りました。エピソードでは、AIエージェントとの付き合い方、GitHubやAWSを活用したMCPサーバー事例、Issueを起点としたAI駆動開発…

TRACERYとMCP連携によるAI開発デモを解説。設計書からAPI実装、ドキュメント登録までの流れを動画付きで紹介。

TRACERYがMCP正式対応。AI駆動開発を加速する連携手法を、BPStudyでの発表内容と動画アーカイブを通して詳しく解説。

ユーザーに「使いやすい」と感じさせる画面設計には、直感的な操作と自然な導線が欠かせません。本記事では、システム開発における画面設計の基本から、ユーザーの思考順序（対象→操作）に基づいたオブジェクト指向UIの活用法までを詳しく解説。さらに、ナビ…

システム開発の成功には、要求の妥当性を早期に検証し、関係者間で認識を揃えることが不可欠です。本記事では、そのために活用されるワイヤーフレーム、モック、プロトタイプの違いと、それぞれの適切な使いどころ、注意点を解説します。ワイヤーフレームは…

「保守とは何か？」を正しく伝えるには、その分類と意図を理解することが不可欠です。本記事では、国際規格に基づく保守の4つのタイプ（是正保守・予防保守・適応保守・完全化保守）を体系的に解説し、それぞれの具体例や注意点を紹介します。また、瑕疵対応…

「知識体系（Body of Knowledge）」は、システム開発に求められる専門知識や技術を体系的に整理したガイドです。PMBOK、BABOK、SWEBOKなど、分野ごとに標準化されたフレームワークを活用することで、抜け漏れのない検討やチーム内の共通認識形成が可能になり…

開発者がビジネスへの関心を持ち、開発と価値創出を結びつけるにはどうすればよいのか。本記事では、ビジネスアナリシスの実践者とDDD実践者が、現場での工夫や対話の重要性について語ります。顧客視点での問いかけ、戦略と設計の接続、シニアの背中を見せる…

生成AIの進化は、要件定義や企画書作成などビジネスアナリシスの領域やソフトウェア開発に大きな影響を与えつつあります。本記事では、ビジネスアナリスト、ソフトウェアエンジニア、DDD実践者の視点から、生成AIと人間の役割分担をどう考えるべきかを議論し…

BABOKは、ビジネスアナリシスの知識体系として知られていますが、その活用には読み手の解釈と実務経験が不可欠です。本記事では、BABOKのバージョン2と3の違いや、要件定義や上流工程での使いどころ、現場で役立つエッセンスの見極め方を、開発者・アナリス…

戦略的に差別化すべき業務領域を見極め、そこに集中投資するという点において、ビジネスアナリシスとドメイン駆動設計は同じです。ビジネスアナリシスとドメイン駆動設計の接点として、差別化戦略、ビジネスルールが考えられます。ビジネスルールを導くため…

BPStudy#213の第2部として開催された「ビジネスアナリシスとDDD（ドメイン駆動設計）」に関するパネルディスカッションの様子をお届けします。ビジネスアナリシスとDDDそれぞれの専門家が、両者の関連性やV字モデルにおける位置づけ等を話しました。

「見積りソン」に参加したパネラーたちの感想です。他社の見積もりが見られるのは本当に貴重で、書籍などでは決して得られない情報です。他の会社がどのように見積もりを立てたのかを知る機会はなかなかありません。RDRAを用いることで、工数と金額が明確に…

新規システム開発と既存システム改修では、見積もりの進め方や考え方が異なる点が議論されました。既存システムの修正では、影響範囲の調査や品質リスクの見立てが特に重要であり、有識者の分析が不可欠であることが強調されています。 既存システムの修正で…

開発見積りをテーマにしたパネルディスカッションの内容をまとめた記事です。過去の経験を見積りに活かす方法について議論しています。 見積もり結果や実績データの蓄積・活用方法、プロジェクト終了後の振り返りの重要性などが話題にあがっています。

開発見積もりにおけるトレードオフの考え方について議論しています。特に、予算感の早期共有、要件のツリー構造化による優先順位の明確化、品質の重要性について掘り下げています。パネリストたちの議論を通じて、見積もりプロセスにおけるコミュニケーショ…

ソフトウェア開発の見積もりをテーマにしたパネルディスカッションの内容を紹介する記事です。この記事では特に、「高すぎる」と言わせない見積りの技術について議論されています。見積もりの根拠を明確にすること、早い段階で見積もりを提示すること、スコ…

BPStudy#210で行われたパネルディスカッション「開発見積りの重要論点」の内容を詳細レポート。第1回は「内製開発と外部委託における見積りの相違点」に焦点を当て、注意点や落とし穴を話しあいました。