最近、スマホ部門の新規プロジェクトを見ていて感じる事があったのでエントリーします。
（極端な表現をしている部分もありますが、社内向けとしてご理解ください）
スマホ部門の中途入社エンジニアには、前職に受託開発を行なっていた方が多くいます。
私が思う受託開発の特徴は、
・発注元が神、彼らの意見がすべて（＝決裁権がない）
・仕様が決まらないと開発が始まらない、仕様変更は悪（＝予め決まったものを作る）
と考えています。
受託開発に窮屈さを感じ、当社に転職をしてきたエンジニアが多いと思います。
実際に彼らの仕事ぶりを見ると、
高いモチベーションで、ヒットサービスを産み出すためにがむしゃらに頑張ってくれています。
ですが、最近いくつかのプロジェクトでなかなかアウトプットが出ない、
また、プロジェクトの進捗にスピード感を感じないプロジェクトを見かけるようになりました。
そのプロジェクトの状況をヒアリングしてみると、
この原因を掘り下げていくと、若手プロデューサーの力量不足があげられますが、
加えて、「受託開発のジレンマ」と格闘するエンジニアの存在もあげられます。
受託開発の特徴として、「決裁権がない」・「予め決まったものを作る」の2点をあげましたが、
ネットサービスの開発の特徴は、「自分で決断する」・「自らで考えたものを作る」と正反対のものです。
サービスコンセプトや事業上のゴールを明確にした上で、
自分たちが作るサービスをどのように利用してもらいたいのか？
自分たちが作るサービスが流行っているイメージ（成功イメージ）を膨らました上で、
その為に、どういった画面遷移やユーザーフロー、また、機能を詰めていきます。
何より、自分たちの決断に明確な答えがない状態で、
１つ１つ仕様を決断しサービスを作っていかなればなりません。
（受託開発であれば、発注元が決断をしてくれるから楽）
ここに受託開発のジレンマが潜んでいると思います。
どれだけ高い技術力を持ち、主体的にプロジェクトをリードしてきたエンジニアでも
知らず知らずのうちに、受託開発（決裁権を持たず、予め決められたものを作る事）に慣れてしまうと
頭で分かっていても、具体的な方法論を導き出すことに苦労してしまいます。
また、環境が変わり、一日でも早く成果を出したいと思うエンジニアであればあるほど、
自分の得意とするやり方に固執してしまう傾向があります。
ですが、受託開発とネットサービスの開発は、極めて異質なものであり、
その進め方においてはがらりと頭を切り替えて、モノづくりをしなければなりません。
ネットサービスの開発で、アジャイル開発を用いるプロジェクトが多くいます。
アジャイル開発の利点は、リスクの先出しだと考えています。
だからこそ、ネットサービスの開発でアジャイル開発を用いるケースが多いのだと思います。
ですので、極端な表現ではありますが、
考える過ぎるな、まず、作れ！
が受託開発のジレンマを打破するために大切な事だと思います。
（こんな表現をすると当社のエンジニアから文句を言われそうですが
）
ネットサービスは一定のクオリティでリリースすることができれば、
改善を積み重ねて行くことで、更にサービスの完成度を高めることができます。
また、スマートフォンは、誰よりも早くサービスを提供することが重要な市場です。
だからこそ、過度に考えず、まずは動くものを作り、
そのアウトプットをネガティブチェックをし、完成度を高めていくしかありません。
受託開発のジレンマに心当たりのある方は、
今のプロジェクトの開発の進め方を見つめるところから始めましょう。
昨晩は、スマホ部門の中途入社エンジニアとの懇親会でした。
入社した彼らの情熱、志を聞くことこちらまで熱くなりました。
一緒にスマホユーザーの心をがっちりと掴むサービスを作りましょう！
（極端な表現をしている部分もありますが、社内向けとしてご理解ください）
スマホ部門の中途入社エンジニアには、前職に受託開発を行なっていた方が多くいます。
私が思う受託開発の特徴は、
・発注元が神、彼らの意見がすべて（＝決裁権がない）
・仕様が決まらないと開発が始まらない、仕様変更は悪（＝予め決まったものを作る）
と考えています。
受託開発に窮屈さを感じ、当社に転職をしてきたエンジニアが多いと思います。
実際に彼らの仕事ぶりを見ると、
高いモチベーションで、ヒットサービスを産み出すためにがむしゃらに頑張ってくれています。
ですが、最近いくつかのプロジェクトでなかなかアウトプットが出ない、
また、プロジェクトの進捗にスピード感を感じないプロジェクトを見かけるようになりました。
そのプロジェクトの状況をヒアリングしてみると、
「要件が曖昧でなかなか進められない」という意見がよく聞きます。
この原因を掘り下げていくと、若手プロデューサーの力量不足があげられますが、
加えて、「受託開発のジレンマ」と格闘するエンジニアの存在もあげられます。
受託開発の特徴として、「決裁権がない」・「予め決まったものを作る」の2点をあげましたが、
ネットサービスの開発の特徴は、「自分で決断する」・「自らで考えたものを作る」と正反対のものです。
サービスコンセプトや事業上のゴールを明確にした上で、
自分たちが作るサービスをどのように利用してもらいたいのか？
自分たちが作るサービスが流行っているイメージ（成功イメージ）を膨らました上で、
その為に、どういった画面遷移やユーザーフロー、また、機能を詰めていきます。
何より、自分たちの決断に明確な答えがない状態で、
１つ１つ仕様を決断しサービスを作っていかなればなりません。
（受託開発であれば、発注元が決断をしてくれるから楽）
ここに受託開発のジレンマが潜んでいると思います。
どれだけ高い技術力を持ち、主体的にプロジェクトをリードしてきたエンジニアでも
知らず知らずのうちに、受託開発（決裁権を持たず、予め決められたものを作る事）に慣れてしまうと
頭で分かっていても、具体的な方法論を導き出すことに苦労してしまいます。
また、環境が変わり、一日でも早く成果を出したいと思うエンジニアであればあるほど、
自分の得意とするやり方に固執してしまう傾向があります。
ですが、受託開発とネットサービスの開発は、極めて異質なものであり、
その進め方においてはがらりと頭を切り替えて、モノづくりをしなければなりません。
ネットサービスの開発で、アジャイル開発を用いるプロジェクトが多くいます。
アジャイル開発の利点は、リスクの先出しだと考えています。
リスクの先き出しとは、ユーザーファーストでユーザービリティや品質（表示速度など）、機能性を実際に動くものを触りながらチェックをし、致命的なミスがないか？を開発途中段階で把握すること企画段階でどれだけ具現化したイメージを持って、完璧な仕様は作れません。
だからこそ、ネットサービスの開発でアジャイル開発を用いるケースが多いのだと思います。
ですので、極端な表現ではありますが、
考える過ぎるな、まず、作れ！
が受託開発のジレンマを打破するために大切な事だと思います。
（こんな表現をすると当社のエンジニアから文句を言われそうですが
）ネットサービスは一定のクオリティでリリースすることができれば、
改善を積み重ねて行くことで、更にサービスの完成度を高めることができます。
また、スマートフォンは、誰よりも早くサービスを提供することが重要な市場です。
だからこそ、過度に考えず、まずは動くものを作り、
そのアウトプットをネガティブチェックをし、完成度を高めていくしかありません。
受託開発のジレンマに心当たりのある方は、
今のプロジェクトの開発の進め方を見つめるところから始めましょう。
昨晩は、スマホ部門の中途入社エンジニアとの懇親会でした。
入社した彼らの情熱、志を聞くことこちらまで熱くなりました。
一緒にスマホユーザーの心をがっちりと掴むサービスを作りましょう！