業務システムの開発ドキュメント標準化 第１回：開発ドキュメント体系と業務フロー

常駐・派遣型ビジネスから脱却するには

ソフトウェア業界の仕事は、下請け・孫請けのピラミッド構成となることが多く、常駐・派遣型のビジネスがかなりのパーセンテージを占めています。そんな中、他の業界と同じように、下請け脱却を目指して"一括請負"で仕事を引き受けたいとする会社もあります。    その志は善しとしましょう。しかし、肝心の"実力"が伴っていないと発注者も受託者もお互いに手痛い目に遭います。ここで言う"実力"とは、単なる技術力のことではありません。スケジュール管理や品質管理、コスト管理などのプロジェクト管理の技術・体制を社内で持っているかどうかが成否の鍵となるのです。    筆者の会社は創立11年目なのですが、創業以来「常駐・派遣の仕事はやらない！」という起業時のポリシーを貫いて来ました。C/SやWebのシステム開発を主体としているのですが、10年間の中では当然（？）、いくつかの失敗プロジェクトもありました。その苦い経験の中で「成功率と生産性の向上」を永遠の経営課題と定めて取り組んできたのです。    前回の連載「即活用！企業システムにおけるプロジェクト管理」では、この成功率向上という課題解決のために体系化したプロジェクト管理手法「PYRAMID（ピラミッド）」について紹介しました。    今回は、もうひとつの課題「生産性の向上」に対する取り組みのひとつである業務システムの開発ドキュメント標準「DUNGEON（ダンジョン）」について紹介していきます。    これは、システム開発における「ドキュメントの標準化」を目的とするものです。担当者ごとに異なる"自己流"のドキュメントではなく、各人のノウハウを結集したベストのドキュメントフォームを策定しました。「PYRAMID」と同じく、「DUNGEON」も組織全体で管理し、各プロジェクトでこれを活用しながらバージョンアップを行っています。    PYRAMIDもDUNGEONも、"実践的"なものを目指しており、即活用できるようなテンプレートを用意しています。PYRAMIDではプロジェクト管理、DUNGEONでは開発資料に関するドキュメントを定めています。図1は、プロジェクトサイクルにおけるPYRAMIDとDUNGEONのドキュメント範囲を表したものです。 図1：プロジェクト管理手法「PYRAMID」と開発ドキュメント標準「DUNGEON」 （画像をクリックするとExcelファイルをダウンロードできます。/44.0KB） http://thinkit.co.jp/images/project/1/1/document.xls    今回の連載ではDUNGEONのドキュメントを説明しながら、テンプレートなどを順次ダウンロードできるようにしています。試用してみたい方は、自社の開発スタイルに合わせて手直しして使ってみてください。これらの資料を活用していただいて、日本のIT業界が常駐・派遣スタイルから脱却するのに少しでもお役に立てれば幸いです。

 

開発ドキュメントの種類と内訳

DUNGEONでターゲットとしているのは、主に業務系システムの開発です。これにはWebのポータルサイトやe-Learningなども含まれますが、ゲームソフトや組み込み系ソフトウェアなどは想定していません。C/SやWebなどのシステム開発において、最適なドキュメントはどういうものかというテーマを主体として体系化しています。    業務系システムの開発フェーズは、「要求分析 → 基本設計 → 詳細設計 → プログラミング → 単体テスト → 結合テスト → 総合テスト」という順に工程が進んでカットオーバーを迎えます。DUNGEONでは、各々のフェーズにおいて作成するドキュメントを表1のように定めています。

工程 ドキュメント成果物 内容 範囲 媒体 要求分析 （要件定義） 要求分析書 （要件定義書） 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性/定量） 体制図 概略スケジュール 全体 Excel 基本設計 （外部設計） 業務フロー   全体 Excel システム構成図   全体 Excel ER図   全体 OBER テーブル定義書   全体 OBER 機能一覧表   全体 Excel 設計書記述様式   全体 Excel 基本設計書 （外部設計書） 概要 I/O関連図 画面/帳票レイアウト 個別 Excel 詳細設計 （内部設計） 画面遷移図   全体 Excel 詳細設計書 （内部設計書） 概要 I/O関連図 画面/帳票レイアウト 項目説明書 更新仕様書 補足説明 個別 Excel プロジェクト共通ルール   全体 Excel プログラミング         単体テスト 単体テスト仕様書 /報告書   全体 Excel 結合テスト 結合テスト仕様書 /報告書   全体 Excel 総合テスト 総合テスト仕様書 /報告書   全体 Excel 表1：開発フェーズにおけるドキュメント成果物    これらのドキュメントの標準フォーマットを規定し、そのテンプレート（記入例を含む）を提供するのがDUNGEONの位置づけとなります。

全体／個別

表1の「範囲」欄には、ドキュメントが全体か個別かを記しています。これは、ドキュメントファイルがシステム全体で1ファイルとなるか、プログラム個別にファイル分割されるかを表したものです。    例えば、業務フローやシステム構成図はシステム全体に対して1ファイル（枚数は複数枚となりますが）作成されるので"全体"、基本設計書や詳細設計書はプログラム単位（例えば受注入力など）で個別ファイルとなるので"個別"ということになります。

