設計書をツール化するメリットとは?

 2017.05.09  株式会社システムインテグレータ

コンセプト

本連載は、設計書ジェネレータ「SI Object Browser Designer(以下、OBDZ)」を使ってソフトウェアの設計書(仕様書、基本設計書、詳細設計書)を作るための講座です。
「OBDZを使って設計工程の合理化を図ること」が本連載のゴールですが、そのためには現在の設計工程の実状を知る必要があります。
そこで第1回となる今回では、「現在の設計工程にまつわる問題」、「この製品が開発された背景」についてご説明したいと思います。  

設計書作成にまつわる問題

早速ですが、みなさんは設計書をどのようなツールで作っていますか?
きっと多くの方は「Word」か「Excel」とお答えするのではないでしょうか。

複数の設計者がいる場合は、作成したファイルを企業内のドキュメントサーバーにアップし共有できます。また、VSSやSVNなどのソース管理ソフトと併用することで設計書の変更管理もできます。現在はこの方法で運用されている方も多いのではないでしょうか。確かにこのやり方で設計フェーズが実施できますので、現在の運用方法に問題点を感じない方も多いと思います。

しかし、実はこの運用方法には多くの「無駄」が潜んでいます。
「それは何か?」ということで、ここでは、実際に筆者が経験した過去の失敗例を4点挙げてみたいと思います。

1.設計書間の不整合が発生した

基本設計書、詳細設計書には、「画面レイアウト定義」「項目一覧」「イベント一覧」「ロジック定義」等、複数の種類があり、これらの各情報は関連付けられています。WordやExcelであれば個別にデータを入力する必要があるため、手間になります。入力ミスにより不整合が起きるリスクも高くなります。

2.仕様変更の際に修正漏れがあった

プロジェクトの実施途中で仕様変更が発生した場合は、作成済の基本設計書、詳細設計書の中から影響する箇所を洗い出す必要がありますが、WordやExcelの場合は完全に手作業となるため、修正漏れが起きるリスクが非常に高くなります。

3.過去の設計書の所在がわからない

仕様書、基本設計書、詳細設計書は言うまでもなく、企業の貴重な財産です。しかし、部署ごとにドキュメントサーバーでバラバラに管理されていること、サーバーの容量削減のため、古い設計書から優先されて削除されてしまうなどの理由で、いつのまにか過去の設計ノウハウがなくなってしまうことが多々あります。

4.設計書のフォーマットがバラバラ

筆者は他の部署に異動になった経験がありますが、設計書のフォーマットや記述ルールが従来とまったく異なっており、困惑した経験があります。

新規CTA

皆さんも同じ経験はありませんでしょうか?他にも設計工程での問題を挙げればきりがありませんが、大きく分類すれば「品質・効率・非共有」の3つに分類されます。また、これらの問題はいずれもコストに大きな影響を与えます。設計フェーズの発見が遅れるほど後戻りのコストが大きくなりますので、品質の問題はコストに直結しますし、 あなたが作ったことのある設計書は、過去に類似のシステムを流用して作れたかもしれません。もし一から作っているということであれば2度手間になり、余分なコストが発生していることになります。企業の視点で見れば、設計書の記述ルールや、様式(フォーマット)を会社単位で統一し、個々の設計者に依存しない運用にすることで、効率面、品質面のメリットがあります。しかし、ほとんどの企業では部署や案件単位にバラバラになってしまっているのが実状です。このように、これらの問題は、企業レベルで見れば多くのコストの無駄が潜んでいることが分かります。

[RELATED_POSTS]

設計書の問題はツールにより解決できる

では、これらの問題を解決するためには一体どうすればよいでしょうか?現在のWord/Excelだけを使った運用では解決できません。 Word/Excelは業務フロー、マニュアル、財務諸表など多彩なドキュメントが作成できる万能ツールですが、裏を返せば、設計書作成に特化したツールではないということになります。 解決のためには、設計書を作成するための専用ツールが必要となります。では、そのような専用システムが存在するのか?これまでは実用的なツールはありませんでした。 昔からCASEツールや4GL、コードジェネレータなど設計フェーズを自動化する試みが行われていましたが、 エンジニアに広くは普及されていないのが実状です。

