受託開発とサービス開発を
同じメンバが担うことへの挑戦

2014/01/24
ヴェルク田向祐介
自己紹介
 田向祐介(@fw_tx76129)
 ヴェルク株式会社

 ITコンサル→ベンチャー→起業
 スマホアプリ開発・クラウド・Webシス
テム開発など
受託開発がテーマなので
まずは、受託開発への思い
受託開発は、異なる分野の顧客と仕
事をすることによって、自分たちだ
けでは作り出せないものを作り出す
ことができる、本来は新しい可能性
があって魅力的なもののはず。
でも現実はそうなっていないことが
多く、それを何とかしたい。
受託開発の成功に必要なもの
• 高い技術力?
• 最新の開発手法?
お金をもらってプロとして
仕事をしているので
技術力や開発手法など
専門知識は当たり前

高い技術力を持っていても
最新の開発手法を導入しても
炎上するものはする
持っている知識・スキルを
結果に結びつける力が必要
それってなに?
まずはこういう考えに至った
経緯と背景から
開発だけをやっていた学生時代

• ベンチャーでインターン&その後大学に行
きながら開発の仕事
• 顧客折衝・要件定義・そもそもプロジェク
トの目的など、ほとんど知らなかった
強烈なデスマを体験した新人時代
• プロジェクトが崩壊・炎上する様を目の当た
りにする
• お客さんとの間に立って調整し、プロジェク
トの立て直しに取り組む
• この経験で、開発だけを考えていた学生時代
の感覚から抜けてプロマネを真剣に考えるよ...
なぜ炎上したのか
きちんと技術力があるメンバーがいて
要件定義を進める専門のメンバーもいて
PMがしっかりと進捗を管理して

でもうまくいかなかった
真逆だった次のプロジェクト
• 尐数精鋭チームで、一人ひとりが自立し
て動く
• プロジェクトリーダーは普段は何もして
いないように見えて、いざという時に抑
えるべきポイントを抑える

• 最小のマネジメントコストで、極めて高
いアウトプット
この2つの大きく異る経験か
ら、プロジェクトの成否を分
ける要因として、技術力・開
発手法よりも、「人」に強く
注目していくことになる
受託開発において
大事にしているポイント
•
•
•
•
•

チームで開発する意識
リスク感覚の一致
問題解決のへアプローチ
モチベーション維持
Noと言える勇気

大前提として、必要なレベルの技術力な
どは持っていること
チームで開発する意識

• 自分の仕事の範囲に閉じない
• エンジニアでも、ビジネス的な要素を考える
リスク感覚の一致

• 報連相のタイミングと質が大事。
• 自力で頑張るところと相談するところの判
断。これが一致しているチームは強い。
問題解決へのアプローチ

• どれだけ技術力があっても、最新の開発手
法を導入しても課題は発生する
• 問題解決のアプローチが身についている
と、炎上する前にしっかり潰せる
モチベーション維持
本来は個人の問題ではあるけど

モチベーションの低下を招かない
仕事の割り振り方には気を使うべき
Noと言える勇気
• チーム内で、上司へ、顧
客へ
• 間違ったことや無理の積
み重ねが炎上へと繋がる
• ただし杓子定規ではない
これらを実践の中で
経験して身につけていくための

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

成長のための題材と...
受託開発と自社開発で
身につくスキルは異なる
受託開発
<成長する点>
• 顧客からの厳しい要求に対応するためスキルの向上
• 自分たちだけではできない分野に携わることによって
幅が広がる
<課題>
• 受け身な姿勢になりがち
• 作ることが目的になってしまう
• エンジニアにとってモチベ...
自社開発
<成長する点>
• 開発だけでなく、事業性・マーケティングまで考える
ことで、プロジェクトを俯瞰できるようになる
• 自力でサービスを成功させないといけないので、主
体的に考えるようになり、リスク感覚・チームで仕事
をする力など、受託...
受託開発で身につけたスキ
ル・知識を自社開発へ
自社開発で身につけた総合
力を受託開発へ
ただし
バランスが非常に難しい
1年目の失敗
• エンジニア2人を自社開発メインに
• とは言え、小さいスタートアップで資金
に余裕があるわけではないので、「その
分、僕が頑張って稼ぐ」というモデル
• スタートアップの会社で、売上に貢献で
きていない状況がやりにくかったらし...
2年目のスタンス
• 受託開発を軸に
• 自社開発の優先度が下がり後回しになり、
自社開発の割合が小さくなってしまった。
その結果思い切ったことができない。
3年目の成果
今まで一番バランスが取れた1年
受託メイン
のメンバ

給与
分は
受託
で稼
ぐ

