スモールスタートの定義
普天にするほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
さて今回のタイトルなんですが、スモールスタートはなぜ失敗するのかというタイトルになります。
スモールスタート、よく聞く言葉、システム開発に限らずよく聞く言葉かなとも思うんですが、これは辰巳さんに聞いちゃっていいですかね。
システム開発におけるスモールスタートって大体どういったことを指してたりするんでしょうか。
必要最低限の機能だけを抑えて、それで先行してリリースして運用しながら後は考えるって言うとちょっとそれは言い方悪いかもしれないですけど。
まずは最小限の機能を揃えておくっていうのが開発のことですかね。
スモールスタートと聞くと、なんとなく金額が単純に安くなるのかなみたいなイメージがやっぱり先行しやすいですが、
辰巳さんの今の話を聞く限り、単純に安くするだけではないんだろうなというところを示唆すると言いますか、言っていただいたかなと思ってます。
一般的にスモールスタートというと、単純に安くという言葉で特定のクリエイントさんではないんですが、
そういった意味で使われる方も多いのかなというような印象はあるんですが、
辰巳さんはあってますかね、このイメージとか印象とか。
多分安くやりたいというよりも、とりあえずやってみて反応を見たいっていう感じですかね。
特にB2Cみたいなお客様のシステムだった場合、お客さんの反応を見ながら変えていきたいというので、最初は小さく始めたいという時にも使われがちというところですかね。
そうね、何千万もかけてね、みっちり作っていくっていうのは、昔ながらの開発はそういう風に作っていったと思うんだけど、
その待機後だよね、たぶんそんなにかけてたらどんどん状況も変わっていってしまうし、他の強豪も出てくるかもしれないし、
そんなの待ってられないので、とにかくスモールでスタートしよう。
全然無説明なんで、スモールでスタートしようというのがスモールスタートだね。
話聞いてて思ったのが、スモールスタートと安く押さえたいっていうのは別かなと思っていて、
スモールスタートがなぜ失敗するのかって今回のタイトルですけど、
スモールスタートの失敗要因
スモールスタートだと言えども、中長期的なプランとかロードマップがあって、最終的にこうなる予定であるっていう算段がついてたり、
それを踏まえて開発の設計段階においても、どのフェーズにおいて何が実現されるべきかっていうのをそれなりに議論されていれば問題ないと思うんですけど、
それができてないから失敗するのかなとかちょっとふと思いましたね。
なるほど、スモールスタートをするにあたり失敗しがちなパターンと言いますか、
ということがフェーズがうまく分かれてないっていうところも一つありそうっていうところですかね。
だし、なんでしょうね、やっぱりそこで設計をちゃんと考慮しておかないと、結局じゃあ途中になってきて、
なんかこのままだとまずいってなって作り直すとかもあり得なくはないですし、
あとなんか拡張できない構成になっちゃってしてるんで、
じゃあそれ運用でカバーせざるを得ない状況になってしまったりだとか、
じゃあ結局それだったらパッケージで良かったんじゃねみたいなこともなんかあり得るんじゃないかと思いますよね。
確かに先ほど島田さんにおっしゃっていただいたように、
お客さんの反応を見ながら改善していきたいのでスモールスタートっていうことを考えたときに、
そもそもその反応があったときに回収できるような作りになってないと、
そもそもそれも実現できないっていうところもあったり、
それが抜けていると結局作り直したり、
それであれば既存のこのシステムで良かったのにみたいなことも最初に考えてないとありがちというところになるんですかね。
そうですね。なんかよく言った言葉で言うと、リーンスタートとかプロトタイプ開発とかよくあると思うんですけど、
プロトタイプに関しても、なんか開発会社、全開発会社的にその発言でちょっと怖いですけど、
プロトタイプ開発ってあくまでプロトタイプでしかないので、
それで終わりかって言うと全然、それを使おうとするとあんまり良くないので、
やっぱり実用にかなった設計をちゃんとするっていう必要性も出てくると思いますし、
ちゃんとMVPTでミニマムバリュープロジェクトっていって、
それが満たされてない状態だけれども、とりあえず小さく動かせる状態でやっちゃうってなると、
逆に損をして結果的にコスト高くなっちゃったりということもあると思いますし、
っていうのは意外とあるんじゃない?
聞こえばやっぱりスモールスタートかっこいいですけど、スタートアップとかね、
顧客の声を反映する重要性
キラキラしている印象はあるかもしれないですけど。
確かに後々回収していきたいとか、最初の面で費用を抑えたいといったもののトータルでコース増えたり、
作り直したり、余計時間がかかったり、コースもかかってきたりといったら、
そもそも話が変わってくるというところですもんね。
我々が別に高い金払えって言ってるわけでは、もちろん全然ないんですけど、
そこの認識のズレっていうのは、開発を始める前に擦り合わせて埋め合わせておきたいですよね。
島田さん、スモールスタートを求めてくるお客さん、クライアントさんの場合であれば、
やっぱり最初にきっちり要件を詰めていって進めていくって形になるんですか。
プラムザとしてどう進めていっているんだろうなというのをお伺いしたいなと思いまして。
皆さん言ってる通りだと思いますね。
初めにやっぱり計画立てて、今回のフェーズでは何を維持して、どういうことを吸い上げて、
それによって次どうするかみたいなところを考えていきましょうみたいな、
そういう計画を立ててやるのがいいのかなと思いますよね。
でもコスト面で言うと、初めにフィードバックも受けずに全部作りきってしまうよりは、
そうすると無駄な可能性もあるので、全然ユーザーの方、そっちの方向に使ってもらわなかったみたいな、
こっちの機能ばっかりみんな使ってるとかになると、
使ってもらわなかった方の拡張機能みたいなのは全く無駄になってしまったりするので、
そういう意味では途中まで作って、すごい疲れる部分について、
さらにそこに便利な機能とかね、帳表とかレポート機能とかを追加していくみたいな、
そうすれば無駄がないですからね。
そういう計画をやっぱり開発者とお客さんと両方合わせてね、
一緒になってやっていくべきなんじゃないかなと思いますね。
ありがとうございます。
これは他の回でも結構話していることにはなるんですが、
これはやっぱり準委任とか、ラボ型開発と相性が良いものなんですかね、どうなんでしょう?
もちろんラボ型開発はいいですよね。
いいけど、スモールスタートとかリーンスタートっていうのは、
細かくフェーズを切って作っていきましょうって話なんで、
普通の一括受付でもできると思うんですよね。
4、5ヶ月ごとにフェーズを切ってやっていこうみたいな、そんな感じだと思うんだよね。
スモールスタートというものを成功させるに大事なのは、
しっかり最初に設計したり、フェーズを決めて進めていくというところで、
あとは一括とかラボ型とかいうのも柔軟に対応していく。
それよりも最初の設計を決めて進めるというところが大事になってくる感じですかね。
そうですね。あとは何でしょうね。
何をしないか、何をその時点でやるかというか、何をしないかっていうのもすごい重要な気がしていて。
本当に機能としては根幹にあるものなのかもしれないんですけれども、
それって将来的に拡張性あるよねっていうものがあったりだとか、
それがネックになってコスト高くなってしまうみたいなこともあったりして、
結局お客さんの声っていう話もあると思うんですけど、
使われないとかあんまり人気がない機能とかがあったりするじゃないですか。
それも本当に重要なのかっていうのを、
開発の段階でもお客さんにすり合わせをしていく必要があるかなと思っていて、
例えば本当さっきもミーティングしてたんですけど、
今の段階でどういうふうにすべきか、どういうUI、UXがいいのかみたいな話をするときに、
一番使うユーザーさんにヒアリングの機会をちゃんと設けようって話になっていて、
それを明確にこちら側からアクションをかけて、
ちゃんとヒアリングこの段階でしましょうねっていう、
それでユーザーケース考えましょうねっていうことって、
昔あまりやってなかった、最近は本当にちゃんとやるようになってきたっていうところがあって、
そこも本当に作りながらでもお客さんの声をちゃんと拾い上げて、
スモールスタートの重要性
予算が限られているのであれば、その中でどうやりくりするのかっていうのを、
本当にもう序盤からしっかり考えていって、
終わり際にやって、ああすればよかった、こうすればよかったってならないようにするのが本当に大事かなと思いますよね。
考えてみたら最初の段階で開発を依頼するお客様の方に関しては、
やりたいこと全部上げてくださいっていうことも全然あり得るのかなと思っていて、
将来的にやりたいこととかも含めて全部上げてもらうと。
その中でプラスで実際使用するお客さんの声を吸い上げることによって、
こちらとしては優先順位っていうものが付けやすくなってくるっていうような話になるんですかね。
そうですね。本当に言い方を表せずに言うと、
全部のリクエストとかヒアリングの内容で出てきたことを鵜呑みにするというか、
そっくりそのまま全てそれを採用するっていうのは当然難しいと思うので、
おっしゃる通り優先度をしっかりつけて、ちょっと抑えておいた方がいいかなっていうのは考えておいた方がいいですよね。
なるほど。島田さん、この優先順位をつけていくっていうことに関して、
ちょっと難しいかもしれないんですが、気をつけていることとか、
ここは抑えておくとか、ここは聞いているみたいなこととかあったりするんですか。
優先順位ですか。なかなか難しいですね。
難しいと思うんですけど。
ケースバイケースだと思うけど、やっぱりあまりにも大きな変更はできないので、
よく言うユーザーロールが追加になるとかっていうのはかなり難しいので、
その辺はあれだよね。初めにちょっと設計しておかないといけないっていう感じがしますよね。
そうだね。ケースバイケース。今ね、自分が作っているゲームのアプリがあるんだけど、
それなんかもどんな使われ方をするのかっていうのはちょっとわからないところがあるので、
こちらは工事が楽しいと思ってやってるんだけど、実際はどうなるのかわからないから、
出してみて、面白がってもらっているところを充電的に機能を追加していこうみたいな話になるし、
そういう意味でのスモードスタートっていうのは絶対大事だと思うんでね。
開発プロセスの柔軟性
そうすると、意図的に作り切らないで様子を見るっていう感じでね。
出したけど、一番今悩んでいるのはチュートリアルがあるんだけど、
それどこまで作り込んでいくかっていうのがあって、新しいタイプのゲームなんで、
チュートリアルをちょっと充実させなきゃいけないかなと思うんだけど、
実際はどんどんみんな勝手に始めて失敗しながら学んでいく可能性もあるので、
そうしたらチュートリアルなんて基本的なブロックを基本ソースだけ教えておけばいいのかなって思うこともあるし、
全然やってくれないと。
そうなるとチュートリアルを充実させてクリアすることにこういうのを与えていくみたいな、
そんなこともするわけじゃない?
チュートリアルって使い方の手順をゲーム上のUIとか新コードによって分かりやすく表示するってことですよね?
そうそうそう。
そんな手の込んだことをやってるんですか?
やってるよ。
当てようと思ってるからね。
すごい。確かに僕もゲーム死ぬほどやる人なんでよくわかりますね。
ストーリーを盛り上がらせる曲線と同じタイミングで使える機能を増やしたりだとか。
そうそう。初めからいきなりものすごい教え込んでも嫌になっちゃうしね。
本当そうだと思います。
何系のゲームなんですか?全然突然ですけど。
これは対戦型の軍事将棋とかそういう感じのバトルなんでね。
それがスモールスタートになるのかわからないですけど、リリースを期待して。
来年くらいかな。
来年、結構直近ですね。
全然スモールじゃない。
これも別の回でも何度も話してることかもしれないんですけど、
フェーズを分けるっていうこととか、この時点で必要っていうこと、
もしくは最終的にここが自由になるよねみたいな、
ある種完璧な設計っていうものはやっぱり難しいっていうことですよね。
あれば最初から区切ってってことできると思うんですけども、
やっぱり予期できない部分、お客様の反応が今回特にそういうところかなと思うんですけども、
そういうところを様子見て柔軟に対応するためにスモールスタートをする。
スモールスタートをするにはある程度フェーズを分けるような完璧に設計は難しいと。
だけども抑えどころはシステム開発。
NiziUがやってるプラムザであればしっかりと把握して提示していくことができるっていうような認識であってますかね。
だいぶざっと話してしまいましたが。
でもお任せいただければフェーズの切り方とかも提案できるし、
その辺は大丈夫だと思いますけどね。
とりあえずスモールスタートをするのが流行りだからやりましょうっていうかそういう話ではないのでね。
要はクライアントの要望に沿った開発のフェーズ分けだったりとか開発の手法っていうのは
都度都度ヒアリングして提案できますというのはあると思いますね。
ありがとうございます。本日はこんなところでいかがでしょうか。
ありがとうございます。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
