TRACERY Lab.(トレラボ)

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

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