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

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

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

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

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

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

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

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

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

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

システム開発におけるデータベース設計の重要性と、要件定義の成果物をどのように設計に反映するかを解説します。クラス設計とデータベース設計の違い、データ品質の観点、具体的な設計手法について詳しく説明しています。

ビジネス+ITに掲載されたアジャイル開発に関するインタビュー記事を紹介。アジャイル開発でよくある失敗や誤解、成功のポイント、体制づくりについて、前編・中編・後編に分けて解説します。アジャイル開発を学び始めた方や、現場での活用に疑問を持つ方への…

ソフトウェア開発における「関心の分離」と「高凝集」という重要な設計原則について、これらの概念がなぜ重要なのかを説明し、具体的な設計手法として「オブジェクト指向設計」を取り上げ、特にその中核となる「クラス設計」の考え方を紹介しています。 クラ…

本記事では、システム開発における要件定義とソフトウェアアーキテクチャ設計の重要性について解説します。要件定義で作成された成果物をどのように設計に活用するか、また設計プロセスの流れや観点を理解することで、要件定義の成果物の実用性や完成度を大…

ROUTE06社に、要件定義の重要性と実践のポイントをテーマにインタビューしていただいた記事の紹介です。 特に要件定義の初期段階や、それ以前の企画・要求分析段階における考え方について掘り下げています。

要件定義のゴールは、設計の精度を高めるためのインプットとなる成果物を作成することです。そのためのシステム要件定義の成果物は、(1)ユースケース、(2)ロバストネス図、(3)開発品目の一覧、機能要件、非機能要件、(4)システム構成図、(5)概念モデルです。…

本記事では、システム要件定義において ユースケースとロバストネス図を活用してシステムの要素を抽出する方法 を説明します。前回の記事では 業務フロー図を用いてユースケースを導出 しましたが、本記事ではそのユースケースを詳細化し、ロバストネス図を…

「意」と「情」は互いを高め合う相乗効果が働きます。企画を進める際は、自分たちの「意」を「情」を通じて検証することが重要です。明確な「意」によって「情」に方向性を与えることでき、「情」によって「意」の視野を拡げることができます。

U理論でいうところの「self」と「Self」という概念や、匠Methodの要求分析ツリーにおける「業務要求」と「戦略要求」という概念を紹介しました。そして、これらの概念に共通する、次元を変えることによって問題解決につながります。論理思考で導いた結論を感…

U理論の「観察する」は、判断を「保留」して、立ち止まってフラットな目で見るという意味。現状を分析しすぎると、現状に囚われすぎてしまいます。問題解決のアプローチにすぐに行くと、本質的な解決に至らないことが多いです。匠Methodを用いて価値を見える…

匠Methodの進め方には、価値デザインモデルから始める方法と価値分析モデルから始める方法の2つがあります。経営者や事業レベルの人であっても、従来の成功パターンにとらわれ、新しいビジョンを見出せないことがあります。これは**U理論でいう「ダウンロー…

匠Methodでは「現意識」と「新意識」による未来価値を定義し、特に新意識は社会をより良くしようとする意志に基づく価値創出を意味します。自己中心的な視点から抜け出し、広い視野でビジョンを描くことが重要です。意志（意）を育むことが、より良い未来価…

匠MethodとU理論とのマッピング、およびU理論におけるプレゼンシングからビジョンを見出すプロセスについて解説しています。U理論の考え方を匠Methodのモデリングに取り入れる方法として、「自分たちは何者なのか」という問いを設定し、存在意義を深く考える…

システム開発では、ビジネス側と開発側が協調し、ビジネス価値の創出に向けて動くことが求められます。『超上流から攻めるIT化の原理原則17ヶ条』の第1条『ユーザとベンダの想いは相反する』の原則は、システム開発において、ビジネス側と開発側が持つ責任の…

要件定義を効果的に行うには、ビジネス側と開発側が協力し、互いの視点や目的を共有することが不可欠です。ビジネス側と開発側は具体的にどのように協力すればよいか、指針として参考になるのが、『*超上流から攻めるIT化の原理原則17ヶ条*』です。『超上流…

業務プロセスを構想し、整理する手段として、業務フロー図の作成が有効です。業務フロー図を作成する効果として、5W2Hの視点で業務の必要事項を漏れなく詳細化できること、業務の課題点発見とステークホルダー間の共通理解が促進されること、テスト設計や運…

ゴール記述モデルは、自分たちが果たすべき役割や責任を明確にし、覚悟を促すためのモデルです。このモデルを用いて計画の期間や担当者を決めることで、チームメンバーは現実的に自分ごととして捉えるようになります。また、ゴール記述モデルは、価値が適切…

匠Methodのモデリングにおいて、論理思考の落とし穴に陥らないためには、匠Method Value Metricsを活用して価値概念を記述し、価値を評価することが効果的です。価値概念を明確にすることで、認識の精度をより高めることができます。要求分析ツリーにおいて…

ビジネス+IT様にシステム開発の要件定義に関するインタビューを受け、その内容が前編・後編の2部構成で記事として公開されました。要件定義の重要性やうまくいかない原因、アジャイル開発の誤解について前後編でじっくり解説しています。

V字モデルのレイヤーのうち、「企画」プロセスと「運用・評価」プロセスと、その関係性について説明します。