TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

V字モデルの各レイヤー(プログラミング、コードレビュー編)

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

この記事ではV字モデルのレイヤーのうち、「プログラミング」プロセスと「コードレビュー」プロセスについて説明します。

V字モデルの各レイヤーの説明は以下の記事を参照してください。

tracery.jp

V字モデル上の「プログラミング」と「コードレビュー」

プログラミングコードレビューは、V字モデルの底に位置し、ソフトウェアの設計を実際のコードとして具現化するプロセスです。

V字モデルの底にあることが示すように、プログラミングとコードレビューはソフトウェア開発全体の品質を支える土台です。

以下では、V字モデルにおける「プログラミング」と「コードレビュー」の関係や重要性について解説します。

V字モデル上の「プログラミング」プロセスと「コードレビュー」プロセス

プログラミングプロセスとコードレビュープロセス

プログラミングでは、設計で定義された仕様に基づき、ソフトウェア本体のコードや単体テスト(UnitTest)のテストコードを実装します。

ここで作られるコードは、ソフトウェアの価値と品質を最も直接的に形づくる成果物であり、プログラミングは開発の成否を左右する中核的なプロセスといえます。

コードレビューは、その成果物を第三者の視点でコードを査読し、設計意図との整合性、可読性、保守性、命名や責務分離の妥当性といった内部品質の観点から検証するプロセスです。

手動テストやUnitTestは、外部仕様どおりに動作するかを確認するブラックボックステストですが、コードレビューはソースコードの構造や設計意図を直接確認するホワイトボックス的な品質保証活動です。

コードレビューで欠陥を早期に発見することで、結合テストやシステムテストなど後続プロセスでの手戻りを防ぎ、結果として開発の安定性とチーム全体の生産性を高めます。

プログラミングプロセスとコードレビュープロセスの対応

コードレビューが果たす役割

コードレビューの目的は、単なる不具合の検出にとどまりません。

レビューを通じて設計思想を共有し、チームの文化を育てることにもつながります。

他者のコードを読む経験は、開発者の理解を深め、属人化を防ぎ、チーム全体の開発力を底上げします。

コードレビューによって問題のあるコードを早期に修正出来ます。それ以上に、コードレビューをしてもらうという意識を持ってコーディングすることで、単に動けばよいという意識でコードを書いてしまう問題を防ぐことが出来ます。

コードレビューは「作るプロセス(Make)の質」を高める仕組みといえるでしょう。

最後に

本記事では、プログラミングプロセスとコードレビュープロセスの関係について解説しました。

今日、多くの事業はソフトウェアによって支えられています。ソフトウェアの品質を高めることは、事業の信頼性・継続性・競争力を維持する経営活動そのものです。品質が損なわれれば、顧客離れや開発コストの増大、さらにはサービス停止といった経営リスクに直結するからです。

コードは、ソフトウェアの価値と品質を最も直接的に形づくる成果物であり、ソフトウェアの本質はソースコードにあります。

コードの品質が低ければ、機能追加や改修のたびに不具合が再発し、システム全体の安定性を損ないます。結果として、組織のスピードと信頼の両方が失われます。

コードの品質を高める最も有効な手段が、コードレビューです。レビューは単なる不具合検出の仕組みではなく、開発者同士が知見を共有し、設計思想や品質基準を組織全体に浸透させる技術的学習の場でもあります。

このように、経営の観点から見てもコードレビューは非常に有効です。

まだコードレビューを実施していない組織は、ぜひ導入を検討してください。

次回は、V字モデルの左辺の各プロセスの関係性(トレーサビリティ)について説明します。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

V字モデルの各レイヤー(企画、運用・評価編)

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

この記事ではV字モデルのレイヤーのうち、「企画」プロセスと「運用・評価」プロセスについて説明します。

V字モデルの各レイヤーの説明は以下の記事を参照してください。

tracery.jp

V字モデル上の「企画」と「運用・評価」

企画」プロセスと「運用・評価」プロセスはV字モデルの頂点にあり、システム開発の目的(Why)に焦点を当てたレイヤーです。

V字モデル上の「企画」プロセスと「運用・評価」プロセス

V字モデルでは、右側のプロセスが左側のプロセスの検証を行う役割を果たします。

上図は、「企画」プロセスで定義された課題の解決や価値の実現が、「運用・評価」プロセスで検証され、その結果が次の企画や開発にフィードバックされることを現しています。

このフィードバックループは、システムの継続的な改善を促し、長期的な成功を確保するために不可欠です。

企画プロセスと運用・評価プロセスの概要は以下のとおりです。

  • 企画プロセス:解決すべき問題や取り組むべき課題、創出する価値を定義し、目的を実現するためのコンセプトや方向性、道筋や計画を構想する
  • 運用・評価プロセス:システムを運用し、企画プロセスで定義した課題の解決や価値が実現されているかを評価する

以下、それぞれのプロセスを詳細に説明します。

企画プロセス

企画の構成

企画とは、アイデアをカタチにするための最初のステップです。この段階で最も重要なのは、なぜその企画に取り組むのか(Why)という目的を明確にすることです。具体的には以下のような内容を定義します。

  • 解決したい問題や直面している課題: 誰がどのような問題や課題を持っているか
  • 創出したい価値: 誰にどのような価値を提供したいか。どのような未来を実現したいか(ビジョン)

企画では、自分たちが本当に実現したいと感じるビジョンや熱意が非常に重要です。

これらがなければ、企画を実現するためのモチベーションが欠け、途中で企画が頓挫する可能性が高まります。ビジョンと熱意が明確であれば、取り組むべき価値があるかどうかを判断するための重要な指標となります。

次に重要なのが、納得感のあるロジックです。どれほど熱意があっても、実現可能性が分からなければ企画は実行に移せません。具体的には以下のような内容を定義します。

  • 要求: 価値を実現するためにやりたいことや実施したいこと。事業、業務、システム、活動などの内容が含まれる
  • 計画: 開発のスケジュール、リソース計画、コミュニケーション計画

納得感のあるロジックを持った企画は、実行可能性と共感を生み出し、実行への道筋を明確にします。

運用・評価プロセス

ここでは、運用と評価の2つの側面について説明します。

運用・評価の結果を企画にフィードバック

運用

システム運用プロセスは、開発したシステムを実際に運用し、事業を支える重要な段階です。このプロセスでは、システムが実際の業務で利用され、ユーザーに価値を提供します。

