プロトタイプの開発をそのまま進めなかった理由｜#BYARD開発記 04
第4回は、プロトタイプが生まれた背景と、なぜプロトタイプの開発をそのまま進めなかったのかを振り返ります。
「BYARD開発記」について ※本文はこの下からスタートです
株式会社BYARD・代表の武内俊介が、サラリーマンから税理士資格の取得を経て起業し、BYARDというプロダクトを作り上げるまでの開発ストーリー。
開発に至るまでの背景や、プロダクトの設計に込められた想い、起業・開発を通じて得た経験などをご紹介します。
（ヒアリング／執筆／撮影：藤森ユウワ）
BYARDのプロトタイプについて構想を練り始めたときは、プロダクトの中身も、事業としての有り様も、現在とは少し異なる形でした。
自分たちが感じていたニーズから始まったプロダクト開発は、コアな部分は変わらず、その外形要素は少しずつ変化しながら、現在のBYARDというプロダクトへと昇華されていくことになります。
自分が感じる「強いニーズ」は本当に正しいか
2020年の秋。「業務設計コンサルティング」「バックオフィス領域全体のパッケージ化」という2つの事業を経て私は新たにSaaSプロダクトの開発を行うことを考え始めていました。当初は、まず自分たち自身の課題を解決するツールとして開発し、事業としての収益化はその後という構想でした。
開発の出発点となったのは、私が事業を運営する立場として感じていた2つのニーズです。
まず一つ目は、タスクの進捗状況を可視化したいというニーズ。
会社を設立した2018年はまだコロナ禍前でしたが、当時から会社を「フルリモート・フルフレックス」で運営していました。タスク管理ツールによる進捗管理はもちろん、日報やドキュメントツールによる情報共有、Slackを使った共有（いわゆる「timesチャンネル」）など、メンバーは場所も時間も勤務形態もバラバラであることを前提に仕組みを整えていました。
しかしそれでも、マネジメントする立場として知りたい情報が十分に把握できているとは言い難い状況でした。
タスク管理ツールがあっても、管理者が全案件の状況を細かく把握することは不可能です。そもそもマイクロマネジメントをするつもりはなかったので、各メンバーが働きやすいよう自律的に管理してくれればベスト。かと言って放任主義でマネジメントを放棄するわけでなく、適切なタイミングでフォローに入りたいとも考えていました。
・今、誰がどのタスクに取り組んでいるのか？
・今日は何をする予定なのか？
・全体の進捗の中で、どのようにスケジュールを立てているのか？
管理者として適切なフォローとフィードバックを行うために、計画や進捗状況をもう少し可視化する方法はないものかと感じていました。
二つ目は、改善のPDCAサイクルを回すための情報が欲しいというニーズです。
PDCAを回すためには最初にPlanを立てねばなりません。しかし多くの場合は前回のCheckが不十分で、過去の経験が生かされないまま次のPlanが立てられ、いつまでたってもDoが改善しない…というネガティブなサイクルに陥っています。
Checkをしっかりと行い、次のPlanの精度を上げるためには
・どのような計画を立てたのか？
・その計画は何を根拠にしたのか？
・結果としてどのように実行されたか？
・計画と実行の結果を比較して、最初の計画のどこに問題があったのか？
という情報を集めることが必要です。
しかし既存のタスク管理ツールは「タスクが完了した／していない」の確認でしかなく、完了したタスクのデータはほぼ活用されていません。レポーティング機能があったとしてもタスクの完了・未完了の数を集計しているだけであり、そもそもタスクとしてツールに乗っていない周辺業務はこぼれ落ちて、集計のしようもありません。
この2つのニーズは、バックオフィスの実務に長年携わってきた私が昔から感じていたニーズでもありました。
「請求」「支払」「給与計算」など、バックオフィスの各業務が滞りなく行われなければ、月次決算を締めることはできません。しかし管理部門のマネジャーが全体の進捗を知る方法は、タスク管理ツールの「完了／未完了」のみ。細かい進捗状況は個別にコミュニケーションをとって把握するしかありません。
定期的にくり返し行われるタスクがある一方で、タスク管理ツールには乗ってこない周辺業務もバックオフィスには数多くあります。
各業務は担当者がそれぞれのやり方で回していて、改善しようにも業務の全体像を知る術がありません。結果的に「非効率な方法のまま、細かいところは人の頑張りでなんとかする」ことがバックオフィスでは常態化しています。
・タスクの詳細な進捗状況と全体感を可視化したい
・改善のPDCAサイクルを回すための情報を集約したい
事業を運営するものとして、そしてバックオフィスの実務者として感じてきた2つの強いニーズ。
これらを解決できる新しいツールを作り、市場調査とβテストで仮説検証を繰り返して行けば、市場に受け入れられるのではないか——そう考えていました。SmartHRのグループ会社としてスタートすることが決まり、第1回の面談でより具体的な事業プランを説明する、そのときまでは。
私は上記の仮説を持って、プレゼン資料10枚ほどのツールの概要や機能をCEO（当時）の宮田さんに説明しました。しかしプレゼンを聞き終えた宮田さんが発したのは、
「そうですね、ちょっと機能にフォーカスしすぎていると思うので、ユーザーヒアリングをしてみて、もう一度、考えてみましょう。」
というひと言でした。今考えると、私は自分のアイデアに寄っていた状態だと思いますが、それを宮田さんは優しく諭してくれたのです。私はもう一度、自分のアイデアと深く向き合うことになりました。
どんなに優れたアイデアも、市場にニーズがなければ失敗する
“ほとんどの新製品は市場で失敗する。
たとえ、どんなにきちんと作って売ったとしてもだ。
これが、「新製品失敗の法則」である。”
書籍「NO FLOP!」の序章にはこのようなメッセージが登場します。どんなに優れたアイデアも市場に受け入れられなければ意味がありません。もちろんどの企業もそんなことは分かっています。事前の市場調査もなしに開発を行うことなど誰もしないでしょう。
しかしどんなに綿密な調査を行ったとしても、どんなにすばらしいプロダクトを作ったとしても、そのアイデアがそもそも本当に欲しがられていなければ失敗する——著者のこのメッセージは、宮田さんが言った「もう一度、考えてみましょう」という言葉とまさに同じなのではないかと思います。
「千に三つ」（1,000あるうちで成功するのは3つしかない）とも言われるスタートアップの世界で、成功の確率を上げることは容易ではありません。しかし「こうなってしまうと失敗する」というアンチパターンを踏まないことで失敗の確率を下げることはできるはずです。
そしてSmartHRのグループ会社というスキームのもっとも優れた部分は、この「失敗の確率を下げること」にあるのだと私は感じています。
「BYARD開発記」シリーズのご紹介
「BYARD開発記」は全13話のシリーズになっています。
BYARDそれ自体は、数ある業務用アプリケーションの中の一つですが、その背景にはバックオフィスの実務家として、事業の運営者として感じてきた想いや経験があり、それをプロダクトの設計に込めています。
BYARDでは、私たちと一緒にバックオフィスの世界を変えるようなプロダクトを作る仲間を募集しています。もし開発記をお読みいただいて、ご興味をお持ちいただけたようであれば、ぜひお気軽にお問い合わせください。
シリーズINDEX
第1章：BYARDへとつながった背景ストーリー
第2章：起業・開発で活用した手法
第3章：BYARDのプロダクト紹介
最終章
BYARDの採用情報は、以下のページよりご確認いただけます。
また、BYARDのこと、業務設計のこと、バックオフィスのことなど、CEO・CTOと気軽に話せるカジュアル面談も実施しております。「気になるけど、いきなり採用に応募するのはな…」という方は、ぜひこちらへお気軽にお申し込みください。
この記事が気に入ったらサポートをしてみませんか？