プロダクトエンジニア養成講座@リブセンスのwebアプリケーションコース用研修資料を公開します

はじめに

リブセンスで不動産売買サービスIESHILのエンジニアリングマネージャーしてる@tchikubaです。

今回縁あって、実務未経験の学生向けにプロダクトエンジニア養成講座（webアプリケーションコース）なるインターンのメンターを担当しました。Ruby on Railsを用いたwebアプリケーションの開発を「何を作るか」を定義して「チームで」行う、というものです。

個人的に社会人向けのプログラミング教育に関心があったので良い機会でしたし、未経験者の可能性を広げる意味でも社会的意義が大きいと感じています。

実際に受け入れた2名のメンバーから研修資料を終了後も見れるようにして欲しいと要望頂いていたので、せっかくなので資料を公開します。

期間中、コワーキングしながら作成した資料もあり、それも見れるようにした方が実際に何をやっていたのかより具体的にイメージが湧くのですが、社内のコンフルエンスからQiita記事にサルベージするのが思ったより面倒だったので力尽きました（ニーズあれば追記するかも？）

それでは以下、研修資料をお楽しみください

---

ようこそリブセンスへ！

プロダクトエンジニア養成講座、始まります！！

ここでは、webアプリケーションコース研修の流れについて確認します。

概要

大まかには、以下を研修内容として取り組みます。

• メンターも含めた3人で動くプロダクトを1つ開発する。
• メンティー個人の課題に個別で取り組む。
• 業務レベルのプロダクト開発の現場を体験する。

スケジュール

以下のようなスケジュールで研修を進める想定です。

1週目：9/2(月)〜9/6(金)

• 研修の課題について知る。

  • 01.課題解決するプロダクトを開発しよう

• 実際に開発するプロダクトを検討する前に、プロダクト開発検討の手法について学ぶ。

  • 02.何を開発するかをどうやって決定する？

• 開発プロセスについて基本的な事項を学ぶ。

  • 03.実際に開発（実装など）をどう進めるのか？

• より実践的な実務上での開発プロセスも学んでおく。

  • 04.開発する機能を決める実践例（IESHILの事例）

• 技術的な知識などを補完しつつ、環境構築などを進めていく。

  • 05.プロダクト開発の技術的な側面を知ろう

2週目：9/9(月)〜9/13(金)

• 具体的に作る部分をやりきる1週間。
• 基本的にこの週は3人でモブプログラミングを行う予定。
  • その前に開発（主に実装まわり）の前提知識を補う。
    • 06.チームで実装する
• 最終日に以下の会を行う。
  • お披露目会（スプリントレビュー）
    • 07.開発したプロダクトの成果を発表しよう
  • 反省会（KPT）
  • （やるとしたら）次何やる会（スプリント計画）

3週目：9/17(火)〜9/20(金) ※9/16(月)は祝日 ※Iさん中抜け

• このタイミングでは一旦Iさんが中抜けするので、1〜2週目に学んだことを元に、Kさん個人プロダクトの改善を行う。
• 具体的に何をやるかはKさんと相談して決める。
  • 08.1weekフリーテーマで何をやるか検討しよう
• 初日にスプリント計画を行う。
  • やりたいことの洗い出し（ICEBOX）
  • 優先度順に並べ替え（プロダクト・バックログ）
  • この週でできることを選択（スプリント・バックログ）
• この週は月曜日が祝日でお休みで1日少ないのでその点も考慮して計画する。
• ここでは敢えて私とのペアプログラミングは行わない予定。
  • GitHubフローでPRベースの開発に慣れてもらう目的。
  • コードレビューを通じて開発を行う、ペアプロ／モブプロの体制なしバージョンも体験。
• 2週目同様、最終日にスプリントレビュー／KPTを行う。

4週目：9/24(火)〜9/27(金) ※9/23(月)は祝日 ※Kさんここまで

• 2週目の最終日に行ったスプリント計画を元に引き続きプロダクト改善を行う。
  • 09.開発したプロダクトに手を入れよう
• この週は月曜日が祝日でお休みで1日少ないのでその点も考慮して計画する。
  • 2日しか取れなそう。