運用中は、ユーザーからのフィードバックを収集することが重要です。このフィードバックは、日常の運用活動の一環としてシステムの使用状況を観察し、ユーザーが直面する問題や改善点を特定するために使用されます。

ユーザー観点以外の運用活動として、システムのパフォーマンスモニタリングがあります。これには、システムの速度や稼働状況を定期的にチェックし、問題が発生した場合には迅速に対応することが含まれます。

例えば、ユーザーがシステムにアクセスする際の遅延を最小限に抑えるために、サーバーの処理能力を調整するなどの対策を講じます。

また、セキュリティ対策は運用において極めて重要です。不正アクセスの監視やウイルス対策、定期的なセキュリティパッチの適用などを行います。これにより、システムとデータの保護を強化します。

さらに、定期的なバックアップを実施し、万が一のデータ消失に備えます。

このように、運用プロセスはシステムの発展や改善と安定した運用に欠かせない活動を含んでいます。最終的に、これらの活動がシステムの価値を高め、事業の円滑な運営を支えることになります。

評価

企画プロセスで定義した問題が解決され、価値が創出されているかを検証し評価します。

このプロセスでは、システムのリリース後に、実際に運用した結果を基に、企画で設定した目標や価値が達成されているかを評価します。KGI(Key Goal Indicator: 経営目標達成指標)*1KPI(Key Performance Indicator: 重要経営指標)*2といった定量的な指標を使用して、具体的な成果を数値で測定します。例えば、ユーザー数の増加率や操作ミスの減少率などが評価対象となります。

また、ユーザーからのフィードバックやサポートリクエストの分析を行い、システムの使い勝手や性能に関する定性的なデータを収集します。このデータには、ユーザーインタビューやアンケート調査の結果が含まれ、ユーザー満足度や改善点についての具体的な洞察(インサイト)を提供します。さらに、エラー率やシステムダウンタイムの分析を通じて、技術的な側面からも評価します。

リーンスタートアップとV字モデル

「企画」と「運用・評価プロセス」のフィードバックループを一巡するには時間がかかります。そのため、企画・開発した製品がユーザーに受け入れられるかどうかを確認するまでのコストやリスクも、時間とともに増大します。

リーンスタートアップ*3は、フィードバックループを最小限に短縮し、不確実性から来るリスクを抑える手法です。このアプローチでは、限られたリソースでアイデアを迅速に検証し、市場のニーズに迅速に対応することが重視されます。

具体的には、「最小限の実用的な製品(MVP: Minimum Viable Product)*4」をまず作成し、それを市場に投入して顧客からのフィードバックを集めます。そのフィードバックを基に、製品やサービスを改善するプロセスを繰り返します。この方法により、大きなリスクを避けつつ、効率的に開発を進めることが可能です。

下図は、リーンスタートアップのサイクルとV字モデルのプロセス(企画、運用・評価)の対応関係を示しています。リーンスタートアップのプロセスで短期間で仮説、構築、検証のサイクルを回す際に、V字モデルの考え方も適用できることがわかります。

リーンスタートアップのサイクルとV字モデル

最後に

この記事では、V字モデルの「企画」プロセスと「運用・評価」プロセスについて説明しました。

企画は1度作成して終わりではありません。企画はあくまで仮説であり、システムをユーザーに提供して、得られたフィードバックをもとに仮説を洗練させていくことが重要です。

次回の記事では、V字モデル上の「要件定義」プロセス(業務要件定義、システム要件定義)と、運用テスト、システムテストについて説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:企業やプロジェクトが達成すべき主要な目標を評価するための指標。KGIは、組織が目指す最終的な成果や成果を測定し、戦略の成功を評価するのに役立つ。例えば、売上の増加、マーケットシェアの拡大、顧客満足度の向上などがKGIとして設定されることがある。KGIは、全体的なビジネス目標や戦略の達成状況を示すため、重要なパフォーマンスの指標となる。

*2:組織やプロジェクトの進捗や成功度を測定するための具体的な指標。KPIは、特定の目標やタスクの達成状況を評価するために使用され、組織が戦略的な目標を達成するための進捗を追跡するのに役立つ。例えば、売上高、顧客獲得数、製品品質、作業効率、従業員満足度などがKPIとして設定されることがある。これらの指標は、数値や割合などの形で測定可能であり、進捗のモニタリングや改善のための意思決定に役立つ。

*3:Wikipediaを参照のこと

*4:詳細はWikipediaを参照のこと

V字モデルの基本構造をWhy,What,How,Make,Testの視点で理解する

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

この記事ではV字モデルの構造について説明します。V字モデルの構造を把握することで、各プロセスで力を入れるべきポイントが分かり、効果的にシステム開発を進めることができます。

V字モデルの全体像と開発を組み立てる方法については以下の記事を参照してください。

tracery.jp

システム開発プロセスの分類とその関係

システム開発のプロセスは、大きく5つのプロセスに分けられます。

  • 企画 『なぜそのシステムを作るのか』という目的(Why)
  • 要件定義 『何を作るのか』(What)
  • 設計 『どのように作るのか』(How)
  • 実装『実際に作る』(Make)
  • テスト『品質を保証する』(Test)

プロセスの同士の関係

企画、要件定義、設計、実装は、上図のように左から右へ目的と手段の関係になっています。たとえば、企画から見ると要件定義は企画を実現する手段であり、要件定義から見ると企画は要件定義の目的です。

テストは、企画、要件定義、設計、実装それぞれのプロセスの成果の品質を保証します。

V字モデルへのマッピング

これらのプロセスの関係をV字モデルにマッピングすると下図のようになります。「Test(品質を保証する)」はV字モデルの右辺すべてにわたります。

V字モデルのレイヤー構造

各レイヤーの説明

上図で示したV字モデルの各レイヤーについて順に説明します。

「Why」のレイヤー

システム*1を開発する目的(Why)が関心事のレイヤーです*2。そしてその目的が実現されているかを、V字モデルの右辺で検証します。

Whyのレイヤー

各プロセスの概要は以下のとおりです。V字モデルの右辺の「運用・評価」は「運用」プロセスと「評価」プロセスに分かれます。

  • 企画」プロセス
    • 解決すべき問題や取り組むべき課題、創出する価値を定義します。そして、目的を実現するためのコンセプトや方向性、道筋や計画を構想します。
  • 運用」プロセス
    • 開発したシステムを実際に運用し、事業を運営します*3
  • 評価」プロセス
    • 企画プロセスで定義した問題が解決され、価値が創出されているかを検証し評価します。

「What」のレイヤー

業務やシステムで実現すること(What)が関心事のレイヤーです。

