研究コース６（GOØWY チーム）
研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）

要求獲得のためのヒアリングにおけるゴール指向要求分析の活用～「ゴール指向 Lite」の提案～

Effective Use of Goal-Oriented Requirements Analysis Method
at Interview Process for Requirements Elicitation- Proposal of “Goal-Orientation Lite” 菅原
室井
山口
山崎

扶 （株式会社インテック）
義彦（ＤＩＣ株式会社）俊彦（テックスエンジソリューションズ株式会社）哲 （テックスエンジソリューションズ株式会社）

研究概要
我々は，ソフトウェアシステム開発プロジェクトにおける要求定義での課題解決のために，新たな方策「ゴール指向 Lite」を提言することにした．従来からある要求獲得手法の「ゴール指向要求分析」の本質を損なうことなく，しかもそれよりも迅速かつ簡易に実施できる方策として「ゴール指向 Lite」を創出した．
実験 として仮 想の業務シ ステム開 発プロジェ クトにお ける要求定 義での「 ゴール指向
Lite」適用有無を比較検証したところその適用優位性が確認できた．
Abstract
We propose a new method "Goal-Orientation Lite" to prevent from making failures at therequirements analysis phase of software system development project. Given effectiveness ofGoal-Oriented Requirements Analysis (GORA) methods, we propose "Goal-Orientation Lite" as aspeedy and simple method that still retains the essence of GORA.
We show effectiveness of the proposed method through an experiment that compares
requirement analysis with and without it.
1.

はじめに
ソフトウェアシステム開発プロジェクト（以下，プロジェクト）の要求定義において，要求の抜け漏れ，要求の内容が明確でない，ステークホルダ間での認識誤りが発生するといった課題があり，我々の実経験に基づく議論でも同様課題があると認識できた．
要求工学知識体系 REBOK（Requirements Engineering Body Of Knowledge）によれば，共通知識カテゴリにおける 8 つの知識領域のうち，要求定義に直接必要な知識領域は要求獲
得，要求分析，要求仕様化，要求の検証・妥当性確認・評価の 4 つのプロセスである[1]．
我々は，このうち要求獲得プロセスに着目した．なぜならば要求獲得とは「顧客を含む
ステークホルダを明らかにし，会議やインタビューなどを通して要求を引き出す技術に関する知識」と定義されており，前述の課題解決に効果があると考えたためである．
本研究では，要求の構造化と分析の手法として注目される「ゴール指向要求分析」[2]を要求獲得において活用することに着目し，要求定義における有効性について研究を行う．
以下本論文の構成を述べる．2 章でゴール指向要求分析の特徴とその課題を示す．3 章
では我々の提案する手法の詳細について説明する．4 章ではその手法の有効性検証のために実施した実験詳細を示し，5 章で実験結果について考察する．6 章では，まとめとして本研究の考察と今後の課題について述べる．
1
－157－
－1－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
2. ゴール指向要求分析における課題
2.1 ゴール指向要求分析
ゴール指向要求分析では，ゴールとはシステムが満足すべき状態であると定義されている．また，システム要求とはゴールを達成するための手段であると定義されている．プロ
ジェクトにおいて達成すべきゴールにこそ最も着目すべきであり，ゴールを分解・詳細化（サブゴール化）して達成手段を明確に定義したものをシステム要求と見なすということである（システム要求化）．これにより，システム要求に関する「何のためにそれが必要なのか」が明確になり，要求分析における議論や妥当性確認，要求変更時の追跡がそれぞれ行いやすくなる．ゴール指向要求分析でのサブゴール化やシステム要求化の概念図が図 1である．
■ゴール：システムが満足すべき状態■サブゴール：ゴールの分解・詳細化

ゴー ル■システム要求：ゴールを達成するための手段

サブ ゴール 1-1

サブゴール 1-2…

…

サブ ゴール m-1

サブゴール m-2

シス テム要求 1

システム要求 2．．．

サブゴール 1-n…

．．．

サブゴール m-n

システム要求 3．．．

システム要求 n

図 1．ゴール指向要求分析の概念図

ゴール指向要求分析のいくつかあるフレームワ
ークに共通する，ツリー構造によるゴール間の関係モデルの例を図 2 に示す．
モデリングでは，上位
ゴールを下位ゴールに
AND/OR 関 係 を 用 い て 分
解していく．上位ゴールになればなるほど抽象性が高くなり，ゴール分解の終了基準は，すべての下位ゴールに対してその達成手段，すなわちシス
テム要求が特定されることである．

