バッチ処理設計と要件定義の関係を解説します。バッチ処理は売上集計や在庫更新、帳票作成などに不可欠な仕組みであり、リアルタイム性よりも業務開始前までに正しく完了していることが求められます。記事では、機能要件としての入力・処理・出力の整理方法…
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回は「内製開発と外部委託における見積りの相違点」に焦点を当て、注意点や落とし穴を話しあいました。
システム開発におけるデータベース設計の重要性と、要件定義の成果物をどのように設計に反映するかを解説します。クラス設計とデータベース設計の違い、データ品質の観点、具体的な設計手法について詳しく説明しています。
ビジネス+ITに掲載されたアジャイル開発に関するインタビュー記事を紹介。アジャイル開発でよくある失敗や誤解、成功のポイント、体制づくりについて、前編・中編・後編に分けて解説します。アジャイル開発を学び始めた方や、現場での活用に疑問を持つ方への…
ソフトウェア開発における「関心の分離」と「高凝集」という重要な設計原則について、これらの概念がなぜ重要なのかを説明し、具体的な設計手法として「オブジェクト指向設計」を取り上げ、特にその中核となる「クラス設計」の考え方を紹介しています。 クラ…
本記事では、システム開発における要件定義とソフトウェアアーキテクチャ設計の重要性について解説します。要件定義で作成された成果物をどのように設計に活用するか、また設計プロセスの流れや観点を理解することで、要件定義の成果物の実用性や完成度を大…
ROUTE06社に、要件定義の重要性と実践のポイントをテーマにインタビューしていただいた記事の紹介です。 特に要件定義の初期段階や、それ以前の企画・要求分析段階における考え方について掘り下げています。
要件定義のゴールは、設計の精度を高めるためのインプットとなる成果物を作成することです。そのためのシステム要件定義の成果物は、(1)ユースケース、(2)ロバストネス図、(3)開発品目の一覧、機能要件、非機能要件、(4)システム構成図、(5)概念モデルです。…
本記事では、システム要件定義において ユースケースとロバストネス図を活用してシステムの要素を抽出する方法 を説明します。前回の記事では 業務フロー図を用いてユースケースを導出 しましたが、本記事ではそのユースケースを詳細化し、ロバストネス図を…
「意」と「情」は互いを高め合う相乗効果が働きます。企画を進める際は、自分たちの「意」を「情」を通じて検証することが重要です。明確な「意」によって「情」に方向性を与えることでき、「情」によって「意」の視野を拡げることができます。
U理論でいうところの「self」と「Self」という概念や、匠Methodの要求分析ツリーにおける「業務要求」と「戦略要求」という概念を紹介しました。そして、これらの概念に共通する、次元を変えることによって問題解決につながります。論理思考で導いた結論を感…
U理論の「観察する」は、判断を「保留」して、立ち止まってフラットな目で見るという意味。現状を分析しすぎると、現状に囚われすぎてしまいます。問題解決のアプローチにすぐに行くと、本質的な解決に至らないことが多いです。匠Methodを用いて価値を見える…
