平成 28 年度 文部科学省「成長分野等における中核的専門人材養成等の戦略的推進」事業

地域 IT 産業振興のための IT アーキテクト育成事業

事業成果報告書

平成２９年２月
学校法人河原学園
河原電子ビジネス専門学校

1

2

目次
1.

本事業の概要 ................................................................................................................... 5
1.1. 事業の趣旨と目的 ..................................................................................................... 5
1.2. 事業実施の背景 ......................................................................................................... 5
1.2.1. 地域産業の特性 .................................................................................................. 5
1.2.2. IT 分野の成長可能性 .......................................................................................... 6
1.2.3. 本事業を実施する意義 ....................................................................................... 7
1.3. 事業の実施体制 ......................................................................................................... 7
1.3.1. 概要..................................................................................................................... 7
1.3.2. 各委員会の役割 .................................................................................................. 8
1.3.3. 委員会・作業部会の構成 .................................................................................... 9
1.3.4. 実施委員会の開催 ............................................................................................. 10
1.3.5. 作業部会の開催 .................................................................................................11
1.3.6. 評価委員会の開催 ............................................................................................. 13

2.

事業活動の内容 ............................................................................................................. 14
2.1. 教育プログラムの方針 ............................................................................................ 14
2.2. 成果物の概要 ........................................................................................................... 14

3.

成果物の内容 ................................................................................................................. 16
3.1. テキスト .................................................................................................................. 16
3.2. コマシラバス ........................................................................................................... 173.3. 理解度確認テスト ................................................................................................... 24

4.

実証講座の内容 ............................................................................................................. 36
4.1. 概要 ......................................................................................................................... 36
4.1.1. 目的................................................................................................................... 36
4.1.2. 受講者 ............................................................................................................... 36
4.1.3. 実証講座の概要 ................................................................................................ 37
4.1.4. 理解度確認テストの概要 .................................................................................. 38
4.1.5. アンケートの概要 ............................................................................................. 38
4.2. 実証講座「要件定義」の実施体制 .......................................................................... 38
4.2.1. 受講者 ............................................................................................................... 38
4.2.2. 実施内容 ........................................................................................................... 42
4.3. 実証講座「要件定義」の結果 ................................................................................. 44
4.3.1. 事前理解度確認テストの結果........................................................................... 443

4.3.2. 理解度確認テストの比較 .................................................................................. 47
4.3.3. 事前アンケートの結果 ..................................................................................... 48
4.3.4. 事後アンケートの結果 ..................................................................................... 49
4.4. 実証講座「アーキテクチャ設計」の実施体制........................................................ 54
4.4.1. 受講者 ............................................................................................................... 54
4.4.2. 実施内容 ........................................................................................................... 58
4.5. 実証講座「アーキテクチャ設計」の結果 ............................................................... 60
4.5.1. 事前理解度確認テストの結果........................................................................... 60
4.5.2. 理解度確認テストの比較 .................................................................................. 63
4.5.3. 事前アンケートの結果 ..................................................................................... 64
4.5.4. 事後アンケートの結果 ..................................................................................... 65
4.6. 実証講座の評価 ....................................................................................................... 70
4.6.1. 実証講座「要件定義」の評価........................................................................... 70
4.6.2. 実証講座「アーキテクチャ設計」の評価 ........................................................ 73
4.6.3. 評価委員の所感 ................................................................................................ 75
5.

付録：テキスト『要件定義・アーキテクチャ設計』 ................................................... 77

4

1. 本事業の概要
1.1. 事業の趣旨と目的
近年、愛媛県は観光地として発展を遂げつつある反面、いまだに将来有望な地域産業を見出すことができないでいる。既存の産業構造の特性および立地・物流面での不利も影響していると考えられる。他方、県内情報産業は、この数年売上高を伸ばしているとともに、
すでに 3 つの業界団体が組織され、一定の地域的基盤を形成している。ただし、県内情報
産業は大都市圏の大手 IT 企業の二次請け、三次請けの受託が中心で、このままでは今後の大きな事業拡大を見込むことは難しいという課題を抱えている。そこで、県内情報産業に、利益率の高い SI（System Integration）事業へと事業展開する契機を提供するため、SI 業
務の中核をなす IT アーキテクトの育成プログラムを開発する。プログラム開発にあたっては、今年度は多様な理論・方法論を比較解説するテキスト、講座の再現性を高めた詳細な
シラバス・コマシラバス、受講者の能力判定を行う理解度確認テストを開発する。全体で、IT アーキテクトに必要な広い視野と応用力を備えた人材育成プログラムの開発を目指す。

1.2. 事業実施の背景
1.2.1. 地域産業の特性
近年、愛媛県は、道後温泉・松山城・しまなみ海道等の観光資源によって、観光地として全国的な知名度を獲得しつつある。実際に、愛媛県の県外観光客の年間総消費額は 2014年には 968 億円に達し、2005 年から約 16％も増加している（愛媛県「観光客数とその消費額」） 。しかし、観光産業の振興とは裏腹に、県内人口は 2005 年 147 万人から 2016 年
138 万人へと約 6％も減少しており、典型的な“地方”現象に見舞われている。
事実、産業全体の視点でみると、愛媛県では 2005 年に約 3.4 兆だった売上高総計が 2013年には 3.1 兆へと 7.5％も減少している一方で、企業数は 245 社から 246 社へと 1 社の増加にとどまっている（経済産業省「企業活動基本調査確報」※調査対象は従業者 50 人以上かつ資本金又は出資金 3,000 万円以上の会社のみ）。東京では同時期に、企業数が 7,430 社から 8,454 社へと約 14％も増加しているにもかかわらずである。
では、愛媛県には、どのような産業構造上の特性があるのだろうか。愛媛県で 2011 年に策定された「愛媛県産業振興指針（第二次改訂）」によれば、県内総生産上の比率でみると、サービス業（21.8％）、製造業（18.0％）の 2 つが基幹産業とされている。このうち製造業
は、パルプ・非鉄金属・石油・石炭系等、基礎素材型産業が県内製造品出荷額の 55.7％を占めており、しかもそれらの多くが、（１）県外資本の大手企業によるものであり、（２）
製造品が県内で加工されず県外に中間素材として出荷されるという構造となっている。
5

（１）については、県外資本大手企業がグローバル戦略にともなって、中間素材の生産拠点を将来的に県外に移設する可能性があり、（２）については、加工製品の製造機会が県内製造業から奪われてしまっている。しかし、この構造は県外資本大手企業の経営判断に委ねられており、愛媛県の産業行政によって容易に解決できるものではないと思われる。
以上のことから、愛媛県において今後の成長分野は、観光産業、基礎素材型製造業以外に求める必要があり、かつ、（１）事業拡大が容易となるように設備投資等のコストが低い
産業分野であること、（２）人材教育の利益還元率が高い産業分野であること、（３）愛媛
県の立地・物流上の劣位に左右されない産業分野であることといった条件を満たす必要があると考えられる。
ここで再度、経済産業省「企業活動基本調査確報」の 2005 年と 2013 年のデータを比較すると、愛媛県では製造業の売上高が 1.71 兆円から 1.36 兆円へと約 20％も減少しているのに対して、飲食サービス業が 135 億から 202 億へと 50％の増加、情報通信業（2005 年
段階では「情報サービス・情報制作業」と分類）が 288 億から 299 億へと 4％の増加となっている。他には小売業が 7,695 億から 8,138 億へと 6％程度の増加である。小売業にしても飲食サービス業にしても、売上を左右する商材、営業形態、立地条件は多種多様であり、ひとつの人材教育プログラムによって分野全体に大きな発展をもたらすことは難しいと思われる。
したがって、本事業では、愛媛県における新たな成長分野として IT 分野（とくにシステ
ム開発分野）に焦点を絞りたい。IT 分野であれば、愛媛県内にすでに業界団体（愛媛県情報サービス産業協議会、愛媛県ＩＴ推進協会、愛媛ニアショア開発協議会）が組織され、産業の基盤が形成されているだけでなく、とくにシステム開発であれば、事業拡大に伴う生産設備コストを抑制できると同時に、立地・物流環境の影響を受けにくく、しかも、知的訓練による生産性の向上を期待しやすいからである。

1.2.2. IT 分野の成長可能性
しかし、IT 分野において企業の事業拡大の要因とは何だろうか。情報サービス産業協会の調査（「2014 年版 情報サービス産業基本統計調査」）では、IT 企業を 3 種（SI サービス型、ソフトウェア開発型、IT アウトソーシング/情報処理サービス型）に分類した上で、従業員 1 人あたりの売上高平均値、売上高成長率平均値等の比較を行っている。
「SI サービス」とは、いわゆる超上流・上流（企画・コンサルティング・要求定義）から下流までを一括して提供するサービスであり、「ソフトウェア開発」は下流のみ（プログラム作成やソフト
ウェア保守）、「IT アウトソーシング/情報処理サービス」は、情報システムの管理運用やデー
タ処理サービスを意味している。この 3 種において、従業員 1 人あたりの売上高平均値は、
SI サービス型が 2,861 万円、ソフトウェア開発型が 1,986 万円、IT アウトソーシング/情報処理サービス型が 2,222 万円であり、売上高成長率平均値は、それぞれ 5.44％、2.59％、
6

2.83％である。
ここから、IT 分野において利益や成長を促進する要因のひとつとして、いわゆる超上流・上流工程の技術を考えることができる。IPA の共通フレームの用語にしたがえば、業務要件
定義、システム要件定義、ソフトウェア要件定義、システム方式設計、ソフトウェア方式
設計といった技術である。このような技術を駆使する技術者は、近年では IT アーキテクトと呼ばれている。
他方、経済産業省「企業活動基本調査確報」（2013 年）によれば、情報通信業分野における従業員 1 人あたりの売上高は、東京都の 2,856 万円に対して愛媛県は 1,802 万円とされている。さらに、SI サービス型企業の平均従業員数は 1,148 人、ソフトウェア開発型が 504人であるのに対して（「2014 年版 情報サービス産業基本統計調査」）、愛媛県内の IT 企業の平均従業員数は 166 人である（「企業活動基本調査確報」2013 年）。従業員・売上高の規模から、愛媛県内の IT 産業は SI サービス型が少ない、つまり、IT アーキテクト人材が少ないのではないかと考えられる。

1.2.3. 本事業を実施する意義
以上のことから、本事業では、愛媛県の IT 産業発展に寄与するべく、県内の IT エンジ
ニア（主としてプログラマーが想定できる）を IT アーキテクトへと成長させる教育プログ
ラムを開発するものとする。これにより、愛媛県内の IT 企業に、利益率の高いビジネス（SIサービス）へと事業展開するためのひとつの契機を提供したい。同時に、この教育プログ
ラムは、類似地域 IT 産業への適用や標準的な IT アーキテクト育成プログラムの形成に役立つとともに、将来的に、近年議論されている「次世代高度 IT 人材」（IT サービスアーキ
テクト等の「異分野と IT の融合領域においてイノベーションを創出し、新たな製品やサービスを自ら生み出すことのできる人材」）の育成プログラム形成にも示唆を与えるはずである。

1.3. 事業の実施体制
1.3.1. 概要
本事業は、ふたつの委員会とひとつの下部組織から構成される（図 1（組織図）参照）。
まず、事業の推進主体として「実施委員会」を編成する。実施委員会の下部組織として、事業の実作業（外注作業の発注、作業指示や進捗・品質管理も含む）を機動的に担う「作業部会」を設置する。さらに、教育プログラムや実証講座の有効性・妥当性等の評価を担う「評価委員会」を設置する。

7

図 1（組織図）
実施委員会
評価結果の
フィードバック

事務局（河原学園法人本部）

事業全体の活動方針・方向性の決定
重要事案に関する検討に関する意思決定
発注承認の審議
成果物の改良方針の策定

外部業者の事業者情報・発注内容・期日等の発注条件を説明

作業指示・発注承認
改良案の検討指示

事業全体の進捗・使用経費のマネジメント
関係者への連絡・調整
会議や実証講座の開催・運営・記録等
最終的な報告書

作業部会
教育プログラム開発
実証講座の開催・運営等の企画・実施
外部業者依頼の検討・作業指示書作成

開催・運営・記録

実証講座

監修・制作・実施

発注・作業指示書による指示
進捗・品質管理改良指示

評価
教育プログラム

評価委員会
事業成果物・実証講座の評価基準の検討
評価項目・評価基準に基づく評価
事業成果物・実証講座の最終評価

評価

テキスト
シラバス・コマシラバス
理解度確認テスト

外部受注者
監修・制作・実施

1.3.2. 各委員会の役割
実施委員会は、事業全体の活動方針・方向性、実施内容等の重要事案に関する検討・意
思決定、および、作業部会への作業指示を担う。
作業部会は、実施委員会の指示のもと、教育プログラム（テキスト・シラバス・コマシ
ラバス・理解度確認テスト）開発、実証講座の開催・運営等の具体的内容の企画・実施を担う。また、各活動の過程において発生する作業を外部業者へ依頼する際の具体的内容の検討や発注に必要な作業指示書の作成も行う。これに基づき、実施委員会の審議を経て発注の承認を得る。作業部会は、発注後、作業完了に至るまでの進捗と品質の管理についても担当する。
ただし、外部業者の適切な候補選定が実施委員会開催時機に間に合わず、早急な発注を要する事案等に関して、実施委員会の審議を経ることが難しい場合には、実施委員会委員長に発注の承認を一任することがある可能性について、実施委員会において事前に同意を得ておくものとする。実際に実施委員会委員長に発注の承認を一任する事態が発生した場合には、実施委員会委員長に対して、作業部会が、外部業者の事業者情報、発注内容、期日等の発注条件を説明し、承認を得た上で発注を行うとともに、後日開催の実施委員会において事後承認を得るものとする。
評価委員会は、事業成果物および実証講座の評価項目・評価基準の検討およびそれに基づく評価を実施し、実施委員会にフィードバックを行う。このフィードバックに基づき、実施委員会は改良方針を策定し、作業部会に対して具体的な改良案の検討を指示する。さ8

らに、評価委員会は、事業成果物および実証講座の最終的評価も担当する。
事務局（河原学園法人本部）は、事業全体の進捗および使用経費のマネジメントを行うとともに、関係者への連絡・調整、会議や実証講座の開催・運営・記録等の各種事務作業を担う。

1.3.3. 委員会・作業部会の構成◆実施委員会の構成員（委員）
氏名
１

河原成紀

２

鳥居高之

４

芦澤昌彦

５

神馬一博

６

赤松民康

７

所属・職名

役割等

学校法人河原学園・理事長

都道府県名

統括・管理

愛媛県

開発

千葉県

開発・実証

愛媛県

開発・実証

愛媛県

愛媛県情報サービス産業協議会

実証

