【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得 に参加しました

やっぱりスピード感が大事だと思った。

勉強会URL

supporterzcolab.com

講師

twitter.com

この人。フリーランスでも色々やっているようで、登壇に関係のない話まで聞けてとても良かったです。

概要

基本的に新規事情の失敗談の話。得てしてこのような3つのことが起こる。

• 機能を作りすぎてしまう
• 技術的に挑戦しすぎてしまう
• 仕様が動的に変化する

順番に見ていく。だが、結論から言うと、これらの問題のせいでリリース速度が出ないのは良くないということである。

他者に先を越されてしまうと機会損失になってしまうし、企業であればそれまで投資したコスト、見込まれた売上を取り返すのは難しい。（そもそも新規事業は直近は赤字しか出ないし、黒字にするまで時間がかかるものである。黒字にする苦労が強ければ強いほど、お金を出してくれるステークホルダーは渋い顔になり、最悪打ち切り…となりかねないだろう。）

機能の作りすぎ

現代のモダンなアプリに求められる機能水準は年々上がっているように思われる。そのため、他の競合・類似サービスを真似て色々作るが、結局の所本質的に自分たちが考えていた機能にフォーカスすると優先順位が低かったり、そもそも不要である場合も多い。

機能の作りすぎはサービスリリース速度の低下につながる。まず、本当に必要なものに立ち返ることが大事で、類似サービスでの経験、ユーザーへのリアリング、最低限実装（とりあえず中身大きく作らずGASとか使う）、そして大事なもの以外は全て作らずに仮設を高速に検証して必要最低限で作っていくのが大事。

特にエンジニアの場合、色々な機能がついていれば使いこなさなきゃ！となりがちなのだが一般の人はそれまでITに強くないことを忘れてはならない。（そういえば今日、 chokudai さんがこんな発言してたし）

親子供兄弟、そういう人たちスマホやITに疎い人がいれば、そういう人たちの気持ちになって使ってみるのも悪くないかもしれない。

技術的に挑戦しすぎてしまう

ここはこの前の勉強会との共通部分になる。

yumechi0525.hatenablog.com

自分及びチームメンバーがなれている技術でササッと作ることが大事である。世間のエンジニア的ににこれがイケてる、この言語、このFWを使わなければエンジニアとして遅れてしまう！！ という思いがあるかもしれないが、世間の一般人としては表面に出てきているものが全てで、中身のことなんて正直どうでもいいのです。（エンジニアとしては寂しいかもしれないが、サービスというのは氷山の一角でしかないので）

とはいえ、ここは技術的好奇心との戦いでもあり、様々な技術を使って広い知見をつけていくのがエンジニアとしては良いはずである。なので、APIを高速化しないといけないところをRuby on RailsじゃなくてGoで書いてみるとか、フロントはVue.jsで頑張ってみるとか… 部分的に取り入れるのが良さげ。

全部新しい技術でやるのは勉強コストも高いし、新しいものを選んでしまうと日本語どころか英語ですらドキュメントがないのでリスキー。相当スキルがあるという自身がある人だけがやるべし… というのは間違いないと思う。自分ができても周りができなかったらコミュニケーションコストが高くなって、チームは崩壊に向かうでしょう。

枯れた技術を使うのも大切というのを感じました。

仕様が動的に変化する

新規サービスではあるあるで、最初の要求と変化してしまうために何を作っているのかわからなくなることがある。

ここで大事な物は「コアバリュー」を確認することである。Wikipediaによると、

コア・バリューは、英語のCore Valuesの訳語であり、中核的価値観を意味する。人や組織の価値観はその成長過程や環境の中で形成され、誰でも無意識のうちに持っているものであるが、使命や目的の達成のため、日々の行動や意思決定の基準として意識的に定めるものを「コア・バリュー」という。

らしいです。よくわからないように思うけど、結局このサービスを使って利用者に何を提供するのかを常に意識しておくことが大事であるということですね。

コアバリューが決まると、結局何を作るべきか決まるので着地点も見え、リリースも見据えられます。プロダクトを通して、何を与えるのか考えるのは大事ですね。

書籍の紹介とか

2冊ほどありました。

コンセプトのつくりかた

「事業を創る人」の大研究

両方とも結構面白そうな感じ。実家に帰るときに新幹線でひましている時間に読んでみようかなと思いました。

まとめ

失敗談を聞いていて思ったのは、お客さんにプロダクトを通して価値提供できないのが技術的な問題とか、開発的な問題でモヤモヤすると大変なのかな… と思いました。

最近良く聞きますが、ササッと最小限で作って公開、あとはABテストかしつつサービス改善だ！ っていうのはとてもいい傾向なのかも。これがほしい！ っていって1年後とかに出てきても今更かーと反応を裏切りかねないので。

反面、中途半端なものを出さないようにする工夫は大事です。β版だからここはうまく動いてないよ！後から実装するよ！っていうホップアップ出すだけでも印象は良いもの。とりあえず変に期待されすぎるのは良くないので、現実的に提供できている価値を的確かつ正直に表現できると人はついてくるはず… と感じました。

めっちゃいい話でした。