• スプリント計画の進捗次第で、後半2日を使ってIESHILのプロダクト改善を行う。
  • 10.IESHILのプロダクト開発を体験しよう
• 最終日、Kさんはインターン終了となるのでできれば打ち上げ的な何かやれれば！

5週目：9/30(月)〜10/4(金) ※Iさんここまで

• このタイミングでは既にKさんがインターン終了でIさん1名となる。
• 1〜2週目に学んだことを元に、やりたいことをIさんと相談して決める。
  • 08.1weekフリーテーマで何をやるか検討しよう

• 初日にスプリント計画を行う。

  • やりたいことの洗い出し（ICEBOX）
  • 優先度順に並べ替え（プロダクト・バックログ）
  • この週でできることを選択（スプリント・バックログ）

• ここでは敢えて私とのペアプログラミングは行わない予定。

  • GitHubフローでPRベースの開発に慣れてもらう目的。
  • コードレビューを通じて開発を行う、ペアプロ／モブプロの体制なしバージョンも体験。

• 2週目同様、最終日にスプリントレビュー／KPTを行う。

研修資料

01.課題解決するプロダクトを開発しよう

プロダクトエンジニア養成講座メインの研修となる、プロダクト開発を行います。

ここでは、プロダクト開発におけるゴールやコンテキストについて紹介します。

ゴール

プロダクト開発のゴールは以下を想定しています。

• 何を作るかの一連のプロセスを体験する。
  • リーンキャンバス作成
  • インセプションデッキ作成
  • 詳細は02.何を開発するかをどうやって決定する？
• 限られた期間内にプロダクト開発するノウハウを体験する。
  
  • ユーザーストーリー設計
  • プランニングポーカーによる協働見積もり
  • MVPの意志決定／スプリント計画
  • 詳細は03.実際に開発（実装など）をどう進めるのか？
• 実際にエンジニアが現場で実践していることを体験する。
  • 各種技術要素
  • 開発環境構築　など

コンテキスト（制約条件）

以下の条件で開発するプロダクトを決定する。

MUST条件

• 3人（Kさん、Iさん、私）の共通の課題を解決するプロダクトを開発すること。
  • ドッグフーディング（自分がユーザーとして試せる）できることは重要な要素。
• 1週間程度で最低限の課題を解決する、動くプロダクトができる見込みが立ちそうであること。
• Rails6（8/16にリリースされたばかり！）でwebアプリケーション開発を行い、本番環境としてHerokuにデプロイすること。

WANT条件

• テストコードで重要機能を保護すること。
  
  • これは研修の目的から踏まえるとMUST要件に近いけど、プロダクト開発という目線ではWANT。
• サーバーサイドの実装をメインとしたアプリケーションとすること。
  • 裏を返せばフロントエンドにはそれほどこだわらない。
• 現状見えている要件を加味した設計かつYAGNIにならないように配慮すること。

YAGNIとは
https://qiita.com/sesame525/items/fb2cfb23d0d7ef593014

others

以下は開発するプロダクトの案出しの軸を提供する意味合いで記載。

プロダクト観点

• 各自抱えている課題をリストアップ。
• 課題リストから共通点を探る。

エンジニアリング観点

• 何らかのAPIと連携する。
• 会員登録機能が必要かどうか。
  • 一般的には必要だけど期間の制約からあまり時間をかけたくはない。

02.何を開発するかをどうやって決定する？

ここでは、具体的に何を開発するか、大枠をどのようにチームで決めていくのか、その過程を学ぶと共に実践していきます。

何を開発するか決まっていないケース

このタイミングをエンジニアとして経験できるのはそもそも貴重かも。

だいたいのケースにおいて、ビジネスサイドが何か具体的に課題解決したい案を持っていて、エンジニアに話が来る時点で既に決まっていることが少なくないです。

真面目に経験するなら、ベンチャー企業の創業者（エンジニアならCTOとか）としてジョインするのが良さそうです。

2014Y新卒研修
リブセンスの2014年の新卒研修では、「あたらしいあたりまえを発明する」というビジョンを具体的に実践することを行っています。

とはいっても、エンジニアが個人的な課題を解決するために、個人的なプロダクトを開発する時はその限りじゃないと思います。

