こんにちは。Micoworks代表の山田と申します。

私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。
その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。

2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。

当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。

この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。
そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。

※テックサイドの方々からすると当たり前の話ばかりになると思いますが、こんなことも知らない人がいることを認識いただくことで、Bizとの意思疎通のしづらさが少し緩和されるのかもしれません。

＜免責事項＞
現在は自身の解像度も高まったこともありますが、すごく優秀なCTO,CPOを始めテックチームの皆さんに支えていただけいておりますので現在のチームとは大きく異なります。

プロダクトリニューアルを考えた背景

今から2,3年ほど前、Micoworksが3プロダクトを運営していた頃に遡ります。
当時は、新卒採用特化型の採用管理システムが順調に成長していました。

調子は良かったものの、中長期的な成長や解約率の低減を実現するには、「新卒採用だけでなく、中途採用でも使える仕様にすること」「顧客の使いやすさ向上のためにUI/UXをリニューアルすること」の2点が必要との声が社内で強まっていました。

そして、理由を聞く限り、私自身 リニューアルの正当性があるように感じていました。
要点をまとめると下記3つの理由がありました。

当時、リスクを提言しているメンバーは存在していたものの、その声に耳を傾けるのではなく、経営サイドで「どうすればリスクがある中でもリニューアルを実現できるのか？」とリニューアルを進める前提での会話が進みました。

課題に対して「どうすれば解決・実現できるのか？」という視点で向き合うこと自体はとても重要だと考えています。しかし、プロダクト開発におけるリスクの軽視が後に大きな綻びをプロダクトに生じさせ、チーム・顧客・会社と全方位に対して非常に苦しい状態を引き起こすことになりました。

プロダクトリニューアルを決断した理由

上の内容だけでもツッコミどころだらけですが、当時リニューアルを進めていきたかった理由は明らかでした。

1点目は、現在のプロダクトを改良すれば、本気でマーケットを取れる可能性を感じていたからでした。

リリース1年で数百社に導入されていたことで、プロダクトへの手応えを感じていました。また、利用継続率も比較的高く、まだまだ拡大できるポテンシャルを感じていました。

チャンスを感じていたからこそ、業界No.1になるための必須要因として「もっと顧客が使いやすいプロダクトにしなければ」と考えていました。

2点目は「採用規模が大きな企業ほど使い勝手の悪さを感じる」という、お客さまからの声が存在していたからでした。

使い勝手が理由で解約になったケースを自分自身も目の当たりにしており、「とにかくお客様に喜んでもらえるプロダクトにしたい」気持ちが非常に強く存在していました。

規模の大きな企業ほどいただける金額も大きくなるため、ビジネス的にも重要だと思っていました。

3点目は、中途採用への対応により、マーケットが数十倍に広がるからでした。
リリース当初のプロダクトは、あくまで新卒採用に特化した採用管理システム。

仕様を変えることで中途採用においても利用可能であり、そのことで事業としてより魅力的になると考えていました。お客さまからも「中途採用で使えるようにしてほしい」という声もいただいており、その考え方が正しいとも感じていました。

そして中長期的な競争優位性を加味しても、今のままではプロダクトの優位性を維持し続けることが難しいことは明らかで、プロダクトが成長している間にマーケットを広げるための次の種を仕込んでおきたい気持ちも強く持っていました。

今振り返ると全く持ってGOできる状態ではなかった社内事情

今振り返るとGOしたい理由は理解できるものの、リニューアルを進めるべきでなかったことは明白でした。様々な理由が連なっていたとは思うものの、大きくは以下の3点がGOすべきではなかった理由だったと考えています。

まずは、「適切なメンバーアサインができなかった」点についてです。

具体的に言うと、経験が浅いメンバーや大規模な開発を行ったことのないメンバーに重すぎる役割を投げてしまっていました。

また、外部を活用するにも関わらず外部のエンジニアの皆様をマネジメントするためのロールも手薄な状態でした。

その結果、チームビルディングや開発状況の適切なモニタリング、仕様のレビュー等全方位的に穴だらけな状態を生み出してしまっていました。

