プロジェクトマネジメント のページでは、プロジェクトの対象が広い場合と狭い場合が書かれています。 狭い場合というのが、システム開発です。 システム開発で作られたシステムが失敗したり、不具合が起きる原因として、 システム開発の最初の方の段階になっている要件定義の問題があります。
システムの不具合には、開発者のミスによるものが分かりやすい原因ですが、根本の原因をたどると、 要件定義に問題がある場合が、多いそうです。 「プログラミングには何の問題もなかったが、そもそもプログラミングしようとしていたものに問題があった」、というものです。
「要件定義」と「要求定義」は、文献によって読み分ける必要があります。
ネットで調べると、要件定義と要求定義を分け、要件定義の前の段階として、要求定義を説明しているページが、けっこうあります。 なお、英語の文献で、要求定義と要件定義のような２段階があるとしているものを、筆者は見たことがないです。
要求定義と要件定義を分けることにしている文献では、 要求も要件も「定義」して、ドキュメント（要求定義書、要件定義書）にまとまるものと考えています。
要求はユーザー（発注者）側、要件は制作者（受注者）側がまとめるものと考えることが多いようです。
要件定義書の内容は、外部設計書（概要設計書）くらいの内容で、システムの専門家でなければ、知らないような内容が想定されていることが多いようです。 確かにこの内容が「要件」なら、ユーザー側にはまとめられません。 なお、外部設計書に近い要件定義書は、国際的には標準的なものではないようです。
文献によっては、「要件定義」がなく、「要求定義」が書かれている場合がありますが、 この場合は、「要件定義」と「要求定義」の意味は同じです。
英語の「Requirement」の訳語の違いになっています。
要件定義書の内容は、業務の中でどのような位置付けになっているのかを示すものになり、実際にそのシステムを使うユーザーが、 自社の業務をどのようにしたいのかで決まってきます。 そのため、基本的にユーザーが責任を持って作成するものです。
要件定義書の内容は、このようなものが国際的には標準的になっているようです。
要件定義のみで、要求定義が書かれていない文献で、「要求」という言葉が出て来る時には、 英語にした時に、「ニーズ（Needs）」が当てはまってくるような意味合いで使われています。 「要件定義の中でニーズの調査が必要」という流れで説明されます。
要求定義のみで、要件定義が書かれていない文献での「要求」という言葉の使い方は、 システムに求められているものと、システムが満たすべきものの両方の意味が混ざっている感じです。
要件定義の手順は、現在、２つのものがよく言われているようです。 ニーズを重視する方法と、ニーズを出発点とする方法があります。
歴史的にはニーズを重視する方法の方が登場が早いようですが、ニーズを出発点とする方法が国際的な標準になってきています。
ユーザーのニーズを明確にして、その後で、「ニーズを実現するためには」といった考え方をします。
要求定義と要件定義の２段階があるとしている文献は、このような考え方をしています。
このような考え方をする場合は、過去のシステム開発で、システムができてから、ユーザーのニーズに合っていないことがわかって大問題になったことへの反省があるようです。
ただ、どんなにニーズに忠実にできたとしても、そもそもニーズに不備があった時には対応しきれません。 例えば、「例外的な業務が多い」、「発注の担当者が、社内の状況を把握しきれていない」、等の場合です。
システムを作りたいと思ったもともとのニーズがあったとしても、それをその通りに実現しようとするのではなく、 そのニーズの背景、経緯、関係者、等も明らかにします。
問題解決や課題達成 のようにして進めます。 現状を明らかにした上で、未来の姿を描きます。
未来の姿の中でのシステムの位置付けを考えます。 それがシステムの要件になります。
ニーズを出発点とする方法を進める時に、開発したいシステムの目的、内容、関係者、等を分析することは、 「Business Analysis：ビジネスアナリシス：ビジネス分析」と呼ばれることもあります。
そのため、「ビジネスアナリシス」というタイトルの本の内容が、要件の分析になっていることがあります。
広い意味でのビジネス分析としては、 会計の分析 のようなものもあると思いますので、筆者は最初混乱しました。。。
要件定義ができると、システムの構造（アーキテクチャ）の設計になります。
この段階は、要件定義と一体的に考えたり、行ったり来たりで考えるの良いようです。
「要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書」 上村有子 著 技術評論社 2020
要件定義の責任は発注者側にあり、本来、要件定義を作るのは発注者側としながらも、実際に定義する作業は、受注者側がリードして進めるものとしていて、
その受注者側の視点でまとめられています。
発注者側のニーズを元にして、網羅的に定義していく内容になっています。
「プロジェクトを成功に導くシステム外注の教科書 知識ゼロから学べるシステム開発の基礎知識」 島本道夫 著 ナツメ社 2019
要件定義を、業務要件定義とシステム要件定義の２つに大きく分けます。
業務要件定義は、現状の把握から始め、新しい業務プロセスを決めます。
この本は、発注者側の立場で書かれています。
システム開発の実施レベルには、作業改善、業務改善、業務改革の３つがあり、作業改善レベルでは新システムの導入について、再考をすすめています。
「業務デザインの発想法 「仕組み」と「仕掛け」で最高のオペレーションを創る」 沢渡あまね 著 技術評論社 2019
業務が円滑に動くことや、業務の継続的な改善、ステークホルダーの観点、等も踏まえた業務設計の指南書になっています。
そのようなシステム設計に必要な観点や、ノウハウが著者の豊富な経験に基づいて豊富にまとめられています。
こうすることで、システムが完成してから、そのシステムの大問題が発覚してしまうような事態を避けつつ、
良いシステムとして動き続けるようにします。
モニタリングの方法など、新しい業務（ビジネス）を考える時に、チェックするポイントが体系化されています。
「PMIビジネスアナリシスガイド ビジネスアナリシス標準を含む」 Project Management Institute 著 PMI日本支部 2019
ステークホルダーなども把握しながら、現状を把握してから、未来の姿を描き、
そのうえで要件定義をします。
計画やソリューションの妥当性の確認もあります。
NeedsとRequirementsは分けて書かれています。
段階を踏んで行くのですが、それぞれの段階に、インプットとアウトプットとして何を作っていくのかが示されています。
「実務者のためのビジネスアナリシス 実務ガイド」 Project Management Institute 著 PMI日本支部 2016
PMIの上記の本と内容は似ています。要求事項を出すための話は、ボリュームがあります。
こちらは実務向きの話が多く、例えば、ステークホルダーの話は力説されていない一方で、要件定義はドキュメントとして残すことが書かれています。
「ビジネスアナリシス知識体系ガイド」
Wikipediaによる解説です。
https://ja.wikipedia.org/wiki/ビジネスアナリシス知識体系ガイド
ビジネスアナリシス知識体系ガイドは、ビジネスへの要求をまとめるものと、ソリューションが要求に対して妥当なものかを評価する方法として説明されています。
そのため、「BABOKは、システム開発だけのものではない。」、「BABOKは、システム開発の上流工程だけのものではない」とは言えます。
「BABOK超入門」 広川智理 著 日経BP社 2011
ITシステムの構築がうまくいかない原因を、システムへの要求や、プロジェクト開始時の状態が不十分であると考えて、
それを十分にする方法論として、BABOKを参照しています。
「要求工学知識体系(REBOK)概説」
https://www.ipa.go.jp/files/000005375.pdf
BABOK、REBOK、SWEBOKの違いがあります。
BABOKはビジネス要求、REBOKはシステム要求、SWEBOKはソフトウェア要求が対象としています。
いわゆるビジネス分析では、現行ビジネスと新ビジネスの比較はしますが、現行システムと新システムの比較はREBOKが行うという考え方をしているようです。
「REBOK（DX編）」
https://www.jisa.or.jp/LinkClick.aspx?fileticket=XRL0u7FP5xk%3d&tabid=3167
DXを念頭においたREBOKとしては、10種類のパターンを想定しています。
「システム思考がモノ・コトづくりを変える デジタルトランスフォーメーションを成功に導く思考法」 稗方和夫・高橋裕 著 日経BP 2019
システム思考
を使いながら、顧客からの要求事項を明確にすること、その実現手段は自由に発想することについて、かなりの紙数を使って解説しています。
SVN（ステークホルダー・バリュー・ネットワーク）という図を使って、ステークホルダーの間での価値の流れを図で表します。
要件定義の後に、設計が始まります。 ここにまとめている本は、設計の最初の方の内容でもあり、要件定義の最後の方でもあるような内容になっています。
「はじめよう!システム設計 要件定義のその後に」 羽生章洋 著 技術評論社 2018
プログラマがソフトウェアを完成させるために必要な情報は、UI、機能、データであり、それを要件としてまとめるのが要件定義。
システム設計はフロント層、バック層、DB層に分かれる。
フロント層の設計は、UIや機能の設計で、UI設計は要件定義の一部。
「ITアーキテクトの教科書 システム設計の先導者」 石田裕三 著 日経BP社 2018
ITアーキテクトとは、システム開発の全体を見る役割の人です。
プロジェクトマネージャーと、プログラマーの間のいる立場になっています。
開発の各段階の整合性だけでなく、改修の手順や、人の書いたコードを他の人がチェックしやすくする、等、必要ならば、細かな取り組みも進めます。
「システム開発・刷新のためのデータモデル大全」 渡辺幸三 著 日本実業出版社 2020
ある程度複雑なデータを扱う時の必須の知識として、データモデリングを紹介しています。
データを扱う技術としてプログラミングが重視されることがありますが、著者は時代によって内容が変わるプログラミング技術よりも、
登場したころからほとんど変わっていないデータモデリング技術の方を、
データリテラシー
として重視しています。
アジャイル開発では、部分的に良いものができるが、建て増しを繰り返して作られたビルのようになってしまい、全体的に良いものにならない。
データモデリングは、リレーショナルデータベース（RDB）と相性が良いが、RDB以外でもデータ構造に矛盾を生まない技術。
主キーの設定が、複雑なデータ構造を扱うために重要としています。
オブジェクト指向では、データをプログラムの従属物と考えるので、RDBと相性が悪い。
オブジェクト指向では、データの保管や形式に対して特段の指針がないことは、業務システムでは困る。
オブジェクト指向で扱うデータに対して、RDBのような保管や形式を持たせることが必要。
業者の選定は、３時間程度のオーディションが良い。
A4で1ページくらいのシステム要件を見せて、その場で実装してもらう。
今どきのツールを使えば、そのくらいの時間である程度のものは作ることができる。
このやり方に対して、「設計するための情報が足りない」、「持ち帰って検討したい」と考える業者は、実力がない可能性が高い。
この本は、前半がデータモデルの全般的な話です。
後半は、減価償却や在庫など、実際の業務の用語と、それを扱うシステムのあり方の各論になっています。
「データマネジメント知識体系ガイド 第二版」 DAMA International 著 日経BP社 2018
データマネジメント
のガイドです。
第4章がデータアーキテクチャなのですが、データアーキテクチャ（システムの構成）の記述には、データモデルとデータフローの２つが必要としていて、
かつ、それらの仕様は、お互いに適合していなければならないとしています。
順路
次は
時系列解析
