QCDを発注側と開発側で共有することがシステム開発を成功に導く【2024年最新版】

QCDとは、システム構築に限らず、さまざまなビジネスで一番重要となってくる要素の共通点を取り出したものです。
世の中にはさまざまなビジネスがありますが、結局お客様が求めるものは、「Quality（品質）の高いものを、Cost（費用）を抑えて、Delivery（納期）を守って提供する」というところに集約される、という考え方です。

共通部分を取り出して単純化した分、業界ごとに「QCD」を応用して使う場合もあります。
例えばファストフードなどでは、Deliveryに代えて Time（時間）を入れ「QCT」とする場合もありますし、建設業界の場合は Safety（安全性）を加え「QCDS」とする場合などもあります。

そしてシステム構築でも、「QCD」は非常に明確にお客様の満足指標を表現しています。

システム開発は、発注者へのヒアリングをベースとした要求定義から始まり、設計、コーディング、テスト、納品という一連のプロセスを踏みます。
したがってシステム開発におけるQCDが達成されるためには、最初の設計のときだけQCDを共有しておけばよいとか、納品が近くになったらQCDをチェックしようとかいう考え方はNGです。

システム開発成功のためには、プロセスの各段階において、発注者とシステム開発会社がQCDを意識してプロジェクトを進めることが重要です。

この記事では、発注者側が開発会社にシステム構築を丸投げすることなく、常に途中のプロセスでQCDを達成するために、コミュニケーションを取って共同作業を進めていくためのポイントについてお伝えします。

最初にシステム開発におけるQCDについて整理しておきます。

システム開発における品質の向上でよく指標として用いられるのが、ISO/IEC 9126-1に記載されている６つのソフトウェア品質特性です。
具体的には「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」を指します。

ここで言う品質が納品されたシステムだけの「品質」を指しているわけではないことに注意してください。
「機能性」はシステムそのものの品質ですが、「信頼性」「使用性」「効率性」「保守性」「移植性」はすべて納品したあとの運用、さらには更新までを含んだ品質を指しています。

品質とは納品を完了したシステムが稼働している限り維持すべきものなのです。

見積もりを取って納得して発注したあとに、コストが理由なく安くなるということは期待できません。
したがって、プロジェクトのスタート後に発注側と開発側で共有しておくべきコストとは、「予算内に収める」ということになります。

予算内にコストが収まらない、という原因は下記の３つに集約されます。

以下、順に整理します。

開発がスタートしてから予算をオーバーする代表的な例は、設計が終わってコーディング過程に入っている段階で、発注側が「こういう機能も欲しい」と次々と追加の要求をしてしまう場合です。

システム構築は目に見えない部分を取り扱うので、開発が進むに連れて発注側企業の担当者やキーマンたちの頭のなかが具体的に整理されてくる、ということはよくあります。
その結果「あ、あの機能も欲しかったのだ」とあとから気がつくケースが少なくありません。
そして、おそるおそる開発側に「実は追加機能が欲しいのですが…」と相談するたびに、コストが増大していきます。

単なるアイデアとして追加機能を思いつたというだけならば、「システム構築会社に追加費用がけっこうかかると言われたし、今回はやめておこう」ということで諦めることもできます。
しかし、想定していたコストをオーバーしても機能を追加したいという場合は、新システムに必須の機能が抜け落ちていた、というケースがほとんどです。

これは、新システムの表面的な新しさばかりに目がいってしまい、自社にとって新システムの導入がどんな意味を持つのか、その目的を詰めきれていなかったときに生じます。
目的が詰めきれていないので、具体的なシステムの活用シーンなどが思い浮かばず、あとから必須機能が抜け落ちていることに気がつくという事態に陥ってしまうわけです。

セキュリティ対策は、設計段階で盛り込んでおいたほうが安価にすませることができます。
例えば、システム開発も後半になって「社外からのアクセス時にセキュリティが守られるか不安だと上司から言われたので、対策をして欲しい」となると、すでに仕様が固まっているシステムに対して、新たにセキュリティ機能を付け加えることになります。

最初から、外部からのアクセスに関して万全のセキュリティ対策を立てたい、ということをしっかり開発側と共有できていれば、プログラム的にセキュリティ対策を施すのではなく、SaaS＋VPN接続などによって回線ごとセキュアな状態を用意するという方法も取れるでしょう。

セキュリティ対策を納品間際になって追加すると、予想しているより遥かに費用がかかることがあるので注意が必要です。

このあたりの詳しい話については、同じアイミツまとめのこちらの記事もぜひご参照ください。

