エンジニア
システム品質は外部品質だけでは維持できません。利用時の品質・内部品質・プロセス品質の4つの視点から、品質が崩れる原因と継続的に品質を高める方法を解説します。
コードレビューから運用・評価まで、V字モデルに沿った品質保証プロセスの目的と進め方を整理。システム開発で品質を確実に積み上げる方法を解説します。
システム開発における「トレーサビリティ（traceability：追跡可能性）」の基本概念を、V字モデルの構造に沿って説明しています。要求・要件・設計・実装・テストといった各プロセスがどのように対応し合い、整合性を保ちながら品質を高めていくのかを、4つ…
V字モデルの底に位置する「プログラミング」と「コードレビュー」プロセスを取り上げ、ソフトウェア開発の品質を根本から支えるその重要性を解説します。プログラミングは設計で定義された仕様をコードとして具現化し、ソフトウェアの価値と品質を最も直接的…
V字モデルにおける「詳細設計」と「単体テスト」の関係を解説します。詳細設計は、画面・API・機能などのコンポーネントや、それらを構成するモジュールの構造・処理を実装可能なレベルまで具体化する工程です。一方、単体テストはその設計をもとに、各モジ…
V字モデルにおける「基本設計」と「結合テスト」の関係を解説します。基本設計は、ソフトウェア全体の構造を明確にし、画面・API・バッチ処理などのコンポーネントの責務や連携方法を定義するプロセスです。一方、結合テストは、基本設計で定義したコンポー…
この記事では、V字モデルにおける「要件定義」「運用テスト」「システムテスト」プロセスの関係を体系的に解説します。 V字モデルでは、左側で定めた要件を右側のテスト工程で検証する構造になっており、要件定義は“何を作るか”を定めるプロセス、運用テスト…
本記事では、システム開発における要件定義と設計の関係を体系的に解説します。要件定義で整理された「何を作るか（What）」をもとに、「どのように実現するか（How）」を設計へと具体化する流れを、ソフトウェアアーキテクチャ設計、クラス設計、データベー…
要件定義を成功させるには、流れを体系的に理解し、必要な成果物を正しく準備することが欠かせません。本記事では「要件定義とは何か」を整理し、要望から要求・要件へとつなぐ三層構造の考え方、業務フロー図やユースケース、ロバストネス図による具体化の…
システム開発では、事業・業務・システム要件に加え、現行環境から新環境へ円滑に切り替えるための移行要求（移行要件）を定義することが不可欠です。国際的なビジネス分析ガイド 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では「現意識」と「新意識」による未来価値を定義し、特に新意識は社会をより良くしようとする意志に基づく価値創出を意味します。自己中心的な視点から抜け出し、広い視野でビジョンを描くことが重要です。意志（意）を育むことが、より良い未来価…
