システム開発の成功に欠かせない目的と目標の共有とは【2024年最新版】

システム開発において、目的と目標の違いを認識することは、単なる言葉の問題ではなくプロジェクトを成功に導くための大きな前提条件です。
失敗するプロジェクトのほとんどは、この目的と目標の混同が生じています。

システム開発で言う「目的」とは、そもそもなぜその開発投資を行うことになったのか、その課題について一文でズバッと答えたものです。
例えば「現状の汎用機システムが老朽化し、事務処理に余計な時間がかかっている」という課題に対して、「事務処理業務の効率化を目的として、新しいシステムを導入する」という解決方法は、本質的な目的部分をズバッと一言で表しています。

これに対して目標とは、目的を達成するための具体的な「標し」（しるし、めじるし）です。
上のケースで言うと、例えば「オープンシステムを導入して現在の事務処理時間を半分に短縮する」というのが「目標」になります。

失敗プロジェクトの場合いつの間にか目的が忘れ去られ、「オープンシステムを導入して現在の事務処理時間を半分に短縮する」という目標だけが独り歩きしていきます。

ヒアリングや要求定義などのプロジェクトの初期段階で、このことが独り歩きしていくと、「現在の事務処理時間を半分にする」ということだけに目がいってしまい、不要な業務プロセスを思い切って廃止するなどの抜本的なBPR（ビジネスプロセス・リエンジニアリング）などが忘れ去られてしまいます。
既存の業務ありきで発想しその時間短縮だけを目指すのではなく、不要な業務プロセスそのものを廃止したり統廃合したりすれば、本来の「目的」である「事務処理業務の効率化」はもっと激的に進む可能性もあります。

「目的」の重要性を指摘してきましたが、もちろん「効率化」という目的だけを追求しても、具体的な目標が決まらないことにはプロジェクトが前に進みません。
プロジェクトの成功のためには、発注者と開発側企業がこの「目的」と「目標」の両輪としての重要性をしっかりと認識して、プロジェクトの最初から最後まで共有し続けていくことが不可欠です。

この記事では、ついつい混同されがちな「目的」と「目標」の役割を明確化して、システム開発プロジェクトを成功に導くコツをお伝えします。

システム開発に関するその他記事は以下をご覧ください。
システム開発における設計書の書き方｜おすすめツールもご紹介！
システム開発におけるプログラミング言語とは？
システム開発の流れを徹底解説！
システム開発の仕様書の書き方・種類・サンプルをご紹介！
【システム開発の種類】web系・オープン系・汎用系の違いを解説！
Webシステム開発にかかる費用と料金相場

では最初に「目的」と「目標」がどのように違うのかをさまざまな角度から整理していきます。

目的は目標に優先する、という原則を頭に入れておけば迷ったときに間違いない方向を再確認することができます。
例えば東京から大阪に移動することが「目的」の場合、新幹線に大事故が起きて不通になっているという状況でも、すぐに羽田から飛行機で移動するという代替手段が思い付きます。

目的は東京から大阪までの移動にあるので、本来はどんな移動手段を使ってもよいわけですが、目の前の新幹線の不通状態にとらわれてしまうと、遅刻しそうだということを取引先や自分の会社の上司に報告するなどの後ろ向きの対処に追われてしまいます。

システム開発で言えば、最初に要件定義をした内容がどうも当初予定していたようなメリットがなさそうだ…と気が付くことがあります。
そのときに大切なのは、「納期どおりにシステムを納品してもらう」という納期目標を遵守することではありません。
こうした場合には、いったん納期目標などをリセットしてシステム構築の「目的」の確認を発注側と開発側で再度行い、適切な目的の共有をしたあとに、納期を後ろにずらすなど、「目標」を再設定するという態度が必要です。

ビジネスの現場では、常に具体性が求められます。
抽象的な言い方や考え方は会議などの席上でむしろ敬遠されがちという場合もあります。
しかし、システム構築の現場では抽象的な「目的」というのは非常に重要です。
もちろんいわゆる絵に描いた餅、極端な理想論などは何の役にも立ちません。