これらの製品は、設計工程からプログラミング工程までをカバーする製品として登場していますが、 そのためには本来、プログラマの裁量に任せられる部分まで設計者が定義しなければならず、設計作業の効率がかえって悪くなることがあります。 また、ソースコードの自動生成では、実用的なアプリケーションをつくるのに限界があります。ベースとして作成後、ソースコードに手を加える前提となりますが、 ソースコード改変内容を設計書にリバースすることができず、設計書とコードの不一致が発生してしまいます。 このような理由により、エンジニアに普及していないのが実状です。

では、私たちはWordやExcelを使って設計を続けるしかないでしょうか? いえいえ、そんなことはありません!
  新たな解決策として当社が2013年6月にリリースした製品がOBDZです!

OBDZは「実用的な設計書を作成するシステム」をコンセプトに開発された製品です。 OBDZでは最終的に仕様書や基本設計書、詳細設計書を作成しますが、ソースコードは作成しません。 これは、設計に必要な最低限の入力のみにとどめること、また2度手間を防止する機能などの設計書専用機能のみにすることで、実用的な設計書作成ツールにするためです。 もちろんツールですので、製品の使い方やテクニックを覚える必要はありますが、使いこなすことで、設計コストを大幅に改善することが可能となっています。そのための操作方法については、これからの連載で詳しくご紹介していきたいと思いますが、第1回ではOBDZの特長をご紹介したいと思います。

設計書作成ツール「OBDZ」の導入メリット

設計データの統合管理

設計書作成ツール「OBDZ」では、設計書の作成に必要な画面レイアウト、コントロール項目、イベント、ロジック、テーブルとのマッピング情報などをクラウド上のデータベースに統合的に管理します。 クラウド上のデータベースを使用することにより、場所を選ばず設計情報を参照、編集できるだけでなく、会社の全プロジェクトの設計データからの串刺し検索や、過去バージョンの設計出力が可能となります。 また、過去の案件で作成した仕様書や基本設計書、詳細設計書セットを流用できることにより、自社パッケージのカスタマイズ案件などにも活用できます。

course1img01.png

設計品質・効率の向上

設計データの種類は画面レイアウト定義、コントロール定義、イベント定義など複数がありますが、OBDZでは、画面レイアウト定義はビジュアル形式、 コントロール定義はグリッド形式など、最適なインタフェースが用意されています。 また、関連するデータも自動で作成されます。例えば、画面レイ アウトを作成すれば、コントロール定義情報も自動で作成され、さらにイベント情報を入力すれば、モジュール関連図(I/O関連図)が自動で作成されるようになっています。 また、テーブル設計情報についてはデータベース設計ツール「SI Object Browser ER」のER図データを自動で取り込むことができます。 これらの関連データ自動生成機能により入力の2度手間を防止し、効率化・品質向上を図ることができます。

また、OBDZでは、設計データの変更内容は自動で記録され、変更バージョンごとの比較も可能ですので「誰が、いつ、何を変更したのか」をいつでも確認できます。 定期的に他の基本設計書、詳細設計書と誤って修正されていないか、変更内容に間違いがないかなどを確認にすることにより品質の向上に役立てることができます。 また、更新日付などの情報も自動で記録されますので、更新日の変更忘れなどのありがちなミスも防止できます。

設計書の標準化

OBDZを導入することにより、標準化の促進に役立てることもできます。例えば、記述ルールです。画面レイアウト定義上に入力データの記述ルールを決める手法があり、 《数値のみ、6桁でゼロサプレスあり》なら「ZZZZZ6」と表示するなどいったルールを定めることができます。 これにより、画面レイアウト上で視覚的にデータの形式を確認できます。OBDZでは、この書式ルールをマスタで持っており、自動で表示されます。

これらの特徴により設計工程にまつわる問題を解消し、トータルコストに大きく削減することが最大のメリットといえるでしょう。

course1img02.png

 次回からは具体的にOBDZ上で基本設計書、詳細設計書を作る手順をご紹介していきます。ぜひOBDZを使いこなして設計工程を合理化しましょう!

新規CTA

RECENT POST「設計書の書き方講座」の最新記事


この記事が気に入ったらいいねしよう!
ブログ購読のお申込み

RANKING人気資料ランキング

RANKING人気記事ランキング

RECENT POST 最新記事

ITだけCAD使ってない不思議