はじめまして。ICTマネジメント部の遠藤と申します。
今回はイースト・コースト・ワン（以下、EC1）の自社サービスプロジェクトの顛末についてご紹介します。
自己紹介
本題に入る前に私の経歴について簡単に触れさせてください。
一昔前と違い、様々な業務経歴（元バンドマン、元パティシエ、元携帯販売員）を持つ方が増えてきた昨今、私も同じく他の業界（食品メーカーの元配車マン）からの転職組です。
もちろん食品メーカー在職時はITの「I」の字も知らない人間でした。
コマンドプロンプトすら触れたことがありませんでした。
30歳を過ぎて「人生は一度きり」をモットーにECサイトベンチャー会社へ転職したことが、私のIT業界の始まりでした。その後再度転職し、友人とエンジニアと共に小さなWEBサービスを立ち上げましたが、約1年半で事業を縮小することになります。
私はこの後にIT技術者になるための職業訓練を受け、ご縁がありEC1に入社させていただきました。 入社の決め手は当社代表である小島社長が「今はSES事業だが最終的には自社サービスを立ち上げたい」と仰っていたことでした。 前職のリベンジをいつかしてやる。そういう気持ちがありました。
話はここでやっと本題のプロジェクトに戻ります。
私がその当時、所属していた部の定期会議で、何か新規事業の施策を募集したいとアナウンスがありました。私には前述の気持ちがありましたので、迷わず手を挙げ新規事業プロジェクトに参加することになります。
プロジェクトの始まり
ほどなくしてメンバーが集まりました。 メンバーは所属長を含め7人。偶然にもサービス立ち上げに必要な領域全てを担当できるメンバーが集まりました。
ご存じの方も多いと思いますが、WEBサービスを開発運営するには大きく分けて3つの領域の能力が必要になります。 企画・開発(プログラミング・基盤)・サポート保守の三領域です。ちなみに私はサポート保守がメインの業務でした。
初日はどういったサービスを開発するか決めず、一旦各メンバーで企画案を考えて持ち寄ることになりました。
とりあえず決まったのはプロジェクトチームの名前です。
名前は「とにかくリリース部隊」となりました。
命名理由は「サービスをとにかく世に出す」そのままです（笑）
このコラムを読んでくださっている方にはSES業界について詳しくない人もいると思われるので、念のため説明しておくとSES業界のエンジニアは基本的に自分の会社で業務をすることはありません。「現場」と呼ばれる別会社に派遣されて各々の技術力を活かして日々業務を実施しています。
この施策は日々の業務にプラスαで実施する内容でしたので、メンバーが捻出できる最小限の時間で実施することが求められました。 その条件のもと私が考えたのがミニマムアプリである「寄り道検索（仮）」です。
サービスをひとことでいうと会社や学校の通勤、通学帰りに定期区間内で寄り道できるスポットを一括検索できるサービスです。
特定の区域（多摩等）を検索できるサービスは色々あったのですが、自身の通勤定期区間（実質無料で移動できる範囲）を一括検索できるサービスは見つからなかったので、あったら便利なのでは？という気持ちがありました。
また、駅間経路検索機能やレストラン、スポット情報は無料で公開しているもの(API)があったので、これを使えば手間をかけることなく、機能リッチなサービスをつくれるかも。という思惑もありました。
他のサービスもいろいろあったのですが、結局次の会議で「寄り道検索（仮）」の開発が決定しました。 ついでに所属長の一任で私がプロジェクトのリーダーになることになりました。 しかし、私にあるのは前職におけるプロジェクトマネジメントのつたない経験だけで、開発の現場をまとめたことはありません。前回は完全にサービスの「発注」側で技術的な話は全てエンジニアにお任せでしたから。 色々不安はありますが、まずはやってみようの精神でこのプロジェクトを進めることになりました。
大緊張の社長プレゼン
まずはプロジェクトの承認を社長に得なければなりません。 そのため、企画に必要な情報を集めてプレゼン資料を作成することになりました。企画・開発にかかる期間（コスト）や予想される需要（売上）、リスクなどです。
サービスのコンセプト、画面を作成して開発期間を開発の担当者に見繕っていただくようにお伝えしたところ、開発期間は約5カ月となりました。想定される需要の大きさを社内アンケートやフェルミ推定などで予測し、データを集めました。 サービスに関する社内アンケートの評判は想定よりも良く、社員の70％がサービスに興味があると回答しました。このアンケート結果はシンプルに嬉しかったですね。
実のところ、私は事業計画を考えたことはありますが、前職のサービスは完全に自己資金で実施していたためステークホルダー向けにプレゼンをしたことがありません。もっと言えばプレゼン資料を作ったこともありませんでした。 「はじめてのプレゼン」のようなマニュアル本や、YouTubeなどでプレゼンの勉強を行い、まずは部長プレゼンに挑みました。正直手ごたえはなかったのですが、やり切りました。このプレゼンで指摘を受けた部分を修正すれば、本番も何とか通るかな？くらいの手ごたえでした。 今思えば、このときのなんとかなった感が本番での大失敗につながったのだと思います。
いよいよ社長プレゼン。 メンバー内でのプレゼンとはまず空気が違いました。社長以下取締役、他部署の部長などが勢ぞろいし、私は修正した資料を基にできる限りのプレゼンをしましたが、リスクに対する見通しの甘さや、収益予測の甘さなどを指摘され、厳しい状況でした。 そう、大惨敗です。残念ながら、事業の承認は通りませんでした。必要な情報を再度精査してから、また日を改めて再度プレゼンをさせていただくことになりました。
二転三転
指摘された内容をもとに、ここで改めてレストラン情報の取得API（無料）を調査したところ、想定している仕様に耐えられないことが発覚しました。本当に初歩的なミスです。 取れる選択肢は有料のAPIに切り替えるか、サービスを変えるかです。 会議を開きここまでサービスについて作業を実施したので、一旦有料APIで試作品を作成して、どのような挙動をするか見てみることにしました。
開発担当は優秀で想定よりも早く試作品が完成しました。ありがたいことに試作品は評判が良く、私が想定していたカタチでない使い方もされ、作って広めたことでユーザーの真のニーズを知ることができた、この体験は純粋に嬉しかったですね。
ただ、その後致命的なサービスの欠陥が発覚します。 有料APIを使用した場合想定する売り上げ期待値の10倍以上の経費がかかることがわかったのです。つまり、使われれば使われるほど赤字になるサービスです。 無料APIでは使用できるレベルにならず、有料APIの場合大赤字のサービス。 八方ふさがりとなり、残念ながらサービスは開発中止となりました。
APIの問題は、私たちが「スピード感を持って進めること」と「調査を深く掘り下げること」のバランスを間違えた結果でした。企画段階での調査の甘さがサービスの生命線に関わることを痛感しました。次の企画では、この失敗の教訓を活かし、スピードを維持しながらも、コストと技術の根幹部分については深く検証することを徹底したいと思います。
プロジェクトは続く…
実はこのプロジェクトはまだ続いています。
プロジェクト名の「とにかくリリース部隊」のとおり、とにかくサービスを世に出すということを目標にしているからです。 前回の失敗で「リリースに至らなかった」という悔しい結果を経験したからこそ、このシンプルな目標にメンバー一同、強い思いを持っています。 前回、失敗した私にも再度事業企画に挑戦するチャンスが与えられるのは、EC1の失敗を恐れない文化の現れだと感じており、本当にありがたいことです。 また、嬉しいことにメンバーの大半は次回の企画にも参画してくれています。
今はこの失敗があったから成功があったといえる段階ではありません。
いつかそう言えるように現在企画中の次のサービスは必ず成功させます。
もし、このコラムを読んでEC1に少しでもEC1に興味を持たれたら、是非、当社までご連絡ください。
EC1には失敗を恐れず、挑戦し続けられる環境があります。
あなたが我々と一緒にEC1で働いていただけることを心より楽しみにしております。
このような、つたないコラムを最後までお読みいただき、
誠にありがとうございました！