システム開発で必要とされるドキュメントフロー
はじめに
前回、セミナーで「設計の効率化＆品質向上のために3つのうちどれが一番大切か?」と質問をしたところ、圧倒的に「設計の標準化」に手を上げる人が多かったとお伝えしました。
- (A)設計スキルを教育する
- (B)設計の標準化を進める
- (C)設計ツールを導入する
やっぱり、設計の標準化は大事なんですねということで、今回もInception Deckを用いて、そもそも「なぜ標準化が必要なのか」というところから入ってみましょう。
なぜ設計書の標準化が必要なのか
これ、逆に考えてみると分かりやすいようです。もし、設計書が標準化されてないとどうなるでしょうか。
システムエンジニアは、いちいち「どのような設計書が良いのか」を考えながら仕様を書き込む必要が生じます。場合によってはプログラマーがプログラミングをするのに必要な情報が漏れていることもあるでしょう。また、設計書を資産として捉えたとしても、システムごとにバラバラの設計書だったら、保守・運用の担当者が読み解くのも大変です。そう考えると、設計書を標準化することで図1のような効果があることが分かります。
図1：設計書を標準化する目的
システム開発全体の標準化
標準化するのは設計書だけとは限りません。目を少し遠ざけてシステム開発全体の標準化を考えてみましょう。そうすると、標準化すべきドキュメントとして図2のような対象が浮かび上がってきます。これらの資料を目的別に整理すると、大きく「プロセスの標準化」と「ドキュメント(成果物)の標準化」に分けられます。
プロセスの標準化は、WBS(Work Breakdown Structure)の標準や見積基準など、主にプロジェクト管理関連です。当社では第2回で紹介した「PYRAMID」という標準テンプレートを経て、現在は統合型プロジェクト管理システム(OBPM)を使うことで標準化を実現しています。
一方、ドキュメント(成果物)の標準化は、設計書やテスト仕様書、コーディング規約などが対象です。当社では「DUNGEON」という標準テンプレートを経て、システム開発用CADツール(OBDZ)を使うことで、機能設計書などの標準化を実現しています。
図2：システム開発の標準化対象
システム開発のドキュメントフロー
ここではプロジェクト管理関連は対象外として、ドキュメント(成果物)の標準化を取り上げてみましょう。図3はシステム開発の上流工程である要件定義、基本設計、詳細設計におけるドキュメントフローです。この図を基に、どのようなドキュメントが必要とされるかを説明します。
図3：システム開発のドキュメントフロー
(1) 要件定義書
これを読めば、どのような目的でどのようなシステムを作ろうとしているのかがひと目でわかるものです。現状(as is）の課題を解決するために、どのようなもの(to be)を作るか、それに必要なコストとスケジュール、得られる効果など、プロジェクトのゴーサインを出すために必要な情報がまとまっています。
(2) ユースケース図
システムを利用する人(アクター)が、どのようにシステムに関わるか(ユースケース)をシンプルに図示したものです。例えば、図4は当社のプログラミングスキル判定サービス「TOPSIC」を用いて、中途採用のスキル判定を行うユースケース図です。
当社(SI)の管理者が問題を作成し、ユーザー企業の管理者が問題を選んで、応募者を登録すれば準備OK。あとは応募者が受験して、ユーザー管理者がその結果を確認する。というようにシステム利用者の役割と関わりがひと目で分かります。
図4：ユースケース図(TOPSICの採用スクリーニング)
(3)業務フロー
ユースケース図は、基本的に時間の流れを表現しにくいので、複数の部門にまたがって業務処理を行う基幹業務システムなどでは業務フローを作成します。図5は見積・受注の業務フローを表したものですが、この図を上から下に読むだけでユーザーから見積依頼を受けて受注に至るまでの業務処理の流れがぱっと理解できます。
図5：業務フロー図
- 麻里：先輩、UMLって知っていますか?
- 先輩：もちろん。Unified Modeling Languageのことで、日本語だと統一モデリング言語などと訳されている。
- 麻里：それってどういうものなんですか?
- 先輩：システムをモデリング(モデル化)するためのドキュメント標準かな。ドキュメントの種類(ダイアグラム：図法)が13種類もあるんだけど、通常、目的に応じて使い分けているよ。
- 麻里：全部、使うってわけじゃないのね。
- 先輩：よく使うのは、ユースケース図とクラス図かな。時間の流れを表現できる図法としてシーケンス図なんかもわりと使われているよ。
- 麻里：うちの会社ではあまり見かけませんね。なぜですか?
- 先輩：う～ん。ひと言でいうと文化かな。ちょっと専門的な記述になるから、お客様が記述ルールを覚えて理解するのがちょっと難しい。だから、お客様が直感的に理解しやすい業務フローや画面遷移図などを使う人が多いみたいだね。
- 麻里：部門によっても文化の違いがあるみたいですね。
- 先輩：うん。ERP部は複数部門に処理がまたがる基幹業務システムだから業務フローを非常に重要視しているけど、画面遷移図は書いてないことが多い。一方、eコマース部はECサイトを作るときに画面遷移図を重要視しているけど、業務フローはそれほどでもないみたいだよ。
- 麻里：構築するシステムの特性によって、作成するドキュメントの優先順位が変わるのね。
- 先輩：ま、誰と食事するかによって、レストランのチョイスを変えるのと一緒かな。
- 麻里：そんなこと言って、先輩は誰と一緒でも、いつも同じ居酒屋ですよね。
- 先輩：「誰とでも平等に接する」を旨としているからね(実は下心をカモフラージュする戦略なんだけど)!
(4)画面遷移図
どの画面からどの画面へ切り替わるかをビジュアル化したものです。例えば、図6はゲームをしながら花の名前を覚えてゆく無料アプリ「花の名前ダウト」の画面遷移図です。Web系のシステムでは、このような画面遷移図を作ることにより、ユーザーを迷子にさせない導線、セキュアな画面とオープンな画面の境界を理解するなどの目的に役立てることが多いです。
図6：画面遷移図(無料アプリ「花の名前ダウト」)
最近、あまり耳にしなくなった言葉に「データ中心設計(DOA：Data Oriented Approach)」があります。これ、実は概念が流行らなくなったわけではなく、ただ単に当たり前過ぎて今さら言うまでもなくなっただけなのです。今も重要性は全く変わらないのですが、ふと「ひょっとして若いエンジニアは知らないかも」と老婆心が芽生えたので、コラムで取り上げてみます。
データ中心設計(DOA)が提唱される前に、一般によく用いられていたのはプロセス中心設計(POA：Process Oriented Approach)です。これは、業務の処理(プロセス)ごとにシステムを設計してゆく方法で、例えば図5の業務フローなら見積業務、受注業務という単位でシステム化を図るアプローチです。業務ごとに考えれば良いので分かりやすい手法ですが、業務ごとに別個のシステムとなりやすく、データの重複や不必要なデータのやり取りが増えるといった問題がありました。
一方で、データ中心設計(DOA)は、まず、データをどのように持つかを考えることを重視します。例えば、図5の業務フローの場合、見積データや注文データなどのデータベース設計を同時に行い、各業務はこれらのデータベースに対してどのようにアクセス(データの挿入、更新、抽出、削除)するかという観点で捉えられます。
通常の業務フローではデータの図は含みませんが、私は図5ように見積データや注文データなどのデータも書き込んでいます。この方がデータを意識したシステム設計がしやすいと感じているからです。また、業務フローを書いてからデータベース設計を行うのが一般的ですが、私の場合は業務フローと並行してERツールを使い、データベース設計も同時に行っています。
データ構造はシステムの骨組みとも言えます。一般に業務は変更になることが多いですが、骨組みさえしっかり作っておけば、システム全体を大きく変更させる必要は生じません。データ中心設計できれいな骨組みを作ることで、業務の変更にも強いシステムを作ることができるのです。
おわりに
今回は、システム開発で作成されるドキュメントの中から、要件定義書、ユースケース図、業務フロー、画面遷移図など、主に要件定義工程で必要となるドキュメントについて説明しました。次回はデータ中心設計(DOA)に基づいたデータモデリングについて解説します。お楽しみに!
