ホーム

無料セミナーのアンケート結果

演習で学ぶ要件定義 in 札幌　アンケート結果（2010年07月03日）
アンケート回収数：１５　　　公開可能コメント数：９

●初めて会った人で、しかも専門的な知識があまりない方とのグループワークだったので、そういった場面の難しさを体験できてよかったです。「要件のツボ」はシステムを作る上で何を考えなければならないかというガイドラインとして大変有効だと感じています。「KANAME」でなくなってしまい残念です。

●普段はデバイスドライバの開発を行っており、要件定義の経験が殆どなかったので大変勉強になりました。
●アクターの設定とかユースケースの粒度とかが難しかった。（私はほとんどメインフレーム系の大規模システムのある一部とかの開発が多いので）使いこなせば、KANAMEかなりイケルと思いました。
●初めて会った人とグループ演習で要件を検討することが、とても難しいことが実感できました。用語の統一や考え方の理解が必要で立ち上げに時間がかかりましたが、コミュニケーションスキルの向上に役立ちました。要件についてもこのツールを利用することで上や下から繰り返し回すことで、みんなで理解を深めながら進めることが出来ました。本日はありがとうございました。

●内容は大変期待通りだった。グループ演習も大変有効だった。
●具体的なフレームワークに乗せることで何をやるかは明確になった反面、やることを具体的にイメージできないと何もできなくなると思った。全員にそのレベルを要求するのは難しい。が・・・、開発上でも似たような状況下なぁ･･･。題材としては、もっとシンプルにやる方が良いかもしれない。
●大変役に立ちました。またの機会があればぜひ参加したいです。
●初心を思い出します。ありがとうございます。
●大変期待通りの内容だった。「要件のツボ」は大変役に立つと思いました。

要件定義セミナー in 東京　アンケート結果（2010年05月17日）
アンケート回収数：８　　　公開可能コメント数：
●大変勉強になりました。“ガント”で上手くいかない点も理解できた気がします。
●ソリューションの提案を作っているので、その場でうまく情報共有が出来ないものかと思っていたのでツールには興味があります。

●これまでの要件定義のやり方と大きく異なる手法なのでプロジェクトのメンバーにRDRAを理解させる（この手法の素晴らしさを理解させる）ことがまずは第一歩だと思います。
　 また今回、要件定義のプロセスとフレームワークを教えていただき、これまで全くこういうものを意識していなかったので、大変参考になりました。
　是非ツールを試してみて、より深く理解したいです。

●ツールを試してみたいと思います。

●受け入れテストを実施するに当たっての参考になればと思い参加しました。“要件定義”の認識が少し違っていたので受け入れテストに直結はしませんが、社内で小さな開発をするときなどにツールを使ってみたいと思いました。

 

要件定義セミナー in 札幌　アンケート結果（2010年03月05日）
アンケート回収数：１６　　　公開可能コメント数：１４

●RUPのような考え方で大変勉強になりました。ガントチャートは納得です。

●要件定義では「なぜその結論に至ったのか」というところがあやふやになることが多いので、この考え方（このツール）はその辺りが明確で立ち返りやすい。
●「人」というファクターに変化があるのは実感している。この方法で解決するのだろうか？
●XPのペアプログラミング、スパイラル開発に似ていると思った。次回も案内をください。

●要件の構造化、ツールとも参考になりました。未経験分野の要件定義やチーム内で共通認識を持って進めるのに良い手法だと思います。発注者（お客様）との合意に有効かは相手のレベルによるでしょうが・・・。
●要件定義について理解できました。（普段は要件定義に携わっていないのですが）
●用語集についても対応して欲しいです。とても分かりやすかったです。ためになりました。
●要件定義の必要性は何となくわかりました。
●現在「アジャイルな見積もりと計画づくり」という本を社内で読んでいますが、開発工程と要件定義の工程の違いはあるとはいえ、通じるものがあると感じました。開発までサポートされるとより面白いような気がします。
●大変興味深い内容でした。ガントチャート式は常々難しいのではないかと思っていたのでKAMAMEを是非使ってみたいです。
●PCのスペックはどの程度必要なのでしょうか？　ガントチャートについては、まさしくその通りです。
●感覚的に問題があると分かっていたガントチャートですが、今日、何がダメなのか、いいのか、明らかになってスッキリしました。タイムボックスはとても興味深い手法です。
●具体的な開発事例を通したKANAMEの使用方法があれば理解が進むと思います。
●いつもスケジュールを引けと言われ、ちょっと苦しんでいる部分があります。少し解決のヒントが見えてきたような気がしています。ガントチャートを引きたくない派ですので・・・。

 