この「業務やシステムで実現すること(What)」を定義することを、ここでは「要件定義」と呼びます。

要件定義は、「業務要件定義」と「システム要件定義」に分かれます。

そしてV字モデルの右辺では、大きく以下の2つの内容を検証します。

  • 業務要件定義で定義した要件が実現されているか、実運用できるかどうか
  • システム要件定義で定義した要件が実現されているか、システムとして動作するかどうか

Whatのレイヤー

各プロセスの概要は以下のとおりです。

  • 業務要件定義」プロセス
    • 具体的な業務の構成や業務の流れ、業務の中でのシステムの利用場面(ユースケース)など、業務に求める要件を定義します。
  • システム要件定義」プロセス
    • 業務要件定義で定義したシステムの利用場面(ユースケース)を詳細化し、機能要件や開発項目を抽出します。また、システム全体に求める性能やセキュリティなどの非機能要件やシステムのアーキテクチャを定義します。
  • 運用テスト(受入テスト)」プロセス
    • 業務が実運用できるかどうか、業務要件定義で定義した要件が実現されているかを検証します。開発チームに開発を依頼した担当者が、依頼内容が実現されているかを確認する目的の場合、受入テストともいいます。
  • システムテスト」プロセス
    • システム内に配置される各ソフトウェアや外部システムが連携して動作し、システム要件(機能要件や性能、セキュリティなどの非機能要件*4)を満たしているかを検証します。

「How」のレイヤー

業務要件やシステム要件を満たすために、ソフトウェアをどのような仕様で実現し、ソフトウェアの内部をどのようにを作るか(How)*5が関心事のレイヤーです。

V字モデルの右辺では主にソフトウェアが仕様どおりに正しく動作するかどうかという観点で検証します。それに加えて、要件定義で定義した要件を満たすことができるかという観点でも検証します。

Howのレイヤー

各プロセスの概要は以下のとおりです。

  • 基本設計」プロセス
    • 大きく「仕様化」と「全体設計」に分かれます
      • 仕様化: システム要件定義フェーズでリストアップされた開発項目(画面、API、機能など)の仕様を定義します*6
      • 全体設計: ソフトウェアアーキテクチャー設計、データ全体設計(リレーショナルデータベースを使用する場合、ER図等)などを設計します。
  • 結合テスト」プロセス
    • 個々のモジュールやコンポーネント*7を結合し、ソフトウェア全体としての動作を検証します。画面や機能間のデータの連携などをテストします。
  • 詳細設計」プロセス
    • 開発の最小単位であるコンポーネントやモジュールを設計します。詳細設計を完了するとプログラミングが可能になります。
  • 単体テスト」プロセス
    • コンポーネントやモジュール単位の動作を検証します。

「Make」のレイヤー

設計に基づき、ソフトウェアを実装すること(Make)が関心事のレイヤーです。

そしてV字モデルの右辺ではプログラミングしたコードが可読性や保守性に優れ、品質が高いかどうかを検証します。

Makeのレイヤー

以下は各プロセスの概要です。

  • プログラミング」プロセス
    • 設計に基づいて具体的なコードを書き、システムの機能を実現します。
  • コードレビュー」プロセス
    • プログラムコードを査読し、コードが可読性や保守性に優れているか、バグやセキュリティの脆弱性がないか、効率的に動作するかなどの品質を検証します。

最後に

本記事では、V字モデルの構造について説明しました。

V字モデルの各レイヤーの関心事を把握することで、各プロセスの重要なポイントを理解し、力を集中させることができます。また、各プロセス間の関係を理解することで、他のプロセスの成果物を確認する能力が養われます。

そして、V字モデルの構造を理解することで、効果的にシステム開発を進められるようになるでしょう。

他のプロセスの成果物を確認するために必要となるプロセス間の関係についての知識や各レイヤーの詳細な内容は、別の記事で説明します。

次の記事では、V字モデルの各レイヤーの説明として、企画プロセスと、運用・評価プロセスについて説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:ここでのシステムは狭義のシステムを内包する「広義のシステム」を対象とする。詳細はシステム開発におけるシステムとは何かを参照のこと

*2:企画プロセスでは、システムを開発する目的だけではなく、目的を実現するための構想や計画も立案する。システムを開発する目的が、企画プロセスの最大の関心事であり、起点となるため、ここではシステムを開発する目的のみをあげている

*3:共通フレーム2013では、「運用」プロセスは運用テストと同じレイヤーに位置づけられている。これは、運用が業務担当者の責任と考えられているためと想定される。本メディアのV字モデルでは、事業運用の責任を経営者の責任、すなわち事業レベルと捉え、企画と同じレイヤーに「運用」プロセスを置いている

*4:機能要件(Functional Requirements)は、ユーザー視点から見て、ソフトウェアシステムやアプリケーションがどのように動作すべきかを具体的に定義する要件のこと。非機能要件(Non-functional Requirements)は、ソフトウェアシステムの性能、セキュリティ、使用性や信頼性、効率性など機能以外に関する要件である。

*5:「ソフトウェアをどのような仕様で実現するか」=「外部設計」、「ソフトウェアの内部をどのようにを作るか」=「内部設計」と表現することもある。

*6:共通フレーム2013では「ソフトウェア要件定義」に該当するが、本メディアでは「基本設計」に分類する

*7:コンポーネントは、ソフトウェアシステムの機能的な単位で設計される。特定の機能やサービスを提供する部分であり、他のコンポーネントやシステムとインターフェースを通じて通信する。モジュールは、プログラムを構成するコードの単位で設計される。特定の機能やロジックのまとまりを表し、コードの整理と管理を容易にする。

V字モデルを使って開発プロセスを組み立てよう〜システム開発で迷子にならないために

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

システム開発におけるシステムとは何か - TRACERY Lab.(トレラボ)では、システムの定義について説明しました。

この記事では、V字モデルを使ってシステム開発の進め方を組み立てる考え方について説明します。

システム開発は迷路のようなもの

まずは質問です。迷路をうまく抜けるコツはなんでしょうか。

迷路をうまく抜けるコツは?

答えは迷路を上からみることです。迷路を上から俯瞰することで、複雑な迷路もゴールが見えて、進むべき方向が見えてきます。

迷路を上から俯瞰する

システム開発プロジェクトも迷路のようなものです。

できそうなことから手当たり次第に進んでも、ゴールにたどり着くことはできません。全体像が見えないまま進めると、無駄な作業や手戻り工数が発生しやすくなり、プロジェクトが混乱状態となるリスクが高まります。

