品質コンサルタントが必要とされる背景

わが国では全産業のうち製造業の比率が最も高く、国際競争力向上の観点においても、わが国が抱える多くの課題に対する解決策創出のためにも、IoT、ビッグ データ、AIの活用が期待されています。そしてこれらを組込んだシステムが健全に開発され、高機能な製品やサービスが提供される環境 を確保することが重要な課題となっています。しかしながら現状、ソフトウェアを組込み込んだ製品やシステムの不具合原因は「ソフトウェアの不具合」が半数を占めており、ソフトウェア自体も「設計力の向上」「開発能力の向上」「新製品・新技術の開発」が課題となっています。

出典：「組込みソフトウェア産業の動向把握等に関する調査」から見える課題と解決　独立行政法人 情報処理推進機構（IPA）P18.P20

このような問題や課題を解決するためのサポート役として「品質コンサルタント」という役割が存在していますが、本記事では品質コンサルタントとはどのようなサービスなのか、また導入することによって得られるメリットについてご紹介していきます。

QualityCubeの品質コンサルティングとは

前章で挙げたソフトウェア業界の課題や問題対する解決策について、弊社、QualityCubeでは次のふたつの切り口で考えています。それは「当たり前品質の改善」と「魅力的品質の向上」です。

「当たり前品質」と「魅力的品質」の両面からサポート

「当たり前品質」とはユーザーが当たり前に担保して欲しいと思う品質のことを指し、不具合が無いことなどが該当します。「魅力的品質」とはユーザーの予想を上回る機能や性能の品質のことで、この品質が高いほど魅力的に感じます。ソフトウェアの不具合が多いということは、当たり前品質が低いことになり、設計力や開発能力、新製品・新技術の開発に課題があるということは魅力的品質が欠けていることになります。

弊社QualityCubeではこれらの問題、課題を解決するためにソフトウェア開発工程のプロセスと、工程のアウトプットであるプロダクト両面に対してアクションを起こし「当たり前品質の改善」と「魅力的品質の向上」をサポートします。

QualityCubeの４つのサポートサービス

QualityCubeのサポートサービスは大きく4つのカテゴリーで分けられています。

①品質コンサルティング
②プロジェクトマネジメント支援
③プロジェクト実務支援
④教育支援

QualityRoomのサービス詳細はこちらからご確認いただけます。

品質コンサルティング

IPAの調査によると、ソフトウェアの不具合に起因する品質問題の再発防止策として、以下が上位に挙げられています。

• 「技術者への教育」
• 「業務プロセスの見直し」
• 「障害情報共有」

QualityCubeでは、技術者への教育、業務プロセスの見直し、障害情報共有のための体制づくりはもちろん、品質改善のための様々なアプローチが可能です。実際にはプロジェクトごとに問題や課題は異なりますので、まず「現状分析」を行い、品質課題の"根本原因”を分析します。顕在問題だけでなく、その奥に潜んでいる問題まで掘り起こすことにより、真の解決に近づけます。現状分析後、不具合原因がドキュメントにあるのか、体制にあるのか、プロセスにあるのかを突き止め、根本原因を解決するアクションプランをご提案します。

たとえば、不具合が多発するソフトウェアがあったとして、一見、テストに問題があるように捉えられがちですが、根本原因は要件定義の考慮漏れであることがあります。そういった場合、テスト工程の見直しを行っても一向に品質は改善しません。現状を正しく把握することは品質向上への最短ルートなのです。

プロジェクトマネジメント支援

プロジェクトをとりまとめるPMが「品質の改善・向上」にとって重要であることは言うまでもないのですが、プロジェクトを一任できるスキルを持ったPMは業界全体で不足しています。また、一人のPMが複数のプロジェクトを担当している状況で、PMへの負担度が大きくなっていることもあり、「PMをサポートして欲しい」「PMを代行して欲しい」「ベンダーコントロールをアウトソージングしたい」といったニーズが増えています。QualityCubeでは様々な業界、業種のプロジェクトを成功に導いた実績のあるPMが多数存在しており、どのようなプロジェクトにおいてもQCDバランスを考慮した遂行が可能です。安心して一任ください。

プロジェクト実務支援

プロジェクトの問題、課題はコンサルティングやマネジメント支援だけでは解決しないことがあります。
そもそも人材が不足していたり、スキルが不足していたりする場合です。そのような場合にQualityCubeではコンサルタントが実務面からも上流から下流までサポートいたします。サポート体制としては「要件定義工程」や「テスト工程」といった、工程をまるごとお任せいただくパターンと、作業補助として人員を導入するパターンの二通りがあります。どちらのパターンが貴社のプロジェクトにとって適切であるかもご提案させていただきます。

リバースエンジニアリングのご紹介

実務支援には様々なプランがありますが、リバースエンジニアリングという言葉を耳にしたことはありますでしょうか。リバースエンジニアリングとは 開発ドキュメントが揃っていない、更新されていないため使えないと言った場合に プロダクトからドキュメントを逆起こしする技術です。ドキュメントが更新されていないということはソフトウェア品質において致命的です。リリースを急いでいてドキュメントが残っていない、属人化されたプロジェクトで担当者が退職してしまい、ドキュメントが更新されていないなどでお困りのことがございましたらご相談ください。

教育支援

人材不足であるソフトウェア業界では教育不足も課題です。十分な教育を受けていない、知識やスキルが不足したメンバーがプロジェクトにアサインされることは品質の低下につながります。反対に、プロジェクトを牽引できるスキルを持ったPMが多く在籍するようになればプロジェクトは安定し、品質も安定するでしょう。

QualityCubeはQualityRoomという「品質向上のためのジム」をイメージした教育サービスをご提供しております。研修内容はITリテラシーからDX推進、セキュリティ、品質マネジメント、文書作成、業務フロー図作成と、必要なITスキルに応じて多岐に渡っており、研修形態は集合研修、Web研修、eラーニングとご用意がございます。QualityRoomの研修コンテンツは、これまで携わったプロジェクトの中で、実際に教育のニーズがあったものであり、多くの開発現場で起きる問題を具体例として挙げ、実践的な解決方法のポイントをわかりやすくまとめています。人材不足だからこそ、納期に追われているからこそ、教育はアウトソースして効率的にヒューマンスキルを高め、品質を向上させましょう。

＞QualityRoomの研修一覧はこちら

QualityCubeの特徴

品質コンサルティングサービスを提供している企業は、世の中にまだそれほど多くありません。しかしながら他にも開発プロジェクトのコンサルティングを行っている企業はあります。他社とQualityCubeの違いはどのようなことなのか？QualityCubeの強みについてご紹介します。

１．あらゆる業界のフローを熟知

QualityCubeはこれまでに、製造業、建設業、金融業、サービス業、情報通信業、物流業、エネルギー業界、自治体など、様々な業界でのご支援を通じて、あらゆる業界のフローをナレッジとして蓄積しています。
「あらゆる業界フローを把握している」ことが強みの一つです。

２．超上流工程の品質に精通

QualityCubeは品質コンサルティングをコアコンピタンスとしており、品質の源泉となる超上流工程の品質に精通していることが二つめの強みです。超上流工程に精通した人材は不足しており、品質の源泉だからこそプロの力を借りることをおすすめします。

３．SDLC（システム開発ライフサイクル）に沿った様々なサービス提供が可能

QualityCubeは、SDLC(ソフトウェアライフサイクル)に沿った品質向上策として、戦略からマネジメント、実務まで様々なサービス提供が可能です。また、成果物を納品して終わりではなく、品質向上に対する施策が定着するまで併走型支援をモットーとしています。

４．第三者的な立場で中立性を担保

QualityCubeは独立系であり、特定の会社との利害関係はありません。そのため特定のシステム開発会社や製品、サービスに限定されることなく、第三者的な立場での評価が可能です。コンサルティング会社の本来あるべき姿として、公正中立な立ち位置でご支援いたします。

５．圧倒的なコストパフォーマンス

弊社は大企業様のみならず、中小企業様へのお役立ちを強く意識しており、サービス内容を損なわないことを前提にコンサルフィーを極限まで抑えています。そのため、大手コンサルティングファーム様との比較において大幅な費用減が見込めるものと自負しています。

６．拠点拡大中