要件定義セミナー in 東京（onsite）アンケート結果（2009年11月26日）
アンケート回収数：６　　　公開可能コメント数：９
●いつも要件定義を進める中で感じていたモヤモヤに一つの答えをいただいた感じがしています。
決められた形式や固定概念にとらわれて、要件定義の本質的な目標と離れたところに時間と労力を費やしていたのではないか、と気付くことができました。要件に構造（枠組み）をつけて整理することを意識はしていましたが、具体的な手法を持っていなかったので思い通りにならなかった部分でした。今回のセミナーで具体的な手法を示していただいたので、是非実践したいと思います。また、タイムボックスを使用したスケジュール管理も新鮮で、今後実践してみようと思いました。お忙しい中、本当にありがとうございました。
●要件定義フェーズでガントチャートが役に立たないことを、ちゃんとその理由と代替策を持って説明されていることに感銘を受けました。このフェーズでもアジャイルを適用していく勇気が沸きました！
●前回拝聴した時よりも、時間に余裕があった事もあり、より具体的に説明して頂き、よく理解できました。参加メンバからも良い話が聞けたとの声が聞こえています。本当にありがとうございました。
●普段の要件定義のなかでは成果物を確認して合意(チーム内やユーザーと)することに意識がとられがちですが、その検討をチームで行って関係性を説明できるようにし下地を作り、それによりユーザーをリードしていくという考え方が斬新でした。
「UC&業務」などの普段の成果物を組み合わせた途中成果物は確かに普段各担当が成果物を作る再に頭の中で考えていることですが、それをきちんと見えるように定義していくのは今後実践してみたいと思います。
プロセスについてはやはり信頼がある状態で初めてユーザーにも展開していけるかと思います。まずはチーム内での進め方には適用してみたいと思います。ガントチャートとうまく組み合わせてプロセスを進めていく方法が模索できればと思います。
まずはEAのテンプレートを利用させていただきつつ、いつかは機能制限版でもいいのでRDRACheckerも公開されることを期待しています。
●哲学的なことではなく、実際に成果物に落とし込むまでの方法と目的がきけて非常に有意義でした。
実際に要件定義をかかわったことはないですが、担当するときはRDRAを試してみたいと思います。時間が経過するごとによりドキュメントが増え、システム全体が見えにくくなる。という印象がありましたが、EAを使うことにより各ダイアグラムでの関連させることにより、要求の実現ができているか？というチェックが見えやすくなり感心させられました。

●非常に有用なお話しを聞かせていただき感謝しています。ありがとうございました。
特に
・ UMLをそのままお客様との合意に利用しない
・ 要件定義をアジャイルに進める
という点に、非常に興味を持ちました。
 プロジェクトを前に進めようとする目的志向が全体のベースにあるのだと感じ、機会があればプロジェクトでも実践したいと思っています。
要件を引き出し顧客との合意を得るサイクルについて、機会があればさらに具体的なお話を伺いたいです。
本日は貴重なお話を聞かせていただき、ありがとうございました。

 

要件定義（RDRA)セミナー in 豆蔵　アンケート結果（2009年10月20日）
アンケート回収数：１０　　　公開可能コメント数：９

●要件定義の以下の進め方が役に立ちました。
　・最初は関係者全員でやって認識を合わせる。
　・ユーザヒアリングを行う前に、一度全体を作成する。
社内の標準プロセスとの対応付けが難しいような気がしました。

