クオリティの高い納品物はシステム開発の適切な管理がポイント【2024年最新版】

システム開発を外注しようと考えてネットを検索すると、比較しきれないほどのたくさんのシステム開発会社が出てきます。
どの会社も自社の強みをアピールしていますが、発注者が完全に満足のできる状態の完成品をきちんと納期通りに納品してくれる会社は全体の４分の１くらいだとも言われています。

納期が多少遅れ、発注者都合で追加した機能を実現するために費用がかかっても、最終的に求めていたクオリティを満たしていればよいのですが、この点に関してはどのシステム開発会社に頼んでも安心というわけではないのが実情です。

こうした状況の背景として、開発会社の実力不足、あるいは実力不足であるにも関わらず、自社のホームページでは経験豊富で技術力が高いということをアピールしているということがあるのは確かでしょう。

しかし、納品物のクオリティが満足できるレベルではないというケースは、責任のすべてが開発会社にあるわけではないことも多いのです。
システム開発においてクオリティの高い納品物を収めてもらうためには、発注者側でしなければならない点もあります。
そうした点をきちんと押さえている発注者が開発会社任せにせず、開発プロジェクト全体を管理している場合には、開発会社の技術力や経験のレベルがそれほど高くなくても、高いクオリティを実現した納品物が上がっています。

この記事では、高いクオリティの完成品を納品してもらうために、発注者がシステム開発プロジェクトの管理をリードするためのポイントについてお伝えします。

システム開発会社では１つのシステム開発案件をたった１人で担当するということはほとんどありません。
必ず何人かの開発者、そしてプロジェクト全体をマネジメントするプロマネ（プロジェクトマネージャー）がチームを組んで発注者の希望する納品物を仕上げていきます。
もし依頼した開発プロジェクトに対し、発注先がたった１人でしか対応していないと分かったらかなりの不安を覚えるのが普通です。

これと同じことが、実は発注側についても言えるのです。
発注側がチームで動いておらず、事実上たった１人の発注担当者だけがプロジェクトを担当しているという場合、開発会社は発注元企業に対してかなりの不安を覚えます。

開発プロジェクト全体を発注側できちんと管理するためには、まずきちんとしたプロジェクトチームを組んで、組織的にシステム開発プロジェクトを管理していく必要があります。

システム開発の目的とは、例えば「顧客満足度の向上」や「営業部門の受注率を高める」「受発注業務を効率化する」などです。
こうした目的は、単に現場の業務部門が認識しているだけでなく、経営マネジメント層を含んだ全社的規模で組織として共有しておく必要があります。

例えば、マーケティング部門で「顧客満足度の向上」という目的のために何ができるかを考えた場合、「営業マンによるキメの細かいフォロー」という営業部門マターの項目はなかなか上がってきません。
逆に営業部門において「営業部門の受注率を高める」ために何ができるかを考えるときには、「CRM的な長期関係を管理できる顧客データベースの整備」というマーケティング部門マターの項目も上がってきにくいでしょう。
同じように、「受発注業務を効率化する」という課題の解決を業務部門だけで解決しようと発想した場合にも、マーケティング部門や営業部門にまたがるような提案は出てきにくいものです。

このように「顧客満足度の向上」「営業部門の受注率を高める」「受発注業務を効率化する」といった目的を達成するためには、部門をまたいだ課題解決の検討が必要であることは明白です。
また、ビジネスプロセスそのものを変革する場合には、業務改善の権限のある経営マネジメント層を含んだ意見の集約も必要になってきます。

こうした大きな枠組みでシステム開発の目的を明確化するためには、全社的なシステム開発への取り組みが重要になってきます。

要求定義とは、システム開発プロジェクトにおいて何をしたいかを、開発会社に理解してもらう作業です。
このとき大切になるのが、先程指摘した全社的なシステム開発への取り組みと管理です。
マーケティング部門、営業部門、業務部門など今回のシステム開発に関係がありそうな部署を横断的にまたいだプロジェクトチームを結成し、「上流工程」「超上流工程」において自社のやりたいことを明確化する「要求定義」を進めていきましょう。

