はじめに

社内外からCTOと呼ばれることの少ない繁田です。
珍しく自社サイトに投稿しますが、実は技術情報共有サービス「Qiita」で公開している qnote アドベントカレンダー2016 の最終日の記事でもあります。
この記事以外にも弊社スタッフが忙しい中、時には寝る時間を削ってまで書いた記事があるので、どうぞお時間のある方は読んでやってください。

【Qiita】 qnoteアドベントカレンダー2016
http://qiita.com/advent-calendar/2016/qnote

最終回は技術ネタというよりは企画に関するノウハウとして、失敗から学んだことをまとめたいと思います。ちょっとタブー的なところもあり関係各所からお叱りを受ける気がしますが思い切って投稿します。

背景

弊社は受託開発一筋で13年の月日が経ちました。

もうすぐ14回目の年末。

業界通例となる年末進行も、ここ数年は若手が育ってきたおかげもあり、わりと平穏なお正月を過ごせています。

さて、そんな弊社も、そろそろ自社で何かサービスを始めたいと言う声が頻繁に上がってくるようになりました。ある程度人的リソースの空きが生まれてきたというのもありますが、それよりも、技術的なノウハウが蓄積し、それらをもっと自由に、自分たちのやりたいように活用したい、という思いが強いんだと思います。

もちろんこれまでも何度かそういった声は上がり、有志だけで集まって企画を考えたこともありましたが、実現には至っていません。

また、今年に入り何度か全社員でブレストの時間を割いたりし、素晴らしいアイデアがいくつか生まれましたが、これもまた実現には至らずでした。（※現在進行中のものもあります）

「なぜなのか？」

という事を弊社の開発主任と二人で飯ついでに話し合ったことがあり、お互い見えてきたものがあるので、「受託専門の開発会社が自社サービスを立ち上げる時に失敗しがちな5つの要因」と題して5つほど挙げたいと思います。

受託専門の開発会社が自社サービスを立ち上げる時に失敗しがちな5つの要因

要因1 スキル不足

冒頭にも述べたように弊社は受託開発専門を長く生業としており、経験はそれなりに自信があります。また、雑誌やWebコラムにも寄稿していたりと、新しい技術動向の収集にも力を入れています。にも関わらず「スキル不足」というキーワードを第一に上げたのは、開発以外のスキルが不足している、という事を言いたいからです。

開発以外のスキルとは？

何度も言いますが、弊社は受託開発案件をメインにやってきました。プログラムを書くという開発以外にも、インフラ構築、保守、などプロジェクト進行の多くのタスクを経験しています。

しかし、

プロジェクトの初期のタスクに関しては誰も未経験だったりします。初期のタスクとは、例えば、企画立案、提案書、事業計画、競合などの市場調査など、事前準備のタスクであったり、プロモーションや売上予測などの運営・営業タスクです。

なので、自社で何か始めようとしても、何から始めればよいかわからず、いきなり設計書を作ろうとしてしまいます。ライトなゲームやWebのマイクロサービスなどであれば勢いで作っちゃうと言うのも頷けますが、会社の事業の一つとしてサービスを立ち上げるとなるとこれが大きな落とし穴となるのではないかと考えました。

要因2 開発の辛さを知っている

弊社スタッフは全員開発者です。実は営業や経理を専門としたスタッフは居ません。つまりそういうメンバーだけで構成された自社サービス開発チームは、開発の辛みを知り尽くしています。良いものを作ろうというアイデア出しの段階でこういった辛さがブレーキになっている事が少なからずあると考えています。もちろん経験やノウハウから来る仕様の回避は必要ですが「これは実装が面倒だな。。」と言った理由で仕様を回避する可能性が高まり、要因の一つとなっている可能性は高いです。

要因3 プロダクトオーナー不在

全てがそうとは言いませんが、受託案件というものは、仕様書設計書を渡されて、ただひたすらその通りに作る、という進行が比較的多いです。良かれと思い、仕様書に無い便利な機能を追加したり、明らかにユーザビリティを無視した仕様を変えようものなら、直ちにバグとして扱われることもあったりします。（もちろんそうならないように事前に先方に提案して仕様書を改善するように努力するのが我々の勤めです）
何が言いたいかと言うと、我々のタスクの範囲に作り手の本当の思いや、その仕様に至ったアイデアの過程などはなかなか見えてこないということです。

見えるのは、ただただ機械的な文章で構成された仕様書設計書。

これはつまりスクラムで言うところのプロダクトオーナーが見えない状態であり、普段からその存在を意識していないため、いざ自社サービスのプロダクトオーナーになろうとしても右往左往しがちなのは当然です。これも要因の一つと考えられます。