しかしシステム開発は、現状の具体的なプロセスをいったん白紙に戻して、ビジネスプロセスを再定義するという非常に大きな役割を担っているプロジェクトであることが少なくありません。
その場合、抽象的な「目的」はシステム開発を最後まで軸をぶらさずに完遂するために不可欠の要素であるとさえ言えます。

もっとも、抽象的な目的がいつまで経っても具体的な目標に落とし込まれなければ、結局、極端な理想論となってしまいます。
システム開発では、発注側と開発会社とが、この抽象的な「目的」と具体的な「目標」のバランスを常に意識して共有することが大切です。

いくら大切だからと言って、目的の数が多すぎるプロジェクトは失敗します。
例えば、「業務の効率化」という目的のほかに「顧客満足度の向上」という目的を１つ加えただけで、システム開発は混乱します。
なぜなら、このケースで言う「効率化」と「顧客満足」とは必ずしも同じベクトルを持っているとは限らないからです。

例えば、顧客それぞれに対してキメの細かい対人アプローチで顧客満足向上を実現していく、というプロセスはいわゆる「効率化」とは相容れません。
「効率化」を最優先目的としたいなら、顧客それぞれにきめ細かい対人アプローチをしていくということは犠牲にしなければならないケースもあるでしょう。

もちろん最初の段階では「目的」が複数あってもよいのです。
例えば、「業務の効率化」のほかに「ミスの軽減」を検討してもかまいません。
この２つは、同じベクトルを向いているので、両者を具体的に検討していくなかで、最終的に「業務の効率化」に「ミスの軽減」が含まれることに気が付く場合もありますし、逆に「ミスの軽減」を最終目標とすることで自然と「業務の効率化」が図られていくというシステムを設計することになるかもしれません。

大切なのは、目的を１つに絞ることです。
絞ることに困難を感じるような２つ以上の目的（「効率化」と「顧客満足」など）が浮かび上がったときには、プロジェクトを分割すべきです。
「仕事効率化システム開発」と別個に予算を確保して「顧客満足向上システム開発」を行うことで、混乱なくプロジェクトを完成させていくことが可能です。
開発会社とも「最終的に顧客満足度向上システム開発もやりたい」ということを共有することで、将来的なシステム統合を視野に入れた無駄のないシステム設計をしてもらえます。

これに対して、目標は複数持ったほうが目的の達成に向けて多面的なアプローチが可能になります。

「目的」は１プロジェクトにつき１つに絞るべきですが、「目標」は１つのプロジェクトにいくつあってもかまいません。
むしろ、あらゆる目標をリストアップして、そのなかで優先順位を付けていくという考え方が必要です。

例えば「業務効率化」で言えば、下記のような要素はすべて検討すべき「目標」となります。

こうした「目標」をリストアップして発注側と開発会社とで共有し、難易度や工期、予算などに応じて優先順位を付けることが必要です。

「目的」はどんなことがあっても、プロジェクトが続く限りは変更しないのが原則です。
最初に「業務効率化」を目的とするプロジェクトを推進していたのに、それを破棄して「顧客満足度向上システム開発」に切り替えるということをしてはいけません。

どうしてもそうしたいのならば、別個にプロジェクトを１からスタートさせるべきで、決して「せっかく途中まで設計した業務効率化プロジェクトの設計図を流用しよう」などと考えてはいけません。
目的が変わるということは細部の目標そのものも変化するので、中途半端な再利用をすると途中で設計に無理が出てくることは間違いありません。

これに対して、「目標」は柔軟に変更可能です。
旧来の「ウォーターフォール型システム開発」の場合には、最初に目標までガチガチに固めてしまいますが、最近日本でも主流となりつつある「アジャイル型開発」の場合には、「目標」ごとに小さな納品を繰り返し、納品のたびごとに発注者側と開発会社側で、次にどの目標に取りかかるかの優先順位を決めていきます。
小さな納品物を実際にローンチしていくことで、現場の声をさらに拾い上げて目標を柔軟に見直し、より良いシステムを作り上げていくことができます。

