要件定義コミュニティコミュの要件定義セミナー：プロセス編 in 大阪　終了

昨日無事に大阪での第２回目のセミナーが終わりました。

日曜日にも関わらず前回同様セミナールームがほぼ満杯になり、参加して頂いた方には大変感謝しています。

また、懇親会ではお酒が入り本音ベースで話ができたので、普段なかなか聞けない生々しい話も聞けて楽しい時間が過ごせました。

折角平さんが開設してくれたのでRDRAでの質問をこの場に投げてもらえると私の分かる範囲でお答えさせて頂きたいと思います。

それではよろしくお願いします。

コメント(3)

最初
全て
最新の40件

[1] mixiユーザー 03月17日 07:11

第１回目、第２回目共に、有意義な内容でいくつかの内容は、
実際の現場で実践して効果がありました。
（現在進行中のＰｒｏｊｅｃｔ受注できました）
ほんとに、ありがとうございます！

さて、さっそく質問です。
第２回目の内容で、スケジュール管理について話がありましたが、
「マイルストーンは状態として共有する」
ですが、第１回目にも、お話があったと思いますが、
どうも、この状態と言うのが、私の中で消化できていなくて。。。
例えば、大日程で、ウォーターフォール型のスケジュールが
ざっくりと決まっていて、その中の要件定義のフェーズであると仮定します。
要件定義では、なんとなく、あるテーマについて業務システムを構築する
との課題があり、それを要件定義しなければならない。
そして、政治的な理由のみの期日が決まっており、
その場合のマイルストーン、状態の設定とは、
どの様な事になるのでしょうか？
よろしくお願いします。

追記：
次回３回目も、楽しみにしています！
書籍サイン、Ｎｏ２の森。

[2] mixiユーザー 03月18日 00:02

masaoBearさん

２回の参加ありがとうございます。
RDRAが受注に少しでも貢献できたとすればとてもうれしいことです。
セミナーを開いた甲斐がありました。

さて質問の件ですが、状態で捉えるというのは選択肢を広げることと、次のアクションをとれるようにするためです。

通常ウォーターフォール型のマイルストーンでは工程の切れ目にいれるのが普通だと思います。

そしてこの場合マイルストーンは成果物の完成をもってその工程を終わる　という形ではないでしょうか。

これは成果物が出来ることで次の何かにつなげられるから成果物を作っているわけです。

つまり、その何かにつなげることがそのマイルストーンの目的と考えることができます。

そこで以下のようなことを考えるとどうでしょう。

　成果物ができることで何を達成した状態になるのか？

　その状態になることで次のマイルストーンでは何ができるのか？

こうして考えると重要なのは次につなげられる状態になることで、成果物を作ることではない　ということになります。

先に状態で捉えると選択しが広がると言ったのは正にこの点です。

つまり、成果物をマイルストーンのゴールにしてしまうと、その成果物ができないとダメだ　となります。

しかし、状態で捉えると、次につながれば必ずしも成果物が全て出来ていなくてもいい　ということになります。

マイルストーンとして決めた状態が実現できれば何をしてもいいことになるので、プロジェクトを取り巻く様々な状況に対処しやすくなります。

重要なことはプロジェクトの状況が変化するなかで柔軟にその状況に対応することです。

そのためにも絶えず選択肢の多い方法でプロジェクトを管理する方が成果物を決めて管理するよりも変化の激しい環境では有利ではないかという考え方です。

当然、状態で管理するということはゴールが曖昧になる可能性があるので、日々の管理は大変になります。

このように考えて状態として管理することを提案しました。

[3] mixiユーザー 03月18日 01:48

ご回答ありがとうございます。

なるほど、確かにマイルストーンは工程やフェーズの切れ目に設定しがちですよね、
要件定義を進めるにあたっては、なんとなくのゴール設定、
又は、方向性すら決まっていない状態で、そもそも、切れ目なんか、設定しにくいですよね。
今までＰＧや設計をメインにしてきたので、
どうもまだ、実装フェーズでのスケジューリングが頭から離れなくて、
自分の中でもう少しパラダイムシフトが必要だと感じています。
これだ！と言うのはまだわかっていませんが、
少なくとも、状態で捉えるメリットがわかったので、スッキリです。
次の機会で「状態で捉える」を実践してみようと思います。

ありがとうございました！

ログインすると、みんなのコメントがもっと見れるよ