東工大AGL山田道場 プログラミングワークショップJan-Mar/2016報告

2016年1月から約2ヶ月間に亘り、本学、一橋大学、慶応大学の学生が集まりWebアプリケーション開発を行うワークショップ「AGLプログラミングキャンプ」を実施致しました。本キャンプは、AGL3期生の石垣さん（知能システム専攻/D2）を中心としたメンバーが企画、事前ワークショップにおける勉強会のファシリテーション、メンターとしてお願いしたギルドワークス社の皆さんとのメンタリング内容の打ち合わせ等を行って実現したものです。参加者は、本学と一橋大学のAGL所属生13名とOPEN参加の１名（慶應義塾大学）でスタートし、最後の３日間の合宿には12名が参加しました。参加者のプログラミングに関する知識・経験のレベルはバラバラで、全くの初心者も4名ほどいましたが、事前学習の段階から2名１組でチームを組み、お互いサポートしながら、最後の合宿に入りました。全部で６チーム（１人になってしまったところもありますが）が、それぞれのテーマで「動くwebサービス」の構築に挑戦し、すべてのチームが完成させることができました。

チームリスト：
(1) 「酒蔵人」：日本酒のデータベースと愛飲者情報交換サイト：長濱・今野
(2) 「はるふる」：カフェ空席情報：齊藤・宮崎
(3) 「Trip Suggestor」：予算に最適な旅行場所案内：岡本・吉木
(4) 「くすりばこ」：薬飲み忘れ防止サイト：甲斐
(5) 「出合い酒」：高価なお酒をシェアして飲むサイト
(6) 「やさいいね」：野菜生産者とのコミュニケーションツール：松原・神原

以下、全体のファシリテーションを行った石垣さんのレポートです。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
• 事前ワークショップの概要
3月の合宿までに２ヶ月間は、学習サイトProg-8を用いた自習に加え、5回の事前ワークショップ（各回2時間ずつ）を行いました。

2016年1月19日 HTML/CSSの事前学習
2016年1月28日 Rubyの文法
2016年2月 8日 Rubyによるオブジェクト指向プログラミング
2016年2月23日 Ruby on Railsの基礎
2016年3月22日 Ruby on Railsによる家計簿アプリ作成
2016年3月25日 ～ 3月27日 開発合宿によるオリジナルWebアプリケーション開発
　　　

・開発合宿（25-26/Mar）の概要
開発合宿ではギルドワークス（株）から5名のメンターの方に参加・参画していただきました。各日を2つのイテレーションに分け、それぞれのイテレーションで「設計→実装→コードレビュー＆テスト」を繰り返す、いわゆるアジャイル開発を実践しました。

（初日）
午前中：　ユーザーストーリマッピングによるMVP（Minimum Viable Product, 必要最低限の機能を持った製品）の同定
お昼：　KPT（Keep, Problem, Try）による振り返り
午後：　コーディング→GitHubを介し、メンターがコードレビュー＆アドバイス
夕方：　KPTによる振り返り

ユーザーストーリーマッピングでは、「そもそもなぜサービスを作るのか？」「誰が使うのか？」「いつ使うのか？」「どのような目的が叶えられるのか？」という根本的な問いを、図として表現していきます。

例えば、「クスリバコチーム」のユーザーストーリマッピングの場合、遠くに住んでいる家族がきちんとくすりを飲んでいるか確認したいという課題を、薬箱の開け閉めを監視するシステムで解決できるか検証しています。また、最低限の機能を持った製品（MVP）に必要な機能とはなにかを明らかにします。

午後からは実際にRuby on Railsを用いたWebアプリケーション開発を行っていきます。作業を始める前に、どれくらいの規模のタスクであるか見積もり、このイテレーションでの作業を決めます。
　　

設計、実装を行い完了したらGitHubというサービスにアップし「プルリクエスト」という仕組みを使い、メンター陣と議論します。現役のエンジニアとの議論を通じ、自身の設計やコードを見直します。

（2日目以降）
午前中：　コーディング→GitHubを介し、メンターがコードレビュー＆アドバイス
お昼：　KPTによる振り返り
午後：　コーディング→GitHubを介し、メンターがコードレビュー＆アドバイス
夕方：　KPTによる振り返り

各イテレーションのあとに行った「KPT」では、継続すべきこと（Keep）、改善すべきこと（Problem）、次試すこと（Try）をホワイトボードに書き出し、本質的な問題はどのような点にあるか明らかにしていきます。例えば、Problemで「見積もり通りに作業が進まなかった」という点が上がったとすると、「なぜ見積もり通りに作業が進まないのか？」という疑問を繰返します。

参加者インタビュー（吉木くん、岡本くん）
合宿に参加した吉木くん、岡本くんは「Trip Adviser」というWebアプリケーションを開発しました。お二人に、ブートキャンプの様子をインタビューしました。

合宿で開発したTrip Suggesterのコンセプトを教えて下さい。
みなさんは普段、旅行の計画はどのようにしていますか？行きたい場所を決めて、飛行機を調べ、宿を調べ、予算を考え・・・すごく手間ですよね。手間を省くためにツアーを選ぶと飛行機や宿が微妙なこともしばしば。それに、パッと思い浮かぶ場所以外は、なかなか旅行に行く選択肢に入りません。
そういった従来の旅行計画を覆す！「予算と現在地だけ入力すれば、どんなところに行けるか提案してくれて、意外性のあるところに簡単に行けるサービス」。それがTrip Suggesterです。

