システム開発会社を選ぶときには品質評価を重視しよう【2024年最新版】

システム開発の成功の指標としてよく使われるのがQCDです。
QCDとはQuality(クオリティ)、Cost（コスト）、Delivery（デリバリー）の略ですが、「Q」は納品物やサービスなどの品質を表します。
具体的には、設計時に要求された品質を提供しているか、仕様に定められた機能や性能を満たしているか、誤差や歩留まり、個体ごとの質のばらつきが安定しているかなどを表します。
「C」はコストですが、単にシステム構築の金額が高い安いというだけでなく、IT投資に見合った費用対効果があるかどうかで測られます。
「D」は納品、引き渡し、提供などが理想通りかどうかですね。

QCDのなかでも、クオリティ（Q）に関しては、発注した会社によって差が出やすい部分です。

相見積もりを取ったことのある方は分かると思いますが、きちんとしたRFP＝Request For Proposal（提案依頼書）を複数のシステム開発会社に配布して見積もりを取り寄せると、だいたい同じ水準の金額に落ち着いています。
また、納期に関しても多少のばらつきはあっても、発注側が希望として「どうしても３ヵ月後にリリースしたい」と納期を具体的に指定した場合、よほど無茶な要求でもない限り、「その納期で間に合うようにいたします」という回答が返ってくるのが普通です。

ところがクオリティに関しては、会社ごとに非常にばらつきがあります。
この原因は「品質」という評価基準が、定量的に測定しにくいということがあげられます。
見積金額（C）や納期（D）に関しては数字や期日が開発業者比較の客観的評価の基準として明確に提示されます。
しかし、品質については定量化しにくいところが多いので、業者間で大きなばらつきが出やすいというわけです。

この記事では、QCDのなかで最もコントロールしにくい「品質」について、どのように評価すればよいのかを整理し、品質評価の高いシステムを納品してくれる業者を選び出すコツについてお伝えします。

高品質な納品物は、設計の段階から途中の製造過程、最終納品前テストまで、各工程において厳しい品質評価を受けています。
決して途中のプログラミングの段階のみに高品質が問われるのではなく、要求仕様を聞き出す際の品質、要求をシステムに落とし込む設計段階における品質、そしてもちろんプログラミングを行う製造段階での品質、そしてテストの品質、納品後の保守・メンテナンスの品質と、ITシステムのクオリティを維持するためには各段階での高品質評価の維持が必須です。

品質評価と言うと納品物についてのものと考えがちですが、システム開発というプロジェクトでは発注者側の要望を形にしていくヒアリングの段階から厳しい品質評価が始まります。
特に伝統的なウォーターフォール型のシステム開発では、設計は悪かったけど、でき上がった納品物はたまたま良かったということはありません。

この段階では、いかに発注者側の要望をうまく聞き出せるかが、高品質の納品物のために欠かせません。
具体的には、そもそもなぜその開発投資を行うことになったのか、その課題についての解決方法は何かが見えてくる、システムプロジェクト開発の「目的」を明確化することが高品質の要求仕様工程では必須です。

例えば「老朽化した汎用機システムを効率化するために、オープンシステムを導入する」という目的は、現状の問題点＝老朽化した汎用機、解決方法＝オープンシステムの導入という部分がはっきりしています。

こうした、「目的」部分をしっかりと明確化するための方法については、こちらの記事もぜひご参照ください。

設計工程では、要求仕様で明確化された課題と目的をいかに的確にITシステムで解決するか、その具体的な方法に品質の善し悪しが出てきます。
一般的にこの設計段階での品質評価を図るためには、下記の指標が用いられます。

設計図の理解しやすさには、設計をした人間がシステム構築の目的と課題について十分に理解しているかどうかが大きく影響してきます。
専門用語などがあって分かりにくいという部分があれば、発注者がその部分を口頭で確認するという方法が有効です。
そうした確認作業をしても、自社のシステム構築の目的や課題解決にどうつながるのか分からない、という場合、品質は高くないと言えます。

