スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

プロセスバリュー・エンジニアリングとは(第7話)


前回までは現状把握の勘所について話してきました。
現状把握が終ったら次に行なうのが要件の確定です。

・・・・・

ICTシステムを構築する場合、特に重要なのがシステムの要件定義です。
システムの要件定義は

「何をゴールとしてシステム構築をするのか」を決めることだ

と言い換えられます。

大切な言葉は
「ゴール」

「決める」
です。

これがとても至難とも言える難しいタスクなのです。
システム開発を主導してきたエンジニアの皆さんなら、一度くらい痛い目に遭っているのでは無いでしょうか?



(続きはこちらへ・・・)



              <Time Slip>
           ☞ 前回   ☞ 第1話 



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

スポンサーサイト

ER分析というもの(第7話)


ER分析はゴールでなく、その後で業務プロセスに照らして検証をするという話をしてきました。

今日はその続きです。

・・・・・

業務プロセスによる検証が済んだら、最後に実際に使う形を設計します。
RDBを使うのか、単なるファイルを使うのか、もしくは表計算ソフトを使うのかといったことを考慮して、それに適した形にエンティティとリレーションを再編成するのです。

これを非正規化もしくは物理設計ということもあります。


デライブドデータ(データそのものを持っていなくても演算で導出される2次的なデータ)をどう扱うのか等といったことも、求められるレスポンスや許容されるシステム性能と見比べて決定します。


これでデータ設計はほぼ完了です。

「ほぼ」というのは、バックアップをどうするかとか、複数の事業所で共用するのはどうするかと言った運用に関わる部分が残っているからですが、今回の主眼からはずれるのでここまでとしておきます。(^^)



データ設計の方法を改善したい悩みを抱えている方がいらしたら、正規形ER分析を取り入れてみることをお勧めしますよ。(^^)/






              <Time Slip>
           ☞ 前回   ☞ 第1話 


                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

ER分析というもの(第6話)


ER分析について話をしてきました。

今日はその続きです。

・・・・・

「データ設計を効率的に行なうために」ER分析は有用ですという話をしました。

しかしER分析はゴールではありません。
あくまでゴールはシステム設計で、その作業の1つとしてデータ設計があります。ER分析はデータ設計の一部であり、1つの手段なのです。

ロジックの設計に入る前に、そのシステムで扱うデータの設計をしているのです。

ではER分析が済んだら次は何をするのでしょうか?


それは業務プロセスからの検証です。
ER分析で整理されたエンティティとリレーションというデータ(レコード)の塊には、理想的なものが挙げられていたり、逆に現実に必要なものが抜け落ちている可能性があります。

そこで、今度は実現しようとする業務プロセスでそのエンティティとリレーションを検証します。

必要な情報が拾い出されているか?
不要な情報が定義されていないか?

といった検証です。

実務に適した無駄のないシステムを設計するための検証です。

検証は、データフローを1つ1つ当たっていけば済むことなので、難しいことではありません。(作業は膨大なことが多いですが・・・)