先程のISO/IEC 9126-1の「６つのソフトウェア品質特性」でも確認したように、「機能性」はシステムそのものの品質ですが、「信頼性」「使用性」「効率性」「保守性」「移植性」はすべて納品したあとの運用などに関わる品質を指しています。

こうしたシステムの機能以外の品質について設計段階で詰めておくことで、効率的でコストパフォーマンスの良い品質が維持できます。
例えば、運用時に人手が５人かかるところを、システム構築の段階で半自動化して、２人で対応できるようにするだけで３人分の追加コストを削減することが可能です。

納品間際になって「そういえば、運用のこと考えてなかったのですが、御社に頼むといくらかかりますか？」と開発会社に相談するケースがけっこうありますが、運用代行にはもちろん追加コストが発生してしまいます。
プロジェクトの初期段階で運用のアウトソーシングも検討しているということを開発会社と共有できていれば、運用費用をかなり下げることが可能です。

短納期とは、システムやソフトウェア開発の開始から納品物がリリースされるまでの期間が短いことを指します。
短納期を実現するためには、開発する内容に合わせて最適な開発手法を選択することが大切になってきます。

ウォーターフォール型開発の特徴は、最初に発注者がやりたいことを伝え、開発会社がそれを設計に落とし込み、その後は基本的に後戻りすることなく、一気に滝が流れるように開発を進めて納品するというところにあります。

ウォーターフォール型の開発での典型的な失敗例は、１～４の工程で発注者がきちんと開発の目的を伝えきれずに、プログラミング以降の段階でいろいろな追加のリクエストを繰り返していくというものです。

ウォーターフォール型では、最初の設計を基本的に最後まで反映させていきますので、１～４の工程が曖昧だと作業の確認ややり直しなどで納期が遅れる可能性が高くなります。納期が遅れれば、それに付随してコストがかかり、完成度（クオリティ）も落ちていきます。

QCD達成上の重要な工程は、２番目の「要件定義」です。
なぜなら、「要求定義」で把握したユーザーの要望をしっかりと理解し、どのように実現していくのかを突き詰めていく工程になるからです。
要件定義がしっかりできていないと、外部設計以降の後工程、すべてに影響してしまいます。

プロトタイピング型開発は、ウォーターフォール型開発の１つのバリエーションです。
基本的にはウォーターフォール型開発の流れを踏襲しますが、より発注者との情報共有を重視して、細かい工程ごとに試作品（プロトタイプ）を作って、完成形のイメージにずれがないか確認しながらプロジェクトを進めていきます。

例えば、本番で使うECシステムは完了していない状態で、ショッピングバスケットに商品を入力してから最終的に注文ボタンを押すまでのインタフェースだけを先行して作成し、使い勝手の部分でイメージにずれがないか、などを確認します。
この段階ではデータベースなどは稼働している必要はありませんので、プロトタイプを作ると言っても本物と同じ環境で同じように動作するレベルのものを作る必要はありません。

もし、インタフェースにそれほどのこだわりがなく、操作しているときの体感スピードを重視したいという場合には、データベース構築を優先し、データベースにダミーデータを数万件入れてサクサクと快適に動くかどうかを試してもらうなど、発注者の重視する点を開発側が共有して、最適なプロトタイプを開発していきます。

そこで発注者側と開発側のずれが発見された場合には、すり合わせを行います。
一見するとウォーターフォール型よりも手間がかかりそうですが、プロトタイプを作らないウォーターフォール型に比べて、あとから「ちょっとイメージが違うのでやり直して欲しい」というような要望は出にくいので、結果的に短納期を実現できることも多いのです。

アジャイル型開発では、ゴールを決めながらも、そこに至るまでにいくつもの小さな完成形を段階的にリリースしていきます。
つまり、アジャイル型は最終的なゴールを1つに決めていませんので、そのゴールに向かって短納期を目指してプロジェクトを推進していくという考え方そのものがないのです。
１つのゴールの代わりにあるのは、短く区切られたスコープです。
２週間くらいで完結して、その間に製品としてリリースできるものを１つのスコープとします。
この短いスコープの連続で短納期を繰り返すのがアジャイル型開発なのです。

短納期で作られた製品は、発注者やユーザーに評価された後、開発者にフィードバックされます。
フィードバックの結果、もっと改良したほうがよいということになれば、新たなスコープで改良版の製品開発に着手します。
一定の評価を得た場合には、次に取り組むべきスコープの優先順位を発注者側と開発側で話し合います。

ここまでシステム開発におけるQCDの基本的な部分を整理してきました。
プロジェクトの最初から最後までQCDを意識して、発注者側と開発側が情報や課題を共有していくことの大切さがお分かりいただけたと思います。
それでは次に、実際にQCDを発注側と開発側と共有するために、どんなところがポイントとなるのかを見ていきましょう。

