神崎コンサルノート

バージョン1.5公開

要件のツボ

先週「要件のツボ」バージョン1.5を先週公開した。

このバージョンではパッケージの関係をグラフィカルに表示し、その関係を調整できる「パッケージ登録」を追加した。

当面の積み残し機能の中で最後に残っていた重要な機能である。

ある程度規模の大きなシステムになると、サブシステム分割が欠かせない。

そこで「要件のツボ」ではサブシステムに対応するものとしてパッケージを対応させ、同じくUMLのパッケージにも対応させた。

パッケージに分割すると今度はパッケージ間の関係が重要になる。

そこでパッケージ登録画面では、パッケージ間の関係をグラフィカルに表示し、各々の関係の詳細を表示出来るようにした。

定義情報をパッケージ間で移動させることで関係を調整できる機能も用意した。

＜早わかりビデオ集＞要件定義支援ツール【要件のツボ】

これで規模の大きな要件定義にも対応出来るようになった。

サブシステム間の依存関係を一目で見られる機能は既存システムの分析で一番効果を発揮すると考えている。

画面、イベントとデータをパッケージに分割し、それらの関係を整理することでシステムの全体像が見えてくる。

画面、イベントとデータは機能でつなぎ、機能とデータはCRUD分析で結びつける。

＜早わかりビデオ集＞要件定義支援ツール【要件のツボ】

業務の流れは状態とその遷移で表現し、その遷移に画面とイベントを紐付ける。

＜早わかりビデオ集＞要件定義支援ツール【要件のツボ】

これで既存システムの分析を行い、次期システムの要件定義にスムーズにつなげることを考えている。

問題はどうやってサブシステム分割を行うか　ということだがこれは次回まとめたいと思う。

Permalink | コメント(0) | トラックバック(0) | 11:07

要件定義と要件のツボ

要件定義

１０年ほど前より要件定義をUMLで行い、徐々にUMLでの要件定義が体系化してきた。

そして、2008年にAmazon.co.jp： 顧客の要求を確実に仕様にできる要件定義マニュアル: 神崎 善司: 本の執筆を機会に要件定義の手法としてまとめ上げることができた。

出版をきっかけに、具体的に案件で利用しているかた方からフィードバックをいただき、応用範囲が広がっている。

この体系化をもとに一昨年は既存システムの分析を実践し、昨年何回かその成果をプログラムの大海に溺れないために発表した。

やはり既存システムの分析は苦労している方が多く、実際に「既存システムの分析のサービスはないかと」何回か打診を受けた。

しかし、既存システムの分析を素手で行うのは無謀。

スライドにもまとめたがトップダウンとボトムアップのアプローチを併用して短期間にまとめ上げる目処をつけたので、この機械化も今後のテーマである。

一方要件定義の方はUMLを使わない「要件のツボ」に注力し、はじめて要件定義を行う人でも短時間に要件をまとめられるツールにまとまってきた。

次のバージョンでは細かな改善と同時にパッケージ間の関連をグラフィカルに表示し、その関連をドラッグ＆ドロップで調整する機能を追加した。

これで規模の大きいシステムの要件定義をサブシステム分割して定義できるようになり、同時に関係性の調整もできるようになった。

このバージョンは今月中には公開する予定である。

昨年要件定義の勉強会を何度か開き、その中でUMLツールか要件のツボのどちらかを選択できるようにした。結果的には多くの人が要件のツボを選択して要件定義を行い、短時間で要件を洗い出すことができた。

専用ツールなので当然定義スピードはUMLのツールよりは早いが、問題点も見えた。実際に使っていただく中で様々なフィードバックを得ることができた。

その中でも多かったのが「どうやって要件を定義するか」というのが課題になった。

「勉強会でリードされれば出来るが、一人では厳しい」という意見がもっとも多かった。

そこで次のバージョンではスタートアップ画面をユースケース毎に整理し、それに合わせて考え方を紹介する動画を用意した。

またサンプルの充実も兼ねて「要件のツボ」でERP用のテンプレートを作成する予定である。

要件のツボでの定義方法のサンプルとすることと、基幹系のシステム開発案件の立ち上げを早くすることが目的である。

去年までは要件のツボの機能強化に努めたが、今年は使い方や活用方法についての情報発信に注力する予定である。

