システム開発のためのEarly Validation&VerificationとSystems Engineering

Validation & Verification (V&V) とは？

システム開発の成功には、正確な要件の把握と実装の妥当性の検証が欠かせません。ここで重要になるのが Validation（妥当性確認）と Verification（検証）です。

Validation(妥当性確認)

「正しいことを行っているか」を確認するプロセスです。ユーザーが本当に求めているものを正しく理解し、成果物がそれを満たせているかを証明します。腕時計を例に挙げると、「高精度で見やすい腕時計が欲しい」というユーザーがいた場合、開発した時計がユーザーのニーズを正しく満たせているかを確認します。

Verification(検証)

「正しく行われているか」を確認するプロセスです。設計や仕様に基づき、システムが期待通りに動作しているかを検証します。腕時計を例に挙げると、開発した時計の針が、正確な時刻を指すよう正しく動作しているかを確認します。

これらの2つの視点を、開発ワークフローに組み込みながら進めることで、開発プロセスの無駄を省き、手戻りを最小限に抑えることができます。

システム開発で陥りやすい「大きな手戻り」

システム開発の効率化や品質向上を目指す中で、V字モデルは非常に有効なフレームワークとして知られています。このモデルでは、左側が要件定義や設計・開発といった「計画・実装段階」、右側が結合テストや受け入れテストといった「確認段階」に対応しており、各フェーズが互いに整合性を保ちながら進行します。ウォーターフォールやアジャイルといった開発手法の違いを問わず、品質保証と効率的な開発に役立つ普遍的な概念です。

TASUKIでは、特に「確認段階」に力を入れており、以下のような徹底した検証を行っています。

Pull Requestのレビュー

コードの品質を担保するため、レビュー担当者がコードの正確性や可読性を確認しており、バグや仕様の不整合を未然に防止しています。

単体テスト

各機能やモジュールが設計通りに動作するかを検証します。テスト自動化を活用し、繰り返しの検証を効率化しています。

E2E試験

システム全体が期待通りに連携して動作するかを確認し、ユーザー視点での操作性や機能の整合性を担保しています。

ユーザーインタビューによる効果検証

リリースの前段階あるいはリリース後の経過観察として、顧客やユーザーへのフィードバックを収集しています。機能が期待通りの価値を提供しているかを確認します。
 

 これらの取り組みによって、高品質なプロダクトをユーザーに届けることを目指していきます。しかしながら、プロジェクトの工程が順調に進み、最終段階である「受け入れテスト(TASUKIにおける効果検証)」に到達した際、ユーザーから「この機能は想定していたものと違う」「この仕様では実際の業務に使いにくい」といった意見をいただくことがあります。

こうしたフィードバックがある場合、すべての工程を最初からやり直す必要が生じます。

この「大きな手戻り」は、時間やコストを多分に浪費するだけでなく、プロジェクトチームの士気にも影響を及ぼすことがあります。

Early Validation & Verificationのすゝめ

システム開発において、最終段階での「大きな手戻り」を最小限に抑えるためには、開発ワークフローの早い段階で課題を特定し解決することが重要です。そのために、Early Validation（早期の妥当性確認）とEarly Verification（早期の検証）が不可欠です。これらの取り組みは、成果物の成否を大きく左右します。

Early Validation（早期の妥当性確認）

「システムがユーザーの期待に合致しているか」を開発ワークフローの早期に確認します。ここでニーズ・要求の正確性を担保します。ニーズと要求の文章化・プロトタイプを用いたユーザーインタビューなどを実施します。

Early Verification（早期の検証）

「システムが設計や仕様通りに正しく動作しているか」を開発ワークフローの早期、あるいは計画・実装の各フェーズと同時に確認します。本稿では、要件定義におけるEarly Verificationを取り上げます。要件定義のEarly Verificationでは、要件の洗い出しを行い、考慮漏れを解消します。ここでも、プロトタイプを用いてユーザビリティテストなどを実施します。

