ソフトウェア・シンポジウム2016 in 米子

学生による UX ／アジャイルソフトウェア開発の YWT ふりかえり事例
浦本 竜
北九州市立大学大学院
w5mcb002@eng.kitakyu-u.ac.jp

奥村 潤
北九州市立大学大学院
w5mcb003@eng.kitakyu-u.ac.jp

佐野 隼輔
北九州市立大学大学院
w5mcb004@eng.kitakyu-u.ac.jp

要旨

山崎 進
北九州市立大学
zacky@kitakyu-u.ac.jp

ある．失敗の原因は，チームにおけるメンバー間の連携がうまく取れないことや経験不足等が考えられる．我々

チーム開発の経験が少ない初心者のみで構成されたは 2014 年に行った開発において，初めてチームで開発チームにおける開発は，様々な要因で失敗をすることがする機会があった．その時の開発で多くの失敗を経験し，ある．そこで，チーム開発の初心者であった我々が行っそれらについての対策を考えた．また，我々は 2015 年

た 3 件のアジャイル開発手法と UX を取り入れた開発経においてもチームで開発する機会があり，2014 年に考え験を YWT でふりかえることにより，教訓を導く．導かた対策を実行してみたところ，2014 年に比べ，良い開発れた教訓によって，初心者のみで構成されたチームにおになったと考えられる．そこで我々の開発事例を YWTける開発で，初心者にありがちな失敗を回避できるのでというふりかえり手法を用いてふりかえり，教訓を導くはないかと考えた．そこで本稿では以下 2 点のことを目ことで，初心者のみで構成されたチームにおける開発が的としている．

初心者にありがちな失敗を回避できるのではないかと考えた．そこで本稿では以下 2 点のことを目的としている．

• チーム開発の初心者に対して，失敗を軽減する為の教訓を導く• チーム開発の初心者に対して，失敗を軽減する為の教訓を導く• YWT の使用感を考察する
YWT でふりかえりを行い，教訓を導くことができた．

• YWT の使用感を考察する
本稿は以下の構成になっている．次の 2 章では YWT

また，次の開発の方針を定めることができた．教訓を導くことができ，次の開発の方針が定めることができるについて紹介する．3 章で 3 件の開発事例について紹介

YWT はふりかえり手法として有効であると考えられる．

する．また，それぞれの開発事例について YWT でふり

将来課題として，導き出した教訓は，初心者のみで構かえり，失敗を軽減するための教訓を導く．4 章でまと成されたチームに適用して効果を確かめる必要がある．

める．

またふりかえり手法として YWT は普遍的に有効である

2. YWT とはかを調査する必要がある．

YWT というフォーマットを利用して，ふりかえりを1. はじめに行う．YWT とはやったこと（Y），わかったこと（W），次にやることの（T）の頭文字をつなげたものである．

チーム開発の経験が少ない初心者のみで構成された

まず，YWT について，倉貫義人は次のように述べている [1]．

チームにおける開発は，様々な要因で失敗をすることが136

SEA

ソフトウェア・シンポジウム2016 in 米子

以前に紹介した KPT でふりかえるのが１〜２行う．YWT を繰り返すことにより，より良い学習につ週間程度だとしたら、YWT では半年単位くらながり，より良い教訓が得られると考えられる [3]．

いでふりかえりと戦略について考えます。

開発事例と YWT によるふりかえり

3

この YWT を考えるためには、将来に自分がどうありたいかといった漠然とでもビジョンが本章では我々の 3 件の開発経験を説明し，YWT でふなければ難しいでしょう。YWT を考える機会

りかえりを行う．

は、自分の未来のことを考えるきっかけでもあるのです。

2014 年における WEB アプリケーションの開発

3.1
また，松尾睦は次のように述べている [2]．

事例

先日、ある方から「YWT」というふりかえりの我々が 2014 年に行ったチーム開発によるソフトウェ手法を教えてもらった。
（中略）「これは面白い」

ア開発事例について説明する．と思ったのだが、この手法は、コルブ（Kolb）の経験学習モデルに対応している点に気がつ3.1.1

いた。コルブによれば、人は「具体的な経験を→内省して→教訓を引き出し→新しい状況へ応

