【発注者向け】開発を発注する際に押さえておきたいシステム開発の流れ

既存のシステムをリニューアルすることになった。しかし、その時の担当者はもういなくて、その際に開発してもらった業者とも付き合いがない。
 
上司から新しくこういうシステムを作れば業務が効率化できるのではないかと言われて業者を探そうとしている。
 
しかし、システム発注なんてしたことがないからわからないから不安だという方もいらっしゃるのではないでしょうか。
 
でも、開発会社はプロなんだから丸投げで大丈夫でしょ、、、と思っていたら大間違い。
 
そのようなスタンスだと、大げさではなく、伝えたことの3割くらいしかできない、またはそもそも完成しないと思ってもらってもいいくらいです。
 
もちろん、発注者側は開発者ではないのでなんでも覚える必要はありませんが、知っておくだけで未然に回避できるシステム開発を頼む上でのトラブルもあります。
 
そこで今回は

 
を中心に発注者の視点でできる限り使える知識と本音を交えながら、知っておきたい開発の流れや専門用語について説明したいと思います。
 
 

システム開発の流れを少しでも理解しておくと発注後もトラブルを減らすことができてスムーズになるため重要です。
 
ただ、少し覚えることが多いので、できるだけ細かなことを覚えるというよりも開発の意味を理解してもらった方が良いと思います。
 
ここでもできるだけ意味の理解を重視して説明していきます。
 
システム開発の流れはなぜ重要なのか。これはシステム開発の商品特性にあります。
 
パソコンやテレビにはスペックや説明書があり、パソコンやテレビでどのようなことができるのか理解できます。
AさんもBさんも買う商品は同じです。
 
システム開発はどうかというとパッケージなどの既製品を除いては、あなたの要望に対してのオーダーメイドの商品になります。
 
だからこそ、ある意味では正確に要望を伝えるということは説明書を作るようなものなのです。
そうでないと、正確にはこれだけの要望を満たすには費用はいくらかかりますであるとか、製品の受け入れもできないのです。
 
システム開発の工程・流れがなぜ重要で難しいのか。
 
私たちはこういうことをやって欲しいです。
 
これを漏れなく伝え、その後、開発に入るわけです。
 
 
こういうことをやって欲しいという頭の中で思っていることは各人でバラバラです。
 
お客様の中でも上司が思っていることも、発注担当者が思っていることも、開発をする窓口が思っていることも、開発するエンジニアが思っていることも全員が思っていることは異なるのです。
 
そのため、各人で思っていることを認識をあわせていき、認識のズレがないようにシステムを作り、テストを行い納品をするという一連のプロセスをどこのタイミング（工程）で誰が何をどうするのが正しいのかを理解することでシステム開発がスムーズにできるわけです。
 
そのためにシステム開発の流れ・工程を理解することが大事になります。
 
 

システム開発の手法にはいくつかやり方があります。
一長一短ですが、代表的なものが、「ウォーターフォールモデル」と「アジャイルモデル」です。
 
 

ウォーターフォールモデルとは、上から下に水が流れるように工程を進め、水と同じように一度下に水が流れると上には戻れないように、工程を一度進めると後で戻すことはできない進め方です。
 
工程A→工程B→工程Cと一つの工程ごとに進めていき工程Aが終わったら工程Bに進めますが、工程Bでやっぱり工程Aで話してたあの話はやめてこうしたい、みたいなことができないということです。
 
これだけ聞くと柔軟性がない進め方のように思われるかもしれませんが、一番メジャーであり、他の開発手法でも大なり小なりこの考え方は取り入れられてる一番ベーシックな進め方だと思います。
 
 

 
アジャイルモデルは、アジャイル＝「素早い」という意味からわかるようにスピードを優先した開発の手法です。
 
ウォーターフォールモデルが一工程ずつ順番に進めていくのに対して、アジャイルモデルは開発→テストを繰り返しながら、修正しつつ進めていくのが特徴です。
ウォータフォールモデルに比べ、途中の変更を吸収しやすいという柔軟性が高いのが特徴です。
 
 
ここではシステム開発の手法として一番メジャーなウォータフォールモデルの説明をしていきます。
 
 

ざっくり説明すると、、

 
となります。
 
これらの言葉は定義や意味合いが微妙に違っていたり、ややこしいことに言い回しが違う言葉だったりするためなおややこしいですし、どこまでの範囲で説明するかでも違ってきます。
 