システム開発でやるべきことはさまざま

システム開発プロジェクトで迷走しないためには

システム開発プロジェクトで迷走しないための第一歩は、システム開発全体を俯瞰することです。

迷路と同じく、全体を俯瞰することで、進む方向や打ち手を検討できます。

システム開発を俯瞰するにはV字モデルが有用

システム開発を俯瞰するにはどうしたらよいでしょうか。それにはV字モデルが有用です。

システム開発を俯瞰するには、V字モデルが有用

V字モデルは、システム開発での活動をV字上に配置したものです。

このシステム開発の活動のことを「プロセス*1」といいます。

V字モデルは、各プロセス間の関係が明確に対応付けられています(後述の「V字モデルの構造」で説明)。

これによりシステム開発全体を見通すことができ、各プロセスの目的と作業内容を明確化しやすくなるので、無駄な作業や手戻り工数を減らすことができます。

V字モデルの構造

V字モデルは、大きく3つの内容から構成されます。

V字モデルの構造

  1. つくるプロセス(左辺)

    • システムの企画、要件定義、設計、プログラミングといったシステムやソフトウェアをつくり込んでいくプロセスです。
  2. 品質保証のプロセス(右辺)

    • 左辺の各開発プロセスに対応するテストプロセス。具体的には、単体テスト、結合テスト、システムテスト、運用テスト(受入テスト)が含まれ、システムの品質を確保します。
  3. 成果を検証する(つくるプロセスと品質保証のプロセスの対応)

    • 左辺の各開発プロセスに対して、右辺の対応するテストプロセスが存在します。例えば、業務要件定義に対する運用テスト、システム要件定義に対するシステムテスト、基本設計に対する結合テスト、詳細設計に対する単体テスト、プログラミングに対するコードレビューなどです。これにより、各プロセスでの作業が適切に検証され、品質が保証されます。

俯瞰したうえで、開発の進め方を検討する

システム開発の全体像を俯瞰できたら、開発を具体的にどのように進めていくかを検討します。

「治療より予防が大切」とよく言われるように、健康を維持するためには予防が最も重要です。

これは、身体の病気が発生してから治療するよりも、日々の予防や健康づくりのための活動が大事であるということを意味します。

システム開発も同じです。

発生した不具合を直す以前に、不具合が発生しないように日々のプロセスの品質を高め、優れたプロダクトを生み出すための基盤を作ることが重要です。

以下では、システム開発のプロセスを組み立てるためにV字モデルを活用する方法について説明します。

V字モデルをシステム開発の「型」として、現場に適用する

V字モデルを見て、「ウォーターフォールモデル*2」を思い浮かべる方もいらっしゃるのではないでしょうか。

V字モデルのままに、左辺から右辺へと順にシステム開発を進めるなら、その通りです。

しかし、これはV字モデルの開発への適用例の一つに過ぎません。

V字モデルを基に、開発プロジェクトやチームごとの事情や状況に応じた「開発モデル*3」へと適用し、プロセスをカスタマイズできます。

V字モデルをシステム開発の「型」として、現場に適用する

標準的な開発プロセスや手法を、プロジェクトの特定の要件や条件に応じてカスタマイズすることをテーラリング(Tailoring)といいます。

「テーラリング」という言葉は、もともと「仕立てる」という意味を持つ英語の「tailor」から派生しています。洋服の仕立て屋が個々のお客様に合わせて服をカスタマイズするように、システム開発プロセスにおいてもプロジェクトの特定のニーズや条件に合わせてプロセスや手法を調整することを意味します。

ウォータフォールモデルへの適用

ウォータフォールモデルは、基本的には各プロセスを1度だけ実施します。各プロセスで実施する内容がすべて完了したら、次のプロセスに進みます。

ウォータフォールモデルへの適用

反復型開発への適用

反復型開発とは、システム開発を複数の短い反復*4に分けて進める手法です。各反復ごとに計画、企画、要件定義、設計、実装、テストを行い、フィードバックを反映させながら段階的にシステムを完成させていきます。アジャイル開発も反復型開発のひとつです*5

反復型開発への適用

システム開発の「型」としての共通フレーム2013

V字モデルの例として、共通フレーム2013を紹介します。共通フレーム2013は、ソフトウェアおよびシステム開発のプロセス標準を定めたフレームワークです。国際規格の「ISO/IEC 12207:2008(Systems and software engineering — Software life cycle processes)*6」をベースに、日本の実情に合わせて策定されています。

「型」としての共通フレーム2013のV字モデル

共通フレーム2013はプロセス*7を、開発対象や各組織の事情を考慮して取捨選択することを推奨しています*8

共通フレーム2013ではテーラリングの例として、ウォータフォールモデル、段階的モデル(インクリメンタルモデル*9)、進化的モデル(反復型モデル)、リエンジニアリングモデル*10への適用例を説明しています*11

最後に

本記事では、V字モデルの全体像と開発プロセスの組み立て方について説明しました。

V字モデルでシステム開発全体を俯瞰し、各プロジェクトのニーズや事情に合わせてプロセスを組み立てることで、プロダクトの品質向上の基盤を作ることができます。

また、日々の仕事をする際にV字モデルを意識することで、自分の仕事の位置づけやプロジェクトの現在地を把握しやすくなるでしょう。開発の現場で迷子になったり、迷走することも少なくなります。

その意味で、V字モデルはシステム開発に携わる人にとって地図のようなものであり、必須の知識といえるでしょう。

システム開発に携わる方々には、V字モデルを心に留めて日々の仕事に取り組まれることをおすすめします。

次回は、V字モデルの基本構造を成す各レイヤーについて説明します。

tracery.jp

参考文献

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:インプットをアウトプットに変換する、相互に関連する又は相互に作用する一連の活動[JIS Q 9000:2006]。互いに関連をもった"アクティビティ"の集合で入力を出力に変換するもの[ISO/IEC 12207]

*2:システム開発プロセスの一つで、各フェーズが順序立てて実行されるシーケンシャルなアプローチ。このモデルでは、プロジェクトの進行が水が上から下に流れるように一方向に進むことから「ウォーターフォール」という名前が付けられた

*3:開発プロジェクトを計画し、管理し、進行させるためのプロセスや方法論のこと。開発モデルは、プロジェクトの各フェーズをどのように進めるかを規定し、プロジェクトの成功を支援する。これにより、開発チームが効率的かつ効果的に作業を進めることができる。開発モデルの例としては、ウォーターフォールモデル、ScrumやXP(extreme programming)などのアジャイルモデル、スパイラルモデル(反復型モデル)、RAD(Rapid Application Development)モデル、インクリメンタルモデルなどがある

