システム要件定義の手法である「DOA」とは

システム開発において 「DOA」とはData Oriented Approachの略で、要件定義フェーズのアプローチ手段の1つです。

本記事では要件定義とは何か、DOAというアプローチ手法にはどのようなメリットがあるかなどを紹介していきます。

1.　システム開発における要件定義

システム開発において要件定義は非常に重要度が高い項目になっています。要件定義において発注側の求めている課題や要望が明確化することができるので、開発において欠かせない項目となっているのがポイントです。

要件定義を行うことで効率の良い開発に結び付くので、開発側と発注側で細かく話し合い、要件定義を図っていくことが求められます。

システム開発の上流工程

システム開発における上流工程は、システム開発・設計において最初に行う初期の段階を指します。「要件定義」「機能定義」「構成管理」「計画立案」などを策定し、システム開発における詳細や全体の流れを決定づけることが可能です。

上流工程はシステム設計に当たる部分なので、疎かにしてしまうと実際の開発を行う下流工程に悪影響が出てしまいます。開発を行う際に開発の方向性がブレてしまったり、スケジュールに問題が発生したりと開発がスムーズに進まなくなってしまうでしょう。

また、上流工程を上手く組んでいないとコストの増大につながる恐れもあります。上流工程が上手く設定できていないために見積もりが甘くなってしまい、開発側が全く想定していなかった機能追加が後々に発覚し、スケジュールにも悪影響が出てしまうでしょう。

さらに、上流工程の設定が甘い場合は、開発が完了した後の運用後にも問題が浮き彫りになる可能性もあります。発注側が開発側の想定していなかった運用の仕方をして、トラブルを引き起こし問題になってしまう場合があるのです。

このように上流工程を上手く組まないと様々な問題が発生してしまいます。そのため、本格的に開発を開始する前に開発側と発注側で細かく話し合い、上流工程を完璧にしましょう。

システム開発における要件定義など、重要工程である上流部分についてお困りの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した方法、また対応可能な開発会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

2.　システム要件定義とDOA

システム要件定義が行われる際には様々なアプローチ方法があります。 今回はその中でも、近年広く使われている「DOA」というアプローチ手法についてご説明します。

他にも「DOA」と関連のある「POA」の解説やDOAとPOAの違いの違いについてもご紹介しているのがポイントです。

DOAはシステム要件定義にも関わってくる部分となっているので、システム要件定義についてさらに知識を深めたいという方は、是非ご参考にしてください。

DOAとは

「DOA」とは、Data Oriented Approachのことであり、「データ中心アプローチ」と訳されます。具体的には業務要件に基づいてデータの構造を明らかにし、システム設計を行うアプローチのことを指しているのがポイントです。

まず業務で扱うデータ全体をERモデルなどの手法でモデル化し、データベースやデータファイルの設計や構造を作ります。その後実際に開発するプログラムはこのデータ群を元に設計・実装されるのが一般的なDOAの流れです。

実際にメリットとして、DOAをシステム構造の基礎におくことで、業務内容や手順に変更があった場合でもデータベース部分は触らずとも、プログラムのみを修正するといった更新がしやすくなる点が挙げられます。そのため、開発効率の向上に繋げられるのがポイントと言えるでしょう。

システム要件定義で重要となるのは「何を中心として定義するか」であり、DOAは特に「業務で使われるデータ」を考え方の中心に据えた手法です。実際にシステム開発において業務に使われる機能を優先できるので、要件定義の手法として用いられることが多くなっています。

POAとは

DOAの確立までは、「POA」と呼ばれる手法が一般的でした。 POAでは業務プロセスを中心にしてシステムの設計を行います。 業務ごとに切り分けてシステムを考えるので単一での設計は比較的楽に進めることができます。

業務のフローや工程を図などに落とし込んで定義し、それに合わせてシステムの挙動などを策定していくので、現実の手順に基づいてシステムの動作や詳細を考えることから、関係者にとって分かりやすいというメリットもあります。

しかし、複数の業務に跨ってやりとりする場合、相互の連携を改めて行わなければならず、それに応じて複雑性が増していきます。また、あくまで設計段階での業務プロセスを反映しているため、後々業務内容自体が変更になった時の改変が問題となっていました。

POAは業務手順をシステムに反映させることに重きを置いているため、部署を超えた利用やデータの再利用などは考えられていないことが多いです。そのため、システム間でデータの重複や不整合が起こり、接続などがあまり上手くいかず開発効率を下げてしまう場合もあり得ます。

実際に、業務へのコンピュータ導入の初期である1970年代まではPOAが一般的でしたが、システムの規模や種類が増え、システム開発の工程も複雑したという背景からより正しいデータ管理が重視されるとDOAへの注目度数一気に高まりました。

DOAとPOAの違い

DOAでは、まず業務プロセス全体を俯瞰し、一つのデータベースを設計します。 複数の業務の流れを把握した上での設計になるので、POAよりも初期段階での複雑性は高くなります。

ただ、あらかじめデータの整合性を保つことを前提として設計されるので、最終的なシステム間でのやり取りは格段にスムーズになります。そのため、規模の大きい開発や、複雑な工程が存在するシステムではDOAは大きく役に立ちます。

また、業務内容が変更になった時でも、データベースに合わせた形で該当箇所のみを修正すれば良いので、 改変も楽になります。結果的に最初は複雑性が高まりますが、後々にトラブルがあった際などは後戻りが少なくなるので効率的という見方も可能です。