開発概要

表 1 に開発概要について示す．

用」することで学ぶという。つまり、YWT 分
析は

表 1. 開発概要「何を実施したのか（具体的経験）」（Y)

開発人数

5名

開発期間

9 月 20 日〜12 月 20 日

アプリ名バトリング

プラットフォーム

Ruby on Rails

ソースコード行数

約 2500 行 (自動生成の行も含む)「何がわかったのか（内省＆教訓）」（W)「次に何をすべきか（新しい状況への応用）」（T)を考えることで、職場の経験学習を促進すことができる。
文献 [1]，[2] より，3 章で紹介する，我々のチームで開発したソフトウェアの説明を以下に示す．

行った 3 つの開発事例の開発期間が約 4ヶ月であることと YWT でふりかえることによって，教訓を導き出し，初心者のみで構成されたチームにとって，より良い学習• 対象ユーザーは対戦型ゲームで遊ぶ人と定めた．
• 対象ユーザーが同じゲームで遊ぶユーザーと親交をになるのではないかという 2 つの考えから，YWT を採深めることができるように，コミュニケーションを用することにした．本稿では，我々が行った開発事例をとれる機能を開発した．

以下のようにふりかえる．

• 実力を試したいユーザーがトーナメント式の大会を

1. やったこと（Y）で具体的体験をふりかえる

簡単に開催・参加できる機能を開発した．

2. わかったこと（W）で 1 の内容から，わかったことや気づきをふりかえる

3.1.2

3. 次にやること（T）で 2 の内容から次にすることをソフトウェア開発経験

ソフトウェア開発経験を 2014 年 9 月 20 日〜10 月 31

考える日，11 月 1 日〜11 月 30 日，12 月 1 日〜20 日の大きく3 つの期間に分ける．

このフォーマットの，わかったこと（W）が教訓になり得る．改善が見込めるわかったこと（W）は次にやるこ

1. 2014 年 9 月 20 日〜10 月 31 日についてと（T）で，改善できるような仮説を立てる．その仮説

この期間では制作するソフトウェアの仕様とそのを実際に次の開発で実行し，再び YWT のふりかえりを対象ユーザーを定めた．10 月 20 日までを Ruby on137

SEA

ソフトウェア・シンポジウム2016 in 米子

Rails の学習期間とした．学習期間が終了した後に– 1 週間おきに定期会議を行って，全員がプロ開発を開始した．開発にはアジャイルソフトウェア

ジェクトについて考える機会を設けた．

開発を適用して行った．11 月の期間ではイテレー– プロジェクトマネージャーの選出を行った．

ションを繰り返した．

– ファイルの共有や履歴を管理するため，バー

2. 11 月 1 日〜11 月 30 日についてジョン管理ツールを導入した．

– 開発終了後に開発経験についてふりかえりを• 進捗の確認の不十分で，プロジェクトが遅延し行った．

た．従って，定例進捗会議を行うようにした．

• プロジェクトを管理する役を決めていなかっ• UX を意識した設計を行った．

たため，プロジェクトの全体を把握することができなかった．従って，プロジェクトマネー– ペルソナ法を用いて，ユーザー像を定義した．

ジャーを選出した．

– ペーパープロトタイプを作成した．

• 開発メンバー間でユーザーストーリーの優先度の認識がかみ合っていなかったため，ユー3.1.4

わかったこと（W）

ザーストーリーの優先度の統一を行った．

• プロジェクトを管理していない時に比べ，プロジェ• 設計の際，開発メンバー間で認識がかみ合ってクトを管理している時の方が作業が円滑に進む．

いないことが発覚したため，開発メンバーの認識を統一するために，プロトタイプとして，– 定期会議を行うことにより，進捗の確認や現紙にインターフェースを手書きしたペーパー

在の問題点等の情報をメンバー間で共有するプロトタイプを作成した．

ことで，次の週の開発における方針決めや，問題点に対応できる．

• 作成・編集されるファイルの変更履歴を管理していなかったため，全員でのファイルの共– プロジェクトマネージャーがチームにいない

有とバックアップができなかった．また，ファ時は，会議を行う間隔がばらばらであった．しイルの共有が出来ていなかったのでマージはかし，プロジェクトマネージャーがプロジェク変更したファイルを渡し，手動でマージした．