*4:短い場合には1週間、長くて数か月のことが多い

*5:図の反復は一例であり、企画だけの反復、要件定義だけの反復などさまざまなケースがあり得る

*6:ISO/IEC/IEEE 12207の最新版は、ISO/IEC/IEEE 12207:2017で、2017年版が最新(2024年6月時点)

*7:共通フレームは、「プロセス」をさらに「アクティビティ」「タスク」「注記」の階層構造であらわしています。

*8:P.320 第4部 共通フレームに対する誤解と適用上の注意点を参照のこと

*9:ソフトウェアを段階的に構築するアプローチ。システムを一度に全て作成するのではなく、小さな機能単位(インクリメント)に分割して開発する。各インクリメントは、計画、設計、実装、テストの全プロセスを経てリリースされ、動作する部分的なシステムが提供される

*10:既存のソフトウェアシステムやビジネスプロセスを根本的に再設計・再構築するためのモデル

*11:第4部 2章共通フレームの適用とテーラリング(修整)

システム開発におけるシステムとは何か

シリーズ: システム開発の基礎

TRACERYプロダクトマネージャーの haru です。

システム開発と一般的にいいますが、そもそも「システム」とはなんでしょうか。

この記事では、「システム開発」における「システム」についてわかりやすく説明します。

システム開発の仕事をするうえで、システムそのものの意味や定義を知っておくことは重要です。

プロジェクトの範囲や目的が明確になり、クライアントやステークホルダーと共通の認識を持つことで、システム開発の成功の鍵を握る要件定義段階での誤解やミスを減らすことができます。

「システム」とは

システムとは「極めて多数の構成要素から成る集合体で、各部分が有機的に連携して、全体として一つの目的を持った仕事をするもの」です。

この定義は新明解国語辞典第7版の説明を引用したものであり、本記事でもこの定義をベースに説明します。

「システム」の一般的意味

システム開発における、狭義のシステムと広義のシステム

システム開発における「システム」は「狭義のシステム」と「広義のシステム」で考えられます。

システム開発における、狭義のシステムと広義のシステム

まず、狭義のシステムは、特にソフトウェアとハードウェアが連携して動作する仕組みを指します。たとえば、ソフトウェアはオペレーティングシステム(OS)、ミドルウェア、アプリケーションなどがありますがこれらが連携して機能を提供します。ハードウェアはスマートフォン、PC、家電などの物理的な装置があげられ、ソフトウェアと連携して動作します。たとえば、OSはハードウェア資源を管理し、アプリケーションがユーザーの操作に応じて動作する仕組みです。このように、狭義のシステムは主に技術的な要素に焦点を当てた仕組みです。

システム開発に携わるエンジニアの方々は、この狭義のシステムに馴染みがあるのではないでしょうか。

一方で、広義のシステムは、人、物、金、情報など、さまざまな要素が連携して動作する全体の仕組みを指します。例えば、会社全体の経営システムを考えてみましょう。ここでは、従業員(ヒト)、製品や原材料(モノ)、予算や資金(カネ)、社内データ(情報)などがすべて連携して、会社が効率的に運営されるように働いています。このように、広義のシステムは複数の異なる要素が連携して目的を達成するシステムと考えられます。上図のように狭義のシステムは広義のシステムの中に含まれます。

次の節では、狭義のシステムと広義のシステムについて、それぞれの例をあげて説明します。

狭義のシステム

狭義のシステムとは、先に説明したようにソフトウェアとハードウェアが連携して動作する仕組みを指します。

ここでは、iPhoneアプリとサーバーという構成でつくられたシステムを例に説明します。

狭義のシステムの例

以下に、システムの構成要素とそれらの役割を列挙します。

ハードウェア

  1. iPhone:
    • ユーザーが直接操作するデバイス
    • アプリケーションの実行環境として機能し、ユーザーインターフェースを提供する
  2. サーバー:
    • データ処理やストレージ、バックエンドのロジックを処理するためのマシン
    • iPhoneからのリクエストを受け取り、必要なデータやサービスを提供する

ソフトウェア

  1. iPhone内のソフトウェア:

    • スマホアプリ:
      • ユーザーが直接操作するアプリケーション
      • データの表示やユーザーからの入力を受け取り、処理する
    • iOS:
      • iPhoneのOSで、ハードウェアリソースを管理し、スマホアプリの実行を支援する
      • アプリケーション間の通信やデバイスの管理、セキュリティ機能を提供する
    • SQLite:
      • iPhone内で使用される軽量のデータベースシステム
      • アプリケーションがローカルデータを保存および取得するために使用される
  2. サーバー内のソフトウェア:

    • Web API:
      • iPhoneのスマホアプリからのリクエストを受け取り、適切なデータや処理結果を返すインターフェース
      • サーバーとクライアント(iPhone)間の通信を管理する
    • Python:
      • サーバーサイドのプログラミング言語
      • Web APIやデータ処理ロジックの実装に使用される
    • Ubuntu:
      • サーバーのオペレーティングシステム
      • ハードウェアリソースを管理し、PythonやDjangoを実行する環境を提供する
    • Django:
      • Python製のWebアプリケーションフレームワーク
      • Web APIの構築やデータベース管理、ユーザー認証などの機能を提供する

これらのシステムの構成要素、つまりハードウェア(iPhoneとサーバー)とソフトウェア(iOS、スマホアプリ、SQLite、Web API、Python、Ubuntu、Django)は単一では動作せず、それぞれ連携して動作することで、ユーザーにサービスを提供します。

広義のシステム

広義のシステムについて、Webのフリマサービス*1を例として説明します。このシステムには以下の構成要素が含まれるとします。

  1. 購入者: 商品を探し、購入するユーザー
  2. 出品者: 商品を登録し、販売するユーザー
  3. コンビニ: 購入者が商品を受け取る場所であり、物流会社へ商品を渡す中継地点
  4. 物流会社: 商品を出品者から購入者へ配送する役割を担う会社
  5. お金: 購入者から出品者への支払い、およびフリマサービス運営会社の手数料として利用される資金
  6. 商品: 出品者が販売し、購入者が購入する物品

広義のシステムの例