●時間が短かった。フレームワークよりプロセスを詳しく聞きたかったです。
●目新しい内容ではなかった。成果物の整理がされているのでわかりやすかった。
●標準化の逆を行くような現実的な話で面白かったです。
●いわゆる反復開発で使う時の利用法があると嬉しいです。ありがとうございました。
●事前に本を読んでいたので、内容は良く理解できました。資料にない話や事例が興味深く、役に立ちそうです。
●仮説のための要件定義が良いなと感じました。
●全体像がざっくり解り、整合性の確保を最重視した定義手法だということが良く理解できました。参考にさせていただきます。
●要件定義メンバーで1週間まず作るくだりが面白かったです。ややテストドリブンな香りがして納得感がありました。

 

要件定義（RDRA)入門セミナー in 東京　アンケート結果（2009年9月11日）
アンケート回収数：９　　　公開可能コメント数：９
●もうウォーターフォールには戻れません・・・　大変有意義なセミナーでした。ありがとうございました。

●実習の部分がたくさんあったため、あまり理解できずにただ転記しているだけという状態になってしまった。
内容が多く理解するのが難しかった。本を見て復習します。ありがとうございました。

●実習でダイアグラムに記述していくことでより具体的に実務に導入するイメージが出来ました。
普段アクターと関わる部分しか扱っていないため、プロトコル部分は少し現実感が持ちにくかったです。
全体の粒度をそろえることに留意する、という考え方が新鮮でした。
実務でつい陥りがちな「進行に比例して詳細になっていってまとまらない」理由がわかりました。
●各モデルを作成する意図やそのモデルの関係性を理解することが出来ました。
また、各モデルはひとつ前のモデルに依存し、最終的には“システムの価値”が大事であることが理解でき、要件定義をする上で、軌道修正の方法が解りました。本日はありがとうございました。
●管理が難しそうだと感じました。要件定義で定義する範囲が明確になって参考になりました。
各図をつなげる時に上手くつながるかなと思いました。
チーム内での共通語としてのモデル図はメンバーが読み方、書き方を理解すれば有用なものになると思いました。
●レビュー時にダイアグラムに配置しながら確認するというのは感心した。
あと、計画についてはタイムボックス方式を理解していない人が多い。（ガンチャート、WBSで線を引かないと気に入らない人）
でもやってますが。　進捗の報告が難しい（神崎さんの言う、濃度・粒度・洗練度をどう伝えるか）
●・複数のダイアグラムの関係により、要件がシステマティックに整理されていくのはよい手法だと思った。
　→従来だと「えいや」で途中が飛躍してしまうことが多いので。
・どのようなダイアグラムが必要（使える）か？は理解できたが、どうやって図を作っていくかはまだ理解しきれていない。
　これはケースをこなしていくことが必要だと思う。（実践セミナー？）
・成果物をだんだん洗練させていくイメージは昔からあったが、それぞれのマイルストーンでの具体的な達成基準を例示して頂いたのは解り易く、参考になった。
●・セミナーの申し込みですが、Acrobat readerではフォームに入力した内容を保存できないので、戸惑ってしまった。
　自宅にAcrobatを入れている人は少ないでしょうし、法人でも全PC分ライセンスを買うのは稀だと思うので、申込み方法を変えた方が良いです。
・とても現実的な方法だと思いました。曖昧でターゲットが定まっていない状態でstartする要件定義という工程を歪みなく自然に進められるのではないでしょうか？
・タイムボックスが良かったです。上流工程でスケジュール法に切り込んでいる方法は他に無いのでは？
●「要件定義マニュアル」の本を使用し、実際にRDRAで要件定義を行っているのですが、曖昧な部分（理解できていない）に関して知識が深まりました。実践セミナーにも参加したいのですが、予算的なところと相談になりそうです。
本日はありがとうございました。

 