愛媛県

小林真也

愛媛県ＩＴ推進協会

実証

愛媛県

８

大塚純孝

愛媛ニアショア開発協議会

実証

愛媛県

９

武村貴史

株式会社アイ・エヌ・エス

開発・実証

愛媛県

10

下村宰

株式会社正岡商店

開発・実証

愛媛県

学校法人三橋学園船橋情報ビジネス専門学校校長
学校法人河原学園・教務部長
学校法人河原学園河原電子ビジネ
ス専門学校教頭◆評価委員会の構成員（委員）
氏名
１

梶原直樹

２

沖中孝広

３
４

所属・職名

役割等

学校法人河原学園河原電子ビジネ

都道府県名

統括・管理

愛媛県

コンピューターシステム株式会社

評価・検証

愛媛県

光永尚志

株式会社デーコム

評価・検証

東京都

生山浩

株式会社アライアンス代表取締役

評価・検証

埼玉県

ス専門学校教務部長◆実施委員会における下部組織（作業部会）の構成員（委員）
氏名

所属・職名

役割等

都道府県名

１

芦澤昌彦

学校法人河原学園・教務部長

統括・管理

愛媛県

２

井坂昭司

専門学校東京テクニカルカレッ

開発

東京都

ジ・情報処理科科長
9

３

平澤一志

４

神馬一博

５

武村貴史

６

下村宰

株式会社 ISID インターテクノロジー

開発

東京都

開発・実証

愛媛県

株式会社アイ・エヌ・エス

開発・実証

愛媛県

株式会社正岡商店

開発・実証

愛媛県

学校法人河原学園河原電子ビジネ
ス専門学校教頭

1.3.4. 実施委員会の開催◆第 1 回実施委員会
日 時

平成 28 年 9 月 28 日（水）16:00～18:00

場 所

国際ホテル松山 ２F パールの間 （愛媛県松山市一番町１－１３）

出席者

河原成紀（委員長、学校法人河原学園・理事長）、鳥居高之（学校法人三橋学園船橋情報ビジネス専門学校校長）、芦澤昌彦（学校法人河原学園・教務部長）、神馬一博（学校法人河原学園河原電子ビジネス専門学校教頭）、赤松
民康（愛媛県情報サービス産業協議会）、小林真也（愛媛県 IT 推進協会）、大塚純孝（愛媛ニアショア開発協議会）、下村宰（株式会社正岡商店）

議 題

１．委員長 挨拶
２．委員 自己紹介
３．事業計画の説明（１）文科省「成長分野等における中核的専門人材養成等の戦略的推進」（２）平成 28 年度事業概要の説明
４．事業実施内容の意見交換
５．今後のスケジュール
６．交通費・謝金についての説明

配布資料

１．
「地域 IT 産業振興のための IT アーキテクト育成事業」事業概要について
２．平成２７年度「成長分野等における中核的人材養成等の戦略的推進」事
業

採択一覧

３．IT アーキテクトとは◆第 2 回実施委員会
日 時

平成 28 年 12 月 2 日（水）16:30～18:00

場 所

河原電子ビジネス専門学校

出席者

河原成紀（学校法人河原学園・理事長）、芦澤昌彦（学校法人河原学園・教会議室（愛媛県松山市柳井町 3 丁目 3-31）

務部長）、神馬一博（学校法人河原学園河原電子ビジネス専門学校教頭）、赤10松民康（愛媛県情報サービス産業協議会）、小林真也（愛媛県 IT 推進協会）、
大塚純孝（愛媛ニアショア開発協議会）、武村貴史（株式会社アイ・エヌ・エス）、下村宰（株式会社正岡商店）
議 題

１．委員長ご挨拶
２．事業の進捗状況について
３．開発概要について（１）発注仕様について（要件定義）（２）発注仕様について（アーキテクチャ）
４．システム仕様書、演習システムの説明（１）在宅介護サービス支援システム仕様書
５．意見交換６．今後のスケジュール

配布資料

１．発注仕様書（アーキテクチャ）
２．発注仕様書（要件定義）
３．在宅介護サービス支援システム仕様書
４．要件定義サンプル
５．ソフトウェア要求仕様書（USDM）◆第 3 回実施委員会

1.3.5. 作業部会の開催◆第 1 回作業部会
日 時

平成 28 年 9 月 29 日（木）16:00～18:00

場 所

東京テクニカルカレッジ会議室 （東京都中野区東中野 4-2-3）

出席者

芦澤昌彦（学校法人河原学園・教務部長）、井坂昭司（専門学校東京テクニ
カルカレッジ・情報処理科科長）、平澤一志（株式会社 ISID インターテクノ
ロジー取締役）、神馬一博（学校法人河原学園河原電子ビジネス専門学校教
頭）

議 題

１．ご挨拶
２．委員 自己紹介
３．事業計画の説明（１）文科省「成長分野等における中核的専門人材養成等の戦略的推進」（２）平成 28 年度事業概要の説明（３）開発物の方向性の説明
11

４．事業実施内容等についての意見交換
５．今後のスケジュール
６．交通費・謝金についての説明
配布資料

１．
「地域 IT 産業振興のための IT アーキテクト育成事業」事業概要について
２．平成２７年度「成長分野等における中核的人材養成等の戦略的推進」事
業

採択一覧

３．IT アーキテクトとは◆第 2 回作業部会
日 時

平成 28 年 11 月 22 日（水）15:30～17:00

場 所

東京テクニカルカレッジ （東京都中野区東中野 4-2-3）

出席者

芦澤昌彦（学校法人河原学園・教務部長）、神馬一博（学校法人河原学園河原電子ビジネス専門学校教頭）、井坂昭司（専門学校東京テクニカルカレッ
ジ・情報処理科科長）、平澤一志（株式会社 ISID インターテクノロジー取締
役）

議 題

１．ご挨拶
２．事業の進捗状況について確認
３．開発概要について
４．システム仕様書、演習システムの説明（１）在宅介護サービス支援システム仕様書
５．意見交換６．今後のスケジュール

配布資料

１．開発概要について
２．在宅介護サービス支援システム仕様書◆第 3 回作業部会
日 時

平成 29 年 1 月 16 日（月）16:00～17:20

場 所

東京テクニカルカレッジ （東京都中野区東中野 4-2-3）

出席者

芦澤昌彦（学校法人河原学園・教務部長）、神馬一博（学校法人河原学園河原電子ビジネス専門学校教頭）、井坂昭司（専門学校東京テクニカルカレッ
ジ・情報処理科科長）、

議 題

１．ご挨拶
２．事業の進捗状況について確認
３．開発物（テキスト）の確認・修正作業
４．実証講座12

（準備・運営・記録・取りまとめ、結果分析、発注内容）について
５．意見交換６．今後のスケジュール
配布資料

１．開発物（テキスト）
２．アーキテクチャ設計 発注仕様書
３．要件定義 発注仕様書◆第 4 回作業部会

1.3.6. 評価委員会の開催◆第 1 回評価委員会
日 時

平成 28 年 12 月 21 日（水）16:30～18:00

場 所

河原電子ビジネス専門学校

出席者

芦澤昌彦（学校法人河原学園・教務部長）、神馬一博（学校法人河原学園河3F 会議室 （愛媛県松山市柳井町 3 丁目 3-31）

原電子ビジネス専門学校教頭）、沖中孝広（コンピューターシステム株式会社）、光永尚志（株式会社デーコム）、生山浩（株式会社アライアンス代表取
締役）
議 題

１．ご挨拶
２．委員 自己紹介
３．事業計画の説明（１）「地域 IT 産業振興のための IT アーキテクト育成事業」事業概要について（２）テキスト等開発概要説明（３）システム開発仕様について（在宅介護サービス支援システム）（４）発注仕様書および、事業成果物の説明と検証
４．事業実施内容の意見交換
５．実証講座について
６．今後のスケジュール
７．交通費・謝金についての説明

配布資料

１．
「地域 IT 産業振興のための IT アーキテクト育成事業」事業概要について
２．平成２８年度「成長分野等における中核的人材養成等の戦略的推進」事
業

採択一覧

３．IT アーキテクト教育プログラム テキスト等開発概要
13

４．在宅介護サービス支援システム仕様書
５．要件定義－発注仕様書
６．アーキテクチャ設計－発注仕様書
７．アーキテクチャ設計◆第 2 回評価委員会

2. 事業活動の内容
2.1. 教育プログラムの方針◆対象者の設定
本事業は、愛媛県内の IT 企業でシステム開発に携わり、かつ、超上流・上流工程（要件
定義やアーキテクチャ設計）には直接携わった経験がないプログラマーを対象とする。ただし、超上流・上流工程の学習には、一定のプログラミング技術を前提とするため、中堅以上のプログラマーで、将来的に IT アーキテクトの業務を希望している者を対象として推奨するものとする。
◆知識領域の設定
IT アーキテクトの活動は、ビジネス領域とシステム領域を媒介するものであることから、「要件定義」、「アーキテクチャ設計」の 2 つの知識領域を扱う。いずれの知識領域にも、
ソフトウェア工学上の著名な理論や経験的に有力だと評価されている方法論を導入することにより、IT アーキテクトに必要な視野の獲得を目指している。

2.2. 成果物の概要◆2 科目分のテキスト
ソフトウェア工学の成果に基づいて、「要件定義」、「アーキテクチャ設計」の 2 つの知識領域に対応して、2 科目分のテキストを開発している。
「要件定義」については、要求工学
知識体系（REBOK）を踏まえたうえで、具体的な方法論は、社団法人日本情報システム・
ユーザー協会（Japan Users Association of Information Systems : JUAS）の「要求仕様定義 ガ イ ド ラ イ ン 」 の ベ ー ス と し て 採 用 さ れ て い る USDM （ Universal Specification
Describing Manner）を主要な題材としてとりあげている。
「アーキテクチャ設計」については、近年の開発事例と親和性の高い設計手法（レイヤーパターン等）も含めて、CMU/SEI
アーキテクチャ手法群の「品質特性駆動型設計」（ADD ：Attribute Driven Design）を主
14

要な題材としてとりあげている。
◆2 科目分のシラバス・コマシラバス
実証講座での運用を想定し、「要件定義」、「アーキテクチャ設計」に対して、それぞれ 4
コマ分のシラバス・コマシラバスを開発している。シラバス・コマシラバスの形式は、平成 20 年度専修学校教育重点支援プラン事業『ソフトウェア開発教育の高度化のための「オブジェクト指向」教材の開発』の成果物を参考にし、講座の再現性向上を図っている。
◆テキストに対応した理解度確認テスト
実証講座での運用を想定し、「要件定義」、「アーキテクチャ設計」に対して、それぞれ 20
問ずつの問題を開発している。テキストで扱った理論・方法論に関して理解度を問うものとなっている。

15

3. 成果物の内容
3.1. テキスト
テキスト『要件定義・アーキテクチャ設計』の内容を巻末付録として掲載する。

16

1

90分/コマ要求仕様書に関わる問題と背
景

コマ主題

17

細目レベル

5キーワード

復習・予習課題

1_ 4

1_ 5

1_ 6

コマ主題細目

到達目標

1_ 2

1_ 3

シラバスとの関係

1_ 1

コマシラバス項目

復習：ISO/IEC 12207（JIS X 0160）の目的と共通フレームとの関係を説明できるようにしておくこと。また、共通フレームにおける要件定義の位置付
けを再理解しておくこと。ソフトウェア開発の現場における仕様の問題点とは何かを説明できること。
予習：要求と仕様とは具体的に何が違うかをテキストを読んで理解しておくこと。また、要求定義において高品質なシステムに求められるものは何なのかを説明できるようにしておくこと。

①共通フレーム ②要件定義 ③要求工学知識体系（REBOK） ④要求分析 ⑤ステークホルダー③ソフトウェア開発工程における最上流工程である要件定義のプロセスを工学的に定式化する技術を要求工学知識体系（REBOK）の観点から学習し、要求分析プロセスを理解させる。その上で、ソフトウェア開発の現場における仕様の問題についても確認させる。

②共通フレームにおけるソフトウェア開発にかかわる主要プロセス、アクティビティを知り、要件定義には事業要件定義、業務要件定義、システム要件定義の違いを確認する。

①ISO/IEC 12207(JIS X 0160)の目的と共通フレームとの関係を策定された背景を通じ理解させる。開発プロセスのソフトウェアライフサイクルモデ
ルであるウォーターフォールモデルに対する適用箇所を確認し、要件定義の位置付けを理解させる。

①共通フレーム2013 ②共通フレームにおける要件定義 ③REBOKの知識体系

共通フレームの目的と要求定義の重要性を説明できるようになる。要求と仕様それぞれが何なのかを説明できるようになる。

