システム開発で作成するドキュメントの体系
はじめに
実は、かなり前になりますが、私はThink ITで2つの連載を執筆していました。
「即活用！企業システムにおけるプロジェクト管理」(2004年)
「即活用! 業務システムの開発ドキュメント標準化」(2005年)
連載終了後、プロジェクト管理に関しては、そこで紹介したプロジェクト管理手法「PYRAMID(ピラミッド)」を統合型プロジェクト管理システム「SI Object Browser PM(OBPM)」として製品化しました。また、開発ドキュメント標準化の方も、記事でダウンロード可能とした開発ドキュメント標準「DUNGEON(ダンジョン)」をシステム開発の設計書作成CAD「SI Object Browser Designer(OBDZ)」として製品化しています(図1、2)。
図1：PMの連載⇒管理手法化⇒専用ツール化
図2：設計ドキュメント連載⇒設計書標準化⇒専用ツール化
今回は、図2の延長としてDUNGEONをOBDZに製品化する際に得たノウハウ、出来上がった製品を各社に導入しながら学んだことをもとに、改めて「設計書はどうあるべきか」を解説します。15年前と変わったこと、変わらないことを踏まえて、令和時代の設計書のあり方について一緒に考えていきましょう。
システム開発のドキュメント体系を見比べる
図3は、15年前の連載でPYRAMIDとDUNGEONのドキュメントをシステム開発(ウォーターフォール型)の工程別に体系化したものです。△マークがPYRAMIDで用意したドキュメントテンプレートで、多くがその後のOBPMに取り込まれています。そして□マークがDUNGEONのドキュメントテンプレートで、このうち設計書に関わるものがOBDZへと進化しています。
図3：「PYRAMID」と「DUNGEON」のドキュメント体系
表1は、図3から開発ドキュメントをピックアップしたものです。「範囲」欄はドキュメントがシステム全体か機能別に作成するものかを表すもので、「ツール」欄は当社でのツール利用状況です。
要件定義書や業務フローなど、まだワープロ作業(ここではExcelと記述)で作成するドキュメントも残っていますが、開発ドキュメントの中心となる基本設計書や詳細設計書はCAD(OBDZ)で作成でtきるようになりました。ER図とテーブル設計書は、データベース設計を効率化するためのデータモデリングツール「SI Object Browser ER(OBER)」を使っています。
表1：開発フェーズにおけるドキュメント成果物
| 工程 | ドキュメント成果物 | 内容 | 範囲 | ツール |
|---|---|---|---|---|
| 要求分析(要件定義) | 要求分析書(要件定義書) | 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果(定性/定量) 体制図 概略スケジュール |
全体 | Excel |
| 基本設計(外部設計) | 業務フロー | 全体 | Excel | |
| システム構成図 | 全体 | Excel | ||
| ER図 | 全体 | OBER | ||
| テーブル定義書 | 全体 | OBER | ||
| 機能一覧表 | 全体 | OBDZ | ||
| 設計書記述様式 | 全体 | Excel | ||
| 基本設計書(外部設計書) | 概要 I/O関連図 画面/帳票レイアウト |
個別 | OBDZ | |
| 詳細設計(内部設計) | 画面遷移図 | 全体 | Excel | |
| 詳細設計書(内部設計書) | 概要 I/O関連図 画面/帳票レイアウト 項目説明書 更新仕様書 補足説明 |
個別 | OBDZ | |
| プロジェクト共通ルール | 全体 | Excel | ||
| プログラミング | ||||
| 単体テスト | 単体テスト仕様書/報告書 | 全体 | Excel | |
| 結合テスト | 結合テスト仕様書/報告書 | 全体 | Excel | |
| 総合テスト | 総合テスト仕様書/報告書 | Excel |
良い設計を行うためには、①開発ドキュメントを体系化し、②個々のドキュメントの標準化を図り、③設計者全員に設計書の記述方法をレクチャーする、ということが大切です。表1を自社の開発ドキュメント体系と照らし合わして見ると、更なる合理化・効率化のヒントが見つかると思います。
- 先輩：あれ、麻里ちゃん。サザエのしっぽを食べたような顔をして、どうしたの?
- 麻里：え、なんですか、それ。失礼しちゃうわ! ちょっとCADについて思案していたのよ。
- 先輩：CADって、コンピュータ支援設計(Computer Aided Design)のこと? 今さら何を考えていたの?
- 麻里：いや、ほら、CADって建設業、土木業、家電、機械、自動車、航空機、アパレルとか各業界で幅広く使われているでしょう。なのに、なんで本家本元のIT業界だけ、いまだにワープロ作業で設計しているのかって、ふと、不思議に思っちゃって……。
- 先輩：なるほど、そう言えばそうだね。でも、昔からCASEツール(Computer Aided Software Engineering)や4GL(4th Generation Language)、RAD(Rapid Application Development）、MDA(Model-Driven Architecture)など、コードを書かずにアプリケーションを自動生成するコードジェネレータツールってのが手を変え品を変え登場しているよ。
- 麻里：コードの自動生成は、システム開発の長年の夢なのね。でも、なかなか普及していない……。
- 先輩：ノンコード開発には課題が2つあるんだ。1つは、コードを生成する必要があるので、本来プログラマの裁量に任せられるところまで記述しなければならないこと。もう1つは、どうしても通り一遍のアプリしかできないので、UI/UXに優れたアプリケーションを作るためには生成されたコードに手を入れざるを得ないこと。
- 麻里：コードに手を入れると、ツールの定義内容との乖離が生じますね。
- 先輩：うん、だから最近では、こうしたノンコード開発を見直して、一部分はソースコードを書く「ローコード開発」という手法も注目されているんだ。
- 麻里：無農薬農法という理想が掛け声ほど簡単じゃないから、現実的な低農薬農法を採用するって感じですね。
- 先輩：うん……まぁ、そうかな? で、もう1つの解決方法が発想を転換してCADに徹するというもの。なまじコードまで欲張るから難しい課題に直面するわけなので、設計書を作成することをゴールにすると割り切るんだ。
- 麻里：な～るほど、設計作業を効率化するだけでも、生産性向上やメンテナンス性が相当改善できますね!
- 先輩：IT業界は、ついコード生成までできそうだなんて思えるからCADが登場しなかったとも言えるね。
- 麻里：ようやく腹落ちしました。でも、先輩。サザエのしっぽ(肝)って、餌の海藻を蓄えた部分なので、ミネラルやタウリンが多く含まれていて美容に良いんですよ。だから私はいつもしっぽまで食べます。
- 先輩：(まじまじ)ふ～ん……。
- 麻里：なによ、そのまなざしは。今、食べても効果ないって思ったでしょう。本当に失礼ね!
令和時代のシステム開発のあり方はどう変化しているか
15年前と現在を比べた場合、システム開発のあり方はそれなりに変化しており、勢い、システム開発で重要な設計書の書き方も、そうした変化に対応して工夫が凝らされています。
①アジャイル開発の比重が大きくなっている
⇒ウォーターフォールだけでなく、アジャイル開発における設計書のあり方を論じる
②カスタマイズ案件の割合が増えている
⇒イチからの新規開発だけでなく、カスタマイズ開発における設計書の書き方を統一する
③運用・保守の比重が大きくなっている
⇒新規開発のための設計書だけでなく、運用・保守コストを下げるための設計書を意識する
④オフショア/ニアショア開発の割合が増えている
⇒ラボ型、請負型において、阿吽の呼吸を期待しない設計書の書き方を定義する
これらのポイントについて、いくつかの統計データを見ながら現状を認識していきましょう。
(1) ウォーターフォール開発 Vs. アジャイル開発
2018年5月にガートナージャパンが発表した日本国内におけるアプリケーション開発手法の調査結果「各開発手法に関する現在および今後の方針(図1)」では、アプリケーション開発手法を「ウォーターフォール型」「反復型」「アジャイル型」の3つに分けて調査しています。ウォーターフォールの各工程において、イテレーション(反復)により確認＆修正を取り入れるウォーターフォールとアジャイルの混合スタイルを「反復型」としてアジャイルと別に分類しているのです。
この調査結果では、現在ウォーターフォール型を採用中という割合が43% (継続／拡大28%、縮小15%) 、アジャイル型は17% (継続／拡大15%、縮小2%)、反復型が16% (継続／拡大15%、縮小1%) となっており、依然としてウォーターフォール型が主流だと分かります。
一方で、現在は未採用だが今後採用する予定という割合は、ウォーターフォール型が2%なのに対してアジャイル型が13%、反復型が9%となっており、アジャイル型や反復型(俗称:なんちゃってアジャイル)が増える傾向にあることが見て取れます。
ちなみに、IT部門が関与しないビジネス部門主導の開発は「採用中：継続／拡大」が9%、「未採用：採用予定あり」が6%となっており、IT部門が保守運用に追われる中で現場部門が直接開発を主導するケースが増えつつある傾向が伺えます。
また、同じ調査でアジャイル型開発に対する今後の方針を従業員規模別に表した「アジャイル型開発手法に関する現在および今後の方針×従業員数規模(図2)」では、従業員数が2000人以上の企業のアジャイル型開発採用中は40%近くで、未採用だが採用予定ありは30%にも達しており、今後アジャイル型開発を取り入れようという意向が伺えます。
ただし、これらの数字が全面的にアジャイル型開発を採用していることを示すわけではありません。大企業では、実施されている開発プロジェクトが多く、その一部でアジャイル型開発を取り入れているというケースでも「採用中」となるので、この値がウォーターフォール型とアジャイル型の割合を示しているわけではないのです。
それでは、実際の割合はどれくらいなのでしょうか。これを示すデータもあります。JUASが調査した「ソフトウェアメトリックス2018年」の図表5-15「開発方法論の使用割合」では、合計欄で見るとウォーターフォールの件数が1060件なのに対し、ウォーターフォール以外(反復型とアジャイル開発)は80件と10分の1にも満たない状況となっています。
(2) カスタム開発 Vs. パッケージカスタマイズ
カスタム(スクラッチ)開発とパッケージ導入の比率はどうでしょうか。この2つに関しては、経済産業研究所の「日本企業のソフトウエア選択と生産性 －カスタムソフトウエア対パッケージソフトウエア－」というレポートがあります。
このレポートの図3「業務別のカスタム・パッケージ比率(p.11)」は、5006社へのアンケート依頼に対し回答があった1126社のデータです。業務別にカスタム開発とパッケージソフトとの割合を調査したもので、数字は社数です。みなさんの想像通り、経理財務や人事管理にはパッケージ(含む主としてパッケージ)が多く採用されていますが、販売管理や生産・サービスではカスタム開発の比重が多いことがわかります。
売上ベースの比率ではもっと格差が生じています。日本と米国のパッケージの売上比率を比較したデータ(同調査の図2「売上比率 日本 アメリカ(p.4)」)を見ると、アメリカでは30年以上前にカスタムソフト(スクラッチ開発)からパッケージソフトへ移行しており、売上におけるパッケージの割合は7割前後を占めています。一方、日本では相変わらずカスタムソフトが根強く、パッケージの割合は1割しかありません。調査が20年近く前なので、この後にパッケージの比率は少し増えたようにも感じていますが、それほど大きな変化はないように思います。
(3) オフショア開発 Vs. 国内(含むニアショア)開発
オフショア開発の状況はどうでしょうか。少し古いですが、2007年に総務省が実施したオフショア実態に関する調査レポート「オフショアリングの進展とその影響に関する調査研究報告書」で状況が報告されています。これは、4032社にアンケートを依頼して514社から有効回答を得たものです。p.4にある「ソフトウェア開発業務を行っている企業におけるオフショア開発の実施状況」のグラフによると、元請および開発元企業の48.2%が既にオフショア開発を実施しているとの回答があります。
おわりに
今回は、システム開発で作成されるドキュメントの全体像を把握しました。また、令和時代のシステム開発の特徴を知る上で、アジャイル開発やパッケージカスタマイズ、オフショア開発の状況について、いくつかのデータをもとに実態を確認しました。
次回からは、いよいよこれらの状況を踏まえた上で、「令和時代にどのような設計書を書くべきか」について、具体的に解説していきます。