「上流工程」での要求定義とは、発注側のやりたいことを現場レベルで明確化して、開発会社に伝える作業です。
先程の例で言えば「顧客満足度の向上」「営業部門の受注率を高める」「受発注業務を効率化する」などの課題につき、関係各部署にヒアリングをして課題点などを浮き彫りにします。

もちろん、開発会社の設計担当者もヒアリングに参加しますが、開発会社任せにしてはいけません。
業務の内容を一番よく知っている発注サイドが「こういう問題の解決をシステムに反映して欲しい」という積極的な態度で、この工程のマネジメント（管理）をリードしていくことが必要です。

「超上流工程」での要求定義とは、システム開発の目的の確認などを、業務の管理者や経営マネジメント層と行うことです。
なぜこうした作業が必要になるかについては、先程確認したように、現場レベルの要求定義だけでは部門をまたぐ建設的な提案が出てきにくいからです。
また、現場レベルですと、「この業務をこう改善したい」というように「業務ありき」の視点になりがちです。
業務部門を統括する管理者や経営マネジメント層に聞くことによって、「そもそもその業務のやり方自体に問題があるのではないのか？」というビジネスプロセスの改革に踏み込んだ意見を出してもらうことが可能です。

例えば「受発注業務を効率化する」という目的を改善するために、業務部門の現場からは「検品のスピードを上げるために、バーコードリーダーを導入する」というアイデアが出てきたとしましょう。
これに対して経営マネジメント層からは、「検品が受注発生時に担当者ごとにバラバラに行われている業務形態を改善し、検品だけを行う部隊を新規に作るべきではないのか？」という意見が出てくる場合もあるでしょう。
単なる業務の改善案ではなく、こうしたBPR（ビジネス・プロセス・リエンジニアリング）に踏み込んだ提案は多くの会社で現場に決定権がありません。

新規のシステム開発は、BPRを推進する大きなチャンスでもあり、現場での業務改善を超えたより抜本的な意味での業務システムの改善について、超上流工程での要求定義を行うことが大切になってきます。

要求定義を開発業者に丸投げすることなく、プロジェクトチームが組織的に調整・管理をして、システム開発会社に対して機能要求としてまとめて伝えることが必要です。
そうすれば、発注側企業の抱えている問題解決に直結するクオリティの高い納品物が期待できます。

開発が進んできた段階で、発注者が「あ、やっぱりこの機能を加えて欲しい」「すいません、この機能がないとまずいことに気が付きました」と開発会社に伝えると、「仕様が確定した段階で、今から言われても困ります」という態度を見せるところも少なくありません。

しかし、発注者は業務のプロではあってもシステム開発のプロではありませんので、プロジェクトの初期段階においてシステムの完成図を細部に至るまではっきりとさせることには無理があります。

確かに、発注者から要求定義の変更・追加があると、プロジェクトへさまざまな影響が出ます。
代表的な例として、下記のような影響が生じます。

発注者からの一言でこれらの影響が頻繁に起きるのは、プロジェクトにとって望ましいことではありません。
しかし、発注者の本音としては「かなり高額の開発費を払っているわけだし、そもそも、お客さんはこっちなのに、なぜ要求定義の変更・追加にそんなに気を使わなくてはいけないのだ？」という思いもあることでしょう。

この思いを根本的に解決するには、プロジェクト管理の主導権を発注者側で握っておけばよいのです。
つまり、プロジェクト管理をすべて開発者側に任せてしまっているので、「すいませんが、追加リクエストを処理してもらえませんでしょうか…」という、態度になってしまうわけです。

こうした遠慮が行き過ぎてしまうと、必要な追加仕様の相談も開発会社の顔色をうかがうことが普通となってしまい、結果として本来納品物に必要なクオリティ要件を満たすことができなくなってしまうことにもなりかねません。

開発者側で「スケジュール管理」「設計・仕様管理」「作業範囲管理」「見積もり管理」「運用管理」「プロジェクト目標管理」ができていれば、「今回の追加仕様で、スケジュールと見積もりに変更が出てきますが、それについてはこのように考えています」という形で、開発会社と話ができます。