トを管理することにより，1 週間おきの定期会

従って，この問題を解決するために，バージョ議を行うようになった．それぞれのメンバー

ン管理ツールを導入してソースコードを開発の進捗を全員で共有する場を設けることで透メンバー間で共有した．

明性が向上し，プロジェクトが円滑に進む．

• フィードバックを得ることなく開発を進めて– メンバー全員が常に最新のファイルを持つこいたため，ユーザーに価値があるものを実装とができ，バージョン管理ツールを導入してできているのか不明瞭だった．この問題を解いなかった時と比べ，時間短縮となる．

決するために，想定ユーザーが使用している様子を観察することでフィードバックを得た．

それぞれのメンバーが感じた成功したことと失敗したことを共有でき，次の開発における3. 12 月 1 日〜26 日について仮説を立てることができる．

チーム開発が終了した後，プロジェクト全体のふりかえりを行わなかった．チーム開発の経験者に指摘• UX を意識することによってプロダクトの品質が上され，プロジェクトのふりかえりを行った．

3.1.3– メンバー全員参加のふりかえりを行うことで，がるだけでなく，一種の指標になる．

– ペルソナ法を用いてユーザー像を定義したこ

やったこと（Y）とにより，実装する機能がユーザー像に対し• 数々のチーム運営における失敗から，改善行動をてどのような効果をもたらすかという視点で行った．

考えることができる．

138SEA

ソフトウェア・シンポジウム2016 in 米子– ペーパープロトタイプを作成することにより，認識の統一を計ることができる．また，ペーは現在地周辺にある店舗がわかり，店舗に行かせる

パープロトタイプは，ページレイアウトを考動機付けをさせる狙いで開発した．

える際に想定したユーザーが使いやすく，使• 対象ユーザーは実店舗にプレゼントを買いにいく 20

用後の満足感が高くなるように意識して作成

歳前後の女子大学生と定めた．

した．

3.1.5

• 一言で言えば，店舗情報提供サービスである．これ• アイテム別のチェックボックスを用意し，検索機能とした．検索した結果，検索条件に合致したお店が次にやること（T）表示される．さらに，お店を選ぶとお店の詳細情報• プロジェクト初期に，開発が円滑に進むような仕組を確認することができる．

みを導入する．

– プロジェクトの状態を把握できるような仕組
3.2.2みを調べ，導入する．

– プロジェクトマネージャーを選出する．

ソフトウェア開発経験を 2015 年 9 月 20 日〜10 月 31日，11 月 1 日〜11 月 30 日，12 月 1 日〜20 日の大きく– プロジェクトの始めにメンバー全員でプロジェ3 つの期間に分ける．

クトについての考えを共有する．

– バージョン管理ツールとして Github を用いた

1. 2015 年 9 月 20 日〜10 月 31 日についてが，習得が不十分であったため，次のプロジェクトが始まる前までに習得しておく．

• チームビルディングの一環として，インセプ– 定期的にふりかえりを行う．

ションデッキ [4] を作成した．その際にプロジェクトマネージャーの選出を行った．使用するフ• 開発を通して，UX を意識した開発の経験を積む．

レームワーク，チケット管理ツール，バージョ– ユーザーの価値を創造できるような方法を考ン管理ツール等を決定した．

え，導入する．

3.2• プロダクトの方針を決定するために，事前アンケートを実施した．アンケートの対象は 202015 年における WEB アプリケーションの開発

歳前後の大学生であり，100 件以上回収した．

事例• GitHub や Ruby on Rails 等の使用するツール

我々が 2015 年に行った，チーム開発によるソフトウェについて事前に学習した．

ア開発事例について説明する．

3.2.1

ソフトウェア開発経験• ペーパープロトタイプを作成した．
• ER 図の作成を行った．

開発概要• 我々で定めた，ユーザーが目的を達成できる

表 2 に開発概要について示す．

最小限のプロトタイプを開発した．

2. 11 月 1 日〜11 月 30 日についてユーザーが目的を

表 2. 開発概要
開発人数

3名

達成できる最小限のプロトタイプが出来た段階でア

