プラットフォーム開発にありがちな泥沼を回避せよ – RE-Business

プラットフォーム開発にありがちな泥沼を回避せよ

はぁ〜なんでだろう・・・常に、泥沼化した案件を抱えている。

シェアリングエコノミーやマッチング系のプラットフォーム開発はよくこうなる。同じ失敗は繰り返さなくても、毎回新しい失敗を繰り返しているような気がする。

冷静になって自分でも考えを見つめ直し、頭を整理するためにこの記事を書いてる。

プラットフォーム開発が泥沼化する根本的な原因は、ほとんどの場合最初の設計図があまりに複雑すぎて、全容を把握している人間が誰もいなくなるとうケース。

要件定義書や画面遷移図などは本来ならそのプラットフォームを思いついた本人(アイディアマン系)が最後までしっかり監修しておかなければいけないんだけど、こうしたアイディアマンは途中から「あとは任せる」みたいな感じでプロトタイプ版が完成するタイミングまで顔を見せなくなる。

こうした事前の設計図に責任者を明確につけないといけない。

何人かが関わったりすると、「ここまでは俺やるけど、あとは頼むね」みたいな感じに責任が移動し、移動を重ねるたびにその責任の重さや所在が不明になる。

プラットフォームの肝である設計図。開発中に泥沼化するケースはここがまずもってダメになってる。

 

フェーズごとに予算を分散化しとく

プラットフォーム開発をする人・・・・・。ん〜なんて言うか、お金を出す人ね。そのプラットフォームの発注者であり所有者のこと。

プラットフォーム開発の経験がない人に限って、「一発で成功する」って期待を込めてお金をかけるわけですが、申し訳ないけど

一発で成功するはありえない

って思った方がいい、いやそれを知っておいた方がいい。

だから例えば開発予算が1,000万円だとしたら、一発目に全ての予算を注ぎ込むんじゃなくて、

テストを3回重ねる前提。第4フェーズでローンチを目指す。

これを前提として予算を分配する。最初はまずデザインだけ見たいから100万円で、次にシステムのラフ設計が入るから300万円で、次にプロトタイプ完成だから300万円、最後にローンチ段階は微修正だけにしたいから開発予算200万円の広告予算100万円。

こんな感じになるということを当然のように押さえておくべきだ。

焼肉屋やラーメン屋みたいなリアル店舗をOPENするのとは訳が違いすぎるので、「一発で理想のプラットフォームが出来上がるはず」なんて思っていると失敗する。

 

ボーリングではなくピンボール

これFacebook本社でCMOの人から教えてもらったことなんだけど、

プロダクトの開発は「ボーリング発想ではなくピンボール発想」と言うもの。

意味はシンプルなので両方解説しておくと、

まずボーリング発想が、

ボーリングの球をプロダクト(商品)だとして、レーンの奥に並んで立っているピンがユーザー(消費者)だとする。

ボーリングのボールは時間をかけて自分好みの重さやデザイン、指のフィット感まで完璧に仕上げてある。ツヤツヤに磨き上げた完璧なボールをピンに向かってストライクを願いながら投げる。

つまりあなたが強い想いを込めて完璧を目指して「完成」させたプロダクトを、消費者めがけて投げる。そのピンが倒れた本数だけがあなたの成果となる。

 

次にピンボール発想が、

同じくボールをプロダクト(商品)だとして、盤に無数に刺さるピンをユーザー(消費者)と見立てる。

ピンボールで使われるボールはピカピカでもなく完璧な球体でもない。少し荒くてサイズも小さい、どちらかと言うと未完成の状態だ。

このボールを運命に任せて盤に送り込むと、無数のピンに弾かれまくる。ピン、カン、コン、となんども音を立ててボールは弾かれてゆき、最終的に当たりかハズレのポケットに収まる。

つまり、ボーリングのボールの様にプロダクトを「完成」させてからユーザーに放り込むのではなくて、「未完成」の状態でいいからマーケットに投げ込んでしまうのがピンボール発想だ。