これらの要素がどのように連携しているかを説明します。

  1. 出品者が商品を出品: 出品者はフリマのプラットフォーム上に商品を登録し、販売を開始する。ここで商品情報(情報)が登録される
  2. 購入者が商品を購入: 購入者はプラットフォーム上で商品を検索し、購入する。購入手続きが完了すると、購入者からお金が支払われる
  3. 商品をコンビニへ持ち込む: 出品者は商品を近くのコンビニに持ち込む。コンビニは商品を受け取り、物流会社に引き渡す
  4. 物流会社が商品を配送: 物流会社はコンビニから商品を受け取り、購入者の住所まで配送する。配送が完了すると、購入者は商品を受け取る
  5. 取引の完了と評価: 購入者が商品を受け取り、問題がなければ取引が完了する。購入者は出品者に対して評価を行い、これが他の購入者への情報となる

このように、Webのフリマサービスは、購入者、出品者、コンビニ、物流会社、お金、商品という多様な要素が有機的に連携することで成り立っています。それぞれの要素が連携し、システム全体が円滑に機能することで、ユーザーにとって便利で効率的なサービスが提供されます。

システム思考を取り入れ、戦略や施策の仮説を立てる

システムが運用され、うまく回るようにするためには、システムが発展、成長していくための施策を考える必要があります。

その際、システム思考*2という考え方を取り入れることで、システムに持続可能な好循環を生み出す戦略や施策を考えることができます。

システム思考とは、個別の要素だけでなく、それらの相互作用や全体の関係性に着目して問題解決や改善策を考える方法です。

システム思考は、まさに広義のシステムを対象とした思考法といえるでしょう。

下図に、システム思考の観点からWebのフリマサービスを発展、成長させていくため具体的な施策とその効果の例を示しました*3

Webのフリマサービスを発展、成長させていくため具体的な施策とその効果

上図の例では重要施策を3つ示しました。重要施策の具体案を以下に示します。

  1. 出品者増加施策
    • 出品キャンペーンの実施
    • 手数料の一部無料化
    • 出品ガイドやサポートの充実
  2. 出品/購入機能の利便性向上
    • モバイルアプリの機能強化
    • 直感的なユーザーインターフェース
    • AIを活用したおすすめ商品機能
  3. コンビニや物流会社との連携強化
    • コンビニでの発送受け付け
    • 提携物流会社による迅速な配送サービス
    • 発送時の割引サービス

これらの施策を実施することによる効果は以下のとおりです。

  1. 出品者増加施策出品/購入機能の利便性向上によって期待される効果
    • 出品者が増えると、プラットフォーム上の商品数が増加する
    • 商品の種類や選択肢が増えることで、購入者にとって魅力的な選択肢が広がり、購入者が増加する。これにより、システム内の「購入者」が増える
    • 購入者が増えると、自然と売上が増加する
    • 増加した売上は、出品/購入機能の利便性向上に再投資する。具体的には、モバイルアプリの機能強化や直感的なユーザーインターフェースの改善に投資する
    • 利便性が向上することで、ユーザーの満足度が高まり、リピーターが増加する。さらに出品者が増加するという好循環が形成される
  2. コンビニや物流会社との連携強化によって期待される効果
    • 出品者は、商品をコンビニで手軽に発送できるようになり、発送の手間が減る。これにより、システムの「物流会社」と「コンビニ」が効率よく連携する。
    • 手間が少なくなることで、出品のモチベーションが向上し、出品者が増加する
    • 購入者は、コンビニで商品を簡単に受け取ることができ、受け取りの利便性が高まる
    • 商品を受け取りやすくなることで、購入者の購入意欲が高まり、購入者が増加する。これにより、システムの「購入者」が増え、システム全体の取引数が増加し、サービス全体の活性化につながる

このようにシステム思考を取り入れることで、施策を単独で考えるのではなく、サービス全体を一つのシステムとして俯瞰し、施策とその効果を関連付けて捉えることができます。

これによりサービスが持続的に発展していくための効果的な戦略や施策、改善策、そしてそれらが生み出す効果などの仮説を立案できます。

V字モデルと広義のシステム開発、狭義のシステム開発、ソフトウェア開発の関係

V字モデルはシステム開発プロセスを表すモデルです。企画、要件定義から設計、実装、テスト、リリースまでの各段階を示します。

V字モデルと、これまでに説明してきた狭義のシステム開発、広義のシステム開発、そしてソフトウェア開発の関係を下図に示しました。

V字モデルと広義のシステム開発、狭義のシステム開発、ソフトウェア開発の関係

  • 広義のシステム開発
    • V字モデル全体に対応する。事業全体の観点からシステムを構築するプロセスであり、事業目標や業務プロセスの設計から、具体的なシステムの設計・開発・運用までを含む
  • 狭義のシステム開発
    • V字モデルの下半分に該当し、システムとソフトウェアの開発に焦点を当てる
  • ソフトウェア開発
    • V字モデルの一番下のレイヤーに該当し、ソフトウェアの設計や実装に特化したプロセス

上図のV字モデルを見ると、要件定義には「業務要件定義」と「システム要件定義」の2種類があり、「広義のシステム開発」と「狭義のシステム開発」の両方がスコープに含まれていることがわかります。

そのため、要件定義を成功させるには、開発から運用までをイメージするスキルやシステム全体を捉えるスキルなど、幅広いスキルが必要です。具体的には以下の記事を参照してください。

tracery.jp

最後に

本記事では以下のことを説明しました。

  • 「システム」の一般的意味
  • 狭義のシステムと広義のシステム
  • システム思考を取り入れ、施策の仮説を立てる
  • V字モデルとシステム(広義、狭義)の関係

システムを技術の観点から見た狭義のシステムだけでなく、広義のシステムで捉えると、生態系(エコシステム)のように見えてきます。

そのように考えるとITが不可欠なこの時代において、システム開発の仕事は社会の生態系(エコシステム)、仕組みやインフラを構築し、社会を発展させる重要な役割を担っていると言えるのではないでしょうか。

次回の記事では、実際にシステム開発を進める際にV字モデルを使ってシステム開発のプロセスを組み立てる方法を説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: @haru860

*1:フリーマーケットサービスの略。個人がインターネットを通じて手軽に商品を売買できるオンラインのプラットフォーム。利用者は、出品者として自分の不要な物品を販売したり、購入者として他のユーザーが出品した商品を購入したりできる。

*2:システム思考とは、物事を個々の要素だけでなく、全体としての相互関係や相互作用を理解しようとする考え方。システム全体の構造、パターン、および動的なプロセスに焦点を当て、問題解決や意思決定に役立てるアプローチ。全体視点、相互依存性の認識、フィードバックループ、動的複雑性などの特徴をもつ

