要件定義への橋掛け~失敗しないシステム開発の準備#1~

要件定義への橋掛け~失敗しないシステム開発の準備#1~

システム設計の登竜門!要件定義入門から関連した内容を補うように紹介しています。要件定義をする際に気になる部分の補足となるように派生して本記事を作りました。読んでいただけたら幸いです。

要件定義の前に

本来、システム開発プロジェクトにおいて「システム化企画」や「業務分析」といった工程は、「要件定義」の前に終了していることが前提です。業務分析/新業務定義で行うべき作業には、以下の2つがあります。

・システム企画に基づく ToBeモデル(あるべき姿)の策定·作成

・AsIsモデルの作成

システム化企画ではビジネスの視点から、今回のシステム開発の投資効果、目的、方向性を明確にします。「超上流工程(上流工程とはシステム開発の初期工程を指し、「企画」「分析」「要件定義」といった工程のこと)」と呼ばれることもあります。業務分析では、システム化企画を基に ToBeモデルを作成し、現状分析の結果作られる AsIsモデルを参考にして、ToBe新業務の形を想定可能にします。システム化企画と業務分析により要求を明確にします。その要求を基にToBeモデルを作成します。そこから、AsIsモデルと制約を踏まえて、要件として整理し、新しく ToBeモデル化します。これが要件定義で行うべき本来の内容です。

上の図の「①元ToBeモデル」の作成と、「②AsIsモデル」の作成までが、要件定義の前に行っておくべき作業です。図の二重線、つまり「③新ToBeモデル」の作成が、要件定義で行うべき作業です。

まず初めに…目的の確認

エンタープライズ系システムかコンシューマー向けシステムかを問わず、システム開発には「目的」が存在します。「何のために」このシステムを作るのかです。まずはその目的を明確にしましょう。その際には、可能な限りあらゆるドキュメントを収集しましょう。エンタープライズ系システムであれば、業務規定集やマニュアル等は必須です。コンシューマー向けシステムであればビジネス企画書などです。そして現行システムのドキュメント類があるなら、参考にします。これらのドキュメントに目を通した上で、ステークホルダーとなりうる人、組織のトップ、業務責任者、業務担当者にインタビューを実施します。最低限、以下の項目については、考えを聞き出しましょう。

・「目的」

・「対象」

・「効果」:期待している定性効果/定量効果と投資回収期間

上記3点を踏まえた新システムイメージシステム以外の組織、役割のイメージインタビューの結果は一覧形式でまとめていきます。但しこれらの作業は、新規開発のときだけで構いません。保守·修正の場合は、大きな方針変更を除き、ある程度省略しても問題ありません。

調査

インタビューの前に最低限、システム開発対象の「業界」について最近の動向を調査し、インタビューで考えを聞き出します。もし明確な考えがないような場合には、インタビューする側から業界動向を踏まえた提案を行う必要があります。またインタビュー後も、内容の精査を目的として追加調査を行う場合があります。

要求の整理

インタビューや調査の結果を踏まえて要求を整理し、新たなビジネスモデルや、システム化企画となりうるかを検証します。

システム化計画

新規システムの場合、目的·対象·効果の3つを明確にしていきます。A3サイズの用紙の中央にシステムを描き、その周りに、関係のあるインフラ、顧客等を制限なく描き出していきます。保守フェーズにおける修正案件の場合は、今回の開発が、開発時に策定した目的や方向性とずれていないかを確認します。エンタープライズ系システムでは、「システム化計画→要求→要件」を明確にトレースできるように整理する必要がありますが、コンシューマー向けシステムでは、計画から要求や要件の「時間軸が短い」ため、時間をかけてはいけません。特にアジャイル型開発を適用する場合は顕著です。コンシューマー向けシステムの「効果」は、ビジネス価値とイコールの場合が多いでしょう。そのため、例えば「売り上げの増大」等を目指して、早期のリリースを最優先します。エンタープライズ系システムの場合、数年にわたるシステムライフサイクルの中で投資回収が行われればOKです。何を最優先にするかで、新システムのイメージをどこまで整理しておくかが変わってきます。

ToBeモデルの作成

新ビジネスモデルを基に、ToBeモデルの作成を開始します。このToBeモデルは、プロセスモデルとデータモデルの概要を描くことから始めます。最初はかなりラフなものになります。プロジェクトの考え方次第ですが、この工程に時間をかけて詳細レベルまで、つまり ToBeプロセスモデルとデータモデルを、実際の業務レベルまで想定可能な状態に落とし込んだ場合、要件定義を含む後工程の工数はかなり軽減されます。保守フェーズにおける修正案件の場合、現行システムのシステム全体図、データモデル、プロセスモデルがあればよいのですが、ない場合もあります。そのときは、修正対象のシステムを明確にするために、システム全体図を作成しましょう。システム全体の中で修正対象機能の位置づけ、連携の有無がわかるレベルを目指します。さらにプロセスモデルとしては、開発対象システムに関連がある大きな括りのプロセスの概要フロー図を、ラフで構わないので作成しましょう。

