.png)
１～２年前「システム内製化に舵を切る企業が増える」という予測をよく耳にしました。2018年末の現在、本当にそうなったのかはよくわかりませんが、IPAの「IT人材白書2018」によれば、社内にITのスキルを蓄積・強化するためにIT業務の内製化を進めている企業は（アンケート回答企業の）全体で5割弱とのことです。工程でいえば、企画・設計など上流の内製化を進めており、大規模の企業ほどその傾向が強いことが見て取れます。
上流工程の重要な役割の１つとして「業務仕様を固める」ことが挙げられます。本ブログをご覧いただいている皆様の中にも、現在その役割の中心を担っている方、補助的に関わっている方、今後関わっていきたいと考えている方がいらっしゃるでしょう。そんな皆様に質問を投げかけてみたいと思います。
「業務仕様を固める」にあたりどのような方法を取りますか？
実際のところ、業務要件定義には方法論が少ないと思います。「システム開発方法論」を持つ企業はありますが、業務要件を整理するパートに関しては抽象的な表現になっており、大雑把な成果物サンプルが載っている程度の場合があります。あるいは、具体的に表現されているものの、その遂行が形式的になっている場合があります。この場合、業務仕様を固める方法は人依存になってしまいます。
筆者は、個人的には「徒弟制度」にはそれなりの良さがあると考えていますが、一方で標準的な方法論を学んでおくことが重要だとも考えます。そこで、本エントリーではDOAによる業務要件定義を紹介させていただきます。
まず「DOA」について簡単に説明をします。
DOA(Data Oriented Approach)は「データ中心アプローチ」と呼ばれ、業務要件に基づいてデータの構造を明確にした上で、システム設計を実施するアプローチのことを指します。データの構造を明確にするにあたっては概念データモデルを作成します。DOAをシステム設計方法として紹介するところもありますが、弊社では業務分析法だと考えています。
続いて、なぜ業務要件定義をDOAで進めるべきかを述べます。
一言でいえば、業務システムは「事物をデータとして蓄積するシステム」だからです。業務上の「モノやコト」をデータとして捉え、これを登録・加工・参照するのが業務システムの本質です。あるユーザがデータを登録・加工し、それを他のユーザが参照して次の業務を行います。この連鎖がビジネスです。画面や帳票などは、この連鎖を効果的、効率的に行うためのものでしかありません。業務と業務のインターフェースであるデータを先に整理しない理由がどこにあるでしょうか。
DOAによる業務要件定義プロジェクトの進め方について少しだけ触れます。
※弊社ではこの進め方を業務要件定義方法論「PLAN-APL」としてまとめています。
詳しく知りたい方はお気軽にこちらまでお問い合わせください。
概ね以下の流れで進めていきます。
- システム概要の理解＋現状資料の収集
- 現状骨格モデルの作成
- ヒアリングによる課題の洗い出し
- 現状業務プロセス分析
- 現状データ分析
- 既存関連システムの理解
- 業務課題定義
- 新規業務設計（新規業務プロセス＋新規データ構造設計）
- 新規入出力設計
- データ定義
- システム処理機能要件
ポイントとなる点を1つ挙げるとすると「現状データ分析」のタスクです。ここで現状のビジネスのデータ構造をしっかりとおさえます。その理由は2つあります。
１．ビジネスで使用されるデータには継続性があり、情報システムが新たに構築されても、
大部分のデータは継続利用されるためです。
現状業務から新規業務に移行する際に、継続して利用されるデータの割合が多ければ多い
ほど、現状データモデルの活用が新規業務要件定義の近道となるのは明らかです。
２．新規業務要件を検討する場においてコミュニケーションの質と効率が向上するためです。
コミュニケーションの質と効率が低下する原因は「現状業務に対する認識がずれている場合」
と「話す用語の意味が人によって異なる場合」が大半を占めます。
現状データモデルは、現状業務を客観的に表現するとともに、モデル上で使われる業務名や
ファイル名が用語の意味を明確にするため、これらの原因を取り除くと言えます。
DOAが誕生してから30年以上が経過していますが、「若い世代のITエンジニアの方々にとっては逆に新鮮だったりしないか」と思ったのが本エントリーのきっかけです。もしDOAに興味を持っていただいたなら是非インターネットや書籍で調べてみてください。
また、弊社では「システムエンジニアのための業務要件定義セミナー」と題し、DOAに気軽に触れていただける場を無償で提供しております。ご都合に合わせお気軽にお申込みください。
↓こちらをクリックいただくと申込ページに移動します。
