設計書の書き方講座

OBDZ設計の勘所(Vol.30)

  • 2017.08.16
  • 株式会社システムインテグレータ
OBDZ設計の勘所(Vol.30)

本連載は、設計書ジェネレータ「SI Object Browser Designer(以下、OBDZ)」を使ってソフトウェアの設計書(仕様書、基本設計書、詳細設計書)を作る講座です。今回は「OBDZの勘所」として、設計を行うにあたり、つまずきやすい箇所とその対策についてご紹介します。

OBDZにご興味があればぜひ評価版をお申込みください。以下のURLよりお申込みいただくと、製品のダウンロードURLおよびログインに必要なアカウントを取得いただけます。

https://www.sint.co.jp/products/obdz/trial/trial.html

ロジックとソースコードは切り離して考える
(必ずしも関数と1:1でなくてよい)

OBDZのロジック画面はビジネスロジック設計するための機能ですが、導入ユーザーでは、ソースコードの関数(メソッド)とロジックを1:1で作成するユーザー様が多いようです。特に設計チーム・製造チームに分かれずに一貫でシステム開発を実施する(できる)企業様では、設計者は最終的に落ちるソースコードに逆算できてしまいますので、当手法を取られるケースが多いように見受けられます。

プログラマ向けの詳細な設計書がつくれるメリットがありますが、反面「画面遷移などの簡単な処理を定義にもロジックをつくらなければならない」「Oracleのストアドパッケージになるものをサブファンクション単位でロジックを作らなければならない」というデメリットが生じてしまいます。

データベース設計の世界でも論理モデル→物理モデルと段階的に考え、論理モデルのエンティティは物理テーブルと1:1でなくてもよいという設計文化があります。もし、「ロジックの設計が大変」と感じるようでしたら、「ソースコードとは切り離して考え、ユーザー目線で(ブラックボックスレベルで)ロジックを考える」「画面遷移はイベントの処理内容に書いてしまう」ことを検討してほしいと思います。

lights.pngOBDZのロジック設計項目について

第17回でもご紹介していますが、OBDZのロジック画面での入力項目はパラメータ、アクションするテーブル等のインタフェースレベルのみの画面で済ますようにしにし、アルゴリズムや変数など細かな入力は不要となっています。言い換えれば、「ロジックのI/O(入出力の仕様)は設計者が定義するが、その実現方法(アルゴリズム)はプログラマの裁量に任せる」という考えで作られています。そのような理由からも、OBDZではユーザー目線の設計方式の方が運用しやすくなっています。


既存設計書からの「断捨離」を
(必ずしも全ての情報を移行する必要はない)

OBDZ導入の際は、これまでのExcel/Wordの設計書と同じ書式で、同じ情報を格納したまま移行したいと言われるユーザー様がほとんどです。これまで慣れ切った書式のほうがスムーズに移行できますので、当然の要求だとは思いますが、そうなるとどうしてもOBDZの書式とギャップが生じてしまい、入れきれない情報が出てしまうのも事実です。OBDZでは補足説明(フリー入力機能)を用意しておりますので、移標準入力画面で移せない情報はこちらに入力しておく運用ができますが、補足機能はExcel入力画面の形式となっていますので、多用してしまうとOBDZの「標準化(属人化の廃止)」などの導入メリットが出せず、本末転倒となってしまいます。そこでOBDZ導入時は、

・過剰な記載はないか(例えば、イベント定義と補足説明で同じことを書いていないか)

・業務フローやコーディング規約など案件共通で良い情報を個々の画面設計書に記載していないか?

・本当に設計書に明記する必要があるのか?(変数名などプログラマの裁量でもよい情報はないか?)

などの過剰な記載がないかを見直していただいた上、不要な情報は思い切って捨てる(OBDZ上では記載しない)ことも考えてほしいと思います。

いかがでしたでしょうか。今回は筆者が導入ユーザー様の声をお伺いする中で、感じたことを書いてみました。これまでの設計文化を変える必要も出てきますので、容易なことではないと思いますが、OBDZで導入効果を出すためには重要なポイントだと思いますので、ぜひ導入時に一度、見直していただきたいと思います。

株式会社システムインテグレータ Object Browser事業本部 後迫

SI Object Browser Designer カタログ

SI Object Browser Designer カタログ