アンケートに回答する
AND 詳細化

アンケート回答

アンケート回答

を作成する

を提出する
OR 詳細化アンケートを FAX

アンケートを電子で提出する

メールで提出する

FAX 送信ボタン

メール送信ボタン

達成手段
システム要求図 2．ゴール間の関係モデル例
2
－158－
－2－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
ゴール指向要求分析の要求定義への適用，すなわちツリー構造によるゴール間の関係モ
デリング手法実施で，すべてのゴールに対するすべての達成手段（システム要求）を特定でき，それらを明示的に可視化することができるため，以下の効果が得られる．
(1) 要求獲得における抜け漏れの防止(2) 要求の必要理由の明確化(3) 要求獲得における矛盾や誤りの排除(4) 要求の重要度・優先度の把握(5) 要求獲得のためのヒアリング時における暗黙知に対する気付き(6) ヒアリング者と被ヒアリング者間（ステークホルダ間）での認識共有の促進
2.2 課題
まず我々は，ゴール指向要求分析を実際に試行実施してみた．具体的には，仮想小規模
プロジェクトを設定し，ゴール指向要求分析におけるツリー構造によるゴール間の関係モ
デリング作成を行い，要求分析を試行した．結果，ゴール指向要求分析の実施には，以下
表 1 の課題があると認識した．表１の課題は，いずれも実際のプロジェクトにおいてゴー
ル指向要求分析を活用することは容易でない，ということに起因しており，かつ我々の共通認識の課題であった．
表 1．ゴール指向要求分析における課題
No

課題 点

課題内容

理由

1

時間 制約

分析実施や手法の習熟に時間が・基本的にシステム全体のゴールモデルを書くこかかるとが前提となっており，ツリー内の記述に曖昧さを残せず，明示的に記述せざるを得ないため
・各手法の記述ルールの理解に時間がかかるため

2
3

属人 性

分析結果が個人の経験や知識量

・あくまでツリー構造による記述の枠を提供するに依存してしまうだけであり，記述の自由度が高いため本来目的のツリーを完成させることに意識・見た目の記述の枠に目が 行きがちで，かつわか

喪失が働き，本質的な要求分析というりやすい終了基準である記述の完成に目が向い

本来目的を見失いがちとなるてしまうため3.
ゴール指向 Lite
3.1 アプローチ
要求定義におけるゴール指向要求分析手法の有用性は認知しつつも，それを実際のプロジェクトで活用するには，2.2 章の表 1 の課題に対する対策が必須である．そこで我々は，
表 1 の課題を解消でき，2.1 章で挙げたゴール指向要求分析の 6 つの期待効果を極力損な
うことのない手法としてゴール指向要求分析を簡易化した「ゴール指向 Lite」を提案する．
3.2 手法詳細
ゴール指向 Lite はシンプルであり，既に獲得済の要求 1 つ 1 つに対し，2 つの手順を実施するだけである．図 3 にゴール指向 Lite の概念図を，表 2 に手順を，実際の具体例を図4 に示す．実施手順では，表 2 の洗い出し観点を自問することにより導出対象を獲得する．
洗い出し観点の決定根拠は，数あるゴール指向要求分析手法に共通する最も核となる観点だと考えたためである．また 1 段上位までとしたのは，手順をシンプルにすることで導出
対象の獲得を容易にするためである．実施にあたっては，思いつく限りの上位ゴールや問題・リスク，他要求を複数件導出して構わない．
3
－159－
－3－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）

上 位目的・ ゴ ール [A]2) 他要求抽出

1) ゴール抽出

元 要求[a]

他 要求[b]

図 3．ゴール指向 Lite 概念図（上位ゴールからのアプローチ）

表 2．ゴール指向 Lite 実施手順（上位ゴールからのアプローチ）
No

手順

1

獲得済の要求から１段上位の洗い出しの観点
なぜ要求[a]を実現する必要があるのか

目的 ・ゴールを導出する
2

導出対象
上位目的
ゴール[A]

導出した上位ゴールに紐付く

要求[a]を実現することだけで，ゴール[A]が実

下位要求

他の 下位要求を導出する

現するか

[b]

ゴ ール [A]を 実 現 する た め に必 要 なこ と は ，要求[a]以外にないか
要求[a]以外で，ゴール[A]を実現することができないか

上 位目的・ ゴール [A]
上長は月の残業時間が特定時間をオーバーしそうな部下を把握したい
1) ゴール抽出