最初に外部のサポート企業に「可能です」と言われたことだけを信じ、徐々にそれが不可能だと分かり始め、プロジェクトの前提が大きく変わる事態になっていました。

開発に限らず起こりうるとも感じていますが、新しいことをやろうとするとアサインが必要なポストが増えていきます。

その際に、「このポストに必要なスキル/スタンスは何か」と前提定義をせずに「誰ならできそうか？」という視点のみで誰かをプロットしてしまいがちです。

時には「今はやらない」選択こそが、会社の成長に重要なインパクトを与えることもあると痛感した出来事でもありました。

次に、「システムの要件定義に十分な時間を割かなかった」点に関してです。

前提として、リリースに余裕のあるプロジェクトの方が世の中には少ないのだと思っています。

しかし、余裕がないなりにもプロジェクトのサイズや技術的難易度に合わせた最低限の検討期間が必要です。

その中でも様々なリスク要因や今見えているプロダクトの拡張性を担保し得る要件定義はとても重要です。

以前、THE GUILDの代表でnote株式会社 CXOの深津さんに「私なら開発よりも、開発前の設計に多くの時間をかける」とコメントをいただきましたが、当時の私はこのことの真意を理解していませんでした。

これは私自身が出来上がったプロダクトの状態しか見たことがなく、プロダクトを作ることの全貌を正しく認識していなかったからこそ起きていたように感じています。

例えば、車を見たときに約3万個の部品から成り立っていると分かる人はほとんどいないのではないでしょうか。100個や、500個ぐらいと見えてしまう人もいると思っています。

100個の部品からなる車と、3万個の部品からなる車だと、設計の難易度が大きく異なるのは想像に難くありません。

（そもそも100個の部品からなる車はないのだと思いますが、イメージのために記載しています）

「何人乗りでどのぐらいのスピードでどれだけ長く走れる車にしたいのか？」の定義次第で、設計思想やパーツ数が異なり、設計に必要な時間が変わってきます。

また、CO2排出量に関する条件や車椅子が必要な方でも乗りやすい車にしたい要望が出ればさらに検討項目が増え、結果として「どうやって作るのか？」を定義するのに必要な時間が増えていきます。

話を戻すと、我々が推進していた100人/月以上の開発プロジェクトを完遂するのに必要な検討・開発期間が部品3万個だとすると、実際に用意できた時間は部品3,000個を作れる程度でした。

意思決定者である経営サイドが要件定義の重要性を理解しきれていないがゆえに、「リリース期間のタイトさは工夫によって解決できる」と思い込み、取り返しのつかないリスクを見逃していました。

最後に「外注管理の仕組みがない中での大規模な外注開発」についてです。

当時、社内に開発リソースがなかったため、外部企業を活用してリリースする以外選択肢はありませんでした。

外部企業は採用領域に知見がある訳ではなかったこともあり、コミュニケーションギャップが必要以上にに生じてしまいました。

（これはそのリスクや差分を埋める方法を考えていなかった弊社の失態でしかありません。）

私個人としては、「外注＝悪」ではなく、外注管理を行うためのノウハウや仕組みが社内に存在していなかったことで防げたトラブルが多分にあったように感じています。

これらの結果、リリース予定日の早朝時点で緊急度最高カテゴリの不具合が100以上存在しており、とてもじゃないがリリースできない結果を招いてしまいました。

ちなみにその後数ヶ月かけて開発は続けスモールリリースはしていましたが、本リリースには至りませんでした。

今思い出しても関わってくれていたチームの皆さん、そしてリリースを待ち望んで下さっていたお客さまのことを考えると申し訳なさすぎてとても胸が詰まります。

当時の自分が向き合うべきだった問い

では、当時どんな問いを考えていれば、もっと良い選択ができたのか。

結論としては、難しい話ではなく当たり前の問いに向き合うだけで良かったのではないかと感じています。誰かの参考になるのかもしれませんので、具体的な問いかけの例を記載しておきます。

