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

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

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