2) 他要求抽出

元 要求[a]

他 要求[b]

上長 は部下全員分の月の残業時

月の残業時間が特定時間をオーバーしそうな社員

間を 一覧で確認できるようにしについて特定のタイミングで上長宛に警告メッセ

たいージが届くようにしたい

図 4．ゴール指向 Lite 活用例（上位ゴールからのアプローチ）

また，上位ゴールがうまく導出できない場合の代替手順として，問題・リスク観点からのアプローチを行う．表 3 にその手順を，図 5 に具体例を示す．

4
－160－
－4－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
表 3．ゴール指向 Lite 実施手順（問題・リスクからのアプローチ）
No

手順

洗い出しの観点

導出対象

1

要 求 [a]が 実 現 で き な い 場 合 の

要 求 [a]を 実 現 で き ない 場 合 ， ど の よう な 問 題

問題・リス

問題 ・リスクを導出するが起こり得るかク[A’]

導 出 した問題・リスクに紐付 く

要求[a]を実現することだけで，リスク[A’]が他要求[b]

他の 要求を導出する

起こらないか2

リ ス ク [A’] を 起 こ さ な い た め に 必 要 な こ とは，要求[a]以外にないか
要求[a]以外で，リスク[A’]を起こしてしまうことがあるか

元 要求[a]

他 要求[b]

上長 は部下全員分の月の残業時

月の残業時間が特定時間をオーバーしそうな社員

間を 一覧で確認できるようにしについて特定のタイミングで上長宛に警告メッセ

たいージが届くようにしたい

1) 問題・リスク抽出

2) 他要求抽出

実 現できな い 場合の 問題 ・リ スク[A’]
上長 は月の残業時間が特定時間をオーバーしそうな部下を把握することが困難となる

図 5.

ゴール指向 Lite 活用例（問題・リスクからのアプローチ）

実験
ゴール指向 Lite のヒアリングにおける有効性を検証するため，勤怠管理システム構築の仮想プロジェクトによる実証実験を試みた．利用者(ヒアリングされる者)と分析者(ヒアリングする者)に分かれ，さらに分析者は，ゴール指向 Lite の手法を用いなかった場合(分析者 A)と用いた場合(分析者 B)に分かれ，それぞれ要求獲得の為のヒアリングを実施した．
最終的にヒアリング時の質問内容と獲得した要求のリストを分析・比較することでゴール
指向 Lite のヒアリングにおける有効性を検証した．
4.

4.1 実験方法
今回の実証実験の手順概要を表 4 に示した．また，各実験参加者の詳細手順と初期開示
した要求リストについては付録 1 に記載した．
表 4．要求獲得ヒアリング検証実験の手順概要
No

実験手順

1

