概念モデルの書き方

概念モデルから論理モデルを作成するときに、ER図（概念モデル）を記載し、論理モデルを作ることでシステム構築ができるだろうと思っていた。

ただ、ER図や論理もどれも正解はなく、それぞれの業務とシステムの特性を考えながら選択するというのがいい方法らしい。

よく知られている論理モデル（データモデルといったほうが良いか）は以下の４つのようである。

1. リレーショナルモデル
2. ネットワークデータモデル
3. ハイアラキカルデータモデル（階層型）
4. オブジェクト指向データモデル

それぞれ、結果としては表している意味は同じであるが、表現が異なるだけであり、

それぞれの時代の背景などもあるようである。

ホスト系を中心に今まで見てきたので、論理モデルならあれか、遠い浮かぶのだが、オブジェクト指向に沿った開発だと、先々の開発工程や扱うツールに沿った形でモデルを表現したほうが良いのかとも思っている。

もう少し、データモデルに関して見たり、実際に実装してみる必要がありそう。

※概念データモデル・・・ビジネスの観点で必要な情報の体型をデータモデルとして表現

※論理データモデル・・・特定のデータベースに依存しないデータモデル。業務における意味を反映した項目名や項目に関する説明などを定義。

リレーショナルデータベース入門―データモデル・SQL・管理システム (Information&Computing)

posted with amazlet at 13.09.02

増永 良文
サイエンス社
売り上げランキング: 48,038

Amazon.co.jpで詳細を見る

 

４つの軸でみる

業務定義や要望、現状把握する際に様々なわからない言葉が出てくる。

また、知っている用語でも怪しいな？と思う言葉もある。

会議中にも頭をフル回転させて考えないといけない必要もある。

同期と話していてこれはとおもったのは、

「人」「物」「金」「情報」の視点を持って見ること。

経営やBSCなどで出てくるが、やはりこの視点は必要。

例えば、ものが直送した場合、物の動きとお金の動き、情報の動きが

ばらばらになる可能性が高い。

これを１つずつ腹に落として整理することで現状も把握可能であり、

要望も整理できるのではないかと思い始めている。

要求の獲得

BABOKやシステムアナリスト、超上流など様々な要求定義に関連する知見が増えてきている。

どれも概略として書かれているが、実践的なことはやってみないと、わからないなというのが最近の所感。

確かに、記載されていることは重要なプロセスと思うのだが、時間的制約と能力的な制約。及び、前提条件や現状にあるドキュメント量によって、やるべきことは異なる。

例えば、現状システムや業務を表すものがない場合は、それを補完する資料から作成する必要があるし、ある場合でも、俯瞰する資料がないならば、作成する必要がある。

なぜ、作成するのか。

経験上ではシステム関係者とユーザ及び、経営関係者は、共通の用語・定義で語らせないと行けないからである。それぞれの言語で語られると、意味合いは違うのに、同じ言葉を使ったりしており、後々、「おや？おや？」ともなる。

また、ドキュメントがないと、何について話をすればよいかわからなくなり、それぞれが言いたいことをいって、話が終わるケースもままならない。

ヒアリングであろうとインタビューであろうと、ノープランで望むことはNGであり、現在ある資料の中で、現状とみられることを整理し、課題として捉えられることを想像し、何を聞き出したいかを明確にして望まないと、ユーザは何を話してよいのかわからなくなる。また、要求を引き出すにしても、TVなどのインタビューと同様で、引き出し手が思っていたとおりに展開が進むことはそうない。議論がブレないように、何を軸に話を進めていくのかは事前に準備が必要である。

相手に合わせて資料をつくる

長い時間使われ続けているシステムほど、システムドキュメントや

業務運用に関わる、業務フローやデータフローが残っていない。

または、ドキュメントはあるが、構築時点のもので、メンテナンスがされていない

場合が多い。

そのような場合でも、システムの再構築やBPRを行う場合、現行調査が必要となってくる。理由は、新業務を入れる場合でも現行業務を変える場合でも、既存で稼働している仕組みと結合させる必要がある場合が多く、影響調査が必要だからである。

今では、リバースエンジニアリングツールも多く出ていると思うのだが、まだまだ人海戦術でソースやある資料をかき集めてドキュメントを作るのが主流かなと思われる。

どんなドキュメントを作るかというのはITproや書籍に参考例は書いてあるので、

そこに任せておくとして、私なりに気をつけている事があります。

・クライアントで利用されている文言、定義で記述する

・作成した資料を見たり、使う相手を考えて作ること

　（エンドユーザなのか？システム部門なのか？

　　一般社員なのか、役職者なのか？）

　　→　それによって、システムより業務よりのドキュメントに変える必要があるし、　　　　まとめるテーマを変える必要がある

どちらも当たり前のことだが、意識して資料を作らないと一般用語やITの用語になってしまう。クライアント企業や人が日頃から使っている言葉で表さないと、言いたいことは同じなのに、資料が違うとか本質とは関係のない議論で終始してしまう。また、自分たちのことを考えていないな・・・と思われてしまうこともあります。