システム開発の目的と課題点が網羅的に矛盾なく解決できる設計になっているかどうかが、完全性の指標となります。
例えば、会計システムの事務処理スピードの向上と、専門的な会計知識が十分ないオペレーターでも操作ができる、というふたつの課題は、同時に解決することが難しい場合があります。
会計のエキスパートの事務処理能力を前提とせず、既存の会計システムに比べて業務の効率化が図れることを矛盾なくうまくシステムで解決しているものが完全性を満たした高品質な設計となります。

シンプルイズベストの原則は、ITシステムの設計にも当てはまります。
そもそもITシステムの設計とは、複雑な業務システムを簡潔に整理することでもあります。
発注者の視点で複雑すぎるシステムは、エンドユーザーにとってはさらに複雑に映るはずです。
簡潔性は、特に定量的に評価しにくいところではありますが、使いこなすことに困難を感じるような設計は、いくら機能が充実していても高品質とは言えません。
不必要な機能の多さはむしろ簡潔性を損なっているので、低品質であると考えたほうがよいでしょう。

特定のメーカーの汎用機でしか動かないようなレガシーシステムは、いくらその他の指標で優れていても、もはや今の時代、高品質とは言えません。
特定のハードウェアに依拠しないシステムになっているかどうかという移植性は高品質の前提条件となっています。
また最近では、物理的なハードウェアに依存しないだけでなく、仮想化技術を前提としてサーバーやネットワークを意識しない移植性も高品質の条件とする場合も増えています。

一貫性とは、設計が記法や用語など設計の規約部分を遵守していることを指します。
プログラム言語自体は通常の話し言葉と同様に、、同じ動作をする場合でもソースコードのさまざまな書き方のクセを許容します。
しかしシステム開発の多くは集団で作業をしますので、この規約の部分に一貫性がないと隣に座っているプログラマのソースコードが読めないなど、開発の生産性に重大な影響が出るのは容易に想像がつきます。
規約の遵守の徹底は設計時間の増大にもつながりますが、品質を測る上で非常に重要です。

保守性とは、メンテナンスが容易であるかどうかで測られます。
開発業者としてはシステムを納品すれば、その段階でメインの業務は終了するわけですが、発注者側としてはシステムを納品してもらってからが業務の開始となります。
したがって、設計段階においてシステムが滞りなく動作して最小限の保守性のみ要求するシステムが高品質なシステムであると言えます。

試験性とは、各種テストが容易に実施できるという点です。
どこに不具合があるかを特定するために、コーディングされたソースコードの深い階層まで調査しなければならないという場合、試験性の品質は低いということになります。
試験性の品質が高ければそれだけ保守性の品質も向上しますし、結果的にシステムの安定稼働につながります。

主に外部設計のインタフェース部分の品質を指します。
同じ動作をさせる場合であっても、エンドユーザーが分かりやすく直感的に操作可能なシステムは、ユーザビリティの品質が高いと言えます。

具体的には「ユーザーインタフェースはGUIベースで直感的か」「クリックを要求する操作は単純か」「エラーメッセージは分かりやすく、自分で解決できる種類のものか」「マニュアルは簡単に参照できるか」などが大切です。

ここで言う効率性とは、システム稼働時にコンピュータリソースを無駄に消費しないことを意味します。
業務システムそのものの効率性は、理解可能性や一貫性などで測られます。

不正アクセスからデータを守り、悪意ある操作に耐性があることを意味します。
セキュリティと言うと、納品してから対策を立てるものだと考えてしまう発注者の方も多いのですが、認証機構、アクセス制御、暗号化などを設計段階で考えておくことで、より確実で安価なセキュリティ対策を実施することが可能です。
このあたりの詳しい解説はこちらの記事もご参照ください。

