要求開発アライアンス合宿レポート その２
というわけで、前回に引続き先日行った、要求開発アライアンスの勉強会合宿「要求開発 実践からのフィードバック」のレポートです。個人的なメモも兼ねているので、一部わけわかんなかったらごめんなさい。2日間の合宿の1日目のレポートはこちらです。
さて、前日の講演と宴会(反省会・猛省会)が終わった後ホテルに帰ったのは午前3時orz...。ギリギリまで寝て、翌朝バイキング形式の朝食を済ませた後、さっそくのワークショップです。
■ワークショップ１『要求不在自慢 ～「失敗に学ぶ、要求開発実践のためのポイント」』
要求開発アライアンス理事の細川さんによるプレゼンテーションとラウンドテーブルです。
私はまだ味読なのですが、「失敗学」を参考に、特に上流工程における失敗についての対策を考察するという筋立てで、参加者によるディスカッションをしました。細かい内容は非常にナマナマしいのでご紹介できないのですが、いろいろと興味深いキーワードも沢山出ました。以下メモです。
- 日本のITにおけるユーザ「没」主体と業界構造
- 米国では、ユーザ企業の役割として「CIO」「アーキテクト」「PM」「専門技術者」がいて、これを支援する形で外部のベンダーや専門家・海外技術者が参加するというプロジェクト形態となっている。
- 日本では、ユーザ企業の役割は未分化で、「CIO」もいない場合が多く、また情報システム部門が曖昧に「アーキテクト」「PM」「専門技術者」の役割を担っている。そして、外部のベンダーが対応して二次請けとしてソフトウェアハウスや海外技術者を利用するという、多段構造になっている。
- 日本の「総合的なIT投資意欲」の低さ
- ITへの投資額などは大きいが、CIO設置比率や経営陣のIT重要性理解、攻めのIT投資など総合的に比較すると、海外に比べて非常にランキングが低い。(ガートナー 2007/5)
- 日本人は「失敗を受け入れ難い」(?)
- 本来はデジタルに「成功」「失敗」が決まるわけではない。「失敗」ではなく「10%成功」「30%成功」という状況を受け入れて、より成功するための戦略を。
- うまくいかないパターン
- 要求不在
- ビジネス目的と関係の無いゴールがあらかじめ設定されている
- ステークホルダー不在(肝心な利害関係者がプロジェクトにいない)
- フォーマルな開発方法論の適用やコタツモデルの導入で失敗を防止
- 要求発掘(要求考古学)
- 最近増えて来ているシステム更改では、要求を定義したり開発をするのではなく、考古学的に発掘しなければならない事がある。
- 仕様書がない、とか
- 仕様変更の繰り返しの結果、当初の目的が失われている、とか
- 面倒になって、全てを移植しても、実際には使われない、とか
- 非常に困難そして非効率。
- 別のアプローチの検討が必要
なお、同じ時間には別の部屋でもセッションが行われています。『布教の時間：～ビジネスモデリングの有効性：価値のある見える化に向けて～』『おまかせ隊長！よだばなし』全部に参加できないのが残念です。
■ワークショップ２『実演ライブ！ 要求分析ツリーがみるみるできる』
続いてのセッションは、要求開発アライアンス理事長の山岸さんの実演ライブ。要求分析ツリーの作成を、コンサルタントとユーザ企業担当者の掛け合いロールプレイで実際にやってみるというものです。個人的にはトークの流れや質問の仕方について非常に刺激になりました。また、要求分析ツリーは適当なツールが無いのが悩みで、ExcelやPowerPointを活用していたのですが、ここではJUDEのアクティビティ図を使って作成していました。なるほど！
このセッションもあっという間に時間が尽きてしまいました。別の部屋では『ハッピー！ホッピー！TFP！』『体験！君がオブジェクトだ！』というセッションが行われていましたが、これも超気になります。
ここでだいたい12時です。最後にクロージングミーティングを全員で行って合宿は終了。睡眠不足気味ですが、非常に充実した2日間となりました。
0 件のコメント:
コメントを投稿