〔論説〕

ソフトウェアの要求引き出しにおける
ステークホルダーの特定

名児耶富美子

1.

1.

序論

2.

基本概念の比較3.

ステークホルダーの特定技術

4.

関連研究

5.

結論

序論
ステークホルダーは、経営戦略、企業統治、企業の社会的責任などの幅広い分野で利害関係者を意味する言葉として使用されている。ステークホルダーの概念が Edward Freeman によって整理されたのは1984年のことである。Edward
Freeman は、ステークホルダーとは企業の目標の達成するために影響を与えう
る、または影響を受けるグループまたは個人を指し、具体的には、従業員、顧客、供給業者、株主、銀行、環境保護論者、政府、その他の企業に対して利益を与えるか、もしくは害をもたらすグループが含まれる [Freeman2010] と定義している。ソフトウェア開発においてステークホルダーの特定は、ソフトウェア開発を行う技術者は誰と仕事をするのかを意味し、いかなるシステムも、正確、

─245─

かつ、完全にすべての可能性のあるステークホルダーをタイプ別に特定し、それらの利益と責任を管理することは非常に重要である [Laplante&Kassab2022]。
ソフトウェア開発にかかわる研究者や技術者は、ステークホルダーは誰なのか、どの範囲まで含めるべきかについて、再考すべき時に来ているようだ。
Ingo Müller ら [Müller et al., 2022] は、アメリカのデトロイト警察が採用した顔認識システムが人種的な多様性に欠如した画像データを機械学習に使用したことにより無実の男性が逮捕された事件を挙げ、特定のソフトウェアのユーザー
ではない人々、または、そのソフトウェアの存在すら知らないにもかかわらず操作により影響をうける可能性がある人々を間接的なステークホルダーと呼び、間接的なステークホルダーを見落とすことでソフトウェアが深刻な事態を引き起こすと我々に警告する。ソフトウェアの専門家が使っている国際標準や知識体系がソフトウェアの要求開発の段階で間接的なステークホルダーを特定する具体的なガイダンスを提供していないこと、ならびに、ステークホルダーの要求を満たすために企業が実施する仕事のやり方が社会的および社会的影響への配慮に欠けていることを間接的なステークホルダーを見落す原因として挙げている。
前者の「国際標準や知識体系が間接的なステークホルダーを特定するガイダ
ンスを提供していない」という指摘については、機械学習で使用する訓練デー
タまでをステークホルダーに含むとする規定が存在しない可能性が考えられる。ソフトウェア開発を行う技術者は、システムやソフトウェア開発における技術的な問題を解決する際に彼らの判断を支える根拠、または、専門家同士のコミュニケーションに齟齬がないようにする用語の定義として国際標準 ISO/
IEC/IEEE24765 (Systems and software engineering – Vocabulary) [IEEE2017]、 知
識 体 系 ガ イ ド SWEBOK(Guide to the Software Engineering Body of Knowledge)[SWEBOK2014] な ど を 利 用 す る。 国 際 標 準 ISO/IEC/IEEE24765 [IEEE2017]は、システムとソフトウェア工学に関する共通の語彙の提供を意図している｡SWEBOK [SWEBOK2014] は、IEEE Computer Society が後援して編集されたソ

─246─

ソフトウェアの要求引き出しにおけるステークホルダーの特定