これらの指標には、定量的な視点だけでは評価しにくいものもあります。
定量化しにくい部分に関しては、発注者側が設計段階の工程を「高品質」かどうか、評価するのが難しい面もあります。
大規模なプロジェクトなどでは、設計図を提出してもらう段階までを業務委託契約で複数の業者に依頼し、その評価をコンサルタントなどに依頼するという方法もあります。

プログラミング段階で発注者が品質評価を行うことは稀です。
しかし、納品物としてソースコードの品質は高いことに越したことはありません。
品質の低いコードはバクにもつながりやすく、他の会社にメンテナンスやバージョンアップを依頼するという場合に引き受けてくれないこともあります。

コードがいわゆるスパゲッティコード（動くもののコードはスパゲッティをフォークでかき混ぜたようなぐちゃぐちゃという意味）であったり、サブルーチン、ファイル、クラス、テンプレート、ライブラリ、コンポーネントといったものが規約や標準化を無視した作りになっていたりするコードは品質が低いということになります。

プログラムが要求仕様などに従った動作するかを判定するのがソフトウェアテストです。
プログラムテスト、結合テスト、システムテスト、受け入れテストと分けて考えます。
プログラムテスト、結合テスト、システムテストはプログラミング工程のテストですので、プログラミング工程での品質評価のポイントの一部と考えることができます。

受け入れテストは、実際にシステム稼働領域にプログラムをインストールして、納品物が当初の目的に合致した機能を実現しているかどうかを確認しますので、最終的な納品物の品質評価そのものと言えるでしょう。
要求仕様がきちんと満たされているか、そのシステムで本当に業務がきちんと回るのか、テスト項目をきちんと洗い出して品質を測りましょう。

このテスト工程での品質評価は、システム開発会社を選ぶときに非常に重要なポイントなので、どのようなテストを行ってくれるのかを事前に聞いておくようにしましょう。

これまでは会社の選び方やポイントについて解説してきました。

ここからは、会社選びを実践してみましょう。

アイミツではコンシェルジュが、あなたにあった企業を選定しご提案します。

一社一社自分で探している時間がない、どのように比較すればいいのかわからないという方はぜひアイミツにお問い合わせください。

会社選びのポイントを参考に数ある企業の中から企業を選んでみてはどうでしょうか。業種・地域・特徴などから絞り込みも可能です。

企業一覧から比較・選択

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

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

以上、品質評価を軸にしてシステム開発の各工程を整理してきました。
システム開発の品質評価という言葉からは、最後の「受け入れテスト」のみを連想しがちですが、工程ごとに発注者側でも必ずチェックすべき品質基準があることをお分かりいただけたと思います。

システム開発の品質評価は見えにくく、客観的な基準を知らない、どこを品質評価のポイントにすればよいのか分からない、という発注者の方も多いでしょう。
そうしたことから品質保証についておざなりにしてしまう開発会社も多いのが実情です。
「アイミツ」に相談していただければ、発注側企業に品質評価を丁寧に伝えることを意識した、優良システム開発会社をご紹介することが可能です。

なお、最終的な受け入れテストの項目洗い出しや、テストの立ち会いなどをアウトソーシングすることも可能です。
外部業者に受け入れテストを依頼すれば、ソフトウェア品質の評価に関する国際規格である「ISO9126」に基づいたテスト観点で抽出し、テストケースを作成するところから引き受けてもらえます。

納品間際にこうした業者に声をかけるのではなく、初期の設計段階でこうしたテスト代行業者にも声をかけておけば、開発会社と共同でリスクベースドテスト、ユーザビリティテスト、機能・非機能テスト、ユースケーステスト作成を行い、品質（Q）・コスト（C）・納期（D）を意識したテスト計画を実施してもらうこともできます。

システムを納品する会社がテストをする場合、自社に都合のよい品質評価を実施してしまうという懸念もあります。
最終の受け入れテストについて、開発を担当する会社とは別の会社に依頼することでより客観的な品質の評価を実現できます。
「アイミツ」では、こうした受け入れテスト代行会社もご紹介することが可能ですので、ぜひご検討いただければと思います。