お役立ち記事

システム開発の工程

要件定義からリリースまでは以下の流れで進みます。

要件定義
 ↓
設計
 基本設計
 詳細設計
 ↓
実装（プログラミング）
 ↓
システムテスト
 ↓
納品
 ↓
受入テスト（発注側企業）
 ↓
リリース

まずは設計について解説しましょう。

ます。目的は大きく2つ。一つは、システムの具体的なイメージをプロジェクトメンバー全員で共有することです。 もう一つは、エンジニアに向けて仕様を提示すること。 エンジニアは、設計書を読めばプログラミングをすることができます。

そして設計には「基本設計」と「詳細設計」があります。

基本設計

はじめに行うのは基本設計です。 基本設計では、要件定義で決まった内容をシステムに実装する機能として明確化、具体化していきます。

システムの骨組みから画面レイアウト、各機能の動作、画面から画面への遷移の仕方などを 基本設計書というドキュメントに落とし込み、発注側企業に提示します。

基本設計書は発注側企業に対して「このような仕様で問題ないか」を確認してもらうために作られるものなので、ITに詳しくない人にもわかりやすく書かれているはずです。

基本設計書の項目

基本設計書に決まった形式はありませんが、おおむね以下のような項目にまとめられます。

1. システム構成
2. 画面設計
3. 帳票設計
4. バッチ設計

1. システム構成

システム全体の構成を、図で表したものです。サーバーやネットワークなどのインフラをどのように構築するか、それぞれがどのような役割を担っているかなどが記載されています。

2. 画面設計

画面のレイアウトや、画面から画面への遷移の仕方などを図に表したものが「画面設計」です。実際にどのような操作画面になるかがわかります。

3. 帳票設計

出力する帳票各種を定義して、まとめたものです。例えば見積書や請求書、領収書といった帳票がある場合、それぞれのフォーマットと、どのデータをどの欄に出力するかなどを定義する必要があります。そうしたデータ設計をまとめたドキュメントです。

4. バッチ設計

一定量（または一定期間）のデータを一括で処理することを「バッチ処理」といいます。例えば、ブログサービスのマイページにおいて、自身の投稿ブログの閲覧数が一日一回集計されて表示されるといったような処理です。そうしたバッチ処理をするものをまとめたドキュメントが「バッチ設計」です。バッチの種類や起動時間などが記載されています。

発注側企業はこうした基本設計書の内容を確認します。双方の合意がとれると、次の詳細設計の工程に進みます。

詳細設計

詳細設計とは、エンジニアがシステムを実装するのに必要な設計図を作成する工程のことです。詳細設計書は基本設計書をもとに作られます。

エンジニアのためのドキュメントなので、発注側企業が目にする機会はほとんどないと言っていいでしょう。したがって、詳細設計書の内容を発注側企業がレビューするとか、それ自体に直接関わることは特にありません。

実装（プログラミング）

エンジニアは詳細設計書に基づき実装を行います。

システムテスト

開発が大詰めになると、ベンダーは、開発したシステムが想定通りに動作するか、システムが仕様書通りに構築されているかを検証するためにシステムテスト（総合テスト）を行います。

本番と同じ環境でさまざまな角度からテストを行うことで、開発環境ではわからなかった機能面でのバグや、ハードウェア環境の不具合などを見つけることができます。

システムテストが行われるタイミングは、開発の最終段階です。これによってシステムの品質を確保したあと、発注側企業に納品されます。

開発中に発注側企業がすべきこと

設計と実装、システムテストはベンダーが行いますが、この間に発注側企業がすべきこともたくさんあります。それぞれの工程における発注側の役割を解説しましょう。

「基本設計は、要望を軌道修正できる最後の機会」と捉えよう

基本設計の工程では、ベンダーが作成した基本設計書をしっかり確認しましょう。もし認識にずれがある場合はベンダーに伝え、解決してから先に進めるようにします。

この工程が済むと、ベンダーはエンジニア向けの詳細設計、実装へと進んでいきます。この段階になって認識違いが発覚すると、手戻りやスケジュール遅れ、追加コストの発生にもつながってしまいます。

基本設計は、発注側企業の要望を軌道修正できる最後の機会と捉え、主体的に関わっていきましょう！

詳細設計〜実装〜システムテストの期間中にも、すべきことはいろいろある！

基本設計で認識のずれをなくし双方の合意がとれたら、ベンダーは詳細設計書を作成します。 先述したように、それをもとにエンジニアは実装（プログラミング）を行います。

これらの工程の作業主体はベンダーですが、このフェーズでも発注側企業がすべきことはあります。

1. 開発の進捗を監視する

開発が計画どおりに進んでいるかを管理、監督します。

