DevLOVE「越境する受託開発 〜サービス開発と受託開発の境界を、越えて〜」の発表資料

1. 受託開発とサービス開発を
同じメンバが担うことへの挑戦
2014/01/２４
ヴェルク田向祐介

2. 自己紹介
 田向祐介（@fw_tx76129）
 ヴェルク株式会社
 ITコンサル→ベンチャー→起業
 スマホアプリ開発・クラウド・Webシス
テム開発など

3. 受託開発がテーマなので
まずは、受託開発への思い

4. 受託開発は、異なる分野の顧客と仕
事をすることによって、自分たちだ
けでは作り出せないものを作り出す
ことができる、本来は新しい可能性
があって魅力的なもののはず。
でも現実はそうなっていないことが
多く、それを何とかしたい。

5. 受託開発の成功に必要なもの
• 高い技術力？
• 最新の開発手法？

6. お金をもらってプロとして
仕事をしているので
技術力や開発手法など
専門知識は当たり前
高い技術力を持っていても
最新の開発手法を導入しても
炎上するものはする

7. 持っている知識・スキルを
結果に結びつける力が必要

8. それってなに？

9. まずはこういう考えに至った
経緯と背景から

10. 開発だけをやっていた学生時代
• ベンチャーでインターン＆その後大学に行
きながら開発の仕事
• 顧客折衝・要件定義・そもそもプロジェク
トの目的など、ほとんど知らなかった

11. 強烈なデスマを体験した新人時代
• プロジェクトが崩壊・炎上する様を目の当た
りにする
• お客さんとの間に立って調整し、プロジェク
トの立て直しに取り組む
• この経験で、開発だけを考えていた学生時代
の感覚から抜けてプロマネを真剣に考えるよ
うになる

13. なぜ炎上したのか
きちんと技術力があるメンバーがいて
要件定義を進める専門のメンバーもいて
PMがしっかりと進捗を管理して
でもうまくいかなかった

14. 真逆だった次のプロジェクト
• 尐数精鋭チームで、一人ひとりが自立し
て動く
• プロジェクトリーダーは普段は何もして
いないように見えて、いざという時に抑
えるべきポイントを抑える
• 最小のマネジメントコストで、極めて高
いアウトプット

15. この2つの大きく異る経験か
ら、プロジェクトの成否を分
ける要因として、技術力・開
発手法よりも、「人」に強く
注目していくことになる

16. 受託開発において
大事にしているポイント
•
•
•
•
•
チームで開発する意識
リスク感覚の一致
問題解決のへアプローチ
モチベーション維持
Noと言える勇気
大前提として、必要なレベルの技術力な
どは持っていること

17. チームで開発する意識
• 自分の仕事の範囲に閉じない
• エンジニアでも、ビジネス的な要素を考える

18. リスク感覚の一致
• 報連相のタイミングと質が大事。
• 自力で頑張るところと相談するところの判
断。これが一致しているチームは強い。

19. 問題解決へのアプローチ
• どれだけ技術力があっても、最新の開発手
法を導入しても課題は発生する
• 問題解決のアプローチが身についている
と、炎上する前にしっかり潰せる

20. モチベーション維持
本来は個人の問題ではあるけど
モチベーションの低下を招かない
仕事の割り振り方には気を使うべき

21. Noと言える勇気
• チーム内で、上司へ、顧
客へ
• 間違ったことや無理の積
み重ねが炎上へと繋がる
• ただし杓子定規ではない

22. これらを実践の中で
経験して身につけていくための
機会を作っていく

23. 今、取り組んでいること
• 「技術力や開発手法などではなく、仕事をする
力を向上させることが必要」というコンセプト
で、受託開発・自社開発の両方をやることで、
総合的に力をアップ
• もちろんメンバーによって割合の差はある
成長のための題材として
両方を経験することが大事

24. 受託開発と自社開発で
身につくスキルは異なる

25. 受託開発
＜成長する点＞
• 顧客からの厳しい要求に対応するためスキルの向上
• 自分たちだけではできない分野に携わることによって
幅が広がる
＜課題＞
• 受け身な姿勢になりがち
• 作ることが目的になってしまう
• エンジニアにとってモチベーション維持が難しい
個人的には自社開発よりも受託開発の方が
スキルは成長すると考えている

26. 自社開発
＜成長する点＞
• 開発だけでなく、事業性・マーケティングまで考える
ことで、プロジェクトを俯瞰できるようになる
• 自力でサービスを成功させないといけないので、主
体的に考えるようになり、リスク感覚・チームで仕事
をする力など、受託開発に比べて格段に成長
• 高いモチベーションが維持できる
＜課題＞
• 身内・自分に甘くなりがち
• スキル・経験の幅が狭くなってしまう

27. 受託開発で身につけたスキ
ル・知識を自社開発へ
自社開発で身につけた総合
力を受託開発へ

28. ただし
バランスが非常に難しい

29. 1年目の失敗
• エンジニア2人を自社開発メインに
• とは言え、小さいスタートアップで資金
に余裕があるわけではないので、「その
分、僕が頑張って稼ぐ」というモデル
• スタートアップの会社で、売上に貢献で
きていない状況がやりにくかったらしい

30. 2年目のスタンス
• 受託開発を軸に
• 自社開発の優先度が下がり後回しになり、
自社開発の割合が小さくなってしまった。
その結果思い切ったことができない。

31. 3年目の成果
今まで一番バランスが取れた1年
受託メイン
のメンバ
給与
分は
受託
で稼
ぐ
自社メイン
のメンバ
2割で自分の得意な分野で支援
受託:自社 = 8:2
その結果生まれたものが→
受託:自社 = 3:7

32. バランスを取るポイント
• 自社開発メンバでも自分の給与分くらいは
稼ぐことで、受託メインのメンバーに迷惑
をかけない
• 受託・自社の割合の公平性を追い求めない
• 自社開発をとにかくスモールスタートで
• 両立のために求められていることは多いの
で、溢れないためのコントロール
→現時点ではかなり自分のさじ加減

33. 受託開発と自社開発の
両方の経験を積むことで
総合力がアップして
スキルを結果に
結び付けられるよう
になってくる

34. 結果的に好循環が生まれる
炎上しない受託開発
↓
いい仕事が回ってくる
↓
挑戦しがいのある仕事
↓
さらなるスキルアップ

35. この取り組むの難しさ
•
性質の違うことを次から次へと考える必
要がある。コード書いた直後にプロモー
ションのことを考えるなど。
•
個々人の特徴を踏まえて、リーダーがバ
ランスを考えたアサインが不可欠

36. その結果・・・
• 受託開発のデリバリー力が格段に向上。最
近は、自分が入らず他のメンバだけで安定
して回っている
• 自社開発で、僕が主導しなくても進む。僕
が出した案が余裕で却下される・・・。
各メンバの総合力の向上によりマネジメント
コストが低下
→より簡単に安定して進められるようになる
→損益分岐点が下がることでより自社開発を
やりやすくなる

37. これからの課題
• メンバーが増えた時に同じことができる
か
• 自分以外のメンバが、新しく入ってきた
メンバに同じことができないといけない

38. エンジニア絶賛募集中！
新オフィスの内装をDIYしています

39. ご静聴ありがとうございました
enjoy life and creation