フトウェア知識体系ガイドである ｡ 筆者は、ソフトウェアの要求開発における基本概念を対象に、国際標準 [IEEE2017]、知識体系 [SWEBOK2014]、関連研
究 [Wiegers2013] を用いた比較と分析を実施している [名児耶2022]。その研究において、ソフトウェアの要求開発、つまり、引き出し、分析、仕様作成、妥
当性確認の際に使用する基本概念を比較したところ、要求、フィーチャー、制約条件では抽象度が高い記述が求められていること、並びに、システム要求に関わる人的な対象をシステムの顧客またはエンドユーザーに限定せず ､ ステー
クホルダーを含み ､ さらに個人が識別可能な情報源以外の幅広い人的情報源にまで及んでいると判明した。残念ながら、ステークホルダー、顧客、エンドユー
ザーに関する詳細な分析は、その時点で実施できていなかった。
Ingo Müller らが言及した後者の「ステークホルダーの要求を満たすために企業が実施する仕事のやり方が社会的および社会的影響への配慮に欠けている」という指摘については、ソフトウェア開発を行う対象の周辺環境の変化が影響していると考える。アジャイルソフトウェア開発宣言 [AgileManifesto2001] で素早く変化に対応することを理念として掲げているアジャイル型開発の現場であっても、ソフトウェアの要求開発時に顧客が意図した用途を完成した成果物であるソフトウェアが満たしていない事態が残念ながら発生する。顧客の意図していないソフトウェアが最終成果物として顧客に提供される理由の１つは、ソフトウェアの要求開発の段階で Pamela Zave [Zave1997] と Michael Jackson[Jackson2000] が指摘した「システムが動作する世界 (W) とマシン (M) を混合」が発生していることがある。
ステークホルダーの要求は、どのような機能やサービスが提供されるかというシステムの振る舞いに関するものが主であるが、プロジェクトで設計する必要があるのはシステムが動作する世界 (W) の振る舞
いではなく、プログラミングによって作られるマシン (M) の振る舞いである。
ソフトウェア開発を行う技術者は、ステークホルダーの期待や関心を正確に把握し、プログラムが提供する振る舞いについてステークホルダーと認識の違いが発生しないように努める必要がある。

─247─

そこで、本稿は、ステークホルダーの特定について、概念の定義、実務で広く使われている技術、最新のレビュー研究で判明している内容に焦点を当て、検討を行うことにする。最初に、国際標準や知識体系がソフトウェアの要求開発で人的な基本概念である、ステークホルダー、ユーザー、顧客をどのように定義しているかを比較する。次に、システム開発の現場で広く実務家に使われているステークホルダーを特定する技術について言及する。
その上で、
ソフトウェ
ア開発のステークホルダーの特定に関する研究をレビューするために学術論文
データベースからキーワードをもとに対象を抽出し分類する最新の研究に着目し、それらの分析手法とステークホルダーを特定する要素や手順から、ステー
クホルダーの特定について考察を行う。

2.

基本概念の比較
前述したように、著者は国際標準 [IEEE2017]、知識体系 [SWEBOK2014]、

関連研究 [Wiegers2013] を使って、要求 ､ フィーチャー ､ 制約条件、ユーザー
ストーリー ､ ユースケース ､ シナリオ、システム要求 ､ 機能要求 ､ 非機能要求の分析と比較を既に行っているため、本研究では、対象システムの要求と環境から仕様書で定義すべき人的な要素として誰を抽出すべきなのかを考察する
ことから始めたい。使用する国際標準 [IEEE2017]、知識体系 [SWEBOK2014]、
関連研究 [Wiegers2013] に関しては、原文からの翻訳は著者が直接行い、比較対象に一致する用語がない場合には、著者がもっとも近い表現であると考える
用語を選んでいる。

2.1

ステークホルダー• ステークホルダー[IEEE2017]①システムに対して、またはシステムが有するニーズや期待に見合う特性に対して、権利、共有、要求、または関心を持つ個人や組織。②プロジェクト

─248─