細かく定義していくと以下とも言えます。

 
細かくしようと思えばもっと細かくもできます。
 
発注側としては大まかな流れがわかり、どこのタイミング（工程）で誰が何をどうするのが正しいのか、それはなんのためにするのかを理解しておけばよく、細かな定義の理解は専門家でもない限りは不要でしょう。
 
システム開発はプログラム・システムという目に見えないものを扱うために開発の流れというものがわかりにくいという側面があります。
ここではざっと流れを理解するために目に見えてわかりやすい家やビルを建てることに例えます。
 

RFP(Request For Proposal)とは「提案依頼書」のことです。
IT系の開発業者ではメジャーな言葉です。
 
要望や目的、納期などをまとめた資料のことです。
 
私自身も東証一部上場の開発会社に在籍していたことがありますが、RFPがお客様から出てくることはめったにありませんでした。
 
きっちり書こうとすると大変ですし、書けるような会社でしたら、恐らくは情報システム部があり、ある程度は自分たちで開発できるような企業だと思います。
 
あった方がトラブルが減りやすいなどとRFPについては説明されていることはありますが、RFPがあればトラブらないかというと私の経験上はほとんど関係ないかなという感想です。
 
RFPがあろうが、なかろうがトラブる時はトラブります。
 
むしろシステム開発がうまくいくかどうかは頼む業者のプロジェクト管理能力の方が圧倒的に大きいとは思います。
 
ただ、だからと言って、RFPが全く不要だというつもりはありません。
要望事項を口頭で伝えるのみという形ではなく、形式はメモ書きでもなんでも良いので書面でまとまっていた方が開発側としては進めやすく、助かります。
 
 

例えば、何か一戸建ての家を建てたいとします。
建築士、設計士と家に関する要望を打ち合わせをしながら伝えますよね。
和風の家にしたい、庭に池が欲しい、和室が欲しいetcです。
 
システム開発でも同様です。
 
ざっくり言うとあなたの要望をシステム開発の観点からまとめるという工程です。
 
開発行者と打ち合わせをしながら、その要望をまとめるということです。
 
基本的にはなんらかの資料でまとめるのは業者側で行い、その資料をもとにお客様と業者の間で認識合わせをします。
 
後から言った言わないの話にならないようにするためです。
 
発注者側としては形式にはこだわらずに箇条書きでも良いので要望を一覧にしたり、既存のシステムのリニューアルなどであれば可能な範囲で情報開示をするとスムーズです。
 
要件定義は、機能要件、非機能要件とあります。
 

などです。
 

システムの機能面以外の要件ですが、通信速度(パフォーマンス)やセキュリティーなどに関することです。
 
思ったようなシステムができても、とても遅いシステムだったり、顧客情報が漏れやすいシステムだったら嫌ですよね？
 
そう言ったことを決めるということです。
 
ここはお客様側からこうしたいとは難しいため伝えにくいかもしれません。
こういう場合には業者側にパフォーマンスやセキュリティーなどの非機能要件は今回作りたいものだったらどういうことが考えられますか？と教えてもらうのが良いと思います。
 
ただし、ここの領域はこだわりだすと工数＝費用がかさむため、予算に限りがある場合には、業者の話を聞きながらある程度の妥協は必要かもしれません。
 
 

基本設計は外部設計と言うこともあります。
 
要件定義で決まった内容をもとに画面や帳票など主に目に見える箇所、システムとユーザーとの接点(ユーザーインターフェース)を設計する工程です。
 
家の例で説明しますと要件定義で和風な家、庭に池、和室と言われても、池のサイズや深さ、和室と言っても畳があれば良いだけなのか、ふすまや障子が必要なのか、何らかの木を使って柱を見せたりするのかなど、細かく決めないといけないことはたくさんあります。
 
システムでも同様です。
 
顧客情報を登録できるようにというのもどういう項目を登録できるようにするのか、どのような見た目の画面にするのか、などそういったことを詳細に決めていくという工程です。
 
 

ここは家に例えると大工さんが作る工程です。プログラマーがシステムを作るイメージです。
ここはわかりやすいですよね。
 
家でも同じですが、大工さんは大工さん用の作るための設計がないと作成はできません。
 
システム開発においても基本設計(外部設計)後にすぐ作れるかというとそうではなく、開発者用の設計を行います。
 
内部設計という開発するシステムの内部の動作、処理、データなどの設計を行い開発するための設計を行います。
 
「機能仕様書」「データフロー図」「 データベース物理設計書」などを作成します。
 