要件定義セミナー in 岡山　アンケート結果（2009年8月1日）
アンケート回収数：２８　　　公開可能コメント数：９
●現場で行っている内容と異なる話もあり、今後の現場に今日の話が応用できるかを考えてみようと思った。

●もっと具体例が聞きたかった。
●先生の本を買ってよく読みたいと思いました。
●短時間ではあったが非常に有益であった。開発手法／顧客対応への大きな助力となります。ありがとうございました。 質問に対して非常に解りやすかった。
●スケジュールの考え方を詳細に聞きたい点がありました。要件定義は最初の工程なので考え方がよくわかりました。
●実業務に役立てれそうです。
●要件定義を4つの部分に分けるというのが、解りやすかった。
単独モデルのチェックではなく、関連でチェックするというのは確かに期待できた。
●RDRAの関係ダイアグラムの訓練（ドキュメント作成）－お客様へのヒアリングをする前に関係者でドキュメントをすべて書きましょうという部分－を１日の有料セミナーにするのであれば相当有効なものになりそうな気がします。 情報源など有益な情報が多く、参考になりました。

 

要件定義紹介セミナー in 東京　アンケート結果（2009年7月29日）
アンケート回収数：２６　　公開可能コメント数：５
●"様々な視点から見たモデルを多数作成するということで、グラフィカルで分かりやすいと思います。一度、実践してみて感覚をつかんでみたいと思います。
●網羅性と整合性については良かった。
●予想よりも簡易に使えそうなフレームワークだと思いました。
●要件＊＊は、やってみないと実感がわかない。
●要件定義の分野では、新しい概念というか考え方があり、その点ではとても良いかと思いましたが、一般的な要件定義のイメージがあるため、世の中にどこまで受け入れられる考え方あるいはやり方を考えると、疑問符が浮かんできます。

 

要件定義セミナー in 札幌　アンケート結果（2009年7月10日）
●フレームワークの定義的な部分についてはとてもよくまとまっており、自分の経験と合わせて今後の業務に行かせると感じた。 反面、もう少し具体的な導入事例等の説明があればよかったように思う。
●参加者同士でワークショップをやるような形をやりたいですね。前半は本を読んでいる人にとってはやさしく、読んでない人には 難しいのでは？と思いました。慣れるためにも小規模な要件定義のワークショップをやりたいですね。有料でも参加します。
●要件定義のまとめ方（Framework）は有用だと思いました。気にかかるのは納品物としてのまとめ方でした。　 やはり、平文形式が求められる形なので。　今後、チームに広げていければと思っています。　ありがとうございました。
●社内で扱っている案件のほぼ100%近くの開発物（例えば、ECサイト、コンテンツ投稿サイト、携帯サイト）で、なかなか しっかりした上流行程することがなかったので、今後の開発に役立てればよいと思いました。　本日はありがとうございました。
●こういった上流行程のセミナーを受ける機会があまりなかったので、貴重な時間を過ごさせていただきました。
●非常に別な視点で考えることが出来るのではないかと思いました。
●要件定義マニュアルとEAをセットで使用（まだ活用できていませんが･･･）しています。 ドキュメントライブラリアンを配置もしくは担当しなくて済むので助かっています。
●有料セミナーの受講を検討したいですが、具体的な費用などの情報が欲しいと思いました。
●「本」で復習します。　タイムボックスにはスキルが必要なところをどうするか悩みますね。
●全体が体系化されていて、とてもわかりやすかったです。　ありがとうございます。
●目からウロコでした。　参加していない社内の人間にも聴講させたい内容でした。
●話は非常によく解ります。　ただ、どう実践したらよいか？がいつも悩みの種。 RDRAを使って確認してみたいので、有料セミナーも検討してみたいです。
●フレームワークもプロセスも、実際の業務で取り入れられたら面白そうだし、上手く出来たらスケジュールも要件定義も新鮮な形で モチベーション高く作業も出来そうだと思いました。　やってみたい！というのが感想です。

 

要件定義紹介セミナー in 東京　アンケート結果（2009年6月10日）