そして未完成のプロダクトは当然の様に、ありとあらゆるユーザーの声を集める。

「こんなのじゃ使えない」

「50点だね、合格点を取るには最低限これは用意しないとだめ」

「なぜこれはデキるのに、これはデキないの!?」

ほぼクレームに近いユーザーの声が集まってくる。

Facebookはこれを意図的に集めたいがために、プロダクト未完成の状態で世の中に投げ込む。

FacebookのCMOは

「プロダクトは私たちが完成させるのではありません。未完成のまま世の中にデビューし、様々な声を反映させて行きながら開発を進めています。まだ完成ではありませんが、完成させるのは私たちではなく、お客様です」

というかっこいいキメ台詞をぼくにくれた。

「完璧」や「完成」を決めるのは開発チームではなく、ユーザーだと言うことを理解するだけでも現在の取り組みが前進すると思う。

 

毎日探し続けないといけないモノ

プラットフォーム開発を心に決めたその瞬間から、毎日あなたが探し続けないといけないものがある。

それは何だろう!?

お金!?ノウハウ!?

 

もちろんそれも大切だけど、毎日探し続けなければいけないもの、それは

エンジニアだ

よく失敗するケースを紹介すると、最初のうちはアウトソーシングで開発をスタートし、優秀なエンジニアが見つかったら開発を内製化するというもの。

しかしこのケースの場合、お目当のエンジニアがなかなか見つからずに、結局引き継ぎ不能なところまでアウトソーシングで開発を進めてしまう。例によって「完璧」「完成」主義がそれを加速させる。

エンジニアは1人に決める必要はない、どちらかと言うと何人も候補者を周りに集めておくべきだ。

正社員なんて重たく考えるべきじゃない。一般的な企業体質だとエンジニアを正社員として採用して・・・・3人だとすれば給与と賞与、それから社会保険と・・・・・。

こう考えるからなかなか積極的に探せないし、採用もできない。

 

エンジニアはもっと現代的!?と言うか、働き方がズレてるというか・・・・。特にそういう奴ほどスキルが高い。

彼らに対して、素直に

『一緒にやろう!力を貸してくれ』って伝えるだけでいい

フリーランスとして期間を決めて付き合うのもいいし、新会社を立ち上げてその彼を役員として巻き込むのもいい。

時間で雇われるのを嫌うエンジニアが多いので、ぼくがよくやるエンジニアへの報酬支払い方法、

  • 進捗30%で報酬の20%支払い
  • 進捗70%で報酬の50%支払い
  • 進捗100%で報酬の110%支払い
  • アジャイル契約で毎月報酬の5%支払い

ちょっと意味が伝わりにくいかもしれないけど、エンジニアに完成納品後の支払いっていう契約はあまりにナンセンス。彼らのモチベーションを落とすとプロダクトの品質低下に直結する。

 

さてこの続き!?というかこうした開発系プロジェクトの中でよくあるトラブルや成功事例をメルマガ的に更新してるnoteマガジンを開設しました。

お盆休み明けから更新して行くので、お楽しみに〜

SHOのnote「開発プロジェクト日誌」

 


レンタルを中心としたストック型ビジネスモデルのネタ帳noteもやってます▼▼

note_logo_catch

ブログでは書けないことが書かれています。1記事100円からご購入いただけますので、ぜひ覗いてみてください。


年間500冊読む藤本翔がお勧めするBooks】

Female student studying at college library「知識は人生を豊かにする」という諸葛孔明の言葉が大好きです。ぼくが読んだ本の中で特におすすめの本をプチ書評と一緒に紹介しています。


Sho Fujimoto/藤本翔

藤本翔 | Sho Fujimoto Mobile🌏Bohemian | Artist 💻| CD | 6months Living🏡Osaka
✈︎ 2months work at 🏢Tokyo ✈︎ 4months Traveling🌏World | Love my Family💓

スポンサーリンク

●今日も元気にTweet中ですよ〜