ソフトウェアの要求引き出しにおけるステークホルダーの特定の決定、活動、または成果物に影響を与えうる、影響を受ける、あるいは影響を受けることを認めている一個人、グループ、または組織。③システムに関心を持つ個人、チーム、組織、または、それらに関するクラス。リスクに影響を与える、影響を受ける、あるいは影響を受けることを認めている個人、グループ、または組織。
• ステークホルダー [SWEBOK2014]
ステークホルダーはプロジェクトによって変わるが、ユーザー / オペレー
ターと顧客 ( 同じである必要はないが ) は常に含まれる。ソフトウェアのス
テークホルダーの典型例は、次のとおりである ( ただし、これらに限定はされない )：ユーザー、顧客、規制当局、ソフトウェアエンジニアら。
• ステークホルダー [Wiegers2014]
プロジェクトに積極的に関わっている、プロジェクトのプロセスや成果物の影響を受ける、あるいは、それらに影響を及ぼす可能性がある個人、グルー
プや組織。
コメント：[IEEE2017] のステークホルダーの定義は、「影響を与えうる、影響を受ける、あるいは影響を受けることを認めている」となっていることから極めて広い範囲が想定されていることが分かる。しかしながら、このような肥大化した定義は必要ないとの批判 [Meyer et al.,2019] も存在する。[IEEE2017]と [Wiegers2014] におけるステークホルダーの定義は抽象的である。一方、[SWEBOK2014] ではステークホルダーの典型例はこれらに限定されないと言いつつも、具体的に、ユーザー、顧客、規制当局、ソフトウェアエンジニアを挙げている。なお、[SWEBOK2014] の原文ではステークホルダーは複数形になっている。

2.2

ユーザー• ユーザー [IEEE2017]①システムと相互作用する、またはシステムの使用中にシステムから利益を

─249─

受ける個人やグループ。②システム、製品、またはサービスと相互作用する人。③ソフトウェアと対話、または相互作用するあらゆる人や物。④システ
ムの使用中に、システムから利益を受ける個人やグループ。⑤ソフトウェア
を使って1つ以上のタスクを実行する人、特定の聴衆のメンバー。⑥ターミ
ナル経由 ( または同等のユーザーインターフェイス ) で、タスクを送信して計算された結果を受け取ることによりコンピュータベースのソフトウェアシ
ステムの機能を使う人 ( またはインスタンス )。⑦ CASE ( コンピュータ支
援ソフトウェア工学 ) ツールとの相互作用を通じてエンジニアリングの価値を引き出す人。⑧特定の機能を実行するためにシステムやソフトウェアを使う個人や組織。⑨ソフトウェア製品の使用中に、その製品からすぐに利益を受ける個人やグループ。
• ユーザー [SWEBOK2014]
ユーザーのグループは、ソフトウェアを操作する者によって構成される。異なる役割と要求を持つ人々を含む混成のグループであることが多い。
• ユーザー [Wiegers2014]
直接または間接 ( システムからの出力を使うが、その出力を自ら生成はしない ) でシステムと相互作用すると思われる顧客。エンドユーザーと呼ぶこともある。
コメント：[IEEE2017] と [Wiegers2014] におけるユーザーの定義には「相互作用する」という言葉が含まれている。 [SWEBOK2014] では混成のグループとしていることから、ユーザー同士、またはユーザーと関連を持つ対象との関係性をさらに分析することが必要と考える。[SWEBOK2014] の原文ではユーザー
は複数形になっている。

2.3

顧客

• 顧客 [IEEE2017]①製品やサービスを受け取る組織、または人。②プロジェクトの製品、サー─250─

ソフトウェアの要求引き出しにおけるステークホルダーの特定

ビス、あるいは結果を利用する人、または組織。③アプリケーション管理組
織の1つまたは複数のサービス、あるいは製品を受け取る組織または組織の一部、または人。④製品やサービスを受け取ることができたであろう、または受け取る人や組織で、製品やサービスが対象としている、あるいはこれを要求した人や組織。
• 顧客 [SWEBOK2014]
顧客のグループは、ソフトウェアを委託した者、またはソフトウェアがターゲットにしている市場を代表する者によって構成される。
• 顧客 [Wiegers2014]
製品から直接または間接に利益を得る個人、あるいは組織。ソフトウェアの顧客は、ソフトウェア製品が生成する出力を要求し、代金を支払い、選択し、指定し、利用し、または受け取る。
コメント：[IEEE2017] と [Wiegers2014] における顧客の定義には「受け取る」という言葉が入っている。つまり、製品やサービスから便益を得る対象を指しているが、両者の違いは [Wiegers2014] は間接的に利益を得る個人や組織を明示していることである。[SWEBOK2014] の原文では顧客は複数形になっているためにグループという表現になっている。

2.4

考察