Permalink | コメント(0) | トラックバック(0) | 13:56

F#とScala　F#勉強会メモ

SCALA

昨日のF#勉強会の演習をScalaで組み直しコードを比べてみた。

F#のPartition関数をたたみ込み関数を使って作成する

自分のいつもの癖で関数型で考えるときはパターンマッチで再帰を使って考える癖がある。

そもそもこの時点で演習課題とずれているのだが、foldでいきなり考えられないのでまずはパターンマッチで考えた。

昨日は時間切れで完成せず家に帰って、中村さんの答えを参考に復習した。

F#バージョン

let partition (f:'a -> bool) (lst:'a list):('a list * 'a list) =
    let comp (list1,list2) v = 
        if(f v) then (v ::list1,list2) else (list1,v :: list2) 
    List.fold comp ([],[]) lst

これをScalaで書き直してみた

Scalaバージョン

def partition1[T](f:T=>Boolean,lst:List[T]):Pair[List[T],List[T]] = {
    def comp(tpl:Pair[List[T],List[T]],v:T):Pair[List[T],List[T]] ={
       if(f(v)) Pair(v :: tpl._1,tpl._2) else Pair(tpl._1,v :: tpl._2)
    }
    lst.foldLeft(Pair(List.empty[T],List.empty[T]))(comp)       
}

今回F#バージョンで型注釈を入れているがこれも省ける。

しかし、個人的にはパブリックな関数の型は定義した方がいいと思うのでF#バージョンでも型注釈をいれた。

この例でF#とScalaでの違いはcomp関数の型定義とタプルの型定義に現れている。

F#では型注釈でタプルを「( )」で表現できる。Scalaでは「( )」だけではタプルの型とは見なされない（はず...ひょっとして別の表現があるかも）

もう一点はF#では関数定義の型注釈も省けるのでcomp関数の型注釈が無い分簡潔になっている。

ネストした関数については型定義が省ける方が見通しがいいように思う。

この方式はListを使っているのでimmutableな処理方式であるが答えの並びは逆転する。

一方通常自分はどのように解決するかというとmmutableな処理方式で解決する。

単純に答えの形をつくりそこに要素を追加していく方式がイメージしやすいからである。

import scala.collection.mutable._
def partition2[T](f:T=>Boolean,lst:Buffer[T]):Pair[Buffer[T],Buffer[T]] = {
    val tpl = Pair(Buffer.empty[T],Buffer.empty[T])
    lst.foreach(v => if(f(v)) tpl._1 += v else tpl._2 += v)
    tpl
}

この方式は答えとなるtplを先に定義し、f関数の評価結果によってtplの１番目か２番目のArrayに追加する方式である。

F#勉強会では関数型でシンプルなコード作成を演習として行っている。

私はF#のライブラリをほとんど知らず力責めできないので、かえってこの演習が効果的である。

Scalaだと解決策が直ぐに見えるので関数型であろうがなかろうが、その解決策でコードを書いてしまう。最後のScalaのコードも直ぐに書けた。

F#だと手足をしばられてパズルを解いているようで窮屈だが、関数型で考えるトレーニングにはその窮屈さが効果的だ。

Permalink | コメント(0) | トラックバック(0) | 11:53

定義情報をEnterpriseArchitectのファイルに出力

要件のツボ

先々週の東京でのセミナーで「要件のツボ」の情報をEAにつなげた　という意見を沢山いただいた。

そこでセミナー後早速「要件のツボ」からEAへの出力プログラムを作り、先週の札幌での勉強会で紹介した。

札幌での勉強会ではEAと「要件のツボ」の両方で要件定義を行った。

参加者の方からは柔軟で表現力の高さではEAがいいけども、何もないところから定義するのは「要件のツボ」の方が定義内容に集中できて簡単だ。　という意見をいただいた。

セミナー終盤で「要件のツボ」からEAへ出力した結果を見せたところ、関心をもってもらうことができた。

要件のツボで初期の要件定義を行い、ある程度固まってきたところで、EAに移っていくのがいい　というストーリーが見えてきた。

EAにつなげれば設計工程にもつなぐことが出来、開発にスムーズにつなげられる。

