システム開発の手順の中で、品質管理はどう進めていくべきなのか？【2024年最新版】

システムには「組織・体系・方法・手順」という日本語の意味があります。これを「企業のシステム」に置き換えるのであれば「企業における業務の方法・仕組み」ということになるでしょう。つまり、システム開発とは個別企業に最適化された「業務の仕組みを開発」することであり、今日では、業務の仕組みに沿ったコンピュータープログラムの開発を意味することがほとんどです。

ERPなどの業務システム、在庫管理システムからECサイト構築まで、現在も業界や業種によってさまざまなシステム開発が行われていますが、いずれの場合も、既存業務の改善・効率化・最適化、もしくは新規事業の仕組み・手順を構築するのが目的だという点では共通してるといえるでしょう。

この目的を達成するためには、発注企業自らが業務の方向性・仕組みを整理し、どんなシステムを構築したいのか？どんな機能が必要なのか？を明確にしたうえで、開発を依頼する制作会社とコミュニケートしなければなりません。これが「要件定義」であり、一般的なシステム開発で真っ先に行われるべき、開発への第一歩です。

要件定義によって定められた「仕様」に従って開発されるシステムは「基本設計」「詳細設計」「実装」「テスト」という手順を経て納品され、運用されます。しかし、最終的にできあがったシステムに対し「想定していたものと違う」「仕様が反映されておらず使われないシステムになってしまった」「納期が大幅に遅れた」「予算を超過してしまった」などの不満を感じることも少なくないでしょう。

これらの不満を大きく分類すると「品質」「納期」「予算」に集約されることに気付くのではないでしょうか？品質・納期・予算のすべてが満足されて、はじめてシステム開発が成功したといえるのは明らかですが、なかでも重視しなければならないのが「品質」です。満足のいく品質が完成しなければ、納期が短縮できても費用を予算内に収めても、システム開発が成功したとはいえないからです。

それでは、システム開発を成功に導くために、開発中のシステムを、企業自らが品質管理していく方法はあるのでしょうか？もちろん、実際のプログラミング作業となる実装時に、企業が直接かかわるのは現実的ではありません。しかし、システム開発の正しい手順や手法を知り、開発チームメンバーの役割を理解すれば、企業が積極的に品質管理に参画できるヒントが見えてきます。

そこで本記事では、現在主流となっているシステム開発の手順や手法、開発チームで共有されるべき品質管理の考え方、キーパーソンとその役割などを解説し、品質管理を担保するために企業が気を配るべきポイントを紹介していきます。

そもそも、システム開発における品質管理とはなんでしょうか？品質管理のゴールは「企業の希望・計画どおり、もしくはそれを上回るシステムの完成」であり、それを実現するために作業工程を管理することです。このため、システム開発における品質管理は、開発中のシステムが完成する以前のタイミングで行わなければなりません。

上述したように、クライアントである企業自らがプログラミングに参画するのは現実的ではないため、プログラマーへの指示書作成にあたる「詳細設計」以前が品質管理に関与する重要なタイミングになるでしょう。

それでは、企業がシステム開発で行うべき品質管理とは、具体的になにをどう管理するものなのでしょうか？品質をジャッジする成果物が存在しない段階での品質管理とは「企業の希望・計画とズレのないシステム」を完成させるため「企業の希望・計画と開発チームの認識のズレ」を修正し、管理していくものだといえるでしょう。

開発するシステムに企業が求める希望・計画を明確にし、開発チームと共有するための「要件定義」が非常に重要になるのはこのためです。では、開発の最初期段階で行われる要件定義さえ押さえておけば、システム開発の品質管理が充分に行われたことになるのでしょうか？

もちろん、要件定義はシステム開発の成否を決定付ける重要な要素ですが、要件定義だけを品質管理だと定義付けるのは間違いです。なぜなら、一般的なシステム開発の手法であるウォーターフォール型開発以外にも、アジャイル型開発という手法が注目されているからであり、それぞれの手法で品質管理の考え方も方法も異なるからです。

従来からある、もっとも一般的で主流となるシステム開発の手法が「ウォーターフォール型開発」です。ここまでで何度か触れてきたように、ウォーターフォール型によるシステム開発は、どのような機能を持つ、どんなシステムを作るのかを決定する「要件定義」からはじまります。

その後、要件定義で決められた仕様をどのように実現するか、大まかな機能・デザインをドキュメントやワイヤーフレームなどで具体化する「基本設計」を経て、プログラマーへの設計図となる「詳細設計」に移り、実際のプログラミングである「実装」「テスト」という工程を経るのが一般的です。大規模なシステムなどでは、実装する機能ごとに詳細設計を分け、できあがったプログラムをそれぞれ単体でテストし、結合してからさらにテストを行う場合もあります。

これらの工程を見てもわかるように、ウォーターフォール型開発では工程ごとに担当者・チームが異なり、段階を経て作業が進められるのが一般的です。滝（Waterfall）のように上流から下流へと作業を流していくことから名付けられた開発手法であり、詳細設計・基本設計を上流工程、それ以降を下流工程と呼びます。下流工程を外部のプログラマーが担当するケースが少なくないのも特徴です。

