要求開発アライアンスで合宿を行いました

またもや更新間隔が空いてしまいましたが、先日金曜日の夜から翌日の昼まで、都内某所のホテルのカンファレンスルームを利用した合宿形式の勉強会に参加(?)してきました。要求開発アライアンス「要求開発　実践からのフィードバック」というタイトルです。というわけで、記憶が薄れる前にレポートします。

■基調講演「開発上流工程の歩き方」
春から新たに要求開発アライアンスの理事として参加いただいた中山さんの発表です。ユーザ企業のシステム部門の目からみた上流工程に関するお話です。ベンダ企業に勤める私としても、とても参考となるお話がたくさんありました。
なお、着色している部分は私の個人的な感想ですのでご注意ください。

• ほとんどウォーターフォール(WF)は採用していない。
• 開発はRUP風(?)に、「準備」「方向付け」「推敲」「作成」「移行」の5つのフェーズに分けられているとのこと(反復型開発)。
• 確かに、開発ベンダから見ればWFは御しやすく、いろいろと都合の良い(契約や、コスト・仕様変更などの取扱い)のですが、ユーザ企業の観点からすると当然だと思います。その割には世の中的にはWF型のプロジェクトが多いのはなぜなんだろう･･･
• ポリシーとして「プロジェクトサイズ」をコントロールする。
• プロジェクト期間は12ヶ月以内と制限しているそうです。これは、大規模プロジェクト化した場合のリスク対策に加えて、技術進歩や世の中のスピードへの対策としてとのこと。
• 超えてしまう場合は次フェーズに見送るということです。
• 情報システム部門の役割
• ユーザ部門と、ベンダの間のメッセンジャーではない。
• 企画・設計を行う。
• 手段は「モデリング」である。
• 新システムの前提
• 単純コンバージョンのシステム更改を除き、ポリシーを決めている。
• 業務のBPRや組織改革を伴わなければいけない。
• 新たなITを取り入れたものでなければいけない。
• このビジョンは、わかりやすさと明確さでちょっと感動した。
• テスト駆動
• 情報システム部門としては、コードや設計レビューの実施は現実的では無い。その代わりにプロジェクト初期からテストデータ作成に参加し、実業務に近いINデータとOUTデータによってシステム検証に参加する。
• スケジュール管理
• 遅れが2週間を超えた時点で再スケジューリングを実施。
• 再スケジュールは科学的根拠に基づく次工程移行の短縮による。
• あたりまえなのですが、それをやっているということ、およびユーザ企業の方から聞けるということにクラッとしてしまった･･･。

他にもいろいろな気づきやヒントをいただける講演でした。内容そのものもそうですが、全体的にはシステム部門としてのポリシーやビジョンがハッキリとしている事に感動を覚えました。あたりまえですが、ユーザ企業は「システムを導入すること」が目的ではなく、「システムを使ってビジネスで成功すること」が目的です。しかし、プロジェクトが開始されると参加者の目標が「システムを導入すること」に摩り替わってしまい、結果として使えないシステムや使いにくいシステムが生まれる原因になりがちです。これに対する対策として、まずポリシーとビジョンをしっかりと定めるというのが、とても効果的だというのが感想です。

■その後
1日目は基調講演後、ホテルのパーティルームでの反省会、居酒屋に移動しての猛省会、そして……という感じでした。私は普段は自宅が遠い為に途中で失礼することが多いのですが、この日はホテル泊なので時間を気にする必要が無い！ というわけで、とてもリラックスして参加できたのが良かった……

長くなりそうなので、合宿2日目のレポートは次回にまわします。翌日は9時からワークショップを2セッションです。