では、概念的なことがわかったところで、具体的に「そもそもなぜその開発投資を行うことになったのか、その課題について一文でズバッと答えたもの」の例を見ていきましょう。

【解決すべき課題】
現状の汎用機システムが陳腐化して、非効率的な事務負担が過大化している
【システム開発の目的】
非効率的な事務負担を解消するためにオープンシステムを導入する

【解決すべき課題】
営業所ごとに顧客情報が分散されており、情報が有効活用できていない
【システム開発の目的】
顧客情報を一元化して本部が情報を統括し、共通のプロモーション活動がうてるようにする

【解決すべき課題】
見込み客を成約に結び付けることに失敗する失注率が高すぎる
【システム開発の目的】
現状のエクセルベースの顧客管理システムを廃止し、SFA連動型のCRMを導入して他社との競争力をつける

【解決すべき課題】
営業マンが社外から社内データに自由にアクセスできない
【システム開発の目的】
セキュリティを重視したファイルサーバーを構築して社内資産を社外から閲覧できるようにする

このように、まず現状の課題があり、それを認識することで正しい「目的」が見えてきます。
システム構築の目的の明確化は、開発会社から提案されるものではなく自社内で見つけ出すことが必要です。
それに対する具体的な解決手段としての「目標」は開発会社にアイデアをもらいながら、明確化していきましょう。

では次に「目的を達成するための具体的な「標し」（しるし、めじるし）」である「目標」の設定について見ていきましょう。

【システム開発の目的】
非効率的な事務負担を解消するためにオープンシステムを導入する
【目的を達成するための具体的目標】
・本支店のネットワークをインターネットベースにする
・営業マンにとって使い慣れたエクセルベースの効率的システムを開発する
・メンテナンスはリモートで行う

【システム開発の目的】
顧客情報を一元化して本部が情報を統括し、共通のプロモーション活動がうてるようにする
【目的を達成するための具体的目標】
・マーケティングオートメーションツールと連動したシステムを構築する
・ネットを使ったプロモーション活動はすべて新システムの管理画面で完結する
・営業所からのデータ蓄積は日報をベースとして顧客情報だけを抽出する

【システム開発の目的】
現状のエクセルベースの顧客管理システムを廃止し、SFA連動型のCRMを導入して他社との競争力をつける
【目的を達成するための具体的目標】
・100名弱の営業マンの現在抱えている案件が一覧できるようにする
・商談の進行具合、成約率等の指標によって営業マンをランク付けできるようにする
・CRMはマーケティング部門、SFAは営業部門が管理できるようにして、情報システム本部が両者を統括する

【システム開発の目的】
セキュリティを重視したファイルサーバーを構築して社内資産を社外から閲覧できるようにする
【目的を達成するための具体的目標】
・SaaS型のクラウドシステムを活用して開発コストを極限まで下げる
・ファイルサーバーにアクセスできる権限を細かく設定できるようにする
・ノートパソコンだけからではなく、タブレット、スマホからも閲覧できるようにする

こうしたレベルに落とし込むことが「目標」設定となります。

ここまで「目的」と「目標」の違いや具体例について整理してきました。
こうした点について発注者側と開発会社が最新の情報を共有できていれば問題ないはずですが、それでも現場では「目的」と「目標」をめぐる混乱がよく生じてしまいます。
次にどんなときにどんな混乱が生じるのかを見ていきましょう。

「目標」とは本来最終的な「目的」を達成するための手段に過ぎません。
例えば「業務効率化のための新システムを2017年10月1日に稼働させる」という場合、最終的な目的は「業務効率化」であり、「2017年10月1日にシステムを稼働させる」ことはあくまで目標です。
納期については納品や支払いといったことにも影響があるために、なんとしてもその日を死守しようというのが、発注側とシステム開発会社との共通の思いですが、これは最終的な「目的」ではないのです。