「小さな手戻り」を繰り返す

要求分析と要件定義におけるEarly V&Vの目的は、要求の正確性の担保と要件の考慮漏れ解消です。ただし、一度の要求分析と要件定義によって、その後修正無しに進むことは殆どありません。あるいは問題無く進んでいるように見えて、開発に着手してから矛盾に気づくといったケースも多々あると思います。開発ワークフローの初期段階においても、不可逆的に次のステップに進むよりも、イテレーションを推奨します。

要求分析や要件定義において、イテレーションを繰り返すことは Early V&Vを効果的に活用する鍵となります。この2つのプロセスが連携することで、以下のような相乗効果が得られます。

矛盾や漏れの早期発見

Early Validationを通じて、ユーザーの期待や要求の曖昧さを明確化し、目的に適った要件を漏れなく定義することができます。また、定義された要件をEarly Verificationで検証することで、技術的に実現不可能な点や設計の不整合を早い段階で発見できます。

柔軟かつ敏捷性の高い変更対応

初期段階で頻繁にフィードバックを得て修正することで、柔軟に要求や要件を調整可能です。発生する手戻りの規模が小さくなることで、コストを削減し、開発ワークフロー全体でスムーズに進行することができます。

ユーザー満足度の向上

Validationでユーザーのニーズを的確に把握し、Verificationでそのニーズが満たされていることを確認することで、ユーザーにとって価値のあるプロダクトのみに注力し、開発することができます。
 

例えば、要求分析の段階でユーザーインタビューを行い、仮説の要求が間違っていると判明した場合でも、その時点で修正すれば、設計や実装に進む前に対応が可能です。大きな手戻りを無くし、手戻りを最小限に抑えることが重要だと述べましたが、「小さな手戻り」を繰り返すことでワークフロー全体の効率性を高めることが必要です。

プロトタイピングの重要性

プロトタイピングは、アイディアや要件を具体化し、実際の利用シーンを想定した形で確認するための重要な手法です。

特に、要求分析や要件定義といった初期段階では不確定要素も多く、文章や口頭ではイメージが曖昧、あるいは相互の共通認識を持つことが難しく深い議論にならないことがしばしばあります。そこでプロトタイプを通じて、早期に課題を洗い出し、修正を加えていくことが重要となります。

プロトタイプを制作することによって以下の効果が得られます。

Think Deep

つくることで深く考え、内省することで具体化していきます

Communication & Various Perspective

共通のイメージを共有すること多様な人と会話し、多視点を取り入れます

Feedback

仮説検証を通して学びを得ていきます
 

プロトタイプは単なる試作ではなく、アイディアから成果物のイメージの具体化に加え、ユーザーとのコミュニケーションを深めることができるため、プロダクトの品質を高めるための重要なツールとなっています。

TASUKIでは、プロトタイピングにFigmaを活用しており、インタラクションやフローを簡易的に表現したモックアップと、視覚デザインやユーザーフローを再現したデザインカンプを制作し、Early V&Vに活用しています。

アイディアを開発可能な状態に変えるSystems Engineering

システム開発において、ユーザーのニーズを実現するためには、アイディアを「開発可能な状態」に変える必要があります。このプロセスを体系的に支援するのがシステムズエンジニアリング（Systems Engineering）です。

システムズエンジニアリング国際協議会（INCOSE）では、システムズエンジニアリングは以下のように定義されています。

システムと言うとコンピューターシステムを思い浮かべる方も多いと思いますが、システムズエンジニアリングではあらゆる幅広い分野を横断し、物事をシステム(要素間の関係性)として捉え、成果物を構成していきます。航空や宇宙、自動車といった産業においてもシステムズエンジニアリングは活用されており、大規模複雑なシステムを構築する際には欠かせない存在になっています。

機能とは？

機能という言葉はよく耳にしますが、機能という言葉を説明するとなると難しいと思います。