要因4 スクラム慣れしていない

スクラム開発という言葉も浸透して久しい今でも、こと小規模な受託開発に関しては適さないと考えています。前述の通り社内タスクフローにはプロダクトオーナーが日常的に存在することはなく、大きなプロジェクトを除き、コードを書かない立場にあるスクラムマスターを社内で立てる余裕もありません。特に2,3人で進行する案件が多い弊社ではほぼ効率的な進行は無理です。もちろん発注元も含めたプロジェクト全体でのスクラムの一部として参加することはありますが、結構レアです。

自社サービス開発となるとやはりプロダクトオーナー、スクラムマスターによる2トップ体制での進行は圧倒的に効率的でありますので、ここのスキルを持ったリーダーが存在するかどうかというところが鍵となるでしょう。

要因5 副業感覚によるプライオリティ低下

これが一番やっかいです。

受託専門でやっているとどうしても「自社サービス ＜ 受託案件」となってしまいます。これはまぁ受託業者としては絶対的な図式なのですが、それが故に、自社サービスの開発を断念せざるを得ない状況が発生します。特に自社サービスはすぐにマネタイズできるわけではなく、明確な金額で受注した案件を優先するのは会社経営判断にもなりますので、どれだけモチベーションが上がっていても、顧客を優先しなければなりません。案件受注はありがたいことですし、これを減らせば自社サービス開発の資金も無くなる、というプレッシャーもあり、負のスパイラルに陥ってしまいます。

一度解散し、プロジェクトがペンディングした案件は余程強いリーダーシップが無い限り再結成は難しいです。

改善

これらの理由は大きな頷きと共に、改善の余地が大いにあると考えました。

まず「要因1,3,4」に関しては経験するしか無いのですが、弊社では後述の"演習的"なプロジェクトを立ち上げる事で解決しようとしています。強引な解決案に思えますが、誰だって最初は未経験です。なにより弱点を知ったというのは大きな収穫。それを意識して経験すれば成功への近道になるでしょう。

「要因2」の解決においては、プロダクトオーナーはコードを書いてはいけない、という立場に尽きると思います。作り手の思いが開発の辛みで邪魔されないように、プログラムから一旦離れた立場に居続ける必要があります。今回は私がその立場になるのですが、根っからの開発者気質の私にはこれが非常に難しい。気がつけばコードを書き始めている自分が居るので、そこは若い世代の育成という意味でもタスクを任せないといけないなと反省しています。

「要因5」は意識を変えていくことが重要で、予算の無い自社サービスの開発作業は決して「副業ではない」と言うことをメンバー全員に強く認識させるべきです。
自分たちで立ち上げたサービスが成功するということは、自分たちが楽しく仕事できるように、というゴールへの投資でもありますので、本来最優先すべき案件です。そう考えると受託案件とバランス良く進めて行くことが出来るはずです。

あとはどれだけ忙しくても決してプロジェクト進行を止めないこと。遅くても良いので少しづつ続けて行き、数分でも良いので朝会や情報共有時間を定期的に取る事が大事。一度離れてしまったモチベーションを戻すのは体力を使いますので、それを維持することを心がけましょう。

実践

ラッキーなことに、とある案件で必要としているサービスがあり、それを自社で立ち上げるという試みを始めてみました。既に軌道に乗っている案件があり、そこで最初の導入先が確約されているため、成功の確率は少し高まります。改善のための経験や、自社でサービスを立ち上げたという成功体験をさせるタイミングとしては最適でしょう。

ただ、演習的ではありますが、顧客が居る限り失敗は許されません。むしろ、このタイミングと環境が揃っている状況で失敗するのであれば、そもそも自社で何か立ち上げる力なんて無いんだと諦めるべきです。

それくらい背水の陣を布いて臨んでいます。

まとめ

というわけで長々と書いてしまいましたが、この経験は実は自社サービスの立ち上げの成功体験だけでなく、受託案件にも還元されるものも大きいと考えています。仕様書設計書に書かれていることだけを見るのではなく、作り手の思いを意識して、自分の頭で考えて行動し、より良いサービスに改善するためそれを提案する、など、開発のタスクだけにフォーカスしがちな意識をサービス全体に持っていくことで、より良い「ものづくり」が出来るようになると思います。

立ち上げサービスについてはまだ具体的な内容はお伝えできませんが、うまく行けば来年後半には大体的に紹介できるかと思います。

2017年の qnote にご期待下さい！

それでは、最後になりましたが、本年も大変お世話になりました。
来年も変わらぬご愛顧のほど、どうかよろしくお願い申し上げます。