システム開発のステップを理解して外注管理を成功させよう【2024年最新版】

システム開発を外注する場合、発注者もシステム開発の種類やステップを知っておく必要があります。
発注責任者の方の中には「え？どこの業者に発注するかは大事だけど、発注したあとの開発の種類やステップまで知っておく必要があるの？」という疑問を持つ方もいらっしゃるかもしれませんが、案件ごとに最適な開発の種類を指定したり、発注したあとのシステム開発の進捗状況をチェックしたりするときにも、最低限外注先が何をどんなふうにやっているのかを把握しておく必要があります。

また、開発業者がすべての開発スタイルの経験があったり、常に最新の開発スタイルに精通していたりするとは限りません。
進捗管理だけでなく、そもそもどこの業者に発注するかを決定するときにも、案件ごとに最適な開発スタイルに対応できる業者を発注者側の視点で選び出すことが成功する外注先選びの第一歩にもなります。

現在多くの開発会社で採用されている標準的な開発ステップでは、下記のようなプロセスを踏んでいきます。

■ システム企画
システムの詳しい設計に入る前に、開発会社の営業担当やITコンサルタントは発注者側の新規システム構築に対する要望の概略や、既存システムの課題の把握・簡単な調査などを行い、その結果をプレゼンテーションします。
あるいは発注者側がRFP＝Request For Proposal（提案依頼書）を配布し、外注先候補の開発会社はそれに沿って提案をします。

■ 要件定義
発注者からの要望を聞いて、それをシステムに落とし込むことを「要求定義」と言います。
定義という言葉を使うのは「発注者の言葉をシステムの言葉で言い換えるとこうなる」という作業をするためです。
通常発注者は、システム関連の詳しい知識を持っていませんので、いくら厳密に話をしようとしてもシステムに落とし込むには曖昧な箇所が多かったり、論理的に矛盾していたり、無駄な繰り返し作業が多かったりといった特徴があります。
こうした点を明確化して、エンジニアに分かる言葉に置き換えていく作業が「要求定義」となります。
この「要求定義」がしっかりできていないと、あとの工程で致命的な設計上の欠陥が明らかになり、最悪の場合プロジェクトが空中分解することもあり得ます。

■ 概要設計
基本設計、UI（ユーザーインタフェース）設計などを行います。
ユーザーインタフェースに関わる部分が多いので、発注者も直感的に理解しやすく、自分たちの実現したいことをストレートに伝えていくためにとても重要なステップとなります。
抽象的な設計作業ではなかなか問題点が顕在化しませんが、UIベースでエンジニアとやり取りをすると「その画面構成を実現するためには、あらかじめ○○というデータの整理が必要だ」などと発注者にも分かりやすい対話が可能となります。

■ 詳細設計
先程の概要設計で決まった内容に基づき、それに必要なプログラム内部のシステム構造設計を行います。
このステップに関しては、発注者側が積極的に口を出す場面はほとんどありません。
逆に言えば、この「詳細設計」に至るまでに、自社がやりたいことを伝え、操作上のイメージのすり合わせをしっかりやっておく必要があります。

■ プログラム設計
「詳細設計」において機能ごとに分割したプログラムにつき、さらにコーディングレベルで処理手順を詰めていきます。
これも発注者の手を離れて、開発会社の内部でしっかりと詰めていく作業となります。

■ プログラミング
「プログラム設計書」にしたがって、実際にコーディングを行います。
このステップも発注者側はとくに積極的に関わることはありません。

■ プログラムテスト、結合テスト、システムテスト、運用テスト
機能ごとに分割して作業を進めていたプログラムを単体でテストしたり、各プログラムをつなげて整合性のチェックをしたり、システム全体としてテストをしたりします。
発注者がタッチするステップのテストは、実際にシステム稼働領域にプログラムをインストールしたあとに行う「運用テスト」となります。
このステップを通過すれば晴れて「納品」という最終ステップとなります。

■ 運用保守
開発、納品が終了したあとに、納品先のエンドユーザーがシステムを使いこなせるように指導したり、細かな不具合を直したり、正常にシステムが作動し続けるようにメンテナンスをしたりするのが「運用保守」のステップです。

以上が大まかなシステム開発のステップとなりますので、しっかりと把握しておきましょう。