ステークホルダー、ユーザー、顧客に関する国際標準 [IEEE2017]、知識体系 [SWEBOK2014]、関連研究 [Wiegers2013] における定義の比較を行ったが、ステークホルダーを識別するためのテクニックや手法についての記述はない。
そこで、ソフトウェアの要求引き出し時においてステークホルダーの特定するために実務家が用いている技術について BABOK ガイドを使って考察を行う。

─251─

3. ステークホルダーの特定技術
ここでは、ビジネスアナリシスに関する知識体系である BABOK ガイド (AGuide to the Business Analysis Body of Knowledge version 3.0) [BABOK2015] と、
BABOK ガイドを日本語に翻訳した [BABOK2015J] を参考にして、ステークホ
ルダーを特定するために開発現場で実務家が用いている実践的な技術に注目する。BABOK ガイドは、2003年に設立された国際的に活動する非営利団体 IIBA
(International Institute of Business Analysis) が発行するグローバルなビジネスア
ナリシス・コミュニティの知見を集めた技術と知識体系である。

3.1

ビジネスアナリシスの本質

BABOK ガイドは、ビジネスアナリシスを「ニーズを定義し、ステークホル
ダーに価値を提供するソリューションを推奨することにより、エンタープライズにおけるチェンジを引き起こすことを可能にする専門活動」と定義している[BABOK2015J]。この定義に使われている概念：チェンジ、
ニーズ、
ソリューショ
ン、ステークホルダー、価値、コンテキストをビジネスアナリシスに関する６
つのコア・コンセプトと明記している。つまり、ビジネスアナリシスとは、組織をとりまく状況において問題やビジネスの機会を定義し、ステークホルダーに価値を提供する具体的な方法を推奨することによって、変革を可能にするための活動と言い換えることができる。
ビジネスアナリシスを実行するための個別の作業をタスクと呼び、それぞれのタスクは、目的、概説、インプット、要素、ガイドラインとツール、テクニッ
ク、ステークホルダー、アウトプットが記述されている。ただし、タスクを実行するプロセスや順番については規定していないと BABOK ガイドは述べている。要するに、BABOK ガイドの本質はタスクという要素で構成された集合であり、タスクの属性としてのステークホルダー、テクニックやツールは記述されているが、ステークホルダー自体を特定する手順は含まれていないと考える。

─252─

ソフトウェアの要求引き出しにおけるステークホルダーの特定BABOK ガ イ ド は 、 前 述 し た よ う に 、 最 初 に ビ ジ ネ ス ア ナ リ シ ス の ６ つ の・コンセプトを定義している。その１つにステークホルダーがある。
3.2コ アステークホルダーの定義と役割
ステークホルダーとは、「 ビ ジ ネ ス ア ナ リ ス ト (タ ス ク を 実 施 す る 人 )が 直 接BABOKガイドは、前述したように、最初にビジネスアナリシスの６つのコア
・
または間接に関係する可能性が高い個人またはグループである」と規定しコンセプトを定義している。その１つにステークホルダーがある。ステークホている。
ルダーとは、「ビジネスアナリスト ( タスクを実施する人 ) が直接または間接
次 に 、コ ア ・ コ ン セ プ ト ご と に 解 説 が あ り 、ス テ ー ク ホ ル ダ ー の 項 目 に おに関係する可能性が高い個人またはグループである」と規定している。
いて、すべて の ス テ ー ク ホ ル ダ ー を 網 羅 すステークホルダーの項目において、ることは意図していないとしつ
次に、
コア
・コンセプトごとに解説があり、
つも、一般的なステークホルダーの役割をあげて、それぞれの役割の持つすべてのステークホルダーを網羅することは意図していないとしつつも、一般
責 任 に つ い て 言 及 し て い る 。 図 １ は BABOK ガ イ ド が 一 般 的 な ス テ ー ク ホ
的なステークホルダーの役割をあげて、それぞれの役割の持つ責任について言ルダーの役割として例に掲げた個人またはグループを著者がオニオン図に及している。図１はBABOK
ガイドが一般的なステークホルダーの役割として表したものである。
例に掲げた個人またはグループを著者がオニオン図に表したものである。

