要求定義の手法を見直す動きが活発になってきた。これまでの開発者視点の手法では，社外ユーザー向けのシステムなどが開発しづらくなってきたからだ。旧来の手法で無理に進めれば，使われないシステムや赤字プロジェクトが増すばかり。要求工学，ユーザー中心設計，超上流など，システマティックな手法を取り入れ，いち早く要求定義の問題解決に挑んだ現場から，実践のノウハウを探った。 「システムの利用目的や対象ユーザーが大きく変わった。要求定義の認識を改める必要がある」──。30年間にわたり，情報システム部門，ユーザー，ベンダーと立場を変えながら金融システム開発の現場に携わってきたアイネスの菊島靖弘氏（金融システム本部 副本部長）は，こう警鐘を鳴らす。 帳票作成などの定型業務をシステム化していた時代，システムの利用ユーザーは発注者そのものであり，きちんと要求を語ることができた。ところが「Webシステム全盛の今は，社

文・高畑　和弥（日立総合計画研究所電子政府プロジェクト・リーダー） WBS（Work Breakdown Structure）とは、プロジェクトで実施する作業を細分化し、階層構造で示した表のことです（表）。プロジェクトの工数をより正確に見積もると同時に、プロジェクトの対象範囲を厳密に定義することを目的に作成します。 WBSの作成は、プロジェクト管理全体の基盤となる活動といえます。というのも、WBSを作成して見積もった工数は、進ちょく管理やコスト管理、人員配分計画を決める際の基本的なデータとして利用されることが多いからです。下の表は、最もベーシックな設計･開発段階のWBSです。これに、担当者名や予定した工数、実際に終わった工数、作業中かどうかなどの状態を書き加えて利用します。 WBSを作成するメリットは、大きく2点あります。一つは、作業の抜けや重複を防ぐことが可能となり、工数の見積もりや進ち

システム構築の現場では，ユーザーと開発者による何回もの打ち合わせを経てシステムを実装しているはず。しかしながら，設計書の段階では目に見えなかったシステムが，工程が進むにつれて形になってくると，ユーザー側で「これは言っていた仕様と違うのでは？」という認識のギャップがよく発生する。 設計書は膨大な量になることが多い。開発者は仕様を凍結する際に，仕様全体を説明しなければならないが，「残された時間が少ないときなどは，設計書をすみずみまで説明するのは難しい。ユーザーにとって業務上インパクトの大きい部分だけを説明することがどうしてもある」（あるベンダーの開発者）。しかも，仕様凍結時に説明していない部分は，それまでの話し合いで合意しているから大丈夫だろうと考える。こうして開発工程が進んでいくと，「言った，言わない」というトラブルが発生しやすい。 小刻みにレビューを受ける こうした問題を完全に防ぐのは難し