2023年5月より島根県の出雲にて、新たな支店を開設する運びとなりました。
当社はITコンサルティングや品質マネジメントを通じて、製品やサービスの品質向上に向けてサポートを行います。
今後も主要都市（札幌、仙台、広島、福岡）を中心に拠点拡大を行い、地域密着をモットーとした実現性の高いサービスを拡充していきます。

品質コンサルティング導入のメリット

QualityCubeの品質コンサルティングを導入することにより以下のようなメリットがあります。

コンサルタントにサポートを依頼する費用はかかりますが、費用を上回るメリットを享受することができます。QualityCubeのコンサルティング費用は大手コンサルティング会社様と比較して、期待を上回るコストパフォーマンスをご提供できると自負しております。お見積りのみでも歓迎しておりますのでご比較ください。

一度コンサルタントから受けた知識や技術はそこで終わりではありません。それらは社内で活用いただくことにより、コンサルティングを受けた企業様の資産として長く有効活用することができます。QualityCubeはプロジェクトに伴走し、企業様が品質向上のためのPDCAを自走して回せるようになるまでサポートいたします。詳しいサポート内容がお知りになりたい方は、30分程度でサービスのご説明をさせていただきます。お気軽にお問い合わせください。

サポートサービス導入の流れ

ここからはサポートサービス導入をご検討されている方向けに導入までの流れをご説明させていただきます。
下図のようにまずはITコンサルタントが貴社の抱えるDX課題を30分程度ヒアリングいたします。その後、貴社の課題に沿ったサポートプランのご提案とお見積りをいたします。ご契約から導入までは最短1か月程度です。
※人材教育プランは1週間程度の準備期間でご提供できるものがございます。

大手企業様から中小企業様まで多くのサポート実績がございます。開発プロジェクトのお悩みはQualitCubeにお任せください。

ドキュメント作成の目的

まず始めに、ドキュメント作成の目的について解説していきます。
ドキュメント作成の目的は、後述するドキュメントの種類によって違ってきますが、大きな括りとしては「コミュニケーションを円滑にするためのもの」であると言えます。
どのようなコミュニケーションを円滑にするのかという観点で３つに分類することができますので、それぞれ見ていきましょう。

１．開発側とクライアントのすり合わせ

システムやソフトウェアを開発するエンジニアとクライアントの間には、ITに関する知識量に差があることがほとんどなのではないでしょうか。
そのため、エンジニアが普段使い慣れているIT用語もクライアントにとっては耳慣れない言葉かもしれません。
両者が口頭のみでやりとりをすると「言った言わない」といったトラブルや、「言わなくてもやってくれると思っていた」などの認識齟齬が起こりやすくなります。
そもそも開発側とクライアントが共通の完成イメージを持つことができなければ、プロジェクトは失敗となるため、このようなトラブルを防止するためにも必ずドキュメントを作成し、予算・要件・デザイン・機能・納期などを明確にします。

２．プロジェクトメンバー間の意思疎通

多くの開発現場では、最初から最後までひとりが担当することはなく、開発規模に合わせて複数人がプロジェクトに関わります。
また、開発フェーズに合わせて適した技術者が担当することが一般的なので、工程をまたぐときに担当者が変わることになります。
工程移行する際に滞りなく引継ぎが行えるよう、また、開発途中で仕様変更が生じた際にも漏れなく情報共有できるよう、記録として残すためにドキュメントを作成します。

３．保守・運用の業務引継ぎ

システムやソフトウェアの完成後、実際に運用してみると、想定していなかったトラブルが起きたり、バグが見つかったりすることがあります。
このようなトラブルやバグは随時修正していく必要があり、該当するシステムがどのように構築され、どのようなテストを実施したのかといった経緯を把握しておかなければなりません。
ドキュメントがあれば、修正点をすばやく発見することができ、修正でどのような変更を行ったかを記録として残すことにより、保守・運用担当者が変更になる際にも引継ぎをスムーズに行うことができます。

ドキュメントの種類

一般的な「ドキュメント」が意味するものは記録物や文書ですが、システム開発におけるドキュメントは主に設計書や仕様書、マニュアルなどを指します。
仕様書と設計書の違いについて触れておくと、「仕様書」は完成までの制作工程を明確にしたもので、「設計書」は完成イメージを明確にするためのものになります。

ドキュメントは各工程ごとに作成するため、複数種類ありますが、今回はシステム開発における一般的なドキュメントについて解説いたします。

RFP(提案依頼書)

RFPはRequest for Proposalの略称で提案依頼書とも呼ばれます。
RFPはクライアントが開発側に業務を委託するにあたり、具体的な提案を依頼するために作成するものであり、以下のような情報が記載されています。

• プロジェクトの概要
• システムの要件
• システムの評価基準
• システムの目的や概要
• 制約条件
• 開発の目的、目標、予算、スケジュール
• 提案を依頼したい範囲、役割分担、必須な機能、運用・保守、成果物

これらは5W1Hで明記するのが基本です。
RFPに対する開発側からの回答として、具体的な提案や正確な見積もり金額などが明記されます。

要件定義書

要件定義書はRFP(提案依頼書)の内容であるクライアントの要望を基に、システムが満たすべき性能や機能を明確にしたものになります。

要件定義書には以下のような情報が記載されています。

• システムの概要（目的・背景・課題・解決策）
• 業務要件（業務フロー）
• 機能要件（必要な機能）
• 非機能要件（セキュリティ・性能・運用）
• 実行計画（開発の計画）

要件定義書はクライアントの要求に応えるための羅針盤の役目を果たすものであり、基本設計や詳細設計のベースとなります。
「要件定義」と似た言葉で「要求定義」があり混同しやすいですが、要求定義書はクライアントの「要望・希望」を記載したものであり、要件定義は、クライアントの要望・希望を実現可能にするために「具体的な機能や要件」としてまとめたものになります。

ブログ

続きを読む要求定義│要件定義との違いや品質を高める進め方・書き方まで網羅的に解説

システム開発の要求定義について、要求定義書と要件定義書・RFPとの違いから品質を高める要求定義の進め方・書き方、記述内容に至るまで網羅的に解説します。よいシステムを開発するには、考え方や進め方も含め、目的に合わせて変化していく必要があります。...

基本設計

基本設計は、要件定義でまとめた内容を実現するためにシステムやソフトウェアに実装する機能を具体化したものです。
画面レイアウト、ボタンの配置、出力する帳票、データ処理設計、システムの連携方法などを記載します。

基本設計には以下のような情報が記載されています。

• 画面設計書
• 帳票設計書
• バッチ設計書
• データベース設計書
• 外部インターフェース設計書

詳細設計

詳細設計は基本設計の内容をさらに細分化し、エンジニアが実装しやすいように内部構造や仕様を示したものです。

詳細設計には以下のような情報が記載されています。

• クラス図
• シーケンス図
• ステートマシン図

基本設計は外から見たシステムの動きを記すのに対し、詳細設計はシステムの内部まで詳細に示すため、基本設計は「外部設計」詳細設計は「内部設計」とも呼ばれます。
基本設計はクライアント向けに作成しますので、難しいIT用語は使わず読みやすい記述を心掛けることが重要です。詳細設計はエンジニアに向けた指示書になりますので、IT専門用語が多い記述になります。

テスト仕様書/報告書

テスト仕様書は、テストをどのように実施するのかを記したものです。
テストは、単体テスト・結合テスト・総合テストと３つに分かれています。
単体テストではプログラムを単体で動かし、結合テストでは各プログラムをつなぎ合わせて、総合テストでは総合的に操作して正しく動くか検証します。
それぞれのテスト項目をまとめたものがテスト仕様書で、テスト結果がテスト報告書になります。

テスト仕様書には以下のような情報が記載されています。

• テスト条件
• テスト実施手順
• テスト期待結果
• テスト実施担当者
• テスト実施端末
• テスト実施日
• 判定結果

運用マニュアル

運用マニュアルは、クライアントが一連の運用ができるよう手順や説明を記載したものです。
運用マニュアルは主に次の3つの項目から構成されています。

• 業務マニュアル・・・システムの一連の流れについて可視化し、業務全体を把握するためのもの
• 操作マニュアル・・・実際にシステムを操作するために、具体的に手順が記載されたもの
• 障害対応マニュアル・・・障害発生時に迅速に対応できるよう備えたもの