私自身もここは具体的な解を持っている訳ではありません（それができたらとっくに起業しているかもｗ）。

個人的な話で言えば、開発案リストみたいなものを持っていて書き溜めてそこからやりたいことを抽出していく感じでやっています。

この研修は時間に限りがありますが、プチ創業体験的な感じで「何を開発するか」から検討していきます。

せっかくなので、お題の通り、チームビルディング兼ねて3人の共通点を見出しつつ、何らかの課題解決する小さなプロダクトを開発していきましょう。

やりたいことの大枠がぼんやりでも決まったケース

実際にやりたいことが大枠でも決まってきたら、どういう機能をどういう順番で実装するのが良さそうかなどを決定していく必要があります。

本当は実装の前にプロダクトのニーズを確認するための「仮説検証」や「ユーザーインタビュー」などのフェーズを挟むことが少なくないですが、今回は時間の兼ね合いで省略します。

ここでは、以下の2つのフレームワークを作成するコワーキングを行います。

1. リーンキャンバス
2. インセプションデッキ

リーンキャンバスとは
簡単に言えば「そのプロダクトがユーザーの課題をどう解決するのか」を明確にするための手助けをしてくれる素晴らしいフレームワークです。特に最低限価値あるプロダクト（MVP）を明確にするのに向いています。MVPも含めて詳細はググってみてください。様々記事が出てきます。