ポイントは「要件のツボ」の情報構造をEA上のパッケージで「どのように再現するか」ということだった。

もともとRDRAはEAでのモデリングから生まれたもので、そのノウハウを使って「要件のツボ」を作った。

従って親和性は高かったが、EAから「要件のツボ」に情報を戻すときのことを考えると、検討すべき課題が幾つかあった。

しかし先週のセミナーでの反応から「要件のツボ」からの出力を優先させることにし、低いバージョン（Ver0.3）として公開することにした。

出力する情報は「要件のツボ」のプロトコル以外の全ての情報を出力した。

もう一つの課題は、つながりのある各定義情報をどのようなダイアグラムとして表示するか？　ということと　定義情報の配置の方法である。

まずはつながりのある定義情報を一つのダイアグラム上に全て表示することにし、後はEAの自動レイアウト機能に託すことにした。

EAの自動レイアウト機能がなかなかよい。

自分でモデリングするときには自動レイアウトはほとんど使ったことがなかったが、今回初めて使ってみて結構使えることを確認した。

「要件のツボ」で定義情報を出力し、その結果を自動レイアウトしたのが以下の画面である

http://www.vsa.co.jp/outside_files/hatena/overview_hatena20110919.png

http://www.vsa.co.jp/outside_files/hatena/smallview_hatena20110919.png

自動レイアウト機能は全くレイアウトされていない状態のものを配置するのには大変よい。

正式版を出すまではコミュニティエディションでも使えるようにしようと考えている。

※コミュニティエディションでは以下のことができないので、関係するリンク情報は作成できない。

• 要求の階層化
• 機能とデータのCRUD
• 要求と他の定義情報との関係

公開用のページを作成していないのでしばらくは興味のある方に渡す限定的な公開になりそうである。

Permalink | コメント(0) | トラックバック(0) | 22:08

要件定義に整合性をもたせるためには　定義内容の確認

RDRA, 要件のツボ

前回は時系列にドキュメントを積み上げる方式の問題点をあげ、その改善として洗練化による要件定義の話題を扱った。

今回は同じ整合性でも、定義した内容の整合性について考えたい。

私は、単純に考えると　

　システムとは　「入出力のつじつまを合わせるための仕み」　　　

　　　と捉えている。

役に立つシステムとは、業務やユーザにとって価値のある結果が得られるように最適なタイミングで入出力を提供すること　だと考える。

要件定義においてシステム化の価値を明らかにし、そのためのシステム境界を明確にする。

これが最適なタイミングにおける入出力となる。

問題はここからである。

その入出力のつじつまをどのように合わすか？　

というのが本当の問題になる。

例えば

複数の画面が洗い出され、それらの画面が扱う情報とタイミングをどのように整理すればいいのか？

それらの画面が扱う情報が必要な情報を満たしているとどのように確認するか？

この他にも整合性を確認する方法が幾つかある。

これらの定義した内容のつじつまを合わせるのが整合性を確保することである。

RDRAではCRUDとプロトコルモデルというもので整合性を取る。

その他にも厳密ではないが要求との突き合わせや個々の定義のつながりをナビゲーティブに確認する方法などもある。

UMLを使った場合はCRUDは機能とデータの関連上にCRUDを記述し、プロトコルモデルはステートマシンを利用する。

「要件のツボ」ではCRUDもプロトコルも両方専用の機能として実現している。また、定義のつながりをグラフィカルに表示することや項目レベルの突き合わせ機能もある。

従来のセミナーでは概念的な説明が多かったが、来週のセミナーではこれらをUMLと要件のツボを使って整合性を向上させる方法を紹介したい

９月８日　要件定義支援ツール「要件のツボ」を使った要件定義 | 要件定義の株式会社バリューソース

９月９日　「RDRA＋EAで要件定義モデリング セミナー」

Permalink | コメント(0) | トラックバック(0) | 13:28

要件定義に整合性をもたせるためには　時間との戦い

RDRA, 要件のツボ

要件を定義するとは　役に立つシステムを組み立てる　ということである。

この「組み立てる」というのがなかなか難しい。

１，２週間で終わるような要件定義であれば、そんなに整合性を気にすることはない（頭の中である程度つじつまを合わせられる）が、数ヶ月かかる要件定義では整合性を取ることは大変難しい。