そこで、高校数学で習う y = f(x) という数式を例に定義してみようと思います。この f はfunctionを表しています。x という入力に対して処理を行い、y に変えるのがこの y = f(x) という数式の意味になります。

つまり、「特定の入力を受け取り、特定の出力に変換する作用やはたらき」が機能です。そのため、機能名は、「⚪︎⚪︎を△△にする機能」という形で定義した方が、どのような処理を行えば良いかというイメージがつきやすくなります。

システムとは？

システムという言葉も各個人でイメージのズレが生じやすい言葉です。筆者のシステムの定義は、「特定の目的や目標を達成するために構成された複数の構成要素が相互に連携し、統合的に機能する集合体」です。システムは要素の集合であり、要素は機能の集合であると捉えています。それらが互いに相互作用し合うことで、目的を達成するのがシステムであると考えています。

システムとして捉える

アイディアをシステムとして捉える際には、全体俯瞰と構成要素の繋がりという2つの視点を持つことが重要です。システムを単なる「機能の集合体」ではなく、目的達成のための有機的な構造として捉えるための鍵となります。

全体俯瞰

システム全体でどのように機能し、何を達成するのかという全体像を捉えます。

構成要素の繋がり

構成要素の繋がりを意識することで、機能同士の関係性や相互作用を明確化し、設計や実装段階で矛盾や不足が生じないようにします。
 

開発段階まで進むと、その機能だけに注目してしまい、システム全体や他の関連機能が見えなくなってしまうケースが多々あります。まさに「木を見て森を見ず」といった状態です。

開発に進む前に、全体俯瞰と構成要素の繋がりの二つの視点を持ちながら、全体と部分の視点を意図的に切り替えることで「木を見て森も見る」ことができ、全体最適かつ目的に適合したシステムの開発に繋がります。

システムとして図に書き起こす際、「多視点からの観察」「構造化してシンプルに」「可視化して共有」の三点を意識することが重要です。これにより、複雑な構成要素を整理し、効果的な設計や意思決定を支援するための具体的な手法が得られます。

多視点から観察する

システムを複数の視点から観察することで、全体像だけでなく、個別の構成要素や関係性も明確にします。異なる立場（ユーザー、エンジニア、営業担当など）からのニーズを考慮できます。

構造化してシンプルにする

複雑なシステムを分解して整理し、全体像を理解しやすい形に落とし込むことができます。また、設計の矛盾や、非効率な箇所を特定することができます。

可視化して共有する

システムの構造や動作を図やモデルとして視覚化し、関係者間で共通の認識を持つことができます。認識のズレを防ぎ、議論の効率化を図ることができます。
 

TASUKIでは、これらのシステムズエンジニアリングのアプローチやシステム思考を利用し、要求分析と要件定義、設計に活用しています。

Early V&VとSystems Engineeringを適用した開発ワークフロー

最後に紹介した、Early V&VとSystems Engineeringを適用した開発ワークフローについて、解説をします。

TASUKIでは、以下のような開発ワークフローで、要求分析と要件定義・概念設計を行なっています。

要求分析

ニーズ・要求の言語化

まず始めに、ニーズ・要求の言語化を行います。ここで、言語化を行うのは、要求分析の土台をつくるだけでなく、組織内で共通認識を持ちながら多様な議論を行うといった目的もあります。そのため、開発担当だけでなく、顧客接点の多いカスタマーサクセス担当やプロダクト全体の方針を決定するプロダクトマネージャーなど、分野を横断したメンバーが参加しています。

ニーズと要求の違いについては様々な見解があると思いますが、以下のように定義しています。

いきなりユーザーの要求を文章化するのはハードルが高いですが、以下のような要求分析の簡易フォーマットを利用すると比較的書き出しやすく具体化できるようになると思います。

要求機能の洗い出し

言語化された要求に対して、何の機能があればその要求を満たすことができるか、機能のリストアップを行います。前項の通り機能は、「⚪︎⚪︎を△△にする機能」という形で書き出します。また、可能な限り詳細に書き出し、抽象度を揃えるように階層的にまとめます。

