先日のイベント「エンジニアの働き方を変える最新開発手法！〜 開発スピードを500%アップさせるクラウドソーシング徹底活用セミナー〜」で発表させてもらった資料をアップします

1. 100%失敗しない
クラウドワークスの発注方法
@hisaju01

2. 自己紹介
•ひさじゅ
•Twitter: @hisaju01
•Facebook: hisaju
•株式会社ポケットメニューCTO

4. アジェンダ
•私とクラウドワークス
•間違いだらけのクラウドソーシング
•100%失敗しないクラウドワークス発注
方法

5. 「私とクラウドワークス」

6. 自己紹介を兼ねて
クラウドワークスを
使い始めた経緯

7. 某アドテク企業にいた頃
クラウドソーシングのプラットフォームを!
作ったので使ってください！
(面白そうだけど、アドテクの!
発注は難しいな。。）

8. 1年くらい経って

9. 退職してフリーランスに

10. スタートアップを対象とした
週１のCTO
(何でも屋さん)

11. エンジニアがいるところは
足りない部分を補完
(ほとんどインフラ)

12. エンジニアがいないところは
受託形式で

13. ピーク時に
週１が4社と受託2社

15. 手が足りない！

16. 人を雇うには
お金も時間もない！

17. 瑕疵対応をやめて、時給でやるのが一番ですよ

18. 時給なら払えるところまでで
止められるからいけるかも！？

19. 募集開始

20. その後、
ポケットメニュー入社後も
手が足りなかったので
開発をお願いしてました

21. 「間違いだらけのクラウドソーシング」

22. 発注をはじめるに当って
他社の募集ページを色々
見てみた感想

24. 受託をやっていた
身からすると
クラウドソーシングは
問題が多いと感じた

25. 受注側エンジニアからみた
ダメな発注事例
•タスクが明確でない
•単価が安すぎる
•単価が高くても一人で出来るボリューム
じゃない
•納期は決まってる

26. 個人で受けるには
リスクと責任が大きすぎる

27. 仮に受注した場合どうなるか

28. そうだ 京都、行こう。

29. 受託と比較した場合のク
ラウドソーシングの問題点
•PM、ディレクション不在
•責任の所在があいまい
•理想と現実にギャップが多い
•発注側の明らかなスキル不足

30. 受託と
クラウドソーシングは別物

31. 「100%失敗しない
クラウドワークスの発注」

32. 色々踏まえて考えてみた

33. 元気玉のイメージで
発注出来ないかな

34. 既存のSIモデルではなく
クラウドソーシングの
特性を活かした
発注側も受注側もハッピーに
なれる仕事のやり方を考えよう

35. その前に

36. ※ 前提として
PMは必須です

37. 受けやすい仕事パターン
•いつでも (時間の制約がない)
•どこでも（非対面）
•責任・リスクがない
•単価が安すぎない
これなら正社員の副業や学生、
フリーランスの 間時間でも出来る！！

38. 受けやすいように
仕事の方法をワークシフト
•いつでも
•基本的には納期は切らないようにして、多数の人が自由な時間に
仕事が出来る環境を作ろう
•どこでも
•こちらで設計まで行って、コミュニケーション量を減らした上で、
細かい部分はチャットのみで完全非対面にしよう
•責任・リスクがない
•単価が安すぎない
•時給制なら瑕疵対応も見積もりもなくて、責任・リスクも減るか
ら、高額じゃなくてもお互い納得しやすいかな

39. これってオープンソースの
開発方法でいけるかな？

40. 前段の条件で仕事を
進める上での懸念点
•いっぱい人が集まらないと難しいかな
•コード(エンジニア)のクオリティって担保
できるかな
•人によってバラつきがでない？
•いっぱい人を集めたら全員管理するの大
変じゃないかな

41. WAF選定で
リスクを減らす
•なるべく書き方にバラつきを持たせない
•フルスタックWAFであれば、似たような書
き方に落ち着くと思われ
•ライブラリが豊富
•やっている人が多そうなWAFじゃないと人が
集まらないかな

42. オレオレマトリクス
フルスタックWAF編
人口多い
クオリティ平均
高い
クオリティ平均
低い
人口少ない

43. Railsで決定！

44. それらをまとめた結果として
考えたのが

45. 空いた時間で好きな時間だけ出来る
Ruby On Railsを使用した開発

46. 「A successful Git branching model 」
をベースに
1.issue
5.test、merge
2.assign
4.pull request
3.branch

47. 経験からのポイント

48. 1.募集をする時に
ハードルを下げない

49. このPJに参加出来る条件
•Ruby On Rails経験者
•github、git flowが使える人
これだけで、
ある程度足切りが出来るので
クオリティが高いレベルで均一化される

50. それでも
いっぱい集まりました
募集要項、仕事の進め方が明確なら
ハードルを上げても人は集まります

51. 2.タスクは小さく分かりやすく

52. タスクを小さく
分かりやすくする理由
• 間時間で出来るようにする
•なるべく数時間以内で終わる大きさに切る
•途中でいなくなっても痛くないように
•仕様のキャッチアップに時間がかかるので、仕様を
理解しなくても出来るように
•テーブル定義や、どこに何をを明確に書いておく
•最初は面倒だけど、慣れてくるとゆるく指示しても
伝わるようになるので、最初はなるべく細かく！

53. サンプル

54. 3.やっぱりRailsでよかった！

55. Railsでよかった！
•Bundlerやマイグレーション、seedsなどセッ
トアップの自動化ツールが整備されているの
で、初期セットアップまでの準備が早い
•コードのクオリティにそこまでブレがない
•gemがかなり豊富なので、余計な工数も少な
くてすむ
•詳しい人が多いので、勉強させてもらってま
す！

56. 一応厳しい点も。。
•納期をコミットする場合は、ある程度自分で
やることも
•予算がほぼ確実に前後します
•テストの仕組みを入れずに走ってしまったの
で、不具合を見逃してリリースしてしまうこ
とも(現在受け入れテストの仕組み導入中)
•稼働のほとんどが夜か休日なので、携帯での
チャットワークの返信が大変。。

57. まとめ
•発注する前に受注する側の気持ちになって考
えよう
•その際のリスクは極限まで下げるように仕組
みを作ろう
•WAF選定はなるべくメジャーなものを使った
ほうが後々楽
•このスタイルの発注者が増えてきたら、みん
ながもっと自由な働き方が出来ると思います！

58. その後

59. ポケットコンシェルジュで
サービスの立ち上げ期にも
活躍してもらいました

60. ですが

61. クラウドワークスでの
発注を終了しました

62. 理由

63. 開発早すぎ。。

64. ディレクションが
追いつかない。。

65. スタートアップの場合

66. 立ち上げ期や
開発が集中している
タイミングで使うと
効果的

67. フロントエンジニア募集！
クラウドソーシングを使った
フロント開発方法を
作ってみたい方お待ちしています！
(一度私がやって失敗したので。。)
!
ポケットメニュー菊本までご連絡ください！

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