1試合で6キロ痩せるんだとか…。
システム設計書に関するセミナーへ参加してきました
最近は、お師匠様の薦めもありまして、月に1回ほどのペースでセミナーに参加しております。本日のブログもその報告になります。
今回はこちらのセミナーに参加しました。
↓↓↓
https://products.sint.co.jp/obdz/seminar/sn20191003
システム設計書の書き方改革セミナー
～設計書の書き方の基本、ツールを使った設計の生産性向上～
株式会社システムインテグレータ様のセミナーは、7月に続いて２回目の受講になります。前回の内容が非常に充実していたので、今回も楽しみにしていました。
7月のセミナーの内容はこちら⇒https://futurebase.co.jp/1955/
セッション1 令和時代のシステム設計書の書き方
いつも通り、各セッション毎に内容をまとめたいと思います。
１人目は、 株式会社システムインテグレータ 代表取締役社長 梅田 弘之 氏
実は梅田さんは前回も講義されていて、今回は２回目です。
内容自体は前回と被るところもあったのですが、前半部分で挙手アンケート制の問題があってそれが面白かった。普段、同業他社の事情を知る機会は中々無いために、周りをキョロキョロしながら参加していました。
そちらのアンケートをいくつかまとめたいと思います。
質問：システム開発において設計とプログラミングの比重はどちらが大きい？
- A.設計
- B.プログラミング
- C.ほぼ同じ
結局やっぱりプログラミング！と、最初は思ったのですが、自分の場合はアジャイル開発が多く、お客様の話をしながら、ああした方がこうした方がと仕様を考えている時間は設計の時間に入ると考えて「C」に手を挙げました。
会場の結果は
- A.2～3割程度
- B.１割程度
- C.4～5割程度
といった感じでした。
梅田さんの調べでは、ウォーターフォールの場合でも、「C.ほぼ同じ」工数というところが多かったそうです。プログラミングの比重は確かに大きいのですが、要件定義・基本設計・詳細設計と細かく段取りを踏めば設計も同程度比重の重いものになるのでは？との事。今回のセミナーの重要性を強調されていました。
もう一つ。
質問：設計の効率化、設計品質強化を行うために必要なことは？
- A.設計スキルを教育する
- B.設計の標準化を進める
- C.設計ツールを導入する
これは悩みました。正直どれも大切かとは思うのですが、スキルを教育するのも、設計ツールを導入するのも、結局はBの標準化が目的ではないのか。と、Bの包括性を考慮して「B」に手を挙げました。
会場の結果は、
- A.2割程度
- B.5割程度
- C.1割程度
といった感じ。さてさて答えは。
梅田さん曰く、実はこれはちょっとイジワル問題。答えは全部大切ですとの事（笑）。
そうですよね。
ただし、多くの会社ではアンケート通り、「C」の設計ツールを軽視している会社が多いとの事。例えば、昔はトンカチで打ってた釘も、今はDIYの現場でも、釘打ち機を使用できます。作業効率が上がるのは勿論、技術的に未熟でも簡単にできるため、技術の画一化や品質も向上する事が狙えます。
私も、前職で工具を扱う機会が多かったのですが、「道具が９割、扱える技術が１割」と言われていました。使える道具を見極めていくことが大事なようですね。
セッション2 AIとツールでシステム設計書を標準化する Object Browser デザイナー
2人目は、 株式会社システムインテグレータ ObjectBrowser事業部 後迫 潤 氏
タイトル通りここからは、製品の営業が多分に入ります。無料のセミナーなのでそこはご愛敬ですね。
「SI Object Browser Designer」の説明が半分ほどでしたので、こちらは前回のブログのセッション3を参考にしてください。（https://futurebase.co.jp/1955/）
後半はデザイナーのオプションサービス「AISIA-DR」の紹介でした。
「AISIA-DR」は簡単に言うとエクセルなどで制作したシステムのGUI画面を、画像認識でデータ化し、設計書へとリバース作成するものです。こちらのサイトで動作を試してみて下さい。https://aisia-dr.sint.co.jp/
（言葉で説明するの難しいな～と頭を傾げていたら、AISIAのデモサイトのご案内が来ました。さすがの営業力だ。）
自分が業務システムを開発する時は、業務フローと機能詳細を固めたら、DBの設計から入っていき、プログラムしていくので全体のGUI作成は最後になります。ただし、アジャイル開発が主になってくるので各段階で大きく修正が入る事も多々あります。GUIが固まってからの修正も、もちろん多く。むしろ、ある程度大枠のシステムが固まってからの修正が主です。
そうした際に、自分だけでなく他の開発者と設計情報を共有したい場合があるかもしれません。この段階で一から設計書を作るのは（あるいは元ある設計書を修正するのは）かなり大変です。そういった際に、このAISIAは使えるのかなとも思いました。
まあ、それなりにお値段は掛かりますので、弊社では早急には必要性は無いですが。チームやプロジェクトが大きくなってきた場合は、「Object Browser Designer」と同様に、検討の余地があるかもしれません。
セッション3 データモデリング”Object Browser ER”で設計生産性を向上
3人目は、 株式会社システムインテグレータ ObjectBrowser事業部 横島 広信 氏
こちらも、主にソフトの紹介です。
「Object Browser ER」はER図の作成やリバース・フォワードエンジニアリングが出来る、ERD設計ソフトです。弊社ではER図の作成は現在、Toad Data Modelerを主に用いております。Object Browser ERと、機能やコスト面で比べると特に不利益も無く。現在のままで良い模様です。（というか、前身の「case studio 2」が、windows1903から使えなくなったため、ERソフトを替えたばっかりなので。当分はこのままの模様。）
Object Browser ERの概要はこちらを参考にして下さい。https://products.sint.co.jp/ober
さて、このセッションで気になったのは、最初の方で行われたこんな質問でした。
「この中でER図を見たことがある方は？」
手を挙げた人は、8割程度。
次にこんな質問。
「この中でER図を作成したことがある方は？」
これが何と4割程だったのです。
SEやプログラマが「設計書」をテーマにしたセミナーで、ER図を描いたことがある人が、半分にも満たないことに驚きました。前項で先述した通り、自分の場合は、まずデータモデル部分から設計していきます。そのためER図は必須なのです。
戻ってきてお師匠様にこの事を話すと、「プロジェクトが大規模であれば大規模であるほど、業務は細分化されていく。そのため、設計段階でも、画面設計だけする人や仕様設計だけをする人もいれば、ER図を作るだけの人もいる。」との事でした。
総括
同業の人でも、いろいろな人がいることを再認識しました。
自分の業務に生かせる部分や、改善が必要な部分など、気づくことは多くあります。定期的に外の世界を見るのは良いことですね。
また、講演などに参加した際にはご報告いたします。
ちなみに、梅田さんも「ER図は作った方が良いですよ。」と、おっしゃってました。
おわりに
ラグビーワールドカップが盛り上がってますね。
自分はスポーツ観戦はバスケットボールが好きです。理由は目が離せないぐらいテンポが速いから。ラグビーも同じくらいボールが止まらず、展開が早いので、すっかりハマってしまいました。
生まれ変わったら、フォワード選手ぐらいのガタイになりたいです。
それでは。
聖。