DOAがどういった手法であるかを知っておくと、実際の要件定義でのすり合わせがやりやすくなります。システム開発を外注する際の前準備として、覚えておくとよいでしょう。

システム開発でのDOAを使った要件定義など、上流部分、依頼内容の具体化などお困りの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した方法、また対応可能な開発会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

3.　DOAのメリット

DOAには「ビジネス視点における普遍性が高い」「大幅なシステム改修が比較的少ない」というメリットが存在します。そのため、システム開発において活用する意味は十分にあると言えるでしょう。

そこでここからはDOAのそれぞれのメリットについて詳しく解説します。いずれもDOAを細かく理解する際に必要な項目となります。要件定義をよりスムーズに行うためにも是非チェックしておきましょう。

ビジネス視点における普遍性が高い

システム開発における業務はでフロー含め変更されることは往々にしてありますが、扱うデータ自体は普遍的であることが多くなっています。POAは業務フローが変わると煩雑になってしまう可能性がある一方でDOAはそれぞれの業務フローを明確化できるので便利です。

DOAでは必要となるデータ項目を洗い出せるため、業務内容を漏れなく把握することができ、業務フローの変更にも臨機応変に対応することが可能です。システム開発に必要なデータとその流れを可視化することで、業務内容を分かりやすく視覚的に理解することができるので業務に携わる関係者全員の共通の認識を得ることも可能です。

また、システム開発における業務内容を漏れなく把握することが可能なので、現時点での業務分析、システムが抱える問題点などを掴みやすいのもポイントです。このようにDOAはビジネス視点における普遍性が高いため、システム開発におけるメリットに繋がります。

大幅なシステム改修が比較的少ない

DOAでは、普遍性の高いデータを最優先順位にしているので、変動が少ない部分であり、システム改修が必要な場合最小限に抑えられる傾向があります。

また、DOAでは具体的な処理内容やプログラムの実装とは別にデータを定義・蓄積するため、様々なシステムや部門で共有される情報資産としてのデータ基盤を構築することも可能です。そのため、大幅なシステム改修が少なくなり、無駄な工数を押さえることができます。

戻しや修正が少なくなるだけで開発効率は圧倒的に高まるので、DOAの段階でデータ基盤を整える価値は高いと言えるでしょう。

また、一度データ基盤を整えれば、システムやプログラムの追加や修正といった局所的な変更も容易です。万が一、システム改修が必要になった場合でも臨機応変に対応できるという強みがあります。

4.　DOAの進め方

DOAの進め方としては下記の流れが一般的です。

DOAの進め方

• データをモデル化する
• データの流れを作成する
• 必要なデータを集める
• データを整える

いずれの工程もDOAを明確に策定する際に必要なものになっています。理解度を高めておくと、それぞれの工程を理解しておくことでよりスムーズにDOAを策定することに繋がるでしょう。

ここからはDOAの進め方を1つ1つ詳しく解説するので、是非ご参考にしてください。

データをモデル化する

DOAの工程を進める際はER図などの手法でモデル化しましょう。ER図とはデータベース設計において用いられることの多い設計図で、作成したER図がそのまま物理データベース上に変換できます。

そのため、データベース設計手法において用いられることが多いのが特徴的です。視認性も高まるため、無駄のなく効率の良いシステム開発を行う際に必須となるツールと言えるでしょう。

実際にER図を用いると、システム全体の構造を手軽に把握できるので開発における後戻りのコストを防ぐことが可能です。また、ER図を開発後も残しておくことで使用内容の変更が容易になるので、運用・保守フェーズで大いに役立ちます。

これらの理由からER図はDOAとの相性が高くなっています。開発側と発注側で必要となる各種ワークフローやビジネスルールを効率よく作成できるので、DOAを用いて要件定義を行う際は非常に便利です。

データの流れを作成する

データをモデル化した後はデータがどのように加工・編集されていくかを流れにするのが一般的です。実際に下記の項目を入出力で確認して流れを作成していきます。

• 項番
• 項目名
• オブジェクト種類：テキスト、ラベル、イメージ、リスト
• 属性：全角、半角、数値など
• 画面表示内容
• 文字フォントの種類
• フォントサイズ
• 参照テーブル
• 参照項目

必要なデータを集める

データの流れが判明した後はDOAにて集めたデータを分類化しましょう。顧客グループ、製品グループなど細かくふるい分けることでデータ収集の効率を高めることが可能です。

実際に必要なデータを集める際には、Excelなどで項目ごとに分けると更に見やすくなります。

必要なデータを集める際に集めたデータがビジネスの記録なのか、ビューなのか、既に存在するのか、異音同義語はないか、同音意義はないかという細かいところまで分けられると、さらに正確なデータベースを構築することが可能です。

DOAに必要なデータを集める際は、ただ集めるだけではなく関係者に共有しやすく、運用後も明確に確認できる体制を整えておくことを意識しましょう。

データを整える

DOAに必要なデータを集め終わった後は、正規化、最適化、一般化。データの重複を洗い出し、抜け漏れがないかを確認しましょう。実際にシステム開発に使うデータになるので、整理整頓が非常に大切です。

もし、データが重複したりしていると後々作業トラブルや、関係者同士での認識のズレに繋がります。システム修正や修正作業が発生するので、なるべくこの段階で使うデータは整理しておくことがおすすめです。

データモデルを一元化し、開発側と発注側でトラブルの内容にデータを整えて最終調整を行いましょう。DOAの工程の最終段階となるので綿密なチェックを重ねることが求められます。