前回は、エンジニア組織をつくり、自社開発を開始するにあたって最初に考えるべきポイントとして開発言語の選定について説明しました。今回は、自社開発を進める際の「制約の理解」とそれに基づいた「適切な戦略の策定」を取り上げます。

理想と現実のギャップを把握する

新しい開発組織を築く際の理想的なシナリオとしては、無制約の環境で最高の人材を集め、強固な組織文化をつくり上げ、無限の資金を投じて最適なシステムを構築することかと思います。しかしそのような環境は、現実には存在しません。

現実のビジネスの世界にはさまざまな制約が横たわっています。これらの制約は無数に存在しますが、大きく以下の3つに分けることができます。

  • ・資金的制約：予算や投資の限界
  • ・期間的制約：プロジェクトの期限やマイルストーン
  • ・人材採用の制約：適切なスキルや経験を持つ人材の可用性

    • これらの制約を正確に把握し、それに合わせて戦略を策定することが自社開発の成功の鍵となります。

    資金的制約 - 戦略的開発を行うには?

    予算は常に限られています。特にスタートアップなど、初期段階のビジネスにとってはこの資金的制約は一層厳しいものとなります。ここでの大きなポイントは、「資金が限られている中で、どのようにして戦略的な開発を行うか」です。

    初動の鍵「MVP」

    その答えの1つが「MVP（Minimum Viable Product）」です。これは最小限の機能を持ちながら、顧客に価値を提供する製品を指します。MVPは余分な機能や装飾を省き、まずは基本的な機能のみで市場に投入します。そして、顧客からのフィードバックを基に、改良を進めていく手法です。このアプローチを実践するにあたり、近年では「Figma」や「Prott」といったモックアップツールが台頭しているため、これらを活用してモックアップやプロトタイプを作成することが有効です。

    「オズの魔法使い」アプローチ

    少し話を変えて、MVPの変化球的アプローチである「オズの魔法使い（Wizard of Oz）」をご紹介します。これは、顧客が触る部分だけを開発し、裏側は人力で支える手法です。アパレル関連の通販サイト「Zappos.com」はこのアプローチを活用した事例として知られています。同社はサービスローンチの初期段階では、注文後の管理などを全て人手で行っていました。そこまで踏み込んだアプローチを選択することはなかなか難しいですが、「初期段階での過度なつくり込みを避けること」を常に意識して自社プロダクト開発に取り組むことは重要です。

    期間的制約 - 「時間」に対する認識の統一

    新しく開発組織を立ち上げる場合、最初は具体的なプロダクトの出来上がりを求められることはないかもしれません。しかし、それが無限に続くわけではありません。初期フェーズでのチャレンジは、開発開始から組織の形成、そして最初の製品リリースに向けた明確なタイムラインを策定することです。

    共通認識の構築

    マイルストーンを設定する際には、チーム内での共通認識が不可欠です。特に開発経験が浅い組織の場合、「どのくらいの時間で何ができるか」という「時間の感覚」を統一する作業には十分な時間とコミュニケーションが必要になります。

    認識がずれやすいのは採用プロセス – 事前の考慮ポイントは?

    特にマイルストーンにずれが生じる可能性が高いのは、採用プロセスです。これを回避するには、以下の点を前もって考慮しておくことが大切です。

  • ・採用が遅れた場合、開発のスタートを延期できるか
  • ・もし延期が難しい場合、採用のための予算を増やすことはできるか

    • これらの状況に備えられるよう、計画の柔軟性やバックアッププランの確立も重要となります。

    実際に筆者も必ず「いつまでリファラル採用など、低コストで採用できる方法にチャレンジするか」「いつから採用媒体やエージェントなどを積極的に活用するか」といった内容を事前に各所と擦り合わせるようにしています。

    人材採用の制約 – 優秀な人材を獲得するための採用法

    近年、エンジニアの採用市場は競争が非常に激しい状況です。特に、優秀なエンジニアが市場に現れるチャンスは希少になっています。

    この採用の課題に対応するには、正社員採用の枠を超え、副業やフリーランスの採用も視野に入れることが効果的です。特に開発組織構築の初期段階やタイトな期間制約の中では、次のような柔軟な手法を採り入れることを筆者は推奨します。

  • ・フルタイムではない形態での採用を許容する
  • ・フリーランスのエンジニアを積極的に活用する

    • もちろん、こうした柔軟な対応が難しい状況にある企業もあるでしょう。その場合はエンジニアの採用プロセスにかかる時間を長く見積もっておくことが大切です。

    最後に、私が過去に実施したことのある採用事例をいくつかご紹介します。

    最初はサービスの申込ページを実装しない

    エンジニアリソースが潤沢ではない初期段階では、LPや申込ページのつくり込みは最小限に抑え、Googleフォームを活用するなど簡易的な方法を積極的に採り入れました。

    「概算工数」の感覚を揃える

    開発フェーズにおいて、おおよその開発工数感を伝えるシーンは多々発生します。しかし、「大体○日くらいでできそうです」といった見積もりを出す際のバッファの感覚は、開発組織立ち上げ段階では各々バラバラである場合が多いでしょう。そのため筆者は、この感覚を必ず揃えるようにします。例えば、“大体”という表現を1つ取っても、「大体1週間でできそうです（2週間くらい遅れる可能性もあります）」という人もいれば、「大体1週間でできそうです(1日くらい早くできるかもしれません)」という人もいるでしょう。それぞれ暗黙的に内包している意図が必ずあるので、そこの擦り合わせを行うよう意識していました。

    最適な選択の重要性

    最終的に、開発組織立ち上げを目指す全ての企業は、最適な意思決定をすることが必要となります。最適な意思決定とは、各企業が抱える制約と向き合いながら、その中で考えられる選択肢の中から判断することなのです。