マニュアルは業務に精通した担当者が作成することが多いですが、マニュアルを一番よく使うのは業務に詳しくない担当者です。
確認したい作業が検索しやすいことや、初心者目線でわかりやすい内容であることが求められます。

ドキュメントの重要性

これまで解説してきたように、ドキュメントは認識齟齬の防止 ・開発遅延の防止 ・運用の負担軽減など各フェーズで役割があります。
アジャイル開発においても、このようなメリットを享受するためにドキュメントを作成することをおすすめします。
むしろ効率を重視するアジャイル開発だからこそ、作成したほうが良いと言えるでしょう。
反対に、もしこれらのドキュメントが無い場合や、きちんと管理されていない場合、様々なトラブルが想定されます。

ドキュメントに関わるトラブル

ドキュメントに関わるトラブルとはどういったことが考えられるでしょうか。

要件定義書の内容があいまい

システムやソフトウェアは「機能」であり、直接目に見えるものではありません。
ですので、それがクライアントの要望に沿ったものになっているのか否かは、機能を可視化したドキュメントによって判断します。
要件定義書があいまいで分かりにくい場合は、設計者が本来の意図と異なる解釈をしてしまう可能性があり、手戻りの原因となります。

保守・運用に必要なドキュメントが残っていない

運用開始後にシステム障害や、致命的な不具合が発生したときに、誰が何をするというような役割分担や、手順が無い場合、復旧に遅れが出たり、責任の擦り付け合いになったりなどの二次トラブルが発生する可能性があります。

実装されているシステムの状態と設計書に乖離がある

リリースを急ぐあまり、設計・実装・テストに工数を優先的にかけてしまい、ドキュメント作成、更新に時間をとることができないということもよく耳にします。
しかし、機能拡張や改修を重ねると構造が複雑化していくため、すでに実装した機能にどのような意図があるのかといった情報を残すことは必要不可欠です。
ドキュメントが最新になっていない場合、調査に時間を必要以上に要してしまったり、影響範囲の特定ができなくなったりします。

まとめ

以上、ドキュメント作成の目的と重要性について解説してまいりました。
ドキュメント作成は工数もかかりますが、それに見合うメリットやドキュメントを作らなかった時のリスクがあることをおわかりいただけたのではないでしょうか。

弊社、株式会社QualityCubeはシステム、ソフトウェアの品質向上を使命として、様々な業界のプロジェクトをサポートさせていただいているIT品質コンサルタントであり、ドキュメントに関しても開発スピードを落とさず、効率よく作成できる方法をご紹介しております。

「ドキュメント作成のコツ」について知りたい方は、ぜひこちらのダウンロード資料をご活用ください。

より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。

• システム開発で作成するドキュメントにおいて、定型のテンプレートがない
• ドキュメントがテンプレート化されていないため、項目をその都度考えて作成しなければならず効率が悪い
• ドキュメントがテンプレート化されていないため、ドキュメントの粒度や項目が人によって異なり、考慮漏れが発生している
• ドキュメントがテンプレート化されておらず定型でないため、レビューアへの負担が大きい。また、レビュー効率やレビュー精度の低下を招いている

2022年12月、経済産業省と独立行政法人情報処理推進機構（IPA）は、企業・組織のDX推進を人材のスキル面から支援するため、個人の学習や企業の人材育成・採用の指針である「デジタルスキル標準（DSS）」を取りまとめました。
掲載記事ではそのあらましと活用のポイントについて、企業担当者にもわかりやすく解説しています。
購読されていらっしゃる方はぜひご一読ください。

また、弊社のDX人材教育サービスであるQualityRoomのWebサイトでも「デジタルスキル標準(DSS)」について、わかりやすく解説したブログを掲載しています。
デジタル化が加速しているビジネス社会においてどのような人材が求められるのか、ビジネスパーソンである皆様に知っておいていただきたい内容です。

QuaityRoomブログ

■DX人材不足解決に向けて　経産省(IPA)が公表した「デジタルスキル標準」とは何か？

■経産省(IPA)が公表した、ビジネスパーソン全てが身に着けるべき「DXリテラシー標準」とは何か？

■DX推進スキルの見える化によって日本企業のDXが加速する？経産省(IPA)公表の「DX推進スキル標準」とは何か？

QualityCubeでは「デジタルスキル標準(DSS)」に準拠した教育サービスを提供しております。
ご提供の際には弊社のITコンサルタントがヒアリングを行い、教育対象のITレベル、業種業界、ご予算に合わせた適切なプランを設計いたします。
ご相談、お見積りは無料です。
まずはお気軽にご相談ください。

ご相談窓口／お見積り
https://qualitycube.jp/service-inquiry/

組織の業務効率化を検討されている方々が多いのではないでしょうか。業務効率化はDX推進で解決します。一方、DX推進自体に課題を抱える企業も多いです。「人材がいない」「予算がない」「進め方がわからない」などの課題が挙げられます。

今回は、業務効率化を達成するためのDX推進のポイントを解説します。
「業務フローの書き方ガイド」、「DX企画ガイド」をダウンロードして進めましょう。

業務効率化の課題抽出と、DX推進のポイント

（1）社内の課題業務効率化課題を明確にする（※小さな課題の解決から取り組む）

（2）DXに関する情報共有を進める

（3）DX推進に適切な人材を配置し進める

社内の業務効率化課題の明確化

社内の課題は、可視化し、明確にすることが業務効率化を進めるための第一歩です。
DX化のためツールを導入する企業は増えていますが、導入したことだけ効果の見える化をしていない企業が多いです。

業務を可視化するためには、業務フローを整理することが必須です。
「業務フローの書き方ガイド」は下記ボタンから無料ダウンロードできますので、資料を参照して業務フローを書いてみましょう。

業務フローが作成できたら、チームで議論し、現在の業務フローでどこに課題があるのか抽出して下さい。業務効率化のためには、ムダな業務、ミスの起きやすい業務、人手がかかって時間のかかる業務、定型業務に注目して、改善点を洗い出して下さい。

解決策の案リストを列挙できたら、結果が把握できるデータを見つけだし、改善後結果を定量的に管理できる様にします。ビジネスモデルのゴールを明確化し、ゴールに近づける様にPDCAを回すことが重要です。

DX活動の情報共有

DX推進は経営陣のリーダーシップで進めるべきです。DX推進者は経営陣と密に情報共有しながらDX企画を進めます。

DX企画時から、社内でDX活動の情報共有をすることも重要です。DX推進過程では現場社員から不安や疑問がでてくることがあります。そのため、早い段階からDXを適用する事業部門長の協力を得る根回しも必要となります。社内で共通意識を持つために、定期的な情報共有の場を設けて下さい。　

推進過程で考え方にズレが生じている場合があるので、DX推進前には、しっかりとお互いが理解しあう環境を整えておきましょう。担当分けとそれぞれの活動内容、責任分野も明確化しておくと良いです。

DX推進に適切な人材配置

最後に、DX推進に適切な人材を配置することです。

DXツールの活用はIT技術や知識を持っている人でなければ推進が難しいため、一定レベルのITスキルを持った人材の育成が必要です。DX化に対して明確な計画や予算を用意しても、推進者のスキルが伴わないとプロジェクトは進みません。知識レベルでは業務効率化とDXの関係を良く理解し、プロジェクトマネジメント力を備えた人材を揃える必要があります。

日本の企業で業務効率化が進まない理由

日本企業の特異性

日本で業務効率化が進まない理由として、長時間労働に依存する経営が原因と考えられています。日本と諸外国では、雇用される従業員の在り方に大きな差があります。職務内容で受け取る賃金が決まる諸外国に対して、日本では時間単位での給与計算、残業も当たり前という風潮が残っている企業が多いです。

職務範囲を超えた仕事をこなす従業員の個々の裁量を頼りに収益を上げているケースが多く、企業ではコストをかけてまで組織としての業務効率化を感じていないのではないでしょうか。

実は日本の生産性はとても低いです。OECDデータに基づく日本の時間当たり労働生産性は、47.9ドル（4,866円／購買力平価（PPP）換算）。米国（77.0ドル／7,816円）の約6割の水準に相当し、順位はOECD加盟37カ国中21位となっています。主要先進7カ国でみると、データが取得可能な1970年以降、最下位の状況が続いています。

DX推進効用

DX推進がなぜ、業務効率化につながるのでしょうか。主な理由には以下のようなもの挙げられます。

新しいシステムにより業務のスピード向上