こういう開発者向けの設計については発注者側は関与することはありません。
 
ただし、作っているうちに？？？みたいな設計漏れが見つかることがあります。
 
そういう場合には発注者側に再度認識合わせを求められることがあります。
 
 

ここは家とは異なります。
 
家は建てられたら、何もテストすることなくそのまま住むと思いますが、システムというのは処理や動作を伴うものであるため、決めた要件・仕様通りに動くかどうかをテストする工程が必ず発生します。
 
テストについても細かく分けるとフェーズわけができるのですが、ここで発注者側にとって大事なのは受け入れテスト（ユーザーテスト)です。
 
業者の方で決めた要件・仕様通りに動くかどうかはテストを行なった後に、発注者側の方でもテストを行い、要件・仕様通りにシステム開発が行われているかどうかを確認します。
 
受託での開発の場合にはこの受け入れテスト（ユーザーテスト)で合格の判定をすることで、契約通りの開発が行われたということになりますので、しっかりと発注者側でも確認を行います。
 
業者側では以下のようなテストを行なっています。
 

 
分割されたプログラムが動くかどうかのテストです。
 
 

 
単体テストが終わったもの同士を連携したテストです。
 
 

 
 
発注側の環境でのテストです。細かなことを言うと同じ環境ではできないこともあるため、できる限り発注者と同じ環境にしてテストを行うこともあります。
 
業者側での最終的なテストです。
 
ここまで終わった後に受け入れテスト（ユーザーテスト)で発注者側にも確認してもらうという流れになります。
 
 

テスト後は本番環境にリリースをします。
何らかの不具合がリリース後に出てくることもあります。
瑕疵担保の期間は不具合の対応が行われます。
 

瑕疵担保期間後の不具合対応やコンテンツ追加、改修などをリリース後に行う場合には別途で保守・運用の契約を行います。
 
瑕疵担保というのは一定期間不具合があった際に無償で対応する契約内容を指します。
 
開発の依頼を行う際に合わせて、保守・運用をどうするかを決めておき同時に契約をするか、リリースの少し前に保守・運用の契約も行うことが多いです。
 
 

ここで現場の本当の話をします。
 
実際の現場でこんなに工程をきっちり進めているのかというとそれはNOです。
 
案件にもよりますが、細分化された細かな工程をその工程通りに進めるということをやっていると、時間もお金もかかって仕方がないというのが本音です。
 
ただし、工程を飛ばすのではありません。効率よくやることが大事です。
 
私も長年の経験があるから効率よくできていると言えます。
 
開発の経験が浅かったり、これまで書いて来たような正しい開発フローの流れを理解していないと効率よく進めるということはできません。
 
こういう効率性は最初から求めるというよりは正しい開発フローの理解し、長年の経験があった上でできるやりかたと言えます。
 
また、効率重視なやり方をすべきかどうかは開発するシステムにもよります。
 
例えばですが、ECなど課金機能があるようなもの、金融機関など社会的に影響が大きいものなどは効率重視ではなく、工程通りに進めた方が良いです。
 
開発するシステムの目的によりますし、リスクをどう捉えるか、またリスクが発生した際の影響度を考えるリスクマネジメントの領域と言えます。
 
実際、自社サービスなどの開発の場合にはこういう杓子定規に工程通り進めるというスタイルは、その目的から考えると向いてないと思います。
 
こういうバランスを考えながら、案件にあわせた進め方ができる開発会社は数が少ないですが、良い開発会社だと思います。
 
また大手の開発会社に在籍していたことがあるのでわかるのですが、大手の場合には未然にトラブルを防ぐという観点から社内で工程通りに進めているかチェックするような部署があります。
 
こういう部署が存在していることはある意味安心感を持つかもしれませんが、柔軟性にはかなり欠けます。
 
また、裏でこれだけの人間が動いているということは開発費用もかなり高くはなってしまいます。
 
また、だからトラブルがないかというと、結局は担当者の腕次第だなという感覚です。
 

いかがだったでしょうか。
 
開発を発注する際に押さえておきたいシステム開発の流れについてここまで説明してきました。
 
まずはここで説明したような工程やその意味を理解することが大事です。
あくまでも開発者側ではないので細かなことを覚えるというよりは意味を理解した上で開発業者と会話できて、相談できるようになっていれば良いと思います。
 
システム開発に関してお悩みであれば私たちにご相談ください。
 
確実にメリットがある情報をご提供させていただきます。