【この記事を読むのに必要な時間は約 6 分です】
データデース開発支援ツールとして根強い人気を誇る Object Browser の開発元である株式会社システムインテグレータ（SI）社から、設計工程を支援するツール Object Browser Designer が6月に発売されました。SI社の方に製品を紹介いただき、評価版も使用してみたのですが、功罪ともにあるツールだという印象を持ちました。
システム開発においては、要件定義から詳細設計までExcelやWordを用いてフォーマットを策定、記述していくスタイルが一般的です。これは私がIT業界に入った約10年前より不変であり、SI社が指摘する通り「ワープロ作業」では「設計効率が悪い」、「修正箇所が複数にわたり不整合が発生する」、「設計書の記述ルールや フォーマットを統一できない」といった問題が付いて回ります。
「ワープロ作業」という嘲るような表現が示すように、SIer が多くの時間をドキュメント整備に費やしてきた現実は全く滑稽としかいえない悲惨なものでした。Object Browser Designer では設計作業をシステム化することで設計工程の課題を解決し設計工数を従来よりも 3 割削減できるとしています。
Object Browser Designer (OBDZ) でできること
- 設計書のテンプレート化
一度作成した設計書セットは、「ドメイン機能」によりテンプレート化
類似する特性をもつシステムの設計には、既存ドメインを使用する - 設計書間の整合性確保
開発中に仕様変更が発生した場合の修正漏れを防ぐ - 設計書の自動生成
OBDZ にて設計した画面・帳票レイアウト、ロジック、テーブル定義を Excel 設計書へ出力 - バージョン管理
履歴の管理、最新ドキュメントを明確にする
チェックイン/アウトによりロックし、編集の競合を防ぐ - クラウド上でデータの一元管理
AWS を利用しクラウド上のデータベースにデータを保存
オンプレミスの場合は自前の PostgreSQL が必要 - データベース連携
同社の Object Browser ER と連携しデータベースからテーブル定義をインポート
テーブル定義から使用するデータを選択して関連付け
次に具体的な機能を見ていきます。Object Browser Designer では、Visual Studio ライクな画面レイアウト機能を備えており、ドラッグ & ドロップによりコントロールを配置、プロパティエディタで属性値を設定します。
ここで変更した項目はコントロール、イベント定義など他の設計と相互に連携しており、横断的な設計が可能となっています。
ボタンやテキストボックスなどの各画面要素には、イベントを関連付けることができます。
以下では、イベント発火から呼び出されるロジックを定義します。
画面 – イベント – ロジックの関連をモジュール関連図により可視化し、アプリケーションを鳥瞰します。
画面コントロールとロジックの紐付けができ、自動の可視化機能は便利だと感じました。別製品になりますが Object Browser ER を使用することでデータベースとも連携できるようになります。
ただし、現状の仕様では画面、帳票ありきの設計しかできません。OBDZ がターゲットとしているのは明らかに業務向けアプリケーション開発であるため、バッチ処理への対応を急ぐべきです。バッチの実行スケジュールも可視化できれば良いと思います。
Excel 設計書の出力
レポート出力機能により、Excel 形式で設計書を作成することができます。以下はOBDZ により作成された Excel を印刷表示したものです。
今後予定されている機能追加
- 画面定義から画面モックアップの自動生成
- テスト仕様書の自動生成
Object Browser Designer の功罪
OBDZ は発売間もないこともあって、製品全体のインタフェースや帳票のレイアウト機能、ロジック定義に関する機能は未熟であり、今後の改善によって使い勝手や機能は向上していくでしょう。また実装が予定されているモックを自動で作成する機能にニーズがあることは容易に想像できます。
現時点でも製品の方向性は明らかで、開発経験者はここまで見ただけで実際の開発イメージが浮かぶのではないでしょうか。社内ドキュメントを統一化し、あの煩雑なドキュメント整備の労苦が少しでも軽くなるのであれば、 Object Browser Designer の導入は検討する価値があるといえますが、全ての開発現場で有効なツールとはなり得ません。
導入に向いているケース
営業の方から伺った話では、SI 社の製品 (Object Browser / ER / PM) を利用しているのは社員 100人以上の規模のユーザ系企業が多いとのことです。作業従事者が増え十分な意思疎通が出来なくなってきた場合に、作業効率化のためあらゆるテンプレート化を推進することは自然な流れと言えます。
ユーザ系の企業が OSS のように頻繁にトレンドが変わりサポートが受けられない製品よりも、同じ製品を長い期間使用できるパッケージ製品を選択する事情にも通じています。長いスパンでの企業活動が明確であり、テンプレート化が作業効率の向上に直結する企業にとって、OBDZ が好ましい製品であることは疑いようがありません。
導入に不向きなケース
テンプレートを用いた作業効率化は、作業が単純化する反面自由度を損ないます。今日のシステム開発では市場環境変化の早まりに伴い、開発期間の短縮・並行開発が求められるケースが少なくありません。アジャイル開発手法も一般化し、ウォーターフォールモデルのように設計工程の成果物を確定させてから実装に入る案件は確実に減少しています。BPMN や UML 、概念データモデルなど設計書に記述する内容も変わりつつある昨今、従来の開発手法を踏襲している OBDZ がどこまで利用価値を上げられるのかは疑問です。
まとめ
OBDZ が業務効率化を推進したい経営層から歓迎されることは想像に難くありません。しかし、より柔軟な開発スタイルの導入機会を奪い開発環境が硬直的になるあまり、企業活動のツールに過ぎないはずのシステムが逆に活動の制約となり、システム開発環境刷新の機会を失うのではないかといった懸念もあります。
OBDZ のようなテンプレート化ツールの導入は使い方によって開発の効率化あるいは硬直化を招きます。どちらも同じ評価基準からは問題が見えにくいものです。また、導入範囲を限定したスモールスタートでは効果が表れにくい点も評価を難しくします。システム部門の方針と経営の方針、メリットとデメリットを鑑みて、テンプレート化が必要な状況であるかを判断する必要があります。