*3:システム思考では因果ループ図という図を用いることが多いですが、ここでは簡易的な表記にとどめました。

要件定義に求められるスキルとは

シリーズ: 要件定義に求められるスキルとは

TRACERYプロダクトマネージャーの haru です。

要件定義の難しさ - TRACERY Lab.(トレラボ)では、要件定義がなぜ難しいのか、という説明をしました。

今回の記事は、要件定義を成功させるために必要なスキルと、そのスキルの身につけ方について説明します。

要件定義に求められる3つのスキル

『要件定義』に求められるスキルは、以下の3つです。

  • ニーズをまとめるスキル
  • 開発から運用までをイメージするスキル
  • 全体を捉えるスキル

それぞれのスキルについて説明します。

ニーズをまとめるスキル

さまざまな要望を取りまとめ、導くスキル

システムにはさまざまなステークホルダー(利害関係者)が関わり、それぞれがシステムに対して要望を持っています。

例えば、経営者はシステムの活用によって売上が上がるか、費用が下がるか、従業員の満足度が上がるかなど、経営的な側面から要望を出します。

業務担当者は、業務で成果が上がることや効率化を求める要望を持っています。

顧客は、自分の仕事の成果が上がるか、やりたいことができるかという要望を持っています。

開発担当者は、日々開発がしやすいか、保守がしやすいかといった要望を持っています。

現実的にはこれらの要望に全て応えることはできません。

あるステークホルダーの要望を満たすと、他のステークホルダーにマイナスの影響が生じることもあります。

これらのさまざまな要望をヒアリングし、文書化、モデリング、プロトタイピングなどを行うことで認識をすり合わせていきます。

そして、要望を取捨選択し、要件としてまとめ、最終的にステークホルダー間で合意を形成する必要があります。

このように、要件定義を行うためには、多種多様でばらばらな要望を整理し、要件の合意に導く力が求められます。

開発から運用までをイメージするスキル

開発から運用までをイメージするスキル
 

要件定義をする際には、開発工程から完成、運用までを一貫してイメージするスキルが必要です。

このスキルや知識は2つから成り立っています。

1つは、開発のインプットにどのような情報が必要かを理解していることです。

要件定義でまとめた要件(上図の青)は開発プロセス(上図の緑:設計、実装、テスト)のインプットになります。

たとえば、設計と実装は要件定義の情報を基に進められ、テストでは要件を基にシナリオテストなどのテストケースが作成されます。

そのため、どのような情報が開発プロセス(設計、実装、テスト)にとって必要十分かを把握することが求められます。

そうでないと、開発中に何度も要件の確認が必要となり、手戻りやタイムラグが発生し、開発の遅延につながる可能性があります。

2つは、要件を実現するためにどれくらいの工数がかかるかをイメージすることです。

開発の設計プロセスでは、画面設計やシステムの背後にあるアーキテクチャ、データベースの設計が行われます。

定義された要件を満たすために無理な設計になったり、必要以上の実装工数がかかると、工数増加や他のトラブルにつながることがあります。

そのため、要件定義の段階で、要件定義者はその要件を満たす画面や背後の仕組みがどのようなものになるかをイメージし、工数的にも妥当な設計や実装ができるような要件を定義する必要があります。

要件定義担当者が十分にイメージできない場合は、開発者と協力し、設計や実装にとって妥当な要件かどうかを確認しながら進めると良いでしょう。

エコシステム全体を捉えるスキル

エコシステム全体を捉えるスキル

要件定義に必要なスキルの3つ目はシステムだけではなくエコシステムを含めた全体を捉えるスキルです。ここでいうエコシステムはビジネスの流れ(人、物、金、情報の循環)を表します。

ビジネスの観点から業務に必要なシステムの要件定義を進める中で、エコシステムにも目を向ける必要があります。

事業に関連する業務が全て自社で完結するわけではありません。

たとえば、物流については専門の会社に依頼する方がよいかもしれません。倉庫での管理については、倉庫を借り、管理をする人員を専門事業を行っている会社から雇うか、自社で確保するかを選ぶ必要があります。

このような観点から、自社内だけではなくエコシステム全体を考慮し、必要か不必要かを選択する必要があります。

外部の力を借りることが費用対効果に優れている場合、独自のシステムを新たに開発する必要はありません。

自社だけでなく、人、物、金、情報がスムーズに循環し、時間が経つにつれて発展していくエコシステムを持つことが良いビジネスだと言えます。

事業およびエコシステム全体を捉えた上で、必要なシステムやその中のソフトウェアを考慮し、要件定義を行います。

システムの外側を意識しないと、事業を実現するためのシステムにはなりにくいと言えます。

必要なスキルを身に着けるために『型』を学ぶ

要件定義に必要なスキルはどのように身につけるのでしょうか。

それは、要件定義の『型』を学び、身につけることです。

ここでいう要件定義の『型』とは、広く深い思考を促す手法や思考プロセスのこととします。

要件定義の『型』

要件定義で必要なスキルとして、①ニーズをまとめるスキル、②開発から運用までをイメージするスキル、③全体を捉えるスキルがあると、説明しました。

たとえば、要件定義手法のRDRA *1にならうと、これらを高めるための手助けをしてくれます。

詳しくは、今後書いていく別の記事で説明していきたいと思います。

『型』に倣い、身につけることのメリットは、考えることが減ること

『型』に倣い、身につけることのメリット

要件定義を進めるにあたって、「ニーズをどのようにまとめるか?」「開発から運用までをどうイメージしながら進めるか?」「全体をどのように捉えるか?」など、進め方を自分で考えるとすると、相当な時間がかかります。

その方法が適切であればまだしも、誤っていれば余計なコストが発生します。

本当に必要なのは、具体的な要件定義の進め方ではなく、成果物(何を作るかを示すもの)とステークホルダーの合意です。

「型」に倣い、それを身につけることで、要件定義の結果として必要なものを作り出すことに集中できます。

『型』は万能ではない

ここで注意してほしいのは、「型」が万能ではないということです。

「型」はスキルを高めるための方向づけを提供しますが、価値あるものを創出できるかどうかは最終的に関わる人々の力量に依存します。

また、「型」はシンプルさを追求するために、本当に必要ではないものを削除しスコープ外とすることが多いです。そのため、他の方法で補う必要がある場合もあります。

まとめ

要件定義に必要なスキルとして、以下の3つを挙げました。

  • ニーズをまとめるスキル
  • 開発から運用までをイメージするスキル
  • 全体を捉えるスキル