自社メイン
のメンバ
2割で自分の得意な分野で支援

受託:自社 = 8:2

その結果生まれたものが→

受託:自社 = 3:7
バランスを取るポイント
• 自社開発メンバでも自分の給与分くらいは
稼ぐことで、受託メインのメンバーに迷惑
をかけない
• 受託・自社の割合の公平性を追い求めない

• 自社開発をとにかくスモールスタートで
• 両立のために求められていることは...
受託開発と自社開発の
両方の経験を積むことで
総合力がアップして
スキルを結果に
結び付けられるよう
になってくる
結果的に好循環が生まれる
炎上しない受託開発
↓
いい仕事が回ってくる
↓
挑戦しがいのある仕事
↓
さらなるスキルアップ
この取り組むの難しさ
•

性質の違うことを次から次へと考える必
要がある。コード書いた直後にプロモー
ションのことを考えるなど。

•

個々人の特徴を踏まえて、リーダーがバ
ランスを考えたアサインが不可欠
その結果・・・
• 受託開発のデリバリー力が格段に向上。最
近は、自分が入らず他のメンバだけで安定
して回っている
• 自社開発で、僕が主導しなくても進む。僕
が出した案が余裕で却下される・・・。
各メンバの総合力の向上によりマネジメント
コス...
これからの課題
• メンバーが増えた時に同じことができる
か
• 自分以外のメンバが、新しく入ってきた
メンバに同じことができないといけない
エンジニア絶賛募集中!

新オフィスの内装をDIYしています
ご静聴ありがとうございました

enjoy life and creation
受託開発とサービス開発を同じメンバーが担うことへの挑戦
Upcoming SlideShare
Loading in...5
×

受託開発とサービス開発を同じメンバーが担うことへの挑戦

14,366

Published on

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

Published in: Technology
0 Comments
73 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
14,366
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
71
Comments
0
Likes
73
Embeds 0
No embeds

No notes for slide