開発期間

9 月 20 日〜12 月 20 日

プリケーションを使ってもらい，その様子を観察す

アプリ名Gift toること，及び使用後の感想を聞くことという 2 点をプラットフォーム

Ruby on Rails

をフィードバックとして開発を続けた．ユーザーテ

ソースコード行数

約 2600 行 (自動生成の行も含む)

ストは 1 度目に 2 人，2 度目に 3 人の計 2 度，5 人に対して行った．

開発したソフトウェアの説明を以下に示す．

139SEA

ソフトウェア・シンポジウム2016 in 米子

3. 12 月 1 日〜26 日についてはメンバー間におけるゴールの不一致や，大ページデザインをブラッシュアップした．

切な機能は何かということや，メンバーの役

プロジェクト終了後に KPT で，プロジェクトのふ割は何かということ等で発生した．インセプ

りかえりを行った．

ションデッキでは，それぞれの役割，エレベーターピッチ作成等を定めるため，去年発生し3.2.3

た余計なコストが比較的かからず，プロジェクやったこと（Y）トが円滑に進んだ．

• プロジェクトを始めるにあたって，プロジェクトが• UX を高めるために行った方法はいずれも有効な手円滑に進むように新たな方法を導入した．

段であると考えられた．

– チケット管理ツールを用いて，プロジェクトの– 開発前にアンケート調査を行う事は，有効なタスク管理を行い，タスクの可視化を行った．

手段であったと考えられる．しかし，アンケー– プロジェクトの始めに，チームビルディング

トの内容が深く練ったものでなかった為，得の一環として，インセプションデッキの作成られた学びは少なかったと考えている．目的を行った．この時，プロジェクトマネージャーを明確にし，それに合わせたアンケート作りの選出を行った．

をする事で，得られる学びに違いがあるのではないかと考えた．

• UX を意識したアプローチを新たに導入した．

– ユーザーテストにより，得られたフィードバッ

– アプリを作る方針を決定した後，想定ユーザー

クを元に，機能やタスクの優先順を選び開発が実際どのような点で困っているのかを知るたする事で，次のユーザーテストの際，ユーザーめに，開発前にアンケート調査を行った．対象からよいフィードバックを得ることができる．

は 20 歳前後の大学生であり，100 件回収した– 想定ユーザーがある目的を達成できると予想

3.2.5

される最小限の機能を開発できた段階で，実際に想定ユーザーに使ってもらった．使用中

次にやること（T）• プロジェクト運営の観点で，チームの生産性を上の様子を観察，また使用後にインタビューをげる．

行い，それをフィードバックとして次に開発– チーム内で勉強会を開き，チームメンバーがする機能の参考にした．

互いに教え合う事で，チームのレベルが上がるのではないかと考えた．

3.2.4

わかったこと（W）– 我々は開発におけるテスト工程の際，コードを記述し，実行画面を開き，手動で動作確認• プロジェクトの初期から開発環境を整える事で，余をするテストのみを行っていた．そこで，テス計なコストを抑える事ができる．

ト駆動開発を試し，手動で動作確認をするテ– 2014 年の開発では，ホワイトボードに書き留ストと比較する．比較した結果を考察し，今めるという方法でタスクを管理していた．そ後の開発に活かす．の時と比べると，残りのタスクの確認コスト• ユーザーの価値について考え，チームにおける価値が低くなることや，タスクを優先度が高い順も高める．に並べているので取りかかるべきタスクが認知しやすく，タスクの分担も容易である等の– 目的をはっきりさせて，アンケートを作成す利点があった．

れば，さらに学びが大きくなるのではないか– 2014 年の開発では，認識のずれにより開発にという仮説を立てた．次のプロジェクトでは，余計なコストがかかってしまった．認識のずれ

行動を起こす際，目的をはっきりさせる．

140SEA

ソフトウェア・シンポジウム2016 in 米子– プロジェクトの始めに定めたペルソナである

使用したいというものが存在したため，条件が，これが妥当なものであるかという事を第に合うような Wi-Fi モジュールを調査した．

三者にレビューを行ってもらう事で，UX の高• 必要な電子パーツをリストアップして，調達いプロダクトが作成できるのではないかと考した．