それでは、今見てきたシステム開発のステップを、案件ごとに現場でどのように実行しているのかを見てみましょう。

ウォーターフォール型開発では、開発工程を上流工程から下流工程へと、滝（ウォーターフォール）の水が上から下へ一方向に流れ落ちるように開発していきます。
この開発手法の特徴は、あらかじめ厳密な設計を行って仕様や機能を確定させておき、前工程で仕上がった成果物を次の工程に引き渡す形で、順番に開発のステップを踏んでいきます。

１つの工程の終了が、次の工程のスタートとなる開発ステップを踏みますので、非常に分かりやすい開発スタイルですが、現在ではいくつかの課題が指摘されています。

1. 工程の「手戻り」問題

「手戻り」とは開発現場で使うIT用語で、ある作業工程の途中で大きな問題が発見され、前の段階に戻ってやり直すことを指します。
ウォーターフォール型開発では、基本的に上流工程の要件定義で必要なすべての要件を洗い出すことにしています。
しかし、発注側という立場であっても、一度でもシステム構築に関わったことがある人なら分かるように、ごく小規模なプロジェクトは別として、数ヵ月から半年、年単位にわたるプロジェクトのすべての工程を初期の段階ですべて見通すことは非常に困難です。

仮に開発者側が途中の計画の不整合をプロセスの進展の中で徐々に吸収していくことができたにせよ、外部設計などでユーザーがインタフェースの作成に深く関わった場面などでは、途中チェックの段階でユーザーから「この画面イメージの操作性は違う！」といった感想が出てくることは普通です。

こうしたケースでは、ウォーターフォール型の原則を壊して前の段階に戻って開発をやり直すことがどうしても必要になってくる場合があります。
また、部分的に前に戻るだけでなく、本番稼働寸前のテスト段階で致命的な要件不備が発覚した場合などはもっと大規模な手戻りが必要になってきます。
本番直前にバグがあったというだけならば、それを潰せばよいだけなのですが、設計そのものにミスがあった場合には、一段階前でなく何段階も前にわたって手戻りを繰り返す必要が出てくる場合もあります。

2. エンジニア確保の問題

ウォーターフォール型では、初期段階の上流工程では開発にタッチするエンジニアの数はそれほど多くなく、実際のプログラミングに入ると急に増え、運用テスト段階でまた減少してきます。
プログラミング工程では多くのプログラマー、SEを必要とすることになりますがシステム構築業界は慢性的な人手不足の状況があり、この段階で優秀なエンジニアを多数確保することが課題の一つとなります。
それができないと、集めることができた限られた人数のエンジニアで多数の工程をこなす必要が出てきて、納期の遅れや品質の低下などが起きやすくなります。

あとで解説する少数精鋭のRAD型開発の場合にはこうした点が考慮されているのですが、ウォーターフォール型は、マンパワーで開発のステップを乗り切っていくという構造的な問題を抱えています。

プロトタイプ型開発のステップの特徴は、全体としてウォーターフォール型の流れに沿いながらも、開発の初期段階でUIや機能の試作品を作ってユーザーに検証してもらうという手順を挟むことにあります。

この試作品（プロトタイプ）作りを初期段階で行うことによって、ユーザーからの「あれ？ そんなものは頼んだ覚えがないです！」というようなプロジェクトが進んでからの重大な認識違いの指摘などがなくなります。

「要件定義」の段階でかなり突っ込んだコミュニケーションが行われ、ユーザーの要件をエンジニアの言葉でしっかり定義したはずですが、いざでき上がってみるとまったくイメージが違っていたということはよくあります。
典型的なウォーターフォール型開発のステップではプロトタイプを評価するということがありませんので、「手戻り」という手法により、滝（ウォーターフォール）のように一直線に開発を流していくというステップの原則を変えて、水の流れを逆流させて前の工程に戻すという無理を行う必要が出てくる場合があります。
プロトタイプ型開発はこの点を改良したものとなります。

確かにウォーターフォール型の欠点は改良されているわけですが、まだ初期段階でユーザーに評価してもらえるレベルの試作品を開発することが必要になるために、総開発工数は典型的なウォーターフォール型に比べてかなり大きくなります。