・お客様が求めているアウトカム（結果）は何か

機能開発は手段であって目的ではありません。

何か強烈に解決したい事象があって、それを解決しようとすると結果的に何かの機能に落ち着くだけです。そのためまず考えるべき事項は「お客様はどんなアウトカムを求めているのか？」という点です。

無意識のうちに自身やチームは「この機能が必要なんだ」とバイアスをかけてしまいますが、使われない機能を出すほど誰の役にも立たない現実はありません。

・本当にそのアプローチがベストなのか？、他にもっと良い方法はないのか？

アウトカムが明確になった場合、次に重要なことは「今思いついているアプローチが本当にベストなのか？」という点です。

人間はどうしても自分が出したアウトプットが愛おしく、否定的な意見に目を背けがちです。そして、人によっては「相手を傷つけてしまうかも」と思い、現案に対するリスクの提言ができないこともあります。

だからこそ、自分自身で自らのアプローチに対する懸念を出すとともに、積極的にリスクや代案について意見をもらう時間を取る必要があると思っています。

「自分自身のアウトプットの良さを競うのではなく、お客様にとってのベストをどう実現するのか？」のみに向き合うべきです。

・開発リソースを他に費やすことでもっと成長するのではないか

開発方針が決まった段階で水を差す動きにはなりますが、「本当にこの開発にリソースを投下すべきなのか？」は何度でも考える価値のある問いだと思っています。

お客様が求めているはずのアウトカムが実は10%のお客様しか求めていない、または求められてはいるがお金をいただける機能ではないので売上貢献ができない、事象が発生している可能性があります。

「10%のお客様でも使ってくれるならば良い」という考えもあるとは思うものの、事業成長をしていくには「より多くのお客様に感動いただけること」に対して優先的に対応していく必要があると考えています。

だからこそ、
・どれだけの人が、どれだけお金を払うほどに望まれているのか？
・どれだけの開発コストが発生するのか？
・同じコストを別に割いた際に、もっと喜んでいただけて事業成長が実現できる方法はないのか？
については機能開発と同じ熱量で向き合うべきです。

・リスクの中でも、取り返しのつかないリスクは何か

リソースの少ないスタートアップであればあるほど、全てのリスクを消すことはできません。つまり一定のリスクを許容しながら、目標期日に必要な品質でローンチすることが求められます。

一方で「これだけは抑えないと取り返しのつかないことになるリスク」は確実に存在しているものだと思っています。

そのため、取り返しのつかない恐れのあるリスクを可視化し、主要なメンバーからのレビューを入れながら必要な議論や方針へのアライメントを取る必要があります。

・絶対にやり切ると自信を持っているテックチームの責任者はいるのか

最後に問いたい点は、「該当プロジェクトをやり切る自信を持っているヘッドがいるのか否か」です。

大なり小なりプロジェクトを走らせると問題が生じてしまいますが、その際に他責にせず生じた問題に対して向き合い切れる人、課題を改善し切れる人がいるか否かが重要だと感じています。

もちろんこれにはスキルや経験も必要ですが、本人が持つメンタリティにも依存すると考えています。

そのため、「GOする前に本当に任せ切れる人がいるのか？」は本人とも会話し確認しておくと良いと思っています。

「依頼側は任せ切れると思っていたが、本人は元々厳しいと思っていた」みたいなことが後から発覚しては後の祭りですが意外と起こってしまう事象なのかもしれません。

開発チームは、必要な工程を飛ばさずに進めたい

今回記載した内容はとても初歩的な失敗です。

しかし「Bizサイドのプロダクトサイドの仕事の進め方に対する理解不足、コミュニケーション不足」に起因するプロジェクトの失敗は、経験の浅いメンバーには割と起きる事象ではないかと思っています。

なぜそう感じるのかと言えば、数年前の私自身が機能開発を進めていけないことに対して「何で開発チームってこんなに消極的なんだろう？」とモヤモヤしていたからでした。