これらの「型」を学び、倣うことで、これらのスキルは向上し、要件定義の結果として望むもの、つまり要件定義の成果物(何を作るかを示したもの)の創出とステークホルダーの合意を形成することを効果的に進められます。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:Relationship Driven Requirement Analysis:ラドラ。モデルベースの要件定義手法。アイコン同士を線でつないだシンプルなモデルによって業務とシステムの構成要素の関係(Relationship)を構造化し、要件をかたちにしていく

要件定義の難しさ

シリーズ: 要件定義に求められるスキルとは

TRACERYプロダクトマネージャーの haru です。

システム開発は、企画、要件定義、設計、実装、テストというプロセスに大きく分けることができます。

開発者にとって、設計、実装、テストは仕事内容をイメージしやすい領域です。

ビジネスに近い立場の人々は、企画段階での企画書作成などを具体的にイメージできるでしょう。

しかし、要件定義に関しては、何をすべきか不明瞭でイメージしにくいという人も多いかもしれません。

この記事では、システム開発における要件定義の位置づけ、そして要件定義が難しい理由について説明します。

開発プロジェクトが失敗する一番の理由と世の中で求められている人材

システム開発が失敗する一番の理由を知っていますか?

日経クロステック、日経ビジネスが開発プロジェクトの失敗理由を調査した結果をみてみます。

日経XTechの調査結果
日経ビジネスの調査結果

上記は2017年、2018年に行われた調査結果ですが、いずれも『要件定義』に関する理由が1位です。

また、ビズリーチが発表した、『レジュメ検索・検索トレンド』の検索キーワード1位は『開発要件定義』でした。(2022年) 翌2023年の結果でも、要件定義は8位にランクインしています。

2022年レジュメ検索トレンド
2023年レジュメ検索トレンド

これらの調査結果をみると、要件定義が原因でシステム開発がうまくいかないことが多く、その結果として要件定義ができる人材が企業で求められているということが見えてきます。

要件定義は誰が何をするのか

システム開発のプロセス

システム開発の4プロセス

システム開発のプロセスは、上の図のように4つのプロセスに分けられます(ここでは「作る」ことにフォーカスし、テストは除いています)。

  • 企画 『なぜそのシステムを作るのか』という目的(Why)
  • 要件定義 『何を作るのか』(What)
  • 設計 『どのようにシステム・ソフトウェアを作るのか』(How)
  • 実装『実際に作る』(Make)

4つのプロセスは『レストランでの食事』に例えられる

レストランの例え

4つのプロセスを身近な例として、『レストランでの食事』に例えてみます。

まず『企画』は、食事のプランニングです。

何のために(Why)レストランで食事をするのでしょうか?親交を深めるためなのか、誰かの誕生日のお祝いなのか、理由は様々ですが、『仲良くなる』『お祝いをする』といった目的があると思います。ここまでが企画の部分です。

食事の目的が決まったら、何の料理を食べるのか、を考えます。ここが『要件定義』にあたります。

友達の誕生日を祝うため(企画)、友達の好物であるハンバーグを食べに(要件定義)、いろんな種類のハンバーグを頼めるお店に行こう(要件定義)、といったイメージです。

ここまでが、お客さんが担当する部分です。

続いて、お客さんからの注文(要件)を元に、レストラン側が料理をどのように作るのかを考えます。『設計』に当たる部分です。

どのように(How)、焼くのか煮込むのか、ドリアに乗せるのか、チーズを入れるのか、お客さんからの注文(要件定義)を元にどんな風に調理をするのかを決めていきます。

そうした調理方法(設計)を元に料理をつくります(実装)。

料理に例に説明しましたが、一連のプロセスは、「料理を注文する側」のお客さんと「料理を作る側」のお店側に分けられます。

ビジネス側と開発側の境界線

これはシステム開発も同じです。『企画』と『要件定義』、そして『設計』と『実装』とに分けられます。ただし「ビジネス側」「開発側」はロール(役割)と捉えてください。ビジネス側が開発の仕事を担当することもありますし、開発側がビジネスに携わることもあります。ここが料理とは異なる点です。

ビジネスを『事業』と『業務』に分けて理解する

ビジネスは事業と業務で構成される

ビジネスは『事業』と『業務』に分けて考えられます。

『事業』とは組織が社会的または組織的な目的を達成するために行う継続的な活動の全体を総称したものです。『業務』とは、事業を実現するために行う現場の仕事、オペレーションや運用を指します。

例えば「全世界に商品を販売したい」という目的をもった越境EC事業*1があるとします。

『事業』を実現するためには、商品をどこから仕入れるのか、商品の在庫管理はどうするのか。顧客に商品を届けるための物流などを考える必要があります。これらが『業務』です。この『業務』を行うためにはどのようなITのシステムが必要なのかを最終的に定義するまでが要件定義です。

要件定義の難しさ

要件定義における専門性の谷

要件定義における専門性の谷

ここまで説明してきたように、要件定義は、事業・業務を行う『ビジネス側』の役割(ロール)をもった人が行います。

ここで問題になるのが、一般的にビジネス側の人は、ITシステムそのものへの知識やシステム開発プロジェクトの経験が少ないということです。

そのため、事業や業務に必要なITシステムがどのようなものなのかを定義することが難しくなります。

一方で、開発側の人も一般的にビジネスの知識や経験が少ないため、事業や業務に関して定義することが難しくなります。

ここが要件定義の難しさであり、要件定義のおける専門性の谷といえるでしょう。

この専門性の谷のために、冒頭で示したように多くのシステム開発が要件定義を理由として失敗していると考えられます。

この専門性の谷を渡るためには、ビジネス側と開発側の協力が特に必要になってきます。

そして、要件定義を推進し、様々なニーズを取りまとめられる人が世の中で求められている人材です。

要件定義ではビジネスと開発の協力が特に必要. Photo by Unsplash Antonio Janeski

まとめ

本記事では以下のことを説明しました。

  • システム開発が失敗する一番の理由と世の中で求められている人材
  • システム開発全体において要件定義は誰が何をするのか
  • 要件定義の難しさ(専門性の谷)

要件定義における専門性の谷を乗り越えるための『要件定義に必要なスキル』については以下の記事で説明します。

tracery.jp

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:インターネットを利用して異なる国や地域にある顧客に商品やサービスを販売するオンラインビジネスの形態。このビジネスモデルでは、企業は国境を越えて製品を提供することで、より広範な市場へアクセスし、多様な顧客層にリーチすることが可能になる。