スパイラル型開発では、全体の工程を多数に分割して、徐々に完成度を上げていくことを目指します。

「要求定義」⇒「設計」⇒「プログラミング」⇒「テスト」⇒（繰り返し）「要求定義」⇒「設計」⇒「プログラミング」⇒「テスト」⇒（繰り返し）「要求定義」⇒「設計」⇒「プログラミング」⇒「テスト」
という感じで、ウォーターフォール型を小さくスパイラルさせていくのです。

スパイラル型は、何度もテストを繰り返すので１回１回の「手戻り」は少なくなりますが、全体の整合性を管理しながらゴールのステップに導いていくことにかなりの労力を必要とします。

１回１回きちんとユーザーもテストをして満足しているので次に進める、という形を取っているわけですが、部分それぞれはよくても、全体として一つのゴールに向かって整合性が取れていないと、取り返しがつかない状態に陥ります。

これまで、「ウォーターフォール型開発」「プロトタイプ型開発」「スパイラル型開発」と見てきましたが、そのどれもが、途中段階での仕様の変更に苦慮し、なんとかそれを克服しようという工夫をしてきていることに気がついたと思います。

途中の仕様変更は、最初に「要求定義」を行って、それに従って開発を進めるという標準型の開発ステップにとってはアキレス腱のようなものです。
いっそのこと、この途中段階で仕様変更が起きることを前提として、開発ステップを組み立ててしまった方がよいのではないか？ という発想のもとに生まれた開発ステップが、「反復型開発」です。

反復型開発の特徴は、納品前になって初めて発注者に最終テストをやってもらうのではなく、全体を細かく分けた上で、小さな最終テストと小さな納品を繰り返していくというところにあります。

大きなシステムは、全体が100％完成していなくても、部分的に使い始めることができる場合がほとんどです。
例えば会計ソフトの場合も、日々の経理の伝票処理ができるようになっていれば、それを使って伝票処理業務を効率化することができます。
年末調整が自動的にできるところまでを設計段階では最終完成品としていても、年末調整は、年末にでき上がっていればよいわけです。

優先順位に従って、「今回は伝票処理部分を納品しますので、最終テストしてください」「今回は見積書と請求書の発行部分を納品しますので、最終テストしてください」「・・・・・・・・・」という段階的な納品ステップを繰り返していき、実際にそれらの納品物を使ってもらいながら、年末の最終時期に「最後に年末調整部分を納品しますので、最終テストしてください」というやり方を取れば、途中段階でユーザーの評価を適切に受けながら納品を繰り返していくことができます。

途中のテスト段階でリクエストがあればその部分を反映して納品すればよいので、「手戻り」は最小限度に抑えられます。
初期に大量の試作品（プロトタイプ）を作る必要もありませんし、多くの工程を同時並行でスパイラル式に回していく必要もありません。

以上、代表的な開発ステップの手法を見てきましたが、いずれの手法を採用するにあたっても、開発ステップを着実に踏んでいくためにはそれぞれの開発の「標準化」が重要になってきます。

「標準化」とは何かについて考える場合には、その反対の言葉からイメージするとよいでしょう。
システム構築において「標準化」の反対を意味する言葉は「属人化」です。

システム開発で行う「プログラミング」は職人的な仕事に似ていることがありますので、それを設計したり、進捗を管理したりする部分では、どうしても職人的な技や経験が必要になってくる場面があります。
プロジェクトの中に経験豊かなエンジニアが１人いると開発効率が劇的に向上したり、何か問題が起きたときに奇跡的に短期間でクリアできてしまったりすることがありますが、これは「開発ステップの標準化」という点から評価するならばそれほど望ましいことではないのです。

もしその技量の高い職人芸を発揮するエンジニアがプロジェクトの途中で離脱するようなことになってしまえば、その属人化された経験とノウハウそのものがプロジェクトから失われてしまうことになるからです。

そうした事態を避けるために、これまで説明してきた開発プロセスを「誰がやっても同じ結果が出る」という状態にまで標準化する必要があるわけです。

開発プロセス、ドキュメント規約、コーディング規約から、テストのやり方まできちんとドキュメントによって標準化が行われていることは、開発ステップを正しく先へ進める上で必須だと言えます。