図１：ステークホルダーの役割に関するオニオン図

図１：ステークホルダーの役割に関するオニオン図

最 後 に 、B A B O Kガイドの構成要素である個々のタスクの中で、ステークホ
ガ イ ド の 構 成 要 素 で あ る 個 々 の タ ス ク の 中 で 、ス テ ー ク
最後に、BABOK
ホルダー・リストを提示し、ステークホルダーの役割ごとに説明を加えてルダー・リストを提示し、ステークホルダーの役割ごとに説明を加えている。
いる。たとえば、ステークホルダー分析を実施するという要素を持つ「スたとえば、ステークホルダー分析を実施するという要素を持つ「ステークホル
テークホルダー・エンゲージメントを計画する」タスクにおいて、ステー
ダー・エンゲージメントを計画する」タスクにおいて、ステークホルダー・リ

ストに「プロジェクト・マネジャー」、「エンドユーザー」、「業務領域の専門家」
、

─253─

「スポンサー」、「顧客」、「サプライヤー」、「規制者」を列挙し、それぞれのステー
クホルダーの役割を簡潔に説明している。

3.3

ステークホルダーの特定技術

BABOK ガイドは、個々のタスクにおいて、タスクの目的、概説、インプット、要素、ガイドラインとツール、
ステークホルダー、
アウトプットとともに、ステー
クホルダーは誰かを特定するテクニックを記述している。
先ほど例に挙げた「ス
テークホルダー・エンゲージメントを計画する」タスクは、「ステークホルダー分析を実施」、「ステークホルダーとのコラボレーションを定義」、「ステークホルダーのコミュニケーションのニーズ（考慮事項の評価）」の3つの要素で構成されている。これらの要素を実践するためのテクニックとして、ステークホル
ダー・リスト、マップ、ペルソナをはじめとして、11の手法が提案されている。
ステークホルダー・リスト、マップ、ペルソナの具体的な内容は、BABOK
ガイドの後半部分で、コミュニティで最もよく知られ、広く活用されているビ
ジネスアナリシスのためのテクニックとして50に及ぶ手法の内容の中で詳しく紹介されている。たとえば、ステークホルダー・リスト、マップ、ペルソナの
うち、マップ ( ステークホルダー・マップ ) は、ステークホルダー・マトリク
スやオニオン図の2つの代表的な図を描画し、内容を説明している。ただし、タスクを実施する者は自分の経験と考察に基づいて状況に応じてテクニックを選択し活用するとしているため、ステークホルダーを特定するためのテクニッ
クの組み合わせやステークホルダーの特定するための手順についての言及はない。そこで、定量的な視点から文献レビューを行っている研究を用いて、ステー
クホルダーを特定する要素や手順に注目して内容の検討を行う。

─254─

ソフトウェアの要求引き出しにおけるステークホルダーの特定

4.

関連研究
ソフトウェアの要求引き出し時におけるステークホルダーの特定に関して、学術論文のデータベースからキーワードで抽出して該当すると思われる研究を収集し、かつ、タイトルや要約から判断して研究上の問い ( リサーチクエスチョン ) に沿って内容を分類するデータ駆動型アプローチをとっている３つの研究を対象に、それらの研究手法とともに研究結果について観察する。
[Pacheco&Garcia2012] は、系統的文献レビュー（Systematic Literature Review[Kitchenham2004]）の手法を使って1984年から2011年に発表されたソフトウェ
アの要求引き出しにおけるステークホルダーの特定に関する研究を ACM
Digital Library, IEEE Xplore, Springer Verlag などのデータベースを使い980本以上の研究論文を抽出し、タイトルや要約から判断して彼らのリサーチクエス
チョンに関連すると予想される245本の論文を実際に読んで、その中から47 本の研究を選択している。選択した研究論文を分析し、ステークホルダーの分類、
プロジェクトにおける利益の優先順位、スキルや望ましい属性、ステークホル
ダー間の関係性分析、特定方法の実践、問題点をリサーチクエスチョンの観点から報告している。
[Zhao&Zhao2018] は、過去に発表されたソフトウェアの要求引き出しにおけるステークホルダーの特定に関する研究論文を対象にして、Systematic
Mapping Studies [Petersen et al.,2008] という手法を使って抽出・分類した後に、リサーチクエスチョンに沿った分析を行っている。702本の研究論文を Scopus
をはじめとする7種類のデータベースからキーワードを使って抽出し、最終的に26本の論文に絞り込みを行っている。26の研究におけるステークホルダーの特定に関する技術について概要を記載した上で、役割、知識、影響などの観点から分類して、ソフトウェア開発のための体系的なステークホルダー選択
モデルを確立するための影響要因を提示している。影響要因として、(1) プロ
ジェクトの範囲を決定し、プロジェクトのすべてのステークホルダーを特定す─255─