利用者(1 名）が作成した要求リストのうち 10 件の情 報を分析者(各 2 名)に開示

30 分

2

開示された情報を基に，ゴール指向 Lite の分析を実 施 ※分析者 B のみ

30 分

3

開示された要求リストを基に分析者 A，分析者 B がそ れぞれヒアリング実施

60 分

4

最終的に分析者 A，B が獲 得した要求リストとヒアリング時の質問内容を比較

30 分

5
－161－
－5－

所要時間

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
4.2 実験結果
実証実験にて，分析者 A，B がヒアリングした全質問リスト及び獲得できた全要求リストを付録 2 に記載した．これら結果のうち，分析者 B が獲得した要求リストの一部を抜粋したものを表 5 に，ゴール指向 Lite 適用による効果の分析結果を表 6 に示す．
また実験時には，従来のゴール指向要求分析手法実施者も設けて分析を行ったが，30～
60 分の時間制約内でツリーを完成させられず，十分な効果をあげることはできなかった．
表 5．実験にて分析者 B(ゴール指向 Lite 分析有)が獲得した要求リストの一部抜粋
No

獲得要求内容02

プラ イベートのデバイス（携帯・PC）からは利用できないようにしたい

08

承認 差戻しなどが頻繁に起こらないことが望ましい

12

費用 種別は,PJ 費用(直接作業費)とそれ以外費用(間接作業費)を管理したい

13

定時 退社率などの分析レポート機能などは今の所不要14

申請 ・承認は月次だけでよい

15

三六 遵守の為に社員の残業状況を見える化したい

16

三六 協定違反者にはメールで通知する機能が欲しい17

三六 協定に違反しそうな人には,アラートが上がる機能が欲しい18

三六 遵守のアラート機能は該当社員だけでなく，上長にもあがるようにしたい19

三六 遵守のアラートは閾値設定で管理できるようにしたい20

さら に三六遵守のアラート前に，後何時間のような情報が伝わるようにしたい21

上長 が部下の勤務実績について，6 営業日毎にチェックできるようにしたい23（適 度な 柔軟 性を欠 くことがなけれ ば） 自動登録機能 があり，それを編集 できる 仕組みとしての 検討の余地はある38

従業 員の入力負荷削減を最優先で重視（1 人あたり 1 日 4，5 分⇒1，2 分にした い）

表 6．ゴール指向 Lite 実施による効果分析
ゴー ル

総質

指向

問件

ゴール指向要求分析に期待する６つの効果

機能仕様ま

(1)抜け

(2)必要理

(3)矛盾

(4)重要

(5)暗黙知(6)認識共

たは現状の

Lite

数

漏れの防

由の明確

や誤りの

度・優先

に対する

有促進

確認

適用 有

(件)

止

化

排除

度の把握

気付き

A（無）

42

1

2.4%

4

9.5%

0

0.0%

0

0.0%

0

0.0%

0

0.0%

37

88.1%

B（有）

42

0

0.0%

13

31.0%

1

2.4%

2

4.8%

5

11.9%

0

0.0%

21

50.0%

無

5. 考察
5.1 ゴール指向 Lite 適用の効果（ゴール指向要求分析の 6 つの期待効果に対する）
2.1 章で挙げたゴール指向要求分析の 6 つの期待効果に対し，ゴール指向 Lite での適用
効果を 4.2 章の表 6 より下記の通り考察した．
(1) 要求獲得における抜け漏れの防止効果は見られなかった．これは，複数抽出していた上位ゴールが初回ヒアリングにて明確化される前に，抜け漏れを洗い出すことは非効率であった為，今回の実証実験では効果が出ていないものと思われ，ヒアリングを数回繰り返すことで効果が出てくるものと推測する．
(2) 要求の必要理由の明確化
6
－162－
－6－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
大きく効果があった．例えば，4.2 章の表 5 における要求 No.11 から 21（36 協定に関連する各要求）の獲得にあらわれている．そもそもゴール指向 Lite の手順が問いかけている内容そのものである為，期待通りの結果が出ていると言える．
(3) 要求獲得における矛盾や誤りの排除
効果はほとんど見られなかった．これは複数の要求を照らし合わせるなど，全体を見ることで気が付くことができる内容であるため，ゴール指向 Lite では難しいと思われ，予想通りの結果と言える．
(4) 要求の重要度・優先度の把握
多少の効果があったと見られる．具体的には 4.2 章の表 5 における要求 No.38（入力
負荷軽減が最優先）の獲得があげられる．複数抽出したゴールそれぞれに対して，質問することで優先度の高いゴール・要求というものが見えてくることより，それなりに期待する効果が得られたと言える．
(5) 要求獲得のためのヒアリング時における暗黙知に対する気付き効果があったように見られる．例えば，4.2 章の表 5 における要求 No.02（個人のデバイスは使用不可という社内ルール）及び No.08（承認時の差し戻し頻発対策）の獲得などが該当する．ユーザーが当たり前と思っている内容は，要求として提示されないこともしばしば起こり得るが，上位ゴールから下位要求を把握する段階で幾分か気が付くことができるものと思われる．しかし，今回の実験結果では(1)の抜け漏れが抽出できていないことから，偶然的に出た結果かも知れず，さらなる検証を要すると言える．
(6) ヒアリング者と被ヒアリング者間での認識共有の促進効果は見られなかった．しかし，ヒアリング時に一緒に付箋を貼りながらゴールを洗い出すなどを実施することができれば，より期待する効果があげられるのではないかと推測する．
また，表 5 からは確認できないが，「代替案の提案」が可能となるという効果も実験の結果から見て取れた．これは，上位ゴールを分析した上で，そこから代替案を検討・提案するというアプローチが可能となるという効果である．実験結果として，4.2 章の表 5 における要求 No.35（自動登録機能）の獲得にその効果が現れている．初期開示要求においては，「自動登録機能は不要」という要求だったが，「柔軟性担保」というゴールを維持出来
れば，自動登録ありで編集可能とすることで検討の余地があるという回答を獲得している．
5.2 ゴール指向 Lite 適用の効果（ゴール指向要求分析の 3 つの課題に対する）ゴール指向 Lite の適用に対し，2.1 章の表 1 の課題が解消できているかどうか表 7 に整理した．ただし，1 度の検証実験しか行えていないため確定的な結果とするためには，実験を重ねる必要があると考えている．
表 7．ゴール指向要求分析の課題への対応
No

課題点

1

時間 制約

2

属人 性

ゴール指向 Lite を用いた結果
実施手順が少ないので短時間で実施することができた
実施 手 順の 観 点が 明 確 であ る た め， 分 析実 施 者 が代 わ っ ても 概 ね同 様の結果が期待できる3

本来 目的の喪失

記載 レ ベル （ 分解 化 ・ 詳細 化 ） の観 点 を定 め て ある の で ，重 要 で本 質的な要求の獲得と分析という本来目的が実施できた

7
－163－
－7－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
5.3 実験結果から考察されたゴール指向 Lite の特徴(1) ステークホルダとの協働分析作業
通常のゴール指向要求分析においては，その分析をいつ行うのかは特に定められていない．しかしゴールモデルが大きくなることを考えると，ステークホルダとその場で一緒にツリーを作成するような方法は現実的に難しく，要求獲得後に分析者が個別分析し，質問事項を後で作成することが通常である．一方，ゴール指向 Lite の場合，1 つの要求から導出した複数のゴールをヒアリング時に確認しながら分析していくことで，短い時間でヒアリングと分析を同時並行で進めることができた．
これより，ゴール指向要求分析をすべて実施しきるよりも，ヒアリング時にステーク
ホルダとその場で一緒に分析することのハードルが低くなると感じた．また，その場で実施完 了を目指 すのでステ ークホル ダ間でゴー ルと要求 の認識共有 が促進さ れるこ とを期待できる.
(2) ヒアリング傾向
ヒアリング時における質問全体の特徴としては，ゴール指向 Lite 非適用の分析者 Aは，「機能詳細を明確にしようとする」傾向が見られた．一方,ゴール指向 Lite 適用の分析者 B は，「目的を明確にしようとする」傾向が見られた．この傾向から，分析者 Aは分析者 B より早い段階で質問が枯渇することが予想され，ヒアリングを複数回繰り返していくことで，分析者 A，B 間の要求獲得・分析の差はさらに大きくなっていくものと推測できた．
6.

結論と今後の展望
我々は，仮想プロジェクトへの実証実験を通して，要求獲得のためヒアリング時における手法であるゴール指向 Lite を提案し，以下の有効性を確認した．
・ゴール指向要求分析の 6 つの効果を引き継いでいる(5.1 の(1)～(6)参照）
・ゴール指向要求分析の 3 つの課題を解消できる(5.2 参照)
また，今回の実証実験は時間的制約上，1 つの仮想プロジェクトを１度しか実施することができなかった為，十分な検証が行えたとは言えない．特に 5.1 章の以下の 3 点に対しては実証実験を繰り返し行うことによりその効果検証ができると考えた．
(1) 要求獲得における抜け漏れの防止(5) 要求獲得のためのヒアリング時における暗黙知に対する気付き(6) ヒアリング者と被ヒアリング者間での認識共有の促進
今後，実プロジェクトにおけるゴール指向 Lite 活用も含め，あらゆる検証を継続的に行いつつ，必要に応じてゴール指向 Lite をブラッシュアップしていくことで，より実用的な手法として確立していきたい．

・謝辞
本論文の執筆に当たり,九州大学大学院の荒木啓二郎教授,栗田太郎主査,石川冬樹副主査,
日科技連・研究コース 6 の研究員の皆様,日科技連・事務局の皆さまにお世話になりました.
厚く御礼申し上げます.
参考文献[1] 飯村結香子・斉藤忍,REBOK に基づく要求分析実践ガイド,近代科学社,2015[2] 山本修一郎,非機能要求とゴール指向要求定義,情報処理 Vol49 No4,2008,pp371-379

8
－164－
－8－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
付録 1．4.1 実験における担当者毎の詳細手順と初期提示した要求リスト
表 8．利用者の詳細手順
No

手順

1

要求 リストを作成 ※事前準備

2

その 内 10 個を初期情報として分析者 A，B に開示

3

分析 者からヒアリングを受ける

4

受け た質問に対してのみ回答し，要求リストからの要求情報を提示する

表 9．分析者 A(ゴール指向 Lite 分析無)の詳細手順
No

手順

1

初期 提示された要求リストを基に，思いつくままにヒアリング内容を整理

2

利用 者に対してヒアリング実施

3

上記 ヒアリング結果を元に整理

4

最終 的に獲得した要求をリスト化

表 10．分析者 B(ゴール指向 Lite 分析有)の詳細手順
No

手順

1

初期 提示された要求リストを基に，ゴール指向分析及びヒアリング内容を整理

2

分析 結果を元に利用者に対してヒアリング実施

3

上記 ヒアリング結果を元に整理

4

最終 的に獲得した要求をリスト化

表 11．初期提示した仮想プロジェクト(勤怠管理システムの構築)の要求リスト
No
01

要求内容
各 社 員 が毎 日 登録 する勤怠入力 画 面が 使いづら く， 登録 に 時間がか かっ て しま って いる ことを改 善したい02と は い え， 残 業時 間規制の管理 目 的よ り，一月 分を まと め て登録す るよ う なこ とは させ たくない （原則社員に毎日登録してもらうことを想定している）

03

入退 室 ID などから自動登録するような厳密な管理は柔軟性を欠くためやりたくない04

2018 年 4 月 15 日には全社 員が登録可能とする

05

予算 は 3,000 万円

06

現状 ，社内ネットワークに接続した PC からしか利用 できないが，スマホからでも利用できるよう にしたい07

三六 協定遵守を強化すべく，社員に注意を促したい

08

作業 Work や PJ，部門の間接費と作業時間を紐付けることで，当月発生した費用種別を分類したい

09

社員 数 1,000 名，20 年分以 上のデータ保持が可能であること

10

月末 など複数ユーザーが同時に利用しても耐えられること

9
－165－
－1－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
付録 2．実験における分析者 A，分析者 B の質問内容および獲得した要求リスト
表 12．実験結果にて分析者 A(ゴール指向 Lite 分析無)が実施した質問リスト
No

質問内容

01

各社 員はどのような契約種別の方がいるか（正社員，契約社員）

02

現状 の勤怠入力画面はどのようなものですか03

入力 する項目は時刻だけですか04

なに が使いづらい（どのような点に使いつらさを感じていますか）05

項目 への不正入力チェックは？

06

時間 がかかっている（現状と改善ラインの明確化）

07

残業 時間規制管理とはどのようなものか（詳細を説明）

08「入 退出管理の柔軟さ」とはなにか。

09

自動 登録ではない場合，虚偽申請はどう排除するか

10

承認 機能はつけますか11

現状 の承認は

12

代理 承認はありか？

13

承認 者の変更は可能か？

14

代理 入力はありか？

15

入力 可能期間の想定はあるか？

16

入力 間違い時の訂正の仕組みは？

17

つけ るならどのような承認となりますか

18

24 時間使えますか19

アカ ウントの管理はどのように行いますか20

既存 のアカウント管理システムはありますか21

スマ ホ利用時の機能はＰＣと同等か（スマホでの制限があるか）22

スマ ホ利用の目的はなにか

23

携帯 は？

24

リモ ート申請に対する虚偽チェックは？

25

三六 協定遵守に関し，どのような温度感で注意を促したいか26

作業 work とはなにか？

27

費用 種別とはなにか

28

どの ような分類があるか

29

分類 した後，どのような目的に使用したいか

30

20 年貯めたいということだが，退職者の扱いはどうするのか

31

20 年の根拠は？

32

過去 データの閲覧方法は

33「20 年以上」とは？

34

社員 数 1000 名超えることはないか

35

将来 への拡張性はどう考えているのか

36

同時 利用の想定人数は？

37

デー タのバックアップは38

シス テム停止時間は「あり」？（メンテナンスはありか？）39

クラ ウド利用は？

40

シス テム停止時間は「あり」？（障害時の復旧所要時間）

412018 年 4 月 15 日近辺の入 力内容の扱いをどうするか？

42

試行 期間を設けますか？

10
－166－
－2－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
表 13．4.2 実験結果にて分析者 B(ゴール指向 Lite 分析有)が実施した質問リスト
No

質問内容

01

現状 （スマホ or）社内ネットワークに接続したノート PC からのみできるのか？

02

外出 時は？

03

現状 はスマホ・PC

04

必ず VPN？セキュアな接続は必要ですか？

05

現状 ，何が使いづらいのか？

06

手入 力はできればしたくない？

07

マウ スだけでできれば良い？キーボード入力が使いづらいということ？

08

入力 する項目数が多い？現状どのくらいの数？

09

具体 的に何が使いづらいのか？

10

承認 差戻しとかが沢山あるという意味で使いづらいということはあるか？

11

作業 Work とか PJ は別シス テムで紐付けているのか？（新規か現行か）

12

連携 機能が必要ということで良いか？

13

間接 費と直接費とそれ以外で分けておく必要があるか？

14

承認 を紙で行っているのは，月次のことか？

15

36 に関する現状は？あまり遵守されていないのか

16

これ をシステム的に実現したいということか

17

36 遵守はマネージャーに求められているのか？現場に求められているのか？

18閾値 があってアラート機能があるといいということか？

19

月次 だけの連携でよいか？年次は？

20

レポ ート機能はいるか？定時退社率など

21

自動 登録ではだめなのはなぜか？

22

出張 ・外出者が 3 割程度だ として 7 割の自動登録でも コストダウンになるが…

23

自動 登録機能がありつつ，編集できる機能があればありなのか？

24

自動 の情報の管理は法的側面で重要ではないか？

25

一月 分まとめて登録したくないとのことだが，毎日入力している監視は必要か？

26

日ご とに入れるようなチェック・注意機能がある方が望ましいのか？

27

管理 者が見えるビューはいるのか？（上長が部下のを）

28

その 時どういう風に見ることができるとありがたいのか？

29

社員 数の増減はあるのか？

30

同時 利用者数は？派遣社員とかも含め

31

管理 が必要な ID 数は32

なぜ 20 年残すのか？

33

20 年後はどうするか？削除？

34

可用 性も関係しているか？遠隔地バックアップもできるが35

すぐ 使うか？20 年分がクラウドサ ーバ上に管理出来ていればよいか？

36

登録 可能とは？

37

試用 期間？

38

開発 費のみか？

39

費用 オーバーの場合,必須の要求は何か？

40

最も 望む効果は何か？（効率化か？残業時間の管理？）何を重要視しているか41

企業 理念は何か？究極のゴールは何か？

42

スマ ホは海外でも使用できるべきか？

他？ガラケはある？会社のスマホ？プライベートも？
現場の声は？

⇒基準？保存期間？

ユーザー登録？利用開始？
保守運用費含む？

11
－167－
－3－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
表 14．4.2 実験結果にて分析者 A(ゴール指向 Lite 分析無)が獲得した要求リスト
No

獲得要求内容01

勤怠 （出勤，休暇）と出勤時刻，退勤時刻，各日ごとの総勤務時間を入力する

02

15 分単位で入力

03

1 人 /日の入力で 3 分が現状 ．1 分以内が目標

04

原則 ，今日の分は今日中に入力したい

05

三六 協定遵守違反しない，させない

06

入退 館管理との自動連携は普段もしません07

虚偽 申請に対するチェックは基本的には上長チェック．不正は承認しない

08

シス テム承認機能をつける

09

新シ ステムにおいては，システムで 1 ヶ月分をまとめ て上長承認する

10

代理 承認はしない

11

承認 者の変更はシステム管理者でのみ承認者の登録・変更が行える

12

代理 入力はしない（原則本人で実施）

13

入力 可能期間は上長承認実施となる翌月第 5 営業日ま でに本人入力，申請する

14

申請 の単位は 1 ヶ月まとめ て15

入力 間違い時は，申請するまでは本人訂正が可能

16

24 時間使用できる

17

アカ ウントの管理はＡＤでのみ実施（ＡＤ以外は存在しない）

18

スマ ホ利用時の機能はＰＣと同等か（スマホでの制限があるか）

19

同等 (システム管理者も同等）

20

利用 者や承認者のリモート作業のためスマホを利用できるようにする

21

携帯 電話（ガラケー）の想定はしなくてよい22

リモ ート申請に対する虚偽チェックは本人の自己申告に任せる

23

三六 協定 遵守 に関し ，6 営業日ごと にチ ェックをし， 閾値を超えた場合は ，イエ ローアラー
トを 本人および上長にシステムメールする

24

費用 種別は，プロジェクト費用（直接作業費）とそれ以外費用（間接作業費）を管理したい

25

費用 種別で分類した後，人事システムや経理システムへ夜間バッチ連携したい

26

分類 データについては，バッチ以外でのデータ抽出も実施したいが優先度低（コスト次第）

27

分類 データについては，CSV 出力で．（汎用性担保）

28

退職 者も含めて 20 年ためる

29

過去 データの閲覧方法を検索して閲覧できることも今回システムに含む30

最低 20 年分のデータをためられること．最高は特に規定しない.

31（デ ータ保存上限に基づき，最高は定まる）

32

上限 に達しそうだというメッセージは出力し，上限に達した場合は管理者で消す

33

1,000 名利用を最大として，最初から 1,000 名が使え るようにする

34

同時 利用の想定人数は 200 人ぐらい．ただし，レスポンスが悪くなってもいいけど使用できなく なるのは不可

35

デー タのバックアップはいらない36

シス テム停止時間は 24 時間までは許容する．（自社メンテナンス，障害時対応）

37

クラ ウド利用はＮＧ．オンプレで構築

38

2018 年 4 月 15 日システム 稼動だが 4 月 1 日分を新シ ステムで入力可能とする

39

試行 期間を設けない．4/15 で完全切り替え

12
－168－
－4－

研究コース６「要求と仕様のエンジニアリング」（GOØWY チーム）
表 15．4.2 実験結果にて分析者 B(ゴール指向 Lite 分析有)が獲得した要求リスト
No

獲得要求内容01

利用 するデバイスはスマホとノート PC のみでよい（ガラ携の想定は不要）

02

プラ イベートのデバイス（携帯・PC）からは利用できないようにしたい

03

AD 認証で管理できるようにしたい

04

VPN などセキュアな接続は不要

05

勤怠 登録画面の入力項目はなるべく選択などできる形だと有難い06

キー ボード入力なしでマウスだけで動かせるような UI だと嬉しい

07

勤怠 登録画面の必須項目が少ないと嬉しい

08

承認 差戻しなどが頻繁に起こらないことが望ましい

09

費用 種別は別システムとの連携機能が欲しい（二重登録を避けたい）

10

分類 データについては CSV 出力で（汎用性担保）

11

費用 種別の連携機能は月次だけで十分,年次は不要（別システムで管理する為）

12

費用 種別は,PJ 費用(直接作業費)とそれ以外費用(間接作業費)を管理したい

13

定時 退社率などの分析レポート機能などは今の所不要14

申請 ・承認は月次だけでよい

15

三六 遵守の為に社員の残業状況を見える化したい

16

三六 協定違反者にはメールで通知する機能が欲しい17

三六 協定に違反しそうな人には,アラートが上がる機能が欲しい18

三六 遵守のアラート機能は該当社員だけでなく，上長にもあがるようにしたい19

三六 遵守のアラートは閾値設定で管理できるようにしたい20

さら に三六遵守のアラート前に，後何時間のような情報が伝わるようにしたい21

上長 が部下の勤務実績について，6 営業日毎にチェックできるようにしたい22

出張 ・外出者も登録することを視野に入れた入力の仕組みとしたい23（適 度な 柔軟 性を欠 くことがなけれ ば） 自動登録機能 があり，それを編集 できる 仕組みとしての 検討の余地はある24

自動 登録 され た情報 を法的側面で有 効に 活用できる可 能性については検討 の余地 あり（電通
問題 のようなトラブル時の証明として利用可能）

25

毎日 ,業 務終了後に社員が 必ず勤怠入力す る運 用とし たい為， 日々の 入力 完了/未完の監視・注意 機能は不要

26

上長 が部下の勤怠情報を参照できるビューが欲しい27

現在 普通社員 300 名程度だし，派遣社員や離職者を加味しても過去の社員数増減の推移的に最大 1,000 名で十分

28

管理 が必要な ID 数は 6 桁（100,000 ユーザ）

29

同時 利用者の想定人数は 200 人位

30

20 年分保持したい理由は会社の決まりであり，必ず守る必要がある

31

20 年後は手動で削除する為，自動削除機能は不要

32

デー タのバックアップはいらない33

クラ ウド利用せず今回はオンプレ，いつでも 20 年分シ ステムで見られるようになっていたい34

2018 年 4 月 15 日システム 稼動だが 4 月 1 日分を新シ ステムで入力可能とする

35

試用 期間は不要

36

開発 費のみで 3000 万円．ハードや保守運用費は別でも OK37

費用 対効果が見込めるなら，多少のオーバーもあり

38

従業 員の入力負荷削減を最優先で重視（1 人あたり 1 日 4，5 分⇒1，2 分にした い）39

スマ ホは海外でも利用したい

13
－169－
－5－