ドキュメント媒体

表1の「媒体」欄にはドキュメントのファイル様式（WordやExcel、PowerPointなど）が記されています。皆さんは、普段どのアプリケーションで設計書を書いていますか？著者自身は「文章なんだから当然Word」という根っからのWord派なのですが、社内にはなぜかExcel派も多く棲息しています（PowerPoint派もいました）。    どちらも、それなりの譲れない主張はあるようなのですが、あくまでも"ドキュメントの標準化"を目指しているので、WordとExcelを混在してテンプレートを作成しておくのは非合理的です。Word派 VS. Excel派の大議論の結果、DUNGEONではプロジェクト管理手法PYRAMIDに合わせてExcelを基準とすることになりました（無念）。    ただし、PYRAMID同様、ツールが有効な部分はできるだけツールを活用する方針です。現段階ではER図とテーブル定義書に関しては、自社ツール「SI Object Browser ER」を使うことにしています（自社ソフトなので当然ですが…）。

 

基本設計工程のドキュメント

要求分析フェーズは後回しとし、基本設計フェーズのドキュメントから説明したいと思います。業務システムの設計は基本設計（外部設計とも言う）で骨組みを決め、詳細設計（内部設計）で肉付けを行います。    基本設計がユーザとの仕様確認、詳細設計はプログラマに対する指示書という役割が強いとも言えます。ただし、基本設計と詳細設計は別物ではなく、詳細設計は基本設計をベースに肉付けを行います。    ここでのポイントは、リバースしないことです。基本設計をベースにして詳細設計作業を行うのですが、その結果基本設計の内容が変更になったとしても後戻りしません。詳細設計は、基本設計を"踏み台"にするものと位置づけており、詳細設計書が完成したあかつきには基本設計書は顧みないことにしています。

業務フロー

今回は基本設計工程における標準ドキュメントの中から、「業務フロー」について説明しましょう。業務システムを構築する際は、ユーザの業務の流れを正確に把握する必要があります。流れをイメージしないで断片の組み合わせで作成されたアプリケーションは、運用に大きな落とし穴がある場合が多いからです。業務に関して自分の頭を整理し、ユーザと確認し、プロジェクトメンバーにも伝える、そういう重要な役割を持ったドキュメントが業務フローなのです。    図2は、DUNGEON様式の「業務フロー」の記入例です。表紙、記号説明に続いて、業務単位にシートを分割して業務フローを記述していきます。以下、業務フロー作成時のポイントについていくつか解説しましょう。 図2：DUNGEONの「業務フロー」記入例 （画像をクリックするとExcelファイルをダウンロードできます。/86.0KB）

担当部門（ロケーション）

業務フローは、業務担当者の役割分担が明確にわかるようにします。そのため、業務処理の行われる場所を欄で分け、業務の流れに沿って記載します。図2の例では、営業とユーザに欄を分けて、見積依頼から見積、見積書出力、再見積、受注、注文請書出力までの流れを上から順番に記載しています。

主なデータ

図2の例では、左端に主なデータ欄を用意しています。業務フローの書き方も、"データを書く派"と"データを書かない派"がいます。ユーザ自身が業務フローを書くような場合は、データを書かないケースが多いでしょう。しかし、我々のような開発サイドが業務フローを作成する場合は、主なデータを記載した方がわかりやすいと思います。    入力処理でどのようなデータができるか、どのテーブルから照会画面や帳票出力のデータを取り出すかなどが明確に理解できるからです。その際に記載する対象のテーブルは主要なものだけでかまいません。業務の流れをデータの流れと対比させて見る目的さえ達成できれば十分です。

 

画面や帳票はすべて記載

業務フローには、システム化の対象となる画面・帳票はすべて登場するようにします。図2の例では、以下の表2に示すような機能一覧表に記載されている画面・帳票機能が業務の流れの中で記載されています。    逆の見方をすれば、機能一覧表に登場する機能が、業務の流れのどこで使われるかを示すのが業務フローなのです。そして、その機能ひとつずつについて"個別"に基本設計書を作成していくことになります。

サブシステム 機能 画面 帳票 バッチ 備考 見積〜受注 見積入力 ○       採算計算書   ○     見積書   ○     見積書（控）   ○     注文書   ○     見積一覧 ○       受注入力 ○       注文請書   ○     注文請書（控）   ○     表2：業務フローの画面・帳票を機能一覧と対比

まとめ

今回は、業務システム開発の各工程におけるドキュメント成果物の種類について、弊社の開発ドキュメント標準DUNGEONをベースに説明しました。基本設計でデッサンし、詳細設計でその絵をペイントするという役割分担で、後戻りしない設計ドキュメント方式としています。    最初のドキュメントテンプレートとして、業務の流れを理解するのに欠かせない「業務フロー」について、具体例をもとに解説しました。システム化の対象となる画面や帳票を業務フローに漏れなく記述すること、記述するデータ（テーブル）については理解を深めるための主要なものでかまわないこと、などのポイントを覚えておいてください。