会社の関係上、参画するプロジェクトはデータ中心設計で行うというものが多いのですが、データ中心で行うといっていながら実際にはプロセス中心で設計を行っているのではないかと感じることがよくあります。
エンティティ関連図を作成すればデータ中心設計だと思われているのではないでしょうか？
データを中心に据えて設計を進めていくことが本当のデータ中心設計だと思いますが、実際にはデータのあるべき構造を導き出す方 . . . 本文を読む
これまで、いろんなプロジェクトに携わってきましたが、途中から参加することも多く、前任者がすでにデータモデルを作っていて、それを見直してほしいという仕事もありました。
前任者の仕事の進め方としては、以下の方法で進めていたようです。
①業務チームによるエンティティとリレーションの定義業務チームでユーザの要件を整理し、要件を満足させるために必要なデータを抽出しエンティティの定義及びエンティティ間 . . . 本文を読む
全社のデータモデルを作成することにより、感覚的には保守工数を削減することができるだろうと思います。
しかし、全社のデータモデルを作成するためのコストと保守で削減できるコストを比較してどちらが大きいのかによって、全社データモデルを構築すべきかどうか判断が変わってきます。
もしも、保守で削減できるコストがそれほど多くないのであれば、全社データモデルは必要ないかもしれないし、莫大なコストの削減が可能 . . . 本文を読む
全社のデータモデルを構築するということで言えば、実際にはデータだけではなく、プロセスも全社的に管理する必要があります。
データの意味や目的を把握するためには、そのデータがどのように利用されるのかをきちんと把握した上で整理していく必要があるからです。
しかしながら、全社のプロセスを整理するということ一つをとっても、非常に難しいといえます。
企業全体のビジネスフロー図を以前作成したことがあります . . . 本文を読む
「プログラムでカバーする・・・」というのは、データベースが多少おかしくても、プログラムでがんばればなんとかなるということです。
データベースは、多少ヘンな設計・実装をしてもプログラムでカバーすれば動くものは作れます。
結果、データベース設計にそんなに重きがおかれないという側面があるのではないでしょうか？
ネットワークであれば、下手な設計を行うとそもそもつながりませんので影響は甚大です。
デ . . . 本文を読む
Xupperの開発手法では、ビジネスフロー図とビジネス要求定義書で業務の５Ｗ２Ｈを表現しましょうということを言っています。
ビジネスフロー図を記述し、ビジネスフロー図に出てくるプロセス（画面入力系、画面照会系、帳票出力系、バッチ更新系、手作業系の各プロセス）に対して、ビジネスフロー図だけでは定義できない詳細な情報を定義していこうという考え方です。
そうすることにより、ビジネスフロー図だけでは明 . . . 本文を読む
データはプロセスに比べて安定しているといわれます。
しかし、データモデル（エンティティ関連図）を作成しさえすれば安定的なシステムが開発されるというわけではありません。
データモデルを作成する際に安定的なモデルにするには、どうすればいいかを意識しながら作成しなければ安定的なモデルを作成することはできません。安定的なモデルを構築する際のポイントは、抽象化・汎化です。
個人的には、全く想定されてい . . . 本文を読む
プロセスのプロパティに概要を記述する欄があります。
この部分には、プロセスの実施目的や実施要領、実施タイミングなどを５W２Hで記述して、ビジネスフロー図では表現しきれないものを補足していきます。
★５W２H ①Why（実施目的） ②When（実施タイミング） ③Where（実施場所） ④Who（実施者） ⑤What（実施対象データ） ⑥How（実施要領） ⑦How much（作業時間、作業 . . . 本文を読む
業務分析を実施する際、ビジネスフロー図だけでは表現できない場合があります。
テキストで説明を記述しなければわかりにくくなるというようなケースです。
そのような場合、ビジネスフロー図上に必要な補足事項をすべてテキストを使用して記述していくという方法もありますが、テキストの量によってはかえって見づらいものとなることがあります。また、テキストだけでは表現できないような補足事項もあることでしょう。（表 . . . 本文を読む
プロジェクトにユーザが参画するということが成功のポイントであるということがよく言われます。（ここでいっているユーザというのはユーザ側のシステム部門のことではなく、ユーザ側の業務部門のことをいっています）
成果物のレビューや承認は、やはりユーザが行うべきでしょうが、成果物自身を一緒に作成していくということになると、これは本来開発者側の責任で行うべき内容です。
しかし、ユーザとしても開発側が必要な . . . 本文を読む