また、複数のステークホルダーがいる場合や、システム間の連携が必要な場合、抜け漏れが発生してしまいます。そのため、ユースケース図などを利用し、可視化を行い、全体を俯瞰しつつ構造化して必要な要求機能を洗い出すことを推奨します。　

以下に例として、ファイルのダウンロード用APIを考案した際の要求機能とユースケース図を記載します。ここでは既存機能もあるため新たに開発が求められる機能は少ないですが、ユーザーがどのようなユースケースでの使用を想定しているのかを分析し、システム間の相互関係を見ながら、必要な機能を洗い出すことができます。

【新たに開発が求められる機能】

• 機能1　ファイルのダウンロードを行うための認証キーを発行する機能

• 機能2　発行された認証キーによってダウンロード可否の認証を行う機能

• 機能3　特定のファイルをダウンロードする機能

  • 機能3-1　特定のファイルのmdファイルをダウンロードする機能

  • 機能3-2　すべてのファイルをダウンロードする機能

モックアップ制作

要求機能を洗い出すことができたら、モックアップの制作を行います。モックアップは作り込む必要はなく、あくまでユーザーの要求が正しいことを確認するための必要最低限で良いと考えています。TASUKIではFigmaを使い、モックアップを制作しておりますが、PowerPointでの簡易的なポンチ絵あるいは、手書きのワイヤーフレームなどでも良いと思います。

Early Validation(早期の妥当性確認)

Early Validationはユーザーインタビューが望ましく、要望をあげていただいたユーザーに実施することが理想です。また、その要望をあげたユーザーにインタビューを行える環境と体制を整えておくことが重要です。

Early Validationにおける、ユーザーインタビューの設計時に重視しているポイントは以下の通りです。

• 仮説の課題をもとに、深掘りを進める

  ユーザーが抱える課題を特定する質問を行うことを心掛けます。「〇〇を△△するときに、XXで悩んでいませんか？」といった形式で、特定の課題について取り上げ、ユーザーの答えがYESとNOで場合分けした質問を用意しておき、更に深掘りを行います。また、その際、ユーザーがその行動を行う背景や動機、感情を探ることも重要です。

• 解決策を直接聞くのではなく、仮説に基づき演繹法を用いてユーザーの要求を確認する

  「〇〇の機能が欲しいですか」といった直接的な解決策を聞く質問は避け、考案した解決策がユーザーの要求を間接的に満たしているかを確認できるよう質問を設計します。

• オープンエンド質問とクローズド質問を使い分ける

  Early Validationにおけるインタビューはクローズド質問が基本となりますが、解空間を広げアイディアを発散させる際にはオープンエンド質問も有効です。

  オープンエンド質問

  自由に答えられる形式で、ユーザーの考えや意見を広く収集します。
  例: 「〇〇の作業を行う際、最も面倒に感じることは何ですか？」

  クローズド質問

  特定の選択肢の中から回答を選ばせる形式で、仮説の検証や選好を明確化する。
  例: 「AとBのどちらが重要ですか？」

上記の3点を考慮し、ユーザーへの質問を事前に考え、ユーザーインタビューに臨みます。

　要求分析では、以上の4ステップを、ユーザーの要求が確からしいことが確認できるまで繰り返します。

要件定義・概念設計

要件の洗い出し・見直し

　要求分析でリストアップされた要求機能に対して要件の洗い出しと見直しを行います。

　始めに、要求と要件の定義について整理しておきます。

要件定義によって、要求が具体化され、実現可能な形に落とし込まれることで、開発の方向性が明確になります。以下に、要件の洗い出し・見直しで着目すべきポイントを説明します

• 実現可能性の確認

要求が技術的・コスト的に実現可能であるかを評価します。例えば、「暗い場所でも視認可能」という要求に対し、バックライト機能や蛍光塗料の利用が現実的か検討します。

