システム設計能力を個人でどうやったら効率的に上げられるのか？
そう言われてみれば経験がない。何が無いってシステム設計能力をどうやったら体系だて、学べば効率が良いのか教えてもらったことがない。そういう本を読んだこともない。ということは考える価値がある課題だろう。
1998年、私が新人研修で学んだ設計技法といえば以下の二つだ。
１． データフローダイアグラム （DFD）の作り方
２． データ中心アプローチ（DOA）
その後、働きだしてから自習でオブジェクト指向、UMLを学習した。しかし、オブジェクト指向やUMLは比較的目新しい考え方であったようで、数百人規模のプロジェクトで使用するには学習のオーバーヘッドが強烈すぎたようだ。最初は分かる人で研修などをしたものの、これじゃあプロジェクトが進まないのでJAVAをつかうのだが手続き指向のプログラムができるフレームワークを作るというアプローチをとった。
この時に設計スキルを上げるのは自分だけではだめでプロジェクト全体で共通認識が持てるような設計手法ではないとだめなのだなと痛感した。
それにしても「システム設計能力」と一言で表すと非常に広範囲な内容が含まれてしまう。
ITスペシャリスト
ハードウェア、ソフトウェア関連の専門技術を活用し、顧客の環境に最適なシステム基盤の設計、構築、活用を実施する。構築したシステム基盤の非機能要件（性能、回復性、可用性など）に責任を持つ。
アプリケーションスペシャリスト
ハードウェア、ソフトウェア関連の専門技術を活用し、顧客の環境に最適なシステム基盤の設計、構築、活用を実施する。構築したシステム基盤の非機能要件（性能、回復性、可用性など）に責任を持つ。
もっと詳しく知りたければ以下のURLを参照されたし。
https://www.ipa.go.jp/jinzai/itss/download_V3_2011.html
私がアプリケーションスペシャリストということもあり、業務システムを作成するアプリケーションスペシャリストの視点で考える。
設計能力を上げる方法だが、大きく分けて二つの体系に分けて考える必要が有る。
ココがポイント
１． 自分が携わるシステムの業界・業務に関する知識
２． システム設計の方法論
目次【本記事の内容】
- 1.自分が携わるシステムの業界・業務に関する能力を個人で上げる方法
- 1-1.その企業が提供しているサービスに申し込む
- 1-2.同業他社が提供しているサービスに申し込む
- 1-3.業界協会、関連省庁のHPを確認する
- 2.システム設計の方法論に関する能力を個人で上げる方法
- 2-1.高度情報処理試験に受かる
- 2-2.新システムに出会ったらモデリングしてみる
- 2-3.考え方の組み合わせに抜け漏れがないか表で考える
- 3.まとめ
自分が携わるシステムの業界・業務に関する能力を個人で上げる方法
システムの設計をしていると顧客企業の担当者が専門にしている分野について話さなければならない。
- コールセンター
- 法人営業
- 企画、マーケティング
- システム部
- コンプライアンス部
- 経営層
- 事務処理部門
等など。
顧客は毎日その仕事に従事しているのだから詳しいのは当然だ。システムエンジニアの我々はその仕事をしていないものの、その分野のシステム構築経験がある。レベルが上がるにつれて、その分野でのシステム構築経験が増えていろいろな事が分かってくる。
顧客企業の担当者は自分の仕事に範囲については詳しいが、その他の全体を分かっているのはシステムエンジニアの方だったりする。だから部署間の調整もレベルが上がってくるとできるようになる。
「別の部署の人はこう言っていますが、こちらの部署ではどうですか？」
そういう問いかけや、時には
「他社さんではどうやっているのですか？」
と聞かれることもある。
この質問に答えることができるようになると顧客との話が円滑になる。内心では他社の真似して御社の競争力は大丈夫なのですか？と聞きたくなるのだが、それは心の奥にしまって
「こんなふうにやっているケースが多いですね」
と答えるのだ。そんな経験値を仕事以外でどうやって自分一人で高めることができるのだろうか？
その企業が提供しているサービスに申し込む
最近のシステムはWebで公開されている事が多い。私は金融関係のシステム構築をしていたのだが、担当になる顧客がすでに提供しているサービスがあれば直ぐにWebから申し込む。
オンライン銀行だったら口座開設の時にどんな約款があるかとか、どんな項目を入力しているとか、サービスを利用開始できるまで何日かかったとかということを記録しておく。
そしてサービスが開始できるようになったら、そのサービスを使ってみる。顧客企業の顧客になってつかう。サイトに説明やFAQが出ている場合もあるので遠慮なく質問してみる。よくわからないことがあればコールセンターにも電話してみよう。
同業他社が提供しているサービスに申し込む
同業他社はどんなサービスを提供しているのか同じように申し込む。（以下同文）
業界協会、関連省庁のHPを確認する
どんな業界でもその業界の協会、関連省庁があるだろう。そのような協会、関連省庁のHPをみると業界の課題や将来の取り組み、法改正の予定などを確認することができる。
そういう情報はシステム改修に影響するのでユーザーもチェックしているしその業界のシステム開発に影響するはずだから一見の価値はある。もしハイレベルエンジニアだったら業界共通のサービスを企画してその市場を独占するとういことができると素敵だ。
システム設計の方法論に関する能力を個人で上げる方法
業界知識ではなくて汎用的なシステム設計の方法論を高めておくことは重要だ。私も経験したが、金融業界のシステムから突然、商社や通信業界のシステムを担当するという事は長いシステムエンジニア生活の中で何度も訪れるだろう。
私も顧客管理システム→証券会社のディーリングシステム→システム間結合システム（EAI）→信託銀行システム→商社システム→通信会社システム→ネット証券システム→食品会社システムとフラフラしている。そんな時に役立つのはシステム設計に関する一般的な方法論だ。
- 要求定義のやり方
- 要件定義のやり方
- 基本設計
- 詳細設計
- 単体テスト設計
- 結合テスト設計
- 総合テスト設計
- 移行設計
- 運用設計
基本設計ぐらいまでをシステム設計能力と考えがちだが、システムをカットオーバーし、顧客企業がつつがなくシステムを運用し、システムによって顧客企業に利益をもたらすのがシステムエンジニアの務めである。基本設計ぐらいまでデキたからと言って油断してはダメだ。一般的な方法論については様々な書籍が出ているので、まずはそういう書籍を一読して欲しい。そのような本に書いてないであろうことを私は書いておこう。
高度情報処理試験に受かる
資格の勉強なんて無意味だという意見もある。確かに資格をとったからといって急に仕事ができるようになるわけではない。あいつはこの資格を持っているからこんな役割でプロジェクトにアサインしようと私は思わない。今までの実績でその人に任せるかどうかを私は判断する。
そんな私でも個人でシステム設計の能力を上げるというなら資格の取得を推薦せざるを得ない。なぜか？そりゃ、情報処理試験に出てくるような簡単な事例を解けないなら、現実世界のもっと複雑なプロジェクトで成功できっこないからだ。情報処理試験に出てくる事例は、典型的な事例、世間のプロジェクトでよく起こる問題を事例として出している。
顧客と話していて、
「ちょっとまってくださいね」
といって5分も考えて答えることなんかデキない。
「だめだ、このSEは」
って顧客に思われるぞ。Webシステムの3秒ルールと同じだ。ポータブルスキルとして高度情報処理試験に出てくるような内容は抑えておけば基礎知識として別の業界のシステムを担当する事になっても役立つだろう。
新システムに出会ったらモデリングしてみる
最近はゼロからシステムを作るということは殆どなくなってしまった。既存システムの改修だったり、リプレースだったり、再構築だったり、パッケージの導入だったり。
新しいシステムに出会った時にはまずモデリングをしてみる。クラス図でもいいしER図でも良い。このシステムにはこんなクラス／Entityがあるだろうな。こんな関連があるだろうな。そういうことを想像しながらモデリングする。
それからシステム解析の作業に取り掛かるのだが、自分が思っていたクラス／Entityを格納するテーブルが見つからないときがある。そういう時は要注意だ。どこかのテーブルに非正規化して持っているとか、設定ファイルに持っているとか、プログラムに直書きしているとか。どこかに潜んでいるはずだ。
有るべき姿にするほうが良いか、今のまま移植するほうが良いのか悩むだろう。でも悩むという事は自分が予めあるべき姿を想定していたから悩めるのだ。悩んで悩みぬいて設計を決める。いまのプロジェクトだけじゃあなくって、将来の保守性のことも考えて決める。どっちが良かったかは後になってみないけどわからないけどな。
考え方の組み合わせに抜け漏れがないか表で考える
例えばすべての要求事項をどのように実現するか？要件定義書にもれなく記載しているか？
「大丈夫です、チェックしました」
と言ってくる人を私は信じません。要求事項を全部一覧にして要件定義書のどの業務機能でどうやって実現しているのか表にしてくださいとお願いします。
上記のところでいうと黄色の製造リードタイム短縮の要求をどうするか検討してないじゃん！という事がわかります。
先程の部署の例で考えよう
表にすればどの部署でヒアリングできていないかがわかります。製造部は需要予測ができたとしてどこまで製造キャパシティがあるのかとか、売上が増えたら事務処理部門は大丈夫なのかといか表に整理すれば気になってきます。
また、組み合わせのパターンが網羅されたかどうかを確認するにも表は効果的。
オンラインショッピングで考えてみよう。
予約、キャンセル、注文済み、配送中、配達済、配達出来ずのようなステータスが考えられます。
全部のステータスの組み合わせをもれなく抽出して業務としてどうするのか顧客と検討しましょう。頭を抱えるような組み合わせが出てきます。
上流工程で作成したこのような表はそのままテストケースとして使用することもできる。上流工程で抜けもれない設計をし、下流工程のテストでも抜けもれなくテスト出来、成果物を改めて作り直す工数を削減できる。UMLでステート図はあるが、こちらのほうが私の好み。
まとめ
設計能力を上げるというのは人類がプロジェクトに取り組んで以来の課題だ。最近のシステムは新技術の採用やインターネットベースのシステムでステークホルダーが多かったり、非機能要件の難易度が高かったりする案件が多い。
技術の進展に追いついて設計の腕を磨くか、技術の進展に置いていかれるのか。己の研鑽で技術の進展をぶち抜いていこうや！
それじゃあ ノシ