現状分析

AsIs分析の目的は、業務の現状を把握することです。所謂、現状分析をどのように考えるかは大きな問題です。この項の冒頭で AsIsモデルについて触れましたが、筆者は「全くの新規システムを開発する場合、現状分析に時間をかけるべきではない」という考えを持っています。現状はあくまで参考情報とします。特に、Asls業務フローの作成に時間をかけるのは無駄です。要件定義においては、元TOBEモデルを前提にして、その制約としてのAsIsモデルを参考にします。AsIs業務フローよりもむしろ、現行システムに関する以下の情報を押さえておく必要があります。

(1)非機能要件

データ更新及び業務処理の頻度、処理速度や応答速度、データ量、そして昨今では最低限求められていたューザビリティなどについて、現行システムのドキュメントやUIのハードコピー等を参照して洗い出します。もし現行システムがない場合、例えば、コンシューマー向け新規事業等の全くの新規システムや、ドキュメントがそもそもない場合には、担当者からの聞き取りを行います。非機能要件が要件定義工程で埋もれてしまうと、システムテストまで問題を先送りしてしまい、後々大問題になるので要注意です。

(2)データ構造

概念データモデル、データライフサイクルが把握可能であるものがなければ、ドキュメントを基に、データ構造の概要が把撮可能なレベルのラフな AsIs概念データモデルは作成しましょう。

(3)コード体系

現状分析で一番時間を割くべきは、この記事に続く#2のメインの内容となる「データ要件の明確化」でも説明しますが、「コード体系」です。現行コード体系の中には、現行システムのロジックがたくさん詰まっています。特に「意味ありコード」(例えば、取引先コードの頭3桁が地域を表す等)は要注意です。現行システムのコード設計書が存在するならそれを参照しますが、存在しない場合は厄介です。項目名に「…コード」「…区分」「…フラグ」といった文言が付与されている項目を抽出し、アプリケーションの目星をつけてロジックを調査するしかありません。もう一つ、現状分析で大切なのは、「現行システム」以外の部分、つまりビジネスや業務に近い部分です。例えば、エンタープライズ系システムの場合、組織図や分掌規程には目を通しておいた方がよいでしょう。業務フローからはわからないビジネスルールが浮き上がってくることがあります。

 

現状問題点の認識

すなわち、現場の声を吸い上げて「業務要件」「システム要件」を定義する際に、高次の「ビジネス要件」と食い違いが生じないよう、注意を要します。両者の間がトレースできるように、きちんとつながっていなければならないということです。そうしておけば、経営の観点からも、システムの効果を確認できるはずです。

 

まとめ~システム企画/業務分析システム企画/~

業務分析業務分析/新業務定義の具体的な手順は以下のとおりです。

Step 1 目的の確認

Step 2 調査(インタビュー)

Step 3 要求の整理

Step 4 システム化計画の立案

Step 5 ToBeモデルの作成

Step 6 現状分析~ Aslsモデルの作成

実施作業の場合分け

これらの作業項目を、下記のような場合分けに応じて、適宜、実施していきます。

エンタープライズ系システム→新規➊→修正③

コンシューマー向けシステム→新規❷→修正④

➊の場合、具体的手順を全て行います。❷の場合、時間をかけずに目的を明確化します。開発対象システムがエンタープライズ系システムへの影響度が低い、他システムとの連動がない場合、Asls 分析は省略し、ビジネス価値に焦点をあてます。③の場合、ビジネス要求の変更、サブシステム単位の修正ならば、システム全体の目的からブレていないかを確認した上で、既存システムとの連携、外部接続を意識して整理します。業務要求の変更、プロセス単位の修正ならば、システム全体との整合性を意識して追加·修正対象のプロセスの位置付けを明確にします。システム要求の変更、機能レベルの修正ならば、想定機能の位置付けのみ整理します。④の場合で、ある程度のプロセス機能のまとまり単位で大幅な修正が入る場合には、③同様の整理を行います。プロセスレベルの修正ならば、ある程度の規模の場合に限り、エンタープライズ系システム同様の整理をします。機能レベルの修正ならば、想定機能の位置付けのみ整理します。

【広告】Librus Tech Communityのお知らせ

Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18

テックカテゴリの最新記事