そんな思考で仕事を行い、大きな失敗も起こした後に、社内外問わず色々な方のお話を聞く中で「開発チームは開発に消極的なのではなく、必要な工程を飛ばさずに進めたいだけである」と感じるようになりました。

Bizが普段行う仕事は、世に出してもすぐに修正可能な類の仕事がほとんどです。そして、多くの失敗が自分一人で簡単に修正できてしまいます。
スライドを変更するだけだったり、クリエイティブを少し調整するだけだったり、、、。

また、仮にセールスメンバーが提案資料の修正依頼を出しても、既存の資料を使って提案を続けることはできるわけでチーム全ての動きを止める経験をすることがありません。CSも同様です。

一方で、プロダクトチームの仕事は、工場の生産レーンの一部をそれぞれが担っており、自分が停まるとレーン全体を停止させ、出荷を遅れさせる大きな影響を与えてしまいがちです。

自動車の製造レーンで例えると、レーンごとに部品を作成し取り付けながら次の部品が取り付けられていきますが、たった1箇所の部品を変えるだけでも周辺パーツの形状や部品そのものを替える必要が出てきます。

そうなると、これらの箇所の取り付けが完了するまでは出荷できなくなるため、余分に多くの時間が必要です。また、取り付けられたとしても正常に動くかわからないため、動作確認も必要となります。

つまり、1箇所の修正だけのはずが、実は
・周辺との整合性を取るためのシステム設計
・システムを人が使うためのUI設計
・確からしい設計の実装
・実装後の動作検証
という工程が隠れています。

そして、これだけ手塩にかけた車が売れないとなると大きな損害が生じるため「本当にこの車って必要なのか？」といった事前検証も一定確信が持てるレベルで欲しくなるのは当然です。

そのため、単に「言われたから開発します」ではなく、「必要な工程をきちんと踏んで、必要な機能を開発し、お客様に届けたい」という思考が強くなるのだと感じています。

逆に言えば、こうした背景を認識していなければ「開発に消極的だ」「思うように動いてくれない」といった感情を引き起こすのだと思います。

プロジェクト失敗のその後

少し話を逸らしてしまいますが、採用管理システムのリニューアルは失敗しましたが、大元のシステムは弊社でしばらく運用を続けていました。

おかげさまでお客様にも恵まれていたものの、リニューアルプロジェクトの失敗があったことや、現在提供しているマーケティングSaaS「MicoCloud」にリソースを集中させる経営判断があったことで、昨年2021年に事業譲渡させていただきました。

会社及び自身としては今回の出来事をきっかけに、遅いながらもテックチームの重要性を痛感し、テックチームの強化に邁進しました。

その結果、国内メガベンチャーや外資系での勤務経験や経営経験のあるCTOや、国内有数のSaaS企業のテックリード、様々な豊富な経験を有するエンジニアの方々が集まってきました。

それだけではなく、ビジョナル社CTOの竹内さんやnote CXOの深津さん等を株主として招き入れ、より良いテックチームづくりができる環境になっています。

最後に

様々な記事で「Bizとプロダクトチームの関係性」について目にします。
それらの記事の多くで互いを理解する必要性や対話の必要性への言及があります。

私自身、対話することはもちろん重要で、それによって関係性の質が改善される側面はあると思っています。

しかし、本質的には「なぜ異なった考え方を持ってしまうのか？」をお互いで理解しなければどちらかがどこかやりづらさを感じ続けることになってしまうと身をもって感じました。

私はプログラミングができないため、実際に動くものがつくれるエンジニアの皆さんや、使いやすいプロダクト体験やUI設計ができるデザイナーの皆さんには頭が上がりません。

しかし、少しでも理解できるようにならなければならないと感じていますので、弊社では開発へのリテラシー向上を目的に、ビジョナルCTOの竹内さんやTHE GUILD代表の深津さんなどに色々な知見をご共有いただく時間を設けています。

今回は派手に失敗した経験のシェアになってしまいましたので、近い将来大きく成功したプロダクトを提供できていることを発信できるよう、「WOW THE CUSTOMER」を実現していきたいと思います。