チーム開発の際のISSUEの作り方イベントで発表したものに少し捕捉をいれたりしました。 クラウドソーシングで不特定多数の人がプロジェクトに参加する方法でのISSUEの作り方を考えてやってます

1. クラウドソーシングな
ISSUEの作り方
hisaju

2. $ git issue add

3. ありがとうございました

4. ではなくて

5. 自己紹介
サラリーマンでアドテクやったり、フリーランスでス
タートアップ手伝ってみたり、スタートアップ入ってみ
てCTOやったり、起業してみたり
• 菊本 久寿（きくもと ひさとし）
• 株式会社StartupTechnology代表取締役
• Twitter: hisaju01
• Facebook: https://www.facebook.com/hisaju
• http://hisaju.org

6. クラウドソーシングを使うようになった経緯
フリーランスで案件燃えたか
ら、git flow、pull request開発
でクラウドワークス出したら
人がいっぱい集まったよ！

7. クラウドソーシングを使うようになった経緯
その流れでクラウドワークス
さんに事例で取り上げられた
り、イベント一緒にやらせて
もらったよ！

8. クラウドソーシングを使うようになった経緯
StartupLabo
結果そのやり方が出来るクラ
ウドソーシングを自分で
作ったよ！

9. StartupLaboを利用した開発工程
クラウドマネージャー github
クラウドエンジニア
issue登録
同期
好きなissueをアサイン
pull request
レビュー
マージ

10. 社内エンジニアと違うクラウドソーシング
社内エンジニア クラウドワーカー
使える言語、WAF
スキル
仕様の把握
稼働時間、場所
使える言語、WAF
責任
？
前提条件が
全く違う

11. クラウドソーシングの使い方はイメージを変える
こうじゃなくて

12. クラウドソーシングの使い方はイメージを変える
こう

13. では具体的に説明します

14. 先ほどの前提条件を考慮

15. 前提条件整理
• スキルが把握出来ない
– 難しいものは振らない
• 場所も時間も合わない
– コミュニケーション量を抑える
• 稼働が読めない、責任も持たせられない
– 大きく振らない
• 仕様を把握していない
– 唯一の共通コンテクスト(Railsのルール)だけで分かるよ
うに
– 細かく記載

16. 前提条件整理
• スキルが把握出来ない
– 難しいものは振らない
• 場所も時間も合わない
– コミュニケーション量を抑える
• 稼働が読めない、責任も持たせられない
– 大きく振らない
• 仕様を把握していない
– 唯一の共通コンテクスト(Railsのルール)だけで分かるよ
うに
– 細かく記載

17. 難しくしない
Scaffold
(rails-admin-
scaffold)
ActiveAdmin
slimerb
AngularJSJQuery
エンジニア的な欲求を捨てて
初級者でも使えるものを選択

18. 前提条件整理
• スキルが把握出来ない
– 難しいものは振らない
• 場所も時間も合わない
– コミュニケーション量を抑える
• 稼働が読めない、責任も持たせられない
– 大きく振らない
• 仕様を把握していない
– 唯一の共通コンテクスト(Railsのルール)だけで分かるよ
うに
– 細かく記載

19. コミュニケーションコストを抑える
scaffold
view
Logic Design
伝えやすいもの 伝えづらいもの
そもそも振る作業をこちらに寄せる

20. 前提条件整理
• スキルが把握出来ない
– 難しいものは振らない
• 場所も時間も合わない
– コミュニケーション量を抑える
• 稼働が読めない、責任も持たせられない
– 大きく振らない
• 仕様を把握していない
– 唯一の共通コンテクスト(Railsのルール)だけで分かるよ
うに
– 細かく記載

21. 大きく振らない
小さく振ったほうがダメージが少ない

22. 前提条件整理
• スキルが把握出来ない
– 難しいものは振らない
• 場所も時間も合わない
– コミュニケーション量を抑える
• 稼働が読めない、責任も持たせられない
– 大きく振らない
• 仕様を把握していない
– 唯一の共通コンテクスト(Railsのルール)だけで分かるよ
うに
– 細かく記載

23. Railsルールに合わせた細かいISSUEの書き方
• scaffoldをベースに管理画面など
– rails-admin-scaffoldのテンプレートを作っておく
と更に楽
– READMEにscaffoldの書き方を記載
• バリデーションはテーブル定義から読める
• 実際にプログラムを書くように説明する

24. ISSUEの例
• 概要
– 管理画面メニュークーポン＞クーポン管理からリンクするクーポン
(coupons)の一覧、詳細、追加、編集、削除の実装をお願いします。
• テーブル定義
– https://docs.google.com/a/xxxxxxxxxxxxxxxxxxxxx
• 詳細
– クーポンの一覧、詳細、追加、編集、削除の実装をお願いします。
– フォーム
• バリデーションはテーブル定義やテーブル定義の備考を参考に設定してください。
• カテゴリはselectボックスでお願いします。
• カテゴリが2の場合のみプランのセレクトボックスが表示されるようにお願いします。
• 一覧表示項目
– ID
– カテゴリ
– クーポン名
【管理画面】クーポン管理

25. 裏技
Rspec形式で仕様を補足する
describe "/courses/1にアクセス"
context “このページのパス名をキーにしたCookieが存在しない場合” do
it "新規訪問とみなしてページビューをカウントアップする" do
end
it "このページのパス名をキーにしたCookieを設定出来る" do
end
end
context "このページのパス名をキーにしたCookieが存在する場合” do
it "すでに訪問済のためページビューはカウントアップされない" do
end
end
context "（Timecop使って）Cookie設定後12時間経過した場合” do
it "設定したCookieがリセットされてる" do
end
it "ページビューがカウントアップされる" do
end
end
end

26. まとめ
• StartupLaboのやり方は、気軽にプロジェク
トに参加出来るようにするために、あえてコ
ンテクストの把握を捨てている為このような
やり方になっていますが、みなさんのチーム
では何が必要で何が必要でないかを取捨選択
し、それに合わせたISSUEの作り方をそれぞ
れ考えてみてください

27. ありがとうございました