業務効率化につながる要因として、新しいシステムの導入によるスピードアップが挙げられます。老朽化したシステムは運用や保守に莫大な費用が発生することもあり、処理スピードが遅いことも多く、業務が思うように進まないこともあります。

DX推進ではクラウド、IoT、AI、5G、ビッグデータなど、新しい技術とシステムを導入することで、処理スピードのアップに加え作業の自動化なども見込め、業務効率化が望めます。作業の自動化によって空いた人手を他の高付加価値な仕事に回すことができ、さらに生産性が向上するという好循環が生み出せます。

正確な分析が可能

DXが業務効率化につながる要因の一つとして、正確な分析が可能になることが挙げられます。DXではRPAなどの自動化を目指すツールの他にBIツール（ビジネスインテリジェンスを行うアプリケーションソフトウェア）との連携ができるオプションもあり、分析結果を確認できる様になっています。

今ある現状を分析できない企業は、これまでのやり方のままではニーズに応えることはできません。企業が商品を提供し利用者が選択する時代から、利用者のニーズに合う付加価値を提供していく時代に適応する必要があると言えます。スマートフォンの普及によって利用者が情報を得るスピードが格段に上がり、企業側は利用者のニーズを見つけるために、膨大な情報を収集して分析する必要が生じます。これを人手で実施するのは厳しく、DXによって分析をスピーディーかつ正確に行えるようにすることで、ニーズに応えやすい環境を整えることができます。

そのため、ビッグデータの活用もさることながら、BIツールによる分析を意思決定に用いることはもはや企業価値を高める上で必要な手法となってきます。

データが一元化され管理・共有しやすくなる

DXによってデータの一元管理や共有することも、業務効率化につながります。

DXは部門毎に導入する先には組織全体、全社的な取り組むになって大きな効果を生みます。部門ごとにシステムが分かれていることも多いのですが、社内DX化でデータを一括管理の方向に進むため、部門間の連携がスムーズになるのもメリットです。システム管理により、人的ミスが減り、チェック作業の負担も軽減されます。また、組織間で二重に行っていた業務も共通プラットフォームで一元化されます。

業務効率化に役立つデジタル技術

DXで用いられるデジタル技術4つに分けられます。

2025年の崖とは

DXへの取り組みが推奨されるのも、「2025年の崖」と呼ばれるリスクを避けるためでもあります。
「2025年の崖」とは、経済産業省が2018年に発表した「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」が注目を集めました。

多くの企業でITシステムが導入されていますが、2025年前後に既存システムが老朽化して運用・保守が難しくなることが想定されます。例えばSAPの2027年問題があります。SAP社は既存のSAP ERP 6.0の保守期限を2027年末までとする発表をしました。他にも基幹システムの保守期限を調べておく必要があります。さらに，2025年前後にはシステムの運用・保守を行える人材が定年退職を迎えることもあり、既存システムを動かせる人材の確保が難しくなり、データの活用ができなくなる恐れがあります。2025年までに、ITシステムに関連するさまざまな変化に対応できなければ、企業の競争力は崖を下るように低下すると考えられています。
2025年以降は最大で年間12兆円の損失をもたらす可能性が指摘されていて、これらの問題が「2025年の崖」です。

※出典元：経済産業省「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」

DX企画ガイドをダウンロード

これからDX推進を担われる方々は、是非、下記ダウンロードボタンから「DX企画ガイド」をダウンロードして、参考にして下さい。

弊社、株式会社QualityCubeではDXの企画からITシステムの導入、運用までサポートさせていただきます。

本記事では、要件定義をスムーズに進めるためのコツから、「良い要件定義書」を書くための重要ポイントまで徹底解説いたします。

要件定義書・要件仕様書とは？関連ドキュメントの違い

システム開発やDXプロジェクトでは、「要件定義書」「要件仕様書」「要求定義書」「要求仕様書」など、似た名称のドキュメントが数多く登場します。しかし、これらは作成目的や視点、関与する関係者が異なり、同じ意味で扱ってしまうとプロジェクト内で認識のずれが生じやすくなります。

本章では、それぞれの役割を工程視点で整理し、要件定義書がどの位置づけにある資料なのかを明確にします。

要件定義とは何か

要件定義とは、業務上の課題や目的を踏まえ、「システムで何を実現するのか」「どこまでを対象範囲とするのか」を明確にする工程を指します。単に機能を列挙する作業ではなく、業務要件・機能要件・非機能要件を整理し、関係者の合意を形成するプロセスとして捉えることが重要です。

要件定義の段階では、業務担当者・IT部門・ベンダーなど複数の立場が関わるため、専門用語に偏らず共通理解を得られる表現が求められます。また、この工程で整理された内容が後続の設計や開発の前提条件となるため、目的や背景を含めた整理が欠かせません。

要件定義書と要件仕様書の違い

要件定義書と要件仕様書は名称が似ているため混同されがちですが、目的や利用される工程、読み手の視点が異なります。

要件定義書は、業務課題やシステム化の目的、対象範囲を整理し、関係者全体の共通理解をつくるための資料です。一方、要件仕様書は、設計や開発に向けて機能や条件をより具体的に整理するドキュメントとして扱われることが多く、技術的な観点が強くなります。

プロジェクトを円滑に進めるためには、両者の役割を分けて理解しておくことが重要です。

このように、要件定義書は「何を実現するか」を共有する資料であり、要件仕様書は「どのように実現するか」に近づくための整理といえます。実務では両者が一体化している場合もありますが、役割の違いを意識して使い分けることで、関係者間の認識齟齬を防ぎやすくなります。

要求定義書・要求仕様書との違い

要求定義書や要求仕様書は、ユーザー側や業務部門の視点で「実現したいこと」や「期待する成果」を整理した資料として扱われるケースが多くあります。システム要件として具体化する前段階で作成されることもあり、現場の課題やニーズを言語化する役割を担います。

名称は似ていますが、要件定義書とは整理の粒度や立場が異なる点に注意が必要です。

要求定義書や要求仕様書は、あくまで「要求」をまとめた資料であり、その内容をもとにシステム視点で整理し直したものが要件定義書と考えると理解しやすくなります。企業やプロジェクトによって用語の使い方は異なるため、名称だけで判断せず、誰がどの目的で作成した資料なのかを確認することが大切です。

案件定義書との関係

案件定義書という呼び方が使われることもありますが、一般的な開発プロセスで正式な工程名称として定義されているわけではありません。プロジェクトの背景やスコープ、予算感などを整理する初期資料として扱われるケースが多く、要件定義に進む前の検討段階で作成されることがあります。 要件定義書との違いは、システム要件そのものよりも「案件として成立するか」「どのような方向性で進めるか」といった検討内容が中心になる点です。実務では、案件定義書で方向性を固めた後に要件定義書へと落とし込む流れを取ることもあり、両者は連続したプロセスの中で整理される資料といえるでしょう。

要件定義書の作成の進め方

要件定義書は、思いついた内容を書き並べるだけでは実務で使える成果物にはなりません。現状の業務やシステムの前提を整理し、課題や要求を段階的に具体化しながら、関係者の合意を形成していくプロセスとして捉えることが重要です。

本章では、要件定義書を作成する際の基本的な流れを、実務での進め方に沿って整理します。

現状業務とシステムの整理

要件定義の初期段階では、現行の業務構造やシステム環境を俯瞰的に整理し、「どの前提で要件を検討するのか」を明確にします。

既存フローを理解すること自体が目的ではなく、業務の役割分担やデータの流れ、システム間の関係性を整理し、後続の要件検討の土台をつくることが重要です。

整理を通じて、要件定義の前提条件を関係者間で共有できるようになります。業務ヒアリングや既存資料の確認をしながら、構造的な視点で情報を整理しておくことが、後工程の手戻りを防ぐポイントです。

課題・要求の深掘りと優先順位づけ

現状を整理した後は、関係者から挙がった課題や要求を具体的に掘り下げ、優先度を整理していきます。単なる要望の羅列ではなく、業務への影響度や実現可能性を踏まえた判断が求められます。

• 業務上のボトルネックや非効率な作業を洗い出す
• 部署ごとの目的や期待値を明確にする
• 現行システムで実現できていない理由を確認する
• 短期対応と中長期施策を切り分ける
• コストや影響範囲を踏まえて優先順位を決める