●書籍を購入して実作業の落とし込みを検討しています。重要事項が分かって良かった。
●UMLについてそれほど使いこなせていないので、内容は高度に感じましたが、面白かったです。
●具体的な要件を元にシステム価値からシステムを説明いただければもっとイメージしやすかった。
●もう少し、コンサルをしたときの事例を教えてほしかった。方法論はとてもわかりやすかった。
●非常に参考になりました。先日、来日したポッペンディーク夫妻もイテレーション、ふりかえり、などを話されていて、今回の話で良く分かりました。
●タイムボックスに関しては、発注がわのエンジニアであれば採用しやすいと思います。実際に開発で採用していました。逆に受注する立場では、提案しずらと思います。そのあたりの提案方法があれば・・。
●要件定義の進め方は、苦労しているので有意義でした。
●要件定義のプロセスと、工程管理の仕方、説明できることの重要性を理解できた。今回、講義いただいた内容が、どれくらいの規模のシステムまで適用可能か知りたい。
●プロセスに出てくるモデルの1つ1つについて、モデルを作る意味、目的をもう少し詳しく話していただきたかった。
●各モデルの具体的な書き方についての説明がもう少し欲しかったです。説明がとてもわかりやすかったです。タスクも人も階層化する点については印象的でした。
●RDRAテンプレートは、とてもよいと思いました。EAとよくマッチしていると感じました。タイムボックス管理は調査してみたいと思いました。
●要件分析フレームワークがとてもわかりやすく整理されており、業務活用できそう。また、計画・管理の話題では、ガントチャートが前提としている事項が目からウロコ。良し悪しではなく、今まで気付かなかった事が分かってよかった。
●いつも要件定義で時間をとられるので、今回紹介いただいたような手法で、効率よく要件できれば、有効と思います。ぜひ実践してみます。失敗プロジェクト＝要件定義がうまくできていないことが多いので、失敗プロジェクト撲滅にも繋がると思います。

要件定義セミナー in 東京（オンサイト）アンケート結果（2009年11月26日）
アンケート回収数：６　　　
●いつも要件定義を進める中で感じていたモヤモヤに一つの答えをいただいた感じがしています。
決められた形式や固定概念にとらわれて、要件定義の本質的な目標と離れたところに時間と労力を費やしていたのではないか、と気付くことができました。要件に構造（枠組み）をつけて整理することを意識はしていましたが、具体的な手法を持っていなかったので思い通りにならなかった部分でした。今回のセミナーで具体的な手法を示していただいたので、是非実践したいと思います。また、タイムボックスを使用したスケジュール管理も新鮮で、今後実践してみようと思いました。お忙しい中、本当にありがとうございました。
●要件定義フェーズでガントチャートが役に立たないことを、ちゃんとその理由と代替策を持って説明されていることに感銘を受けました。このフェーズでもアジャイルを適用していく勇気が沸きました！
●前回拝聴した時よりも、時間に余裕があった事もあり、より具体的に説明して頂き、よく理解できました。参加メンバからも良い話が聞けたとの声が聞こえています。本当にありがとうございました。
●普段の要件定義のなかでは成果物を確認して合意(チーム内やユーザーと)することに意識がとられがちですが、その検討をチームで行って関係性を説明できるようにし下地を作り、それによりユーザーをリードしていくという考え方が斬新でした。
「UC&業務」などの普段の成果物を組み合わせた途中成果物は確かに普段各担当が成果物を作る再に頭の中で考えていることですが、それをきちんと見えるように定義していくのは今後実践してみたいと思います。
プロセスについてはやはり信頼がある状態で初めてユーザーにも展開していけるかと思います。まずはチーム内での進め方には適用してみたいと思います。ガントチャートとうまく組み合わせてプロセスを進めていく方法が模索できればと思います。
まずはEAのテンプレートを利用させていただきつつ、いつかは機能制限版でもいいのでRDRACheckerも公開されることを期待しています。
●哲学的なことではなく、実際に成果物に落とし込むまでの方法と目的がきけて非常に有意義でした。
実際に要件定義をかかわったことはないですが、担当するときはRDRAを試してみたいと思います。時間が経過するごとによりドキュメントが増え、システム全体が見えにくくなる。という印象がありましたが、EAを使うことにより各ダイアグラムでの関連させることにより、要求の実現ができているか？というチェックが見えやすくなり感心させられました。

