要件定義とは、何に対応するかの作業範囲を決めることである。したがって、お客様との会話を経て開発すべきシステムの開発要件を決めていく行程のことを指す。設計とは、システム要件定義を基にシステム開発を行っていく上でのシステムの構成や仕組みの定義のことである。
この記事では、システム開発プロジェクトの発生から、実際の案件化までのプロセスについて解説する。
システム開発プロジェクトの発生
システム開発プロジェクトの多くは自然発生しない。それは、システム開発に対するニーズの多くが顕在ニーズではなく潜在ニーズである場合が多いためである。
地方企業では、上場企業のように作り込まれたウェブシステムを使い込むことで効率化された事業を展開しているようなケースはほとんどないため、ウェブシステムの利用経験がある方が恐らく多くないことが想定される。そのため、ウェブシステムに対して「あったら便利だろうな」とか「開発してほしい」と言った要望があがらないケースが多いと想定される。つまりウェブシステム開発プロジェクトをつくり出すためには、ウェブシステムに精通した人物がニーズを顕在化させるための掘り起しから行っていく必要性が高い。
また、ウェブシステムを活用した結果得られる状況とは、上場を視野に入れる場合を始めとした拡大を志向する場合以外にメリットが少ないため、経営者の志向性によりウェブシステム開発を行うか否かが分岐する。つまり、事業を拡大する気のない企業にとっては、数百～数千万円を投資をしてまで業務効率化を行うメリットを感じていないため、ウェブシステム開発プロジェクトが発生することはほとんどあり得ない。
ただし、コロナ禍においては、リモート環境でのビジネス構築の必要性に駆られて、ウェブシステム開発に着手しようとする会社も一定数存在しており、それらの会社は多くの場合、これまでシステムについてほとんど意識してこなかったため、どこに依頼して良いかわからないことも多いことが想定され、比較サイトなどのビジネスマッチングサービスを介してシステム開発プロジェクトが具現化されていくケースが最も多いと言えそうだ。つまり、システム開発プロジェクトはビジネスマッチングを利用することで最も効率的に受託に繋げることができる。
概算見積と補助金の活用
システム開発プロジェクトが発生すると、まず一番最初に要件のヒアリングを行う必要性が出てくる。概算見積は通常数時間から数週間以内に作成することが多く、概算見積を通して、該当プロジェクトの対応範囲を定義する。プロジェクトの対応範囲を定めることをスコープマネジメントと呼び、プロジェクトマネジメントにおける領域の1つとして、案件の旗振りを行っていく上での重要な視点のひとつとなっているため、見積に含める作業内容の定義は非常に重要である。
また、システム開発プロジェクトにおいて、フレームワークなどを使って概ねゼロベースからシステムを構築することをフルスクラッチ開発と呼び、フルスクラッチ開発の場合は、当社の場合でも予算感的に1人月の工数で80万円程度からのスタートとなる。システム開発プロジェクトにおける要件定義、設計、環境構築、実装、テストと長期でプロジェクトを運営する必要性が多いことから、予算感的にチームで開発を行う場合には、簡単に数百万円以上の予算に達する場合が多い。
また、初期開発費として計上する予算以外に、開発完了後に機能追加や機能改修を行えるだけの予算を事前に計上しておくことが非常に重要である。これら保守・開発予算を計上できない場合には、開発が初期開発完了時点でストップしてしまう場合も少なくない。そのため、初期開発費と開発完了後１～２年分の保守費用を事前に見積もっておき、経産省旗振りの大型の補助金（モノづくり補助金や事業再構築補助金など）で資金を担保しておくと、資金面では後々かなり楽になる。そのため、開発すると決めた場合であれば、思い切って予算を確保し、補助金を大幅に獲得するような動き方をした方が長期的に見た場合に得をする場合が多い。
最低限の投資で済ませようとするのではなく、成果を出すところまで改善を繰り返しながら、成果までたどり着く必要があるという感覚を持てるかどうかが非常に重要である。実際に自社が請け負っている開発案件についても、この流れで営業を行っており、補助金を有効活用した上でシステム開発に繋げていく想定で営業活動を行っている。
業務フローの整理
概算見積をお客様に提出し、概ねの要件と定義していく行程の中で、実際の業務の流れを詳細に把握する必要がある場合は、概算見積前に業務フローの整理を行う場合もある。業務フローの整理を行うためには、業務フロー図やユーザーストーリーマッピングなどの手法を用いて、業務の流れの把握に努めることが重要である。
これらの手法を用いて、業務の流れを明確にできれば、システム化の範囲を詳細に定義することが可能であり、機能定義に繋げることができる。これによって、システムの画面構成や各画面で行うべきユーザーの操作、システムが行う処理の内容などをあらかじめ想定することが可能になる。業務フローの整理により、システム化の範囲が明確になるため、業務フローの整理行程で作成した各種図表は詳細見積を作る上での材料となる。
業務フローの整理を行う上でのポイント
業務フローの整理を行う上でのポイントは、登場人物を明確にし、主語と述語を明確にすることである。これによって、どのような文脈で誰（何）が登場し、どのような動作を行うかを明確にできる。条件分岐などのパターンも明確にする必要があるため、レビュー会による議論を重ねることで、漏れがない状態を作り込んでいくことが必要である。
システム構成の整理
システム構成の整理では、サーバー・インフラ環境をどうするか、開発言語やフレームワークとして何を利用するか、どのようなアプリが存在するかなどを定義する。これによって、開発しなければならないシステムの全貌を把握するために役に立つ資料を作成することができ、全体のボリューム感を把握するのに役に立つ。
概念構成の整理
概念とは、システムを構成するデータ交換やデータ保存の単位である。受発注のシステムにおいては、案件、受注、取引先などの概念が登場するし、ECサイト（ネットショップ）のシステムにおいては、受注、商品、決済などの概念が登場する。業務内容によって、登場する概念は異なるため、最適なシステムの設計を行っていくことが必要であり、最適なシステムの設計を行うことによって、効率的な処理を実現するためのシステムを構築することができる。ウェブシステム開発において整理しておくべき概念の要素としては、データとプログラムの2つが存在する。
データ設計
データの取り扱いとしては、プログラムでやり取りをするためのデータの形であり、最終的にデータを永続化するための入れ物であるデータベースの設計を行う必要がある。データベースの設計を行う上で作成するER図（ERD）により、各データベーステーブルが持つ列（カラム）や関連（リレーション）の定義を行うことができる。またER図を作成することで、データベースの構成や関連が見える化されるため、単なるテーブル定義書を作成するよりも、イメージを醸成する上では非常に役立つ資料となる。必要に応じて作成するようにしたい。
プログラム設計
プログラムの取り扱いとしては、データをプログラム上で取り扱う上で、プログラム上のクラスという概念として扱うことになるため、クラスの設計を行う必要がある。クラスは、メンバー変数とメソッドからなり、各クラスが持つべきデータの形と振舞いとしての処理の内容を定義することができる。データの設計とクラスの設計により、プログラムがデータを扱うことができるようになり、ウェブシステムを構築していくことが可能となる。UMLにおけるクラス図等を作成することで、クラスの構成が明確になるため、設計行程に余裕がある場合には、クラス図の作成なども視野に入れていくと良い。
UIUXの整理
UIとは画面のことである。UXとは、各画面を利用するユーザーの体験のことである。これら画面およびユーザー体験を設計することをUIUX設計と呼ぶ。UIUX設計には、Adobe社のXdやFigmaなどのツールを利用することが一般的である。旧来には、画面設計と呼ばれる行程であったが、最近ではUIUX設計と呼ぶのが一般的になった。UIUX設計では、画面構成を考え、各画面の設計により画面内の要素を定義する。その上で、各画面で実行できる動作・動きの定義を行っていくことにより、各画面での体験を明確にしていくことができる。動き・動作を表現するために、Xd等のツールの機能を利用することもできるし、テキストでどのような動きをするかを明確に記載していくことで、詳細を詰めていく必要がある。
UIUX設計を行う上で、一般の方が利用するシステムの場合には、画面のデザインをデザイナーが作成することが一般的である。逆に、業務システムとして、社内でしか利用しないシステムの場合には、エンジニアが簡易的にデザインする場合がほとんどであり、画面設計時の予算を圧縮することが大きなKPIのひとつになる。XdやFigmaを利用してデザインを行うと、プロトタイプとして実際の画面がどう動くかを見ることができるため、お客様確認の際に、実際の動きを確認してもらいながら要件を詰めていくことができる。
詳細見積
詳細見積は、これまでに設計を行ってきた業務フロー・概念・UIUXの各設計を基に、システムの詳細要件を定義して、実際に開発する内容を完全に定義し、一旦はその内容を開発しきるまで要件が変更できないという状況を作る。これによって、詳細の作業行程が明確になり、詳細の開発予算が算出できるようになる。それでも、ある程度の仕様変更が出ることが通常なので、できる範疇で仕様変更を受け入れながら開発を継続していくことになる。お客様が納得できる範囲で仕様変更を最小にしつつ、まずはシステムのリリースに向けて最短期間で開発を進めることが重要である。
詳細見積における開発工期
開発工期については、最長でも半年程になるように予算とスケジュールの調整を行うことが一般的である。事業環境は刻一刻と変化を続けていくため、半年以上の期間が空いてしまうと状況が大きく変わってしまう可能性が高いためである。設計書の作成だけで数か月間を要する場合には、設計書の作成をスキップすることも検討し、成果物の作成と作成後の機能改修に予算を割けるようにした方が高い生産性を発揮できる。
半年間の工期に収めるために、開発メンバーを多数アサインすることも考えられるが、開発チームの人数は多くても3~4人程度にとどめておいた方が開発効率上効果的である。開発メンバーの数が増えるとコミュニケーションコストが増大し、必要予算の割に開発速度がそこまで向上しない状況に陥ることがある。開発プロジェクトのコアメンバーとなる数名に絞ってメンバーをアサインし、開発プロジェクトを推進していくことで、必要なコミュニケーション量を最小にとどめつつプロジェクトを推進することができる。
開発予算
なお、半年間での概算予算は当社の場合は1000万円が目安である。1000万円の予算があれば、最初の3~4カ月間で迅速にプロトタイプを開発し、その後数か月間にわたって機能改修を行えるだけの予算を十分に確保できる。補助金を活用することで、お客様の支払総額を500～600万円前後に抑えることができる。これらの金額を捻出できないお客様の場合には、システム開発プロジェクトの成功が難しくなる旨を十分に伝えていく必要がある。システム開発プロジェクトは点ではなく、線で考えたほうが成功に近づくため、継続的な機能改善と向き合う必要があるためである。