このことから見えてくる事実は「ウォーターフォール型開発の下流工程では、システムの品質に影響する要素はプログラマーのスキルのみ」だということです。つまり、システムの品質を担保するのは上流工程のみであり、企業が品質管理すべきは「要件定義」「基本設計」だということになります。これは制作会社の開発チームでも共有されている認識だといえるでしょう。

ウォーターフォール型開発に限ったことではありませんが、システム開発では「Scope = どんなシステムを作るか」「Time = どのくらい時間をかけるか」「Cost = どのくらいの予算をかけるか」のバランスを取る必要があります。無限に時間と予算を費やせば、どんなシステムでも作れるかもしれませんが、通常はそういうわけにはいかないからです。

このうち、ウォーターフォール型開発で重視されるのが「Scope」であり、決定・固定されたScope = 要件定義に従って、Time = 納期とCost = 予算が導き出されます。要件定義に変更が生じ、機能追加などを行えば納期も伸び、予算もかさむのはこのためです。

納期・予算を守りながらウォーターフォール型開発の品質管理をしていくには、変更が生じないように詳細に要件定義を詰め、基本設計を逐一確認しながら、開発チームとの認識のズレを丁寧に修正していく必要があるのです。

ウォーターフォール型開発は現在でもシステム開発の主流だとはいえますが、すべてのシステム開発に有効な手法だとはいえません。固定されたはずのScopeが変動しやすいためであり、そのために上流工程への手戻りが生じれば、時間も予算も膨らんでしまうからです。そこで注目を集めているシステム開発の手法が、俊敏な・素早いという意味を持つ「アジャイル型開発」です。

アジャイル型開発でも「要件定義（計画）」「基本設計」「詳細設計」「実装」「テスト」「リリース」という工程を経るのはウォーターフォール型開発と同様です。しかし、アジャイル型開発がほかともっとも大きく異なる点は、リリースにいたる開発工程を1〜2週間、長くても1か月に区切ってサイクル化させ、繰り返すことで開発を進めていくことです。

たとえば、最初のサイクルで商品検索とカートシステムを実装したECサイトを完成させてリリース、次のサイクルで会員システムを実装し、その次のサイクルでレコメンドシステムを実装する、といったイメージです。具体的には、開発メンバーと開発期間 = サイクルを決め、そのなかでどんな開発ができるかを考えていくことになります。

上述したScope、Time、Costでいえば、TimeとCostを重視して固定し、枠組みの範囲内でScopeを変動させていくのがアジャイル型開発の特徴です。開発費用 = プログラマーの人件費であり、メンバーとサイクルを固定することでCostも固定できるからです。サイクルごとに開発されるのは成果物の一部機能になるため、実際に運用した結果をもとに要件を柔軟に変更させ、次のサイクルに活かせるのがアジャイル型開発のメリットだといえるでしょう。

サイクル化された開発工程が明確になっているわけではなく、固定されたメンバー全員でプロジェクトに取り組めるため、ノウハウや認識が共有しやすいというメリットもあり、実装・テスト以外のあらゆる段階で品質管理にかかわれる余地があります。

アジャイル型開発の品質管理では、クライアント企業がプロジェクトの一員として、あらゆる段階でかかわりを持ち、フィードバックしつつ情報共有するのが重要です。いつまでも開発サイクルを回すわけにもいかないため、ゴールとなる目標を立て、見切っていくのもクライアント企業の役目です。

すでに解説したように、ウォーターフォール型開発では開発工程それぞれに担当者が異なり、メンバーが固定されているアジャイル型開発でも開発メンバーはひとりではありません。クライアント企業が品質管理に積極的にかかわっていくには、開発メンバーのなかでも、品質管理に責任を負う担当者と折衝していかなければなりません。

それが「プロジェクトマネージャー（PM）」であり「プロダクトマネージャー（PM）」です。どちらもPMと呼ばれるため混同しがちですが、ウォーターフォール型開発で品質管理の責任を負う場合が多いのが「プロジェクトマネージャー（PjM）」であり、アジャイル型開発で品質管理の責任を負う場合が多いのが「プロダクトマネージャー（PdM）」です。

それでは、なぜシステム開発の手法の違いによって、責任者が異なる場合があるのでしょうか？品質管理に責任を持つという点で両者は同じであるものの、目指すべきミッション、役割、業務内容、意識すべきことが異なるからであり、システム開発の手法の違いに大きくかかわっているからです。具体的に見ていきましょう。

ウォーターフォール型の開発メンバーは、上述したように開発工程でそれぞれ担当者が異なり、役割も大きく異なります。具体的には、要件定義を受け持つのが「プロジェクトマネージャー（PjM）」であり、基本設計・詳細設計を受け持つのが「システムエンジニア（SE）」実装・テストを受け持つのが「プログラマー（PG）」です。