ほかにも「顧客情報を一元化して本部が情報を統括し、共通のプロモーション活動が行えるようにする」ことが最終目的の場合、マーケティングオートメーションツールとの連動は、必要に応じて後回しにして、とにかくデータの一元化を最優先事項としてプロジェクトに取り組むべきでしょう。

とかく開発側は自分たちで対処しやすい「目標」にとらわれがちですが、本来手段にすぎない「目標」が自己目的化されてしまうと、最終的なプロジェクトの「目的」を見失ってしまいますので注意が必要です。

システム開発プロジェクトに限らず、日常的な業務に追われ始めると本来の「目的」が前景から遠のいて、目の前には「目標」だけがクローズアップされるという事態が起きてしまいます。
開発側企業とのミーティングで、新システムに必要な、目立たないけど重要な機能が抜けていることが発覚したときなど、なかなか「目標」をいったん棚上げして「目的」を確認し、設計を部分的にやり直すということはしにくいものです。

プロジェクトがスタートしてしまうと、目標管理のための進捗管理シートの存在感が増していきます。
確かに決められた手順で計画どおりに工期を完了していくことは大切です。
しかしそれ以上に定期的に「目的」からずれたプロジェクトになっていないかを確認し、万が一目的からずれかかっていたら、目の前の作業の進行をストップさせて、「目的」に沿ったプロジェクトの再構築に取り組みましょう。

プロジェクトが「目標」優先になってしまうと、ひとつひとつの「目標」の重要度という指標を見失ってしまいます。
最終的な「目的」からすると、いま進捗が遅れている「目標」の達成は他の項目に比べてそれほど大きなウエートを占めていないというケースが往々にしてあります。
極端な話、他の目標がすべて達成できたあとに、納期後でもその部分だけ追加で対応してもらえれば済むこともあり得ます。

こうした優先順位は「最終目的は何か」→「それは1日も早く営業マンが商談の現場で自社製品のPDFを自由に見せられることだ」という目的から正しく導き出されます。
言い換えれば、近視眼的な思考で目の前の目標だけを処理していこうとしている場合には、他の重要な目標達成との違いが見えてこないのです。

プロジェクトを円滑に進めるためには、常にこの「最終目的は何か」→「だからこの目標は優先だ/後回しだ」と思考できる柔軟性が必要です。

それでは、ここまでの見てきた正しい「目的」と「目標」を、システム開発会社と共有するための具体的な方法を解説します。

普段何気なく使っている「目的」と「目標」という言葉ですが、システム開発においては両者を曖昧なままにしておくと、システム開発プロジェクトの方向性を見失ったり、プロジェクトの進行が止まったり、必要な再設計に目をつぶって目の前のスケジュールだけをこなしていったりということが起きてしまいます。

こうした事態を避けるためのプロジェクトマネジメントノウハウが、優良なシステム開発の現場で長年蓄積されてきています。
実績のある開発会社ならば、ベテランのプロジェクトマネージャーが失敗の兆候をいち早く察知して適切にプロジェクトを仕切り直してくれます。

プロジェクトマネージャーは、システム開発の要所でプロジェクト全体の意思決定のサポートをする役割を果たしてくれたり、プロジェクトを円滑に進行・管理したり、クライアントとのコミュニケーションを推進して必要な情報を共有するための施策を取ってくれます。

また、少し規模が大きなプロジェクトの場合には、プロジェクトマネジメントを組織的に行う「PMO」（Project Management Office、プロジェクトマネジメント・オフィス）を設置する場合もあります。

優秀なプロジェクトマネージャーの存在は、確かにプロジェクトにとって不可欠な要素ですが、逆にあまりにも１人の優秀なプロジェクトマネージャーにすべての権限やノウハウ、情報が集中してしまうと、組織内、組織間で「目的」と「目標」を共有することが難しくなってくることもあります。