る、(2) ステークホルダーの役割、知識、プロジェクトへの影響を指定する、(3) ステークホルダー間の関係を分析する、(4) ステークホルダーのタイプを指定する、(5) プロジェクトに対するステークホルダーの影響と関心を分析す
る、(6) ステークホルダーのスキルを分析するといった６つの手順を明示している。
[Lewellen2020] は、アプリケーションソフトウェア、データベースソフト
ウェア、その他の関連する複数のソフトウェアシステムを考慮した環境として定義されるソフトウェアエコシステムに焦点を当て、ステークホルダーの特定に関する研究を行っている。系統的文献レビューの手法を用いて288本の研究論文を抽出し、そこから73本を選択し、そのうち28本の研究を取り上げ、２つのリサーチクエスチョンに基づいた分析を実施している。第一のリサーチクエ
スチョンはステークホルダーの特定プロセスに関する質問で、15本の論文がス
テークホルダーの特定にかかわるプロセス、方法、フレームワークに関して言及しているとして、それらを使ってステークホルダーの特定する方法を導出している。第2のリサーチクエスチョンはステークホルダーの属性に関する質問で、20本の論文がステークホルダーの属性について言及しているとし、それらの属性について特徴を抽出して4つの次元（タイプ、役割、関係、価値）でグループ化し、階層的な構造を持つタクソノミーとして属性の関係性を明示している。

5.

結論
本稿では、ステークホルダーの特定について、最初に、国際標準 [IEEE2017]、

知識体系 [SWEBOK2014]、関連研究 [Wiegers2013] におけるステークホルダー、
ユーザー、顧客といった基本概念の定義を比較した。国際標準 [IEEE2017] は、
プロジェクトの決定、活動、または成果物に影響を与えうる、影響を受ける、
あるいは影響を受けることを認めている個人、グループ、または組織をステー
クホルダーに含めるとしており、極めて広い範囲でステークホルダーを規定し─256─

ソフトウェアの要求引き出しにおけるステークホルダーの特定ている。しかしながら、ステークホルダーを識別するためのテクニックや手法についての記述はないことが分かった。次に、広く実務家に用いられている
BABOK ガイドで、ステークホルダーの定義と役割、ステークホルダー特定のテクニックについて観察を行った。ビジネスアナリシスを実行するための個別の作業 ( タスク ) で、ステークホルダー・リストやテクニックの詳細は明記されていたが、ステークホルダーは誰かを特定する技術を用いる際の手順や組み合わせについてはビジネスアナリシスを実施する人々の裁量に任されていると推察された。最後に、ソフトウェアの要求引き出しにおけるステークホルダーの特定に関する３つのレビュー研究を検討した結果、これらの研究ではステー
クホルダーを特定する手順の導出や、ステークホルダーの特定に影響を与える
要因、ステークホルダーの属性分析を試みていることが分かった。
今後は、ステークホルダーは誰かを特定する技術について、社会科学の分野でどのような手法が用いられているかを検討するとともに、データ解釈のゆがみに配慮したデータ駆動型のレビュー研究を実践することを予定している。これ
らの研究を通じて、急激に変化する周辺環境の下でステークホルダーをどのように特定するかを明確にすることにより、ソフトウェアの開発を行っている技
術者に少しでも貢献したいと考える。

