見出し画像

#失敗談 新規ビジネスをアジャイルで無理やりやろうとした結果

2年目エンジニア sasayabakuというものです。 普段の仕事はAI関連のバックエンドエンジニアをしているのですが、上層部の一声で新規ビジネスに今流行りのアジャイル開発手法で取り組んで失敗したので、自分への備忘録を含めてnote初投稿してみました。

こんな人に読んでほしい

・アジャイルの経験があまりない人
・プロダクト開発の失敗談を見たい人
・新規開発を押し付けられた人

背景: なぜアジャイル開発が始まったか


ある日、上司やその上の人に

「IoTの新規ビジネスを創出してください」

と言われました。


(著者)「(うん、まぁ流行りだし言ってることは正しいな)。で、どんな方向性で考えてます?」
(上司) 「IoTを使って、売れそうなものならOK」


とこんな感じで、何もない無茶振りな新規事業創出が始まりました。さらに縛りプレイとして、

・サービスとして提供 → SIはダメ!
・会社の方針で、アジャイル + Most Viable Product(MVP)で開発してね
・2週間で、プロトタイプ第1号よろしく


と流行りワードのオンパレードでした...
逆える訳無く、とりあえずやってみようということでやってみましたが、まあ上手くいかなかった (- _- )。
そんな記録をつらつら書いていこうかなと思います。

環境

今回の取り組みでは、まさかのALLエンジニア(8人)しかも、全員普段はバックエンドエンジニアなので、ネット上でアジャイルの手法を調べて素直に取り組んでいきました。

先に結果から

結果から言うと、動くモノを作ることに必死になりすぎて失敗しました...

MVP = 機能最低限のモノを動く形で迅速に作る

の認識でモノの作成にほとんどの時間を割きました。そのため間違った方向に進みまくり、残念 なことに大きなゴミが残ってしまう結果に...

やったこと

何をやったかを説明しながら、しくじった事例を書いていきます ( - _ - )。

大まかな流れ

アイデア出し + アイデアの選定
取り組むトピックの磨き上げ
コードを書いてみる

アイデア出し

はじめに、何はともあれアイデアを出さないと動けないと思い、 何を作るかをアイデア出し ~ 選定まで実践してみました。

ブレインストーミング

集まってから個人ワークで考える のは時間の無駄だと思ったので、アイデアは非同期 で出してもらった状態でアイデアの選定から集まるようにしました。
個人のアイデアは、Google スライドに付箋形式でペタペタ貼ってもらいました。
ネタ出しが困らないように"これいいな"と思ったサイト情報などは、Slackにペタペタ貼る専用のチャネルを作って運用しました。

画像1

アイデアの共有

Slack等で、

・ 他の人のアイデアでわからない部分を質問
・ 同じようなアイデアをグルーピング

して、各アイデアに点数付けできる状態にします。
グルーピングはざっくりと代表が1人でまとめてやるか、会議で短時間で取り組むのが良かったです。

アイデアの点数付け

メンバーが各アイデアに点数を付けれる状態になったので、点数を付けます。
制限時間 20分で、40個ほどのアイデアに点数を付けてみました。
(会議ではなくて、非同期で点数を付ける方がじっくり考えれますが、みんな個人で点数付けに時間をかけると思えなかったので、短時間で集中して点数付けしてもらいました。)

評価軸

今回は、新規ビジネスの種になるかをメインの評価軸として、5点満点で点数をつけてメンバー全員の総合点で何をやるかを選定しました。

評価項目

 ここで、最初に取り組むプロダクトのテーマを確定します。

採点例

下記の採点例だと、総合点の高い「アイデアB」を採用しました。

評価項目サンプル

取り組むトピックの磨き上げ

次に、アイデア出しの段階ではかなり粗々なものになっているため、
選定されたトピックをさらに深掘りしていきます。
今回は、アジャイル開発の立ち上げ時に開発方針を決める手法である。 インセプションデッキを用いて、作るモノの方針を固めます。

インセプションデッキで決めたこと

インセプションデッキには、11個の質問テンプレートがありますが、トピックの磨き上げに必要なものは、以下の2つでシンプルにまとめる方法を取りました。

我われはなぜここにいるのか:トピックの重要なテーマを3つ以内でまとめる
エレベータピッチ:トピックの 解決したいことターゲット  / 強み を、スライド1枚で完結にまとめる

大事なのは今から取り組むトピックの目的をメンバーの共通理解にすることです。

ここからが間違い | 開発に突入

これで何を作るか決めたので、「よし開発」と開発を始めました。
何の言語を使う? フレームワークは? など、徐々に技術的な話になり、エンジニア集団のメンバーが楽しくなっていきました。

しかし、これが問題でした・・・

どうしても、開発・実装というものは時間がかかるため、UI・バックエンド・サーバ などを揃えるためには、2週間超の時間がかかってしまいました。
それで上手くいけばよかったのですが、いざ完成して偉い人に見せにいくと、

「そんなことより。。。今週からこの事業に取り組むぞ!! 」

と、自ら言い出したMVP開発を一蹴して、新たな取り組みのオーダが来たので、無駄に作ったプロトタイプだけが残ってしまいました。。。 Fin

一気に時間を無駄にした気がしました

何が問題だったのか?

さて、ここからが問題です。

「何がダメだったのか。。。」

ポイントは以下の2点だと思っています!

・アイデアの有効性をもっと手軽に検証するべきだった
・細かな頻度で上司などの決定者に当てるべきだった

アイデアの有効性をもっと手軽に検証
まず初めに、アイデア選定 ~ プロトタイプの実装までしてしまったのが、大きなミスでした。
Gartner社などが定義している事業戦略の取り組み方として、

デザイン思考 → リーンスタートアップ → アジャイル

という流れがあります(下図のような定義です)。

画像4

今回の失敗ケースは、

デザイン思考の中でもアイデア出しの部分だけをやった後、検証のリーンスタートアップをすっ飛ばして、アジャイル開発に入ったのが原因だと思ってます。

ユーザ体験を考える部分(UX)を迅速に アイデア出し → 検証 を回して、大きな失敗をしないよ うにする必要がありました。

細かな頻度で、決定者に当てる

やり方はチームに一任されていたので、何とかチーム内で進めていましたが、意思決定者には重要なポイントに絞って報告という形で行っていたのですが、開発者と意思決定者での認識に差異があったのも原因かなと思ってます。

開発者:プロトタイプなので、機能面での評価え判断して貰おう
意思決定者:リソースは与えたから、プロダクトとしてビジネスモデルを作って来てくれるだろう

かなり致命的な意識の違いがあったため、意思決定者の期待値をかなり下回る結果に見えてしまい、途中で頓挫する流れが完成してしまいました。

細かに報告するか、進捗が見えるようにして、目的・方針が共有できるようにしてあれば、どこかで小さな違和感が生まれて修正するだけで済んだのかなと思っています。

まとめ

今回、アジャイル開発での新規ビジネスの創出で失敗したことを備忘録として書いてみました。

見切り発車で、開発に踏み込んでしまったのが大きな反省点です...
特に新規のモノを考える場合は、明確な問題が目の前にあるわけでもないので、なおさら

作る前にそのアイデア・前提が正しいのかを検証する必要がありました。

みなさんは、同じ轍を踏まないようにこの記事が少しでも参考になればと思います。

この記事が気に入ったらサポートをしてみませんか?