参考情報
本連載は、設計書ジェネレータ「SI Object Browser Designer（以下、OBDZ）」を使ってソフトウェアの設計書（仕様書、基本設計書、詳細設計書）を作る講座です。今回はOBDZが向く案件についてご紹介したいと思います。
OBDZが向く案件とは？
さて、今回はズバリ、OBDZが向く（導入効果が高い）案件についてお話しします。前回、前々回でも「ドキュメント体系」のギャップ度合によりOBDZの導入メリットが決まるというお話をしました。今回はもっとざっくりと、わかりやすく「どのような案件に向くのか？」という疑問にお答えしたいと思います。
結論を言いますと、「ウォーターフォール型」「新規」「受託」の案件になります。その理由を以下に解説します。
アジャイル型よりもウォーターフォール型
OBDZでは専用のフレームワーク（設計に特化した入力画面）やバージョン管理、カスタムコントロール機能等の標準化・品質向上に役立つ機能を提供しています。言い換えればこれらは「設計をしっかりさせる」ための機能です。最近ではスピードを重視して、設計書はつくらない（HTMLやVisual Studioでモックアップ作成して顧客と要件を固める等）、または簡易に作る（納品用に後で画面スクリーンショットをはりつける等）運用をされる企業様も増えてきましたが、システムの規模が大きくなるほど設計ミスによる後戻りコストが膨大になることから、「スピード」よりも「品質」のほうが重要になってきます。このように設計をきちんと行ってレビューを通ってから製造に入る、そうしないと後戻りコストが膨大になってしまう案件でOBDZの導入メリットが出せると言えます。語弊があるかもしれませんが、アジャイル型を「スピード重視型」、ウォーターフォール型を「品質重視」と考えれば、OBDZはウォーターフォール型案件に向くと言えるでしょう。
 アジャイル型案件では絶対に使えない？運用の工夫が必要となりますが、アジャイル型案件でOBDZを取り入れることも可能です。例えば、HTMLを作成して顧客とレビューする運用をしているのであれば、OBDZで画面レイアウトだけを入力後、モックアップ出力をすることでも同様の運用が可能です。今回、アジャイル開発でOBDZは向かないと申しましたが、どちらかと言えば機能面より「アジャイル開発の世界において設計専用ツールを利用すること」への現場の反発の方が大きい理由だと思います。この導入障壁を乗り越えてトップダウンで導入した企業様もいらっしゃいますので、アジャイルが主流のベンダー様もぜひ検討いただきたいと思います。（弊社でもアジャイル型開発でOBDZを取り入れています）。 |
既存システムよりも新規システム
既存案件においてはExcelやWordの設計書からOBDZへの移行コストがかかります。OBDZはクロスリファレンス機能をはじめとした、メンテナンスコストを削減する機能も提供しますので、既存システムで利用しても長期的にはコストメリットが出てきますが、新規案件の方が初期の移行コストが不要な分、向いていると言えるでしょう。
派遣よりも受託（自社で実施する案件）
OBDZではリポジトリ（データベース）で設計情報を一元管理することで、過去のノウハウを活用できる点が特徴です。例えば、串刺し検索機能を使えば、過去の類似の案件から設計情報をうまく流用できます。しかし、他社に派遣しての開発となると、セキュリティの観点から過去の設計情報を参照することができないなどの制約が出てしまいます。「ノウハウを貯める」という目的でつかうためには、やはり受託型のような案件でないと難しいでしょう。なお、厳密には「自社の案件で向く」という意味になります。自社パッケージの開発案件であればドメイン機能なども活用できますので、受託案件以上にメリットを出すことが可能です。
| 製品のコンセプトについて OBDZは「IT業界のCAD」というコンセプトで開発したツールです。今回解説した「ウォーターフォール型に向く」等の特徴も、このコンセプトにつながっていると言えるでしょう。 また、もうひとつの大きなコンセプトは「ソースコードジェネレーターと発想を変えて設計に特化する」点です。以下の社内導入事例の紹介ページにて、詳しくご紹介していますのであわせてご覧いただければと思います。 http://www.sint.co.jp/products/obdz/case/si.html |
いかがでしたでしょうか。今回、導入検討されているユーザー様向けに３つの指標をご紹介しましたが、あくまでざっくりとわかりやすく説明するための参考情報になります。「案件」と１口に言っても実際の運用や規模・成果物は企業様によってそれぞれですので 最終的にはぜひ評価版で検証の上、各社様で費用対効果をご判断いただきたいと思います。