共通フレームの元となったISO/IEC 12207(JIS X 01609の目的や、共通フレームの概要について取り扱う。要求とは何かを理解し、要求仕様書における要求と仕様（機能要求／非機能要求）との関係を理解する。要求仕様を共有するための知識共有の方法についても取り扱う。

内容

コマシラバス（90分授業コマ単位のシラバス）

キーワード：共通フレーム、要件定義、要求工学知識体系（REBOK）、要求分析、ステークホルダー、要求、仕様、機能要件、非機能要件、知識共有、機能分割、構成分割、共通分割、時系列分割、UML、ユースケース、画面遷移図

・『要件定義・アーキテクチャ設計』
pp.5-54

教材・教具

科目概要：要求を正しく抽出し仕様化することは、システム全体の品質を高めることにつながる。USDM表記法はさまざまな要求定義手法のデメリットを吸収するものであり、後戻りも少ない開発を実現することができるものである。本科目ではUSDM表記法を在宅介護サービス支援システムをベースとした演習によって、その記述方法を修得する。

科目主題：本科目の主題は、ソフトウェア要求工学の歴史をふり返り、共通フレームにおける要件定義プロセスの位置付けを確認したうえで、USDM表記法を用いて「要求」から「仕様」を抽出し、USDM記述が出来るようになることである。、

科目趣旨：プロジェクトの成功の秘訣は、要求仕様書の明確化にあることは、各種の調査結果で報告されている。しかし「何をどのように書けば良いのか」を具体的に記述したガイドはほとんどないのが現状である。独立行政法人 情報処理推進機構（IPA）が提唱する共通フレーム2013における表銃的な要求定義を軸に、「仕様が漏れない要求仕様」をどのような点を注意し、書けばよいのか、株式会社システムクリエイトの清水吉男が提唱するＵＳＤＭ（Universal Specification Describing Manner）という具体的な表記法を習得する。要求
定義および要求仕様書に潜む問題点を理解した上で、要求を仕様化する際の考え方、整理すべき点、注意すべき点などを中心に演習を行う。また、非機能要求の重要性と定義方法理解し、USDMへの仕様化を行う。演習は架空のサービスである「在宅介護サービス支援システム」をもとに、ユーザーの要求は何か、要求に裏に潜む背景や理由を分析・抽出し仕様化する方法を実践する。

科目名：要件定義 シラバス

3.2. コマシラバス

■要件定義

18

3

2

細目レベル

5キーワード

復習・予習課題

USDM表記法を使用した要求仕様書の作成①（在宅介護サービ 3_ 4
ス支援システム）

3_ 5

3_ 6

シラバスとの関係

3_ 1

到達目標

復習・予習課題

2_ 6

コマ主題細目

5キーワード

2_ 5

3_ 3

細目レベル

コマ主題細目

2_ 3

2_ 4

到達目標

2_ 2

3_ 2

要求仕様の定義方法

シラバスとの関係

2_ 1

復習：本コマで演習した要求と仕様の組み合わせ以外に、在宅介護サービスシステム仕様書からさらに３つの要求と仕様の組み合わせを適切に抽出しUSDMフォーマットで表記しておくこと。また、非機能要求を２つ抽出しUSDMフォーマットで表記しておくこと。
予習：画面仕様をUSDMで表現するにはどうすればよいかをテキストを読んで理解しておくこと。在宅介護サービス支援システムの画面イメージをもとに、どれか１つの画面仕様書を作成しておくこと。

①説明 ②機能分割 ③構成分割 ④共通分割 ⑤時系列分割

・『要件定義・アーキテクチャ設計』②理由に要求が混在する例を参考に、①で抽出した要求と理由のレビューをさせる。その中で必要ならば補足説明を付けることの重要性も合わせ
pp..93-108て理解させる。
・在宅介護サービス支援システム仕様書③要求仕様書は、それ自体が明確な思想の下に整理されており、仕様全体がどのように構成されているか階層化のイメージを持たせる。分割の方法として、機能で分割する方法、構成で分割する方法を例を用いて説明する。また、要求の範囲にも注意をさせ、適切な粒度となるように階層化が煩雑になることを防止させる。ここでは階層化をすすめるとしてもせいぜい３階層までとさせる。分割方法の代表例として、これらの他に共通分割
や時系列分割があることを理解させる。

①要求にはそれが存在する理由があり、上位要求と下位要求を含むすべての要求について明示すること。これによって要求の背後にある理由を探ることができるということを理解させる。また、仕様とは要求を満たすための具体的な振る舞いの記述（２コマ目）であることを復習し、要求と仕様を明確にしUSDMにおける表記法を確認させる。実際にUSDM表記法を使って、在宅介護サービス支援システムの企画をもとに要求とその理由を抽出させる。

①要求から理由を探る ②理由に要求が混在する場合 ③要求の階層化と分割基準要求から仕様を抽出することができるようになること。また基準をもとに要求を分割したりグループ化したりすることができること。

USDM表記法での要求と理由の表記方法を理解させる。要求を上手く表現するには、要求に含まれる振る舞いに着目し、要求の背景までを掘り下げて抽出することが重要である。また、要求から仕様を導き出し、必要に応じて分解・組み合わせを行う基準について理解させる。

復習：要求と仕様とはどのように違うかを説明できるようにしておくこと。その際、仕様については機能要求と非機能要求との違いについて分類できるようにしておくこと。要求と仕様はUSDM表記法でどのように表現するのかを復習しておくこと。
予習：在宅介護サービスシステム仕様書から、要求と仕様のセットを５つ抜き出しておくこと。

①要求 ②仕様 ③機能要件 ④非機能要件 ⑤知識共有

・『要件定義・アーキテクチャ設計』
pp.55-92
・非機能要求グレード（情報処理推②要求には機能要求と非機能要求があり、特に非機能要求の重要性や定義方法を理解させる。非機能要求をUSDMで表記するために、機能要求進機構 IPA）の表記方法とどのように違うかを実際のUSDMフォーマットを確認させて理解させる。
・セキュリティ実装チェックリスト（IPA）③要求仕様書を記述する担当者は誰が適切かを説明し、知識共有の観点から起こり得る問題点を図表３－２（知識共有の状態）を用いて、ケースごとに分析させる。受講者の現場において知識共有がどのようになされているかを考えさせ、どのようなケースで対応するのが望ましいかを確認させる。

①要求には、それが存在する「理由」があり、仕様とは「要求を満たすための具体的な振る舞いの記述」であることを理解させる。仕様はトレーサビ
リティの実現される必要があり、これらを的確に記載することによって得られるメリットは何であるかを理解させる。

①要求と仕様の違い ②非機能要求の対応

USDM表記法の特徴を説明できること。また、要求と仕様の違いや要求から仕様を導き出すプロセスについて説明できること。

要求仕様書を作成する上で、USDM表記法を使用することによって得られるメリットを理解させる。要求と仕様の違いを理解し、要求を達成することで高品質なシステムを提供できることを確認する。

19

4

USDM表記法を使用した要求仕様書の作成②（在宅介護サービ
ス支援システム）

5キーワード

復習・予習課題

4_ 5

4_ 6

コマ主題細目

4_ 3

細目レベル

到達目標

4_ 2

4_ 4

シラバスとの関係

4_ 1

復習：演習で取り扱った画面仕様書をUSDM表記法で記載すること。在宅介護サービス支援システムの画面全体設計を行うこと。

①UML ②ユースケース ③粒度 ④トレーサビリティ ⑤画面遷移図③画面仕様を進めるときに、画面全体要求から画面全体の要求仕様、個別画面設計、個別画面仕様といったプロセスで要求定義することを理解させ、全体の画面遷移図に付与されたIDとUSDM表記法とのトレーサビリティの確保の方法を理解させる。

②一般的な画面仕様のイメージを用いて、仕様の漏れの恐れがある箇所を発見させる。次にUSDMによる画面仕様の例を見せ仕様漏れが少なくなることを理解させる。このとき、GUI画面上のオブジェクトの状態に着目させ、一般的な画面仕様書では表すことが難しい仕様がUSDMであれば、どれくらい利点があるかを理解させる。

様書①ユースケースは要求に対応させることができ、USDMに移行しやすいことを理解させる。UMLによる要件定義ではシナリオ（いわゆるフローチャー ・『要件定義・アーキテクチャ設計』
ト）が発生しやすく要求を見落とす可能性が高いことを理解させる。その他にも、ユースケースの粒度が小さくなると、振る舞いを見落とす可能性もpp.109-127
あり、USDMがUMLよりも優位性があることを理解させる。
・在宅介護サービス支援システム仕①ユースケースとの関連性 ②画面遷移図と全体に対する要求 ③個々の画面に対する要求

UMLのユースケースからUSDMの要求と仕様に移行できるようになること。個々の画面遷移図の機能をUSDMで記述できるようになること。

オブジェクト指向によるソフトウェア開発におけるUSDMの適用方法や画面仕様を表現するにはどうすればよいかを理解させる。USDMで要求定義するプロセスとしてビジネス要求からシステム要求に発展させシステム仕様化するプロセスを理解させ、特に画面仕様については全体の画面遷移から個別の画面遷移に落とし込む方法を複数のUSDMでどのように関連させるか（特に画面オブジェクトの状態に着目させる）を理解させる。

1

90分/コマソフトウェア工学とソフトウェア
品質モデル

コマ主題

20
復習・予習課題

細目レベル

1_4

1_6

コマ主題細目

1_3

5キーワード

到達目標

1_2

1_5

シラバスとの関係

1_1

コマシラバス項目

次コマの予習課題：
SWEBOKの体系を参照して、そこに含まれる複数の領域が、具体的にどのような実務と関連しているかをリストアップしておく。

今コマの復習課題：
IEEEにおけるソフトウェア工学の定義を踏まえ、ソフトウェア工学の目的に関する考え方を整理する。さらに、ソフトウェア工学の目的と照らしてSWEBOKの体系にソフトウェア品質が含まれていること、ソフトウェア
品質の体系性について整理しておく。さらに、保守性品質とソースコードの具体的な属性の関係を、ソース
コードを確認しながら再度確認しておく。

①ソフトウェア工学 ②ソフトウェア品質モデル ③属性 ④品質特性 ⑤保守性

④様々な品質特性の中から〈保守性〉に着目し、モジュール強度、モジュール結合度といったソースコードの属性が、どのように〈保守性〉に関与するのか、ソースコードのサンプルをもとに解説する。

③ISO/IEC 9126に基づき、ソフトウェア品質モデルについて解説する。ソフトウェアが存在する局面ごとに、〈利用時の品質属性〉、〈外部品質属性〉、〈内部品質属性〉、〈プロセス品質属性〉といった属性が想定できること、および、各属性が機能性、保守性といった品質特性と関係していることについて解説する。

②SWEBOKを参照し、ソフトウェア工学の知識体系の全体像について解説する。とくに、ソフトウェア品質に関する項目が含まれていることに着目し、ソフトウェア工学の目的とソフトウェア品質の間の密接な関連性について解説する。

①ソフトウェア工学について、どのような目的をもった学問であるか、IEEEの定義や参考文献を参照しながら解説する。純粋に科学的見地から工学的原理をソフトウェアの製造過程に適用するという考え方から、科学的に一元的な判断を否定し、ベストプラクティス程度を目ざすという考え方まで、ソフトウェア工学の考
え方には一定の幅が存在することを解説する。

①ソフトウェア工学の目的 ②ソフトウェア工学の知識体系 ③ソフトウェア品質モデル ④〈保守性〉品質

ソフトウェア工学の目的と知識体系の全体像と関連させながら、ソフトエア品質モデルの必要性、代表的なソフトウェア品質モデルの構造（品質属性と品質特性の関係等）、代表的なソフトウェア品質特性について説明できるようになる。

ソフトウェア工学の目的と知識体系を踏まえたうえで、ソフトウェア品質モデルについて扱う。

内容

コマシラバス（90分授業コマ単位のシラバス）『要件定義・アーキテクチャ設計』
pp.7-16, pp.173-196

教材・教具

キーワード：ソフトウェア工学、ソフトウェア品質モデル、共通フレーム2013、アーキテクチャ設計、CMU/SEIアーキテクチャ手法群、品質特性シナリオ、品質要求、アーキテクチャドライバ、品質特性駆動型設計、モジュール分割

科目概要：ソフトウェア工学、ソフトウェア品質モデル、ISO/IEC 12207に対応した共通フレーム2013を踏まえたうえで、アーキテクチャ設計に関する基礎的な概念、一般的な留意事項、主要な方法論を解説し、さらに品質特性駆動型設計をとりあげ、その概念および方法論を詳説したうえで、仮想的なプロジェクトを設定した演習を通して、品質特性駆動型設計の適用について学習する。

科目主題：本科目の主題は、品質特性駆動型設計およびその周辺の関連技術である。

科目趣旨：ICTの普及に伴い、これまでに様々なシステム開発が行われてきたが、途中で頓挫したり、想定外のコストが生じたり、トラブルに見舞われる開発プロジェクトも決して少なくなかった。そのようなトラブルの要因として、主に、要件定義に要求漏れや不明瞭な定義が含まれていること、アーキテクチャが要件を充分に満たすものではないこと等が指摘されている。本科目では、このうち、アーキテクチャを設計するために必要な基礎的概念や留意事
項、一般的な方法論について取り扱う。

科目名：アーキテクチャ設計 シラバス

■アーキテクチャ設計

21

2

共通フレーム

復習・予習課題

細目レベル

2_4

2_6

コマ主題細目

2_3

5キーワード

到達目標

2_2

2_5

シラバスとの関係

2_1

次コマの予習課題：
共通フレームに含まれるシステム方式設計とソフトウェア方式設計について、前後のプロセスを踏まえて、どのような実務が求められるかを検討しておく。

今コマの復習課題：
ソフトウェアライフサイクル、ソフトウェアライフサイクルモデル、ソフトウェアライフサイクルプロセスという3つの概念のそれぞれの意味と関係について再確認しておく。そのうえで、ソフトウェアライフサイクルプロセスの概念と関連させて、ISO/IEC 12207および共通フレーム策定の背景および目的を再確認しておく。最後に、共通フレームの設計思想である４つの階層のそれぞれの役割について再確認しておく。

①ソフトウェアライフサイクル ②ISO/IEC 12207 ③共通フレーム④要件定義 ⑤方式設計（アーキテクチャ設計）プロセス④共通フレームの中で、システム開発プロセスのサブプロセスとして、システム方式設計プロセスとソフト
ウェア方式設計プロセスがあり、これらがアーキテクチャ設計に該当することについて解説する。

③まず、共通フレーム策定の背景として、コミュニケーションチャネルの複雑さ、用語とその意味内容の不統一、役割分担の不明確、ステークホルダ間での合意欠如・合意不十分の問題、見積りの問題、仕様変更のルールの不備、情報システムの信頼性向上の問題、業務全体を対象範囲として捉えられていない問題といった問題があることを解説する。さらに、共通フレームの適用範囲にハードウェアの開発が含まれな
いこと、共通フレームの設計思想として、4つの階層（事業、業務、システム、ソフトウェア）の区別があり、それぞれの階層に応じて、要件定義も事業要件定義、業務要件定義、システム要件定義というように多層化することについて解説する。

②ISO/IEC 12207策定の背景として、ソフトウェアライフサイクルプロセスに関して世界共通の認識を成立させ(ソフトウェアライフサイクルプロセスの標準化)、開発の発注側と受注側の間で必要な作業に関する認識を一致させるという目的があったことについて解説する。さらに、ISO/IEC 12207に基いて国内で策定差入れた規格が共通フレームであることについて解説する。

①ソフトウェアライフサイクル、ソフトウェアライフサイクルプロセス、ソフトウェアライフサイクルモデルといった概念について、SWEBOK、ISO/IEC 12207を参照しながら、その意味について解説する。その上で、開発技法、プロセス-アクティビティ-タスクの関係、具体的な開発方法論の一般的な構成について解説する。

①ソフトウェアライフサイクル ②ISO/IEC 12207と共通フレーム ③共通フレームの設計思想④アーキテクチャ設計の位置づけ

共通フレームの目的、共通フレームとソフトウェアライフサイクルモデル・ソフトウェアライフサイクルプロセスとの関係、具体的な開発方法論の構成について説明することができる。また、共通フレームの設計思
想、共通フレームにおけるアーキテクチャ設計の位置づけについても説明することができる。

ソフトウェアライフサイクルプロセスに関する国際規格であるISO/IEC 12207に対応した共通フレームの概要について扱う。

『要件定義・アーキテクチャ設計』
pp.17-59

223

品質特性駆動型設計

復習・予習課題

細目レベル

3_4

3_6

コマ主題細目

3_3

5キーワード

到達目標

3_2

3_5

シラバスとの関係

3_1

次コマの予習課題：
品質特性シナリオの作成から、機能性をもったモジュール分割までの手順について、具体的なソフトウェア
設計の事例を想起しておく。

今コマの復習課題：
アーキテクチャ設計に求められる構造とビューについて、具体例の参照も踏まえて何を意味するものか再確認しておく。CMU/SEIアーキテクチャ手法群によるシステム品質特性の概念について全項目をチェックしておく。また、品質特性の一般シナリオの内容、および、モジュール分割までの手順を再確認しておく。

①システム品質特性 ②品質特性シナリオ ③刺激・刺激源・応答 ④品質特性駆動型設計⑤モジュール分割⑤アーキテクチャドライバを選択し、アーキテクチャパターン（実現手法の組み合わせ）を選択する、モジュールに機能性を割り当てるという手順によって、機能性を備えたモジュールまで分割するという手順について解説する。

④アーキテクチャドライバはアーキテクチャを「方向づける」機能要件 と品質要件の組み合わせであることを踏まえた上で、品質特性駆動型設計が、与えられた品質特性の具象シナリオから、システムが満たさなければならない品質特性を把握し、それを元にシステム全体をモジュールに分割していく手法であることを説明する。

③要件定義の中で発見される、非機能要件のうち、この品質特性に関する要求である品質要件を表現する１つの方法として、シナリオを用いる方法（品質特性シナリオ）があることを説明する。さらに、シナリオの構成要素（刺激、刺激源、環境、成果物、応答、応答測定法）について説明し、品質特性の一般シナリオの
うち、とくに変更容易性の一般シナリオをとりあげ、詳しく解説する。

②CMU/SEIアーキテクチャ手法群の概要（成立、構成等）について説明する。そのうえで、CMU/SEIアー
キテクチャ手法群によるシステム品質特性概念について解説する。システム品質特性として、可用性、変更容易性、性能、セキュリティ性、テスト容易性を取り上げ、それぞれを簡略的に説明する。

①アーキテクチャ設計について、ソフトウェア工学における定義では、機能要件、非機能要件などからなるシステム要求仕様書を基に、プロジェクト上の制約や開発組織の状況などを考慮した上でシステムの動的/静的構成を設計し、システム構成要素の役割や振る舞いを明確化し、システム設計書としてそれらを書き起こすことという一般的な定義について解説する。さらに、アーキテクチャ設計は、構造とビューから構成されること、構造には、モジュール構造、コンポーネント＆コネクター構造、割り当て構造があり、それぞれUMLの各ダイアグラムをビューとして表現が可能であることを解説する。

①アーキテクチャ設計 ②CMU/SEIアーキテクチャ手法群とシステム品質特性 ③品質特性シナリオ④品質特性駆動型設計 ⑤モジュール分割

CMU/SEIアーキテクチャ手法群に含まれるシステム品質特性概念を踏まえたうえで、要件定義から品質
特性シナリオを作成し、モジュール分割を行うまでの一通りの手順について説明できる。

CMU/SEIアーキテクチャ手法群に含まれる品質特性駆動型設計によるアーキテクチャ設計方法について扱う。

『要件定義・アーキテクチャ設計』
pp.156-172, pp.197-260

23

4

演習

復習・予習課題

細目レベル

4_4

4_6

コマ主題細目

4_3

5キーワード

到達目標

4_2

4_5

シラバスとの関係

4_1

今コマの復習課題：
具体的なソフトウェア開発の事例に、品質特l性シナリオの作成から機能性をもったモジュール分割までの手順を適用してみる。

①システム品質特性 ②品質特性シナリオ ③刺激・刺激源・応答 ④品質特性駆動型設計⑤モジュール分割④完成したモジュール分割（機能性を備えたモジュール）に基づき、さらにクラス図作成を行わせる。これはアーキテクチャ設計ではなく、詳細設計になるが、作成したアーキテクチャの効果を検証するという意味
で、研修内でこの作業も行わせる。最後にクラス図による一定の設計例を提示し、解説を行う。

③選択されたアーキテクチャドライバに基いて、最初のモジュール分割を行わせる。この段階で一定の回答例を示し、解説する。さらにUSDMに記載された機能要件を割り当て、機能性を備えたモジュール分割まで行わせる。これもまた一定の回答例を示し、解説を行う。

②USDMによる要求仕様書に基づき、品質特性シナリオの作成演習を行う。テキストとは別に記入用紙を用意し、アーキテクチャドライバを選択した上で、品質特性シナリオの記述を行わせる。用紙ではなく、
Excelを利用してもよい。一定の作業時間をおいた後で、回答例を示し、解説する。

①訪問介護事業を運営する株式会社からの発注を受け、「在宅介護サービス支援システム」を開発するという演習の題材である仮想プロジェクトの背景について説明する。その上で、その企業が抱える業務上の課題を示し、さらにUSDMによる要求仕様書（機能要求、非機能要求を含む）を提示する。

①介護業務のIT化という課題の提示 ②品質特性シナリオの作成 ③モジュール分割 ④クラス図作成

小規模な開発プロジェクトのモデルに対して、品質特性駆動型設計の方法論を適用し、モジュール分割までの作業を実行することができる。

仮想的な開発プロジェクトに品質特性駆動型設計の方法論を適用し、実際にアーキテクチャ設計を行うことを通して、品質特性駆動型設計の方法論についての理解を深める。

『要件定義・アーキテクチャ設計』
pp.278-314

3.3. 理解度確認テスト■要件定義
平成 28 年度「成長分野等における中核的専門人材養成等の戦略的推進」事業
地域 IT 産業振興のための IT アーキテクト育成事業
実証講座 ２０１７年２月３日（金）ソフトウェア開発における要件定義の方法 スキルチェック（解答）１

次の文章のうち間違っているものを選びなさい。
（ア）

要求の範囲が大きいままであれば仕様の抽出モレが生じる。

（イ）

要件開発では、要求の気づき方だけでなく、要求や仕様をどのように表現するかについて注意を払う必要がある。

（ウ）

要求仕様を作り込むことによってソフトウェアのバグは完全にな
くなる。

（エ）

ウ

仕様の把握が曖昧で、その記述も不適切な状態のまま開発をすすめると、すでに選択されたデータ構造やアーキテクチャでは対応できないことがある。

２

次の文章のうち間違っているものを選びなさい。
（ア）

要求仕様の提示を適切に行うことで、予算を超過も品質の確保にも効果がある。

（イ）

納期遅延の理由は、開発規模の増大やチーム能力の不足が最大の理
由である。

（ウ）

納期遅延を解消するためには、要求仕様書を明確に作成することが

イ近道である。
（エ）

ソフトウェア開発の発注者としての反省点として最も多いのは、「システム仕様の定義が不十分のまま発注してしまった」というこ
とである。

３

要求仕様書を適切に作成することで得られるメリットとして正しいものをすべて選びな
さい。
（ア）

仕様から設計、プログラミングのトレースが的確になり、仕様変更

アが入っても、それに対応するための工数が少なくなる。

イ

24

（イ）
（ウ）

テストケースの洗い出しがより適切にできるようになり、テスト実

ウ

施効率が向上する。

エ

ベンダー側のリスクが減少する。それに伴いベンダーの開発費用の見積りがより適切なものとなる。

（エ）４

納期遅れのリスクが減少し、品質の向上も期待できる。

次の文章のうち間違っているものを選びなさい。
（ア）

要求は「実現したいことのゴール」である。

（イ）

要求は情報システムを開発する場合に「仕様」を導き出す非常に重要なものである。

５

６

ウ

（ウ）

要求は「範囲」をなるべく見せないように表現する必要がある。

（エ）

機能的要求は「振る舞い」と表現することができる。

次の用語と説明の組み合わせのうち間違っているものを選びなさい。
（ア）

時系列分割 － 時間軸に着目して要求を分割する（イ）

構成分割 － 順序性を持つ機能や構成によって要求を分割する。

（ウ）

状態分割 － 状態という概念で要求を階層化する（エ）

共通分割 － 共通する機能を取り出して独立させる

イ

次の文章のうち間違っているものを選びなさい。
（ア）

要求には理由がある。上位要求および下位要求を含むすべての要求について明示することで、しっかりと仕様を捉えることができる。

（イ）

仕様とは要求を満たすための具体的な振る舞いの記述であり、仕様は必然的にいずれかの要求に属す。

７（ウ）

仕様はプログラムのコードに変換され検証することができる。

（エ）

要求はプログラムのコードに変換され検証することができる。

エ

次の用語と説明の組み合わせのうち間違っているものを選びなさい。
（ア）

USDM 表記法では要求と仕様にそれぞれ要求番号と仕様番号をつけてトレーサビリティを実現している。

（イ）

要求仕様書とは、要求と仕様を別々に記述したものである。

（ウ）

たとえば、ユーザ要求は上位要求とし、機能要求は下位要求として考えることができる。

（エ）８

トレーサビリティを確保することで保守性が向上する。

次の用語と説明の組み合わせのうち間違っているものを選びなさい。

25

イ

（ア）

USDM 表記法では、非機能要求も機能要求と同じように表現することができる。

（イ）

USDM 表記法における説明欄には、単なる付加情報ではなく、その後の設計担当者にとって有意義な情報を記載する。

（ウ）

仕様を的確に記載されていると、仕様漏れや仕様間の矛盾、仕様のイ

衝突などを発見できる。
（エ）

USDM 表記法における説明欄に記載された情報を利用するかしな
いかは、後で設計する担当者が自由に決めることができる。

９

次の文章のうち間違っているものを選びなさい。
（ア）

適切に要求仕様を作成しておけば、SE の知識が不十分であっても問題は発生しない。

（イ）

ユーザと SE との間で必要な知識を共有しているという事実を、さらに共有していれば、知識共有の問題は解決している。

（ウ）

ユーザと SE 双方の理解と認識を確認する方法として、表出によっ

アて理解／認識している内容を表現してもらう方法が望ましい。
（エ）

ユーザと SE との間に要求仕様書上に書かれた言葉と暗黙のルール
について、共通の理解と認識を持つことが望ましい。

１０

１１

要求仕様書に求められる品質のうち、間違っているものを選びなさい。
（ア）

粒度の統一性（イ）

主観的な記述（ウ）

先行文書との関係性（エ）

漏れ／抜け、矛盾、重複の発見容易さイ

検証（レビュー）時に要求仕様書に求められる品質のうち、間違っているものを選びな
さい。

１２

（ア）

任意の事柄に関係する要求仕様を一覧にできること（イ）

要求の裏側にある「理由」を記述できること（ウ）

検証済みかどうかの状態の管理が可能であること（エ）

文書を修正しやすいこと

エ

非機能要求に含まれるものとして、間違っているものを選びなさい。
（ア）

データ出力

（イ）

安全性

（ウ）

サービス提供時間

ア

26

（エ）
１３

セキュリティ

次の文章のうち間違っているものを選びなさい。
（ア）

非機能要求を定義する目的は「システム強度」を確保することである。

（イ）

すべての非機能要求は定量（具体的な数値目標）評価されるように
する。

（ウ）

非機能要求は、ユーザ部門やシステム・オーナーの合意を得た上でイ

IT 部門が記述することが妥当である。
（エ）

非機能要求は、システム稼働開始後の安定稼働に責任を持つシステ
ム運用部門とも合意しておく必要がある。

１４

次の文章のうち間違っているものを選びなさい。
（ア）サービス提供時間はベストエフォートを目指すべきである。

（イ）デリバリータイムとは、ユーザが入力情報を入力し終わってから、特定の担当者の手元に適切なアウトプットが届くまでに要する作
業時間全体をいう。

（ウ）

レスポンス・タイムとは、オンラインでデータなどを入力してから、

ア

結果が出力され始めるまでの時間をいう。
（エ）

サービス・レベルに関する要求は、コンピュータに対するユーザの期待を表すもので、これに応えることは、単純にコスト面から考えても容易ではない。

１５

システムの安全性の要素について、間違っているものを選びなさい。
（ア）

機密性とは、情報にアクセスすることを認可されたものだけがアクセスできることを確実にすることである。

（イ）

安全性とは、情報及び処理方法の正確さ及び完全である状態を安全防護することである。

１６

（ウ）

可用性とは、障害が発生した場合に迅速に復旧できることである。

（エ）信頼性とは、故障が起こりにくく正常に稼働していることである。

ウ

次の文章のうち間違っているものを選びなさい。
（ア）

要求を上手く表現するには、振る舞いに含まれる動詞をすべて表現することを目指す。

（イ）

ウ

理由に要求が混在していることがある。理由に要求の必要性と実現

27

したいことが記述されており、見直しが必要である。
（ウ）

要求に対して適切な理由が付かない場合は、要求として認められな
い。

（エ）
１７

要求に付随する理由は、必ずしも１つとは限らない。

次の文章のうち間違っているものを選びなさい。
（ア）

USDM 表記法では、仕様には☐（チェックボックス）の記号を用い、仕様として識別できるようにしている。

（イ）

USDM 表記法では、仕様には□（チェックボックス）の記号を複数用いることができる。

エ（ウ）

要求仕様書に書かれた説明は、用語集への展開が期待される。

（エ）

USDM 表記法では、できるだけ図や表を用いず、伝わりやす文章を記述することに努める。

１８

次の文章のうち間違っているものを選びなさい。
（ア）

要求仕様書全体をどのように構成するかを検討し、要求を階層化して個々の要求の範囲を狭めて仕様を引き出すようにする。

（イ）

品質要求を階層化する場合、下位要求の持つ範囲の合計が上位の要求の求める範囲と一致する。

（ウ）

要求の階層の深さは２層程度にとどめておく。深くなると煩雑にな

イ

り階層化のメリットが薄れる。
（エ）

要求の粒度のバラツキから、仕様が増加すると要求の範囲を狭めた
メリットが薄れるため仕様のグループ化を検討することが重要である。

１９

次の文章のうち間違っているものを選びなさい。
（ア）

一般に画面仕様における、表示領域やボタンなどに対する仕様は項
目の説明に過ぎないケースが多く、仕様モレにつながりやすい。

（イ）

画面に配置されるボタンなどは、押下するタイミングや動きなど、さまざまな状態について仕様を表現することが重要である。

（ウ）

画面仕様を上手く表現するには、個別画面の配置図のページに、画面の構成要素ごとに要求と仕様を表現する。

（エ）

画面全体に対する要求を確認するタイミングは仕様を抽出する必
要がない。

２０

次の文章のうち間違っているものを選びなさい。

28

エ

（ア）

シナリオ要求の場合、機能が重複しないように手順を考えて要求を
抽出する。

（イ）

機能要求には単独の機能要求と、シナリオ的機能要求の２種類がある。

（ウ）

ユースケースを扱う場合、ユースケースを上位要求として捉え、シア

ナリオを階層化した下位要求として扱えば上手く収まる。
（エ）

状態遷移図を扱う場合、振る舞いを漏れなく表現することで要求を抽出できる。

■アーキテクチャ設計
平成 28 年度「成長分野等における中核的専門人材養成等の戦略的推進」事業
地域 IT 産業振興のための IT アーキテクト育成事業
実証講座 ２０１７年２月９日（木）ソフトウェア開発におけるアーキテクチャ設計の方法 事前スキルチェック
１

次の文章のうちアーキテクチャ設計を行う事で期待出来る効果として間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）

アプリケーションの全体構造や、データ構造が明確化、そして言語化される事で、利害関係者の共通言語が出来るため効率的なコミュ
ニケーションを行うことが出来る。

（イ）

外部とのインタフェースが定義され、アプリケーションの担う責務の範囲が明らかとなる事で、過不足がない開発が可能となり、また外部システムとの接続を容易に行うことが出来る。

（ウ）

実装をするコンポーネントのインタフェースや、役割などが明らか

ウとなる為、実装の段階で必要な情報を全て洗い出す事が可能とな
り、実装時に生じるバグを完全に防ぐ事が出来る。
（エ）

アプリケーションの全体構造が明らかとなることで、早期の段階で必須項目の抜け漏れなどの問題を発見することが可能となり、実装段階になってからの手戻りなど大きな追加工数が必要となるような変更を避ける事が出来る。

２

次の文章のうち、アーキテクチャの成果物において期待される事柄として間違っているものを全て選びなさい。
（ない場合は該当なし）
29

（ア）

システム要件を実現するための責務が、ハードウェア、ソフト
ウェア、
手作業に振り分けられ、また、それを実現するためのハードウェア構成品目、
ソフトウェア構成品目が明確となっていること。

（イ）

全てのシステム構成要素（ハードェア構成品目、ソフトウェア構成品目）が適切なサブシステムに分割されており、それぞれの役
割や構造、必要となる性能・セキュリティ属性が明らかとなって

エ

いること。
（ウ）

システムアーキテクチャの候補案が、評価・考察され、技術的・費用的なトレードオフおよびリスク分析がなされていること。

（エ）

実装を行う言語は何か、データベースは何を使うのかと言った開発可能なレベルまで詳細化・具体化された仕様が完成しており、それぞれの利害関係者からの承認を得ていること。

３

アーキテクチャにおける「構造」と「ビュー」に関する文書として正しいものをすべて選びなさい。
（ない場合は該当なし）（ア）「構造」とはアーキテクチャをある視点から捉える切り口で、「ビュー」はそれを人が理解出来る形で表現するもの。

（イ）「モジュール構造」は、ソフトウェアアーキテクチャの動作時の振る舞いを捉える為の構造。

（ウ）「割り当て構造」は、システム環境など非ソフトウェア構造との関連を捉えるための構造。

（エ）

ア、ウ

「コンポーネント＆コネクター構造」は「分割構造」、「使用構造」、「レイヤー構造」などからなるシステムの静的な側面を捉えるための構造。

４次のうちソフトウェアアーキテクチャを表す「割り当て構造」が表すべき内容として間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）

各ソフトウェア要素はどのプロセッサで実行されるのか。

（イ）

開発、試験、システム構築の間に、各要素はどのファイルに格納さ
れるのか。

（ウ）

開発チームに割り当てるソフトウェアコンポーネントの実装と結エ合に対する責務は何か。
（エ）

主要な実行コンポーネントは何か、そしてそれらはどのように相互作
用するか。

５

以下に示す ISO/IEC 9126-1:2001（JIS X 0129-1:2003）で定義される、ソフトウェア品
質の局面４つのうち「外部品質属性」を測定可能な局面を選びなさい。
（ア）

ソフトウェアが製造される以前に製造工程だけが存在する局面
30

ウ

６

（イ）

ソフトウェアが仕様書、設計図、ソースコードとして存在する局面（ウ）

利用環境を無視してソフトウェアが単独実行される局面（エ）

利用者が特定の環境において実際にソフトウェアを利用する局面

ISO/IEC 9126-1:2001（JIS X 0129-1:2003）で定義される品質特性のうち「信頼性」が持つ品質副特性の組み合わせとして正しい物を選びなさい。

７（ア）

成熟性、障害許容性、回復性、信頼性標準適合性（イ）

成熟性、正確性、機密性、信頼性標準適合性（ウ）

合目的性、障害許容性、機密性、信頼性標準適合性（エ）

合目的性、正確性、相互運用性、機密性、信頼性標準適合性ア

以下の４つの説明文から、ISO/IEC 9126-1:2001（JIS X 0129-1:2003）で定義される品
質特性のうち「機能性」を表す内容を選びなさい。
（ア）

ソフトウェアを指定された条件の下で利用するとき、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。

（イ）

ソフトウェアを指定された条件の下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力（ウ）

ソフトウェアを指定された条件の下で利用するとき、理解、習得、ア

利用でき、利用者にとって魅力的であるソフトウェア製品の能力。
（エ）

修正のしやすさに関するソフトウェア製品の能力。修正は、是正もしくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。

８

CMU/SEI アーキテクチャ手法群で定義されるシステム品質特性の組み合わせとして正しいものを選びなさい。
（ア）

「可用性」
、
「生産性」
、「利用性」、「環境適応性」、
「共存性」

（イ）

「可用性」
、
「変更容易性」、「性能」、「セキュリティ性」、
「テスト容
易性」
、
「使いやすさ」

９

イ

（ウ）

「生産性」
、
「性能」
、
「安全性」、「利用性」、「置換性」、「可用性」

（エ）

「可用性」
、
「性能」
、
「環境適応性」、「共存性」、「安定性」

CMU/SEI アーキテクチャ設計手法群で定義されるシステム品質特性のうち「可用性」を表す説明として正しいものを選びなさい。
（ア）

可用性とは、障害を遮断あるいは修復し、故障なく動作する能力を
表す。

（イ）

可用性とは、要求や環境の変化時に必要な変更コスト・時間が小さい能力を表す。

（ウ）

可用性とは、正当な利用者にサービスを提供しながら、不正利用などの攻撃に抵抗しデータ・情報を保護する能力を表す。

31

ア

（エ）
１０

可用性とは、利用者が必要な作業を容易に達成出来る能力を表す。

CMU/SEI アーキテクチャ設計手法群の品質特性駆動設計において利用される「シナリオ」という概念に関する説明文として間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）

シナリオとは、要求を具体的なストーリーとして記述したもので、利害関係者の意図/興味の表現や、機能要求/品質要求の表現など、様々な用途で使われる。

（イ）

シナリオは、「刺激」、「刺激源」、「環境」、「成果物」、「応答」、「応答測定法」から構成される。

（ウ）

シナリオは、システムに非依存でどんなシステムにも適用出来る

エ「一般シナリオ」と、検討中の特定システムに固有の「具象シナリ
オ」に分類される（エ）

シナリオは、別名「品質特性シナリオ」とも呼ばれ、非機能要求のうち品質特性に関する要求である「品質要求」を表現する為にのみ利用される。

１１

CMU/SEI アーキテクチャ設計手法群において提唱されている「変更容易性の実現手法」の１つとして間違っているものを選びなさい。

１２

（ア）

ピン/エコー（イ）

意味の一貫性（ウ）

既存インタフェースの維持

（エ）

情報の隠蔽

ア

CMU/SEI アーキテクチャ設計手法群において提唱されている「変更容易性の実現手法」のうち「変更の局所化」をサポートする実現手法の組み合わせとして正しいものを選び
なさい。
（ア）

「情報隠蔽」、「既存インタフェースの維持」、「通信経路の制限」、「仲介者の使用」（イ）「変更の一貫性」、「起こり得る変更の予測」、「モジュールの汎化」、「選択肢の制限」、「共通サービスの抽出」（ウ）「実行時の登録」、「構成ファイル」、「ポリモルフィズム」、
「コンポー

イ

ネント交換」、「定義プロトコルの尊守」（エ）「並行性の導入」、「複数のコピーを確保」、「使用可能なリソースの増強」

１３

以下に記す「ソフトウェアパターン」に関する説明のうち間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）

ソフトウェアパターンは「前提」、「課題」、「解決策」の３つの構成から成り立つ。
32

エ

（イ）

ソフトウェアパターンには、その規模（粒度）、抽象度（言語依存度）に応じて「スタイル」、「実装パターン」、「デザインパターン」、「アーキテクチャパターン」などの種類が存在する。

（ウ）

実装パターンとは、特定のプログラム言語において、特定の処理を行う際に頻繁に利用される実装方法をパターン化したもの。

（エ）アーキテクチャパターンとは、「コーディング規約」、「コーディン
グガイドライン」などとも呼ばれ、ソフトウェア開発を共同で行う
際に、実装者間の相互理解のために定められるもの。

１４

次の文章のうちアーキテクチャドライバの説明文として正しいものを選びなさい。
（ア）アーキテクチャドライバとは、アーキテクチャを「方向づける」機
能要求と制約の組み合わせである。

（イ）

アーキテクチャドライバとは、アーキテクチャを「方向づける」機
能要求と品質要求の組み合わせである。

（ウ）

アーキテクチャドライバとは、アーキテクチャを「方向づける」機

イ

能要求と非機能要求の組み合わせである。
（エ）アーキテクチャドライバとは、アーキテクチャを「方向づける」制
約と品質要求の組み合わせである。

１５

次の文章のうち品質特性駆動設計の説明文として間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）アーキテクチャを生成する為に、機能要求と、制約条件、そして一連の品質特性の具象シナリオ（品質要求）を入力として扱う。

（イ）

システムが満たさなければならない品質特性を把握し、それを元にシステム全体をモジュールに分割していく。

（ウ）

アーキテクチャを表現する基本要素としてビューを利用し、ビューを構築する為のパターンやテンプレート及び慣例などを集めたビュー
ポイント(IEEE 標準 1471 に準拠)や、独自提唱しているアーキテクウ

チャパースペクティブを利用する。
（エ）

実装可能なレベルに分割されたサブモジュールにユースケースから機能性を割り当て、それを複数のビューを使用して表現する。最後にモジュール同士のインタフェースと制約条件を定義する事で設計を
進める。

１６

以下の品質特性駆動設計におけるモジュール分割の各ステップを、正しい実行される順
序に並び替えなさい。
「ユースケースと品質シナリオをサブモジュールの制約として検証する」、「分割するモ
33

ジュールを選択する」、「アーキテクチャパターンを選択する」、「アーキテクチャドライ
バを選択する」、「サブモジュールのインタフェースを定義する」、「複数のビューでアー
キテクチャを表現する」
解答

1.「分割するモジュールを選択する」
2.「アーキテクチャドライバを選択する」
3.「アーキテクチャパターンを選択する」
4.「複数のビューでアーキテクチャを表現する」
5.「サブモジュールのインタフェースを定義する」
6.「ユースケースと品質シナリオをサブモジュールの制約として検証する」

１７

ビューを文書化する際に利用される Bass, L が提唱する 7 項目の標準構成の組み合わせ
として正しいものを選びなさい。
（ア）「プライマリプレゼンテーション」、「リソースの構文」、
「コンテキ
スト図」
、
「可変性ガイド」、「論理的根拠と設計上の課題」、
「使用ガ
イド」
、
「その他の情報」（イ）「インタフェースの識別」、「提供するリソース」、「データ型の定
義」、「例外の定義」、「インタフェースによって提供される可変性」、「インタフェースの品質特性」、「要素の要求」（ウ）「プライマリプレゼンテーション」、「要素カタログ」、「コンテキスウト図」、「可変性ガイド」、「アーキテクチャの背景」、「用語集」、「その他の情報」（エ）「使用ガイド」、「例外の定義」、「論理的根拠と設計上の課題」、「イ
ンタフェースの品質特性」、「要素の要求」、「用語集」、「その他の情報」

１８「アーキテクチャを評価する」事に関連をする次の説明文のうち間違っているものを全て選びなさい。
（ない場合は該当なし）（ア）

プロジェクトの規模によっては、そもそも費用対効果を考えると評価を行うべきではないプロジェクトが存在する。

（イ）

アーキテクチャの評価における代表的な手法としては ATAM や
CBAM などが存在する。

（ウ）

アーキテクチャの評価を行うことで、レビューの準備を強制する事
で、アーキテクチャを分かりやすく文書化するモチベーションに繋

該当なし

がる。
（エ）

アーキテクチャの評価を行うことで、アーキテクチャが要求をどれ位満たしているかを議論する事に繋がり、要求自体について議論し直す良い機会となる。

１９

品質駆動設計における「モジュールタイプ」の概念の説明文として正しいものを選びな
34

さい。
（ア）

アーキテクチャパターンにより分割されるモジュールの大局的な分割構造を表す。品質駆動設計における、品質要求をアーキテク
チャ設計の段階から保証する為の重要な概念。

（イ）

品質特性によって分けられる機能要求の分類。各機能がそれぞれの品質特性に分類される事で、アーキテクチャ設計を行いやすくする。

（ウ）モジュール構造においてアーキテクチャを捉える際の、ベストプラ
クティスの集合知。特定のモジュール分割構造を取るアーキテクアチャを持つプロジェクトをどのように表現すればよいかと言う問いに対し示唆を与える。
（エ）モジュールビューを用いて表現される、品質駆動設計のモジュール
分割工程の１サイクルが終わった時点での成果物を表す。次のサイクルにおいて分割を行うモジュールを選択する際に重要な役割を
果たす。

２０

品質駆動設計において成果物であるアーキテクチャを適切に表現するために文書化を行う際、「適切なビューを選択する」上で考慮すべき事として間違っている物を全て選びなさい。
（ない場合は該当なし）（ア）あるアーキテクチャを誰に（who）、何を(what)、どのように(how)
伝えるべきかについて考える。

（イ）

単一のビューで全てのステークホルダーに対応できるような、現在扱うアーキテクチャを表す上で適切なビューを見つけ出す。

（ウ）

候補となるビューを複数選んだ後に、概要しか必要としないビュー
や、ごく少数のステークホルダーにしか役に立たないビューを、より必要性の高いビューに統合する。

（エ）

ステークホルダーによって異なる関心事やバックグラウンドの知識、プロジェクトに対して持つ情報などを考慮してビューを選択す
る。

35

イ

4. 実証講座の内容
4.1. 概要
4.1.1. 目的
本事業は、愛媛県内の情報産業振興に教育的側面から支援を行うものとして、IT アーキ
テクトの育成プログラムを開発するものである。
本年度は、IT アーキテクトの活動に関わる理論・方法論を知識として習得するための「要件定義」と「アーキテクチャ設計」の教育プログラムを開発した。
本事業で開発した「要件定義」と「アーキテクチャ設計」の教育プログラムを用いて、愛媛県内の IT 企業の中堅プログラマーを対象に、実証講座を実施した。
実証講座は、本事業で開発した IT アーキテクトの教育プログラムの有効性を評価することを目的として実施する。

4.1.2. 受講者（１）受講対象
実証講座の対象者は、愛媛県内の IT 企業でシステム開発に携わり、かつ、超上流・上流
工程（要件定義やアーキテクチャ設計）には直接携わった経験がないプログラマーを想定する。
ただし、超上流・上流工程の学習には、高度なプログラミング技術を前提とするため、複数の言語を習得している中堅以上のプログラマーで、将来、IT アーキテクトの業務を希望している者を、実証講座で想定する対象者とする。
（２）告知・募集
実証講座の告知・募集は、「愛媛県情報サービス産業協議会」「愛媛県ＩＴ推進協会」「愛媛ニアショア開発協議会」に協力を依頼し、「地域 IT 産業振興のための IT アーキテクト育成のための実証講座のご案内」を、会員企業に告知いただき、募集を募った。
また、河原電子ビジネス専門学校から、卒業生の就職先企業や求人企業に同案内を送付
し、告知・募集を行った。

36

4.1.3. 実証講座の概要
実証講座は、「要件定義」と「アーキテクチャ設計」の 2 科目を実施した。
図表 1-1-1 実証講座「要件定義」の概要
開催日時

平成 29 年 2 月 3 日（金）10:00-17:00

対象

愛媛県内の IT 企業でプログラミング業務に携わっている方で、将来、IT
アーキテクトの業務を希望している方定員20 名（先着順）

受講料

無料

会場

学校法人河原学園 河原電子ビジネス専門学校〒790-0014 愛媛県松山市柳井町 3 丁目 3-31

講座内容

・要求仕様書に関わる問題と背景
・要求仕様の定義方法
・USDM 表記法を使用した要求定義書の作成（概論）・USDM 表記法を使用した要求仕様書の作成（演習）・理解度確認テストおよびアンケート形式

講義および演習：集合学習担当講師

学校法人河原学園 河原電子ビジネス専門学校 教頭 神馬一博

図表 1-1-2 実証講座「アーキテクチャ設計」の概要
開催日時

平成 29 年 2 月 9 日（木）10:00-17:00

対象

愛媛県内の IT 企業でプログラミング業務に携わっている方で、将来、IT
アーキテクトの業務を希望している方定員20 名（先着順）

受講料

無料

会場

学校法人河原学園 河原電子ビジネス専門学校〒790-0014 愛媛県松山市柳井町 3 丁目 3-31

講座内容

・共通フレーム 2013
・ソフトウェア品質
・アーキテクチャ設計
・アーキテクチャ設計（演習）・理解度確認テストおよびアンケート形式

講義および演習：集合学習担当講師

学校法人河原学園 教務部長 芦澤昌彦

37

4.1.4. 理解度確認テストの概要（１）概要
本実証講座では、講座の開始前と講座の終了後に理解度確認テストを実施した。
（２）目的
講座開始前の理解度確認テストは、講座の進め方の参考情報を収集とすることを目的として実施した。
講座終了後の理解度確認テストは、講座開始前の理解度確認テストの結果と比較することで、テキスト内容および講座内容の効果を測定することを目的としている。
（３）問題
理解度確認テストは、事前と事後で、同じ問題、同じ回答、異なる問題・解答用紙で実施された。

4.1.5. アンケートの概要（１）概要
本実証講座では、講座の開始前と講座の終了後にアンケートを実施した。
（２）目的
講座開始前のアンケートは、受講者の基礎情報を取得することと、講座開始前の理解度
確認テストと同じく講座の進め方の参考情報を収集することを目的として実施した。
講座終了後のアンケートでは、実証講座の有効性等を確認することを目的として、満足度や活用度等の情報を収集した。また、実証講座やテキスト内容の評価に、影響を与えう
る講師や講座環境について、確認のために質問を実施した。

4.2. 実証講座「要件定義」の実施体制
4.2.1. 受講者
受講者の情報は、実証講座の開始前の事前アンケート内で取得した。
ここで取得できた受講者の基礎情報から、実証講座「要件定義」の受講者は、当初に想定していた対象の要件（複数のプログラミング言語を習得している、中堅以上のプログラ
マー）を概ね満たしていることが確認できた。

38

（１）受講者人数
応募定員に 20 名に対して、「要件定義」の受講者は 7 名であった。
（２）受講者の性別
受講者の性別は、男性 6 名、女性 1 名であった。
（３）受講者の年齢
受講者は、25 歳以上 45 歳未満であることから、若年者を除く中堅者が集まっていることが確認できる。
（４）受講者の最終学歴
受講者の最終学歴は、大学学部卒を中心に、高卒、大学中退、大学院卒が集まった。また、大学 4 名の内 2 名は、「情報」関係学科卒であった。
図表 1-2-1 受講者の年齢

図表 1-2-2 受講者の最終学歴

年齢

最終学歴

3

5
4

2

3

1

2

0

1
0

39

（５）受講者の取得資格
受講者は、全員が IT 分野の資格を取得しており、一定の知識を有していることが確認できる。
（６）受講者の習得言語
受講者は、全員がプログラミング言語を習得していることが確認できた。また、受講者 7
名中の 6 名が複数の言語を習得していることが確認できる。
図表 1-2-3 受講者の取得資格

図表 1-2-4 受講者の習得言語

取得資格

習得言語
HTML

基本情報技術者

Java
Java Sclipt

応用情報技術者

SQL

Oracle Java
BronzePHP

Oracle Shilver

C#

CSS
C

Oracle Bronze

COBOL
アセンブラ

CCNA

RubyOnRails
Ruby

LPICレベル1C++
0 1 2 3 4 5 6 7

0

1

2

3

（７）受講者の現在の職種受講者の現在の職種は、プログラマー4 名、SE2 名、その他 1 名であった。

40

4

5

6

（８）受講者の業務内容
受講者の内 6 名が開発を現在の業務としており、テストや設計も兼務していることが確認できる。
図表 1-2-5 受講者の職種

図表 1-2-6 受講者の業務内容

職種

業務内容

4

8

3

6

2

4

1

2

0

0
プログラマ

SE

その他

開発

テスト

設計

その他

（９）受講者の現職の経験年数
現職の経験年数は、3 年から 14 年で平均 8.1 年であることから、概ね中堅以上の受講者であることが確認できる。
（１０）要件定義の経験受講者の内 4 名は要件定義の経験は無いと回答している。また、要件定義の経験者の内 1
名は 2 年以下、1 名は過去に 5 年程度の要件定義の経験があると回答している。
図表 1-2-7 受講者の経験年数

素表 1-2-8 受講者の要件定義の経験

経験年数

要件定義の経験

4
3
2
1
0

5
4
3
2
1
0
経験なし

41

5年以下

不明

4.2.2. 実施内容
（１）講座内容
実証講座「要件定義」は、10:00 から 17:00 の計 6 時間（90 分×4 コマ）、集合形式の講義およびコンピュータを使った実習（演習）で実施された。また、実証講座の開始時および終了時には、アンケートと理解度確認テストを実施した。
図表 1-2-9 実証講座の内容
時間内容

10:00-11:30

・事前アンケートおよび事前理解度確認テスト
・要求仕様書・知識共有の方法

11:30-13:00

・要求仕様の定義方法（USDM 表記法）
・非機能要求の定義方法

13:00-13:50

昼食

13:50-15:20

・USDM を使用した要求仕様書の作成（演習）15:30-17:00

・USDM を使用した要求仕様書の作成（演習）つづき・事後アンケートおよび事後理解度確認テスト

図表 1-2-10 実証講座「要件定義」（午前）42図表 1-2-11 USDM を使用した要求仕様書の作成

図表 1-2-12 USDM を使用した要求仕様書の内容確認

43

4.3. 実証講座「要件定義」の結果
4.3.1. 事前理解度確認テストの結果（１）事前理解度確認テストの正答率
事前の理解度確認テストの結果は、20 問中の平均正答数が 12.3 点（正答率 61.4％）、最高点が 15 点（正答率 75％）
、最低点が 10 点（正答率 50％）であった。
図表 1-3-1 事前理解度確認テストの正答率
正答率
100%
80%
60%
40%
20%
0%
平均

a

b

c

d

e

f

g

（２）事前理解度確認テストの正答率分布
正答率の分布は、60％をピークに 50％から 80％の間で分布されており、正答率が 50％以下の受講者がいなかったことが確認できる。
図表 1-3-2 事前理解度確認テストの正答率分布
正答率の分布
4
3
2
1
0
100%

90%

80%

70%

60%

50%

44

40%

30%

20%

10%

0%

（３）事前理解度確認テストの問題別正答率
問題別の正答率は、20 問中の 4 問が正答率 100％であった。正答率 86％（7 名中 6 名が正答）が 2 問、正答率 71％（7 名中 5 名が正答）が 5 問で、20 問中 11 問が高い正答率であった。
図表 1-3-3 事前理解度確認テストの問題別正答率
問題別正答率
100%
80%
60%
40%
20%

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

0%

１．３．２．事後理解度確認テストの結果（１）事後理解度確認テストの正答率
事後の理解度確認テストの結果は、20 問中の平均正答数が 15.6 点（正答率 77.9％）、最高点が 19 点（正答率 95％）
、最低点が 11 点（正答率 55％）であった。
図表 1-3-4 事後理解度確認テストの正答率
正答率
100%
80%
60%
40%
20%
0%
平均

a

b

c

45

d

e

f

g

（２）事後理解度確認テストの正答率分布
正答率の分布は 80％をピークに 60％から 100％の間で分布されており、受講者の正答率が高いことが確認できる。
図表 1-3-5 事後理解度確認テストの正答率分布
正答率
5
4
3
2
1
0
100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

（３）事後理解度確認テストの問題別正答率
問題別の正答率は、20 問中の 6 問が正答率 100％であった。正答率 86％（7 名中 6 名が正答）が 5 問、正答率 71％（7 名中 5 名が正答）が 4 問で、20 問中 15 問が高い正答率であった。
図表 1-3-6 事後理解度確認テストの問題別正答率
問題別正答率
100%
80%
60%
40%
20%

46

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

0%

4.3.2. 理解度確認テストの比較（１）理解度確認テストの正答率比較
事前と事後の理解度確認テストの正答率を比較すると、平均で 16.4％上昇しており、受講者の内 1 名を除いて 6 名の正答率が上昇していることが確認できる。
図表 1-3-7 理解度確認テストの正答率比較
正答率比較
100%
80%
60%
40%
20%
0%
a

平均

b

c

事前正答率

d

e

f

g

事後正答率

（２）理解度確認テストの問題別正答率比較
問題別の正答率では、20 問中の 13 問で正答率が上昇しており、正答率が 0％の問題がなくなっていることが確認できる。一方で、20 問中 4 問の正答率が下降している。
図表 1-3-8 理解度確認テストの問題別正答率比較
問題別正答率比較

事前

47

事後

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

100%
80%
60%
40%
20%
0%

4.3.3. 事前アンケートの結果（１）自社の要件定義の妥当性・効率性「自社の要件定義は妥当的・効率的に行われていると思いますか？」の設問に対して、全員の回答が「普通」以下の評価であった。
図表 1-3-9 自社の要件定義の妥当性・効率性
自社の要件定義の妥当性等
4
3
2
1
0
十分

やや十分

普通

やや不十分

不十分

（２）講座への期待
本講講座への期待は、3 名が「大」、4 名が「やや大」で、参加者全員が実証講座「要件定義」に期待していることが確認できる。
講座の単元毎の期待は、講座内容１「要求仕様書に関わる問題と背景」のみに「やや小」の回答が見られるが、全体を通して、「普通」以上に回答しており、各単元においても受講者が期待していることが確認できる。
図表 1-3-10 講座への期待
講座への期待5
4

講座内容１の期待3

講座内容２の期待2

講座内容３の期待1

講座内容４の期待
本講座全体の期待

0
大

やや大

普通

やや小

48

小

4.3.4. 事後アンケートの結果（１）講師について
講師の進行スピードは、5 名が「やや速い」と答えている。
講師の教え方は、全員が「普通」以上に回答しており、良い評価が得られている。
図表 1-3-10 講師の進行

図表 1-3-11 講師の教え方

講師の進行

講師の教え方

6
5
4
3
2
1
0

4
3
2
1
0

（２）講座環境について
講座の環境について、1 名が「やや悪い」と解答しているが、全体的に「普通」「やや良い」「良い」に回答が集まっている。また、講座の時間も「普通」を中心に「やや長い」「やや短い」に集まっており、概ね適性に講座が実施されたと考えられる。
図表 1-3-12 講座の環境
図表 1-3-13 講座の時間

講座の環境

講座の時間

3
4

2

3

1

2

0

1
0

49

（３）テキストについて
テキストの分かり易さとテキストの内容（有益性）については、「普通」と「やや分かり易い/やや有益」に評価が集まっている。
図表 1-3-14 テキストの分かり易さ
テキストの分かり易さ
5
4
3
2
1
0

図表 1-3-15 テキストの内容
テキストの内容
6
5
4
3
2
1
0

50

（４）講座の満足度
講座の満足度は、講座内容４の評価に「やや不満」と１名が回答しているが、それ以外
は、「やや満足」を中心に、「普通」以上に回答している。
図表 1-3-16 講座の満足度
講座の満足度
7
6
5
4
3
2
1
0

講座内容１の満足度
講座内容２の満足度
講座内容３の満足度
講座内容４の満足度
講座の満足度
非常に満足 やや満足

普通

やや不満 非常に不満

51

（５）講座の難易度
講座の難易度は、講座内容１に対して 1 名が「ややレベルが低い」に回答しているが、受講者の多くが講座全体および講座内容１から４に「適切なレベル」「ややレベルが高い」に回答している。
図表 1-3-17 講座の難易度
講座の難易度54
3
2
1
0

講座内容１の難易度
講座内容２の難易度

レベルが
低い

ややレベル
が低い

適切な
レベル

ややレベル
が高い

レベルが
高い

講座内容３の難易度
講座内容４の難易度
講座全体の難易度（６）講座内容の活用度
講座内容の活用度は、多くの受講者が講座全体および講座内容の１から４に「やや業務に活かせる」「普通」に回答している。
図表 1-3-18 講座内容の活用度
講座内容の活用度
6
5
4
3
2
1
0

講座内容１の活用度
講座内容２の活用度

52

業務に
活かせない

やや業務に
活かせない

普通

やや業務に
活かせる

業務に
活かせる

講座内容３の活用度
講座内容４の活用度
講座全体の活用度

（７）講座内容とテキストに対する意見■講座内容１「要求仕様書に関わる問題と背景」に対する意見
・要求仕様書に関する基本的な考え方や、重要性を理解するのに役立ったと思います。
・自分がなんとなく感じていた問題について、より具体的に知ることができました。
・業務で実際に起こった問題があり、要求仕様書の必要性を実感しました。
・ユーザの要求エンジニアという点が大きな気づきになりました。
■講座内容２「要求仕様の定義方法」に対する意見
・要求と理由の使い分けが逆になる時があり、難しく感じました。
・USDM についてでしたが、具体例を見るまでは少しつかみにくかったです。
・定義する際の注意点などを再認識することができました。
・あらためて知らなかったことが分かりましました。
■講座内容３「USDM 表記法を使用した要求仕様書の作成（概論）」に対する意見
・自分の書いた文章量が少なく、適切に作成できていなかったと思います。どういったことを記載すればよいか迷いました。
・作成方法がためになりました
・演習しながらの説明でしたので、分かりやすかったと思います。
・終盤は説明が早くて、理解が追いつきませんでしたが、仕様に落とし込む際の注意点などを再認識することができました。
・USDM の使用方法が分かりやすく解説されていて良かったです。
・USDM 自体を使ったことがなかったので、新鮮でした。
・概要を理解する事が出来た。
■講座内容４「USDM 表記法を使用した要求仕様書の作成（演習）」に対する意見・業務に役立てることがありそうです
・ためになりましたが、少し難しかったです・とりあえず USDM を使ってみることができるようになったかと思います。
・実際に体験することで、要求仕様の難しさや注意点などを知ることができました。
・演習時間がもう少し多ければ良かったと思います。
・少し難易度が高めでしたが、基本的なことが良く分かりました。
・演習を行う際の立場、状況、目線を明示して頂きたい。

53

■テキストに対する意見
・重要なところが太字やアンダーラインがあると良かったと思います・１、２、３章あたりの説明は分かりやすかったと思います。6 章で、例を用いて説明されているところはちょっとわかりにくかったです。
・今回の講義時間では短く感じました。演習がもっと多ければ良いと思います。
・品質の高いテキストでした。後で読み返したいと思います。
・ポイントを掴むのが難しかった。
（８）評価委員のコメント
・2.3 は具体例を話されていて分かり易かった
・2.5 はなぜ 2 階層までなのか説明があると良い・4.3 は図零を入れると分かり易い
・5 章は現場では関わる機会が少なく USDM にどこまで含まれるか詳しく説明を聞きた
い・6.7 は 5W1H（？）を意識して使用を書けば良いと思います・6.10 は画面使用がどのタイミングで作られるのかなど、全体の工程が分かりづらい・6.12 は時系列分割、共通分割の例はここでは不要でしょうか・6 章で作業をする際に置かれた状況や立場、目線を明確にするべきだと思う・書く内容のレベルが分かりにくかった
・実際の現場をイメージ出来るようにすると取組みやすい・テキストの各章の最後にポイントを記載した方がよい（振り返りのため）・演習で個々人の作文評価は難しいと思うが、受講者は確認したいと感じているのではないかと
・今回の実証講座の時間で受講者が満足する演習を実施することは難しいのかと・演習に十分な時間を確保できるのであれば、特定の受講者の回答例から皆で意見を出し合う（話し合う）ような講座の進め方も有益なのかもしれない

4.4. 実証講座「アーキテクチャ設計」の実施体制
4.4.1. 受講者
受講者の情報は、実証講座の開始前の事前アンケート内で取得した。
ここで取得した受講者の基礎情報から、実証講座「アーキテクチャ設計」の受講者は、当初に想定していた対象の要件（複数のプログラミング言語を習得している、中堅以上のプログラマー）を概ね満たしていることが確認できた。

54

（１）受講者人数
応募定員に 20 名に対して、「アーキテクチャ設計」の受講者は 7 名であった。
（２）受講者の性別
受講者の性別は、男性 5 名、女性 2 名であった。
（３）受講者の年齢
受講者は、25 歳以上 45 歳未満であることから、若年者を除く中堅者が集まっていることが確認できる。
（４）受講者の最終学歴
大学学部卒が 5 名、高卒が 1 名、大学中退 1 名となった。
図表 1-4-1 受講者の年齢

図表 1-4-2 受講者の最終学歴

年齢

最終学歴

3

6
5

2

4
3

1

2

0

1
0

（５）受講者の取得資格
受講者は、6 名が IT 分野の資格を取得しており、一定の知識を有していることが確認できる。1 名は資格を取得していなが、現職の経験年数が 10 年を超えることから、一定の知識を有していると判断できる。
（６）受講者の習得言語
受講者は、全員がプログラミング言語を習得していることが確認でき、中堅以上のプロ
グラマーを受講者の想定としていたことから、妥当な受講者であることが確認できる。

55

図表 1-4-3 受講者の取得資格

図表 1-4-4 受講者の習得言語

取得資格

習得言語
HTML
Java

基本情報技術者

Java
SQL
PHP

応用情報技術者

CSSJava Script
HTML

Oracle Bronze

C
C#
COBOL

LPICレベル1

VB
C++
0

1

2

3

4

5

0

1

2

3

4

5

6

（７）受講者の現在の職種
プログラマー2 名、SE4 名、その他 1 名で、概ね想定していた中堅以上プログラマーの想定を満たしていることが確認できる。

56

（８）受講者の業務内容
受講者の全員がプログラミングまたは設計を現在の業務としていることから、想定していた受講者として適当であることが確認できる。
図表 1-4-5 受講者の職種

図表 1-4-6 受講者の業務内容

職種

業務内容

4

7
6
5
4
3
2
1
0

3
2
1
0
プログラマ

SE

IT

（９）受講者の現職の経験年数
現職の経験年数は、3 年から 18 年で平均 9 年であることから、概ね中堅以上の受講者であることが確認できる。
（１０）アーキテクチャ設計の経験
受講者の内 6 名はアーキテクチャ設計の経験が無いことが確認できた。1 名は無回答であった。
図表 1-4-7 受講者の経験年数
素表 1-4-8 アーキテクチャ設計の経験

経験年数

アーキテクチャー設計の経験

4
3
2
1
0

8
6
4
2
0
経験なし

57

5年以下

不明

4.4.2. 実施内容
（１）講座内容
実証講座「アーキテクチャ設計」は、10:00 から 17:00 の計 6 時間（90 分×4 コマ）、集
合形式の講義で実施された。また、実証講座の開始時および終了時には、アンケートと理解度確認テストを実施した。
図表 1-4-9 実証講座の内容
時間内容

10:00-11:30

・事前アンケートおよび事前理解度確認テスト
・共通フレーム 2013

11:30-13:00

・ソフトウェア品質

13:00-13:50

昼食

13:50-15:20

・アーキテクチャ設計

15:30-17:00

・アーキテクチャ設計演習
・事後アンケートおよび事後理解度確認テスト

図表 1-4-10 実証講座「アーキテクチャ設計」
（午前）

58

図表 1-4-11 実証講座「アーキテクチャ設計」（午後）

図表 1-4-12 実証講座「アーキテクチャ設計」
（午後）

59

4.5. 実証講座「アーキテクチャ設計」の結果
4.5.1. 事前理解度確認テストの結果（１）事前理解度確認テストの正答率
事前の理解度確認テストの結果は、20 問中の平均正答数が 5.6 点（正答率 27.9％）、最高点 8 点（正答率 40％）が 3 名、最低点 2 点（正答率 10％）が 1 名であった。
図表 1-5-1 事前理解度確認テストの正答率
正答率
100%
80%
60%
40%
20%
0%
平均

a

b

c

d

e

f

g

（２）事前理解度確認テストの正答率分布
正答率の分布は、10％から 40％の間で分布されており、正答率 50％以上がいなかったことが確認できる。
図表 1-5-2 事前理解度確認テストの正答率分布
正答率の分布
4
3
2
1
0
100%

90%

80%

70%

60%

50%

60

40%

30%

20%

10%

0%

（３）事前理解度確認テストの問題別正答率
問題別の正答率は、71％の正答率（7 人中 5 人が正解）の問題が 2 問あるものの、正答率 0％が 3 問、正答率 14％（7 人中 1 人）が 5 問、正答率 29％（7 人中 2 人）が 6 問、正答率 43％（7 人中 3 人）が 4 問と、正答率 50％以下の問題が 20 問中 15 問であった。
図表 1-5-3 事前理解度確認テストの問題別正答率
問題別正答率
100%
80%
60%
40%
20%

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

0%

１．５．２．事後理解度確認テストの結果（１）事後理解度確認テストの正答率
事後の理解度確認テストの結果は、20 問中の平均正答数が 6.7 点（正答率 33.6％）、最高点が 9 点（正答率 45％）
、最低点が 3 点（正答率 15％）であった。
図表 1-5-4 事後理解度確認テストの正答率
正答率
100%
80%
60%
40%
20%
0%
平均

a

b

c

61

d

e

f

g

（２）事後理解度確認テストの正答率分布
正答率の分布は、40％をピークに 20％代から 50％の間で分布されている。
図表 1-５-5 事後理解度確認テストの正答率分布
正答率
5
4
3
2
1
0
100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

（３）事後理解度確認テストの問題別正答率
問題別の正答率は、正答率 86％（7 人中 6 人が正答）が 2 問あるものの、正答率 0％が 5
問、正答率 14％（7 人中 1 人が正答）が 3 問、正答率 29％（7 人中 2 人が正答）が 4 問、正答率 43％（7 人中 3 人が正答）が 2 問で、半数の問題が正答率 50％以下であることが確認できた。
図表 1-5-6 事後理解度確認テストの問題別正答率
問題別正答率
100%
80%
60%
40%
20%

62

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

0%

4.5.2. 理解度確認テストの比較（１）理解度確認テストの正答率比較
事前と事後の理解度確認テストの正答率（正答数）を比較すると、平均で 5.7％（1.1 点）
上昇しており、受講者の内 1 人を除いて 7 人中 6 人の正答率が上昇していることが確認できる。
図表 1-5-7 理解度確認テストの正答率比較
正答率比較
50%
40%
30%
20%
10%
0%
a

平均

b

c

d

事前正答率

e

f

g

事後正答率

（２）理解度確認テストの問題別正答率比較
問題別の正答率を比較すると、20 問中の 8 問で上昇していることが確認できる。一方で、
5 問が下がっており、正答率が 0%になった問題が 3 問から 5 問に増えている。
図表 1-5-8 理解度確認テストの問題別正答率比較
問題別正答率比較

事前

63

事後

問題20

問題19

問題18

問題17

問題16

問題15

問題14

問題13

問題12

問題11

問題10

問題9

問題8

問題7

問題6

問題5

問題4

問題3

問題2

問題1

100%
80%
60%
40%
20%
0%

4.5.3. 事前アンケートの結果（１）自社のアーキテクチャ設計のアーキテクチャ設計の妥当性・効率性「自社のアーキテクチャ設計は妥当的・効率的に行われていると思いますか？」の問に対して、全員の回答が「普通」以下の評価であった。
図表 1-5-9 自社のアーキテクチャ設計の妥当性・効率性

自社のアーキテクチャ設計の妥当性等
5
4
3
2
1
0
十分

やや十分

普通

やや不十分

不十分

（２）講座への期待
本講講座全体への期待は、2 名が「大」、4 名が「やや大」で、参加者 7 人中の 6 人が本実証講座に期待していることが確認できる。
講座の単元毎の期待では、講座内容 3「アーキテクチャ設計」に 6 名が「やや大」と答えている。他の単元においても 6 名は「やや大」を中心に「大」「普通」と答えており、本講座内容に対して全体的に期待していることが確認できた。
図表 1-5-10 講座への期待
講座への期待
7
6
5
4
3
2
1
0

講座内容１の期待講座内容２の期待講座内容３の期待講座内容４の期待
本講座全体の期待
大

やや大

普通

やや小

64

小

4.5.4. 事後アンケートの結果（１）講師について
講師の進行スピードは、6 名が「速い」「やや速い」と答えている。講師の教え方は全員が「普通」以上に回答している。
図表 1-5-10 講師の進行

図表 1-5-11 講師の教え方

講師の進行

講師の教え方

4

6
5
4
3
2
1
0

3
2
1
0

（２）講座環境について
講座の環境は、全員が「普通」以上に回答している。講座の時間は 1 名が「やや長い」と答えているが、6 名が「普通」以下に回答している。
図表 1-5-12 講座の環境

図表 1-5-13 講座の時間

講座の環境

講座の時間

5

4

4

3

3

2

2
1

1

0

0

65

（３）テキストについて
テキストの分かり易さは、1 名が「分かり易い」と答えているが、3 名が「普通」、3 名が「やや分かり難い」と回答している。
テキストの内容は、全員が「普通」以上と回答している。
図表 1-5-14 テキストの分かり易さ
テキストの分かり易さ
4
3
2
1
0

図表 1-5-15 テキストの内容
テキストの内容
5
4
3
2
1
0

66

（４）講座の満足度
講座の満足度は、講座内容４の評価に「やや不満」と 3 名が回答しているが、それ以外は、講座全体と各単元に「普通」以上と回答していることから、本講座には概ね満足していると思われる。
図表 1-5-16 講座の満足度
講座の満足度5
4

講座内容１の満足度

3

講座内容２の満足度

2

講座内容３の満足度

1

講座内容４の満足度
講座の満足度0
非常に満足 やや満足

普通

やや不満 非常に不満（５）講座の難易度
講座の難易度は、講座内容２に対して 1 名が「ややレベルが低い」に回答しているが、受講者の多くが講座内容の１から４および講座全体に「適切なレベル」以上に回答している。
図表 1-5-17 講座の難易度
講座の難易度
7
6
5
4
3
2
1
0

講座内容１の難易度
講座内容２の難易度

67

レベルが
低い

ややレベル
が低い

適切な
レベル

ややレベル
が高い

レベルが
高い

講座内容３の難易度
講座内容４の難易度
講座全体の難易度

（６）講座内容の活用度
講座内容の活用度では、講座内容４に対して 1 名が「業務に活かせない」と回答いている。多くの受講者は講座内容の１から４および講座全体に「普通」を中心に「やや業務に活かせる」「やや業務に活かせない」に回答している。
図表 1-5-18 講座内容の活用度
講座内容の活用度
6
5
4
3
2
1
0

講座内容１の活用度
講座内容２の活用度

68

業務に
活かせない

やや業務に
活かせない

普通

やや業務に
活かせる

業務に
活かせる

講座内容３の活用度
講座内容４の活用度
講座全体の活用度

（７）講座内容とテキストに対する意見■講座内容１「共通フレーム 2013」の意見
・資格試験等で見かけた程度で、内容については知らなかったことでした。全体を一度確認したいと感じました。
・中小規模プロジェクトには活用するのは難しい。
・「共通フレーム 2013」について、もう少し詳しく勉強したいと思いました。
・自分に元々の知識があまりないせいかもしれないですが、共通フレームの有用性をあまり感じることができなかったことが残念です。
・共通フレームに対する興味が持てました。
・用語の統一を行おうとする試みがあったこと初めて知り。興味を持ちました。そのため、時間の都合もあるとは思われますが、内容について話がほぼないまま終えられてしまったように感じられたことは残念です。
■講座内容２「ソフトウェア品質」の意見
・業務をするうえで、参考になります。新人の頃に特に知りたかったと思いました・具体的な事例や、確認項目があれば良い。
・学生向けの講座としては良いのではないでしょうか。
・品質のことについて改めて勉強になりました。ただ、この有用性が発揮されるのはとても大きな規模のシステムの場合だなと感じました。
・"早くて内容の理解が追いつきませんでしたが、テキストを読み返し業務に活用していきたいと思いました。"
・品質の保持という点では普段から意識はしておりましたが、学問としての概念は意識することがなかったので、新鮮味をもって聞くことができました。
■講座内容３「アーキテクチャ設計」の意見
・日常業務で自分が担当しないところでしたので、参考になりました。既存の設計を見るときに、新たな視点で見ることができそうです。
・中小規模プロジェクトには活用するのは難しい。
・品質駆動設計は、業務での活用が難しいと感じました。
・今まで何も考えずにやっていたことなどをあらためて勉強させて頂きました。いつか自分が仕事として携われるようになった際には参考にさせて頂こうと思います。
・もっと時間をかけてきっちりと理解しながら学びたい内容でした。
・"早くて内容の理解が追いつきませんでしたが、テキストを読み返し業務に活用していきたいと思いました。"
・実行できれば有用かもしれないと思われるのですが、品質特性駆動設計など、なぜその内容を書き出すことができるのか、学びきれませんでした。
69

■講座内容４「アーキテクチャ設計演習」の意見
・まだまだ理解が足りず、何をやればよいか勉強が必要と感じます。正解が分からないの前に、何をすべきか・・・をまず身に着けたいと思います・講座内容が圧縮されていた為、理解・納得が不十分だった。
・「アーキテクチャ設計」の講座内容が短かった為、演習が難しかったです。
・"一人での単独作業となったので、あまり達成感をえることができませんでした。講義もそうですが、資料に対しての内容のボリュームが大きすぎて、不勉強な私にはだいぶ難しく感じました。"
・アーキテクチャ設計を業務に活用するイメージが持てました。
・上記、「アーキテクチャ設計」が未習熟のままに作業を行い、得ることが少ないまま作業が終わってしまったことが心残りです。
■テキストについて、ご意見をいただきたく思います。
・充実していました。講義に参加しなかった社員にも見せようと思います・概論的な話が多く、具体的な成果物例等があれば分かりやすい。
・時間の割には量が多かったと思います。
・持ち帰って熟読させていただきます。
・非常に参考になる内容とは思いますが、量が多いので後で読み返したいと思います。
・非常に参考になりそうではあるのですが、講義の進捗に追いつくためには読みきれず、大部分は確認すらできないままに終ってしまいました。
（８）評価委員のコメント
・ICONIX を使って設計した場合との対比ができると、理解が深まると思いました。
（そもそも逆の手順なので対比できないかもしれませんが）・講座内容４の演習が不十分だと感じました。演習問題に対して、問題の補足や回答の確認などがあるべきかと。

4.6. 実証講座の評価
4.6.1. 実証講座「要件定義」の評価（１）アンケートによる評価および考察
・「事前」のアンケートの「受講者の職種」や「業務内容」から、受講者は想定していた「中堅以上のプログラマー」を満たしている。一方で、2 名の要件定義経験者も受講しており、想定していた「超上流・上流工程（要件定義やアーキテクチャ設計）には直接携わった経験がないプログラマー」は満たされていなかったが、受講者の多くが要件定義の経験がないこと
70から、実証講座の実施に大きな影響は出なかったと感じている。
・「自社の要件定義は妥当的・効率的に行われていると思いますか？」の問いに対して、全員の回答が「普通」以下の評価であった。一方で、「講座への期待」は「やや大」を中心に概ね「普通」以上の回答であり、「講座への期待」はやや大きいと感じられるが、「自社の要件定義の妥当性・効率性」と「講座内容への期待」の相関では、「講座内容３への期待」に相関係数-0.31という「薄い負の相関」が見られるだけで、「自社の要件定義の妥当性・効率性」と「講座内容への期待」の関係性を見出すまでには至っていない。
（２）実証講座「要件定義」の印象評価
・「講座全体の満足度」は、「やや満足」と「普通」に集中しているが、「講座全体の満足度」と「講座内容３の満足度」に相関係数 0.89 が得られており、今回の実証講座の満足度が講座内
容３「要求定義書の作成（概論）」によって大きく得られたものだと考えられる。
・「講座全体の満足度」は、「テキストの分かり易さ」と「テキストの内容（有益性）」に相関係
数 0.75 と相関係数 0.73 という「高い正の相関」が得られていることから、今回の実証講座の満足度がテキストによって得られたものだと考えられる。
（３）実証講座「要件定義」のテキストの印象評価
・「テキストの分かり易さ」や「テキストの内容（有益性）」は、「普通」と「やや分かり易い／
やや有益」に回答が集中しており、一定の評価が得られている。また、「テキストに対する意見」からも「１、２、３章あたりの説明は分かりやすかったと思います」や「品質の高いテキストでした。後で読み返したいと思います」とのコメントがあり、一定の評価が得られている。一方で「テキストの分かり易さ」に「分かり易い」や「テキストの内容（有益性）」に「有益」の回答がないこと、「講座内容４の満足度」に「やや不満」があることや「テキストに対する意見」に「6 章で、例を用いて説明されているところはちょっとわかりにくかったです」などから、講座内容４「要求仕様書の作成（演習）」やテキストの 6 章の充実で、さらに評価を得られるものになると思われる。

71

・「テキストの内容（有益性）」と「講座内容３の満足度」に相関係数 0.66、「テキストの内容（有益性）」と「講座内容３の活用度」に相関係数 0.81、「テキストの分かり易さ」と「講座内容３の活用度」に相関係数 0.68 という、それぞれに「高い正の相関」が得られている。このことから、現在のテキストに対する評価は、講座内容３「要求仕様書の作成（概要）」に関係する箇所によって得られていると考えられる。
（４）理解度確認テストの評価および考察
・「事前」の理解後確認テストの結果から、理解度確認テストの問題が「やや簡単」であったと言える。理解度確認テストの問題が、「要件定義」の知識を問うものが多く、要件定義のプロジェクトで状況判断を問うなどの問題があっても良かったのではないかと感じる。
・理解度確認テストの事前と事後の比較から、受講者の 86％（7 名中 6 名）の正答率の上昇が確認でき、問題別の正答率の比較からも多くの問題で正答率が上昇していることから、実証講座に一定の効果があったと考える。また、実証講座の内容と理解度確認テストの内容がリンクしていることから、このような結果が得られたと考える。
・「事後」の理解度確認テストの結果と「受講者の現職の経験年数」に相関係数 0.59 という「中位な正の相関」（限りなく「高い正の相関」に近い）が得られ、受講者を「中堅以上のプログ
ラマー」と想定した講座内容および理解度確認テストになったものと思われる。
・「事後の理解度確認テストの結果」と事後アンケートの「講師の進行」から相関係数-0.4 という「中位な負の相関」が得られた。また、「事後の理解度確認テストの結果」と「講座の時間」
からも相関係数-0.59 という「中位な負の相関」が得られた。さらに、「講師の進行」と「講座の時間」に相関係数 0.42 という「中位な正の相関」が得られている。これらは「中位」な相関ではあるが、「講師の進行」と「講座の時間」に「理解度確認テストの結果」が影響していると考えられる。実証講座「要件定義」では「講師の進行」に「やや速い」という回答が多くあり、「講座の時間」に「やや短い」という回答もあったことから、「講師の進行」を「少しゆっくり」と進め、「講座の時間」をもう少し用意できれば、「事後の理解度確認テストの結果」がより向上する可能性が伺える。

72

4.6.2. 実証講座「アーキテクチャ設計」の評価（１）アンケートによる評価および考察
・「事前」のアンケートの「受講者の職種」や「業務内容」から、受講者は想定していた「中堅以上のプログラマー」を満たしている。また、アーキテクチャ設計の経験者もいなかったことから、想定していた「超上流・上流工程（要件定義やアーキテクチャ設計）には直接携わった経験がないプログラマー」を満たしている。
・「自社のアーキテクチャ設計は妥当的・効率的に行われていると思いますか？」の問いに対して、全員の回答が「普通」以下の評価であった。一方で、「講座への期待」は「やや大」を中心に概ね「普通」以上の回答であり、講座への期待は大きいと感じられるが、「自社のアーキ
テクチャ設計の妥当性・効率性」と「講座内容への期待」の相関では、「講座内容３への期待」に相関係数-0.35 という「薄い負の相関」が見られるだけで、「自社のアーキテクチャ設計の妥当性・効率性」と「講座内容への期待」の関係性を見出すまでには至っていない。
（２）実証講座「アーキテクチャ設計」の印象評価
・「講座全体の満足度」は、「やや満足」と「普通」に集中しているが、「講座全体の満足度」と「講座内容２の満足度」に相関係数 0.75 という「高い正の相関」が得られており、今回の実証講座の満足度が講座内容２「ソフトウェア品質」によって大きく得られたものだと考えられる。
・「講座全体の満足度」は、「テキストの内容（有益性）」に相関係数 0.91 という「かなり高い
正の相関」が得られており、「テキストの内容（有益性）」は「講座内容１の満足度」「講座内
容２の満足度」に相関係数 0.73 と 0.68 という「高い正の相関」が得られている。また、「テ
キストの分かり易さ」は「講座内容１の満足度」に相関係数が 0.71、「講師の進行」は「講座内容２の満足度」に相関係数が 0.71、「講師の教え方」は「講座内容１の満足度」と「講座内容３の満足度」に相関係数が 0.88 と 0.68 という、それぞれに「高い正の相関」を示している。これらの結果から、実証講座「アーキテクチャ設計」の満足度は、テキストと講師によって得られたものであると考えられる。

73

（３）実証講座「アーキテクチャ設計」のテキストの印象評価
・「テキストの分かり易さ」は、「分かり易い」から「やや分かり難い」に分散している。
・「テキストの内容（有益性）」は、「普通」を中心に「普通」以上（「有益」「やや有益」）に回答を得られていて、一定の評価が得られている。
・「テキストに対する意見」からは「充実していました」や「非常に参考になる内容と思います」とのコメントがあり、一定の評価が得られている。一方で「時間の割に量が多かったと思います」や「講義の進捗に追いつくためには読み切れず…」のコメントがあり、「テキストの量」と「講義の進捗」に意見が出ている。
・「テキストの分かり易さ」と「講座全体の活用度」に相関係数 0.77 と「高い正の相関」が得られている。また、「テキストの分かり易さ」と「講座内容３の活用度」「講座内容４の活用度」に相関係数 0.81 と 0.73 と「高い正の相関」が得られている。さらに「テキストの分かり易さ」と「講座内容１の活用度」にも相関係数 0.47 という「中位な正の相関」が得られており、「テキストの分かり易さ」と「講座内容の活用度」に関係性があると言える。
（４）理解度確認テストの評価および考察
・「事前」と「事後」の理解後確認テストの結果から、理解度確認テストの問題が「かなり難しい」ものであったと言える。理解度確認テストの問題が、「アーキテクチャ設計」の深く詳し
い知識を問うものが多く、かなりの知識量を必要とする内容で出題されていると思われる。
・理解度確認テストの事前と事後の比較から、受講者の 86％（7 名中 6 名）の正答率が上昇しているが、上昇した点数は平均でわずかに 1.1 点であった。また、問題別の正答率の比較か
らは、7 問で正答率が上昇している、一方で 5 問の正答率が下降している。この結果から、実証講座が理解度確認テストの結果に効果的であったと立証するのは難しい。

74

4.6.3. 評価委員の所感・受講者について
今回の受講者は、中堅以上のプログラマーであり、実証講座への期待が「やや大きい」こともあり、受講する姿勢は極めて前向きであった。
・実証講座の内容
今回の実証講座は、「要件定義」と「アーキテクチャ設計」で、非常に良くまとまった内容であったと、アンケートの意見からもうかがうことができる。
また、今回の実証講座の内容は、受講者の経験や現職によって活用度が違うと感じる。
「中堅以降」で業務において設計を担当している場合は、非常に有益な内容だと感じたはずである。
一方で、若手のプログラマーにとっては、今回の実証講座の内容が現在の業務において、まだ価値を見いだせない内容なのかもしれない・実証講座の時間
今回の実証講座では、受講者の期待に応えるまでの時間を用意できていない。特に、演習にかける時間や、テキストのボリュームから内容に見合う時間は用意できていない。
講座内容と実施時間の再検討が必要であり、実施方法では e-Learning 等での講座も検討するべ
きかと。
・実証講座「要件定義」について
実証講座「要件定義」の内容は、「演習」部分を除き、テキスト内容や理解度確認テストなどが、非常にコンパクトにまとめられていると感じる。
一方で、「中堅以上」を集めた今回の受講者には、「演習」での仮想の例題では実務レベルに比べて曖昧な部分や、作業のレベル感に戸惑わせてしまったところがあったので、例題から本格的な開発案件での事例に移行する必要があるのかと感じた。
・実証講座「アーキテクチャ設計」についてテキストの内容やボリュームが非常に充実していることはアンケートの意見からうかがうこと
ができる。
一方で、
「中堅以上」の受講者であっても、未知な内容で深いレベルまで掘り下げた内容であることから、講座内での理解や吸収は難しいレベルであると思われる。
ボリュームの調整や理解度確認テストの頻度を増やすなどの反復を実施する工夫が必要なのか
と感じた。

75

・担当講師
今回の実証講座の担当講師は、知識量が十分過ぎるほどあり、実証講座を十分に実施てきたが、他の講師で、同じレベルの講座を実施することは難しいと感じている。
このことから、コマシラバスの充実は重要であり、特に「アーキテクチャ設計」においては、講座の進捗や情報量のボリューム調整も必要であると感じている。
・実証講座の在り方について
1 つの地域で、想定した受講者を十分に集めることは難しいようである。このことから、実証講座を複数の地域で実施することを検討してもよいのではないかと考える。
・今回の評価方法について
今回の実証講座の評価にあたり、受講者数が少ないことから、限られたデータで相関を計るにとどまっている。また、十分なデータ件数を取得できなかったことから、今回の実証講座の評価では有意な結果は計れていない。

76

5. 付録：テキスト『要件定義・アーキテクチャ設計』

77