どういった経緯でこのサービス開発に至ったのでしょうか？
岡本・吉木チームの技術的な目標は、「Web APIを駆使して、ほしい情報を取得し、分別し、表示する」でした。
何か題材になるAPIはないか・・・と探している中で、思いついたサービスが「Trip Suggester」でした。

どのように動作しますか？
この3日間で開発したv0.6では、「全国温泉版」ということで、北は北海道、南は鹿児島までの温泉地から、条件に合致するものをランダムに提案してくれるようになっています。
まず、予算入力です。スライダーで5000〜100000円の範囲内で、予算を決めます。
今回は、予算5万円で、出発予定の駅を「大岡山」にセットして・・・・検索開始です！

次のページでは提案結果が一覧表示されます。
宿情報と、宿泊費、往復の交通費がすべて計算されています。宿泊費と交通費の合計が、予算の範囲内になるようになっています。賢いシステムですね。
なんと、この予算なら意外にも十和田湖や田沢湖まで行けてしまうことがわかりました。


実装はどのように進めたのでしょうか？
岡本：特定の予算の入力とその予算内で行ける温泉付きの旅館の宿泊プランの検索と、その場所までの移動費の概算および予算内に宿泊費と移動費が収まっているかの結果および地図上の表示を最低限の機能としました。

宿泊プランの検索：公開されているAPIを用いて、いくつかの地域における検索を行い、宿泊先の候補を選定する機能を実装しました。
移動費の概算： APIから得た情報をもとにして、スクレイピング技術などを用いて移動費を概算するようにしました。
宿泊費と移動費の予算との判断：宿泊費と移動費がユーザーが入力した範囲を超えている場合に候補として表示されるリストの色が変わり一目でわかるようにしました。
地図上の表示：APIから得た情報をもとに地図APIに用いて表示を行いました。宿泊場所の距離感が伝わるように、日本全体のどこに散らばっているかわかるように表示を行いました。

ブートキャンプで成長できたことはありますか？
吉木：開発目標に向かってプログラミングができるようになりました。ギルドワークス様のメンタリングを通し、開発目標の設定と工程管理を体験的に学べました。しばしば、プログラミングに集中していると「やるべきこと」と「やりたいこと」の境界があいまいになり、本質的な生産性が落ちてしまいます。限られた時間内で必要なものを開発するためには、「やるべきこと」が何かを分析・把握し、集中し続けることが必要です。言葉にするのは簡単ですが、3日間の間で何度も「やりたいこと」をやってしまったり、「やるべきこと」を見失うことがありました。こういった状況を素早く修正し、開発目標に向かい直してプログラミングをする能力がつきました。

チームの生産性を高めるコミュニケーションを心がけられるなど、行動変容を主体的におこなえるようになった
吉木：はじめは、お互いに目標に向かっていなかったり、作業が一見重複しているように見えたり、コミュニケーションによって回避できるミスや衝突が何回もありました。何度か開発セッションの振り返りをしていくうちに、「30分に1回は軽く進捗報告をする」「分担は柔軟に変える」「データの受け渡し部分は、双方で提案しあえる状態になったら話し合いを始める」など、成果が最大化するように、その時々に適材適所に作業がすすめられるように行動を改善できました。
単にコーディングスキルが身につくだけでなく、改善しながらすすめるプログラミングプロセスの一端を学び取ることができたように思います。

岡本くんはどうですか？
岡本：実装下での作業と設計の共有が難しく、衝突することがあった。
今回各チームの開発作業に取り掛かる前に制作するもののストーリー(Why)や機能(What)を決めたが、どういう風に実現するか(How)は詰めていなかった。そのため分担して作業をするときに各々の状況下で作業をすることが多かった。時間が経って作業を共有してみると互いの想像とずれていることや内容が伝わりきらないことがあった。また、設計に関しては、いざ互いの実装したものをつなげてみようとなると互いのイメージの違いで衝突した。開発に対して何が必須で、そのために必要なこと・しないことの決定がいかに重要か身に染みて感じた。

コミュニケーションを通して互いのイメージを共有して、いかにずれをなくすが重要か学び、それらを習慣や取り組みにすることにより、チームの活動をより円滑にすることを確かめることができた。
作業中にこまめにコミュニケーションを取るということを習慣にすることによって互いの作業時間の変化がわかるようになり、ワークショップ内でのゴールの見通しや変更に関して問題なく決めることができた。今回設計の共有で議論が白熱した。互いに納得するイメージを共有することができたが、作業も中断したうえに多大なエネルギーを消費してしまった。もしその習慣や取り組みを早く実施していたなら、作業を進めながら設計の共有などもうまくできたのかと思う。チーム内でのイメージ・作業・手段、それらをいかにずれなく共有できるか、今回学んだ習慣・取り組みをつくることを今後の活動に活かしていきたい。
（文責：石垣達也　知能システム専攻D2/AGL3期生）
＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

１月からの事前学習から約２ヶ月間。みなさんご苦労様でした。特に、全体を設計し最後までやりきった石垣さんのリーダーシップに感謝します。
また、２日間フルにメンタリングいただきましたギルドワークス（株）上野さん、佐々木さん、川瀬さん、原さん、水谷さんに、厚く御礼申し上げます。