業務システムを開発する流れとは? 図とフローで解説
システム開発の基礎知識
会社で任されている業務がいまだに紙の台帳やExcelを使った管理を行っており、いい加減システムを導入して!と思っている人も意外と多いはずです。
そんな現場からの要望を受けて社内のシステム担当者はシステムの検討を始めるわけですが、システム開発はどのように進めれば良いのでしょうか?
本記事ではシステム開発を依頼するユーザー側の担当者に向けて、今さら聞けないシステム開発の流れや開発フローについて、最も手間のかかるスクラッチ開発をベースに解説します。
1.システム開発の一般的な工程(フロー)とは?
開発するシステムの規模にもよりますが、一般的な開発工程(フロー)は以下のようなフェーズで進められます。
下図はV字モデルと呼ばれ、開発の各フェーズにおいて確認と検証が並行して行われ品質を確保するための指針となっています。
①要件定義フェーズ
「要件定義フェーズ」ではシステムで開発したい業務課題の確認、システムに求める機能の洗い出しと詳細化を行います。
基本的にシステム開発では後戻りが発生するとコスト・スケジュールともに少なくない影響を与えるため、最初の要件定義フェーズでしっかりと認識合わせを行うことが重要になります。
関連記事▼
システム開発における要件定義の進め方とは?事例から学んでみよう
柔軟な開発が出来ると言われているアジャイル開発なら問題ないのでは?と思われるかもしれませんが、要件が二転三転すると思うように開発が進まず気がついたらコストが膨れ上がっていたということになりかねません。
特にスクラッチ開発ではパッケージと異なり最初に目に見えるものが存在しないため、雲をつかむようなやりとりに終始して「思っていたのと違う」という事態になる可能性が高くなります。
「こんなの当たり前」「当然分かっているよね?」などという先入観を持たず、細かく要件を伝えることが大事です。
そのような齟齬を発生させないため、要件定義の段階でプロトタイプとして見た目や画面遷移などをイメージできるモックアップを作成するケースもあります。
②基本設計フェーズ
「基本設計フェーズ」はシステムの全体像を設計していく作業です。
要件定義で決まった機能や性能を実現するためにシステムの構造や機能を設計します。
具体的には「データの入出力」、「システム構成要素(モジュール)の設計と関係性の設計」、「データ構造の設計」、「画面設計」などです。
③詳細設計フェーズ
「詳細設計フェーズ」は基本設計を元に具体的なプログラミングに向けた設計図を詳細に描き込んでいく工程です。
各機能の実現に必要なアルゴリズムを明確にして効率的に処理されるように設計していきます。
そのほかにもモジュール間のインタフェースを明確にし、疎結合な設計を進めます。
そのほかにも重要な点として適切なエラー処理の設計があります。
問題発生時に状況を把握しやすくなるよう、エラーログの出力方法を設計します。
④単体テストフェーズ、⑤結合テストフェーズ
「単体テストフェーズ」と「結合テストフェーズ」はプログラムされたソフトウェアのテストの一種ですが、対象と目的が異なります。
単体テストはシステムの最小単位(関数、メソッド、モジュールなど)で仕様通りに正しく動作するかを検証するフェーズです。
単体テストが終了すると、次に結合テストを実施します。
結合テストは、複数のモジュールを結合(相互連携)した状態で仕様通りに正しく動作するか検証するフェーズです。
⑥総合テストフェーズ
いよいよ開発フローの終盤になる「総合テストフェーズ」には、複数のテストがあります。
「システムテスト」はシステム全体が設計通りに動作するかを検証します。
「性能テスト」では所定の負荷環境でレスポンスなどの性能要件を満たしているかを検証します。
そして「受入れテスト」では実際にユーザーがシステムを使ってみて問題ないかどうか最終的に判断します。
受入れテストで合格となればいよいよリリースとなり、長いプロジェクトも終わりに向かいます。
2.なぜシステム開発はお金がかかるのか
一般的な工程(フロー)の通り、システム開発は多くの工程を経てようやく利用開始できるようになることが分かります。
スマートフォンが普及した今、気軽に利用できるアプリケーションやWebサービスがたくさんあるため「システム」に対する価値を低く見積もっている傾向があります。
最近は仕事で使うシステムでも、月額数百円から使えるSaaSサービスなどが存在していることも影響しているのでしょう。
このようなサービスと企業が導入する業務システムのスクラッチ開発では、ユーザーの規模が大きく異なります。
業務システムのスクラッチ開発はユーザーが担当している事業に合わせて「円滑に進める」「自動化する」「見える化する」ものであり、その多くは広く大多数の人に利用してもらう目的では作られていません。
車に例えるならば、レンタカーやシェアリングカーを借りるのと、新車を自分好みにカスタマイズしたオーダーメイドカーと比較するようなものかもしれません。
3.開発の主役はユーザー側
そんな時間も工数もお金も掛かり大変な思いをして実施する「システム開発」ですが、失敗談も多く見聞きするでしょう。
場合によっては訴訟沙汰になっているニュースを見聞きしたこともあるのではないでしょうか。
システム開発側である当社は、顧客からシステム開発の工程(フロー)の中で「一番大事なポイントはどこですか?」と聞かれることがあります。
恐らく、開発関係者は口を揃えて「要件定義フェーズ」と言うのではないでしょうか。
システム開発は誰のためにやるのか?これは間違いなくユーザーです。
要件定義フェーズは決めなくてはならないことが山ほどありますが、何を決めるのか?を一言で言えば「ユーザー企業が欲しいシステムがどんなものなのか」です。
つまり、主役は恐らくこの記事を読んでいただいているあなたです。
システム開発を外注することは「丸投げ」することではありません。
ユーザー(依頼者)は明確に欲しい物を具体化して伝え、開発会社は正しく理解していることを共有し合意しなければなりません。
開発工程(フロー)の最初である要件定義でこの部分が曖昧のまま進めてしまうと、最後の受入れ試験の段階で「思っていたのと違う」「これでは業務が回らない」などといった最悪の事態を招いてしまう可能性があります。
システム開発を成功させるには間違いなくあなたの献身的な協力が不可欠です。
4.まとめ
パッケージ製品やSaaSサービスなどが拡大する中、何度も「スクラッチ開発」は時代遅れという風潮が繰り返されています。
しかし、開発手法は変わっても自社独自のシステムを持つという考えは日本国内において非常に根強いと感じています。
自社にシステムを持ちたいと考える理由には、業界や企業、事業や部門ごとに色々なパターンがありますが、それぞれに文化・作法・思考がありシステムの仕様に合わせ変化することが難しいからでしょう。
そのため、柔軟に仕様を構築・変更できる自前のシステムが必要になりますが、それを開発する主役はシステム開発業者ではなく、依頼者です。
システム開発を成功に導くポイントは「適切な要求」と「意思疎通」です。
ユーザー側と開発側で手を取り合ってゴールを目指していければと思います。