簡単にできることを当たり前にやることから始めるのが結構難しいです。

現行システム調査

ここ最近、とある企業の現行システムの整理をしている。整理といっても、アーキテクチャがこうで・・・サーバとサーバがこうで・・・というわけではありません。

JOBの種類や、DBの関連性(CRUD)、帳票の数など、素情報を集める作業です。

かつ、作業を進めながら、現行システムがどうやって動いているのかを把握していくという作業。

SIerだとよくある作業だよな・・・。と。

この作業フェーズですが、維持・保守されているシステムがどれだけしっかりメンテナンスされているか・・によって、調査の難易度が変化します。

メンテナンスはシステムだけを表していません。

システムを作る・維持するにあたっての仕様書、要件書、ユーザマニュアルなど、すべてをひっくるめてのものです。

個人的に、あるとやりやすい、やりにくいと感じているのは以下のとおり。

＜やりやすい＞

・ユーザーマニュアル・・・どうやって扱っているかを時系列で終えるので頭にはいる。

・業務フロー・・・要件定義していればあるはず。

・データフロー・・・データライフサイクル見えます。（特に業務メッシュで資料が揃っていると最高）

＜やりにくい＞

・コーディングと仕様が乖離している　・・・コードから業務や言葉を推測するのは結構ハード

・ノードキュメント・・・業務で扱われている項目が一切わからず（泣）

市場製品として、現行システム分析ツール（GTOne)とか出ていますが、一般的には人力で解読するのがまだ主力なのかと思っています。（若干、分析ツールは高い？）

システムが肥大化すればするほど、年季が経てば経つほど、読み解くのが苦しくなってきます。そうならないために、システムとそれを支えるものをどう定義していくのか。

なんでも困ったら外部に委託・・の前に、自分たちで対応できることを考えてほしいなと思う次第でした。（多忙で片付けず・・・）

作業の状態を説明できること

何気ないことだが、自分が与えられているタスクに対する計画の予実、課題を端的に説明できるというのは、忘れられがちだが重要である。

特に、相手の所有時間が分単位（１−１０分程度）しか取れないとき、ダラダラと話を展開されると、本題へもたどり着かず、ストレスだけをためてしまい、時間が来てしまう。

そのため、いかに説明できるかが、重要であると見ている。

QCDの視点で見れば、

Q：作業の成果物に対する、完成度について、質問・課題を提示

C：お金に関わる話しなら説明

D：計画に対する差異（大きければ、報告）

というのを先にまとめておけば楽に説明可能かと。

突っ込んだ質問をしている人もいるだろうが、上記の視点で、根拠を持って、対応すれば、多少間違っていても話はできると思われる。

毎朝の電車の中でも、当日の朝一でも良いので、毎日振り返っていると・・・説明は多少簡単にできるようになるはずである。

今の立ち位置を見失わずに進むのがコツだろうと感じている。

現状システム情報を読み解くのに綺麗な資料は必要か？

現行システムを刷新し、新規要件を追加、サーバを入れ替え、 プログラムも作り変え・・・言語も変え・・・ と言った要件というのはSIerにいると、数年に一度くらいのペースで 実施する案件である。

さて、このようなケースの場合、「現行システムの調査」を どのように片付けるか・・というタスクがあります。
一般的に、

• 現行システム調査
• 現行業務調査

　→　現行の流れを把握

• 新システム定義
• 新業務定義

という、いわゆる、物理・論理分析、業務調査を行う。

さて、では現行システム分析をどうやって実施するか
現行システムに関する資料が開発時から保守運用時までソースとドキュメント間で連携が取られおり、勝つ、相応のドキュメントがある場合、影響範囲などは、既存の資料から終えるである。
一方、ドキュメントが整備されていない場合、どうするか・・・ここ数日の経験より、私はこう考えます。

• 現行業務を知るには　→　ヒアリングなど。Slerとしては、まとめはするが、自分では定義がしがたいので、ユーザにまとめていただく。
• 現行システム調査・分析　→　まずは作成されている資料を元に、手書きで修正

資料がない場合は、都度、ユーザと議論し、どこまで作成するか定義する システム分析を綺麗に実施したいものであるが、綺麗に書くというのがゴールではない。

要は、作成した資料を元に、ユーザ内部で議論をし、次のアクションに結びつく工程へ進める資料ならば形はこだわらないのである。

電子で書いておかないとあとから修正するんでは？

という意見もあると想います。私もそう考えていました。

が、よくよく考えてみると、どれだけ現行システムを綺麗にまとめても、新システムを作ろ時に、新システムの手意義に沿った資料に焼き直されるんですよね。

よって、いかにスピードよく確実に、現行システムのこと全員で共有可能な資料を作成するか。ここがポイントになりそうです。

明日からも議論を深めて、資料作りです。