一般的にはミーティングを定期的に開き、進捗確認を行います。 その際にはスケジュールの進捗を目で見て確認できる資料をベンダーに用意してもらい、 それを見ながら報告を受けるのがいいでしょう。

2. 日々発生する課題への対応

実装フェーズに入ってからも、プロジェクトの課題は日々発生します。

一般的には「課題管理表」をベンダーが作り、その中に発注側企業への質問を記載します。 例えば、「この仕様はこれで合っていますか」「画面はこのパターンとこのパターンがあるけどどちらがいいですか」 といったような細かい問いがどんどん追加されていきます。発注側企業はそれについて回答していきます。

また、反対に発注側企業からベンダーへの相談ごとも発生するでしょう。 例えば、社内の関連部門から「当初は想定していなかったが、この機能を追加したい」とか 「この画面にこの要素がないと、使い勝手が悪い。なんとか追加してほしい」というようなことを相談されたら、 それをベンダーと調整しなくてはなりません。

「基本設計は、要望を軌道修正できる最後の機会と捉えよう」と上述しましたが、 実際に発注側企業の要求を基本設計までにしっかり固めたとしても、こうした課題は往々にして発生します。

特にプロジェクトが大きいほど、課題の数は多くなります。溜めておくとプロジェクトが進まないので、 迅速に意思決定をしていかなくてはなりません。

そこで、実装フェーズに入ってからも、課題解決のためのミーティングを定期的に行うことをおすすめします。 その場で相談してその場で解決できるよう、課題を提起するメンバーは会社を代表して意思決定できる人が出席するようにします。 自分の課題が解決したら、ミーティングから出てもらって構いません。

プロジェクトの失敗は、だいたいにおいて関係者を巻き込めないことによるコミュニケーション不足が原因で起こります。 ベンダーが、忙しい発注担当者に遠慮して時間をもらわないケースもあれば、 発注側が「もう言うべきことは言ったんだから、後はよろしく」と協力しないケースもあります。

開発会社の選び方。システム開発の失敗例・事前に知っておきたい落とし穴でもお伝えしましたが、システム開発は発注側企業とベンダーの連携なくしては成功しません。ゴール達成のためにすべての工程でベンダーに協力し、プロジェクトを進めていきましょう。

3. システムを使うユーザー目線でチェック

利用者の目線に立ってシステムに問題がないかをチェックします。開発中にもできることを1つ、ご紹介しましょう。

ウォークスルーで設計の穴を見つける

ウォークスルーとは、開発するシステムに欠陥がないかどうかを机上でチェックする手法です。 会議室に社内関係者を集め、例えば基本設計書で提示された画面遷移図を拡大して映し、 皆でシステム操作のシミュレーションをしていきます。ワイワイとカジュアルに行うものなので、 自由に意見を言いやすく、また、複数の人が俯瞰して遷移図に向き合うことで、意外な設計の穴に気付けたりします。

これまでなぜか誰も気づかなかったこと——例えば「あれ、この画面にこの数字を出すのは、流れ的に不可能なんじゃない？」 というようなこと——を見つけるのに有効とされる手法で、多くの開発の現場で用いられています。

設計書を作らずに進めるケースもある

上記で一般的な開発工程を解説しましたが、実は、小さな規模のプロジェクトでは 設計書を作らずに進めるケースも多いです。

例えば大規模なシステムでエンジニアを何百人も投入するような案件の場合は、 全エンジニアの認識を合わせるために設計書は絶対必要です。 しかし、小規模のプロジェクトでエンジニアが少人数の場合は、設計書を作らずに進めた方が、 そのぶんの工数がかからずスピーディーに開発を進められるなど、メリットの方が大きかったりもします。 この場合は、要件定義を固めたあと発注側企業とベンダー双方でコミュニケーションをとりながら開発を具体的に進めます。

このように、プロジェクトによってやり方は異なりますので、まずは一般的な工程を理解した上で、 自社に適したプロセスで進めていくのがいいでしょう。

今回のまとめ

今回は開発の工程と、開発フェーズにおける発注側企業の役割についてお伝えしました。

設計から実装まではベンダーの作業領域となりますが、発注側企業の役割もたくさんあるということをご理解いただけたでしょうか。

基本設計の工程では、設計書の内容をしっかり確認し、認識のずれがあれば解決しておく。 詳細設計と実装の工程に進んだら、進捗を監理し、発生する課題を解決しながら、プロジェクトを適切に進める。 そうした動きをしていくことがプロジェクト成功の鍵になります。

また、プロジェクトによっては設計書を作成しないケースもあります。 小規模のシステムの場合は、その必要性がないためです。

ただ、いずれのケースも発注側企業とベンダーがしっかりとコミュニケーションをとり、 認識を合わせていくことが重要です。

次回は「受入テスト・納品されたシステムの検証方法」について解説します。