アプリケーション開発手法と事業フェーズ・サービス形態との相性

多くは開示されていない各企業の開発手法

　こんにちは。本日は開発進行に関する手法に関して記事を書いていこうと思います。
　先日よくSaaSビジネスやファイナンス関連で勉強させていただいているCoral Capitalさんのツイートでスタートアップ開発環境マップが開示されていました。

スタートアップへの転職や副業を考えるエンジニアの方に向けて、Coral Family 35社の開発環境マップを作成しました。開発環境、事業内容、CEO/CTO歴、リモート/副業可否、学習環境、福利厚生、募集ポジション等を網羅。社員数3名から260名と多種多様なスタートアップが大集結!https://t.co/atO9Ktfbwl pic.twitter.com/mj7QTREB4k

— Coral Capital (@coral_capital) July 7, 2020

　開発手法や体制などは基本的にはあまりIR資料などにも公開されているものはなく、イベント登壇、Qiitaやエンジニアblogからの情報取得、経験あるPM・エンジニアが伝達したり、各社手探り開発環境に関しては模索している中で非常に面白い取りまとめでした。紹介されている企業はSmartHRさんを抜くとシード、プレ、シリーズAフェーズの企業が大半でしたので、アジャイル開発企業がメインでしたね。
　開発を行っていく中で、開発スピードに関して開発組織-非開発組織で良く議論になることがあると思います。それぞれ会社が提供しているサービス形態やフェーズによって開発に求められる質と速さが異なるので、非常にコミュニケーションを円滑に進めるのは難しいと思います。
　では開発を効率的に進めるためにはどうすればいいのか。

①開発陣の人数と質
②提供しているサービス、会社フェーズに合わせた開発手法の適応
③リリース判定（最終品質判定）方法

　この3点が基本的には重要になってくると思います。どれかのみではなく、全て揃ってやっとその企業にあった開発効率が実現できると思います。よく①のみが議題になり、海外の著名SaaSサービスのR&D比率は何%だから、エンジニアを○人くらいまで増やせばいいかななど色んな企業内で話がなされてると思いますが、

　こちらFreeeさんのIR資料から引用させていただいていますが、半期で5-6%の上下があったり、年間で30%近い上下があるので、見た数字をそのまま当てはめるのは、非常に会社運営上危険だと思います。その会社のフェーズに提供サービスによってもR&Dの割合は異なりますし、あくまで目安程度にみておくのが正しい判断でしょう。

主要アプリケーション開発手法

　アプリケーション開発の手法に関しては、プロトタイプ型（少数なので割愛）を抜くと大きく3つの手法があると思います。

Waterfall Model

JIRA Waterfall Model - JavatpointJIRA Waterfall Model - Javatpoint

　基本的には説明する必要もないと思いますが、要求定義-外部設計（概要設計）-内部設計（詳細設計）-開発（プログラミング）-テスト-運用をフローを計画をがちがちに組んで進めていく方法。メリットデメリットを加味すると、受託型の開発の際に結構利用されていると思います。

Spiral Model

「アジャイル」と異なる反復型開発「スパイラル」とは | バンブロ！ソフトウェア品質特集

　開発する機能の方向性を明確に決め、機能ごとにプロトタイプを作成し、プロトタイプの検証・改良を繰り返して完成形に近づける方法。反復するところに関してはアジャイルと同じだが、プロトタイプ自体が品質を保証していないので、ユーザーからのFBを対応しすぎていくと、開発コストが高くついてしまうのがデメリット。意思決定者が明確で計画を重視する場合は、良い方法かもしれないが、あまり普及はしてないように思えます。

Agile

　現状ベンチャー企業やIT企業で多く採用しているのがアジャイル開発方式だと思います。計画性よりも品質担保、開発スピードを目的として、最初の要件定義は最小限にとどめて、機能ごとに設計→実装→テストを細かく繰り返し、プロジェクトを進め流方法です。
　アジャイル方式は「スクラム」、「XP」、「リーン」「カンバン」など種類もたくさんあります。

非ウォーターフォール型開発（プロトタイプ型、スパイラル型、アジャイル型）をざっくり理解する - Qiita

　アジャイル方式自体のデメリットとしては、「計画に合わせることが困難」があると思います。事業計画上、いつまでに売上を立てて、いくらの売上を上げなければいけない、という事業計画に対しての予実管理が非常に難しい場合は、納期コントロールが難しいためそのまま適合すると会社運営に影響を与える可能性があります。
　また、直近だとベンチャーから事業規模が拡大し、組織が拡大していく中で、スクラム形式を組織拡大に合わせて拡大していくLeSSなどが注目されてます。

What is 『LeSS (Large-Scale Scrum) 』

事業フェーズ、サービス形態との相性

　色々開発手法に関して話をしてきましたが、メリットデメリットなども伝えた通り、事業のフェーズやサービス形態によってもハマる方式は変わってくると思います。

①サービス形態（意思決定者の多・少）
-エンタメ向けtoCサービス（ゲームなど）
　→初期は意思決定者がPOやプロデューサーなど少数。後期はサービスによって拡大するかは異なる。
-エンタメ以外toCサービス（ライフスタイル系）
　→初期〜後期にかけて多くのユーザーから意見を取り入れる
-テックタッチなSaaSサービス（個人も対象）
　→初期〜後期にかけて多くのユーザーから意見を取り入れる
-ハイタッチなSaaSサービス（大規模法人が対象）
　→初期〜後期にかけて一定のクライアントから意見を取り入れる
-クライアント向けの受託開発
　→初期〜後期にかけて一定のクライアント担当者から意見を取り入れる

②事業フェーズ（計画性の困難さ）
-〜シード、アーリーフェーズ
　→予実管理がそれほど難しくない
-シリーズB〜フェーズ
　→予実管理をしっかり行う必要がある
-事業拡大、運用フェーズ
　→資金や事業が既に多角化しているため、会社全体での予実管理が必要。

　これを掛け合わせることで、ベースになる開発方式を決めたり、組み合わせをしたりしながら、会社や事業にあった開発方式を模索するのが良いかなと。最終のリリース判定に関しても、一定の個人が判断するものになるのか、大多数のユーザーの意見を取り入れながら反映していくのか、これも開発効率に影響が出るポイントになると思います。

ex.テックタッチなSaaSサービス（個人も対象）×事業拡大、運用フェーズ

→一定の売上規模とユーザー規模を実現している為、顧客の意見のみにフォーカスし、いかにスムーズに迅速に対応するかが求められるのでアジャイルかつDevOps的な開発-運用を強固にしたスタイルでいくなど。

終わりに

　弊社も事業フェーズが変わっていく中で、開発手法を色々組み合わせをしたりしていますし、一緒に事業を拡大してくれる開発メンバーの募集も行なっています。テックメンバーによるblogは下記。
　是非、VIDEO BRAINの開発にご興味ある方は気軽にご連絡ください^^

OPEN8テックブログ