• 明確性と測定可能性の確認

要件が曖昧な表現ではなく、測定可能な形で記述されているかを確認します。例として、「±1秒の精度で時刻を表示する」といった具体的な記述が求められます。

• 矛盾や抜け漏れのチェック

要求間や要件間で矛盾がないか、または重要な機能が抜け落ちていないかをチェックします。これは書き起こしされた要求と要件を全体俯瞰して見直すことが必要です。ここでも、ユースケース図などで構造化された図解が効果を発揮します。

上記ポイントを考慮し、抜け漏れなく、要件を詳細に定義していくことが求められます。

デザインカンプ制作

デザインカンプは要件を具現化したものであり、ユーザー体験を形にする一方で、実際に実装可能である必要があります。この段階でデザイナーと開発担当の連携が不足すると、開発の実現性や要件との整合性に問題が生じ、後工程で手戻りが発生するリスクがあります。

デザイナーは開発の技術的制約やシステム要件を理解する必要があり、開発担当はデザイン意図やユーザー視点を尊重することが求められます。これにより、デザインの忠実な実装が可能になり、品質の高いプロダクトを効率的に完成させることができると考えています。

TASUKIではモックアップと同じくFigmaで制作しており、Figmaのプロトタイプを成果物としています。プロトタイプはインタラクティブな画面操作と遷移が可能であり、ユーザーに最終成果物のイメージを共有するのに適していると考えています。

Early Verification(早期の検証)

要件が仕様として適切であり、具体的なシナリオで適切に機能するかを検証します。対象者にユーザーインタビューを実施することが理想ですが、現実には実施できないケースもあります。

その場合、社内メンバーへのオブザベーションが有効な検証の手段の一つになります。メンバーにシナリオや背景情報を説明し、その視点でプロトタイプを操作してもらうよう依頼します。可能な限り、観察者はフィードバックを受けるだけでなく、操作や表情を観察し、気づいた点を記録し、要件の見直しを行います。

得られた結果は、ユーザーの期待や行動を完全には代替できないため、正式な検証として採用するかの判断が必要です。フォローアップとしてユーザーへアンケートを実施し、最終確認を行うことも検討が必要です。
 

要件定義・概念設計では、以上の3ステップを、ユーザーの要求を満足するよう要件定義・概念設計ができているかを確認できるまで繰り返します。場合によっては、要求分析に戻るケースもあります。この手戻りが手間に感じる時もあるかもしれませんが、開発に着手してからの手戻りよりはリソースの浪費は少なくなります。また、デザインカンプの完成度が高いほど、開発者は開発のみに集中でき、全体として見るとデリバリー速度と品質は上がります。そのため、要求分析と要件定義・概念設計の「小さな手戻り」は許容するべきだと考えています。

まとめ

「手戻りを最小限に抑えた開発」を実現するための、Early V&VとSystems Engineeringを適用した開発ワークフローについて紹介しました。本ワークフローは実際の現場で試行錯誤を重ねながら運用しており、今後もより効率的かつ効果的な形で進化させていきたいと考えてます。

幸いなことに、TASUKIのツールについて「操作が直感的でわかりやすい」「使いやすい」といった嬉しいお声をいただく機会が増えてまいりました。現在、生成AIの活用がビジネスの成長を左右する時代において、誰もが簡単に生成AIを扱えるようにするためには、ツールのUI/UX改善がますます重要になると考えております。TASUKIでは、より多くの方々に生成AIを身近に感じていただき、その結果として幸せを届けられるよう、継続的なツールの改善に取り組んでまいります。生成AI向けのデータ作成でお困りのことがございましたら、ぜひお気軽にTASUKIまでご相談ください。

以上、「システム開発のためのEarly Validation&VerificationとSystems Engineering」の紹介でした。

それでは、ソフトバンク アドベントカレンダー 2024　8日目にバトンを渡します。