プロダクト開発やシステム開発の全工程ガイド ～ITサービスやアプリにおける開発の進め方、手順、流れ、段階、フロー、フェーズ、プロセス～
はじめまして。
株式会社riplaで取締役CTOを務めている寒川（そうがわ）と申します。
弊社は「事業成長に伴走するプロダクト共創パートナー」として、IT事業会社出身のBizDev、PdM、PM、デザイナー、エンジニアによる専門チームが、プロダクトの立ち上げから成長まで包括的に支援する「Product Lab」や、SaaS事業を低コスト&短期間で立ち上げる「SaaS Box」というサービスを展開しております。
私は、これまで数々のプロジェクトに "クライアントワーク" という形で携わり、大小さまざまなアプリケーションやシステムを開発してきました。本記事では、私自身の経験を基に、ソフトウェア開発の全体フローや各工程の詳細について解説していきます。
実際のプロジェクトで得た教訓や成功の秘訣も交えながら、具体的な手順や進め方を紹介します。これからソフトウェア開発に取り組む方や、さらにスキルアップを目指す方の参考になれば幸いです。
ソフトウェア開発の全体フロー
ソフトウェア開発は、プロジェクトの開始から終了までいくつかのステップに分けられます。この全体フローを理解することは、成功するプロジェクト運営の鍵となります。大まかに言えば、ソフトウェア開発は以下のような流れで進行します。
上流工程
要件定義
設計
下流工程
実装
テスト
リリースと保守
上流工程
要件定義
要件定義はプロジェクトの成功を左右する重要なフェーズです。一言で言えばどのようなシステムを開発するか決める工程ですが、ここで間違えると、この後に控える全ての工程は無駄になる可能性もある、重要なフェーズです。
要件定義に失敗しないためには、まず全体像を掴むことが重要です。どのようなシステムを開発したいのか、それはなぜなのか、どんなユーザーのどんな課題を解決したいのかを整理します。課題を抱えるユーザーについての高い理解と深い洞察を発揮する必要があります。
ここで特に注意したいのは、全体から詳細、あるいは抽象から具体の順に整理することです。もちろんシステム開発の第一歩は、具体的にこれがしたいとか、こういうことができたら良さそう、これが実現したらさらにこういう良いことがある。というような具体的なアイデアだと思います。しかし、プロダクト開発を進めるにあたって要件定義をするには、具体的すぎるアイデアは、時に本質を見えにくくさせてしまいます。要件定義の段階では、目的やターゲットを明確にするなど、発散したアイデアを抽象的なものに昇華して、全体の方向性を定めることが重要です。その上で具体的なアイデアで肉付けしていけばいいのです。
全体像を整理するステップでは、漠然とした課題感やユーザーへの提供価値についての仮説を、できるだけその背景となる知識とともに言語化し、理解した上で整理することが求められます。その繰り返しの先に、やがてサービスとしてどう表現すればいいのかという答えが見えてくるのです。
時には自分たちの知識、経験だけでは本質的にユーザーが何を課題に思っているか、必要としているかを紐解けない場合もあります。その場合はポテンシャルユーザー（潜在的にユーザーになり得る人）から直接ヒヤリングすることで本質的な価値を見出すことができます。
解決したい課題や提供したい価値についての整理が完了したら、それをシステムにどう落とし込んでいくかを定義する作業、つまり要件定義が始まります。ここに大きな落とし穴があります。
ここまでの目的やターゲット、提供価値を整理してきたメンバーと、実際にシステムを開発するメンバーは異なることが多いです。なぜならシステム開発はとても専門的な知識が必要だからです。多くのプロジェクトでいわゆるビジネス職や企画職と呼ばれるメンバーが前段の整理を行い、技術職やエンジニアと呼ばれるメンバーが後段の開発を行うことがもっぱらです。
従って、この要件定義で最もメンバー間の認識の齟齬が起きやすく、最も密なコミュニケーションが必要です。要件定義がとても重要なフェーズである理由はここにあります。
それでは要件定義の際に、なるべく認識の齟齬が起きないようにするにはどうすればいいのか。意識するべきは、対面の言葉よりも文字、文字よりも絵を利用することです。
ミーティング等で話し合って決めた内容を文字やテキストにすることで、より精緻なすり合わせができ、また後からも見返せるため状況の変化にも対応できます。いわゆる言語化です。
そして、言葉やテキストだけでなく、ワイヤーフレームと呼ばれるデザインの骨子も並行して作成しながらすり合わせることも有用です。実際に作成されるシステムのイメージを共有することで、認識の齟齬を減らすことができます。
要件定義の際に、もう一つ意識すべきことは、本当にそのデザイン、機能で解決したい課題が解決できるのか、提供したい価値を提供できるのかといった視点を持つことです。
しばしば、実際にサービスやシステムをどのようなものにするかという具体的な話に入ってくると、せっかく前段で定めた課題や提供価値を忘れてしまうことがあります。常にそういった上段の仮説を意識し、それに基づいて機能やデザインを見つめ直すことが重要です。
設計
設計フェーズでは、基本設計と詳細設計に分けて考えます。基本設計はシステム全体の大きな流れを決定するステップで、詳細設計は具体的な実装に取り掛かるための準備をするステップです。
基本設計で重要なのは、「実現可能性を検討すること」です。どのような設計であればビジネス側の要求や要件を満たすような実装が可能なのかを明らかにすることが目標となります。
どの技術を利用するか、その技術を利用することで本当にその実現したいことは達成できるのか、達成するにあたっての課題はあるのか、あるならばどう解決するのかを考えることが重要です。
基本設計は変更が多く入ります。実現可能性を検討する過程で、さまざまな課題に直面するからです。最初から完璧な設計をしようと考えるのではなく、要件定義の時と同じで、全体から詳細、抽象から具体の順に少しずつ肉付けしていくイメージで設計を進めましょう。
設計に有用な方法論として、GoogleのDesign Docsのフォーマットを活用する例も増えていますし、より具体的にはシーケンス図で整理することが有用です。最近だとNotionで管理するようなプロジェクトが増えているので、NotionのMermaidという機能でシーケンス図を作成することも多いです。例えば、あるプロジェクトでは、データフローを可視化するためにシーケンス図を作成し、下流工程を担当する開発者と共有しました。これにより、開発者全員が同じ理解を持ち、スムーズにプロジェクトを進行することができました。
一方で、実装者の経験が豊富であったり能力が高ければ、基本設計はそこまで詳細に行う必要はありません。なぜなら、経験を元に、あらかじめ課題を予想することができるので、それを解決する設計を頭の中で描けるからです。細かく設計するのは時間的なコストになりますから、能力の高い実装者であれば、設計は適当でも問題ありません。むしろその方が速くプロジェクトを進めることができます。
しかし、実装者の能力を見誤り、実際にはそこまでの能力がないのに、設計を疎かにしてしてしまうと、実装を進める中で結局設計に立ち帰らなくてはならず、手戻りが発生し、より多くの時間をかけてしまいます。時間的な猶予が十分にあるのであれば、より安全に着実にプロジェクトを進めるために基本設計をきちんと行うことを推奨します。
詳細設計は具体的な実装の設計を行うステップです。どのディレクトリ（フォルダ）にどんな名前のファイルを作成し、どんな処理を実装するのかを決めます。
詳細設計は実装者に任せるのが一般的です。詳細設計を行いながら同時に実装を進めるのが効率的です。
下流工程
実装
実装フェーズでは、設計を基にコーディングを行います。ソフトウェア開発の実装はフロントエンドの開発とバックエンドの開発の大きく2つに分けることができます。
フロントエンドの開発とは、ユーザーの目に見える部分の開発を指します。一言で言えばUIの実装とも定義できます。つまり、ユーザーがクリック、入力、スクロールなどソフトウェアのインターフェースに対してさまざまなアクションを行った時に、インターフェースをどう変化させるのかについての開発です。より分かりやすく言えば、どのボタンを押すとどんな処理が行われてどの画面が表示されるのかといった具合です。
バックエンドの開発とは、主にデータの扱いについての開発です。ユーザーが入力した情報をデータベースに保存する、ユーザーがクリックしたページに表示する情報をデータベースから取り出す。などです。
実装段階での具体的な進め方や、チーム内での役割分担については、個々のタスクをステータスごとに整理してまとめたカンバンを用いて管理することが多いです。各タスクの仕様、進捗、課題などさまざまな情報を管理することができ、またこれをチームで共有するのにとてもいい方法です。詳しくはスクラムというアジャイル開発手法について学習することを推奨します。
カンバンの管理にどのサービスを利用するかは、プロジェクトによって様々ですが、Notion、GitHub Projects、Jiraなどがあります。我々のように外部の開発会社としてプロジェクトに参画する場合は、クライアントが普段から利用しているサービスに合わせます。クライアント側で何も利用していない場合は、弊社ではGitHub Projectsが安価で機能が充実しているので採用することが多いです。それぞれのメリットとしては、Notionはビジネスチームとのコミュニケーションを円滑に進めれらる（ビジネスチームもNotionには慣れていることが多い）。GitHub ProjectsはGitHubのPull Requests(PR)と連携するのが簡単。Jiraは多機能。などが挙げられます。プロジェクトの状況に応じて適切に選定しましょう。
テスト
テストはソフトウェアの品質を保証するための重要な工程です。テスト計画を立て、ユニットテスト（単体テスト）、結合テストそれぞれ適切なタイミングで実施します。
ユニットテストとはモジュール（細かな実装単位）ごとにテストすることです。それぞれのモジュールはどのようなインプットに対してどのような処理を行いどのようなアウトプットを返すのかが設計されています。実装されたモジュールが設計通りの挙動を示すのかユニットテストを実施することで検証することができます。
結合テストは複数のモジュールを総合的にテストすることです。それぞれのモジュールが設計通りに動作していても結合して総合的に動作させると想定していなかった挙動をすることがあります。これは、モジュールの設計時点で見落としていたインプットがあったり、モジュール単位では想定通りのアウトプットを返していたとしても次のモジュールで受け付けたインプットが想定していない形になったりした場合に起こります。これらのバグを発見するためにテストを実施します。
開発者はビジネス側の強い要求に応えようとすると、実装ばかりに時間を取られ、テストを疎かにしてしまうことがあります。しかし、きちんとテストを行わないと、結局後でバグが発生し、それに対応する手間が発生し、プロジェクトの速度が上がらないという問題が生じます。あらかじめテスト計画を立て、計画的にテストを実施する仕組みが必要です。
そのために重要なポイントの一つは、テストの自動化です。手動テストだけでは見落としがちな部分をカバーすることができ、また、新しく機能を追加した時に何度も手動でテストする手間を省くことができます。
テストの自動化については、CI/CDパイプラインの中に組み込むことで、継続的にテストが実行される環境を整えられます。これにより、コードの変更が即座にテストされるため、品質の高いソフトウェアを提供することができます。具体的には、GitHub Actionsを利用して、新しくPRが出された時にテストスクリプトを自動実行し、テスト結果を迅速にフィードバックする方法があります。
リリースと保守
リリースフェーズは、開発したソフトウェアを本番環境にデプロイし、ユーザーに提供する段階です。リリース準備で特に重要なのは、開発環境でのテストと本番環境での動作確認です。実装に着手する前に、あらかじめ開発環境と本番環境をほぼ同一の環境として用意し、CI/CDを組んでおくことをお勧めします。つまり、実装と同時に自動的に開発環境にデプロイされるような仕組みを整えておくことです。こうしておくと、開発環境でのテストの完了と同時に本番環境にリリースすることができます。その上で、本番環境にリリースされたら必ず動作確認をするようにしましょう。開発環境と本番環境をどれだけ同じ環境になるように意識しても、入っているデータが違えば挙動が変わってしまう場合があります。もし本番環境で動作確認し、想定していない挙動があればすぐに元に戻す対応が必要になります。開発環境と本番環境の一致を保つには、環境の構築にTerraformなどのIaaS技術を利用したり、Dockerを用いることが効果的です。
リリース後の保守体制をどのように整えるかも重要です。リリース後のトラブル対応やユーザーからのフィードバックを迅速に反映させるための体制を整えることが求められます。例えば、サービスにユーザーからのフィードバックを得られる機能を実装しておき、ユーザーからフィードバックがあればそれをSlackに自動で流すなどの、管理・対応の仕組みが有効です。
まとめ
ソフトウェア開発は、要件定義から設計、実装、テスト、リリースと保守までの一連の流れを通じて進行します。各フェーズでの注意点や成功・失敗の経験を基に意識すべきことを話してきました。効率的かつ品質の高い開発を実現するために、それぞれのプロセスを正確に実行することが重要です。コミュニケーションを密にし、柔軟な対応を心がけることで、今後も、継続的に改善を図りながら、より良いソフトウェア開発を目指していきましょう。
改めてではありますが、株式会社riplaでは、IT事業会社出身のBizDev、PdM、PM、デザイナー、エンジニアによる専門チームが、プロダクトの立ち上げから成長まで包括的に支援しております。IT事業会社出身のプロフェッショナルなメンバーを集めているため、プロダクト成長を第一に伴走いたします。
また、SaaS事業を低コスト&短期間で立ち上げる「SaaS Box」というサービスを展開しております。
もし、
・自社事業のUI/UXの改善や開発の進行に課題を感じており、外部の力を借りて解決したい
・ニーズに応じて、コンサルティングや実行支援など柔軟に対応して欲しい
といったご要望がございましたら、まずはお気軽にお問い合わせください。