以上３つが、発注側チームがプロジェクト管理において果たす役割の代表的なものです。
最後に指摘したような発注者の開発側への遠慮などが生じてしまう一番の原因は、発注者がプロジェクトの全体管理と、コーディングなどの開発部分の管理を区別せず、すべてを開発会社に丸投げしてしまっていることにあります。
次にこのことを確認しておきましょう。

伝統的なシステム開発は下記のようなプロセスを踏みますが、これを見るとコーディングなどのいわゆる開発会社マターの管理領域は、プロジェクト全体の一部であることがよく分かります。

■ システム企画（発注者主導）
どんなシステムを作りたいかを明らかにする段階ですので、完全に発注者主導であるべきです。

■ 要求定義（発注者主導）
現状の業務プロセスの問題点洗い出しや、全社レベルでの改善の方向性の確定などになりますので、完全に発注者主導であるべきです。

■ 要件定義（発注者・開発会社共同作業）
要求定義に基づき業務をシステムに落とし込む作業で、基本的には開発会社が作成しますが、プロジェクトの方向性を決める重要な工程なので、発注者も積極的に関わることが求められます。

■ 概要設計（発注者・開発会社共同作業）
基本設計、UI（ユーザーインタフェース）設計などを行いますので、発注者と開発会社の共同作業になります。

■ 詳細設計（開発会社主導）
ここまでの工程で決まった内容をシステムでどのように実現するかを決める工程ですので、開発会社主導になります。

■ プログラム設計（開発会社主導）
詳細設計の内容をプログラミングでどのように実現するかですので、開発会社主導の工程になります。

■ プログラミング（開発会社主導）
実際のコーディング作業ですので、開発会社主導の工程になります。

■ プログラムテスト、結合テスト、システムテスト（開発会社主導）
システム的なテストなので、開発会社主導の工程になります。

■受け入れテスト（発注者主導）
受け入れテストでは実際の業務での使用に耐え得るかという判断をしますので、どんなテストを実施して検収合格とすべきかのテスト項目策定なども、発注側主導であるべきです。

■ 運用保守（発注者主導）
開発、納品が終了したあとに、納品先のエンドユーザーがシステムを使いこなせるようにしたり、システムトラブルなどで業務がストップしたりしないようにメンテナンスを行う作業です。
やってもらいたい作業の明確化などについては、発注側主導であるべきです。

このようにプロジェクトが開始して、実際にプログラミングに関わる工程のみが開発者に任せる部分であり、プロジェクトの始まりも終了も発注者が管理すべきだということが分かります。
開発会社には、あくまでシステム開発プロジェクト全体のなかで「開発の部分」をお願いしている、という意識を持つことが、クオリティの高い納品物につながります。

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

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

以上、クオリティの高い納品物を得るために、発注者が果たすべき役割について整理してきました。

多くのシステム開発発注担当者の方は、いったん発注者側と開発側との打ち合わせが終わったら品質の向上を目指して開発を行うのは、システム構築会社の担当であると考えがちです。

しかしこの考え方では、本当の意味でのクオリティの高い納品物は上がってきません。
システム開発におけるクオリティの高さとは、単にハードウェアのスペック上限近くまで処理スピードを引き上げることや、決められた動作を滞りなく実行するということだけでは測れません。

開発会社に対して「クオリティの高さ」を要求した場合には、どうしてもこのような品質が追求されてしまいますが、本当のクオリティの高さとは、発注者側のシステム開発の「目的」をいかに実現しているか、という点で評価されるべきです。

そのためにも、発注者側がシステム開発の「目的」を全社的に共有するための社内プロジェクト開発チームを作り、要求定義は会社のチームが率先してまとめるという姿勢でプロジェクトをスタートさせるべきです。
また、開発が進んだ段階でも、必要な仕様の変更や追加は変な遠慮をせずに、開発会社に伝えるべきです。
こうしたポリシーを貫くためには、システム開発を発注者側で責任を持ってマネジメントしていく態度が求められます。

システム開発業界の情報に精通した「アイミツ」にご相談いただければ、発注側企業のこうしたポリシーを最大限尊重してくれる経験豊富なシステム開発会社をご紹介することができます。
社内の開発プロジェクト準備が進んできて、外注先を具体的に選ぶ段階になったら、ぜひ私たちにお声をおかけください。