要求定義というと，ヒアリングのやり方などユーザーの要求の把握の仕方/整理法やまとめかた，ドキュメントの手法などが話題になりがちで，マネジメントのあり方について議論されることはあまりないように思います。しかし，要求定義がシステム構築プロジェクトにおける工程のひとつであるという視点に立ってみると，要求定義に関するマネジメントのあり方にもいろいろと考えなければならないことに気づきます。

　プロジェクト・リーダーやさらにその上で統括的なマネジメント・コントロールを行うマネージャは一体どんな行動を心がけ，またどんな行動は慎んだらよいのでしょうか。

　ある基幹系システム構築のプロジェクトでこんなことが起きました。要求定義を進めてゆくうちに「どうもこれは当初出した見積もりよりも大きな開発規模なるかもしれない」と思った受注側の統括マネージャが，急遽介入してきたのです。それは全く唐突にスケジュールを変更したい，というものでした。

　プロジェクト・ミーティングでは，もっぱらそのマネージャが取り仕切ってユーザー側に向かって声高に問題を指摘します。一方，要求定義を推進しているチーム・リーダーや現場のエンジニアは終始下を向いていました。脇で話を聞いていた営業担当者も，居心地が悪そうでした。発注者であるユーザー側は，明らかに腹を立てていました。

　開発規模が見積もりで提示した規模を超えてしまうという懸念を否定するつもりはありませんが，この時の統括マネージャの介入の仕方には疑問が残ります。当事者達の士気がそがれ，発注側・受注側双方の担当チームのモラルが一気にダウンした上に，以後，スムーズなコミュニケーションができなくなってしまいました。

　システム構築プロジェクトの多くは，ユーザーである顧客側と，受注したメーカーやSIベンダーによって構成されます。このような構造のプロジェクトでは，発注側の立場と受注側の立場の葛藤や争い，駆け引きが生じやすいわけですが，マネジメントは双方の利害を代表して互いに相譲らず，という場面も少なからず生じます。

　一方，現場で要求定義を推進しているチーム・リーダーや担当者は，双方の異なる立場や利害関係をわきまえつつ，それ以上に良いシステムをつくるという目的を共有し合っています。互いに良い結果を出したい，という点では利害は共通しており，だからこそ毎日顔を突きあわせて遅くまで頑張れるのです。

　プロジェクトがおかしくなるきっかけの多くは，場面にそぐわないマネジメントの介入が原因のように思います。組織におけるパワー関係を考えると，現場は本心に反しても黙って上司の言うとおりに行動しなければならないのが普通です。だからこそ，双方のマネジメントには状況にフィットした言動が要求されるのではないでしょうか。

　要求定義は，あいまいさの度合いが高い工程です。開発するかしないかにかかわらずかなり広い範囲の問題について取り上げ，検討しなければなりません。また，双方の自由でオープンなコミュニケーションとアイデアの創出も要求されます。しかし，ここ数年のSIベンダー側の行動には，リスクに対する過剰反応としか思えない行動が目立つようになりましたし，一方で，発注側のマネジメントにおける業者を見下したような態度や要求の無理強いが相変わらず見受けられます。どちらの態度も，現場にとってははなはだ迷惑なものである，という認識を持って欲しいと思います。

　このような問題が生じた時は，双方の現場同士は総論的なレベルで議論しないで，一つ一つの具体的なテーマを取り上げて議論することをお勧めします。話題が具体性を持てば持つほど，前向きなアイデアが出やすいですが，総論で争うとほぼ確実に議論は平行線になってしまうからです。

●編集部からのお知らせ 木村哲氏による書籍「本当に使える要求定義」を発売しました。このブログの1回目を執筆中にゲラのチェックをしていると紹介されたものです。要求定義にまつわるエピソードはもちろん，成果物のサンプルやプロセスマップなど実践的なノウハウが満載です。要求定義に苦労している人や自分のやり方が正しいかどうか知りたい人は，是非こちらをご覧ください。