えた．

• Wi-Fi モジュールを使うための初期設定を行った．

IoT デバイスの開発経験

3.3

2. 2015 年 11 月 1 日〜11 月 30 日この期間は主に，デ3.3.1

開発概要

バイスを組み，通信テスト等を行った．

表 3 に開発概要について示す．

• デバイスの回路図を作成し，回路図の通りに

本事例はインターンシップの一環として行った開発でデバイスを作成した．

ある．インターンシップ先の企業の方を顧客と見立て• kintone 上にアプリケーションを開発した．こて，毎週ミーティングを行い，顧客の要求するシステムのアプリケーションで作業時間の記録を確認を開発した．開発したプロダクトは一言で言えば，作業することができる．

管理デバイスである．複数の仕事を持っている人がそれぞれの仕事に費やした時間を記録できるような仕組みを

3. 2015 年 12 月 1 日〜12 月 25 日

Arduino を基調としたデバイスと kintone[5] というクラ• タクトスイッチを押すと，時刻データを送信

ウドサービスで構築し，作業管理デバイスとしている．

する機能を実装したデバイスの部品として，主に Wi-Fi モジュール，タクト• LED を実装し，デバイスの状態を知ることがスイッチ，LED，SD カードリーダーを使用している．タ可能となった．

クトスイッチを押すと，kintone と通信が行われ，タクトスイッチを押したときの時間を記録する．LED はデバイ

• SD カードモジュールをデバイスに組み込み，SSID やパスワードを登録を簡単にした．

スの状態を表すインジケータとして使用した．SD カー
ドリーダーは Wi-Fi の SSID やパスワードを SD カード4. 2016 年 1 月 5 日〜1 月 31 日この期間は最終調整をに記録し，より利便性が高くなるように使用した．

行った．

3.3.2

• データが送信失敗した時に再送する機能を実2015 年における IoT デバイス開発経験

装した．

IoT デバイスの開発経験を 2015 年 10 月から 2016 年• 2016 年 1 月 26 日時点で，デバイスにかかった1 月までを，1ヶ月ごとに分けて記す．

コスト計算書を作成した．

1. 2015 年 10 月 1 日〜10 月 31 日この期間は主に，仕様に関することを顧客と話し合ったり，技術調査を3.3.3

YWT による事例のふりかえり

3.3.4

やったこと（Y）した．

• 定期ミーティングの場で顧客の要求を調査し，要求を満たせるようなシステムを提案した．例• クライアントの要求を調査し，システム案を作成した．

えば，通信方式を Wi-Fi にすることや LED はデバイスの状態を表すインジケータとして使• デバイスに関するやったこと．

用すること等である．

– Wi-Fi モジュールの初期設定や必要な電子パー• 通信方式が決定してから，Wi-Fi モジュールのツのリストアップ等で時間がかかった．

調査を行った．顧客の要求の中に HTTPS 通• 文書を作成した．

信をすることと可能な限り低コストなものを

141

SEA

ソフトウェア・シンポジウム2016 in 米子

表 3. 開発概要
開発人数

3名

開発期間

2015 年 10 月 1 日〜2016 年 1 月 31 日

プロダクト名作業管理デバイス

プラットフォーム

Arduinoソースコード行数660 行– 消費電力に関する調査報告書を作成した．
– デバイスにかかったコスト計算書を作成した．

• プロジェクトの初期からチームビルディングやタスク管理ツールを決定する等の開発環境を整える事

で，認識のずれによる手戻りやツールを使わない事で発生する余計なコストを抑える事ができる．

わかったこと（W）

3.3.5• UX を高めるために，アンケートによる事前調査を• 顧客と認識をすり合わせる難しさと大切さがわか行う事は有効である．

った．

YWT で開発をふりかえる事によって，内省し，教訓を• ハードの知識が乏しいということがわかった．

導く事ができた．この方法で得られた教訓は他の初心者• 文書を作成する際，他者が読み，理解できるようにのみで構成されたチームに適用し，有効性を確認する必書くことが難しいことがわかった．

要がある．また，YWT によるふりかえりの次にやること（T）から，2016 年における開発の方針が定まった．
開発の方針を以下に記す．

次にやること（T）