要件定義が始まったときと、それから１ヶ月後とではシステムに対する理解度は全く異なる。

最初の頃は全くシステム化への組立ができておらず、断片的な情報にもとづいて要件を組み立てている。

しかし、１ヶ月もたつとある程度組立が進み、システムの形が見えてくる。組立に伴う様々な意志決定が行われ、システム化の方向性も見えてくる。

そうなると今度は当初に作成した資料と、今作成している資料の整合性が不安になる。

若いときに経験した要件定義もまさにこの不安との戦いであった。

特にウォーターフォールが当たり前の時代。

時系列にドキュメントを積み重ねていくような手法を使っていたので、プロジェクト開始直後のドキュメントの精度の悪さが問題だった。

その反省も込めてRDRAでは全体を広く浅く、徐々に深掘りする方法を提案している。

一つ一つのドキュメントを完成させないで、全体を徐々に洗練化する方式である。

これであればドキュメントが時系列に古いものと新しいものに分かれないので、時間的な整合性の問題を解決できる。

しかし、問題は広い範囲をいかにスムーズに洗練化するかである。

そのポイントは個々の情報を深掘りしないことである。

簡単に直せるように個々の情報を少量の情報にとどめることが肝要である。

個々の情報としては大して情報量がなくても、視点の異なる情報がつながることで、豊かな情報を伝えることができる。

この特性を使って情報を表現し、素早く要件定義する。

いわゆる「モデリング」である。

要件定義のためのモデリングがRDRAであり、それを図的にではなく　ツールとして情報をつなげて登録するのが「要件のツボ」である。

来週のセミナーではUMLを使った整合性の取り方を９月９日のセミナーで紹介し、９月８日のセミナーでは「要件のツボ」を使った整合性の取り方を紹介しようと考えている。

特に「要件のツボ」は専用ツールであり、整合性を確認するための機能が幾つか用意されているので、そこを紹介したいと考えている。

要件定義のためのプロセスという切り口でタイムボックスの考え方を紹介し、そのタイムボックスの中でいかにスピーディーに洗練化と整合性を高めていくかを実演したい。

９月８日　要件定義支援ツール「要件のツボ」を使った要件定義 | 要件定義の株式会社バリューソース

９月９日　「RDRA＋EAで要件定義モデリング セミナー」

Permalink | コメント(0) | トラックバック(0) | 13:14

要件定義の網羅性

RDRA, 要件のツボ

要件定義をある程度行うと徐々にスコープが広がり、同時に大量のドキュメントがたまる。

一方要件定義の担当者は「これで全て網羅しているだろうか」「見落としていることはないか」と絶えず不安。

同時にこんなに広がっては予算に見合わないと考える。

さて　要件定義としての網羅性をどのように考えればいいのか？

私も若い頃　要件定義をすると必ず、要件漏れはないか？　これで網羅しているか？と　とても不安になった。

今思い出してもその当時の不安な気持ちが昨日のように思い出せる。

一方要件定義で範囲を決めても、開発見積もり段階で予算に合わせて機能の絞り込みが必要になり、システム化範囲の見直しが発生する。

網羅的に要件定義を行い、かつ機能の絞り込みでもつじつまのあうようにシステム化範囲を決める方法が必要だ。

今までいくつものプロジェクトを見ていく中で網羅性についての考え方がある程度見えてきた。

そのポイントは以下の３点

• 　システム化の価値を明らかにし、その実現を範囲とする
• 　複数視点からの確認で網羅性を確認する
• 　情報のつながりでつじつまを合わせる

来週のセミナーでは「要件のツボ」と「EA」を使った具体的な方法を示したいと思う。

９月８日　要件定義支援ツール「要件のツボ」を使った要件定義 | 要件定義の株式会社バリューソース

９月９日　「RDRA＋EAで要件定義モデリング セミナー」

Permalink | コメント(0) | トラックバック(0) | 17:16

2011年08月22日のツイート

Permalink | コメント(0) | トラックバック(0) | 02:00

2011年08月19日のツイート

Permalink | コメント(0) | トラックバック(0) | 01:32

2011年08月17日のツイート

Permalink | コメント(0) | トラックバック(0) | 01:37