要求の背景を理解せずに優先順位を決めてしまうと、本来解決すべき課題から外れてしまう可能性があります。関係者との対話を重ねながら整理することで、実務に即した要件につながるでしょう。

要件の分類と文書化の手順

整理された要求は、業務要件・機能要件・非機能要件といった形で分類し、要件定義書として構造化していきましょう。表現の美しさよりも、要件の粒度や関係性をそろえることが重要です。

• 要求内容を業務要件・機能要件・非機能要件に振り分ける
• 抽象的な表現を避け、条件や判断基準を明確にする
• 重複や矛盾がないかを確認する
• 用語や表現をプロジェクト内で統一する
• 管理番号や変更履歴をつけ、追跡可能にする

要件の分類を意識して文書化することで、設計工程へ引き渡した際の解釈のずれを防ぎやすくなります。要件定義書は単なる記録ではなく、後工程の基準となるドキュメントとして整理していくことが大切です。

関係者との合意形成

要件定義書は作成して終わりではなく、関係者間で認識をそろえて初めて有効な成果物になります。業務部門、IT部門、開発担当者など、それぞれの立場によって重視する観点が異なるため、レビューやディスカッションを通じて意図を共有することが重要です。 合意形成では、細かな仕様の是非だけでなく、「対象範囲は適切か」「優先順位に納得できているか」といった視点を確認します。最終的に承認プロセスを経て確定させることで、後工程の判断基準として活用できる状態になるのです。

要件定義をスムーズに進める３つのコツ

「要件定義は難易度が高い」と言われる理由として、成果物となる「要件定義書」に書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある、というのがあります。（「要件定義書」については後項で解説します。）

QualityCubeではこれまでのご支援経験から、以下の３つを「要件定義をスムーズに進めるためのコツ」と考えました。

• 既存の業務フローとシステムについて知る
• 要求定義書と要件定義書のすり合わせをする
• 開発担当者を明確にしておく

既存の業務フローとシステムについて知る

発注者の要望は実に様々ですが、システムや業務フローに課題があり、直面している問題を解決したいという要求は少なくありません。
したがって要件定義段階でまず必要になるのは、現在用いられているフローや既に使われているシステムを正しく理解することです。そのうえでどこに課題があり、どのように解決するべきかを明確にします。
なかには、現行システムの設計書通りに業務を行っていないケースもあるので特に注意が必要です。

要求定義書と要件定義書のすり合わせをする

システム開発において、発注者が作成するドキュメント書類を「要求定義書」、この発注者の要求をもとに開発者が作成する書類を「要件定義書」と呼びます。
要求定義書では、発注者が解決したいと考えている課題や、導入したいシステムについての要求をまとめるのに対して、要件定義書では開発者の視点で要件や作業工程を決めていきます。
発注者の描いた夢をもとに、開発者が理想となるシステムの姿を整理していくのです。

しかしながら、プロジェクトによっては発注者が要求定義書を作成していないケースもあり、その場合、発注者に対して開発者がヒアリングを行うことで要求を把握する必要があるので、注意が必要です。

こうして要件定義書が完成したら、漏れがないか発注者と開発担当者とで認識合わせをすることが重要です。
一般的なウォーターフォール型開発では、手戻りが重大なタイムロスになりますから、要件定義の段階でしっかりと作り込みを行うことで手戻りを防いでいきます。

開発担当者を明確にしておく

プロジェクトの開発担当者を明確に決めておくことも重要です。
他のプロジェクトと兼務の開発者は、当プロジェクトにどのくらいの工数を割けるか、明確にしておきます。曖昧なままにしておくと、後々コミュニケーションのすれ違いが増えていく可能性があります。ムダな調整が増えると、本来するべき業務の進行に支障が出る可能性があります。
したがってこの段階で役割分担を明確にしておき、開発担当者が不明確なままの業務をなくします。
開発固定のタスクに関して開発担当者と責任分担が適切に決まっていれば、不要な業務で工数を圧迫する恐れもなくなります。
そのためには、WBS（Work Breakdown Structure：作業分解構成図）を作成し、誰がいつまでに、何を完成させるかを明確にしましょう。

上記の３つをしっかりと守れているかどうかが、要件定義の成否を分けると言っても過言ではありません。
貴社の要件定義はどうでしょうか？照らし合わせてみてください。

要件定義の成果物：「要件定義書」

ここでは、前項で触れた「要件定義書」について解説していきます。
冒頭でご紹介した別エントリでも述べていますが、改めて「要件定義書」とは、要件定義において成果物とされるドキュメント書類の名称です。
前項で「書くべき内容がはっきりと定義されておらず、プロジェクトによって差異がある」ことが難しいと言われる理由と述べましたが、QualityCubeが「要件定義書に書くことが望ましい項目（中身）」として挙げているのは、主に以下の通りです。

要件定義書に記載すべき必須項目

またその中でも、とりわけ必ず記載すべき「必須項目」と言えるものは次の4項目です。

• システム概要：目的や目標を決める
• 業務要件：業務フローを作成する
• 機能要件：必要となる機能を決める
• 非機能要件：システムの裏側を決める

システム概要：目的や目標を決める

システム概要には、「システム開発に至った背景」や「システム開発の目的と目標」の記載が必須です。
目的は、「システム開発によってどのような効果や結果を求めるか」という内容。
目標は、それが「どのような結果になったとき達成されたといえるか」を定義する指標です。
定量的なゴールを定めておくことで、発注者とシステム開発者、また関係者全員の認識に齟齬が発生しないようにしておくことが大事です。

業務要件：業務フローを作成する

システム開発の目的と目標を達成するには、実際の業務はどうあるべきかを考えます。
業務の流れを文書で書くと非常に分かりづらいため、ここでは「業務フロー」を作るのがよいでしょう。
まずは「現状の業務フロー（As-Is）」を作成してから、「システム稼働後の業務フロー（To-Be）」を作れば、システム稼働前・稼働後のフローが明確になります。

機能要件：必要な機能を決める

業務要件で決めた「何をどのように使うのか」ということに対して、「システムがどのような情報を管理したり処理したりすればよいか」を規定するのが機能要件です。
機能要件でありがちな失敗として、「開発者だけで決める方式をとってしまうこと」が挙げられます。
忘れてはいけないのが、発注者の要求こそが開発の大前提であるという点です。
システム課題はもちろん重要ですが、それだけを優先するのではなく、「発注者が実際にどう使うのか」を確認しながら、使いやすさ、必要な機能が備わっているか、を十分検討してください。

非機能要件：システムの裏側を決める

機能要件が「発注者の目に触れる機能」であるのに対し、非機能要件はシステムの品質や性能という「システムの裏側を決めること」です。
どのシステム開発でも、非機能要件で検討すべき内容は同じである場合が多いです。
ここはすでにあるフォーマットを使うことで、資料作成や事項の抽出にかかるコストを削減しましょう。

では、この必須項目のうち「業務要件」「機能要件」「非機能要件」の具体的な洗い出し方法について、さらに詳しく見ていきましょう。

業務要件

業務要件は、要件定義の初期に分析します。
システム化に先立ち、現状の業務がどのように流れているかを分析し問題を抽出した上で、新たに何を実現すべきかを決めていきます。この段階ではシステムはあまり意識せず、あくまで「業務そのもの」に焦点を当てます。
業務要件では、業務に詳しい発注側の関係者に参加してもらい、高いコミュニケーションを図ることが必要です。ここで発注者と開発者間で目的が噛み合わないままスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながるため、丁寧なヒアリングを行うことが肝となります。

業務フローの作成には、弊社がお役立ち資料として無料公開している「業務フローの書き方ガイド」を、ぜひ参考にしてください。

機能要件

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。
機能要件とは、システム開発を通して最低限実現すべき機能のことを指し、発注者へのヒアリングを実施することで具体的に固めていきます。
機能要件で洗い出した成果物は、後述の非機能要件と合わせて、次工程の基本設計フェーズでの重要なインプットとなります。
機能要件の主な内容としては以下の5つがあります。（ちなみにこれは、基本設計の際に必要な情報となってきます。）

①画面要件

・画面一覧：開発時の画面を一覧化したもの

出典：IPA機能要件の合意形成ガイド画面編　P17 　

・画面遷移図：画面の流れをあらわしたもの
・画面レイアウト：画面のイメージを共有するためのもの