品質（Q）を上げるのも、コスト努力（C）をするのも、納期（D）を守るのも、すべて開発会社の責任だ、と考えてしまわないことが大切です。
確かに、最終責任は開発会社の側にありますが、QCDを達成するために発注者側で積極的に関与でききることはたくさんあります。

例えば、品質の向上には初期段階でのヒアリングや、要求定義などで発注者側の現状や意向をていねいに開発会社に伝えることが重要です。
場合によっては、通常の上流工程のヒアリングだけでなく、そのシステムが何故必要なのかについて、トップマネジメント層にシステム開発の目的を話してもらったほうがよいというケースもあるでしょう。

また、コスト努力について発注者がやれることはたくさんあります。
システム開発の見積もりにおいては、プロジェクトの頓挫に対するリスクを織り込んで最終的な見積金額を出すというのは常識です。
プロジェクトを推進していくことに不安要素の多いクライアントの場合には、リスクヘッジの金額が見積もりに盛り込まれることがしばしばありますが、安心感の高いクライアントの場合、その金額を最小限にすることは可能です。
例えばスムーズな打ち合わせや、プロジェクトが抱えるリスクに対して発注者側が積極的にコミットメントするなどの態度を示すことで、開発会社側ではリスクヘッジを織り込まずに、必要最小限のコストと利益で見積もりを作ってくれる場合もあるでしょう。

納期に関しても、途中で必要な打ち合わせを段取りよく行ったり、必要な資料を迅速に整えて開発会社に渡したり、テストをスムーズに実行したりするなど、開発側に協力できることはたくさんあります。

システム開発プロジェクトは、最終的にそのシステムを使うユーザーに対して、なんらかの価値を提供することが目的となります。
この目的をきちんと定義して、社内はもちろん、開発会社と共有することが大切です。

目的がはっきりしていれば、状況に応じてQCDのなかで何を優先すべきかが、間違いなく見えてきます。
例えば、「顧客満足の向上」が最終目的の場合で考えてみましょう。
ウォーターフォール型開発の初期段階で、きちんと開発側に必要な機能（Q）を伝えられていなかったとしても、最終的にそのシステムが「顧客満足の向上」に貢献するためには、納期（D）を遅らせてでも、さらに追加費用を払っても（C）必要な機能を実装すべきだという判断が下せます。

現実のプロジェクトでは「今回どうしても予算が潤沢に取れない」とか「緊急案件なので、品質よりも納期を重視して欲しい」あるいは「多少時間はかかってもよいから品質は業界で最高水準のものにして欲しい」などの「制約条件」があることもしばしばです。

こうした場合、制約条件の内容や背景など、発注者側の事情を可能な範囲で開発側に伝えることが重要です。
単に「お金がない」とか「納期が１ヵ月」とか「業界最高水準の品質」ということだけを伝えても、開発側ではその条件を飲み込むだけで、良い知恵の出しようもありません。

例えば、「予算はない」という中身を聞いてみると、ハードウェアなどのインフラに割ける予算がないというだけで、ソフトウェア的な予算にはそれほど厳しい制約はなかったという場合もあります。
開発側がそうした制約条件の詳細を正確に把握すれば、ハードウェアの投資が要らないSaaS型のクラウドシステムを利用するなどの提案が出てくるかもしれません。
また、やむを得ない場合は「QCD達成のコツ２：プロジェクトの目的の明確化」で示したような形で何を優先するか落としどころを決める必要もあるでしょう。

制約条件を共有するときには、開発会社から良いアイデアをもらえるよう、差し支えない範囲で会社の事情などをざっくばらんに相談してみるとよいでしょう。

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

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

いかがでしたか。
QCDは開発会社だけが追求するべき目標指標ではありません。
発注者が積極的にQCD達成に関わり、プロジェクトの目的の明確化、制約条件を共有しておくことで、より望ましい結果が得られることがお分かりいただけたと思います。

ただし、世の中のシステム開発会社のすべてが、こうした発注側との情報共有に積極的な姿勢を持っているわけではありません。
「QCD？なんですかそれ？」という会社はさすがにないにしても、QCDを表面的に理解して「とにかく高品質で安く、短納期でやれば満足なんですよね、努力いたします」という態度の開発会社が多いのも事実です。

「アイミツ」に相談していただければ、発注者とQCD達成のためにキメの細かいコミュニケーションを取り、制約条件なども考慮して、最終的に本来目的を達成し発注者が納得のいくシステムを作ってくれる開発会社をご紹介いたします。