公立はこだて未来大学 2012 年度 システム情報科学実習
グループ報告書
Future University Hakodate 2012 System Information Science Practice
Group Report
プロジェクト名
新ポートフォリオシステム
Project Name
The New Portfolio System
グループ名
グループ (A)
Group Name
Group (A)
プロジェクト番号/Project No.
20-A
プロジェクトリーダ/Project Leader
1010110
梅本祥平
Shouhei Umemoto
グループリーダ/Group Leader
1010110
梅本祥平
Shouhei Umemoto
グループメンバ/Group Member
1010028
木村幸太朗
1010110
梅本祥平
Shouhei Umemoto
1010126
山本賢人
Kento Yamamoto
1010230
和田聖矢
Seiya Wada
1010234
菊谷裕太
Yuta Kikuya
1010243
中野佑
Koutaro Kimura
Tasuku Nakano
指導教員
神谷年洋
Advisor
Toshihiro Kamiya
提出日
2013 年 1 月 16 日
Date of Submission
Janualy 16, 2013
概要
近年、学習の成果を記録する e-ポートフォリオシステムが、大学等の教育機関で導入されてい
る。e-ポートフォリオシステムを利用して学習の成果を記録し、学習の成果の振り返りや公開
を行うことで、学生生活や就職活動に役立てることができる。しかし現在、公立はこだて未来
大学では、e-ポートフォリオシステムは導入されていない。そこで公立はこだて未来大学に eポートフォリオシステムを導入するため、本プロジェクトがメタ学習センターから開発依頼を
受け、新たに e-ポートフォリオシステムを開発することにした。このような受託開発では顧客
の要求が常に変化するため、適応的にソフトウェア開発を行う必要がある。その方法の 1 つと
して、アジャイルソフトウェア開発が注目されている。本プロジェクトでは、e-ポートフォリ
オシステムを開発すると同時に、アジャイルソフトウェア開発を実践し、ソフトウェア開発を
行うための実践的なスキルを身につける。
キーワード
e-ポートフォリオシステム, アジャイルソフトウェア開発
（※文責: 梅本祥平）
-i-
Abstract
In recent years, e-Portfolio System has been introduced in universities and other educational institutions. Students use e-Portfolio System to store, reflect and publish their
artifacts. Then e-Portfolio System can be useful to learning activity and job hunting.
However, e-Portfolio System has not been introduced in Future University-Hakodate.
Therefore, our project has received a development request from Center Meta Learning.
In contract development like this case, software have to be developed adaptively because customer’s requests are uncertain. For one, Agile Software Development has been
attracting attention. Our project will develop e-Portfolio System and acquire pragmatic
sofware development skills through practicing Agile Software Development.
Keyword
e-Portfolio System, Agile Software Development
（※文責: 梅本祥平）
- ii -
目次
第1章
1.1
1.2
1.3
第2章
2.1
背景
1
前年度の成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
e-ポートフォリオシステムに関する成果 . . . . . . . . . . . . . . . . . . .
1
1.1.2
アジャイルソフトウェア開発に関する成果 . . . . . . . . . . . . . . . . . .
1
現状における問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.1
e-ポートフォリオシステムに関する問題点 . . . . . . . . . . . . . . . . . .
2
1.2.2
e-ポートフォリオシステムの開発に関する問題点 . . . . . . . . . . . . . . .
3
課題の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3.1
e-ポートフォリオシステムに関する課題 . . . . . . . . . . . . . . . . . . .
3
1.3.2
アジャイルソフトウェア開発に関する課題 . . . . . . . . . . . . . . . . . .
4
到達目標
本プロジェクトにおける目的
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
通常の授業ではなく、プロジェクト学習で行う利点 . . . . . . . . . . . . .
5
具体的な手順・課題設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
メンバーの技術習得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.2
環境構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.3
インセプションデッキの作成 . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.4
ファイル共有サービスの調査 . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.5
機能検討 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.6
計画づくり . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.7
e-ポートフォリオシステムの調査 . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.8
プロジェクトコミュニティとの関わり . . . . . . . . . . . . . . . . . . . .
8
2.2.9
システムの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.10 ペーパープロトタイピング . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.11 データベース設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.12 振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
課題の割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
課題解決のプロセスの概要
11
プロジェクトの進行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.1
役割分担 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.2
勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.3
技術習得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.4
議事録の活用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
アジャイルプラクティス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.1
インセプションデッキの作成 . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.2
スタンドアップ・ミーティング . . . . . . . . . . . . . . . . . . . . . . . .
12
2.1.1
2.2
2.3
第3章
3.1
3.2
5
- iii -
3.3
3.2.3
ポモドーロテクニック . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.4
タスクかんばん . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.5
テスト駆動開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
機能検討 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.3.1
ユーザストーリーの作成
. . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4
ペーパープロトタイピング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.5
e-ポートフォリオシステムの調査 . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.6
計画作り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.6.1
ストーリーポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.6.2
プランニングポーカー . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.6.3
ベロシティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.7
プロジェクトコミュニティに対するヒアリング . . . . . . . . . . . . . . . . . . .
14
3.8
振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
課題解決のプロセスの詳細
17
プロジェクトを進めるにあたって . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.1.1
役割分担 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.1.2
議事録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.1.3
インセプションデッキ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.1.4
スタンドアップ・ミーティング . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1.5
付箋によるアイディア出し . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.6
タスクの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
採用技術の検討 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.1
Web アプリケーションフレームワーク . . . . . . . . . . . . . . . . . . . .
22
4.2.2
データベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.3
バーション管理システム
. . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.4
勉強会の実施 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
ユーザーストーリーの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.1
ユーザーストーリーの決定 . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.2
優先順位付け . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3.3
前期と後期の違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
第4章
4.1
4.2
4.3
4.4
全体の計画づくり
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4.1
ユーザーストーリーの選定 . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.4.2
ユーザーストーリーの見積もり . . . . . . . . . . . . . . . . . . . . . . . .
25
4.5
システム全体のペーパープロトタイピング . . . . . . . . . . . . . . . . . . . . .
26
4.6
データベース設計
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.7
e-ポートフォリオシステムの分析 . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.7.1
学内ポートフォリオについて . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.7.2
Mahara について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.8
プロジェクトコミュニティに対するヒアリング . . . . . . . . . . . . . . . . . . .
27
4.9
振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.10
今後について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
- iv -
4.11
4.12
第5章
4.10.1 プロダクトオーナーの決定 . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.10.2 プロジェクトコミュニティでの会議の設定 . . . . . . . . . . . . . . . . . .
28
各人の課題の概要とプロジェクト内における位置づけ
. . . . . . . . . . . . . . .
28
4.11.1 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.11.2 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.11.3 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.11.4 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.11.5 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.11.6 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
担当課題解決過程の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.12.1 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.12.2 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.12.3 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.12.4 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.12.5 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.12.6 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
結果
39
5.1
結果の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.2
システム開発の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3
プロジェクトコミュニティに対するヒアリングの結果
. . . . . . . . . . . . . . .
39
5.3.1
メタ学習センター長へのヒアリング結果 . . . . . . . . . . . . . . . . . . .
39
5.3.2
メタ学習センター教員へのヒアリング結果 . . . . . . . . . . . . . . . . . .
40
5.3.3
メタ学習ラボチューターへのヒアリング結果 . . . . . . . . . . . . . . . . .
40
5.3.4
高度 ICT コース長へのヒアリング結果 . . . . . . . . . . . . . . . . . . . .
40
5.3.5
ヒアリング結果のまとめ
. . . . . . . . . . . . . . . . . . . . . . . . . . .
40
発表会の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.4.1
中間成果発表会の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.4.2
最終成果発表会の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.4.3
成果物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
成果の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.4
5.5
5.6
第6章
5.5.1
プロジェクトの目標についての評価
. . . . . . . . . . . . . . . . . . . . .
46
5.5.2
成果物の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.5.3
振り返りの結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
担当分担課題の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.6.1
木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.6.2
梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.6.3
山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.6.4
和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.6.5
菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.6.6
中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
今後の課題と展望
57
-v-
6.1
6.2
課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.1.1
顧客を巻き込んだ開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.1.2
プロダクトオーナーの決定 . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.1.3
技術力の向上 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.1.4
アジャイルプラクティスの実践 . . . . . . . . . . . . . . . . . . . . . . . .
58
展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.2.1
システムの開発再開 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.2.2
活動の継続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
第7章
謝辞
61
付録 A
新規習得技術
63
A.1
アジャイルソフトウェア開発
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.2
Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.3
Web アプリケーションフレームワーク . . . . . . . . . . . . . . . . . . . . . . .
63
A.4
NOSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.5
ペーパープロトタイピング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.6
バージョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
付録 B
活用した講義
65
付録 C
相互評価
67
梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.1.1 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.1.2 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.1.3 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.1.4 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.1.5 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.2.1 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
C.2.2 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.2.3 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.2.4 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.2.5 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.3.1 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.3.2 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.3.3 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
C.3.4 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.3.5 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.4.1 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.4.2 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.4.3 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.1
C.2
C.3
C.4
- vi -
C.5
C.6
C.4.4 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.4.5 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.5.1 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.5.2 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.5.3 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.5.4 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.5.5 和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
和田聖矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.6.1 梅本祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.6.2 菊谷悠太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
C.6.3 木村幸太朗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.6.4 中野佑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
C.6.5 山本賢人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
参考文献
73
- vii -
The New Portfolio System
第1章
背景
近年、大学等の教育機関で e-ポートフォリオシステムの活用が注目されている。e-ポートフォリ
オシステムとは、学生が学習の成果を蓄積するものであり、学習の振り返りや就職活動に活用す
ることができる。また、教員が教育の改善や学習状況の把握に活用することができる。そして、eポートフォリオシステムは教育の質を保証するものとして役立てられる。
また近年のソフトウェア開発では、顧客の要求が流動的であるため、迅速で適応的な開発が要求
されている。そのため、従来型のソフトウェア開発では、これらの要求に対応することが難しく
なっている。これらの要求に対応するソフトウェア開発の方法として、アジャイルソフトウェア開
発がある。
（※文責: 梅本祥平）
1.1
前年度の成果
1.1.1
e-ポートフォリオシステムに関する成果
前年度は、高度 ICT プレコースにて e-ポートフォリオシステムの開発が行われた。これはメタ
学習センターからの開発依頼によるものであった。
前年度の成果として、2 学年から 3 学年への進級時に行われる配属コースの選択を支援する eポートフォリオシステムが開発された。開発された e-ポートフォリオシステムを、図 1.1 に示す。
開発された e-ポートフォリオシステムは、限定的な機能しか持ち合わせていない。そのため、全
学的な e-ポートフォリオシステム導入に向けた使用に耐え得るものではない。また、メタ学習セ
ンターの体制が変わったため、本学で使用する e-ポートフォリオシステムに対する要求が変化し
た。さらに e-ポートフォリオシステムの開発プロジェクトに携わっていた顧客が不在となってし
まった。
（※文責: 梅本祥平）
1.1.2
アジャイルソフトウェア開発に関する成果
前年度の高度 ICT プレコースでは、e-ポートフォリオシステムの開発にあたり、アジャイルソフ
トウェア開発の開発手法である、エクストリーム・プログラミングが行われた。しかし、エクスト
リーム・プログラミングで定義されているプラクティスを十分に実践できたとは言い難い。そのた
め、低品質なソフトウェアを提供することになってしまっていた。
（※文責: 梅本祥平）
Group Report of 2012 SISP
-1-
Group Number 20-A
The New Portfolio System
図 1.1
前年度開発された e-ポートフォリオシステム
（※文責: 梅本祥平）
1.2
1.2.1
現状における問題点
e-ポートフォリオシステムに関する問題点
本学では、ポートフォリオの作成が教育の方法の一つとして挙げられている。そして、全学生に
ポートフォリオを保存するためのストレージが付与されている。その Web サイトを、図 1.2 に示
す。このストレージでは、学習成果の蓄積やポートフォリオの作成といった機能はシステム化され
ていない。また、学内ネットワークからのみアクセス可能であり、就職活動での活用といった外部
からの利用は不可能である。
現在、オープンソースソフトウェアとして公開されている e-ポートフォリオシステムがいくつか
ある。しかし、オープンソースソフトウェアであるため、本学に最適化されたシステムではない。
また、ユーザビリティなどにも問題があるため、オープンソースソフトウェアの e-ポートフォリオ
システムを本学に導入することは難しい。そこで、本プロジェクトでは本学で使用する e-ポート
フォリオシステムを新たに開発することにした。
（※文責: 梅本祥平）
Group Report of 2012 SISP
-2-
Group Number 20-A
The New Portfolio System
図 1.2 ポートフォリオを保存するためのストレージへのリンク
（※文責: 梅本祥平）
1.2.2
e-ポートフォリオシステムの開発に関する問題点
e-ポートフォリオシステムを開発するにあたり、顧客の要求が流動的である点、迅速で適応的な
開発が要求される点に留意した。そして、本プロジェクトでは従来型のソフトウェア開発ではな
く、アジャイルソフトウェア開発に取り組むことにした。
（※文責: 梅本祥平）
1.3
1.3.1
課題の概要
e-ポートフォリオシステムに関する課題
本プロジェクトにおける課題は、本学で使用する e-ポートフォリオシステムを新たに開発するこ
とである。新たに開発するにあたり、本学の特色に合わせた e-ポートフォリオシステムを目指す。
特に、プロジェクト学習に取り組む 3 年生をユーザーとして想定した。そして、学習の成果を蓄積
する、ポートフォリオを作成する、ポートフォリオを公開するといった基本的な機能に加えて、本
学のカリキュラムの特色であるプロジェクト学習に合わせた機能を追加し、e-ポートフォリオシス
テムを構築する。それによって、学生の学習活動や就職活動をサポートすることを目的とする。
Group Report of 2012 SISP
-3-
Group Number 20-A
The New Portfolio System
（※文責: 梅本祥平）
1.3.2
アジャイルソフトウェア開発に関する課題
本プロジェクトにおけるもう一つの課題は、アジャイルソフトウェア開発に取り組むことであ
る。本プロジェクトでは、アジャイルソフトウェア開発の開発手法である、エクストリーム・プロ
グラミングとスクラムを行う。そして、近年取り組まれているソフトウェア開発手法をプロジェク
ト学習で実践することで、従来の講義や演習だけでは得ることができない知識・技術を獲得する。
特に、顧客の要求の変化に対して適応的にソフトウェア開発を行うために、どのようにしていけば
よいのかということに重点を置き、e-ポートフォリオシステムの開発に取り組む。
（※文責: 梅本祥平）
Group Report of 2012 SISP
-4-
Group Number 20-A
The New Portfolio System
第2章
到達目標
本プロジェクトにおける目的
2.1
本プロジェクトでは、学生が自らの学習成果の管理をサポートするための e-ポートフォリオシ
ステムを開発する。このシステムは、Web アプリケーションで構築され、学習成果を記録する機
能、共有する機能、発信する機能、振り返りを促進する機能を持つ。e-ポートフォリオシステムの
ユーザーである学生が、学習活動や就職活動に役立てることを想定している。本年度は、特に本学
のプロジェクト学習に取り組んでいる３年生をユーザーとして想定し、システムの機能を設計、実
装する。
本プロジェクトでは、アジャイルソフトウェア開発によりシステムを開発し、顧客に真の価値を
届けることに重点を置いた開発を体得する。
（※文責: 中野佑）
2.1.1
通常の授業ではなく、プロジェクト学習で行う利点
本プロジェクトでは e-ポートフォリオシステムを題材に Web アプリケーションを構築する。プ
ログラミング基礎や情報処理演習などの授業では、教員から与えられた課題を解決するだけであ
る。本プロジェクトの活動で設定した課題を解決していくことで、通常のプログラミングの授業で
は学ぶことのできない範囲の実用的なプログラミングを実践することができる。
また、通常の授業では実際の顧客を相手に開発を行える機会はない。ソフトウェア設計論などの
講義では、アジャイルソフトウェア開発の概要や高品質なソフトウェアを開発するための知識を習
得するだけで、それらを実践できる機会はない。本プロジェクトでアジャイルソフトウェア開発を
実践することで顧客に価値を届ける方法を身につけたり、ソフトウェア開発における実践的な知識
を習得することができる。
（※文責: 中野佑）
具体的な手順・課題設定
2.2
2.2.1
メンバーの技術習得
e-ポートフォリオシステムを開発するにあたり、必要な技術が不足しているため、以下の項目に
ついて学習する必要がある。
1. アジャイルソフトウェア開発 ソフトウェア開発において開発されたシステムの機能の大
半が使われていないという現状がある。近年のソフトウェア開発では、より迅速で適応的な
開発に対する要求が高まっている。アジャイルソフトウェア開発では顧客に真の価値を届け
ることに重点を置いている。システムを開発する上で、本プロジェクトではアジャイルソフ
トウェア開発に取り組む。アジャイルソフトウェア開発には様々なプラクティスがある。本
Group Report of 2012 SISP
-5-
Group Number 20-A
The New Portfolio System
プロジェクトに合ったアジャイルソフトウェア開発を行うために、メンバーはアジャイルソ
フトウェア開発について学習する必要がある。
2. バージョン管理システムの活用 適応的にソフトウェアを開発する上でバージョンを管理す
る必要がある。Git を使いこなせるようになるにはまず、バージョン管理システムの仕組み
について勉強会を開催するなどして学習する。その後、必要なコマンドの種類を把握し、実
際に何度も繰り返して利用することで使いこなせるようになる。
3. Ruby Ruby はオブジェクト指向プログラミング言語で、コードを簡潔にする仕組みや理解
しやすくする仕組みが備わっている。本プロジェクトメンバーは、Ruby を使用してシステ
ムを構築する技術を習得するために、Ruby の文法、仕組みについて学習する必要がある。
そのためには、勉強会を開催したり、教員が設定した課題を解くことで文法や仕組みを理解
する。Ruby を学習するにあたり、参考書として「たのしい Ruby 第 ３ 版 [1]」を使用する。
4. Ruby on Rails Ruby on Rails はプログラミング言語 Ruby で構築された Web アプリケー
ションフレームワークで、Web アプリケーションの開発を効率よく行うための仕組みが備
わっている。本プロジェクトでは、システムの開発速度をあげるために Ruby on Rails を導
入する。そのためには、勉強会を開催したり、教員が設定した課題を解くことで仕組みを理
解する。Ruby on Rails を学習するにあたり、参考書として「Rails によるアジャイル Web
アプリケーション開発 第 ４ 版 [2]」を使用する。
5. MongoDB 本プロジェクトで作成する e-ポートフォリオシステムは学生が作成したポー
トフォリオにバージョン管理ができるような仕組みとなる。MongoDB は近年 NOSQL の
中で注目されているドキュメント指向データベースである。この仕組みを満たすために
MongoDB と NOSQL を学習し、Ruby on Rails 上で利用できるようにする。Ruby on
Rails を利用できる前提で、MongoDB のデータベースサーバが起動できることを確認する。
その後、Ruby on Rails と組み合わせて利用する際にデータの格納などを行えるようにす
る。MongoDB を学習するにあたり、参考書として「NOSQL の基礎知識 [3]」を使用する。
6. HTML5 HTML は Web ページの記述をするためのマークアップ言語であり、HTML5 は
最新の構文仕様である。講義では、HTML5 について詳しく取り上げられていないので、学
習して理解を深める必要がある。そのためには、勉強会を開催したり、HTML でスライド
資料の作成ができる deck.js を利用してプレゼンテーションするなどして、知識を習得する。
（※文責: 中野佑）
2.2.2
環境構築
開発を進めていくにあたって、プロジェクトメンバー内で開発環境が統一されている必要があ
る。以下の手順で環境構築を行う。
1. Git バージョン管理を行う際に、Git を使用するため、Git のインストールを行う。Git を
使える環境を構築する。
2. Ruby Ruby を利用するにあたって、開発するための環境にインストールを行う必要があ
る。Ruby には様々なバージョンがあり、本プロジェクトでは 1.9.3 を利用する。
3. Ruby on Rails Ruby on Rails を利用するにあたって、開発するための環境にインストー
ルを行う必要がある。Ruby on Rails には様々なバージョンがあり、本プロジェクトでは
Group Report of 2012 SISP
-6-
Group Number 20-A
The New Portfolio System
3.2 を利用する。
4. MongoDB MongoDB を利用するために、インターネット上からダウンロードしてインス
トールをする必要がある。開発環境によってインストール方法が異なることに注意する必要
がある。
（※文責: 中野佑）
2.2.3
インセプションデッキの作成
プロジェクトを進めていくうえで軸となるものを作成し、方向性を明らかにする必要がある。イ
ンセプションデッキで示される 10 の質問に回答していくことでプロジェクトメンバー内の意思統
一を図る。
（※文責: 中野佑）
2.2.4
ファイル共有サービスの調査
機能検討を行う前に、参考材料を収集する必要がある。既存の各サービスにはどのような機能が
あるか、特徴をまとめることを目標とする。
（※文責: 和田聖矢）
2.2.5
機能検討
開発の計画づくりを行う前に、本プロジェクトが開発する e-ポートフォリオシステムに必要な機
能を、大まかに検討する必要がある。
（※文責: 和田聖矢）
2.2.6
計画づくり
1. スケジュール確認
プロジェクトを進めるにあたってあらかじめ決まっているマイルストーンをプロジェクトメ
ンバー内で認識しておく必要がある。メンバー全員が共通の認識を持っていることを目的と
する。
2. イテレーションの設定
ソフトウェア開発において顧客の要望は常に変化しやすい。本プロジェクトでは顧客に真の
価値を届けることに重点を置いた開発を行うため、顧客へ定期的に動くソフトウェアを提供
し、フィードバックをいただく必要がある。そのため、期間を細かい単位で区切り、システ
ム全体を徐々にフィードバックを反映させながら作成していく。
3. ユーザーストーリー作成
検討した機能から、ユーザーの目線となってシステムの利用シーンを明らかにする必要があ
る。プロジェクトメンバー全員でブレーンストーミングを行い、ユーザーの利用シーンを洗
い出すことを目的とする。
Group Report of 2012 SISP
-7-
Group Number 20-A
The New Portfolio System
4. ストーリーポイントを決める
作成したストーリーの規模をそれぞれに決める必要がある。プロジェクトメンバー内全員が
同意できる規模を決定することを目標とする。プロジェクトメンバー全員でプランニング
ポーカーを行い、重みを付けた理由を話し合う。
5. 優先順位付け
ストーリーの規模から重要なストーリーと特に意識しなくてよいストーリーに分ける必要が
ある。プロジェクトメンバー全員で話し合い、すべてのストーリーに優先順位をつけること
を目的とする。
6. イテレーションの計画作り
作成したユーザーストーリーや、マイルストーンからイテレーションの長さ、回数を決める
必要がある。割り込みタスクが発生しても柔軟に対応できるように設定することを目的と
する。
7. イテレーションのゴール設定
定めたイテレーションで最低限の目標を立てる必要がある。目標を立てることでスコープを
設定することが容易になる。
8. ベロシティの見積もり
イテレーションでストーリーを実装していくにあたり、イテレーション内でスコープを設定
する。その際に、メンバーの技術力を把握していなければスコープの設定を誤ってしまう。
そのため、チームの開発速度を測る必要がある。
9. ストーリーを選ぶ
イテレーションで実装するスコープを設定する必要がある。優先順位から実装するストー
リーを選び、ベロシティを超えない範囲で選択することを目的とする。
10. タスク管理
選んだユーザーストーリーの一覧をプロジェクトメンバー全員で確認できる必要がある。ス
トーリー一覧をかんばんに貼り付け、今どのタスクを行っていて、残りのタスクがどのくら
いあり、終えたタスクはどのくらいあるか把握できることを目的とする。
（※文責: 中野佑）
2.2.7
e-ポートフォリオシステムの調査
より本学に適したシステムの機能検討を行うために、既存の e-ポートフォリオシステムについて
特徴を調べる。e-ポートフォリオシステムの役割について学び、理解を深める。
（※文責: 和田聖矢）
2.2.8
プロジェクトコミュニティとの関わり
アジャイルソフトウェア開発の原則である顧客満足を優先するにはプロジェクトコミュニティの
意見をシステムに反映させることが不可欠である。そのため、メタ学習センター長などから直接意
見をいただく必要がある。それぞれ考え方が違うため、様々な意見をまとめ、プロジェクトコミュ
ニティが納得することを到達目標とする。
Group Report of 2012 SISP
-8-
Group Number 20-A
The New Portfolio System
（※文責: 中野佑）
2.2.9
システムの実装
前期に行うイテレーションでは、最低限必須の機能であるユーザ管理機能の実装から取り組む。
そこから、蓄積機能、共有機能、公開機能、振り返り促進機能などの実装は後期に実施されるイテ
レーションにて行う。
1. ユーザー管理機能の実装
ユーザー管理機能は、システムを利用するユーザーの情報を管理する機能である。管理すべ
き情報には ID、パスワード、所属するグループとグループでの権限、ログインに必要なパ
スワードなどが考えられる。情報をきろくするためにデータベースを使用する必要がある。
パスワード登録に関しては不適切なものを判断できるような仕組みにする必要がある。
2. 蓄積機能
蓄積機能は、ユーザーがシステムに学習成果を保存する機能である。本年度はテキストデー
タと画像データのみを扱うことにし、その他の形式に関しては作成したポートフォリオにリ
ンクをはることにする。
3. 共有機能
共有機能はユーザー間で保存した学習成果を共有できる機能である。学習成果を保存する仕
組み、共有するユーザーの情報設定と変更ができる仕組みとなっている。
4. 公開機能
公開機能は、ユーザーがシステムに保存した学習成果を編集して他者に公開することがで
きる機能である。公開することによって、ユーザーの学習成果を見た他者に学生自身をア
ピールすることができる。学生自身のプライバシー保護のため、非公開設定にすることもで
きる。 5. 振り返り促進機能
振り返り機能は、ユーザーが学習成果をもとに次の学びを促進させる機能である。ユーザー
は公開したポートフォリオに他者からコメントをもらうことができたり、ユーザー自身でシ
ステムに記録した学習成果を振り返ることができることを実現させる。
（※文責: 中野佑）
2.2.10
ペーパープロトタイピング
システムの実装前に、プロトタイプを紙で作成し、ユーザーインタフェースのテストを行う必要
がある。ペーパープロトタイピングを行い、自然でわかりやすい画面遷移、自然なボタンやフォー
ムの配置、直感的な動作を実現できるユーザーインタフェースを決定することを目標とする。ユー
ザーインタフェースのテストには、ヒューマンインタフェースの講義や、勉強会で得た知識を活用
する。
（※文責: 和田聖矢）
Group Report of 2012 SISP
-9-
Group Number 20-A
The New Portfolio System
2.2.11
データベース設計
システムに必要なデータベースの設計を行う必要がある。解決過程では、データベース工学の講
義で得た知識や、本プロジェクトの勉強会で得たデータベースの知識を用いる。
（※文責: 和田聖矢）
2.2.12
振り返り
実施したイテレーションで何か問題が発生した場合や、次のイテレーションでも継続して行える
ような事柄についてメンバー同士で話し合い、反映させるべきである。また、イテレーションだけ
ではなくプロジェクト全体としても振り返りを行うことで、各メンバーの気づきや、今後の新たな
課題を設定することができる。
（※文責: 山本賢人）
2.3
課題の割り当て
前期では、メンバー一人ひとりがプロジェクト全体に対して責任を持つために、各メンバーがす
べての仕事に携わるようにした。これにより、全員がすべての作業に参加することになり、全体で
今どのような作業をやっているか各メンバーが把握できた。
後期からは作業をデータベースの構築とペーパープロトタイピングで分ける。我々のプロジェク
トは、高度 ICT コース、情報システムコース、複雑系知能コース、デザインコースに所属する学
生が集まっており、デザインコースのメンバーはペーパープロトタイピングを行うなど、それぞれ
の得意分野を活かして活動できるように割り当てた。
（※文責: 中野佑）
Group Report of 2012 SISP
- 10 -
Group Number 20-A
The New Portfolio System
第3章
3.1
3.1.1
課題解決のプロセスの概要
プロジェクトの進行
役割分担
本プロジェクトではアジャイルソフトウェア開発を用いているため、前期にはプロジェクトメン
バーそれぞれ明確な役割分担は行わなかった。それにより、各自積極的に活動に参加でき、各分野
において、得意分野を自由に発揮することができた。
後期には、データベースの構築と、ペーパープロトタイピングに作業を分担した。これにより、
実装作業の効率化をはかった。
なお、プロジェクトリーダーとプロジェクトマネージャーはプロジェクト学習において必要であ
るため、一年を通して設定していた。
（※文責: 山本賢人）
3.1.2
勉強会
プロジェクトメンバーの技術習得を目的として、輪講形式の勉強会を行った。プロジェクトメン
バーの一名が、勉強会で扱う技術に関して予習をし、勉強会を 4 回ほど繰り返した。
（※文責: 木村幸太朗）
3.1.3
技術習得
本学で使用する e-ポートフォリオシステムを開発するにあたって、必要と思われる技術を学習
し、習得した。学習方法として、勉強会を行った。学んだ技術を以下のものである。
• Ruby
• Ruby on Rails
• MongoDB
• HTML5
• jQuery
• Git
• GitHub
（※文責: 山本賢人）
3.1.4
議事録の活用
アジャイルソフトウェア開発はドキュメントよりコミュニケーションといわれているが、プロ
ジェクトの活動は一週間に 2 回しかない。そのため、プロジェクトの活動を記録し、振り返るため
Group Report of 2012 SISP
- 11 -
Group Number 20-A
The New Portfolio System
に議事録を活用した。また、報告書の執筆や発表の際に、活動を振り返るためにも活用した。
（※文責: 山本賢人）
3.2
アジャイルプラクティス
3.2.1
インセプションデッキの作成
プロジェクトの方向性を明確にするため、また、プロジェクトメンバーの認識を統一させるた
め、インセプションデッキを作成した。インセプションデッキはいつでも振り返ることができ、プ
ロジェクトが方向性を見失ったときに、正しい方向へ修正することが可能になる。
（※文責: 山本賢人）
3.2.2
スタンドアップ・ミーティング
活動の始めに、前回の活動を報告する。各プロジェクトメンバーの活動に関して、気になる点、
改善点などがあれば、各自意見を述べる。一週間に 2 回しかないプロジェクト活動の振り返りに活
用した。なお、余分な時間がかかる報告になるのを防ぐためにプロジェクトメンバーは全員起立し
て行う。
（※文責: 山本賢人）
3.2.3
ポモドーロテクニック
作業時間と休憩時間を短いサイクルに区切る手法である。25 分間作業を行い、5 分間休憩をとる
というサイクルで、プロジェクト学習を行った。このように短く区切ることで、プロジェクトメン
バーのモチベーションを維持し、さらに作業効率を高める効果が期待できる。
（※文責: 山本賢人）
3.2.4
タスクかんばん
タスク管理には、前期では付箋を使ったタスクかんばんを採用していた。しかし、持ち運びが面
倒であり、プロジェクトの活動場所も変更があるため、後期では、Web サービスのタスク管理ツー
ルである、Pivotal Tracker を採用した。
タスクかんばんを用いると、タスクの進行状況が目に見えるようになり、かつ、自主的にタスク
を消化するよう促す効果があり、プロジェクトの生産性があがる。また、各タスクに見積もられた
コストもある程度明確になる。
（※文責: 山本賢人）
Group Report of 2012 SISP
- 12 -
Group Number 20-A
The New Portfolio System
テスト駆動開発
3.2.5
開発するシステムに必要な機能についてのテストを初めに書き、そのテストをパスする最低限の
実装を行った後、ソースコードをリファクタリングするというサイクルを繰り返し行う手法であ
る。アジャイルソフトウェア開発において推奨されている。本来テストとは、実装を確認するとい
う目的で書かれるものだが、テスト駆動開発では、設計をテストに落とし込み、それを通すように
実装する、という流れで開発を行う。テスト駆動開発を採用する利点は、バグがなくきちんと動作
し、さらに重複などがないきれいなソースコードを維持できるという点である。データベースの構
築の際に、テスト駆動開発を活用し、バグのない実装を行った。
（※文責: 山本賢人）
3.3
機能検討
ユーザストーリーの作成
3.3.1
前期に e-ポートフォリオシステムにおいて、どのような利用方法が想定されるか、ユーザース
トーリーを作成し、機能の検討をおこなった。また、各ストーリーで予想されるストーリーポイン
トを見積り、活動の計画を立てた。後期には、仕様を変更し、より詳細なユーザーストーリーを作
成した。
（※文責: 山本賢人）
3.4
ペーパープロトタイピング
ユーザーインタフェースの設計するため、ペーパープロトタイピングを用いた。ペーパープロト
タイピングのメリットは、紙を用いるため、悪い案を手軽に変更することができ、次々と良案を出
すことが可能となることである。また、レビュアーが開発者に対して設計コストを考慮する必要が
ないなどが挙げられる。デメリットは、実際のシステムとかけ離れたユーザーインタフェースを設
計することが可能となってしまうことが挙げられる。
（※文責: 山本賢人）
3.5
e-ポートフォリオシステムの調査
本学で使用する e-ポートフォリオシステムを開発するにあたって、既存の e-ポートフォリオシス
テムの調査や、導入すべき機能、改善すべき機能の洗い出しを行い、よりよい e-ポートフォリオシ
ステムの開発をめざした。本プロジェクトでは、既存の e-ポートフォリオシステムとして、現在、
最も利用されている Mahara ついて調査した。
（※文責: 山本賢人）
Group Report of 2012 SISP
- 13 -
Group Number 20-A
The New Portfolio System
3.6
計画作り
ストーリーポイント
3.6.1
ユーザーストーリーを見積る際に使う指標である。ユーザーストーリーごとに相対的なコストを
ストーリーポイントとして割り振る。手順としては、まず一番コストが大きいユーザーストーリー
にストーリーポイントの最大値を振る。次に、一番コストが小さいユーザーストーリーにストー
リーポイントの最小値を振る。最後に、他のユーザーストーリーに相対的なストーリーポイント
を割り振っていく。実際に、ストーリーポイントを割り振っていったが、急な割り込みタスクや、
誤った見積りによって、計画通りに進めることができなかった。
（※文責: 山本賢人）
プランニングポーカー
3.6.2
ストーリーポイントをユーザーストーリーに割り振る際に用いる手法である。プロジェクトメン
バーに各ユーザーストーリーにどのくらいのストーリーポイントを割り振るのが妥当かを同時に
聞く。プロジェクトメンバー間での意見が異なった場合、プロジェクトメンバー全員が納得する
意見が決定するまで議論をする。相手を納得させるだけの理由を考えるため、技術的な学習にも
なった。
（※文責: 山本賢人）
3.6.3
ベロシティ
チーム全体として一回のイテレーションでどれだけのストーリーポイントをこなすことが可能で
あるかを示す数値である。初めのイテレーションでは、チームでどのくらいのベロシティをこなせ
るのか不明であるため、おおよその値を設定しておき、イテレーションごとにベロシティを調整し
ていく必要がある。本プロジェクトでは、計画通りに進めることができず、正確なベロシティを予
測することができなかった。
（※文責: 山本賢人）
3.7
プロジェクトコミュニティに対するヒアリング
前期では、プロジェクトコミュニティから意見を得ておらず、e-ポートフォリオシステムに対す
る要求が不明瞭であったため、後期には、プロジェクトコミュニティに対してヒアリングを行っ
た。ヒアリングを行ったプロジェクトコミュニティは以下のとおりである。
• メタ学習センターセンター長
• メタ学習センター教員
• メタ学習ラボチューター
• 高度 ICT コースコース長
Group Report of 2012 SISP
- 14 -
Group Number 20-A
The New Portfolio System
ヒアリングは二人ペアで行った。各自質問した内容を記録するため、メモや録音を行っていた。
（※文責: 山本賢人）
3.8
振り返り
実施する予定のイテレーションの後や、前期、後期の後に振り返りを行う。本プロジェクトでは
KPT 分析を採用する。これは次回の活動に続けると良い内容、今回の活動で問題があり、次回の
活動では気をつけるべきこと、次回の活動で新たに挑戦してみることの３つに分けて振り返りを行
う。また、振り返りを行う際はプロジェクトメンバー全員で行い、１枚の大きな紙に集まって行っ
た。ブレーンストーミング形式で行い、その紙にそれぞれメンバーの意見を付箋に書いて貼り出し
た。そして、同じ意見や似ている意見等をグルーピングしたあとに、メンバーで出した意見に関し
て詳しく話し合いを行う。
（※文責: 山本賢人）
Group Report of 2012 SISP
- 15 -
Group Number 20-A
The New Portfolio System
第4章
4.1
課題解決のプロセスの詳細
プロジェクトを進めるにあたって
本プロジェクトでは、課題解決を行うにあたり、自己組織的なチームを目指した。なぜなら、よ
り良いソフトウェアを作成するには、プロジェクトメンバー各人の自律的行動が不可欠だからで
ある。そのため、開発手法として、アジャイルソフトウェア開発に取り組み、明確な役割分担を行
わずに活動を行った。また、作成するドキュメントは最小限とし、プロジェクトメンバー同士のコ
ミュ二ケーションを頻繁に行い、情報の共有を行った。
（※文責: 山本賢人）
4.1.1
役割分担
アジャイルソフトウェア開発では、明確な役割分担を行わない。しかし、本プロジェクトではプ
ロジェクトリーダーとプロジェクトマネージャーは明確な役割として設定した。これはプロジェ
クト学習を進めるにあたって、プロジェクトリーダーを決定する必要があるためである。そして、
プロジェクトリーダーの補助を行なってもらう役割が必要だと考えたため、プロジェクトマネー
ジャーを設定した。
実際の活動では、プロジェクトリーダーだけがプロジェクトの活動を進める役割を果たすのでは
なく、プロジェクトメンバーが自分の得意な分野で、その役割を果たせるように活動を進めた。ま
た、プロジェクトリーダーやプロジェクトマネージャーは、それぞれの役割だけを果たすのではな
く、取り組める活動には積極的に取り組むようにした。
後期に入り、システムの実装までプロジェクトが進むと、ペーパープロトタイピングを作成する
グループと、e-ポートフォリオシステムを実装するグループに分かれて活動を行った。これは、作
業の効率化を図り、プロジェクト活動をよりスムーズにするためである。それぞれの活動には、そ
の分野の得意なプロジェクトメンバーを必ず入れるようにし、そのプロジェクトメンバーを軸に活
動を行った。他のプロジェクトメンバーも、積極的に協力をして作業に取り組んだ。
（※文責: 木村幸太朗）
4.1.2
議事録
アジャイルソフトウェア開発では、作成するドキュメントを必要最低限に抑える。これは、手間
のかかるドキュメント作成に時間を費やすのではなく、システムの開発に時間を費やし、より効率
よく開発を行うためである。そのため、ドキュメントによる情報の共有の代わりとして、継続的な
活動と活発なコミュニケーションを行い、情報の共有を行った。しかし、プロジェクト学習では活
動が断片的であるため、このような情報の共有を行うことが困難であると考えた。そこで、本プロ
ジェクトでは必要最低限のドキュメントとして、議事録を作成することにした。議事録は活動日
ごとに作成し、その日の活動内容を次回の活動で振り返ることができる粒度で記載した。図の 4.1
Group Report of 2012 SISP
- 17 -
Group Number 20-A
The New Portfolio System
は、プロジェクト活動で実際に作成した、議事録の一部である。
図 4.1 議事録
（※文責: 木村幸太朗）
4.1.3
インセプションデッキ
アジャイルソフトウェア開発を行うにあたって、プロジェクトの全体像や方向性を明らかにする
ために、インセプションデッキ を使用した。インセプションデッキを使用するメリットは、プロ
ジェクトメンバー間でのプロジェクトに対する認識を、合わせられることである。また、プロジェ
クトメンバー以外に対して本プロジェクトの説明をする際も、インセプションデッキを用いて説明
することができる。
インセプションデッキは 10 の課題から構成され、それらの課題に回答することで、プロジェ
クトの全体像や方向性を明らかにすることができた。インセプションデッキの課題一覧を以下に
示す。
1 我々はなぜここにいるのか？
2 エレベーターピッチを作る
3 パッケージデザインを作る
4 やらないことリストを作る
5「ご近所さん」を探せ
6 解決案を描く
7 夜も眠れなくなるような問題はなんだろう？
8 期間を見極める
9 何を諦めるかをはっきりさせる
10 何がどれだけ必要なのか
「我われはなぜここにいるのか？」では、本プロジェクトが対象としている顧客と、本プロジェ
クトを開始する理由を明確にした。「エレベーターピッチを作る」では、プロジェクトの全体像を
Group Report of 2012 SISP
- 18 -
Group Number 20-A
The New Portfolio System
把握するために、本プロジェクトの概要を説明する 2 文を作成した。「パッケージデザインを作る」
では、本プロジェクトで作成するプロダクトに対する認識を合わせた。「やらないことリスト」で
は、本プロジェクトのスコープを明らかにした。「『ご近所さん』を探せ」では、プロジェクトコ
ミュニティを明確にした。
「解決案を描く」では、本プロジェクトで採用する技術や、システム全体
について検討した。「夜も眠れなくなるような問題は何だろう？」では、本プロジェクトで発生し
得る問題を洗い出し、リスクへの対処を考えた。「期間を見極める」では、全体の計画やリリース
計画を作成した。「何を諦めるのかはっきりさせる」では、本プロジェクトで重視すべき要素を決
定した。
「何がどれだけ必要なのか」では、プロダクトを作成するためにかかるコストを検討した。
前期の段階では、インセプションデッキの項目の中に、決定することのできない項目も含まれて
いた。その理由は、e-ポートフォリオシステムについての十分な知識や共通した認識を、プロジェ
クトメンバー間で共有できていなかったためである。そのため、後期に入ってから、インセプショ
ンデッキの再検討を行った。再検討の結果として、まず、「エレベータピッチを作る」・「やらない
ことリストを作る」の項目を、前期に比べより具体的に明記できたことである。また、「技術的な
解決策の概要」という項目を新たに用意し、使用する技術をプロジェクトメンバー全体で把握でき
るよう、図で表すことができた。
（※文責: 木村幸太朗）
4.1.4
スタンドアップ・ミーティング
前項でも取り上げたように、アジャイルソフトウェア開発では活発なコミュニケーションによっ
て情報の共有を行う。その方法の一つとして、スタンドアップ・ミーティングがある。これは、活
動の開始時にプロジェクトメンバー全員が立って行う、短いミーティングのことである。立って行
うことで、ミーティングを短い時間で済ませることができ、さらに共有する情報の質を向上させる
こともできる。本プロジェクトでは、このスタンドアップ・ミーティングを採用し、毎回の活動の
開始時に行い、情報を共有した。スタンドアップ・ミーティングでは、前回の活動で作成した議事
録をプロジェクトメンバー全員で確認した。そして、前回の活動の振り返り、今日の活動でやるべ
きこと、活動における問題点の認識と共有を行った。プロジェクト活動で実際に行われた、スタン
ドアップ・ミーティングの様子を下の図 4.2 に示す。
Group Report of 2012 SISP
- 19 -
Group Number 20-A
The New Portfolio System
図 4.2 スタンドアップ・ミーティング
（※文責: 和田聖矢）
4.1.5
付箋によるアイディア出し
プロジェクト活動を行う際に、アイディアを記述する媒体として付箋を用いた。付箋を用いるこ
とで、プロジェクトメンバー全員がアイディアを自主的に記述するようになり、それぞれの意見に
ついて検討することができた。また、アイディアのグルーピングを容易にできるというメリット
も、付箋を用いた理由である。そして、付箋を中心にブレインストーミングを行い、プロジェクト
メンバー間のコミュニケーションが活発になるように活動を進めた。
（※文責: 和田聖矢）
4.1.6
タスクの管理
作業の進捗をプロジェクトメンバー全体で共有することは、プロジェクトを進める上で重要なこ
とである。そのため、各人の作業の進捗状況を視覚的に表し、いつでもプロジェクトメンバー各人
の進捗を把握できるようにしなければならない。
前期では、その手段としてタスクかんばんを用いた。タスクかんばんとは、ホワイトボードや模
造紙を用意し、タスクを貼り付け、タスクの管理を行う手法である。また、載せるタスクを ToDo，
Doing，Done に分類し、進捗を把握できるようにする。本プロジェクトでは、ホワイトボードに
タスクが書かれた付箋を貼り、タスクの見える化をはかった。プロジェクト活動で実際に使われ
た、タスクかんばんを下の図 4.3 に示す。
Group Report of 2012 SISP
- 20 -
Group Number 20-A
The New Portfolio System
図 4.3 タスクかんばん
後期からは、タスクかんばんに代わり、Pivotal Tracker を用いた。Pivotal Tracker とは、タス
クかんばんの機能を Web アプリケーションとして表したものである。Pivotal Tracker は、アジャ
イルソフトウェア開発を支援するアプリケーションである。そのため、ベロシティを計算する機能
や、タスクに属性を持たせる機能を持っていることが特徴である。また、Web アプリケーションで
あるため、プロジェクトメンバー各人の自由なタイミングで、タスクを確認・共有することができ、
時間的または場所的な束縛が少ない。ホワイトボードと付箋を使ったタスクかんばんの問題とし
て、毎回活動時にタスクの書かれた付箋を貼るのは、手間であり非効率であることが問題に上がっ
たため、このような対処を取った。下の図 4.4 に、実際に用いた Pivotal Tracker の画像を示す。
Group Report of 2012 SISP
- 21 -
Group Number 20-A
The New Portfolio System
図 4.4
Pivotal Tracker
（※文責: 木村幸太朗）
4.2
4.2.1
採用技術の検討
Web アプリケーションフレームワーク
e-ポートフォリオシステムは、Web アプリケーションとして実現するため、Web アプリケー
ションフレームワークを選択する必要があった。そして、Web アプリケーションフレームがチー
ムの生産性に与える影響を調査し、最も生産性の高いものを選択した。Web アプリケーションフ
レームは、プログラミング言語の生産性にも依存している。そこでまずは、プログラミング言語の
生産性を測るために、メンバー全員に課題を与え、6 種類のプログラミング言語で課題に取り組ん
でもらった。完成したプログラムをメンバー全員で回覧し、可読性や保守性について検討し、結果
として Ruby を採用するに至った。そして、Ruby によって構築された Web アプリケーションフ
レームワークである Ruby on Rails を採用することに決定した。
（※文責: 山本賢人）
4.2.2
データベース
e-ポートフォリオシステムでは、学習の成果を蓄積するため、大量のデータや複雑なデータを扱
えるデータベースが必要である。また大量のアクセスに対応するためには、高速な処理が可能であ
Group Report of 2012 SISP
- 22 -
Group Number 20-A
The New Portfolio System
る必要もある。そこで、これらを実現することができるデータベースとして、NOSQL データベー
スである MongoDB を採用した。しかし、Windows への導入の段階で、予想以上に時間がかかっ
てしまった。また、導入することはできたが、使用する段階でも技術的課題が大きすぎたため、結
果として使用を断念した。後期からは、MongoDB に変わり、PostgreSQL を採用し実装を行った。
（※文責: 山本賢人）
4.2.3
バーション管理システム
e-ポートフォリオシステムのソースコードを管理するために、分散型バージョン管理システムで
ある Git を採用した。Git を採用した理由は、このシステムが GitHub という Git の Web ホス
ティングサービスを利用して、オープンソースで開発されるためである。また、ローカルなリポジ
トリを作成することができるため、アジャイルソフトウェア開発で頻繁に起こるコードの変更を容
易にすることができることも理由である。
（※文責: 山本賢人）
4.2.4
勉強会の実施
前述した技術は、大学の授業等で取り扱われない部分が多く、独自に習得する必要があった。そ
こで、前期・夏期休暇中を利用し、毎週金曜日に勉強会を開催した。勉強会は、プロジェクトメン
バーの一人が、他のプロジェクトメンバーに技術指導を行うようにした。プロジェクトメンバー全
員が参考書の予習を行い、指導担当のプロジェクトメンバーがプレゼンテーションによる指導を
行った。後期からは、プロジェクトメンバー各人の都合が合わないという場面が多々あり、結果的
に中断することとなった。
（※文責: 木村幸太朗）
4.3
ユーザーストーリーの作成
ユーザーストーリーとは、システム利用者の視点に立ち、考えられる利用法を想定するものであ
る。また、ユーザーストーリーは細かく設定していくので、各ストーリーの作業の見積りが可能と
なる。
（※文責: 木村幸太朗）
4.3.1
ユーザーストーリーの決定
e-ポートフォリオシステムは、システムの詳細が不明確であったため、システムのユーザース
トーリーを作成し、機能を明確にした。しかし、ユーザーストーリーを作成する際には、どのよう
なユーザーにフォーカスを当てるのかを決定する必要がある。そこで、本プロジェクトでは、公立
はこだて未来大学の学部３年生にフォーカスを当てて活動を行った。公立はこだて未来大学の学部
３年生にフォーカスを当てた理由は、まず、就職活動が本格化する学年であるためである。就職活
動では、学生の学習成果を他者へ発表する機会が多数存在する。そのような場面で、ポートフォリ
Group Report of 2012 SISP
- 23 -
Group Number 20-A
The New Portfolio System
オは自分の成果を他者へ発表する有効なツールであり、e-ポートフォリオシステムはそれを支援す
るアプリケーションである。また、ほかの理由として、プロジェクト学習等の個人ではなくチーム
で活動する機会が多い学年だからという点も挙げられる。チームをマネージメントする上で、情報
の共有は大変重要である。このような場面でも、e-ポートフォリオシステムを用いれば、チーム内
での成果物を容易に共有することができる。
システムのユーザーストーリーを決定していくにあたり、いきなりシステム全体のユーザース
トーリーを決定していくのは困難であった。そこで、各大機能 (データの蓄積・データの共有・他
者への公開・ポートフォリオ作成) を 4 つに絞り、一つずつユーザーストーリーを決定していった。
（※文責: 梅本祥平）
4.3.2
優先順位付け
それぞれのユーザーストーリーに優先順位をつけ、「価値のあるものにするにはどうすべきか」
を念頭におき、なにから実装していけばよいのか、無駄なものはなにか、また、必要な機能はなに
かを検討した。優先度はユーザー管理を行ううえで、なにが最低限必要な機能となるかを基準につ
けていった。
（※文責: 山本賢人）
4.3.3
前期と後期の違い
後期に入ってから、ユーザーストーリーの再検討を行った。ユーザーストーリーの再検討を行っ
た理由は、夏期休暇中に e-ポートフォリオシステムの分析が行われ、そこで各機能の再検討が行わ
れたためである。具体的な違いとして、まず、前期に比べ最低限必要な機能と、実装を後に回して
も良い機能とを、明確に分類することができた。また、システムの機能がどのように遷移していく
のかについて、具体的なイメージをプロジェクトメンバー全員で共有することができた。
（※文責: 山本賢人）
4.4
全体の計画づくり
アジャイルソフトウェア開発では、イテレーションを繰り返して開発を行う。各イテレーション
では、一部の機能を実装し、それを積み上げてシステム全体を完成させる。イテレーションの長さ
は、チームが一部の機能を完成させることができると推測される期間であること、チームが持続可
能なペースを実現できることを基準として決定した。プロジェクト学習の活動日数とイテレーショ
ンの長さから、イテレーションの回数を計算した。本プロジェクトでは、イテレーションの長さを
2 週間とし、プロジェクトの活動中には全体で 6 回のイテレーションを予定した。しかし、開発を
中断せざる負えなくなり、結果、イテレーションを予定通りに進めることはできなかった。
（※文責: 山本賢人）
Group Report of 2012 SISP
- 24 -
Group Number 20-A
The New Portfolio System
4.4.1
ユーザーストーリーの選定
ユーザーストーリーで挙げられた機能のうち、どの機能から実装していくのか検討した。そし
て、他の大機能に関するテストケースをつくる際などに、ユーザー管理機能が必要となってくるで
あると考えた。そこで、ユーザー管理機能に関するユーザーストーリーに絞り、ユーザーストー
リーを選定していった。
（※文責: 和田聖矢）
4.4.2
ユーザーストーリーの見積もり
プランニングポーカー
ストーリーポイントの振り分けを、プランニングポーカーという手法にのっとって行った。
プランニングポーカーとは、職能横断的に見積るために、プロジェクトメンバー全員でそれ
ぞれのユーザーストーリーが、どれほどのストーリーポイントを振るべきか多数決で決定し
ていく手法である。今回、ストーリーポイントの最低値を 1、最高値を 10 として、相対的
に振っていった。
ベロシティの予測
ベロシティとは、プロジェクト全体として一回のイテレーションで、どれだけのストーリー
ポイントをこなせるかの数値である。初めのイテレーションは、ベロシティがまだ定まって
いないため、ベロシティの予測からすることとなっている。ポイントが振られたストーリー
を見直し、最低限必要な機能、可能ならば実装しておきたい機能、時間的に余裕があれば実
装する機能、実装しない機能の 4 つに分類した。また、イテレーションのゴールとして、最
低限必要な機能の実装と設定した。そこで、最低限必要な機能のストーリーポイントを合計
したものを、その回のイテレーションでこなせるストーリーポイントとし、ベロシティとし
て見積った。
タスクの洗い出し
イテレーションで実装する機能が決定したところで、実装するには各ストーリーにどのよ
うなタスクがあるのか、洗い出さなければいけない。そこで、ユーザーストーリーをタスク
に分解し、さらにそれぞれのタスクの優先順位を決定したのち、タスクかんばんを作成し
た。タスクの管理は、前期ではホワイトボードと付箋を用いたタスクかんばんを、後期では
Pivotal Tracker を用いた。タスクかんばんを活用したことで、タスクの進捗を見える化す
ることができ、プロジェクトメンバーそれぞれが自由にかんばんを操作することができるの
で、自主的に作業を促進する効果を得られた。
（※文責: 木村幸太朗）
Group Report of 2012 SISP
- 25 -
Group Number 20-A
The New Portfolio System
4.5
システム全体のペーパープロトタイピング
前期では、システムの全体像が決定すると、e-ポートフォリオシステムのユーザー管理機能の
ユーザーインタフェースを設計をするために, プロジェクトメンバーがペアとなってペーパープロ
トタイピングを行った。ペーパープロトタイピングとは、紙を用いるプロトタイピングの手法であ
る。必要となるページ、考えられるページの動き、ボタンの挙動などを、具体的に紙に描いていっ
た。ペーパープロトタイピングを行ったことにより、あいまいだったシステムの利用の流れが把握
できた。
後期に入ってから、システムの機能が再検討されたため、もう一度、システムのペーパープロト
タイプを作成することとなった。ここでは、メンバー全員が作成に携わるのではなく、グループを
２つに分け、片方がペーパープロトタイピングの作成、もう片方がデータベース設計の活動を行っ
た。前期に比べると、機能がより明確になったため、考えられるページの動きや必要なボタンの挙
動・全体のレイアウトや画面の遷移をより具体的に作成することができた。
（※文責: 木村幸太朗）
4.6
データベース設計
後期に入り、実装する機能をユーザーストーリーから決定したため、続いてデータベースの設計
を行った。データベースを設計するにあたって、まず、各機能ごとにどのような型のデータが必要
なのかについて検討した。その結果、
「学生アカウント」
・
「グループ」
・
「ポートフォリオ」
・
「コメン
ト」
・
「テキスト」の機能に分けられ、それに対し、それぞれに必要なデータの型を決定した。デー
タベースに必要なデータの方については、プロジェクトメンバー全員で検討したが、実装からはグ
ループを２つに分けて活動を行った。
（※文責: 木村幸太朗）
4.7
e-ポートフォリオシステムの分析
既存の e-ポートフォリオシステムの分析を行った。分析を行った理由は、まず、e-ポートフォリ
オシステムの全体像を把握するためである。e-ポートフォリオシステムは、各人によって考え方が
異なるため、公立はこだて未来大学にとって真に必要な e-ポートフォリオシステムの機能とは、ど
のようなものであるのかを検討する必要があった。次に、既存の e-ポートフォリオシステムの利点
と欠点を明確にするためである。その理由は、既存の e-ポートフォリオシステムのどのような部分
が使いづらいのか、また、どのような部分が使いやすいのかを明確にし、今後の開発に活かしてい
くためである。
（※文責: 木村幸太朗）
Group Report of 2012 SISP
- 26 -
Group Number 20-A
The New Portfolio System
4.7.1
学内ポートフォリオについて
学内の「HARBOR VIEW SITE」にある学内ポートフォリオの分析を行った。その結果、まず、
学内ポートフォリオに対しての、学生の認知度があまり高くないということがわかった。これは、
大学側から学内ポートフォリオに関するアナウンスが少なく、学生がその存在に気付けないでいる
ことが原因であると考えられる。次に，学習成果を蓄積するのに手間がかかることがわかった。。
これも、上記した内容が原因だと考えられる。最後に、自分の学習成果を、学外へ発信することが
できない点が挙げられる。
（※文責: 木村幸太朗）
4.7.2
Mahara について
既存に存在するポートフォリオシステム、「Mahara」について分析を行った。その結果として、
まず、オープンソースソフトウェアであるため、システム内の機能が十分ではない。さらに、シス
テム内の機能が多すぎるため、ユーザーがどのように使っいいのかわからないという結果にもなっ
ている。また、本学に最適化されたシステムではないため、学内への導入が難しい。以上から、本
学に最適化されたシステムであり、ユーザーアビリティを考えたシステムが必要であるという結論
に至った。
（※文責: 梅本祥平）
4.8
プロジェクトコミュニティに対するヒアリング
既存の e-ポートフォリオシステムの分析の結果、公立はこだて未来大学に適した e-ポートフォリ
オシステムを作成しなければならないことがわかった。しかし、ポートフォリオ自体の定義があい
まいで、各人によって認識が異っている。そのため、プロジェクトコミュニティへのヒアリングを
行い、本学に適した e-ポートフォリオシステムの定義を決定する必要があった。ヒアリングの対象
は、メタ学習センターのセンター長など、e-ポートフォリオシステムに対して、関心度の高い人・
知識のある人を対象とした。ヒアリングの結果としては、まず、学部１年から院生まで全学年的に
使えるシステムにして欲しいという要望があった。さらに、学生と教員とが使えるシステムを作っ
て欲しいという要望もあった。また、既存の e-ポートフォリオシステムはオープンソースソフト
ウェアであるため、各種機能が不十分であること、機能が多すぎるといった指摘もあった。
（※文責: 中野佑）
4.9
振り返り
本プロジェクトでは６回行われるイテレーションごとと、前期と後期で KPT 分析による振り返
りを行う予定だった。しかし、イテレーションが開発途中で中断してしまい、イテレーションの振
り返りは行うことができなかった。後期では企業講師による振り返りがプロジェクト合同で行わ
れ、用意されたテンプレートに従って付箋にメンバー同士で意見を出し合った。また、メンバーや
Group Report of 2012 SISP
- 27 -
Group Number 20-A
The New Portfolio System
お世話になった方々へ向けたメッセージも出してグルーピングを行い、他のプロジェクトへ向けて
発表をした。
（※文責: 山本賢人）
4.10
今後について
4.10.1
プロダクトオーナーの決定
e-ポートフォリオシステムの全体像が各人によって異なることから、それを統括し、公立はこだ
て未来大学に適した e-ポートフォリオシステムの定義を決定する必要がある。そこで、e-ポート
フォリオシステムの定義を決定し、各種機能を決定するプロダクトオーナーを決定することとし
た。現在、プロダクトオーナーはまだ決定しておらず、今後検討していく予定である。
（※文責: 木村幸太朗）
4.10.2
プロジェクトコミュニティでの会議の設定
プロダクトオーナーの決定後、e-ポートフォリオシステムについての、プロジェクトコミュニ
ティでの会議を予定している。想定している会議の内容は、公立はこだて未来大学に適した e-ポー
トフォリオシステムの定義を決定することである。またその他にも、システムの具体的な機能につ
いてや、プロジェクトコミュニティを本プロジェクトへ積極的に巻き込みたいという要望を提示す
ることが挙げられる。
（※文責: 梅本祥平）
4.11
各人の課題の概要とプロジェクト内における位置づけ
プロジェクトメンバー全体で活動するため、各人の担当課題は概ね同じである。しかし、後期か
らグループに分けて活動を行ったため、プロジェクトメンバーによって担当課題が多少異なる場面
も見られた。各プロジェクトメンバーの課題を以下に示す。
（※文責: 木村幸太朗）
4.11.1
木村幸太朗
4月
技術習得
5月
技術習得・インセプションデッキの作成・全体の計画づくり
6月
第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成
8月
技術習得
9月
技術習得
10 月 インセプションデッキの再検討・ペーパープロトタイピングの再作成ユーザーストーリー
の再検討
Group Report of 2012 SISP
- 28 -
Group Number 20-A
The New Portfolio System
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成
1月
最終報告書の作成
（※文責: 木村幸太朗）
4.11.2
梅本祥平
4月
技術習得・技術指導
5月
技術習得・技術指導・インセプションデッキの作成・全体の計画づくり
6月
ペーパープロトタイピング・第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成
8月
技術習得・技術指導・e-ポートフォリオシステムの分析
9月
技術習得・技術指導・e-ポートフォリオシステムの分析
10 月 インセプションデッキの再検討・データベース設計・ユーザーストーリーの再検討
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成
1月
最終報告書の作成
（※文責: 梅本祥平）
4.11.3
山本賢人
4月
技術習得
5月
技術習得・インセプションデッキの作成・全体の計画づくり
6月
ペーパープロトタイピング・第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成
8月
技術習得
9月
技術習得
10 月 インセプションデッキの再検討・データベース設計・ユーザーストーリーの再検討
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成
1月
最終報告書の作成
（※文責: 山本賢人）
4.11.4
和田聖矢
4月
技術習得
5月
技術習得・インセプションデッキの作成・全体の計画づくり
6月
ペーパープロトタイピング・第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成
8月
技術習得・e-ポートフォリオシステムの分析
Group Report of 2012 SISP
- 29 -
Group Number 20-A
The New Portfolio System
9月
技術習得・e-ポートフォリオシステムの分析
10 月 インセプションデッキの再検討・ペーパープロトタイピングの再作成・ユーザーストーリー
の再検討
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成
1月
最終報告書の作成
（※文責: 和田聖矢）
4.11.5
菊谷悠太
4月
技術習得
5月
技術習得・インセプションデッキの作成・全体の計画づくり
6月
ペーパープロトタイピング・第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成
8月
技術習得・e-ポートフォリオシステムの分析
9月
技術習得・e-ポートフォリオシステムの分析
10 月 インセプションデッキの再検討・データベース設計・ユーザーストーリーの再検討
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成
1月
最終報告書の作成
（※文責: 菊谷悠太）
4.11.6
中野佑
4月
技術習得
5月
技術習得・インセプションデッキの作成・全体の計画づくり
6月
ペーパープロトタイピング・第１回イテレーション計画づくり・ユーザーストーリーの作成
7月
中間報告書の作成・前期の振り返り
8月
技術習得・e-ポートフォリオシステムの分析
9月
技術習得・e-ポートフォリオシステムの分析
10 月 インセプションデッキの再検討・ペーパープロトタイピングの再作成・ユーザーストーリー
の再検討
11 月 プロジェクトコミュニティに対するヒアリング・最終成果発表の準備
12 月 最終成果発表・最終報告書の作成・プロジェクト全体の振り返り
1月
最終報告書の作成
（※文責: 中野佑）
Group Report of 2012 SISP
- 30 -
Group Number 20-A
The New Portfolio System
4.12
担当課題解決過程の詳細
4.12.1
木村幸太朗
技術習得
e-ポートフォリオシステムを開発するにあたり、新規技術を導入するため、プロジェクトメ
ンバー全員で技術習得を行った。しかし、技術習得をプロジェクト活動内で行うのは困難で
あったため、プロジェクト活動外に勉強会を設け、自主的に技術習得を行った。勉強会の形
式はプレゼンテーション形式で行った。各自が題材となっている技術について勉強をし、そ
の成果をプレゼンテーション形式でプロジェクトメンバーに発表する。プロジェクトメン
バーもまた、プレゼンテーションから技術の共有ができるよう努めた。
結果的には、システム開発を実現できるだけの技術を、プロジェクトメンバー全員で共有す
ることができた。
インセプションデッキの作成
プロジェクトの方向性を明確にするために、インセプションデッキを作成した。
インセプションデッキを作成することで、プロジェクトメンバーの e-ポートフォリオシス
テムに対する認識を統括することができた。また、インセプションデッキを適時確認するこ
とで、プロジェクトの方向性を修正することができた。インセプションデッキは、前期と後
期に 1 度ずつ作成した。後期での作成では、e-ポートフォリオシステムの詳細がより明確に
なっていたため、前期に比べ、より具体的なインセプションデッキを作成することができた。
ユーザーストーリーの作成
e-ポートフォリオシステムの機能を決定する際、ユーザーストーリーを用いて検討をした。
ユーザーストーリーを作成する際には、自分がシステム利用者であるとことを想定し、ユー
ザー視点から機能を検討できるよう努めた。そのため、よりリアリティのあるユーザース
トーリーを作成することができた。また、機能を検討する際は、機能をより細かい段階まで
掘り下げた。そのため、機能がどのように使われるのかや、画面の遷移がどうなっていくの
かを予想しながら、ユーザーストーリーを作成することができた。
ペーパープロトタイプの作成
e-ポートフォリオシステムの具体的な機能が決定した後、ペーパープロトタイピングを行っ
た。ペーパープロトタイプを作成する際には、機能の詳細を紙で分かりやすく伝えられるよ
うに努力した。その結果、画面の遷移や機能の流れを視覚的に表すことができた。また、ボ
タンの配置や全体のレイアウトなど、一画面にどういう種類の情報を、どれだけ載せるのか
考えて作成した。その結果、ユーザーエクスペリエンスについて学べた。
プロジェクトコミュニティに対するヒアリング
既存の e-ポートフォリオシステムについて、プロジェクトコミュニティに対してヒアリング
を行った。ヒアリングを行った理由は、既存の e-ポートフォリオシステムの現状を知り、今
後の開発に活かしいくためである。
ヒアリングの結果から、既存のポートフォリオシステムのデメリットを明確にすることがで
Group Report of 2012 SISP
- 31 -
Group Number 20-A
The New Portfolio System
きた。また、ヒアリングを受けていただいた教員から、e-ポートフォリオシステムに対する
具体的な要望や意見をいただいた。
（※文責: 木村幸太朗）
4.12.2
梅本祥平
メンバーへの技術指導
e-ポートフォリオシステムを開発するにあたって、本プロジェクトではアジャイルソフト
ウェア開発を適用した。アジャイルソフトウェア開発については、一部の内容が講義で取り
上げられるものの、具体的な内容については説明されない。そのため、アジャイルソフト
ウェア開発について独自に学習する必要があった。そこで、昨年度の高度 ICT プレコース
での活動経験に基づき、プロジェクトメンバーにアジャイルソフトウェア開発についての指
導を行った。特に、アジャイルソフトウェア開発における見積りと計画づくりや、アジャイ
ルソフトウェア開発を支えるプラクティスについて指導を行った。
アジャイルプラクティスの導入
インセプションデッキやユーザーストーリー、ストーリーポイントによる見積りやスタンド
アップ・ミーティングといったアジャイルプラクティスを、本プロジェクトに導入した。
技術採用についての提案
本プロジェクトの初期では、Java による Web アプリケーション開発を検討していた。し
かし、Java による Web アプリケーション開発は、技術的コストが高いと考えていたため、
Ruby 及び Ruby on Rails による Web アプリケーション開発を提案した。
インセプションデッキの作成
プロジェクトの方向性を明らかにするため、インセプションデッキの作成を行った。インデ
プションデッキで示される 10 の課題に回答するため、リーダーとしてメンバーの意見を引
き出すようにした。
全体の計画づくり
イテレーションの長さを決めるための基準を提案した。そして、実際にイテレーションを行
なってから長さを調整することにした。
ユーザーストーリーの作成
ユーザーストーリーを作成する際に、システムを利用する立場からストーリーを検討した。
イテレーション計画づくり
ストーリーポイントを使用して、ユーザーストーリーの見積りを行った。メンバー全員に
よって見積りが行われるので、他のメンバーと見積りが異なっているメンバーの意見を聞
き、より正確な見積を行うようにした。
e-ポートフォリオシステムに関する調査
Group Report of 2012 SISP
- 32 -
Group Number 20-A
The New Portfolio System
e-ポートフォリオシステムの先行事例を調査した。特に、ポートフォリオそのものに関する
内容について調査し、プロジェクトメンバーと情報を共有した。
プロジェクトコミュニティに対するヒアリング
プロジェクトコミュニティとプロジェクトの間で、e-ポートフォリオシステムに対する意見
の相違が見られたため、プロジェクトコミュニティに対してヒアリングを行った。
e-ポートフォリオシステムの開発
e-ポートフォリオシステムの一部を実装した。e-ポートフォリオシステムで管理されるデー
タに対する作成、読出、削除、更新を行えるようにした。
（※文責: 梅本祥平）
4.12.3
山本賢人
インセプションデッキの作成
プロジェクトの方向性がぶれないようにするためのドキュメントである、インセプション
デッキの作成をした。インセプションデッキには１０の質問と課題があり、それぞれの答え
となるものを考えて、回答していった。本プロジェクトでは、プロジェクト立ち上げ時と、
後期のはじまった時とで二回インセプションデッキを作成、見直しを行った。我々はなぜこ
こにいるのかという問いに対して、このプロジェクトの当初の目的を思い出し、意見を出し
た。エレベーターピッチ作成では、実際に 30 秒ほどでスムーズに説明が可能かどうか確か
めた。やらないことリスト作成では、残り時間を見積り、機能を見直し、やること、やらな
いことを再検討した。
ユーザーストーリーの作成
e-ポートフォリオシステムを利用すると想定されるユーザーが、どのようにシステムを利用
するかを考えた。実際に、e-ポートフォリオシステムを利用していると想像し、ログイン時
からログアウト時までの利用の流れを考え、必要だと思われる機能を洗い出していった。
計画ゲーム
各イテレーションで実装すべき機能を、ユーザーストーリー単位で見積っていった。プロ
ジェクトメンバーが各ユーザーストーリーについて、どのくらいコストがかかるか意見を出
し合って、納得する見積りを設定していった。プロジェクトメンバーと意見が異なった際に
は、なぜ相手は違うコストであると見積ったのか考えた。また、自分の見積りが正しいとい
える理由を相手に説得した。
ペーパープロトタイプの作成
前期のペーパープロトタイピングに携わった。前期の時点で想定していたユーザーストー
リーに基づき、システムのユーザーインタフェースを紙におこしていった。
e-ポートフォリオシステムの調査
夏期休暇の際に e-ポートフォリオシステムについて調査をしていたのだが、参加することが
Group Report of 2012 SISP
- 33 -
Group Number 20-A
The New Portfolio System
できず、プロジェクトメンバー、また担当教員がまとめた e-ポートフォリオシステムに関し
ての調査結果を議事録にて確認した。e-ポートフォリオシステムが、まず、どのような目的
で活用されているのか、どのように作成するのか、現在利用されている e-ポートフォリオシ
ステムの欠点はなんなのかを学ぶことができた。
データベース構築
e-ポートフォリオシステムのデータベースを実装した。e-ポートフォリオシステムの利用者
であるアカウント、利用者同士のグループ、多対多であるためグループとアカウントを関連
付けるためのテーブル、利用者のポートフォリオ、利用者が蓄積する学習成果物の 5 つの
テーブルを作成した。これらのデータベースを構築する際にテスト駆動開発を行った。
プロジェクトコミュニティに対するヒアリング
e-ポートフォリオシステムへの要求を明確にするために、重要と思われるプロジェクトコ
ミュニティにヒアリングを行い、システムに対する要求を分析した。ヒアリングの際に、質
問した内容をメモにとった。また、すべてメモをとることが不可能であるとおもったため、
質問した際に録音をおこなった。
（※文責: 山本賢人）
4.12.4
和田聖矢
議事録作成
活動の振り返りや、プロジェクトメンバー間の情報共有を行うために、議事録を作成した。
議事録には、その日に行ったこと、決定したこと、次回の活動で行うこと等を記録した。議
事録の作成は、プロジェクトメンバーが毎回交代で行った。
インセプションデッキ作成
本プロジェクトでは、アジャイルソフトウェア開発への取り組みの一環として、インセプ
ションデッキの作成を行った。インセプションデッキは、プロジェクトの全体像や方向性を
示すためのドキュメントである。インセプションデッキは、10 の質問と課題から構成され
る。それらに答えることにより、プロジェクトの全体像や方向性を確かにしていく。また、
インセプションデッキの作成にプロジェクトメンバー全員で取り組むことにより、プロジェ
クトに対するプロジェクトメンバーの認識を合わせることができる。
インセプションデッキの作成は、プロジェクト開始時に一度行い、後期のプロジェクト見直
し時にもう一度行った。また、状況に応じてインセプションデッキの更新を行った。プロ
ジェクト開始時のインセプションデッキ作成では、プロジェクトメンバーが作成に必要な知
識を得るため、プロジェクトリーダーからインセプションデッキについての説明を聞いた。
インセプションデッキを作成することによって、どのような効果が得られるか、また、作成
にあたっての注意を教わった。プロジェクトメンバー全員で意見を出し合い、認識をあわせ
ながら、作成を進めた。
計画づくり
Group Report of 2012 SISP
- 34 -
Group Number 20-A
The New Portfolio System
計画は、イテレーション毎に、どういった機能をリリースしていくか、開発に必要な作業は
何かを考え作成した。リリースする機能のスコープや優先順位は、ユーザーストーリーから
の機能抽出、プランニングポーカー等を行い決定した。前期に、1 年を通しての大まかな計
画を作成したが、e-ポートフォリオ分析の結果を受け、後期に計画を作り直した。
開発環境の構築
Ruby on Rails を用いた Web アプリケーション開発や、Git によるバージョン管理を行うた
めの環境構築を行った。Ruby、Ruby on Rails は、それぞれ最新のバージョンをインストー
ルした。また、統合開発環境である、Aptana Studio3 をインストールし、文字コードやイ
ンデント等の細かい設定をプロジェクトメンバー間で統一した。データベースに、NOSQL
データベースである MongoDB を使用するため、MongoDB の安定版をインストールした。
Git に関しては、開発リポジトリをプロジェクトメンバー間で共有するために GitHub を
利用することにした。プロジェクトメンバー全員が、GitHub へのアカウント登録を行い、
GitHub 上に開発リポジトリを作成した。
技術習得（前期）
e-ポートフォリオシステムを開発するためには、いくつかの必要な技術や知識について新た
に学ぶ必要があった。採用技術の検討を行った際に、Ruby on rails を使用して開発を行う
ことが決まっていたので、Ruby、Ruby on Rails の学習は必須であった。また、本プロジェ
クトではアジャイルソフトウェア開発に取り組むことを課題としており、アジャイルソフト
ウェア開発に取り組む上で必要な前提知識を得る必要があった。そのため、アジャイルソフ
トウェア開発についての勉強を行うことにした。Ruby、Ruby on Rails に関しては、プロ
ジェクトメンバーが参考書を使い自習し、その後に輪講形式の勉強会で学習するという流れ
で技術習得を試みた。勉強会では、事前に作成した発表用のスライドを使用した。また、ス
ライドによるプレゼンテーションだけでなく、実際にその場でプログラムを作成するなど、
より体験的な勉強会となるよう心がけた。
技術習得（夏季休暇期間）
前期で、勉強会を何度か行ったが、不十分であったため、夏季休暇を利用して勉強会を行い、
技術習得を行った。プロジェクトメンバー全員で、習得すべき技術について話し合った。話
し合いの結果、MongoDB、Git、GitHub、ユニットテスト、プロトタイピング、HTML5、
継続的インテグレーションについて学習することとした。
ユーザーストーリーの作成
e-ポートフォリオシステムに必要な機能、求められている機能を洗い出すために、ユーザー
ストーリーを考えた。各プロジェクトメンバーがブレインストーミング形式でユーザース
トーリーを考え、その結果をもとに必要な機能、不必要な機能について議論した。
ペーパープロトタイピング
ペーパープロトタイピングは、開発を進める前に、ユーザーインタフェースのテストを行う
ためのプロトタイプを紙で作成する作業である。紙で作成することにより、変更が容易にで
き、ユーザーインターフェース設計のミスの確認と変更を容易に行うことができる。前期に
Group Report of 2012 SISP
- 35 -
Group Number 20-A
The New Portfolio System
ペーパープロトタイピングを行ったが、後期にプロジェクトの見直しを行ったため、その後
もう一度ペーパープロトタイピングを行った。
前期では、まず必要な機能から、大まかにどのような画面が必要かを考えた。次に、各画面
に必要なフォームやボタンを書き加えた。後期では、より詳細なペーパープロトタイプの作
成を目指した。特に、画面遷移や動的なアイテム、データベースの各データ要素に留意して
作成を行った。
e-ポートフォリオシステムの分析
中間発表での、既存製品の調査が必要との意見を受け、夏季休暇中に e-ポートフォリオシス
テムについての分析を行った。既存の e-ポートフォリオシステムである Mahara を実際に
利用し調査を行った。また、e-ポートフォリオの必要性、海外での利用例等について調査し
た。
プロジェクトコミュニティに対するヒアリング
プロジェクトコミュニティの意見を収集するために、プロジェクトコミュニティに対するヒ
アリングを行った。プロジェクトコミュニティに属する人全員にヒアリングを行うことは、
時間の都合上難しいと判断した。そのため、まずはプロジェクトメンバー間でプロジェクト
コミュニティの中でも重要な人物を 3 人決め、ヒアリングの対象とした。次に、プロジェク
トメンバー間での話し合いにより、ヒアリングでの質問事項を決めた。ヒアリング対象であ
る 3 人にコンタクトを取り、決まった質問事項を元にヒアリングを行った。ヒアリングで得
られた意見より、今後本プロジェクトがどのように活動して行くのかを再検討した。
（※文責: 和田聖矢）
4.12.5
菊谷悠太
必要な物品購入
必要に応じて、プロジェクトに必要な物品の購入を行った。活動中に物品購入するときがあ
り、自分が活動教室にいない間、プロジェクトメンバーが何をやっていたか議事録で確認し
た。
計画
まず、全体の大まかな計画を立てた。各イテレーションの最初の工程でイテレーションの計
画を詳細に決めていった。計画で出てきたタスクに時間がどれくらいかかるかプロジェクト
メンバー全員で話し合い、全員が納得するまで話し合って決めた。
インセプションデッキ
インセプションデッキの作成は、プロジェクトメンバーが全員で行いプロジェクトの目的を
統一させるために作成した。前期で一度作成したが、システムの全体像が明確化されていな
い状態であった。夏期休暇に e-ポートフォリオを研究することで、自分たちの作るシステム
の全体像が明確になったので再度作成した。インセプションデッキ作成の際に、顧客と一緒
に行うことができなかった。
Group Report of 2012 SISP
- 36 -
Group Number 20-A
The New Portfolio System
ユーザーストーリーの作成
システムを利用するユーザーの立場になってシステムに必要な機能を洗い出した。付箋でプ
ロジェクトメンバー各人が自分のアイディアを書き、プロジェクトメンバー全員で必要な機
能はどれか話し合って決めた。
e-ポートフォリオシステムの分析
e-ポートフォリオシステムの分析を行った。既存の e-ポートフォリオシステムである
Mahara について調査した。Mahara には、どのような機能があるか、本学のシステムに適
している機能はあるかを調べた。実際に Mahara を使って、ユーザビリティーの調査を行っ
た。
ペーパープロトタイプのレビュー
顧客に、本プロジェクトで開発するポートフォリオシステムを説明するために、ペーパープ
ロトタイプを作成した。作成されたペーパープロトタイプに対してのレビューを行った。プ
ロジェクトメンバー間でレビューをするのは、プロジェクトコミュニティに見せるものの
質を上がるためである。レビューの内容として、次のページに遷移するボタンがないこと、
トップページに戻るリンクがないことを指摘した。
e-ポートフォリオシステムのデータベース
新ポートフォリオのデータベースはアカウント、グループ、コメント、テキスト、ポート
フォリオ、アカウントとグループの関係が多対多の関係だったので、アカウントとグループ
をリンクさせるものの計６つのテーブルで作成した。このうちのグループとポートフォリオ
のテーブルを作成した。
プロジェクトコミュニティに対するヒアリング
プロジェクトコミュニティの意見がまとまってなく、プロジェクトコミュニティに対してヒ
アリングを行った。ヒアリングの対象は、プロジェクトコミュニティと専門家の意見を取り
入れるために、本学で e-ポートフォリオについて詳しいと思われる人を対象に行なった。
（※文責: 菊谷悠太）
4.12.6
中野佑
議事録
活動の振り返りや、プロジェクトメンバー間の情報共有を行うために、議事録を作成した。
議事録には、参加者や日付はもちろん、その日に行ったことや決定したこと、次回の活動予
定などを記録した。作成の際にはプロジェクトに全く関わっていない人でも読んだときに全
く同じ活動ができるように記述する必要がある。議事録の作成は、プロジェクトメンバーが
毎回ローテーションで行った。
インセプションデッキの作成
プロジェクトの方向性を明らかにするため、インセプションデッキの作成を行った。インデ
Group Report of 2012 SISP
- 37 -
Group Number 20-A
The New Portfolio System
プションデッキで示される 10 の課題に回答することでプロジェクトの全体像を明らかにす
ることができた。
全体の計画づくり
イテレーションの長さを決め、最終成果発表に向けてイテレーションの回数を設定した。そ
して、実際にイテレーションを行なってから、長さを調整することにした。
ユーザーストーリーの作成
システムを利用する立場の目線から、利用シーンを想定して作成した。ブレーンストーミン
グ形式で付箋を用いてメンバーで意見を出し合い、グルーピングを行った。
イテレーション計画づくり
ユーザーストーリーの見積りを、ストーリーポイントを使用して行った。その際にも、設定
したストーリーポイントに対して、プロジェクトメンバーが納得できるような理由を考え
た。その後、実装すべきストーリーに優先度をつけてスコープの設定をし、ストーリーポイ
ントがベロシティを超えないようにした。
e-ポートフォリオシステムの分析
既存のシステムとの比較を行うため、e-ポートフォリオシステムの先行事例を調査した。特
に、Mahara について実際に使ってみるなどして良い点や悪い点などを洗い出した。
プロジェクトコミュニティへのヒアリング
e-ポートフォリオシステムを開発するにあたって、プロジェクトコミュニティとの意見の相
違が見られた。そのため、e-ポートフォリオシステムの研究を行なっている専門家や、プロ
ジェクトコミュニティに対して直接会って話を聞いた。
ペーパープロトタイピング
作成したユーザーストーリーからシステムのイメージがしやすいように、紙で画面設計を
行った。特にユーザー目線となって、ユーザビリティに気をつけて作成した。
振り返り
イテレーションの終わりと、前期と後期の終わりに KPT 分析手法で振り返りをメンバーで
行う。それぞれ次回の活動で続けるとよいこと、問題のあった点、新しく挑戦してみたいこ
との三つに分けてブレーンストーミング形式を採用した。その後、自分が出した意見を付箋
に書き出し、プロジェクトメンバー全員で共有をした。
（※文責: 中野佑）
Group Report of 2012 SISP
- 38 -
Group Number 20-A
The New Portfolio System
第5章
5.1
結果
結果の概要
本プロジェクトは、e-ポートフォリオシステムの開発に取り組んだ。e-ポートフォリオシステム
の中心となる３つの機能（記録、共有、発信）を実装をすることを目標として活動した。成果物と
して、インセプションデッキやペーパープロトタイプ、データベース等を作成した。しかし、目標
であるシステムの実装することはできなかった。
（※文責: 和田聖矢）
5.2
システム開発の結果
本プロジェクトの目的は、本学の e-ポートフォリオシステムを Web アプリケーションとして開
発し、アジャイルソフトウェア開発を実践することである。プロジェクトで必要な技術を習得する
ために、勉強会を実施して必要な技術を学び、プロジェクトの計画を作成した。アドバイザーのレ
ビューで、顧客がいなければプロジェクトは失敗すると助言された。顧客を取り入れずに行う提案
型の開発から顧客を巻き込む開発に変えた。顧客を巻き込む開発の計画をもとにシステムのプロト
タイプを作成し、顧客に見せたがそのシステムは受け入れてもらえなかった。
最終的な結果は、本学の e-ポートフォリオシステムを Web アプリケーションとして開発するこ
とができなかった。
（※文責: 菊谷悠太）
5.3
5.3.1
プロジェクトコミュニティに対するヒアリングの結果
メタ学習センター長へのヒアリング結果
メタ学習センター長へのヒアリングを行った。メタ学習センター長からの e-ポートフォリオシ
ステムに対する要望は、全学的に e-ポートフォリオシステムを導入したいため、全学生を e-ポート
フォリオシステムのユーザーとして想定して欲しいというものであった。また、メタ学習センター
への積極的な関与と、e-ポートフォリオシステムの段階的な詳細化も要望として挙がった。
オープンソースソフトウェアの e-ポートフォリオシステムに対しては、ユーザーインタフェース
に問題があるため、新規に開発して欲しいとのことであった。また、核となる部分をシステムとし
て作り、すでに本学で導入済みのラーニング・マネジメント・システムや、他のサービスと連携し
てはどうかという提案があった。
（※文責: 梅本祥平）
Group Report of 2012 SISP
- 39 -
Group Number 20-A
The New Portfolio System
5.3.2
メタ学習センター教員へのヒアリング結果
メタ学習センター教員へのヒアリングを行った。メタ学習センター教員からの e-ポートフォリオ
システムに対する要望は、学習の成果を就職活動で役立てる目的で、e-ポートフォリオシステムを
利用したいというものであった。また、就職活動以外に、プロジェクト学習での自己紹介や教員へ
のアピールといった用途も想定しているとのことであった。想定されるユーザーは 1 年生から卒業
生までで、学習の振り返りができるものが望ましいとのことであり、前述のメタ学習センター長が
想定しているユーザーよりも、より幅が広いユーザを想定しているとのことであった。
提案として、現在、本学で行われている授業フィードバックとの連携が挙げられた。また、e-ポー
トフォリオシステムのリリースにあたり、学生モニターを設定してはどうかという提案もあった。
（※文責: 梅本祥平）
5.3.3
メタ学習ラボチューターへのヒアリング結果
メタ学習ラボチューターへのヒアリングを行った。メタ学習ラボチューターからの e-ポートフォ
リオシステムに対する要望は、オープンソースソフトウェアの e-ポートフォリオシステムでは、い
くつかの機能が不十分であるため、開発する e-ポートフォリオシステムではそれを補って欲しいと
いうものであった。特に、本学に最適化されていない部分や、通知機能、更新情報の表示が不便で
あるとのことであった。
（※文責: 梅本祥平）
5.3.4
高度 ICT コース長へのヒアリング結果
高度 ICT コース長へのヒアリングを行った。高度 ICT コース長からの e-ポートフォリオシステ
ムに対する要望は、就職活動に e-ポートフォリオシステムを役立てたいが、まずは本学の授業と
関連付けされた e-ポートフォリオシステムにして欲しいというものであった。そして、授業での
気付きなどに対して、教員からフィードバックを得られるような仕掛けが欲しいとのことであっ
た。また、まずは高度 ICT コースの中での活用といった限定的な活用を行なって欲しいとのこと
であった。
就職活動との関連については、履歴書との対応付けを行ってはどうかという提案があった。
（※文責: 梅本祥平）
5.3.5
ヒアリング結果のまとめ
ヒアリング結果のまとめとしては、プロジェクトコミュニティ内で、意見の大きな相違が見られ
るということである。各自の e-ポートフォリオシステムに対するイメージが異なっているため、要
求が統一されていない。また、想定しているユーザーも各々異なっており、幅が狭いものから広い
ものまであった。今後は、プロジェクトコミュニティ内で、意見の統一を図る必要があると考えら
れる。
Group Report of 2012 SISP
- 40 -
Group Number 20-A
The New Portfolio System
（※文責: 梅本祥平）
5.4
発表会の結果
この節では、中間成果発表と最終成果発表の結果を記述する。
（※文責: 菊谷悠太）
5.4.1
中間成果発表会の結果
本プロジェクトの本プロジェクトの中間発表を聞いてくださった方に、発表評価シートによる発
表の評価をして頂いた。その結果，合計 55 名分の評価が集まった。
発表技術についての評価
発表技術についての評価では、発表の良し悪しについて 10 段階の点数評価をして頂いた。51 名
分の回答が得られた。評価の平均は 6.65 であった。
発表技術についてのコメント
発表技術についてのコメントを頂いた。頂いたコメントには、以下のようなものがあった。
• 説明がわかりやすかった
• 声の通りが良かった
• 声が小さく聞き取りづらい
• 敬語があいまい
• 指し棒の使い方が悪い
• お客さんの方を見ている
• スライドがシンプルで見やすい
• 途中で聞き取れない部分があった
• カンペを見過ぎなのがきになる
• たどたどしく感じた点が合った
• スライドで足りない内容をしっかり説明できていた
• 発表はふらふらせず、全員が立って行うべき
• スライド内容を頭に入れておくべき
• 発表の役割を分担するべき
• スライドにアジャイルの図があったらいいと思う
• スライドに図が少なく飽きてしまう
• 横文字が多いがわかり易かった
• アジャイル手法うぃもう少しアピールしたほうが良い
• 何が”新”なのかをもっと明確に説明してほしい
• 字が小さい
• 資料の構成がよく、分かりやすい
• まとめを作っているのが良い
• 何を作っているのか分かりづらかった
Group Report of 2012 SISP
- 41 -
Group Number 20-A
The New Portfolio System
• ペーパープロトタイピングングの説明が初めの方にあるべき
• タスクかんばんを持ってきたほうが良い
• プロトタイプを見せてほしい
• インセプションデッキの内容をもっと見せてほしい
発表内容についての評価
発表内容の良し悪しについて、10 段階の点数評価をして頂いた。50 名分の回答が得られた。評
価の平均は 7.12 であった。
発表内容についてのコメント
発表内容についてのコメントを頂いた。頂いたコメントには、以下のようなものがあった。
• システムの構想について聞きたかった
• 何を作るのかが分かりづらい
• 方法についての理由を知りたい
• 先行事例の調査をやってるべき
• システム開発の方法論について，よく勉強されている
• 専門用語の説明が口頭のみで分かりづらい
• アジャイルプロセスの概念を説明をもっとして欲しい
• アジャイルについての説明に重点を置きすぎている
• 今後の計画，課題などを冷静に分析できていた
• システムがどうユーザーを支援するのかが分からない
• 説明にポートフォリオの内容をもっと入れるとよい
• 個人の感想の報告は発表に必要ない
• 目標が分からない
• 作業内容や活動方法が新しく，良いと思う
• 作業の仕方等が参考になった
• アジャイルの利点が良くまとめられていた
• アジャイルベースのプロジェクトとしての形が整っていた
• スタンドアップミーティングは情報共有するに当たってよい方法だと思った
• portbacker の説明がよくわからない
• チームの頑張りがよく分かった
• 聞いていて面白いと感じた
• アジャイルは難しそうだと感じた
• スタンドアップミーティングは自分達のプロジェクトでも使ってみたいと思った
• ポスターの概要が長い
• コンセプトがあると良いと感じた
• アジャイルの説明が分かりやすかった
• 自分達の成長を優先しているなと感じた
• 目標が明確でよかった
• 教員の指摘にもしっかり答えていた
• 計画性の高さが見られた
Group Report of 2012 SISP
- 42 -
Group Number 20-A
The New Portfolio System
• ルール設定の工夫が参考になった
• 難しい用語が多く説明不足だと感じた
• 前期に取り組んだ内容が分かりやすかった
•「勉強した」ということは，発表に盛り込む必要はない
• 方法論の説明は不要
• システム像，ユーザーの利用イメージが分からない
アンケート結果
アジャイルソフトウェア開発を知っているかどうか、「はい」と「いいえ」の 2 択で回答して頂
いた。その結果、「はい」と答えた方は 45 ％、「いいえ」と答えた方が 20 ％、無回答が 35 ％で
あった。
発表を聞いて、発表を聞いて、アジャイルソフトウェア開発について理解できたかどうか、「は
い」と「いいえ」の 2 択で回答して頂いた。その結果、
「はい」と答えた方は 49 ％、
「いいえ」と
答えた方が 13 ％、無回答が 38 ％であった。
プロジェクトで取り組んでみたいプラクティスはあったかどうか「はい」か「いいえ」の 2 択で
答えた頂いた。その結果、「はい」と答えた方は 23 名、「いいえ」と答えた方は 8 名であった。他
のプロジェクトを行っている学生に、プロジェクト活動で取り組みたいと思うプラクティスは何
か、コメントを書いて頂いた。ポモドーロテクニックに取り組みたいと回答した方が 6 名、スタン
ドアップミーティングに取り組みたいと回答した方が 7 名、タスクかんばんに取り組みたいと回答
した方が 8 名、インセプションデッキに取り組みたいと回答した方が 3 名であった。
ポートフォリオシステムについて理解することができたか、
「はい」と「いいえ」の２択で答えて
頂いた。その結果、「はい」と答えた方が 29 ％、「いいえ」と答えた方が 29 ％、無回答が 42 ％で
あった。
（※文責: 菊谷悠太）
5.4.2
最終成果発表会の結果
本プロジェクトの最終成果発表を聞いてくださった方に、発表評価シートによる発表の評価をし
て頂いた。その結果，合計 75 名分の評価が集まった。
発表技術・内容についての評価
発表技術についての評価では、発表の良し悪しについて 10 段階の点数評価をして頂いた。65 名
分の回答が得られた。評価の平均は 6.82 であった。
発表内容について、10 段階の点数評価をして頂いた。50 名分の回答が得られた。評価の平均は
7.05 であった。
各メンバーの発表技術と発表内容についての評価の結果は表 5.1 である。
Group Report of 2012 SISP
- 43 -
Group Number 20-A
The New Portfolio System
名前
発表技術の評価
発表内容の評価
木村幸太朗
7.50
7.10
梅本祥平
7.54
7.67
山本賢人
6.13
6.25
和田聖矢
6.21
6.38
菊谷悠太
6.22
6.29
中野佑
8.00
7.57
表 5.1 発表技術・発表内容の結果
発表技術についてのコメント
発表技術についてのコメントを頂いた。頂いたコメントには、以下のようなものがあった。
• 木村幸太朗
– 聞きやすかった
– 声の大きさを確認していた
– スライドがシンプルで見やすい
– 説明が分かりやすい
– メッセージ性の強い発表が欲しかった。
– スライドにアニメーションなどで発表を強調をつけるべき
– 話の流れがよく理解しやすかった
– 話す早さが調度良かった
• 梅本祥平
– 分かりやすいが、周りの音の大きさもあって、少し聞こえづらかった。
– スライドのキーワードが強調されていた
– 話すスピードが適切だった
– スライドはよくまとまっていた
– 文字と図が多く、イメージしづらかった
• 山本賢人
– 声が聞き取りにくい
– 発表中に、笑っていたり、揺れたりしていた
– スライドの文字数が多い
– 何ができて、何ができなかったのか説明せれていてよかった
• 和田聖矢
– アイコンタクトがとれていた
– プレゼン資料が他のプロジェクトと比較して地味
– Q ＆ A の対応がしっかりしていた
– 資料が文字中心でわかりにくい
– 声が聞き取りにくい
– 図の文字が小さい
– 言葉に詰まるところがあった
• 菊谷悠太
Group Report of 2012 SISP
- 44 -
Group Number 20-A
The New Portfolio System
– もう少しスライドのデザインを検討したほうが良い
– 声が小さかった
– アイコンタクトがとれていなかった
– Q ＆ A の場面はとても良かった
– スライドが少しわかりづらかった
• 中野佑
– 聞き取りやすい声の大きさだった
– 説明がわかりやすかった
– つながりが整理され、理解しやすかった
– プロセスがわかりやすく整理されていた
各メンバーに対する発表内容についてのコメント
• 木村幸太朗
– 目標を達成するまでの計画が少し弱い気がした
– 顧客の役割を明確にするべき
– ポートフォリオシステムのメリットとニーズの確認が必要だと感じた
– より多くのユーザーからシステムのフィードバックをもらうことが必要
– 全学年に対してのヒアリングを行い意見を聞き出す
• 梅本祥平
– 今までに何をやっていたのか伝わり良かった。
– 構築されるシステムの正確に合わせた開発方法を選択していた
– 一年間の計画の変更・修正が反映されていてよかった
– 全作業のスピードを上げるべきだと思った
• 山本賢人
– 完成しないにしても、どのようなアウトプットがあるのか説明するべきだ
– ポートフォ リオがどういうもので、システムで何を実現したいのか説明されていない
– 顧客が誰なのか知りたかった
– 一部計画が甘かったと思うところがあった
• 和田聖矢
– ペーパープロトタイプが見たかった
– 何ができたのかがわからなかった
– 学習成果の説明が不足していた
– 顧客がだれなのか説明されていなかった
– 学習成果とは具体的に何か説明されていなかった
– 目的・問題などに比べて成果が少ないと思った
– 実装したシステムのデモがほしかった
• 菊谷悠太
– 成果 物が何なのかわかりにくかった
– プロトタイプが見たかった
– ユーザーの意見を取り入れたほうが良いと思った
• 中野佑
– 結果がしっかりしていた
Group Report of 2012 SISP
- 45 -
Group Number 20-A
The New Portfolio System
– システム作りとしては成果物とは家いない
（※文責: 菊谷悠太）
成果物
5.4.3
本プロジェクトが作成した成果物は以下の通りである。
• 議事録
• インセプションデッキ
• ユーザストーリー
• e-ポートフォリオシステムの調査結果
• プロトタイプ
• データベースモデル図
• e-ポートフォリオシステムのデータベース
• データベースのテスト
• ヒアリング調査結果
（※文責: 菊谷悠太）
5.5
成果の評価
5.5.1
プロジェクトの目標についての評価
本プロジェクトでは以下の３つの目標を設定した。
• 学生が自らの学習成果の管理をサポートするためのシステムを開発
• アジャイルソフトウェア開発を実践
• web アプリケーションを開発するための技術の習得
１つ目に、学生が自らの学習成果の管理をサポートするためのシステムを開発するという目的だ
が、顧客にシステムを受け入れてもらうことができなかったこと、またそこからシステムを完成す
るまでに至らなかったため、達成することができなかった。反省点として、メンバーが顧客と話す
場を多く作る必要があった。
２つ目に、アジャイルソフトウェア開発を実践するという目標だが、アジャイルソフトウェア開
発のプラクティス（ペアプログラミング、朝会、ポモドーロテクニック、テスト駆動開発、タスク
かんばん）と呼ばれるものはできた。しかし、イテレーションを回すことができなかった。顧客と
のやり取りを増やすことができず、プロジェクトのフェーズごとに止まっていた。プロジェクトの
計画・システムの開発には力を入れて行なっていたが、顧客全員を揃えて話をする機会を設けるこ
とができなかった。
３つ目に、Web アプリケーションを開発するための技術の習得という目標だったが、勉強会を
プロジェクト時間外にして、技術習得をした。夏期休暇や課外活動で企業の方が開いている勉強会
に参加したメンバーがいて積極的に技術習得した。また、夏期休暇に、担当教員から出されたじゃ
んけんゲームを Web アプリケーションで作成するという課題を解いたのでこの目標は達成したと
考える。
Group Report of 2012 SISP
- 46 -
Group Number 20-A
The New Portfolio System
最後に、達成できたと考えられる目標は、Web アプリケーションを開発するための技術習得だけ
となってしまった。すべての目的が達成できなかった要因としてあげられるのは、達成できなかっ
た２つの目標で挙げられている顧客とのやり取りに問題があった。システム開発は、プログラミン
グが出来る人が集まればできるものではなく、顧客のコミュニケーションする場をつくり、本当に
顧客が必要なものを聞き出す能力が必要であるということがメンバー身に染みて理解することがで
きた。
（※文責: 菊谷悠太）
5.5.2
成果物の評価
本プロジェクトで作成した成果物についての評価をする。
議事録
本プロジェクトが行われた日に何をやったのか、その日にいなかったメンバーが見てもわか
るように記録するものである。長期休暇後の活動日に何をやったかを見直すのに役立った。
インセプションデッキ
本プロジェクトの目的を確認するために使った。話していくうちに目的とずれたりして、軌
道修正するときに役立った。
ユーザーストーリー
ユーザーの目線から、システムに必要な機能を具体的に検討することができた。また、検討
した機能に優先順位をつけることで、開発の順序を考えることができた。しかし、実際にシ
ステムをリリースしていないため、ユーザーストーリーの信頼性を評価することができな
かった。
e-ポートフォリオシステムの調査結果
本プロジェクトで作成する e-ポートフォリオシステムを深く理解するため役立った。また、
既存する e-ポートフォリオシステムの比較する図を作成し、e-ポートフォリオシステムの知
識を深めた。
プロトタイプ
メンバー間で共有していたシステムの完成図が文章でしかなかったので、見える化すること
によってよりどのようなシステムができるか明確になった。また、顧客に見せるにも役に
立った。
データベースモデル図
データベースを設計する際に作成した。データの関連などが見える化してデータベースを作
る際に役に立った。
新ポートフォリオシステムのデータベース
データベースに関係するモデルを作成した。バリデーション・正規表現を使って入力フォー
Group Report of 2012 SISP
- 47 -
Group Number 20-A
The New Portfolio System
ムに入力できる文字を制限した。
データベースのテスト
本プロジェクトでは、テスト駆動開発を行った。MVC モデルのモデルと同時に、モデルの
テストを作成した。テストを最後の工程でするよりもプログラミングをすると同時にテスト
作成するほうがバグが少なくなるのでテスト駆動開発を用いた。最後まで、システムを作る
ことができなかったのでテスト駆動開発をして実際にバグが少なくなったは評価できない。
ヒアリング調査結果
ヒアリングの結果をまとめて、顧客がどのようなシステムを求めているのか把握する際に
役立った。まだ、顧客の意見を取り入れたシステムは、作成途中なので、ヒアリング調査結
果を参考にシステムを開発していきたい。
（※文責: 菊谷悠太）
振り返りの結果
5.5.3
前期で行った振り返りではイテレーションを実施することができなかったことや、技術不足を痛
感したなどの問題点があげられた。続けるべきことは、勉強会の実施やなるべく Web サービスを
使わず、アナログ方式を取り入れることなどがあげられた。新しく挑戦すべきことには問題点の改
善点も含めて議論が行われた。後期での振り返りは企業講師主催のもとで他のプロジェクトと合同
で行われた。後期はプロジェクト活動全体を通して振り返り、あらかじめ用意されたテンプレート
に従って振り返りを行った。メンバーの中でテンプレートの課題に従ってブレーンストーミングを
行い、グループ化を行った結果、システム開発に必要な技術を習得できたという意見があった。ま
た、アジャイルソフトウェア開発手法は難しいという意見もあった。
（※文責: 山本賢人）
担当分担課題の評価
5.6
5.6.1
木村幸太朗
計画
プロジェクトの計画は、アジャイルソフトウェア開発という開発手法に則って行った。計画
の作成は、メンバー全員で行い、最初は大まかな計画を立て、段階的に詳細を詰めていった。
実際に計画を立てていくと、様々な点で問題とぶつかった。まず、どれだけ時間がかかるの
かという認識が各メンバーで異なっていたことである。そのため、計画を立てるのに要する
時間が思った以上にかかってしまった。また、いざ実際に計画通りに活動しても、計画と実
績との間の違いが大きく、結果的には、後期で再度計画を立て直すこととなってしまった。
技術習得
システム構築に新規技術を多く導入したため。メンバー全体の技術力を向上させる必要が
あった。そのため、前期での活動には、技術習得の場を多く取り入れた。また、授業外にも
Group Report of 2012 SISP
- 48 -
Group Number 20-A
The New Portfolio System
勉強会と称した場を設け、技術習得に励んだ。勉強会は、プレゼンテーションの方式を採用
し、一人が勉強してきたことを発表し、それをメンバー全体で共有していく方法を取った。
結果としては、システム構築に必要な分だけの技術力を得ることができたように感じてい
る。
インセプションデッキ
インセプションデッキの作成は、メンバーがプロジェクトの指針を理解するために作成した
ものである。作成回数は、前期と後期で一度ずつ行ったが、後期の方が格段に具体的で、わ
かりやすい内容にすることができた。これは、私だけでなくメンバー全体が、自分たちの作
る e-ポートフォリオシステムをより深く理解できたからだと感じる。また、作成する際のメ
ンバーの発言も後期の方が断然多いように感じた。
ユーザーストーリー
システムの具体的な機能やその遷移を考えるために、ユーザーストーリーを作成した。作成
する際には、自分がエンドユーザーであると想像した上で、作成にとりかかった。ユーザー
ストーリーを作成したら、次に優先順位付けを行った。さらにその後、順位付けしたストー
リーをタスクに分解し、タスクに優先順位をつけた。ここまでの工程では、自分と他のメン
バーが感じる優先度合いに差異が生じていたため、思うように作業をすることができなかっ
た。また，発言の回数も少なくなってしまった。作成の回数は，前期に 1 度ずつであった
が、後期の方がより具体的でどのような機能を実装するべきなのか分かるものを作成するこ
とができた。
ペーパープロトタイプ
作成したユーザーストーリ−をもとに、システムの遷移をペーパープロトタイプを作成する
ことで表した。実際にシステムが動く画面を考えることで、より具体的にシステムの動きを
理解することができた。また、作成する中で気をつけたこととして、画面に載せる情報量や
機能の数は適切かどうかを常に考えて活動した。結果としては、システム全体の動きを具体
的に分かる程度には、完成されたプロトタイプができたように感じている。
ポスター作成
文字や概要図の配置に気を使った。人を惹きつけられるポスターを作れなかったので、最終
発表の時には改善していきたい。
（※文責: 木村幸太朗）
5.6.2
梅本祥平
メンバーへの技術指導
アジャイルソフトウェア開発について、独自に学習していたため、プロジェクトメンバーに
スムーズに指導を行うことができた。また、バージョン管理システムに関しても、日頃から
利用していたため、適切な指導を行うことができた。一方で、一部では知識が不足していた
ため、参考書を利用してそれを補った。
Group Report of 2012 SISP
- 49 -
Group Number 20-A
The New Portfolio System
アジャイルプラクティスの導入
アジャイルプラクティスを導入したものの、迅速で適応的な開発を行うという目的を達成す
ることは出来なかった。これは、e-ポートフォリオシステムの開発期間が短かったためであ
り、アジャイルプラクティスそのものの問題ではない。プロジェクト内の情報共有では、詳
細な部分ではメンバー間により認識が異なっている点があった。そのずれを修正するため
に、インセプションデッキの見直し等を行ったが、振り返りを行い、プロセスの改善に尽力
する必要がある。
採用技術についての提案
採用技術についての提案が受け入れられ、目的を達成することができた。しかし採用した
Web アプリケーションフレームワークの学習コストが予想以上に高く、プロジェクトメン
バーが習熟するまでに多くの時間を費やしてしまった。
インセプションデッキの作成
インセプションデッキを作成することで、プロジェクトメンバー間の認識を統一することが
できると考えていたが、実際には多少の相違があった。その後はインセプションデッキの見
直しを行い、プロジェクトメンバー間の認識を統一することができたが、プロジェクトコ
ミュニティとの間での意見の相違があり、さらなる見直しが必要であった。
全体の計画づくり
イテレーションの長さは 2 週間に設定したが、いくつかの機能を実装するには不十分であっ
た。また、イテレーションの長さを調整するための時間を設定することができなかった。
ユーザーストーリーの作成
顧客が積極的に開発に参加してなかったため、ユーザーストーリーを作成することが困難で
あった。
イテレーション計画づくり
ストーリーポイントによる見積りは、ある程度の経験が必要であった。そのため、繰り返し
による見積り精度の改善を試みたが、改善されなかった。
e-ポートフォリオシステムに関する調査
e-ポートフォリオシステムの先行事例は、数が少なく、導入される目的や規模も大きく異っ
ていたため、あまり参考にすることができなかった。
プロジェクトコミュニティ対するヒアリング
プロジェクトコミュニティ内での意見が統一されておらず、e-ポートフォリオシステムに対
するイメージがそれぞれ異なっていたため、開発を進めることができなかった。
e-ポートフォリオシステムの開発
e-ポートフォリオシステムで必要となる機能の実装を行ったが、プロジェクトコミュニティ
からのフィードバックが無かったため、評価することができない。
Group Report of 2012 SISP
- 50 -
Group Number 20-A
The New Portfolio System
（※文責: 梅本祥平）
5.6.3
山本賢人
ユーザーストーリー
e-ポートフォリオシステムの機能を検討する際に、ユーザーストーリーを作成した。プロ
ジェクトメンバーでユーザーストーリーに関して議論したが、意見だしが消極的になってし
まった。今後このような機会があれば、頭に浮かんだ意見を積極的に述べるべきだと思っ
た。
インセプションデッキ
プロジェクトの方向性や、全体像がぶれないようにするため作成したドキュメントだが、実
際にインセプションデッキを再確認することはあまりなかった。今後、アジャイルソフト
ウェア開発を用いたプロジェクトに参加した際には、インセプションデッキを最大限活用
し、リスク管理や、プロジェクトの最終目標を常に見据えてとり組みたい。
プランニングポーカー
ユーザーストーリーについて、見積りを行う際に、プロジェクトメンバーで意見を出し合っ
たが、プロジェクトメンバー全員が、見積り内容に関して納得していたようだった。相手を
納得させる理由を考えるときに、技術的なことも考慮しなくてはいけないため、学習の一環
になった。また、ストーリーポイントを定めるとき、そのユーザーストーリーが適切かどう
か検討するため、計画の見直しをするいい機会だった。
ペーパープロトタイピング
前期のペーパープロトタイピングに携わった。想定していたユーザーインタフェースを紙に
おこせたと思うが、絵が雑であるという評価を受けた。紙で書く分、より丁寧に書かなくて
はいけないと実感した。HTML をもちいたプロトタイピングと比べると、ペンで行うペー
パープロトタイピングのほうが、手軽かつスピーディに行うことができ、もっと活用すべき
だと感じた。
e-ポートフォリオシステムの調査
夏休暇にプロジェクトメンバーで e-ポートフォリオシステムの調査をしていたが、帰省して
いたため、参加できなかった。e-ポートフォリオシステムの調査結果を議事録や報告を通し
て知り、帰省に関しては反省すべきだと思った。
データベース構築
本学で使用する e-ポートフォリオシステムのデータベースの構築を行った。アカウントテー
ブルとグループテーブルの関連付けや、他のテーブルの作成を要求どおりに構築することが
できた。
ヒアリング
プロジェクトコミュニティに対してヒアリングを行った。聞き出すべき質問をまとめ、実際
Group Report of 2012 SISP
- 51 -
Group Number 20-A
The New Portfolio System
に、目的としていた回答を得ることができた。これを参考に、今後の方針を決めていくこと
ができるようになった。
（※文責: 山本賢人）
5.6.4
和田聖矢
議事録作成
議事録を作成することによって、振り返りをより深く行うことができた。プロジェクト活動
開始時間に行う、スタンドアップミーティングでは、作成した議事録を利用し、前回の活動
の振り返りを行った。また、議事録はインターネット上でいつでも確認することができるの
で、欠席者や、別の作業を行っているプロジェクトメンバーとの情報共有にも活用した。議
事録の作成役は、プロジェクトメンバーが交代で担当した。前期では、交代する順番を決め
ていなかったので、活動の記録を取り忘れるケースが何度かあった。そのため後期では、交
代する順番を決めて議事録を作成した。
インセプションデッキ作成
インセプションデッキ作成は、本プロジェクトの目的や方向性について、プロジェクトメン
バー全員で考える良い機会となった。インセプションデッキには、「日々確認してプロジェ
クトの進むべき方向性を失わないようにする」という目的があった。しかし、あまり確認を
行わず活動を進めてしまった。インセプションデッキの利点を生かすため、日々確認できる
よう工夫が必要であった。また、インセプションデッキの作成は、プロジェクトの方向性を
決める作業である。そのため、プロジェクトメンバーだけでなく、プロジェクトコミュニ
ティの全員で作成する必要があった。
計画づくり
計画方法について勉強しながら作成したため、多くの時間をかけてしまった。しかし、ア
ジャイルソフトウェア開発における計画づくりについて勉強することができた。全体の計画
に関して、発表準備、環境構築等の時間の見積りが甘かったと感じた。
技術習得
e-ポートフォリオシステムの開発に必要な技術を習得するために、勉強会を行った。勉強
会は輪講形式で行った。自習に時間をかけることができなかったため、中途半端な輪講と
なってしまった。しかし、教える立場となることによって、効率よく理解を深めることがで
きた。勉強会では、プログラミング言語の学習だけでなく、ペーパープロトタイピングや、
Git、テストユニットなど、様々な技術について学ぶことができた。幅広い技術に触れる良
い機会となった。
開発環境の構築
各自のコンピューターで開発を行うことができるよう、プロジェクトメンバー全員で、eポートフォリオシステムの開発環境を構築した。前期では、各自異なる種類のオペレーティ
ングシステムで環境構築を行ったため、同等の環境を整えるために時間をかけてしまった。
オペレーティングシステムの違いによる問題発生の可能性があったため、後期では、環境が
Group Report of 2012 SISP
- 52 -
Group Number 20-A
The New Portfolio System
同一である開発用のコンピュータを用意した。
ユーザーストーリーの作成
ブレインストーミングにより、多くのユーザーストーリーを作成し、必要な機能について議
論することができた。ユーザーストーリーを作成することにより、e-ポートフォリオシステ
ムに必要な機能をより細かく検討することができた。
e-ポートフォリオシステムの調査
e-ポートフォリオの役割や必要性について調べた。既存の e-ポートフォリオシステムである
Mahara を実際に利用することによって、より具体的に e-ポートフォリオシステムの機能検
討をすることができた。
ペーパープロトタイピング
e-ポートフォリオシステムを実装する前に、紙によるプロトタイプを作成した。使いやすい
ユーザーインタフェースを意識し、他のプロジェクトメンバーと議論しながら作成を行っ
た。情報デザインコースに所属するプロジェクトメンバーと共同で作業を行ったため、よい
勉強となった。ペーパープロトタイプを作成したが、それを用いたユーザーテストを行わな
かった。ユーザーテストを行うことにより、プロトタイプの作成者では気づかない、細かい
問題を発見することができる。より良いユーザーインタフェースを実装するために、ユー
ザーテストを行う必要があった。
ヒアリング調査
顧客に対しヒアリングを行うことによって、顧客の e-ポートフォリオシステムに対する意見
を集めることができた。ヒアリング調査の結果を参考に、今後の活動の方向性を決めた。ヒ
アリングは後期に行った。より早い段階からプロジェクトコミュニティに対するヒアリング
を行い、プロジェクトコミュニティの意見を交えた活動を行うべきであった。
（※文責: 和田聖矢）
5.6.5
菊谷悠太
計画
全員が納得するまで話し合ったので、ここで計画より多くの時間を使ってしまった。また、
計画外の予定が多く入ったことにより、計画に遅れが発生した。本プロジェクトで計画外の
行事が出てきたことから、必ず計画通りに進むことは難しいので計画を立てる際に、何か起
こるときの保険として余分に時間をとっておく必要があると感じた。
ユーザーストーリー
ステークホルダーと一緒にユーザストーリーを決めるべきであった。プロジェクトメンバー
で、ユーザストーリーを決めたが、ステークホルダーが想定していたシステムと異なってい
て、再検討することになった。
インセプションデッキ
Group Report of 2012 SISP
- 53 -
Group Number 20-A
The New Portfolio System
インセプションデッキを作る段階で、顧客の役割を決めておけば、計画の遅延を少なくする
ことができたかもしれない。
e-ポートフォリオに関する調査
e-ポートフォリオに関する調査を行うことで、メンバー全員が曖昧だったポートフォリオの
理解を深めることができた。また、既存の e-ポートフォリオシステムである Mahara を使
用して、便利な機能が多くあってもユーザーはすべての機能を使うわけではないということ
がわかった。ユーザーが求めている機能を実装すれば、ユーザーの選択肢が減り、使いやす
いシステムになると感じた。
ペーパープロトタイプのレビュー
レビューが重要であることを理解することができた。ペーパープロトタイプを作成したメン
バーが、気づかないシステムの欠陥を見つけることができた。
ポートフォリオシステムのデータベース
e-ポートフォリオのデータベースを作成したが、ステークホルダーからの評価をもらうこ
とができなったため、評価することはできない。
ヒアリング調査結果
顧客にヒアリング調査を行うことで、顧客が求められてるシステム像を把握する事ができ
た。しかし、ヒアリング調査を行う時期が遅かったため、開発を進めることができなかった。
（※文責: 菊谷悠太）
5.6.6
中野佑
技術習得
本プロジェクトでは通常の授業で取り扱っていない技術を使用するため、技術習得をする必
要があった。前期では毎週金曜日にプロジェクトメンバー全員に対して輪講をした。内容に
不備があったり、わかりやすい説明をすることができなかったため、さらに学習する必要が
あった。そこで、夏期休暇中に本を読み返したり、セミナーに参加するなどして理解を深め
ることができた。
議事録
毎回のプロジェクトの活動内容をリーダー以外のメンバー間でローテーションして記録し
た。次に読む人がその日行った活動と全く同じことが行えるように詳細に書いて工夫した。
インセプションデッキの作成
プロジェクトの方向性を決めるためにプロジェクトメンバー全員でインセプションデッキの
作成を前期で行った。しかし、実際にはメンバー間で多少の相違があったため、後期に入っ
てからもう一度作成し直した。作成の際には、各質問ごとに多くの意見を出すようにした
り、他のメンバーの意見をなるべく否定しないように心掛け、円滑な話し合いをすることが
できた。
Group Report of 2012 SISP
- 54 -
Group Number 20-A
The New Portfolio System
ユーザーストーリー
ユーザーの利用シーンを明らかにするためにプロジェクトメンバー全員でブレーンストーミ
ングを行った。なるべくエンドユーザーの目線となって考えるように心掛けた。ユーザース
トーリーを洗い出した後に、各ストーリーごとの規模をプランニングポーカーという手法で
見積もった。なぜその規模となったのか理由を説明できるようにしたが、勘で見積もってし
まったこともあったため反省すべきである。
ペーパープロトタイピング
システムを実装する前に、紙によるプロトタイプを作成した。作成したユーザーストーリー
からユーザーの視点でプロトタイプを作成した。ユーザーがマニュアルを参照しなくても使
えるような画面にするようにメンバーと話し合いながら画面設計を行った。特にボタンの位
置などには意味を込めて説明できるように心掛けた。
ヒアリング調査結果
顧客への真の価値を届けるようにするにはプロジェクトコミュニティへのヒアリングは不可
欠である。e-ポートフォリオシステムに関する研究を行っている専門家と、就職委員長にヒ
アリングを行った。ヒアリングの際にはなるべく聞き逃さないようにメモを取るなりした。
ヒアリングの結果、対象としてるユーザーの相違やそれぞれ持っている意見が異なったた
め、それぞれ納得のいくように意見を集約する必要がある。
成果発表会スライド作成
成果発表会の趣旨に沿うような内容でスライド作成を心掛けた。前期の趣旨としてプロジェ
クト間の交流だったため、前期で行ってきた活動紹介を主にスライド作成をした。しかし、
前期の成果物を知りたいという聴講者からの評価を受けてしまった。後期からは成果物の発
表を主に重点に置いて発表したところ、高い評価を得ることができた。
成果発表会
前期では発表会前に ICT コース所属のプロジェクト間で予行の発表会が行われた。その発
表のために練習を何度も行っていたため、本番では特に問題もなく発表を終えることができ
た。発表技術に関しても高い評価を得ることができた。後期では発表会直前にスライド資料
の作成をしていたため、まったく練習することができなかったが、前期での経験を活かして
声を大きくわかりやすい言葉遣いにすることにより悪い評価を受けることはなかった。
振り返り
KPT 分析を行った結果、全体を通してアジャイルソフトウェア開発は前提知識が多いため、
学生によるプロジェクト学習での実践は難しかったという意見が多かった。また、プロジェ
クトコミュニティを含めた開発を行えなかったため、プロジェクトコミュニティの重要性を
理解することもできた。KPT 分析はブレーンストーミング形式で行ったことでたくさんの
意見が出て、自分が気づけないようなことにも気づけた。これは自分自身の学習の振り返り
にも利用できるため、今後も活用していきたい。
（※文責: 中野佑）
Group Report of 2012 SISP
- 55 -
Group Number 20-A
The New Portfolio System
第6章
今後の課題と展望
本プロジェクトに残る課題とその解決方法、今後の展望について記述する。
（※文責: 和田聖矢）
6.1
課題
本プロジェクトは、e-ポートフォリオシステムの開発を中断する結果となった。その原因として、
顧客を巻き込んだ開発をすることができなかった、ということが挙げられる。他にも、プロダクト
オーナーが定まっていない状態で開発を進めようとしていたことも、原因の一つとなっている。eポートフォリオシステムの開発を進めていくためには、これらの問題を解決する必要がある。
（※文責: 和田聖矢）
6.1.1
顧客を巻き込んだ開発
本プロジェクトは、顧客との対話をせずに開発を進めてしまった。そのため、顧客との意見の相
違が生まれ、システム開発を中断する結果となってしまった。顧客と対話をし、要望を集めなけれ
ば、顧客に使用してもらえる「価値のあるシステム」を開発することはできない。今後は顧客との
定期的なミーティングを行うなど、積極的にコミュニケーションをとる必要がある。
（※文責: 和田聖矢）
6.1.2
プロダクトオーナーの決定
プロダクトオーナーが定まっていないため、開発を進めることができないという問題がある。現
在、顧客側には、プロダクトに責任を持った人物が存在しない。そのため、顧客の様々な意見か
ら、開発の方向性を決めることが困難である。方向性が決まらなければ、開発を進めることができ
ない。また、顧客の意見を取り入れず、開発者が独自に方向性を決定しても、顧客に使用してもら
えるシステムを開発することはできない。プロダクトに責任を持ち、開発の方向性を示す「プロダ
クトオーナー」の存在が必要不可欠である。
（※文責: 和田聖矢）
6.1.3
技術力の向上
技術力が不足しているため、システム実装前の技術習得と技術検証に多くの時間を使ってしまっ
た。e-ポートフォリオシステム開発のを円滑に行うために、プロジェクトメンバー一人ひとりが技
術力を向上させなければならない。本プロジェクトでは、技術習得、技術力向上のために、勉強会
等を行ってきたが、基礎的な部分の学習が中心であった。今後は、応用的な技術に関しての勉強会
Group Report of 2012 SISP
- 57 -
Group Number 20-A
The New Portfolio System
を行い、技術力を向上させていく必要がある。
（※文責: 和田聖矢）
6.1.4
アジャイルプラクティスの実践
本プロジェクトでは、アジャイルソフトウェア開発に取り組むことを課題の一つとした。開発
を進めることができなかったため、十分に実践できなかったアジャイルプラクティスがいくつか
あった。
インセプションデッキの作成
インセプションデッキの作成は、プロジェクトの方向性を定める大切な作業である。そのた
め、プロジェクトコミュニティ全員が参加することが望ましい。しかし、本プロジェクトで
は、インセプションデッキの作成をプロジェクトメンバーのみで行った。より多くの関係者
が参加して作成を行う必要がある。
作成したインセプションデッキは、日々容易に確認できる場所に設置するべきである。そう
することで、方向性を確かめながら活動することができる。
計画作り
イテレーションをこなすことにより、チームがこなせる作業量（ベロシティ）を測り、その
量を元に、その後のイテレーション計画を行う予定であった。しかし、割り込み作業が多く
発生したため、うまくベロシティを測ることができなかった。今後は、ベロシティからイテ
レーション計画が立てられるようにしていきたい。
ペアプログラミング
ペアプログラミングは、二人一組で同じ画面を見ながらプログラミングを行うプラクティス
である。本プロジェクトの活動では、プログラミングを行う機会が少なかったため、十分に
取り組むことができなかった。１人がレビューを行うことで、質の高いコードを書くことが
できる。また、技術の共有も同時に行うことができるという利点がある。そのため、機会が
あれば、積極的に取り組んでいきたいと考える。
タスク管理
タスクかんばんを作成したが、活用する機会が少なかった。タスクかんばんを使用すること
により、進捗の見える化を行うことができる。タスクかんばんを積極的に活用するために、
何らかの工夫が必要である。
テスト駆動開発
本プロジェクトでは、データベース構築時にテスト駆動開発を行った。テスト駆動開発で
は、開発の進行に合わせ、テスト量が増えていくため、信頼性の高いシステムを作成するこ
とができる。今後、各機能を実装する際にも、実践していく必要がある。
（※文責: 和田聖矢）
Group Report of 2012 SISP
- 58 -
Group Number 20-A
The New Portfolio System
6.2
6.2.1
展望
システムの開発再開
今後の展望として、まずは顧客とのミーティングを行い、e-ポートフォリオシステムへの意見を
統一することが考えられる。現在システムの開発を中断している状態である。中断している大きな
原因は、プロジェクトコミュニティ内の意見の相違である。意見の相違をなくすることにより、eポートフォリオシステムの開発を再開することができる。
（※文責: 和田聖矢）
6.2.2
活動の継続
今後も、プロジェクト活動による e-ポートフォリオシステムの開発を継続するかどうかは決定し
ていない。プロジェクト活動による開発を継続する場合は、6.1 で示した各課題を解決する必要が
ある。また、次年度以降のプロジェクト学習で開発を行う場合は、開発メンバーの変更が伴う。引
継ぎ方法を考案する等、開発メンバーの変更に対応する必要がある。
（※文責: 和田聖矢）
Group Report of 2012 SISP
- 59 -
Group Number 20-A
The New Portfolio System
第7章
謝辞
本プロジェクト活動において、本学の神谷年洋教授からは、一年間を通して様々なご指導を賜り
ました。深く感謝致します。日本アイ・ビー・エム株式会社高森満様、木下実様には、深い学びを
得るためのアドバイスを頂きました。深く感謝いたします。ヒアリングを快く受けてくださった皆
様、お忙しい中、本プロジェクトの為に時間を割いていただき、まことにありがとうございまし
た。ティーチングアシスタントの方々、発表会にて発表の評価やアンケートの回答をしてくださっ
た方々には、たくさんのご意見を頂きました。心より感謝いたします。
（※文責: 和田聖矢）
Group Report of 2012 SISP
- 61 -
Group Number 20-A
The New Portfolio System
付録 A
A.1
新規習得技術
アジャイルソフトウェア開発
お客様に価値のあるシステムを届ける開発プロセスを身をもって体験した。
A.2
Ruby
e-ポートフォリオシステムの開発には Ruby を使用した。Ruby はコード量を抑えることがで
き、学習コストが低いプログラミング言語である。
A.3
Web アプリケーションフレームワーク
Ruby で構築された Web アプリケーションフレームワークである、Ruby on Rails を用いた。
そこから Web アプリケーションフレームワークの使い方を学んだ。
A.4
NOSQL
SQL を使わないデータベース技術について、MongoDB を題材に学習した。
A.5
ペーパープロトタイピング
紙を使用したプロトタイプを作り、ユーザーインタフェースのテストを行う技術を身につけた。
A.6
バージョン管理
バージョン管理システム Git についての利用法や、バージョン管理の必要性を学んだ。
Group Report of 2012 SISP
- 63 -
Group Number 20-A
The New Portfolio System
付録 B
活用した講義
ソフトウェア設計論
開発プロセスやプロジェクトマネジメントを参考にした。
情報処理演習 I
プログラムの実行環境ツールの活用などを参考にした。
データベース工学
データベース設計の参考にした。
ヒューマンインターフェイス
ペーパープロトタイピングの際に、インターフェース設計を参考にした。
ユーザーセンタードデザイン
モック作成の際に参考にした。
プロジェクトマネジメント論
PMBOK でかかれている開発プロセスを参考にした。プロジェクト・チームの育て方、ス
テークホルダーの権力と関心度を表すグリッドなどを参考にした。
システム管理方法論
開発環境でターミナルを使う機会が多く、コマンドを使う際参考にした。
Group Report of 2012 SISP
- 65 -
Group Number 20-A
The New Portfolio System
付録 C
相互評価
課題解決過程で分担し、連携した作業全般について、互いに客観的に評価した。
C.1
梅本祥平
C.1.1
菊谷悠太
プロジェクト・リーダーとして、プロジェクトの計画立て、計画修正、メンバーへの技術指導な
ど多くのタスクをこなしていた。体調が悪い時でも、プロジェクトに参加しリーダーとしての意識
が非常に高いと感じた。
C.1.2
木村幸太朗
プロジェクトリーダーとして、プロジェクトの運営全てに全力で努めてくれて、メンバーを力強
く引っ張っていたと思います。特に技術面でのアドバイスがすごくて毎回勉強させて頂きました。
これからも今まで以上にがんばってください。
C.1.3
中野佑
プロジェクト全体を通して、技術面では積極的に情報収集に励み、メンバーへの指導を行なって
いた。苦手ながらもリーダーとしてマネジメントを頑張っていたのでよかった。発表や報告書の作
成などではメンバーの分まで添削を行い、プロジェクトにとても貢献していた。
C.1.4
山本賢人
プロジェクトのリーダーとして、プロジェクトの計画立て、技術指導など積極的に行なってい
た。プロジェクトマネジメントの知識も技術的な知識も豊富なため、頼れるリーダーであったと
思った。
C.1.5
和田聖矢
プロジェクトリーダーとして、様々な面でプロジェクトメンバーを引っ張ってくれた。また、知
識が豊富で技術指導を積極的に行い、とても勉強になった。
C.2
菊谷悠太
C.2.1
梅本祥平
プロジェクトではシステムの実装を行なっていたが、若干の知識・技術不足が見られたため、今
後は自主的な勉強を習慣として行うようにしてもらいたい。一方で、プロジェクトマネージャとし
てプロジェクト内の雑用をこなし、プロジェクトを円滑に進めるためのサポートを行なってくれた
Group Report of 2012 SISP
- 67 -
Group Number 20-A
The New Portfolio System
点は高く評価したい。
C.2.2
木村幸太朗
プロジェクトマネージャーとして、メンバーの出席管理や備品の管理など、プロジェクトを裏側
から支えてくれた。また、データベースの実装など技術的な面でも、活躍してくれてとても心強
かった。
C.2.3
中野佑
HTML でのモック作成では大変プロジェクトに貢献していた。雑用も多く任されて、プロジェ
クトのサポートをしてくれていてとても助かった。
C.2.4
山本賢人
積極的に Web アプリケーション技術の知識を習得していた。Web アプリケーションのプロトタ
イプをつくったり、データベースを構築したり、活動に意欲的であった。
C.2.5
和田聖矢
分担作業の際には、担当外のペーパープロトタイピングにも積極的に関与し、多くの意見を出し
ていた。HTML のモック作成を自主的に行っていて、技術習得に関して積極的だと感じた。
C.3
C.3.1
木村幸太朗
梅本祥平
デザインに関することだけでなく、ソフトウェアに関すること（プログラミングや開発プロセ
ス）についても意欲的に学習しており、プロジェクトに大きく貢献していた。発表資料の作成で
は、得意な技術を使用することで資料をより良いものにしてくれた。今後もデザインとソフトウェ
アの両方への理解を深め、高みを目指して欲しい。
C.3.2
菊谷悠太
デザインコースのメンバーが一人しかいなかったので、ポスター作成の時に非常に助かった。話
し合いの時もたくさんの意見を出してくれてよかった。いろいろと活動をしていて、時間外活動す
るのが大変だと思ったが、積極的に参加してくれた。ペーパープロトタイピング作成の際、メン
バーを引っ張ってくれた。
C.3.3
中野佑
話し合いの場では積極的に意見を出して、進行役も上手にこなしていた。発表準備などもポス
ター制作ではデザインコースで培った知識を発揮して、貢献していた。プロトタイピングでもデザ
インコースの視点から的確な指摘をたくさんして、よりよいモックを作成していてよかった。
Group Report of 2012 SISP
- 68 -
Group Number 20-A
The New Portfolio System
C.3.4
山本賢人
唯一のデザインコースということもあるかもしれないが、ポスターづくりや、プロトタイピング
など、デザインコースで培った知識を積極的に活動に発揮していた。プレゼンテーションの技術が
高く、意見もたくさん出していた。
C.3.5
和田聖矢
デザインコースの学生として、ペーパープロトタイピングでは中心となって活動し、豊富な知識
を見せてくれた。また、時間外の活動に関しても積極的に取り組んでいた。議事録担当の際には、
とても細かく活動内容を記録してくれた。
C.4
C.4.1
中野佑
梅本祥平
システムに関することだけでなく、ペーパープロトタイピングの作成といったデザインに関する
タスクにも積極的に取り組んでおり、視野を広げることができたのではないかと考えられる。チー
ム内での議論では、他のメンバーよりも発言が多く、プロジェクトに貢献していた。
C.4.2
菊谷悠太
技術力を向上させようとする意識が非常に高く、学外の活動に参加していた。また話し合いの時
に、積極的に意見をいい真剣に活動に取り組んでいると感じた。プレゼンのスキルがかなり向上し
たと思った。
C.4.3
木村幸太朗
プログラミングなど技術的な面だけでなく、ペーパープロトタイピング作成等の UI 面でも活躍
してくれて、大変心強く感じました。また、ディスカッションでも積極的に発言していて、毎回感
心させられていました。
C.4.4
山本賢人
プロジェクトの議論の場では積極的に意見を出していた。技術に対する意欲が高く、いろいろ個
人的にも学習していた。
C.4.5
和田聖矢
積極的な行動が多かった。チームでの話し合いの際には、多くの発言をしていた。また、オープ
ンキャンパスでのプロジェクト発表では、発表担当をしてくれた。
Group Report of 2012 SISP
- 69 -
Group Number 20-A
The New Portfolio System
C.5
山本賢人
C.5.1
梅本祥平
Web アプリケーションの開発では、高度 ICT 演習で習得した知識・技術を生かし、テスト駆動
開発の実践等を行うことができていた。技術的にプロジェクトに貢献していた。一方で、ディス
カッションの場では、スマートフォンを操作しながら参加している場面が多く、進行の妨げになっ
ていることが多くあった。しかし、それをカバーできる的確な指摘や発言が多かった。
C.5.2
菊谷悠太
話が止まった時に、鋭い発言をして話し合いが円滑に進んだ。前期では、時間外活動に参加しな
かったことが多かったが、後期ではすべてに参加しまじめに取組んでいた。
C.5.3
木村幸太朗
技術面やプランニングの際など、多岐にわたって的確な意見を言ってくれるのですごく参考に
なったし、頼れるメンバーであると感じました。また、プロジェクト演習やユーザー・センター
ド・デザインの講義など、大変忙しい身にもかかわらず、すごくがんばっていたように感じます。
C.5.4
中野佑
全体的に発言回数は少なかったが、的確な意見が多かった。話し合いよりも実装のほうに興味が
あるようで、データベース構築などの際には積極的に取組んでいた。今後は興味のない分野でも積
極的に取組んでほしいと思います。ただ、プロジェクト活動の時間内でプロジェクトに全く関係の
ない別の活動は控えたほうがいいと思います。
C.5.5
和田聖矢
前期と比べ、後期は時間外活動にしっかり参加していた。話し合いの場では、発言回数は少な
かったが、良い意見を出していた。データベース構築の際には、意欲的に作業に取組んでいたと感
じた。
C.6
和田聖矢
C.6.1
梅本祥平
前期に比べてディスカッションでの発言回数も大幅に増え、プロジェクトに貢献することができ
ていたと考えられる。成果発表会での質疑応答でも、的確な回答を行っており、その点を高く評価
したい。
C.6.2
菊谷悠太
成果発表での厳しい質問に対して、的確に回答していた。前期に比べて、発言の回数が増え、プ
ロジェクトが円滑に進んだと思った。プロジェクトが忙しくて空気が悪くなったときに、場を和ま
Group Report of 2012 SISP
- 70 -
Group Number 20-A
The New Portfolio System
させる発言をしてくれた。
C.6.3
木村幸太朗
UI 設計やペーパープロトタイピングなど、デザインの面でとても積極的にディスカッションへ
参加してくれたので、とても心強かったです。また、プレゼンテーションやポスター作りにも積極
的で、共同作業していてすごく楽しかったです。
C.6.4
中野佑
話し合いの際には的確な意見やみんなが気づかなかったところを指摘して、よかったと思いま
す。前半は意見が少なかったように思えましたが、後半になるにつれそれもなくなりました。発表
のときでも厳しい意見にも負けずにきちんと対応できていたのはよかったと思います。
C.6.5
山本賢人
プロジェクトの議論の場では、基本的に静かだが、指摘すべきところでは適切に指摘していたと
思う。また、Web アプリケーションに関する技術の知識が高いと感じた。
Group Report of 2012 SISP
- 71 -
Group Number 20-A
The New Portfolio System
参考文献
たかはしまさよし
ご と う ゆうぞう
[1] 高橋征義, 後藤祐蔵. たのしい Ruby 第３版. ソフトバンク クリエイティブ, 2010.
[2] Sam Ruby, Dave Thomas, David Heinemeier Hansson. Rails によるアジャイル Web アプリ
ケーション開発 第４版. オーム社, 2011.
もとはし し ん や
かわのたつや
つ る み としあき
[3] 本橋信也, 河野達也, 鶴見利章. NOSQL の基礎知識. 株式会社リックテレコム, 2012.
おがわ か
よ
お む ら みちあき
[4] 小川賀代, 小村道昭. 大学力を高める e ポートフォリオ. 東京電機大学出版局, 2012.
[5] JonathanRasmusson. アジャイルサムライ. オーム社, 2011.
Group Report of 2012 SISP
- 73 -
Group Number 20-A