出典：IPA　工程成果物間の関連　P15

②帳票

・帳票一覧：開発する帳票を一覧化したもの

出典：IPA　工程成果物間の関連　P15 　

・帳票概要：帳票の出力場所や、業務上の用途を記したもの

出典：IPA　工程成果物間の関連P15

・帳票レイアウト：帳票の具体的なイメージを明確にするもの

出典：IPA　工程成果物間の関連　P15 　

③バッチ

・バッチ処理一覧：プロジェクトで開発するバッチ機能を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

④データ

・外部システム関連図：関連システムとのデータ連携を図解したもの
　（システム開発の対象となる部分を色分けし、どのシステムに影響を及ぼす可能性があるのか整理する）

出典：IPA　工程成果物間の関連　P15 　

⑤外部インターフェース要件

・外部インターフェース一覧：関連システムとのデータ連携を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

外部インターフェース定義書：関連システムとのデータのやりとりについて、主要なデータ項目を一覧にまとめたもの

出典：IPA　工程成果物間の関連　P15

非機能要件

機能要件が発注者にとって必須の機能であることに対して、非機能要件は、機能以外に「あればいいな」と考える要件です。一見必要ではないように見えますが、非機能要件を実現していくことで、発注者の満足を上げることができます。システム画面の切り替え速度などは、よくある例です。

非機能要件の決定は、予算や納期を意識しつつ、発注者と合意を図ることが重要となってきます。発注者の要望を文字通りに捉えるのではなく、ヒアリングによって「なぜそれを要求するのか？」までを引き出すことで、潜在的な要求に気づくことができ、より質の高い成果物のアウトプットにつながります。
IPAの非機能要求グレードに示された６つの特性をもとに、運用方法を検討しましょう。

出典：IPA　非機能要求グレードご紹介　P6

要件定義書作成の際のポイント

要件定義書は、項目を網羅するだけでは実務で活用できる資料にはなりません。読み手の立場を意識した構成や表現、要件の具体性、変更を前提とした管理方法までを考慮することで、プロジェクトの共通認識として機能するドキュメントになります。

本章では、既存の成果物項目と重複しない視点から、要件定義書を実務で使い続けるためのポイントを整理します。

読み手に伝わる構成にする

要件定義書は、業務担当者・開発者・意思決定者など、異なる立場の関係者が参照する資料です。そのため、専門用語を減らすことだけが目的ではなく、「どの順番で情報を提示すれば判断しやすいか」という構成設計が重要になります。

例えば、背景や目的を冒頭で整理した上で対象範囲を明示し、その後に要件の詳細を記載することで、読み手は文脈を理解しながら内容を把握できます。また、章立てや見出しの粒度をそろえることで、レビュー時に確認すべきポイントが明確になります。単なる説明資料ではなく、意思決定を支援するドキュメントとして構成を設計する視点が求められます。

機能要件の具体的な書き方

機能要件を記載する際は、「何ができるか」だけでなく、「どの条件で、誰が、どのように利用するのか」を明確にすることが重要です。既存の機能要件項目では内容の種類を整理しますが、記載方法の観点に焦点を当てましょう。

抽象的な表現のまま記載してしまうと、設計段階で解釈が分かれる原因になります。操作主体、入力条件、処理内容、出力結果といった視点で文章を構造化することで、開発担当者が具体的なイメージを持ちやすくなります。

また、例外処理や制約条件をあらかじめ記載しておくことで、後工程での仕様変更を減らす効果も期待できます。

非機能要件を明確にする視点

非機能要件は、性能・可用性・セキュリティなどシステム全体の品質に関わる要素であり、機能要件と比べて抽象的になりやすい領域です。

要件定義書では、単に「高性能」「安全」といった表現にとどめず、評価基準や前提条件を整理しておくことが重要になります。

非機能要件は後回しにされがちですが、あいまいなまま進めると運用開始後のトラブルにつながることもあるでしょう。関係者と合意できる指標を意識しながら、測定可能な形で整理しておくことが重要です。

変更管理と合意形成の仕組み

要件定義書は一度作成したら固定されるものではなく、プロジェクトの進行に応じて変更が発生することを前提に管理する必要があります。変更履歴や版管理を明確にし、誰がどの判断で更新したのかを追跡できる状態にしておくことで、後から認識の食い違いが起きるリスクを減らせます。 また、変更内容を関係者へ共有する仕組みを整えておくことも重要です。レビューのタイミングや承認フローをあらかじめ決めておくことで、変更が属人的に進むことを防ぎ、プロジェクト全体としての合意形成を維持しやすくなります。

良い要件定義書の必須条件

ここまで、要件定義書に記載すべき項目について具体的に見てきました。
最後に、「良い要件定義書」とはどういうものを指すのか？要件定義を行うにあたって、QualityCubeが考える大事な条件は以下の2つです。
作成した要件定義書が以下の条件に当てはまるかどうか、ぜひ照らし合わせてください。

条件①専門知識がなくても内容が分かる

発注者はIT分野の専門知識に乏しいケースがほとんどです。
そのため、実際にシステムを利用する発注者が理解できる文章で記載されていることは非常に重要です。
書面では、IT分野に関する専門用語や専門知識を極力使わないことを心がけましょう。いくら素晴らしい内容であっても、書面の内容を理解してもらえないことには発注者側で仕上がりがイメージできず、かえって不信感を招いてしまうこともあります。
発注者のみならず、発注者の関係者が読んでも分かりやすい文章になっているか？までを意識するようにしましょう。

条件②課題に対する解決策になっている

要件定義の最終目的は、発注者からの要求をまとめるだけではありません。
発注者が何を求めているかを見定めるのはもちろんのこと、その要求をどのようにして叶えるのかという「答え」＝「課題解決策」にあたる文章を記載し、発注者に理解してもらうことが重要です。
発注者の課題を解決できていない開発は成功とはいえません。
検収時のクレームやムダなコスト増を防ぐため、この「答え」を提案することこそが求められます。

まとめ

本記事では、要件定義をスムーズに進めるための手法や、要件定義書を作成する上でのポイントをご紹介しました。まとめると以下の通りです。

要件定義をスムーズに進めるには？
発注者からヒアリングした内容をもとに、業務フロー・システムフローを把握した上で、必要な機能や非機能をわかりやすくまとめ、発注者・開発者間で認識に齟齬がないかしっかりすり合わせをしましょう。

要件定義書を作成する上でのポイントは？
発注者の要求をもとに「システム開発に至った背景」や「システム開発の目的と目標」を明確化し、そこから業務要件、機能要件、非機能要件を洗い出していきます。
要件定義書を作成する際には、実際にシステムを利用する発注者や発注者の関係者が理解しやすい文章で書くこと、発注者の要求を満たし、課題を解決するための要件定義であることを忘れないようにしましょう。

ご質問・ご要望

要件定義をうまく進め、良い要件定義書を作成するためにおさえておくべき事項は多岐にわたります。
弊社、株式会社QualityCubeでは、要件定義のスペシャリストとして「要件定義代行サービス」を提供しています。

多くの企業様をご支援してきたプロのコンサルタントが、顧客の課題に沿ったヒアリング・調査から要件定義書の作成を代行させていただくことで、QCDバランスを見ながら、プロジェクトの要である要件定義を解決に導きます。ぜひお気軽にお問い合わせください。

より詳細な情報や、貴社の状況に合わせた具体的な提案が必要な場合は、お気軽にご相談ください。例えば、以下のような課題からお問い合わせを頂くケースが多くなってきております。

• 要件定義のできる経験者のリソースが不足している
• 要件定義がうまくいっていないと感じている
• 要件定義の担当者が少ないため、プロジェクト受注を断念するケースがある
• 要件定義工程の外注を検討している

超上流工程では、経営層から情報システム部門、業務部門がそれぞれ連携しながら、システム導入で目指すべき方向性を決めていきます。
超上流工程とは何か、超上流工程の重要性を解説していきます。

以下をクリック↓

超上流工程とはなにか、システム化への第一歩を決める重要性を徹底解説

2023.1.23

システム化に向けての第一歩は「超上流工程」と言われる工程です。システムを導入する上で目指すべき方向性を決めておく必要があり、課題の洗い出しから他部署との認識共有、要求・要件定義まで...