●非常に有用なお話しを聞かせていただき感謝しています。ありがとうございました。
特に
・ UMLをそのままお客様との合意に利用しない
・ 要件定義をアジャイルに進める
という点に、非常に興味を持ちました。
 プロジェクトを前に進めようとする目的指向が全体のベースにあるのだと感じ、機会があればプロジェクトでも実践したいと思っています。
要件を引き出し顧客との合意を得るサイクルについて、機会があればさらに具体的なお話を伺いたいです。
本日は貴重なお話を聞かせていただき、ありがとうございました。

 

要件定義（RDRA)セミナー in 豆蔵　アンケート結果（2009年10月20日）
アンケート回収数：１０　　　公開可能コメント数：９

●要件定義の以下の進め方が役に立ちました。
　・最初は関係者全員でやって認識を合わせる。
　・ユーザヒアリングを行う前に、一度全体を作成する。
社内の標準プロセスとの対応付けが難しいような気がしました。

●時間が短かった。フレームワークよりプロセスを詳しく聞きたかったです。
●目新しい内容ではなかった。成果物の整理がされているのでわかりやすかった。
●標準化の逆を行くような現実的な話で面白かったです。
●いわゆる反復開発で使う時の利用法があると嬉しいです。ありがとうございました。
●事前に本を読んでいたので、内容は良く理解できました。資料にない話や事例が興味深く、役に立ちそうです。
●仮説のための要件定義が良いなと感じました。
●全体像がざっくり解り、整合性の確保を最重視した定義手法だということが良く理解できました。参考にさせていただきます。
●要件定義メンバーで1週間まず作るくだりが面白かったです。ややテストドリブンな香りがして納得感がありました。

 

要件定義セミナー in 岡山　アンケート結果（2009年8月1日）
アンケート回収数：２８　　　公開可能コメント数：９
●現場で行っている内容と異なる話もあり、今後の現場に今日の話が応用できるかを考えてみようと思った。

●もっと具体例が聞きたかった。
●先生の本を買ってよく読みたいと思いました。
●短時間ではあったが非常に有益であった。開発手法／顧客対応への大きな助力となります。ありがとうございました。 質問に対して非常に解りやすかった。
●スケジュールの考え方を詳細に聞きたい点がありました。要件定義は最初の工程なので考え方がよくわかりました。
●実業務に役立てれそうです。
●要件定義を4つの部分に分けるというのが、解りやすかった。
単独モデルのチェックではなく、関連でチェックするというのは確かに期待できた。
●RDRAの関係ダイアグラムの訓練（ドキュメント作成）－お客様へのヒアリングをする前に関係者でドキュメントをすべて書きましょうという部分－を１日の有料セミナーにするのであれば相当有効なものになりそうな気がします。 情報源など有益な情報が多く、参考になりました。

 

要件定義紹介セミナー in 東京　アンケート結果（2009年7月29日）
アンケート回収数：２６　　公開可能コメント数：５
●様々な視点から見たモデルを多数作成するということで、グラフィカルで分かりやすいと思います。一度、実践してみて感覚をつかんでみたいと思います。
●網羅性と整合性については良かった。
●予想よりも簡易に使えそうなフレームワークだと思いました。
●要件＊＊は、やってみないと実感がわかない。
●要件定義の分野では、新しい概念というか考え方があり、その点ではとても良いかと思いましたが、一般的な要件定義のイメージがあるため、世の中にどこまで受け入れられる考え方あるいはやり方を考えると、疑問符が浮かんできます。

 