インセプションデッキとは
こちらもリーンキャンバス同様ですが、より機能に特化＆チーム開発体制などを検討するための軸を明確にするフレームワークです。詳細は(ry

参考書籍

• リーンスタートアップ
• アジャイルサムライ

03.実際に開発（実装など）をどう進めるのか？

ここでは、どうチーム開発を行っていくのか、具体的な流れを学び、実践していきます。

実装に着手する前にやっておくこと

個人プロダクトなら、闇雲に手を動かしても良いんです。

ただ、機能実装の重さによっても着手する優先度が変わってきたりするので、ここではチーム開発的にやる流れをまずおさえておきます。

アジャイルな見積もりと計画

アジャイルとは
アジャイルって言葉くらいは聞いたことありますかね？英語で「俊敏な」という意味です。素早く必要な機能実装をする上で、どう開発プロセスをマネジメント（※この言葉はあまり好きではないけど）するか、先人達が基本的な考え方や具体的なプロセスを定義してくれています。個人的にはアジャイルソフトウェア開発宣言とアジャイルソフトウェアの12の原則についてはしっかり目を通しておくべきだと思います。

具体的には、ユーザーにどんな価値を提供するかを分割した文章（ユーザーストーリー）を記述して、それぞれのユーザーストーリーに対してストーリーポイントを付与します。

ストーリーポイントは、いろいろな考え方があるのですが、ここでは以下の定義を用いることとします。

• ポモドーロテクニックの理想時間（25分）ベースでのポイント制。
• つまり25分集中して終了できそうなタスクを1ポイントとする。
• 付与するポイントはフィボナッチ数（1,2,3,5,8,13,21）で付与。

ストーリーポイントの見積もりには、プランニングポーカーを使って3人でコワーキングします。

ポモドーロテクニックとは
25分、集中するタスクを実施して5分休憩＝30分を1つの単位（ポモドーロと呼称）として4ポモドーロやると15分休憩する感じのサイクルを続ける手法。つまり2h15mが4ポモドーロセットとなります。ここでクイズですが、1日8h労働だとして、どのくらいの数のポモドーロを消化できるでしょうか？ （ポモドーロテクニック既に知ってたらこのクイズ無意味かもですが）

プランニングポーカーとは
フィボナッチ数が書かれているトランプみたいなカードのことです。ものによって1/2（1より小さい粒度）とか∞（見積もり不可）みたいなのがあったりします（だいたいのプランニングポーカーに付属してるかも）。

大きすぎる見積もりになる場合は、ユーザーストーリーをより細かく見直すか、タスクブレイクダウンを実施して見積もり対象を小さくして、再度見積もりをやり直します。

優先順位付け

ストーリーポイント付与を含むユーザーストーリー設計が終了したら、ストーリーポイント（開発サイズ）を加味した優先度を付与します。

ここでは、以下の3段階で評価します。

1. 優先度：高
   • MVPとして「なくてはならない」機能
2. 優先度：中
   • MVPとして「あれば嬉しい」機能
3. 優先度：低
   • MVPとして「最悪なくても良い」機能

実装〜リリースまでの計画

ここでは開発チームができたてホヤホヤ過ぎてベロシティ（※単位期間あたりに消化できるストーリーポイント）が不明なので、理想時間ベースで計画しつつ、適切そうな係数を掛けて概算します。

単位期間について
アジャイル・スクラムな現場では、ベロシティに用いる「単位期間」のことを「イテレーション」または「スプリント」と表現します。ここではスクラムに寄せた表現を用いているので以降「スプリント」と呼ぶことにします。また、単位期間は研修の流れに合わせて1week（※実質は3-4日になる可能性）を用います。余談ですが、個人的にはガチガチのスクラムだと窮屈に感じることがあるので、本当はスクラム用語は避けたかったりするのですがｗ

具体的には以下の数式で期間（単位：日）を算出します。

• （ストーリーポイントの合計）×（4時間／1日）×（係数：0.8）
  • ストーリーポイントの合計は、優先度ごとに出します。
    • 高のみ
    • 高＋中
    • 高＋中＋低（全部）
  • 上記計算例では、1日あたり実装に使える時間を4時間としています。
    • これはプロジェクトのコンテキストによって異なります。
    • 経験的には通常6時間を用います。
    • ここでは、座学的なことも多いので2時間少ない4時間としています。
  • 係数も正直未知数ですが、経験的には0.6〜1.0の範囲を用いることが多いです。
    • ここではエイヤで0.8をセットしています。

ここではスケジュールありきなので、上記算出の結果、研修期間（1-2week）に合うように5〜7くらいの範囲に収まるよう機能を調整します。

スプリントのサイクル

スプリントにはサイクルがあります。具体的には以下のような流れで開発サイクルを回していきます。

• スプリント計画
  • このスプリントで何をやるかをこのMTGで決定します。
  • なのでスプリント初日のタイミングで行います。
• スプリントレビュー
  • このスプリントでどういう成果が出たのかをお披露目します。
    • ここではちょっとしたイベントとして行う予定。
    • 【FYI】07.開発したプロダクトの成果を発表しよう
  • ちゃんと要件に見合っているか、機能に過不足はないかなども確認します。
  • なのでスプリント最終日に行います。
• スプリントレトロスペクティブ（KPT）
  • いわゆる「振り返り」を行います。
  • KPTは、Keep, Problem, Tryの頭文字を取ったもので、スプリントでの進め方などを振り返り次のスプリントに活かせるネタを探します。
    • KPTの詳細については色々とネットに情報あると思うのでググってみてください。
  • スプリントレビュー同様、スプリント最終日に行います。

ここでは、研修計画上では2回のスプリントをサイクルとして回したいと思います（ちょっとイレギュラーなスプリントになる可能性ありますが）。

• 9/6(金)〜9/13(金)：6営業日　※前半4日を1スプリントとできれば理想
• 9/24(火)〜9/25(水)：2営業日　※↑の余り2日をあわせて4日1スプリントとできれば理想

※期間が空いてしまうので忘れる可能性もあり、その意味では週で分けた方が良いかもしれない。

関連書籍

• アジャイルな見積もりと計画づくり
• エンジニアリング組織論への招待
• SOFT SKILLS

04.開発する機能を決める実践例（IESHILの事例）

ここでは、プロダクト開発の実践例としてIESHILの事例を紹介します。

このタイミングでは、一旦は座学中心となる感じです。

タイミングを見計らって、IESHILの現場でやっている流れを会議に参加するとか、どこかで体験してもらう予定です。

また、研修の後半にIESHILでより実践的な開発の体験の場を設ける予定です。

そもそもIESHILとは？

不動産売買サービス／メディアです。

ビジネスモデルは商品は色々とあるのですが、端的にいえばSEOでサイト集客したエンドユーザーを不動産仲介業者に送客してフィーをもらう感じです。

SEOはそれなりに強くメディアパワーを持っている様子をちょっとgoogleで試してみましょう。

プロダクトの大きな方向性を決める

以下、IESHILで実際に作成されたリーンキャンバス／インセプションデッキ／ユーザーストーリー設計の事例です。

※ここは社内ドキュメントなので記述を削除しました。

プロダクトの開発現場

実は、IESHILではあまり厳格なスクラムの運用は行っていません。

より自律的な組織運営を目指しつつ、いくつかスクラムの手法を取り入れています。

• スタンドアップ
  • ディレクター／デザイナーも交えた朝会的なものを開催。
  • 毎週(月)(水)(金)11:40から開催。
  • 各日っぽい流れなのは、週3の業務委託者さんに合わせていた時の名残り。
• JIRAによるスプリント管理（2week）
  • ベロシティ計測の意味合いで緩く運用。
  • スコープは柔軟に変更することがあります。
• KPTZ
  • Zは雑談のZ。
  • 9/4(水)に体験済（の予定）。
• モブプログラミング（略称・モブプロ）
  • ペアプログラミング（ペアプロ）が2人で実装するのに対して、モブプログラミングは3人以上で行う。
  • 手を動かす人がドライバー、やいのやいの言う側がナビゲーターで役割分担して進める。
  • ひとかたまりの仕事終えたらドライバーを交代する感じ。
  • IESHILではアプリケーションチームの3人でやってます。
  • 実際に見学しても良いかもしれない。

05.プロダクト開発の技術的な側面を知ろう

ここからはRailsによるプロダクト開発において、具体的に使う技術について確認・実践します。

前提として知っておきたいことは、プロトタイプ開発時はここで言及するものをすっ飛ばすケースもあるということです。

逆に言えば、ここではチーム開発を前提としたプロダクト開発の現場で空気なくらい良く使われている技術的な側面をおさえていきます。

05.01.前提知識編

ここでは、Railsアプリケーションをチーム開発する上で必要となる前提知識を補完します。

このあたりは既に身についている気がするので、おさらいみたいなものとしてサクッと行きます。

逆にここに書いてあることのうち、もしわからないことがあったら今のうちに基礎をおさえておくのが良いと思います。

Webアプリケーションとは

• 乱暴に言えばREST分かっていればOK。
• 以下のHTMLにも通じますが、formタグの動作原理みたいなものも理解としては重要ですね。
• そもそもインターネット上の基礎知識は最低限必要。
  • HTTPリクエスト / HTTPレスポンス
  • URL / URI
    • protocol
    • host
    • domain
    • port
    • path
    • FQDN
  • IPアドレス
    • グローバル
    • プライベート
  • DNS
  • TCP / IP
  • メール送受信
  • （昨今話題の）二段階認証などセキュリティ回り

HTML / CSS（SCSS）

• 実は私も良く分かっていない(笑)
• SCSSは結構複雑なこともできるので使いこなせれば便利。
• BEM規約とかは一応考え方はおさえておいた方が良いかもしれない。
• あと、Bootstrapの最低限の使い方が分かっていれば何とかなるハズ。

Unix関連

• ディストリビューションの違いなど。
  • 細かく言えなくても良いけど。
  • パッケージ管理はディストリビューションによって違うのでそのあたりくらいは。
• 要はUnixベースのCUIコマンドの基礎が理解できていること。
  • 余談ですがwebエンジニアはMac使うことが多いですが本質的にはUnixベースであることかなと。
  • なのでWindows Subsystem for Linuxとかでもdockerなど仮想環境でも良い。
• 以下あたり。
  • pwd
  • ls
  • cd
  • mkdir
  • cp
  • touch
  • cat / less / more
  • grep
  • echo
  • history
  • ssh
  • scp
  • curl / wget
  • diff
  • gzip / zip / tarなど
  • tree ※デフォルトだと入ってない可能性
  • vi ※私の趣味が多分に入っています
  • ネットワーク系コマンドの数々
    • ping
    • nslookup
    • dig
    • traceroute
    • netstat ...etc.
• （bashなら）.bashrcとか環境変数とかの基本的な仕組みの理解。
  • 「パス通す」みたいな話がちゃんと通じること。

Git / GitHub

• コマンドが手に馴染んでいればOK。
• （私が？）よく使うコマンドは以下あたりかな。
  • git clone
  • git remote
  • git config
  • git status
  • git pull
  • git fetch
  • git merge
  • git branch
  • git checkout
  • git diff
  • git log
  • git add
  • git commit
  • git push
  • git stash
  • git reset
  • git revert
  • git rm
• そもそもよく使うやつalias切っとく（これは私の趣味）。

git alias

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.di diff
git config --global alias.br branch
git config --global alias.ci 'commit -a'
git config --global alias.ca '!git add -A && git commit'
git config --global alias.tr "log --graph --pretty='format:%C(yellow)%h%Creset %s %Cgreen(%an)%Creset %Cred%d%Creset'"

• プルリクエスト（PR）の出し方＆コードレビューの流れなどをおさえる。

Ruby

• 三大制御構造とそれに付随する書き方、一通りの文法理解があれば。
• 後置ifはRubyらしい文法。
• OOPの基礎。
• バージョンの違いによる差分をなんとなくでも知っている。
  • ここは経験積めば自ずとついてくる部分ではあります。
• ちなみにメタプログラミングはRailsアプリケーション開発で頻繁に使う場面は少ないです。
  • むしろ可読性を下げてしまったりテスタブルじゃなくなるので容量用法を守ってという感じかな。
  • RubyGemsやRails本体のソースコードにコントリビュートするなら大いに必要です。
• パーフェクトRubyを読んでおくとなお良し。

データベース

• 要はRDBMSを知っておけば。
• RailsデフォのSQLiteは実践向きではないのでMySQLまたはPostgreSQLのいずれかと向き合っておきたいところ。
• RDB共通の基礎をおさえておく必要があります。
  • 正規化
  • SQL（DDL / DML / DCL）
    • 特にDDL / DML
    • DCLもECサイトなどデータ整合性が厳密に問われる場面では必要。

参考書籍

• webを支える技術
• パーフェクトRuby
• データベース実践入門

05.02.Ruby on Rails編

既にRails経験者なので基礎的な部分は割愛します。

直近の話題はRails 6.0がリリースされたことですね。

主要機能は以下の通りです。

• Action Mailbox
• Action Text
• 並列テスト
• Action Cableのテスト支援

Rails初心者がハマるポイント

• HTML / ERB / Ruby / Railsの切り分け。
• form_withの挙動。
• render partialする時のパスの命名規則。
• migration回り。
  • rails db:resetとrails db:migrate:resetの違いわかりますか？
• Rails初期設定回り
  • これはハマるというより単に慣れていないというだけかも。
  • locale設定、i18n対応など。
• RubyGemsの選定と使い方。

Railsアプリケーションを自社開発で運用しているチームで良く語られるポイントみたいなものを列挙しておきます。

インフラどうする？

• AWS vs Heroku vs GCP
• 自前でサーバーを契約して運用するオンプレミス（オンプレ）は縮小傾向。

フロントエンドどうする？

• Rails 5.1から導入されたwebpacker（webpackをラップしたRubyGems）を使うか剥がすか。
  • ガチフロントエンド勢がいるなら剥がす方に軍配。
• JSフレームワーク何使う問題。
  • jQueryは負債化。
  • Vue.js vs React.jsのほぼ二択か。
• sprocketsも切り離す？
  • 個人的には残した方が開発スピードは早い。
• turbolinks問題。
  • 古くからオフにする習わし？がある。
  • JSで複雑なことやんないならオンのが快適感あるのは事実。
• production環境で動かない問題。
  • アセット回りちょっと注意が必要。

app配下のディレクトリ構成（設計）どうする？

• よく登場するもの。
  • decorators（helpersとの兼ね合い）
  • forms
  • validators
  • libs
  • services
• その他IESHILの事例など。

モノリシック vs マイクロサービス

• これは中規模以上にならないと議論の余地がないものですが。
• モノリシックなwebアプリケーションをサクッと開発するのにRailsは向いているというのが個人的な見解です。
• マイクロサービス化する（できるビジネス状態）なら何もRailsにこだわらなくても良いです。

テスト

• テスティングフレームワーク（Rspec vs Minitest）

  • MinitestのがXUnit系テスティングフレームワークに慣れていると分かりやすい。
  • Rspecは独特なDSL記法に慣れないといけないのでちょっと学習コストがあがる。
  • ※このあたりは私の個人所感なので他のエンジニアとも話してみて欲しいところ。

• そもそもどこまでテストを書くのか。

• 各種gemの使い方。

  • factory_bot
  • database_cleaner / database_rewinder
  • webmock

• モックやスタブを使ったテストコードの書き方。

その他

• テーブル設計
  • STI
  • 多対多
  • ポリモーフィック関連
    • 【FYI】Active Storage
  • json型など特定のRDB依存どうする

• RubyGems何入れる？

  • ActiveRecord拡張系は慎重に。
  • チーム開発においては何より合意形成が大切。

• バージョン追随どこまで？

  • Ruby
  • Rails
  • RubyGems

• capistrano

  • Herokuなら不要

• Rubocop（各種lint）

05.03.チーム開発編

ここでは、よりチーム開発にフォーカスした技術的な側面を確認します。とともに実践していく。

Git / GitHub

• チーム開発のお作法的なものをおさえる。
  • コミットログの書き方
    • fix #[issue番号]など
  • ブランチの切り方
    • issue番号を付与するケース
    • feature, hotfix, releaseなどのprefix（後述のgitflowも関連）
  • WIPとか
  • issue発行のルール
    • Issue / PR Template
    • ラベル付け
  • （場合によっては）ZenHub連携　など
    • 余談ですがリブセンスでは広くJIRAが使われているのでissue運用はあまりやってないところが多いんじゃないだろうか。
  • ブランチマージ制限的なもの
    • レビュー
    • CI
• gitflow / githubflowの違いを理解する。
• 連携
  • slack
  • Pull Panda
  • Dependabot
    • https://dependabot.com/

CI（継続的インテグレーション）

• CircleCIが広く使われている（印象）。
  • GitHubとの相性良い。
• クローズドな環境だとJenkinsとか。
• rubocopとrspecをCircleCI上で動かして結果確認。

06.チームで実装する

ここでは、チーム（今回は3人）で実装を進めるにあたり基本的にはモブプロ体制でやります。

ただしコードレビュー体験も入れたいのでその余地は残しつつ。

ちょっとしたルール的なものがあった方が捗りそうなので前提条件を予め決めておきました。

モブプロ前提条件

• ポモドーロテクニックでいうところの1ポモドーロ（25m）単位に作業を分割する。
• 基本的には分割した作業ごとにドライバーを交代する。
• 想定の範囲で終わらない場合は合間の5mに見直してドライバー継続する。
• ドライバーは基本、ナビゲーターの言うことを聞いてその通りに実装していく。
  • とはいえ提案はあり。
• 意図するように動くようになった時の掛け声決めたい。
  • 盛り上げていく感じのやつ。
• 懸念なのはエディタが違うことによる差異なんだけどまぁ何とかなるでしょう。
  • 私はvimっすｗ
  • VS codeとかが無難なのかしら？
    • 著註：実際インターン2名ともVS codeでした

モブプロの特徴

• 基本一緒に開発しているのでコードレビューが不要。
• 集中するので結構疲れる。
  • ドライバーよりナビゲーターが。
• 団結感。
• 向いている仕事とそうでないものがある。

07.開発したプロダクトの成果を発表しよう

ここでは、スプリントで開発した成果をお披露目するスプリントレビューについて、特に今回の研修に合わせた形式の認識すり合わせしておきます。

通常のスクラムにおけるスプリントレビューにあたっては、仰々しい資料などはそれほど作成したりはしません。

どういう機能なのかについて「伝われば良い」という判断基準です。

基本的には、実際に動作を見せた方がイメージが伝わりやすいので、既にリリースしたものかローカルで動いているものを見せて解説します。

ただ今回は研修ということもあるので、ちょっとだけ時間をかけて発表会っぽくできればと思っています。

が、この時点で開発が押していることも想定されるので、状況見合いで準備にかける時間は調整しましょう。

スプリントレビュー用の資料作成

• googleスライドで作成。
• 以下の項目を盛り込む。
  • 簡単な自己紹介（2名分）。
  • どんな課題を解決するプロダクトなのか。
  • プロダクトの機能紹介。
  • デモを実演（ここは動くプロダクトを見せるが理想）。
  • できればKPTも盛り込む（2名分）。
  • 最後にスプリントを終えた所感などあれば（2名分）。
• 発表は2人で行うので、役割分担を事前に決めておく。
• IESHILやその他関係者も呼んでやれたらと思います。

発表資料

Kさん

TBD

Iさん

TBD

08.1weekフリーテーマで何をやるか検討しよう

ここでは、Kさん・Iさんのいずれか1名のみなので、この1weekはフリーテーマで開発を行います。

何をやるかも含めて、私と相談の上、決めましょう。

前提条件

共通

• 1weekで区切り良さそうなサイズの課題を選定する。
• 1weekをスプリントに見立ててスプリント計画から行う。
• あえて私とのペアプロは行わず、PRベースでのコードレビューを実施する。
• レビュアーは私に加えてIESHILメンバーにも協力してもらう予定。
• 最終日にスプリントレビュー／KPTを行う。
  • スプリント計画は不要だけど「やるとしたら」前提でやっても良いかも。

Kさん

• 9/16(月)が祝日でお休みなので1日少ないことを考慮する。
• 面接時に個人プロダクト改善の話があがっていたので、その改修を行う想定。
  • 別のことやりたければそれでも。

Iさん

• この週の最後が最終日。

やること案

• 個人プロダクトの改善。
• IESHILの業務体験的なところに何かトライする。
  • テストコード改善にフォーカスするとか。
  • 機能改善系はネタが必要だが細かいものは色々とあるので検討からやるとか。
• 全く別のことにトライでも。
• （Iさんのみ）引き続きプロダクト改善の3スプリント目を行う。

09.開発したプロダクトに手を入れよう

ここでは、最初のスプリントで開発したプロダクトの2サイクル目のスプリントを実施します。

2スプリント目がちょっと前なので、スプリント計画のおさらいから。

スプリント計画

• 前回のスプリント計画のドキュメントを再度確認。
• 状況次第で調整ですが、このスプリントは短い想定なので、やることをできれば絞る。

スプリントレビュー

• 以前抱えていた課題が何かを明確にする。
• 課題がどう改善したのか明確にする。
• 実際にどういう手段で伝えるか検討する。

スプリントレトロスペクティブ

• いつものKPTを実施。
• Tryで仮想スプリント計画的なことも多少盛り込めれば。
• この研修でのプロダクト開発の最後になる可能性があるので、所感（得たもの・気づき等）もあればまとめる。

10.IESHILのプロダクト開発を体験しよう

ここでは、せっかくIESHILに配属になったことでもありますし、IESHILのwebアプリケーション開発の環境構築を行い、実際にリリースまで持っていく流れをコワーキングします。

環境構築

基本的にIESHILリポジトリのREADMEに記載してあるのでその通りにやればそれほど難しいことはないかと。

ミドルウェアはせっかくなのでdocker使ってみましょう。

このへん詰まったら IESHILメンバーがサポートしてくれるハズ。

これまでやってない技術要素でいえば以下あたりです（ざっくり）。

• docker
• elasticsearch
• heroku private spaces
  • アカウントは発行しないといけない。

IESHILのざっくりとした構成の把握

やってなければ以下を簡単に。

※ここは社内ドキュメントなので記述を削除しました。

何をやるか

できればせっかくなんでフロント回りの表示系のタスクとかやってみたいところです。リリースするまでやり切りたい。

以下あたりが候補。

• マスタデータにはあるけどフロントで表示していないものを表示する系。
• API回りのリファクタとか？
  • ちょっとリスク高いかしら…
• テストコード回りの整備とか。
  • そもそも適切なのあるかしら。
• 管理画面系タスク。
  • 現状できないことをできるようにする系のやつ。
  • 比較的やりやすいものではある。