3.3.6• チーム全体の開発レベルを上げるために，チーム内• 顧客が要求の背景に考えていることを意識して，知で勉強会を開く．

る努力をする．

• テスト駆動開発を試す．

• デバイス構築のための電子パーツの知識が乏しいので，早急に必要になりそうなパーツをまとめて，先• 行動を起こす際，目的をはっきりさせる．

達のレビューを受ける．

• ペルソナ設定をより良いものにするために第三者に• 普段からアウトプットする習慣をつけ，文章を書くレビューをもらう．

練習をする．

• 顧客が要求の背景に考えていることを意識して，知る努力をする．

4. まとめ
4.1• デバイス構築のための電子パーツの知識が乏しいの

YWT によるふりかえりから得られた教訓

で，早急に必要になりそうなパーツをまとめて，先達のレビューを受ける．

YWT によるふりかえりから以下 4 点の教訓が得られた．

• 普段からアウトプットする習慣をつけ，文章を書く練習をする．

• プロジェクトを管理していない時に比べ，プロジェクトを管理している時の方が作業が円滑に進む．

4.2• UX を意識することによってプロダクトの品質が上

YWT を使ってみてどうだったのかがるだけでなく，追加しようとしている機能は想定3 章で紹介した開発事例では，開発を行っている最中ユーザーにとって価値があるのかといった考え方がは 1 週間ごとに KPT でふりかえり，また開発期間が約4ヶ月の各事例について YWT で振り返った．YWT のわできるようになるため，一種の指標になる．

142

SEA

ソフトウェア・シンポジウム2016 in 米子

参考文献かったこと（W）はやったこと（Y）を振り返ったとき有効であった経験を教訓とし，さらに改善するための仮説があれば次にやること（T）で改善するための仮説を[1] 倉貫義人，ビジョンを叶えるために。個人でも出来る戦略を考える第１歩 〜 YWT を使った戦略の立立てる．やったこと（Y）で改善する必要がある場合は次にやること（T）に改善するための仮説を立てる．こてかたとは，http://kuranuki.sonicgarden.jp/2013/06/ywt.htmlのやったこと（Y）からわかったこと（W）を挙げる内省は KPT の K と P に相当すると考えられる．次にや[2] 松尾睦，ラーニング・ラボ，http:///blog.goo.ne.jp/

ること（T）はわかったこと（W）から挙げられること

mmatu1964/e/585f7611fd43892f871e3aa0f2ﬀe4bbと同様に，KPT は K と P から T を挙げるので YWTの次にやること（T）と KPT の T は同質のものだと考[3] 松尾睦，職場が生きる人が育つ「経験学習」入門，ダイヤモンド社，2011

えられる．YWT と KPT の違いは YWT のやったこと（Y）を可視化するところである．KPT の K と P は実

[4] Jonathan Rasmusson，アジャイルサムライ-達人開発者への道，オーム社 開発局，2011

経験から挙げていくとはいえ，プロジェクトの実体験を可視化しないため，YWT のやったこと（Y）を挙げてから，わかったこと（W）につなげるプロセスが KPT[5] サイボウズ，kintone，https://kintone.cybozu.com/
jp/の K や P を挙げることより簡単だと考えられる．故に開発期間中をふりかえる場合は KPT が適しており，長期の開発経験をふりかえる場合は YWT が適していると考えられる．
また，やったこと（Y）で開発中に行ったことを列挙した．わかったこと（W）で具体的体験を内省し，教訓を導き出した．次にやること（T）では，開発活動を改善するための仮説を立てた．仮説を立てることで，次の開発の方針を定めることができた．教訓を導くことができ，次の開発の方針を定めることができる YWT はふりかえり手法として有効であると考えられる．

4.3

将来課題

導き出した教訓は，初心者のみで構成されたチームに適用して効果を確かめる必要がある．またふりかえり手法として YWT は普遍的に有効であるかを調査する必要がある．

5

謝辞2014 年と 2015 年おける WEB アプリケーションの開発事例において，ハウインターナショナル 村上照明氏，

IoT デバイスの開発経験において，名古屋大学 舘伸幸
久米純矢氏にとくに謝意を記す．

氏，AISIC

143

SEA