超上流工程では、経営層から情報システム部門、業務部門がそれぞれ連携しながら、システム導入で目指すべき方向性を決めていきます。
本記事では、超上流工程とは何か、超上流工程の重要性を解説していきます。

最後までお付き合ください。

超上流工程とは

超上流工程とは、IPA（情報処理推進機構）のSEC（ソフトウェア・エンジニアリング・センター）の定義から、システムライフサイクルにおける設計などの上流工程よりもさらに上流の「システム化の方向性」「システム化計画」「要件定義」を行う工程です。

この工程では、そもそもの目的や必要な計画を明確にすることが重要になります。
ここからは、説明した3つの工程が関係してきます。

超上流工程で最も重要なことは、対象のシステムに携わるステークホルダーが積極的に参加することです。
ステークホルダーとは、経営層、システム化の対象となる業務を担う業務部門、システムの利用者、システム部門、ITベンダーなどが対象です。ちなみに「超上流工程」という言葉は日本独自のもののようです。ご存じでしたか？

超上流工程は2007年に、標準的な開発プロセス/手順のガイドライン「共通フレーム2007」として規格化され、ソフトウエア・ライフサイクル・プロセスの国際規格である「ISO/IEC 12207（JIS X 0160）」にも準拠しています。

「システム化の方向性」

システム化の方向性を決める段階では、経営方針や現場からのさまざまな課題や状況を踏まえて、システム導入で実現したい大まかな姿を定義します。

まずは社内における業務の現状や問題点の把握をし、把握した内容に優先順位をつけていきます。これにより解決すべき内容が明確になります。
そのあとは、RFP作成、ベンダーとの打ち合わせなど経て、システム化で自社が目指すべき方向性を決定する流れとなります。

「システム化計画」

システム化計画においては、前の段階で明らかにした「システム化の方向性」をより具体化します。
そのためには、要求分析を行い、システム化計画の作成をします。

要求分析は、システム化で実現したい内容を発注者へヒアリングし、言語化したものを文書化してまとめる工程です。具体的には、「現在システムを使っていないために困っていることはあるか」といった内容を主にヒアリングします。

要求分析が完了したら、システムの業務部門や情報システム部門が中心となってシステム化計画を作成します。計画には、プロジェクト体制図や導入スケジュールなど、システムへの要求以外の計画に関する内容も記載します。

「要件定義」

要件定義は、システム開発工程の中で最も重要とされる工程です。

なお、要件定義の重要性については、他のブログで触れていますので、よろしければそちらのブログも覗いてみてください。
過去ブログ↓

超上流工程で取り組むポイントとは？

【システム化の方向性】

（1）業務のプロセスを検討する

（2）検討した具体案の共通認識を持つ

主に、この2点が重要になってくる箇所です。

業務のプロセスを検討する

業務検討のプロセスでは、業務一覧や業務フロー図を作成の上、改善すべき対象を洗い出します。
システム開発担当者やその関係者が、業務の運用担当者へヒアリングを行い、現在発生している問題から根本的な改善点を見つけ出します。

ヒアリング時の注意点としては、担当者が必ずしも問題の原因を正確に理解しているとは限らず、表面的な情報が含まれている可能性も考慮し、状況に応じて深掘りをするなど、真の原因を探れるようにすることです。

また、対立的な意見を集約したり、業務のボトルネックを抽出したり、改善すべき対象のうち、どこから先に取り組むべきかの優先順位をつけたりすることも重要です。

検討した具体案の共通認識を持つ

検討した結果は、以下の項目を具体案としてまとめるようにします。
なお、まとめた具体案については、ステークホルダー全員の共通認識となるように共有しましょう。

・システム化の目的

・システム化の具体的な実現案

・プロジェクト体制の取り組み方法

【システム化計画】

システム化計画では、以下の2点をポイントとして押さえるとよいでしょう。

（1）要求をヒアリングし詳細化する

（2）必要な情報を網羅する

要求をヒアリングし詳細化する

要求分析を行うために、経営層、システム部門担当者、業務の運用担当者へのヒアリングを実施しますが、ヒアリングにて獲得した要求は、まず、ビジネス要求、システム要求、ハードウェア要求、ソフトウェア要求に分類していきます。

要求の分類が終われば、次は各々の要求を詳細化していきます。この際、顕在的な要求としての「機能要求」以外に、潜在的な要求としての「非機能要求」を意識して把握することがポイントとなります。たとえば、「遷移のスピードが何秒以内」といった要求が「非機能要求」に該当します。

ここでは、「非機能要求」の獲得を意識したヒアリングの実施とともに、バラバラな要求をひとつにまとめるための分析も重要な要素となります。

必要な情報を網羅する

システム化計画では必要な情報が網羅できるよう、計画書には必ず以下の項目を盛り込みます。

IPAにシステム化計画の事例がありますので、ご参考にください。
超上流から攻めるIT化の事例集：システム化の方向性と計画　引用

【要件定義】

要件定義では、「業務要件」「機能要件」「非機能要件」の3つの要件を必ず押さえましょう。
なお、3つの各要件定義で押さえるポイントを以下の表にまとめましたので、参考にしてみてください。

超上流工程の重要性

最後に、超上流工程の必要性について、次の2点を重要ポイントとして挙げておきます。

後工程での変更・手戻りリスクの防止

業務要件があいまいなままシステム開発を行えば、テスト段階でシステム機能の漏れや業務要求との違いが発見され、設計や開発への手戻りが発生する可能性がある。要件定義プロセスで十分に内容を詰めておけば、これらのリスクを回避することが可能になる。

ダイナミックな業務改革効果の導出

業務改革による経営効果を得るためには、経営戦略を実現するための各業務のあるべき姿を描き、現状とのギャップを明らかにしたうえで、ギャップを解消するための新しいITを活用した業務モデルを作成する必要がある。

2005年12月の『ITソリューションフロンティア』引用
野村総合研究所の水野満氏「超上流工程における検討のポイント」

まとめ

ここまで超上流工程の重要性を述べてきましたが、いかがでしたでしょうか。
最後に、今回の記事のポイントをまとめておきます。

弊社QualityCubeでは、超上流工程での品質課題に対して様々なサービス提供が可能で、要求定義の代行や要件定義の代行をはじめ、幅広くサービスをご用意しております。超上流工程での品質課題のみならず、システム開発に関するご課題やお悩みごとがございましたら、お気軽にお問い合わせください。

来年も社員一同、皆様にご満足頂けるサービスを心がける所存でございますので
より一層のご愛顧を賜りますよう、お願い申し上げます。

なお、誠に勝手ながら、年末年始は下記の日程で休業させていただきます。

◆年末年始休業　2022年12月29日（木）19時　～　2023年1月3日（火）まで◆

休業中のお問い合せにつきましては、2023年1月4日（水）以降に順次対応させていただきます。
通常より回答にお時間をいただく場合がございますので、あらかじめご了承ください。
ご不便をおかけしますが、何卒ご理解いただけますと幸いでございます。

引き続き、変わらぬご愛顧をいただけますようお願い申し上げます。

「システム開発を成功させるにはどうすれば良いか」といった課題をお持ちの方でも、大抵QCDを達成するための目標が明確に立てられていないことがままあります。今回はそのような方々にお役に立てるような情報となっています。

この記事では、QCDとは何なのか、システム開発におけるQCDを達成するためのコツ、QCDを管理するためのポイントについてわかりやすく解説していきます。

QCDとは

システム開発において、欠かすことのできないのが、「QCD」です。

Qとは「Quality（品質）」を、Cとは「Cost（コスト）」を、Dとは「Delivery（納期）」を指します。あらゆるプロジェクトには人、モノ、金、情報といった資源があり、これらは優先度を考えて作業を進めることが必要です。

システム開発におけるQCDは、以下3点が重要です。

システム開発を進める際は、発注者とシステム開発者がQCDを意識してプロジェクトを進めることが重要です。
発注者側が開発者にシステム開発をすべて任せるわけではなく、常に途中段階のプロセスで、QCDを達成するという意識が大事になります。
お互いにその意識を持って進めていく上でのポイントをお伝えします。

Quality（品質）

Q（品質）の満足度向上には、「画面数」「機能数」「障害時の動作」など細部まで基準を整え、明確にすることが大切です。
例えば、「画面描画にかかる時間は2秒です」というように、設計の段階で発注者側と合意が出来ていれば、開発後に品質面で認識の齟齬が発生することはありません。

Cost（予算）