開発会社を選定するときには、候補となる開発会社がこうした「開発標準化」に力を入れているかどうかを必ずチェックするようにしましょう。

webサイトなどの開発においては、プログラミングからデザインまで全体を俯瞰できるプロジェクトマネージャーの役割が非常に重要になってきますが、より専門性の高い大規模なシステム開発においては、通常のプロジェクトマネージャーよりもさらに技術に詳しいエンジニアが全体の開発ステップを管理することが大切になってきます。

こうした専門性の高い開発ステップを管理するエンジニアを「プロセス・エンジニア」と呼びます。
プロセス・エンジニアは、案件ごとにプロジェクトの特徴を深く理解した上で個々の開発プロセスを「テーラリング」していきます。

「テーラリング」という言葉は、顧客の体型や要望によって最適な服を仕立てるオーダーメイドの洋服を作る「テイラー」から来ています。
個別のプロジェクトに合わせて必要なステップごとの業務プロセスを理解して、標準化された業務内容を個々の現場に適応できるように柔軟に適応していきます。

一例を挙げれば、勘定系などのミッション・クリティカルなシステムとそうでないシステムでは要求される品質レベルが異なってきます。
当然、ステップごとの品質保証体制や作業項目の粒度も違ってきます。
ミッションクリティカルなシステムにそうでないシステムの品質基準を適応させて、開発ステップをどんどん先に進めることは許されませんし、逆に、webシステムのような素早い開発が求められているシステム開発に、ミッションクリティカルな品質を厳密に適応させて納期どおりに開発が終わらなくなるのも困ります。

プロセス・エンジニアは、こうしたケースごとの違いによって、必要な「テーラリング」を行い、案件ごとに最適化されたプロセス管理、開発ステップの円滑化を実現していきます。

専門性の高いシステム構築を発注するときには、通常のプロジェクトマネージャーだけでなく、こうしたテーラリングを行うことのできるプロセス・エンジニアが配置されるのかどうかもチェックするようにしましょう。

ここまで、代表的な開発手法の特徴を説明し、開発ステップのさまざまな局面を見てきました。
発注側としては、開発会社にすべて丸投げしてしまうのではなく、自社の案件にぴったりとあった開発手法を開発会社とともに選定することが必要です。
その上で、開発の途中のステップが正常に行われていることを適宜チェックしていくことが大切になってきます。

システム開発を、家を建てるケースを例に説明すると以下のようになります。

【システム開発のプレイヤー】
■ 施主としての発注者
自分の住みたい家の設計図を理解し、自分がそこに住むことを前提として途中の建築ステップを管理する

■ 建築士としてのシステムエンジニア
業務の仕組み全体を設計し、常に建主の意向が実現できているか図面（仕様書）をチェックする

■ 施工技術者としてのプログラマー
設計図に従って家を建てる

■ 現場監督としてのプロジェクトマネージャー、プロセス・エンジニア
標準化された建築ステップを現場に合わせて運用し、作業員（プログラマー）を指揮監督する

家を建てる例で分かるように、主役はあくまでも施主＝発注者です。
専門性の高いシステム開発では、ついつい開発会社に丸投げをしてしまいたくなりますが、家を建てるときに施主が度々工事現場を訪れて進捗状況を見学するように、システム開発においてもステップごとにどんな作業が行われているのか、発注者はもっと積極的な関心を持つべきだと言えます。

この記事の冒頭部分で説明したとおり、標準的な開発プロセスは「システム企画」⇒「要件定義」⇒「概要設計」⇒「詳細設計」⇒「プログラム設計」⇒「プログラミングプログラムテスト、結合テスト、システムテスト、運用テスト」⇒「運用保守」といったステップを踏みます。
このことはしっかり理解しておくべきですが、実際に発注者が施主の立場で開発会社と関わっていくときには、もっと単純化して「序盤」「中盤」「終盤」の３段階に切り分けてかまいません。

以下、それぞれの段階で、発注者はどのように開発ステップに関わっていくべきかを見ていきます。

システム開発ステップの序盤は、発注者の活躍すべき領域がとても多いことに留意すべきです。
実際にシステムに落とし込むのは開発会社のシステムエンジニアではありますが、既存の業務システムがどうなっていて、どんなふうにシステムを改善したいかについて重要な情報を握っているのは、もっぱら発注者側です。