要件定義セミナー in 札幌　アンケート結果（2009年7月10日）
●フレームワークの定義的な部分についてはとてもよくまとまっており、自分の経験と合わせて今後の業務に行かせると感じた。 反面、もう少し具体的な導入事例等の説明があればよかったように思う。
●参加者同士でワークショップをやるような形をやりたいですね。前半は本を読んでいる人にとってはやさしく、読んでない人には 難しいのでは？と思いました。慣れるためにも小規模な要件定義のワークショップをやりたいですね。有料でも参加します。
●要件定義のまとめ方（Framework）は有用だと思いました。気にかかるのは納品物としてのまとめ方でした。　 やはり、平文形式が求められる形なので。　今後、チームに広げていければと思っています。　ありがとうございました。
●社内で扱っている案件のほぼ100%近くの開発物（例えば、ECサイト、コンテンツ投稿サイト、携帯サイト）で、なかなか しっかりした上流行程することがなかったので、今後の開発に役立てればよいと思いました。　本日はありがとうございました。
●こういった上流行程のセミナーを受ける機会があまりなかったので、貴重な時間を過ごさせていただきました。
●非常に別な視点で考えることが出来るのではないかと思いました。
●要件定義マニュアルとEAをセットで使用（まだ活用できていませんが･･･）しています。 ドキュメントライブラリアンを配置もしくは担当しなくて済むので助かっています。
●有料セミナーの受講を検討したいですが、具体的な費用などの情報が欲しいと思いました。
●「本」で復習します。　タイムボックスにはスキルが必要なところをどうするか悩みますね。
●全体が体系化されていて、とてもわかりやすかったです。　ありがとうございます。
●目からウロコでした。　参加していない社内の人間にも聴講させたい内容でした。
●話は非常によく解ります。　ただ、どう実践したらよいか？がいつも悩みの種。 RDRAを使って確認してみたいので、有料セミナーも検討してみたいです。
●フレームワークもプロセスも、実際の業務で取り入れられたら面白そうだし、上手く出来たらスケジュールも要件定義も新鮮な形で モチベーション高く作業も出来そうだと思いました。　やってみたい！というのが感想です。

 

要件定義紹介セミナー in 東京　アンケート結果（2009年6月10日）

●書籍を購入して実作業の落とし込みを検討しています。重要事項が分かって良かった。
●UMLについてそれほど使いこなせていないので、内容は高度に感じましたが、面白かったです。
●具体的な要件を元にシステム価値からシステムを説明いただければもっとイメージしやすかった。
●もう少し、コンサルをしたときの事例を教えてほしかった。方法論はとてもわかりやすかった。
●非常に参考になりました。先日、来日したポッペンディーク夫妻もイテレーション、ふりかえり、などを話されていて、今回の話で良く分かりました。
●タイムボックスに関しては、発注がわのエンジニアであれば採用しやすいと思います。実際に開発で採用していました。逆に受注する立場では、提案しずらと思います。そのあたりの提案方法があれば・・。
●要件定義の進め方は、苦労しているので有意義でした。
●要件定義のプロセスと、工程管理の仕方、説明できることの重要性を理解できた。今回、講義いただいた内容が、どれくらいの規模のシステムまで適用可能か知りたい。
●プロセスに出てくるモデルの1つ1つについて、モデルを作る意味、目的をもう少し詳しく話していただきたかった。
●各モデルの具体的な書き方についての説明がもう少し欲しかったです。説明がとてもわかりやすかったです。タスクも人も階層化する点については印象的でした。
●RDRAテンプレートは、とてもよいと思いました。EAとよくマッチしていると感じました。タイムボックス管理は調査してみたいと思いました。
●要件分析フレームワークがとてもわかりやすく整理されており、業務活用できそう。また、計画・管理の話題では、ガントチャートが前提としている事項が目からウロコ。良し悪しではなく、今まで気付かなかった事が分かってよかった。
●いつも要件定義で時間をとられるので、今回紹介いただいたような手法で、効率よく要件できれば、有効と思います。ぜひ実践してみます。失敗プロジェクト＝要件定義がうまくできていないことが多いので、失敗プロジェクト撲滅にも繋がると思います。