参考文献[AgileManifesto2001] アジャイルソフトウェア開発宣言 .
https://agilemanifesto.org/iso/ja/manifesto.html[BABOK2015] IIBA: A Guide to the Business Analysis Body of Knowledge. Lightning Source Inc,
2015.
[BABOK2015J] IIBA 日本支部 BABOKv3翻訳プロジェクト :『ビジネスアナリシス知識体系ガ
イド (BABOK® ガイド）Version 3.0（pdf 版 )』、IIBA® 日本支部、2015.
[Freeman2010] R Edward Freeman, Strategic management: a Stakeholder Approach. Cambridge
University Press, 2010.
[IEEE2017] ISO/IEC/IEEE 24765:2017: Systems and software engineering – Vocabulary. https://─257─

ieeexplore.ieee.org/document/8016712, 2017.
[Jackson2000] Michael Jackson: Problem frames: analyzing and structuring software development
problems. Addison-Wesley Longman Publishing Co., Inc., 2000.
[Kitchenham2004] Barbara Kitchenham: Procedures for Performing Systematic Reviews. Keele, UK,
Keele University, vol 33, 2004.
[Laplante&Kassab2022] Phillip A. Laplante, Mohamad H. Kassab: Requirements Engineering for
Software and Systems. Auerbach Publications; 第4版 , 2022.
[Lewellen2020] Stephanie Lewellen: Identifying Key Stakeholders as Part of Requirements Elicitation
in Software Ecosystems. In Proceedings of the 24th ACM International Systems and Software
Product Line Conference - Volume B (SPLC '20). Association for Computing Machinery, New
York, NY, USA, 88–95, 2020.
[Meyer et al.,2019] Bertrand Meyer, Jean-Michel Bruel, Sophie Ebersold, Florian Galinier, andAlexandr Naumchev: Towards an Anatomy of Software Requirements. In Software Technology:
Methods and Tools: 51st International Conference, TOOLS 2019, Innopolis, Russia, October 15–17,
2019, Proceedings. Springer-Verlag, Berlin, Heidelberg, 10–40. 2019.
[Müller et al.,2022] Ingo Müller, Bran Selic,and Philippe Kruchten: Stakeholders: Going Beyond Just
“End Users”IEEE Softw. 39, 1 (Jan.-Feb. 2022), 112–113. 2022.
[名児耶2022] 名児耶富美子 :「ソフトウェアの要求開発における基本概念の考察」、経営総合
科学 ( 経営総合科学研究所紀要 ) 116号 pp89-108、2022年2月 .
[Pacheco&Garcia2012] Carla Pacheco and Ivan Garcia: A systematic literature review of stakeholder
identiﬁcation methods in requirements elicitation. J. Syst. Softw. 85, 9, 2171–2181, 2012.
[Petersen2008] Kai Petersen, Robert Feldt, Shahid Mujtaba, and Michael Mattsson: Systematic
mapping studies in software engineering. In Proceedings of the 12th international conference on
Evaluation and Assessment in Software Engineering (EASE'08). BCS Learning & Development
Ltd., Swindon, GBR, 68–77, 2008.
[SWEBOK2014] P. Bourque and R.E. Fairley, eds.: Guide to the Software Engineering Body ofKnowledge, Version 3.0. IEEE Computer Society, www.swebok.org, 2014.
[Wiegers2013] Karl E Wiegers and Joy Beatty: Software Requirements 3. Microsoft Press, 2013.
[Zave1997] Pamela Zave, Michael Jackson: Four dark corners of requirements engineering. ACM
Transactions on Software Engineering and Methodology, Volume 6, pp. 1-30, 1997.
[Zhao&Zhao2018] Junwen Zhao and Yuemin Zhao: A Systematic Stakeholder Selection Model in
Requirements Elicitation for Software Projects: A Systematic Mapping Study. Master's thesis.
Blekinge Institute of Technology, Karlskrona, Sweden, 2018.

─258─