PMOを設置することで全体会議、ステアリングコミッティ（運営委員会）、進捗会議などを組織的に管理することができますので、その場所を利用してプロジェクトの最終目的や、現時点で機能している目標などをチェックしていくことができます。
各種目標のための指標の基準値作成、収集、評価とクライアントとの共有、フィードバックなどの業務をPMOで行うようにすれば、タイムリーにプロジェクトの目標と目的を確認して必要な調整をしていくことができます。

伝統的なウォーターフォール型では、いったん決めた目的と目標は基本的にはプロジェクトの最後まで見直しは行いません。
しかし、プロジェクトの現場では最初に決めた目的に照らして、目標が正しく達成されているかをクライアント自身が細かくチェックしたり、目標を柔軟に変更したりといったことが必要になる場面も多々あります。

こうしたケースに備えて、最初から開発方式を「目的」と「目標」のチェックに適したやり方で進めるという方法もあります。

例えば、プロトタイピング型開発では、開発の工程内で「目標」となる試作品を作り、それをあらかじめ発注者側に確認を取ります。
ユーザーインタフェースのみで、実際には機能は付いていないというケースもありますし、逆にインタフェースは作り込まず、重要な機能について動作確認を目的として評価してもらう場合もあります。

重要な目標の完成形のプロトタイプを作って、実際に納品後に使うシーンを想定してテストしてもらうので、試作品を試すたびに「本当にこの目標でよいのか」「目標にずれはないか」を体験することができるわけです。

試作品を作りながらですので、工期が余計にかかり費用も上乗せになりますが、ていねいにシステム開発プロジェクトの「目的」と「目標」を検証しながらスケジュールを進行させていくことができます。

アジャイル型開発は、発注者側と開発会社とで「目的」を最初に確認したあと、「目標」を常に共同で再検討しながら進めていく開発手法です。

プロトタイピング型開発との一番の相違は、プロトタイピング型開発があくまでも、最初に決めた「目的」と「目標」を確認するために試作品を共有していくのに対して、アジャイル型開発では、「試作品」ではなく、小さな工程ごとに「納品」を何度も行います。
さらにいったん納品が終わったあとは、最初に決めた目標そのものの優先順位を再検討します。

プロトタイピング型開発は、試作品を作ってNGだった場合にもう一度正しい試作品を作りますが、アジャイル型開発では、再検討をして必要がないとみなされた目標は破棄してしまうこともあります。

この「目標」を開発会社と共有しながら優先順位を組み替えていくというアジャイル型開発手法は、この記事をお読みの方には特に興味深いと思われますので、こちらの記事などもぜひご参照ください。

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

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

以上、混乱しがちなシステム開発における「目的」と「目標」の違いや、設定・見直しの注意点、陥りやすい罠、それを回避する方法について解説してきました。

システム開発において「目的」と「目標」をきちんと機能させるためには、やはり発注者側だけでなく、開発側が「目的」と「目標」の重要性についてきちんと認識していることが必要です。
開発会社のなかには開発とは実際にコーディングを行うことで、それ以外は必要最小限の時間と労力しか割かないというところもあります。

しかし、この記事で解説したように、開発の現場において「目的」と「目標」をきちんと認識して最初から最後まで最適化していくことは開発プロジェクト成功の絶対条件です。
開発会社の規模や実績、提示する費用の安さなども重要ですが、長く付き合える間違いのないパートナー企業を探すためには、こうした表面に現れにくい部分でていねいに仕事をしている開発会社を見つけ出すことが大切です。

業界の評判にも精通した「アイミツ」にご相談いただければ、そうした情報を十分に考慮して、御社に最適な開発会社をご紹介できます。
開発プロジェクトを進めていく上で欠かせない顧客の「目的」を最大限尊重し、マイルストーンとなる「目標」をていねいに共有、最適化しながらプロジェクトを進めていける会社をお探しなら、ぜひ「アイミツ」にお声をかけていただければと思います。

おすすめのシステム開発会社は以下をご覧ください。
Webシステム開発におすすめの開発会社15選！開発の流れや費用も解説
大手のシステム開発会社を5社ピックアップ