C（コスト）の満足度向上には、開発範囲（スコープ）を明確にしておくことが大切です。
その他の要望や、テスト時に発生した課題をどこまで対応するかなども具体的にしておく等、あらかじめ開発範囲を決めておき、コストに関してのクレームを減らしましょう。

Delivery（納期）

D（納期）の満足度向上には、スケジュールを詳細に分けておくことが大切です。
「A機能は○月○日からリリース」「B画面は○月○日から表示可能」など、誰が見ても分かるようにするとともに、可能な限り細かく設定しましょう。
またスケジュールを組む際、詳細まで決めておき前倒しで進めていくようなやり方もオススメです。

システム開発におけるQCDの重要ポイント

QCDの何を重視すべきかという問題は、常に付きまとう重要なポイントと思いますが、要はバランスよく管理するということに尽きます。
品質が上がれば、それだけコストが発生します。コストを抑えれば、品質が下がります。スピーディーな納期を求めれば、品質が下がる可能性も高くなります。

ここで重要となってくるのが、QCDにおける優先順位です。一般的にはシステムを開発する前に品質・コスト・納期の優先順位を付けますが、最も優先すべきものは「品質」です。なぜなら、品質が低ければ、もともと目指している目的を達成出来ないかもしれないというリスクを孕むからです。
QCDの優先順位は、実際にシステム開発に活かしてこそ価値が生まれるのです。

それでは、QCDを実際に管理するための具体的なポイントについて解説していきます。

Quality（品質）を管理するための3つのポイント

QCDの中で、最も重要視されるのは品質です。

レビューを実施する

1つ目のポイントは、「レビューを実施」することです。
品質が現時点でどのくらい担保されているか、第三者としての目線から定期的にレビューを実施する必要があります。
そして、レビューを実施する上で大切なのが「レビュー頻度」と「誰がレビューするのか」ということです。完成間近になってレビューを実施したとしても、何か問題が発生した際、納期に間に合わない可能性もでてきます。納期も視野に入れながら、定期的にレビューを実施しましょう。

誰がレビューするのかについては、実際にサービスを利用する発注者側の方にレビューしてもらうのが最も望ましい形です。システム開発者やその他の関係者がレビューを行なっても良いのですが、レビューを実施する目的は、発注者のニーズを満たすという一択です。

不具合を洗い出すためにテスト実施する

2つ目は「不具合を洗い出すためにテスト実施する」ことです。
テストに関しては1つでも多く不具合が検出できるように、網羅性の高いテストを効率的に行うことが重要となります。

また、検出した不具合は不具合管理表などにまとめて管理することも重要なことです。なぜなら、不具合管理として記録した内容は、そのシステム開発のみならず次のシステム開発時の品質向上にも役立てることができるからです。

なぜその不具合が発生したのかという原因と対策を記録しておけば、次からは同じようなミスが減少します。また、メンバーの入れ替えなどが発生した場合においても、知識共有としてその情報を活かすことが可能となります。

上流工程のリスクを把握しておく

3つ目のポイントは「上流工程のリスクを把握しておく」です。
上流工程とはシステムを開発するための前段階として、具体的には要求・要件定義や基本設計が該当します。

ここで重要なのは、開発段階で品質を低下させる可能性のあるリスクを明確にすることです。あらかじめリスクを把握することで対策を立てることが可能となります。

Cost（コスト）を管理するための3つのポイント

品質を担保しなければならないとはいえ、コストを管理しなければ、無駄な費用が発生してしまいます。

事前に予算を設定する

予算というのは、使用可能な金額の上限額を決めることです。
システム開発計画から必要なコストを算出し、予算を抑えられるのか、足りないのか比較する際、具体的な金額が必要となります。

予算が足りない場合は、機能に優先順位をつけて、縮小を図るか、予算を増やすことを検討しなければなりません。
それとは反対に予算が余る場合は、他に拡張できる機能はないか、または余った予算を他に回すなど検討事項が増えます。

見積りを正確に行う

2つ目のポイントは「見積りを正確に行う」です。見積りとは、事前に発生する可能性があるコストを予測して算出することです。
見積りはあくまで概算なので、実際にかかる費用と誤差が発生する可能性があります。

仮に開発が間に合わなかった場合、必然的に納期も間に合わなくなります。
そうなった場合、開発期間を延長せざるを得ないのですが、人件費によるコストも加算されることになります。

上記のようなケースを避けるためにも、正確な見積りを行いましょう。

コストコントロールを行う

さいごは「コストコントロールを行う」です。コストコントロールとは、予算に対してコストがオーバーしないようにコストを管理することで、システムの開発段階で定期的に行う必要があります。

開発中に想定外のことが起これば早急に対処すると思いますが、定期的にコスト管理を行っていれば、コストが超過しないような対処を検討できるかもしれませんし、もしコストが超過した場合でも即時に把握することができるので、次の対策に活かせます。

Delivery（納期）を管理するための３つのポイント

納期を早めることができれば、コスト削減につながります。

WBSを実施する

WBSとは、Work Breakdown Structureの略で、作業工程を細かく分解することを言います。
あらかじめどのような作業が発生するのかを細かに把握することで、開発時に発生する無駄な時間を削減することができます。

また、さまざまな作業にどのくらい時間がかかっているのかを把握できれば、進行中でも納期に間に合うのか予測でき、進捗把握にも役立ちます。

進捗管理を徹底する

開発者の中には、自分のタスクを少しでも早く進めたいと考え、どんどん前倒しにタスク実行をする方もおられます。しかし、システム開発は1人で行うものではなくチームで行うものですので、部分的に完成していたとしても、他の部分が欠けてしまっていては意味がありません。全体が今どうなっているのかを把握する意味でも、最低1日1回はプロジェクトメンバー内で進捗報告を実施しましょう。

マイルストーンを明確にする

マイルストーンとは、今、プロジェクトがどの地点にいるのかを把握するために役立ちます。
特に長期的なプロジェクトであれば、設定する価値があります。実際にプロジェクトが進んでいるという実感が湧いたり、いつまでに何をやらなければならないのかプロジェクトメンバー内でも明確に把握できます。

システム開発のQCDを達成するためのコツ

システム開発においてQCDを達成することは必須事項です。
品質の悪い製品や、納期に間に合わない製品が欲しいと思う人はいません。また、プロジェクト終了後に「費用が足りませんでした」と言われてもどうしようもありません。システム開発の発注者と受注者（システム開発者）が、プロジェクト完了時にお互い納得のいく結果となるよう、QCDには常に気を配っておく必要があります。次はQCD達成のコツをご紹介します。

QCDを達成するためのコツ1：発注者が積極的に関わる

【QCDとは】でもお伝えしましたが、システム開発者にQCDのすべてを任せていては、システム開発完了時に発注者が求めるものが出来上がる可能性は低くなります。繰り返しになりますが、QCDに関しては発注者も積極的に関わっていきましょう。

QCDを達成するためのコツ2：目的を明確化する

システムの機能が多く、品質の良いシステムをなるべく安く短期間で手に入れたい、と考えるのが発注者側です。
品質を担保するためには、それなりの期間が必要になります。システム開発において、期間が伸びれば費用もその分増えます。QCDの関係性をきちんと理解し、QCDの達成すべき目的を明確にしてシステム開発者と発注者で共有しておくことも、QCDを達成するためにとても重要です。

QCDを達成するためのコツ3：課題を明確にする

QCD満足度にはまず課題を明確にし、解決していくことをおすすめします。
なぜなら、QCDとは３つの項目に分かれていますが、深く関連し合っているため、一項目が伸びていたとしても、他の項目のバランスが取れなくなってしまうからです。良い項目を伸ばすよりも課題から解決した方が効果的なのです。

システム開発をより効率化していきたいのであれば、まず課題の明確化からはじめることを頭にいれておきます。

まとめ

システム開発を行う際は、QCDを達成することが必要不可欠です。プロジェクトを進めていく上で、発注者とシステム開発者が、プロジェクト完了時にお互い納得のいく結果となるよう、QCDには常に気を配ることが達成するカギとなるでしょう。

弊社は株式会社QualityCubeは上流工程を得意とする、品質向上のプロフェッショナル集団です。要求・要件定義の代行など、幅広くサービス展開しております。その他、システム開発に関わるご課題やお悩みごとがございましたら、まずは相談ください。