要件定義や基本設計でクライアント企業とミーティングを持つ場合、SEも出席することはありますが、要件をもとに具体的な設計を担当するのが本来の役割であり、設計をもとに実装・テストするのがPGの役割です。システム開発において品質管理の責任を負うのは、あくまでもプロジェクトマネージャーであり、進行管理型PMとも呼ばれます。

それでは、プロジェクトマネージャーの具体的な役割とはなんでしょう？Airbnbのディレクターである、Ian McALister氏によれば「Project manager own “How” and “When”」だということになります。つまり「どうやって作るか」「いつまでに作るか」に責任を持つのがプロジェクトマネージャーの役割です。具体的に見ていきましょう。

プロジェクトマネージャーのミッションは以下のとおりです。

・システム開発で設定された目的を実現すること
・品質・納期・コストを計画して達成すること
・計画を実現するための方法を見つけ、課題を解決すること

これらのミッションを達成するため、システム開発というプロジェクトを総合的にマネジメントしていくのがプロジェクトマネージャーの役割であり業務内容です。設定されたScope、Time、Costを守るためにメンバーを集め、予算や進行の管理を行い、品質管理しながらメンバー、クライアント企業と密にコミュニケートしていくのです。

このため、ドキュメントやワイヤーフレームの制作を手がけることはあっても、プロジェクトマネージャー自身が実装にかかわることはほぼありません。プロジェクトマネージャーには、プログラミングの知識よりも計画どおりにプロジェクトを進行させる、まさに進行管理型といわれるスキルが求められるのです。

一方のアジャイル型開発では、ウォーターフォール型開発のように開発メンバーの役割が明確になっていない場合が多いといえます。細かく分割された機能を全員で形にしていくため、ドキュメンやワイヤーフレームも必要最低限で済み、ノウハウも蓄積しやすいことからシステムエンジニア（SE）とプログラマー（PG）の境界が曖昧であり、全員がSE、PGの役割を担うといっていいでしょう。

しかし、全員の合議制でシステム開発していたのでは、アジャイル型開発の特徴である短いサイクルでのリリースは不可能です。プロダクトとしてのシステムを形にするため、強いリーダーシップが必要であり、その立場になる責任者がプロダクトマネージャー（PdM）であり、品質管理型PMとも呼ばれます。

それでは、プロダクトマネージャーの具体的な役割とはなんでしょう？Airbnbのディレクターである、Ian McALister氏によれば「Product manager own “What” and “Why”」だということになります。つまり「なにを作るか」「なぜ作るか」に責任を持つのがプロダクトマネージャーの役割です。具体的に見ていきましょう。

プロダクトマネージャーのミッションは以下のとおりです。

・開発したシステムが顧客に提供する価値を高める
・技術的可能性の追求
・顧客の課題解決
・経済性の追求、4P（Product、Price、Place、Promotion）の整合性を図る

これらのミッションを達成するため、システムというプロダクトを総合的にマネジメントしていくのがプロダクトマネージャーの役割であり業務内容です。もちろん、プロダクトマネージャーも、PjMのように進行管理やメンバーとのコミュニケートも担当しますが、開発するシステムが顧客に最大の価値を与えられるように、プロダクトとしてのシステムそのものの責任を担います。

このため、顧客の利益を第一に考えて開発の方向性を定め、メンバーを同じ方向へ向かわせるように鼓舞していくのが主な業務となります。その性格上、プロダクトマネージャーには技術的な知識も求められ、自ら手を動かして積極的にプログラミングしていくのも、PjMと大きく異なるところであり、まさに品質管理型PMだといえるでしょう。

アイミツでは、品質管理を考えたシステム開発をサポート致します。「知識がない」「複数社の見積もりを取る時間がない」「会社選びがわからない」といった方は多いのではないでしょうか。そんな方に向けてアイミツでは、審査済みの優良企業のみを厳選し、最短翌日までにご紹介します！

システム開発の費用相場をご紹介します。

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

Microsoftのシステム開発がアジャイル型へ移行したことからもわかるように、欧米ではアジャイル型開発が主流になりつつあり、それにともなってプロダクトマネージャーの存在がクローズアップされています。日本でもその流れを受け、プロダクトマネジメントの考えをシステム開発に取り入れようという動きが活発化しており、品質管理に対する不満は解消の方向に向かうのかもしれません。

一方、どんなにプロダクトマネジメントの考えを取り入れたとしても、ウォーターフォール型開発の場合、企業が品質管理にかかわれるのは「要件定義」「基本設計」にとどまってしまうのは否めません。

品質を担保しながら新たなシステム開発を依頼する、開発会社を変更するなどを検討しているのであれば、どのような手法でシステムが開発されるのか？具体的な開発工程はどうなっているのか？を念頭に置き、見積もり段階から確認していくのが重要です。

日本最大級の発注業者比較サイト「アイミツ」であれば、システム構築に関する専門知識を持ったコンシェルジュが、信頼のおける業者を完全無料で紹介できます。制作会社の選定に迷ってしまったら、お気軽に相談してみてください。