たわごと・その２０３

　1年経ったので見てくれている人にコメントをお願いしたのですが、奥ゆかしい人が多いようで、最初から見てくれているkomaさんなど、2名ほどしかありませんでした。見てくれている都道府県名ぐらいだけでもいいので、ここで再度お願いしてみます。
そういえば、ｋomaさんから以前に、投稿を頼まれていたのですが、ネットで見つけた堺自由都市文学賞の募集をみて、この連休に書いてみようかと考えています。（同人誌の投稿なら2重投稿も可とのことです）たた、庭の草むしりが、早く終わればですが、komaさん少しお待ち下さい。あと、動画のキャプチャですがフリーソフトで何本かありました。Flashで操作画面の動画も作成できるとは聞きましたが、簡単に出来るのでしょうか？Flashのツールは少し高価ですね。
　メルマガで知ったのですが、以下の検討を数社で、始めるそうです。
非常に興味があるのですが、どうなるでしょう？どの程度のユーザーの声を聞くかでしょうけど、検討会を見てみたいです。

　お客様にわかりやすい仕様の記述方法・合意方法の推進について
～企業・プロジェクト毎に異なっていた仕様記述・合意方法について
現場の実践にもとづいたベストプラクティスを共同検討～
2006年 4月12日
株式会社NTTデータ
富士通株式会社
日本電気株式会社
株式会社日立製作所
株式会社構造計画研究所
東芝ソリューション株式会社

共同検討内容
(対象の領域)
<仕様記述に関する事項>
•画面遷移・定義
画面遷移やレイアウトといったWeb アプリケーションでは必須の設計項目でも、プロジェクト毎にその記述方法は異なっていることが少なくありません。そのため仕様記述方法の検討を行います。
•ビジネスプロセス(業務の流れ・手順の仕様)
要件を定義する際に、ビジネスプロセスを定義することは重要と考えられます。標準的な記述方法も提唱されていますが、IT業界固有の表現が中心であるため、必ずしも発注者にとって理解しやすいとは言えません。そのため発注者が理解するために必要な、より補完的な記述方法の検討を行います。
•データモデル(データベースの仕様)
データの構造(=スキーマ)を設計するには仕様書が不可欠ですが、技術的専門分野の情報であるため発注者が理解することは大変困難です。そのため発注者が確認可能な仕様記述および確認形式の検討を行います。
•業務ロジック(処理詳細の仕様)
処理の詳細を記述する際には、情報の流れ図(=フローチャート)や業務や処理手続きの流れを記述するための図(=アクティビティ図)といった表現を使うケースが多いのですが、プロジェクト毎に記述方法が異なっていることや、抽象的な表現であることにより理解が困難なケースがあります。そのため発注者が容易に確認可能な表現方法の検討を行います。
<仕様合意に関する事項>
•お客様との仕様合意方法
検討の過程で生じた各方法論について、実際の開発現場での適用可能性の検証を行いつつ、発注者側企業の協力を得て、合意までの確認および確定の方法について検証を重ねながら仕様合意形成方法の検討を行います。