つまりこの段階でシステムエンジニアのヒアリングに十二分に答えることができないと、誰のためのシステム開発なのか分からないような設計図ができ上がってしまいます。

既存業務システムの問題点の洗い出しは、現場のチームを巻き込んで行うべきです。
また既存業務システムをどう改善すべきかというより根本的な問題は、現場だけでなく、業務プロセスの責任者である上席の担当者の意見も取り入れなければならないでしょう。

序盤において発注側が手を抜いてしまうと、あとで取り返しのつかないことになりますので、「既存業務、業務改革を積極的にシステムに反映させる鍵は我々が握っている」という意識で開発会社とのやり取りに臨んでください。

中盤は、序盤に設計した仕様に従って、開発会社が開発を進めていくことがメインとなります。
しかしながら、この段階の作業を開発会社に丸投げしてしまうことは非常に危険です。
先程の住宅建設の例で言えば、南向きに大きなバルコニーが広がっていることを設計段階で何度もお願いしたのに、建築途中の現場を確認すると西向きにしか見えない、ということもあり得ます。

建築中の現場の作業員に文句は言いにくいかもしれませんが、図面と照らし合わせてもし施工が違っているのならば現場監督（＝プロジェクトマネージャー、プロセス・エンジニア）に早急に確認を取る必要があります。

先に紹介した開発ステップのうち、「プロトタイプ型開発」「スパイラル型開発」「RAD型開発」においては、発注者が製品を途中段階でチェックすることが開発モデルの中にきちんと組み込まれているので、遠慮せずにどんどん途中段階での進捗状況把握に関わっていきましょう。

終盤の段階では、完成を目指して形を整えつつあるシステムをテストすることで、最初の仕様書どおりに作られているか、実際の業務の使用に耐え得るかなどの評価を発注者主体で行っていくことになります。

テストの評価項目は開発会社が用意してくれる場合もありますが、それだけで満足しないようにしましょう。
開発会社が用意してくれるテスト項目リストはあくまでも、開発会社側の視点でシステムが完成しているかどうかを測るものです。

つまり、開発会社のテスト項目だけをクリアしても、「動くけれども使い物にならない」ということがあり得るわけです。
序盤に伝えた「既存業務、業務改革を積極的にシステムに反映させる」ことができているかどうかについて、発注者側視点に立ってシステムを評価していくという姿勢が重要です。

もちろん、その評価のために独自のチェックリストを用意しておく必要があるでしょう。
そしてシステムの評価は１人で行うのではなく、現場の複数の人間、業務プロセスの責任者である上席の人間も必ず出席してテストを行うようにすることがポイントです。

ここで、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、開発会社が開発を行うときの開発パターンや開発ステップの内容・注意点、開発ステップを成功させるための各種要件、発注者が「序盤」「中盤」「終盤」での開発ステップへどのように関わるべきか、などを解説してきました。

ここまで読み進んでいただくことで、冒頭の「え？ どこの業者に発注するかは大事だけど、発注したあとの開発の種類やステップまで知っておく必要があるの？」という疑問に関しては、「必要があるのだな…」と納得していただけたのではないでしょうか。

質の高い成果物を確実に納期どおりに納品してもらうためには、こうした発注者が開発会社に丸投げをしないという姿勢が極めて大切なのですが、開発会社の中にはこうした発注者とのコミュニケーションを苦手とする会社も少なくありません。

せっかく発注者が苦手意識を克服しながら開発会社と積極的なコミュニケーションを取って、プロジェクトを成功させようとしているのに、開発会社のほうで「我々専門家に任せてください」と言わんばかりに、開発ステップをブラックボックス化してしまうということも無きにしもあらずです。
途中の開発ステップでのミスや遅れをオープンにすることなく、最終的な納期までに帳尻を合わせてしまおうという後ろ向きな発想をベースにしている開発会社は実は少なくないのです。

「アイミツ」に相談してもらえれば、そうした後ろ向きの姿勢を持つ開発会社は除外し、発注者とのコミュニケーションを重視してくれる開発会社をご紹介いたします。

ぜひとも、業界の評判にも精通した「アイミツ」にお声をかけていただければと思います。