AgilePBL祭り（2020/02/21）にて，研究活動をアジャイルやスクラムのやり方を参考にやっています，ということを発表しました．

1. #agilepbl
スクラムで研究プロジェクト
筑波大学 阿曽太郎

2. スクラムで研究プロジェクトとは何か？
渡辺知恵美先生（筑波大学/筑波技術大学）の実験的企画
”スクラムの「短いスパンで目標を決め、アウトプットをして、振
り返りをする」というサイクルが個別の研究活動としても活用で
きる、という仮説をもとに、研究をすすめる”
今日発表すること
● 自分の研究活動をスクラムでやってみた”結果”
● ”具体的な取り組み方”

3. 私の研究テーマ
● テーマ：知識ベースのファセット検索
○ 知識ベース：多様なエンティティに関する知識がトリプルという形式で記述されている
○ ファセット検索：専門知識がない場合でも，多様な切り口によって，情報を絞り込むことで検索を可
能にする探索的検索の 1つ
● 研究の目的
○ 知識ベースの検索をしやすくすることで，多くの人が知識ベースを使えるように
したい

4. プロジェクトにおける自分の研究活動の目標
ゴール：学会への論文投稿
サブゴール
● 手法検討
○ 手法の検討
○ 実装
○ 検証
● 提案システムのアーキテクチャの検討
● 論文執筆

5. プロジェクトのスケジュール
● 週に2回，プロジェクト参加者が集まり，作業，スプリント計画ミーティングやレビュー
，PBLリファインメントメント，振り返り，等を一緒に行う．
スプリント 水曜 金曜
Sprint0 11/15
Sprint1 11/20 11/22
Sprint2 12/4 12/6
Sprint3 12/11 12/13
Sprint4 12/18 12/20
Sprint5 1/8 1/10
発表会 1/20の週
プロジェクト説明
PBL作成・整理

6. 1. （11/18ー）：手法の検討
2. （11/25ー）：検討した手法の実装
3. （12/02ー）：検討した手法の検証
4. （12/09ー）：手法の検討，調査
5. （12/16ー）：検討した手法の実装，検証，abstractの執筆/提出
6. （12/23ー）：検討した手法の見直し，実装，検証，draftの執筆
7. （01/06ー）：システムのアーキテクチャ検討，draftの執筆/提出
〜プロジェクト終了後（個人で続けている）〜
8. （01/14ー）：提案システムの部分的な機能の実装
9. （01/20ー）：提案システムの部分的な機能の実装，被験者実験検討
10. ・・・
11. （02/17ー）：発表スライド作成，ポスター作成
スプリントごとの成果
最終ゴール「学会への論文投稿」は達
成した
現在も続いている
〜
13.

7. 取り組む際の意識
● 前提
○ 研究は本プロジェクトが設定されている水・金以外の日も進める必要がある
○ 1週間の中には研究に直結しないこともある（講義の予復習や課題，ゼミでの論文紹介など）
● 考え方
○ 水・金の取り組み方を他の曜日にも展開して， 1週間全体をスプリントとする（むしろ， 1週間の中に
水・金の集まってやる時間がある，と意識する）
○ スプリントにおけるゴールやタスクとは別のタスクがあることを考慮できるようにする
● やったこと
○ 全体
■ 研究に関するスプリント資料と他のタスクを含めた 1週間のタスクリストを作ってから 1週間を
スタートする
○ 水曜・金曜
■ フィードバックをもらうタスク
○ 他の曜日
■ フィードバックをもらうための準備タスク

8. 取り組み方（週全体）
研究に関するスプリント資料 他のタスクを含めた 1週間のタスクリスト
研究以外も含
めた1週間の
ゴール
研究以外も含め
た毎日のタスク
(だいたい3〜4
個が限界だとわ
かる)
アイデア，
ぼやき，など
前スプリントの
達成状況
今回のスプリン
トで達成したい
こと，付随する
タスク
タスクの詳細，
結果，疑問など
何でも．
実装すべきこと
，検証すべきこ
と，など

9. 取り組み方（曜日別）
月・火・木
● 月
○ 前週を振り返り，スプリント計画（スプリント
資料の作成）を立てる
● 月・火
○ 水曜にフィードバックをもらいたい内容につ
いて準備を進める（手法のアイデア，実験
結果，など）
● 木
○ 水曜にフィードバックをもらった結果を受け
て軌道修正をする
○ 軌道修正したタスクを進める
水・金
● 水
○ 前回のスプリントの達成状況および月火の
タスクについて説明し，フィードバックをもらう
● 金
○ 軌道修正後のタスクを進める
○ 今週のスプリントの達成状況をまとめる

10. KPT
Keep
● 月曜日にスプリント資料と研究以外のタスクを含めたタスクリストを作る
○ あとはスプリント資料とタスクリストに従うだけ ，という状態を作り出せる
● タスクで得られた成果や疑問は，即スプリント資料に書き込む
○ すでにタスクでページは作ってある． 何のタスクで得た成果か，生じた疑問なのかがわかる と，後で見
返しやすい，説明しやすい
● 人に説明するタスク を入れる
○ スプリントが締まる，軌道修正できる
Problem
● 実装系のタスクは延々とやってしまいがち（できると次を実装したくなり，詰まると試行錯誤を続けてしまう）
● 2スプリント以上先のことはあまり考えられていない
● 他の学生とのシナジーはあまり感じられていない
● プロジェクトが終わってからは（人に話す時間が週 1となり），週内で軌道修正ができていない
Try
● 最近になってバックログを作り出した

11. 議論
● スクラムは研究でも使えそうだ
○ 個人の研究活動にリズムが生まれる
○ フレームに従って働く・学ぶ・研究する方が楽
● 研究以外にも応用できそう
○ 例：ビジネスサイドの企画職
■ 企画のタネを検討している時は孤独で，思考も迷走，成果も見えづらい．
■ 上司や関係メンバーも「何やってるのか？」理解しづらい
■ スプリントを意識していないと突発的に頼まれた仕事に追われてしまう

12. AgilePBL祭りを終えて（追記）
● 個人の学び／わかったこと
○ 現時点での自分の活動はスクラムではなく（チームが見えないため），アジャイルに研究を進めるプロジェクトか
もしれない
○ スクラムとアジャイルの違いとかよくわかっていないことだらけなことがわかった
○ このやり方に興味を持つ人は一定数いるから，皆で耕していい文化作りたいな
○ スプリントは（休みなどをのぞいて）同じ間隔で切れ目なく続けることに意味がありそうだ
■ 企業の半期の目標管理制度（MBO）が形骸化しがちなのは，明確な形で日常に落とし込めていないか
ら，が要因と推察する
○ きょんさんの“基盤チームのスクラムのやり方”をもう一度聞きたいと思った（本プロジェクトには基盤チームのス
クラムのやり方が応用されていて，当初拝聴したがあまりピンと来てなかった）
● AgilePBL祭りに対する感想
○ PBLで学生が学んでいることはかなり幅広くて多分発表できていないこともたくさんあるはず．だからこそ，発表
する場があり，議論できる場としてのAgilePBL祭りは貴重な機会だと思った．場があり，喋ることで，できるだ
け暗黙知を拾って顕在化していくことができる．
○ 自分は働いているとき，様々な要因で，実践できなかったり学びに気付けなかったのかなと思うことがある．だ
から，PBLのような純粋な状態は実験環境ともいえ，純粋な状態だったら得られることは何か？がわかる．あと
は，どのように複雑な環境で実現するか，そういう議論の場としてもいいな，と思った．