受託開発とサービス開発を同じメンバーが担うことへの挑戦

  1. 1. 受託開発とサービス開発を 同じメンバが担うことへの挑戦 2014/01/24 ヴェルク田向祐介
  2. 2. 自己紹介  田向祐介(@fw_tx76129)  ヴェルク株式会社  ITコンサル→ベンチャー→起業  スマホアプリ開発・クラウド・Webシス テム開発など
  3. 3. 受託開発がテーマなので まずは、受託開発への思い
  4. 4. 受託開発は、異なる分野の顧客と仕 事をすることによって、自分たちだ けでは作り出せないものを作り出す ことができる、本来は新しい可能性 があって魅力的なもののはず。 でも現実はそうなっていないことが 多く、それを何とかしたい。
  5. 5. 受託開発の成功に必要なもの • 高い技術力? • 最新の開発手法?
  6. 6. お金をもらってプロとして 仕事をしているので 技術力や開発手法など 専門知識は当たり前 高い技術力を持っていても 最新の開発手法を導入しても 炎上するものはする
  7. 7. 持っている知識・スキルを 結果に結びつける力が必要
  8. 8. それってなに?
  9. 9. まずはこういう考えに至った 経緯と背景から
  10. 10. 開発だけをやっていた学生時代 • ベンチャーでインターン&その後大学に行 きながら開発の仕事 • 顧客折衝・要件定義・そもそもプロジェク トの目的など、ほとんど知らなかった
  11. 11. 強烈なデスマを体験した新人時代 • プロジェクトが崩壊・炎上する様を目の当た りにする • お客さんとの間に立って調整し、プロジェク トの立て直しに取り組む • この経験で、開発だけを考えていた学生時代 の感覚から抜けてプロマネを真剣に考えるよ うになる
  12. 12. なぜ炎上したのか きちんと技術力があるメンバーがいて 要件定義を進める専門のメンバーもいて PMがしっかりと進捗を管理して でもうまくいかなかった
  13. 13. 真逆だった次のプロジェクト • 尐数精鋭チームで、一人ひとりが自立し て動く • プロジェクトリーダーは普段は何もして いないように見えて、いざという時に抑 えるべきポイントを抑える • 最小のマネジメントコストで、極めて高 いアウトプット
  14. 14. この2つの大きく異る経験か ら、プロジェクトの成否を分 ける要因として、技術力・開 発手法よりも、「人」に強く 注目していくことになる
  15. 15. 受託開発において 大事にしているポイント • • • • • チームで開発する意識 リスク感覚の一致 問題解決のへアプローチ モチベーション維持 Noと言える勇気 大前提として、必要なレベルの技術力な どは持っていること
  16. 16. チームで開発する意識 • 自分の仕事の範囲に閉じない • エンジニアでも、ビジネス的な要素を考える
  17. 17. リスク感覚の一致 • 報連相のタイミングと質が大事。 • 自力で頑張るところと相談するところの判 断。これが一致しているチームは強い。
  18. 18. 問題解決へのアプローチ • どれだけ技術力があっても、最新の開発手 法を導入しても課題は発生する • 問題解決のアプローチが身についている と、炎上する前にしっかり潰せる
  19. 19. モチベーション維持 本来は個人の問題ではあるけど モチベーションの低下を招かない 仕事の割り振り方には気を使うべき
  20. 20. Noと言える勇気 • チーム内で、上司へ、顧 客へ • 間違ったことや無理の積 み重ねが炎上へと繋がる • ただし杓子定規ではない
  21. 21. これらを実践の中で 経験して身につけていくための 機会を作っていく
  22. 22. 今、取り組んでいること • 「技術力や開発手法などではなく、仕事をする 力を向上させることが必要」というコンセプト で、受託開発・自社開発の両方をやることで、 総合的に力をアップ • もちろんメンバーによって割合の差はある 成長のための題材として 両方を経験することが大事
  23. 23. 受託開発と自社開発で 身につくスキルは異なる
  24. 24. 受託開発 <成長する点> • 顧客からの厳しい要求に対応するためスキルの向上 • 自分たちだけではできない分野に携わることによって 幅が広がる <課題> • 受け身な姿勢になりがち • 作ることが目的になってしまう • エンジニアにとってモチベーション維持が難しい 個人的には自社開発よりも受託開発の方が スキルは成長すると考えている
  25. 25. 自社開発 <成長する点> • 開発だけでなく、事業性・マーケティングまで考える ことで、プロジェクトを俯瞰できるようになる • 自力でサービスを成功させないといけないので、主 体的に考えるようになり、リスク感覚・チームで仕事 をする力など、受託開発に比べて格段に成長 • 高いモチベーションが維持できる <課題> • 身内・自分に甘くなりがち • スキル・経験の幅が狭くなってしまう
  26. 26. 受託開発で身につけたスキ ル・知識を自社開発へ 自社開発で身につけた総合 力を受託開発へ
  27. 27. ただし バランスが非常に難しい
  28. 28. 1年目の失敗 • エンジニア2人を自社開発メインに • とは言え、小さいスタートアップで資金 に余裕があるわけではないので、「その 分、僕が頑張って稼ぐ」というモデル • スタートアップの会社で、売上に貢献で きていない状況がやりにくかったらしい
  29. 29. 2年目のスタンス • 受託開発を軸に • 自社開発の優先度が下がり後回しになり、 自社開発の割合が小さくなってしまった。 その結果思い切ったことができない。
  30. 30. 3年目の成果 今まで一番バランスが取れた1年 受託メイン のメンバ 給与 分は 受託 で稼 ぐ 自社メイン のメンバ 2割で自分の得意な分野で支援 受託:自社 = 8:2 その結果生まれたものが→ 受託:自社 = 3:7
  31. 31. バランスを取るポイント • 自社開発メンバでも自分の給与分くらいは 稼ぐことで、受託メインのメンバーに迷惑 をかけない • 受託・自社の割合の公平性を追い求めない • 自社開発をとにかくスモールスタートで • 両立のために求められていることは多いの で、溢れないためのコントロール →現時点ではかなり自分のさじ加減
  32. 32. 受託開発と自社開発の 両方の経験を積むことで 総合力がアップして スキルを結果に 結び付けられるよう になってくる
  33. 33. 結果的に好循環が生まれる 炎上しない受託開発 ↓ いい仕事が回ってくる ↓ 挑戦しがいのある仕事 ↓ さらなるスキルアップ
  34. 34. この取り組むの難しさ • 性質の違うことを次から次へと考える必 要がある。コード書いた直後にプロモー ションのことを考えるなど。 • 個々人の特徴を踏まえて、リーダーがバ ランスを考えたアサインが不可欠
  35. 35. その結果・・・ • 受託開発のデリバリー力が格段に向上。最 近は、自分が入らず他のメンバだけで安定 して回っている • 自社開発で、僕が主導しなくても進む。僕 が出した案が余裕で却下される・・・。 各メンバの総合力の向上によりマネジメント コストが低下 →より簡単に安定して進められるようになる →損益分岐点が下がることでより自社開発を やりやすくなる
  36. 36. これからの課題 • メンバーが増えた時に同じことができる か • 自分以外のメンバが、新しく入ってきた メンバに同じことができないといけない
  37. 37. エンジニア絶賛募集中! 新オフィスの内装をDIYしています
  38. 38. ご静聴ありがとうございました enjoy life and creation
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×