(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回   ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

ER分析というもの(第5話)


前回、基本論理設計のツールとして役立つようなER分析をするには正規形ER分析をすればよいという話をしました。

今日はその続きです。

・・・・・

データの正規化というのは、主としてリレーショナルデータベースを設計する手法と教わってきた方もいらっしゃるかと思います。

しかし、階層型データベースであってもネットワーク型データベースであっても正規形ER分析をした結果というものは役立ちます。

最近は、オブジェクト指向を標榜するデータベースも良く見られますが、これらはキー項目を暗黙的に保持しているのでデータ間の従属関係が見えにくく要注意です。
しかし、この場合でもデータ設計前に正規形ER分析をしておけば、容易に適用が可能になります。


ネットサーフィンして拝見した感じでは、正規化という作業は何だか難しそうであり、とっつきにくい印象ですが、全くそんなことはありません。やり方を教われば誰でもさらさらと第3正規形に変換できます。


要は、単独であろうと複数の属性の組合せであろうと「主キー」を見つけて、その主キーでただ1つだけデータ(レコード=属性の集合体)が特定できるようなデータ(レコード)の塊に分けるということだけです。




(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回   ☞ 第1話 
                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

ER分析というもの(第4話)


基本論理設計のツールとして役立つようなER分析が重要だというお話をしました。

では、それは一体どのようにしたらいいのでしょうか?
・・・・・

ER分析で得られる「エンティティ」や「リレーション」というのは、顧客企業にとって 「管理関心のあるデータ」 です。

しかしやみくもに 「管理関心のあるデータ」 を定義したところで、あまり嬉しいことは期待できないと思ってください。
意義のあるアプローチでER分析をしなければあまり有益な作業ではなくなってしまう恐れがあるのです。

プロセスバリュー・エンジニアリングでは、正規形ER分析を推奨しています。

何故か?
それは

1.シンプルで誰にも分かりやすい結果を提供する
2.誰が行なってもおおよそ同じような結果を導き出せる


ためには、正規形ERモデルを作ることがポイントだと考えているからです。


プロセスバリュー・エンジニアリングで推奨しているのは、第3正規形を満たすレベルに分析・整理したERモデルです。


第3正規形の説明は、ネットから引用して済ませようと思いましたが、なんか難しい説明ばかりの記事しか捜せなかったので厳密な説明は避けて、私なりの言葉にしておきますね。(^^;)


簡単に言うと第3正規形では、

・主キー以外の項目は全て主キーに従属した項目(=単純属性)で、
・単純属性間に従属関係がなく、
・単純属性のオカレンス(インスタンスとも言います)が主キーに対して1つしか存在しない

状態に成っています。

つまり、
第3正規形とは、主キーとなるデータ項目が決まるとただ1件だけのデータ集合に特定できる状態になっている状態なのです。

例えば学校の健康診断のデータで、
「生徒番号がわかると生徒の学年や身長などがわかる」
という状態がそれです。

この時、生徒番号を「主キー」、生徒の学年と身長を「単純属性」と呼んでいるのです。




(続きはこちらへ・・・)



              <Time Slip>
           ☞ 前回   ☞ 第1話 



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

ER分析というもの(第3話)


ER分析は、システムで取り扱うデータに対する基本論理設計だというお話をしました。

今日はその続きです。
・・・・・

いろいろなシステムでオールラウンドに活用できる「基本」で「論理」の設計だ

ということが肝心です。

そのためには、
シンプルで分かりやすいものでなくては困ります。
多くの関係者で同じ理解ができ、後世にも継続活用可能であって欲しいからです。



ネットでちょっと検索したところ、ER分析についていくつもの記事が解説や手ほどき、例題などとしてヒットしますが、読んでみると中には「???」というものがいくつか目に付きました。


私のバックボーンであるプロセスバリュー・エンジニアリング的に見て、ε=( ̄。 ̄;)っていう感じの記事なんですね。

具体的に挙げるのは差し控えますが、例えば、

・データ構造を複雑でわかりにくくしている
・論理的な発想が弱く、現実世界の制約に捕らわれ過ぎている
・ER分析している意義が感じられない

といった感の内容のものが散見されるのです。



ところで、効率的にデータ設計を進めるためには、作業を簡単に分担できる方が有利です。

作業の中に個人の思惑や感覚に拠る部分が大きいと、担当した作業者によって結果がバラついてしまいます。
つまり田口メソッドで言うところの「品質」が悪くなるわけです。


従って、ER分析についてのもう一つの要件は
「誰が行なってもおおよそ同じような結果を導き出せなくては困る」
というものです。



ER分析は基本論理設計のツールとして役立って欲しいので

1.シンプルで誰にも分かりやすい結果を提供する
2.誰が行なってもおおよそ同じような結果を導き出せる

ものであることが重要なのです。




(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回   ☞ 第1話 




                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

ER分析というもの(第2話)


前回は、データ設計について話し始めました。

今日はその続きです。
・・・・・


「エンティティ」や「リレーション」というのは、顧客企業にとって管理したいデータの集合です。

「管理関心のあるデータ」と言っても、わかったような、わからないような・・・

と戸惑う方も少なくないと思いますが、そうなんです。そんなものなんです。

最初は言葉で理解しようとしてもなかなか難しいようなので、ER分析を何回か体験してみるといいと思います。


ただしER分析というものは、下手に進めると哲学的な迷宮に迷い込んでしまうので要注意です。

あくまで

「データ設計を効率的に行なうために」実施する
と言うことを肝に銘じて取りかかる姿勢が重要です。


将来的にどのような仕掛けでデータを運用することになっても、オールラウンドに活用できる基本設計だと考えて下さい。

そうです。ER分析は、取り扱うデータに対する基本論理設計なのです。





(続きはこちらへ・・・)


              <Time Slip>
           ☞ 前回



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

業務分析の要諦(つづき)


前回は、業務分析の要諦についてお話しました。
ところが書き始めたところ、思いのほか文字数が膨らんでしまったので書ききれませんでした。 (;¬_¬)
今日はその続きです。
・・・・・

さて、私の業務分析はDFD(データフローダイアグラム)という表記方法を応用したものです。
DFDそのものは古くからある有名な表現ですので大した難しさはありません。
誰でも描けて、誰でも理解できるよくできた図表です。

しかしそれを使ったら誰でも良い業務分析ができるかというと、そうでもないのです。

ワープロを買ったからといって、感動する小説を誰でも書けるというものではないのと同じです。
もしくは、音符を理解したからといって素敵な音楽が誰でも作曲できるわけではないのと一緒ですね。


どのように業務の実態を聞き出して、どのように表現するのかといったような、
形の無い部分の作業がきちんとできないと、良い業務分析はできないのです

調査に協力してくれる人の言葉や気持ちがスッと腑に落ちて、そして相手に要点を問い返すことができるような理解力と表現力と共感力、そしてリズム感がとっても重要なんです。

ですからとても奥が深い世界ですね。
私も常に成長を求められます。
20年間業務分析と付き合ってきましたが、
毎回毎回発見と喜びの連続です。

近々、ある大手量産メーカーさんでの業務分析が始まります。
これは春に一度実施したのですが、
この手法の素晴らしさを知っていただいたので、
別の部門へと対象を広げての活動です。

また新たな出会いと感動があると思います。楽しみです。


(続きはこちらへ・・・)


              <Time Slip>
              ☞ 第1話 




                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 日々のつれづれ - ジャンル : 日記

業務分析の要諦(ようてい)

仕事柄、いろいろな企業の業務分析をさせていただいています。

業務分析・・・・?
いったいどんなことをするんだろう?

なんて思われる方もいらっしゃるでしょう。


私の行なう業務分析は、お客さんの目的を踏まえて、
ある時は問題点の洗い出しだったり、
ある時はより良い情報システムを作るための情報収集だったり、
またある時は何か設備を導入する際の青写真作りだったり

と、いろいろな目的で行なわれます。


先日はとある設備メーカーさんでしたが、

・設備の引き合いからその要望に添った設備を設計・製造して納品するまでに、
・費用や期間がどれくらい掛かるのかを見積もる部分の業務をスピードアップする

ための業務分析です。

忙しいときには、その見積作業が処理しきれずに回答が遅れ、ライバル企業に取られてしまうということも少なからずあるそうです。

合計10時間ほどの現場聴取をさせていただき、現状の業務を洗い出し、そこに潜んでいる要改善点を整理しました。

今月からは、業務分析結果から得られた対策案のうちの1つとして、簡単なシステムを作るための要件定義が始まりました。

あいにくのこのご時世ですから、 (^^;)
顧客社内で済ませられる程度の小規模開発だけども効果が出るものという制約付き ε=( ̄。 ̄;) 
のシステムについて要件を決めるのです。
年明けにはシステムの雛形が出来上がる予定です。
大きな効果が見えているので今から待ち遠しくしていただいているんですよ。o(^-^)o



(続きはこちらへ・・・)



                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

要求定義と要件定義の違い(第2話)


前回は、「要求定義」と「要件定義」の内容の違いについてお話をしました。
今日はその位置付けの違いについてお話しします。
・・・・・


前回、要件定義の作業をQFDを作っていく作業に例えました。
ユーザー要求項目を、システム的な代用特性に置き換えて各種パラメータを決めていく作業が、QFD作成の過程と同様だからです。

要件定義の場面は、意思決定の場面であるということが重要です。
どんな機能や性能で我慢するのかを決める場面なのです。
何故「我慢」するのかというと、それは費用や開発期間などに制約があるからです。


それに対して業務要求は「必要なこと」なので開発側の状況におかまいなしに出てきます。
(もちろんそれでいいのです。)

だからそれらを要件定義の場面で、現実的な形に整えていくわけです。


その後要件定義された骨格に沿って、さらに詳細な設計仕様が詰められていきます。
よくできた要件定義書が在れば、その後の詳細設計は比較的機械的な作業で済まされます。
従って要件定義は、開発側にとってとても大切なものなのです。


さて、今度は要求定義についてお話します。

要求定義はユーザー側にとって非常に大切なものです。
というのは、要求定義の善し悪しが、システムが効果的かどうかを左右するからです。


要求定義は、ユーザーの要望を単に書き並べる作業ではありません。
ユーザーの要望は抽象的な表現が多いので、それを具体化するという重要な作業があります。

具体化作業の中には、業務に照らしてその要望が本当に重要なのかを検証していく作業が含まれます。
その要望が、

「どの課題を解決するものなのか?」
「単に不具合現象への対症療法ではないのか?もぐらたたきではないのか?」
「副作用(デメリット)はないのか?」

など、多面的に検証します。当然、具体化の過程で取り下げられる要望も出てきます。

要求定義をきちんとできるためには、業務全般に対する知識や経験を備えていることが望まれます。


ところで要求定義書のことを「RFP」(Request For Proposal) と言うこともあります。
RFPは、ユーザー側から開発側へ提示される要求定義書のことで、RFPを元に開発側が提案書を作って提示します。費用や開発期間などの前提が食い違わないようにするために、ユーザー側と開発側の間で事前に取り交わされます。
RFPと要求定義は同じものだと考えて構いません。


私の勤めるプルーブでは、要求定義や要件定義の作業もお手伝いしています。

ユーザーサイドの要望を租借して、きちんとした要求定義書に落とし込んでいく作業は、プロに任せた方が安心という考え方が定着してきたからだと思います。





              <Time Slip>
              ☞ 第1話 

                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

要求定義と要件定義の違い

一般的に、情報システムを構築する時に「要求定義」とか「要件定義」とかいったものが必要になります。
しかし、意外とこの辺りの区別がされていないことも少なからずあるようです。

書店でコンピュータ関係の書籍コーナーに並んでいるシステム開発技法の解説書を見てみると、この両者をきちんと区別して書くことなく曖昧にされているものが多く見受けられます。


ユーザーとの打合せで、要求定義と要件定義の言葉の違いがわからずに困惑している若いSE(システムエンジニア)も少なくないのではないでしょうか。


要求定義と要件定義をきちんと区別して考えることが大切です。
というのは、要求定義と要件定義では意味合いが全く違うからです。


要求定義は正確に言うと「業務要求定義」または「ユーザー要求定義」の略です。

同じく、要件定義の方は「システム要件定義」の略です。


要求定義の方は、

「こうしたい!」
「こうなって欲しい!」

という、システム利用者(=ユーザ)側からの要望を書き留めたドキュメントです。
つまり、システムが完成した暁に得たい恩恵を示します。
(多くの場合、要求者の脳裏では日常の業務場面に照らした形で発想されています)
もちろん、「いくらで」「いつまでに」といった付帯条件も伴います。

一方、要件定義の方はと言うと、

「では、こうします!」
「こういう機能と性能にします!」

という、システム設計者側で受け入れる設計条件を書き留めたドキュメントです。
(この種のドキュメントのことは仕様書とも言います)


つまり要求定義書にはユーザ側の思いが込められ、要件定義書には調整され意思決定された仕様(スペックとも言いますね)が表わされているのです。

製品開発で設計仕様を決める手法としてQFD(品質機能展開)がありますが、QFDに重ねて考えるとわかりやすいと思います。

QFDの左側の列が要求定義項目、上段の行が要件定義項目という関係です。
つまり、QC(品質管理)用語で言えば、要件定義項目はユーザー要求の「代用特性」ということになります。



(続きはこちらへ・・・)





                拍手する
仕事のやり方を改善したいならここをクリック!
blog用Prove2           
業務改革パートナー!! プルーブ


和太鼓の魅力を感じたいならここをクリック!
blog用JDMS1
心に響く和太鼓音楽集団!! 佐倉太鼓衆

テーマ : 思い入れ - ジャンル : 日記

プロフィール

sugimotom

Author:sugimotom
ようこそ!
職業は業務改革パートナー。余暇は篠笛や和太鼓の響きを楽しんで過ごしています。
そんな私の仕事のこと、趣味のこと、日々感じたことなど 徒然に書き留めています。

私も気が付けば半世紀もの月日を重ねてしまっていました。
飛び去るように過ぎて行く貴重な人生の合間に、ほんの少しだけ立ち止まって、さぁ深呼吸!

大切な今を思いっきり感じましょう。
    → → → プロフィール

最新記事
FC2カウンター
月別アーカイブ
最新コメント
最新トラックバック
..
ブログパーツ アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。