「システムの仕様が決めきれない」「仕様変更が多発して，開発が追いつかない」・・・日経オープンシステム4月号の特集「仕様変更に打ち勝つ」を企画したのは，読者の間でこのような問題意識が高まってきたからだった。

　冒頭に紹介した声は，2001年10月に同誌が読者調査「企業情報システム実態調査2001年版」を行った際，ユーザー，インテグレータを問わず目に付いた意見だった。集計結果を見ても，「システム構築において問題が多い部分」として「システムの設計」との回答が26.3%で，「プロジェクトの体制」と並んでトップである。改めてシステム構築の上流工程を詰めることの難しさが浮き彫りになった。

　仕様を決め，それを揺らさずにプロジェクトを乗り切るには，従来から高いスキルが要求される。さらに，ここにきて難易度を高める新たな課題が加わってきた。それは，(1)開発期間の短期化，(2)開発・運用してみなければ仕様が決まらない業務案件の増加，(3)ビジネス環境の変化など外的要因で変更せざるを得ない仕様への対応，の3つである。

　こうした課題に対処するための工夫やノウハウは，冒頭の特集記事の中で，事例を交えて詳しく紹介したのでぜひご参照いただきたい。ここでは，筆者が特集の企画・取材をしながら考えてきたこと，特集で書いた工夫やノウハウを成功させる大前提として必要だと思っていること，など，特集ではあまり触れなかったことを書かせていただきたい。

　多くの読者の方には“当たり前”のことかもしれない。だが，その当たり前のことを，もう一度確認しておきたいと思っている。

ユーザーが“育つ”のを支援するのもSEの仕事のうち

　開発期間の短期化，変更理由の多様化が進んできた今，「仕様に入れるか，落とすか」「変更に対応するか，否か」を，これまで以上に正確に判断することが求められてきた。これを実現するには，システムの“使い手”であるユーザーと“作り手”であるSEの間でいかに仕様に合意するか，という根本的な課題に立ち戻る必要がある。

　ユーザーは業務を語り，SEは技術を語る・・・。この言葉の壁が仕様への合意を難しくしていることは，昔も今も変わらない。この壁を乗り越えるためのアプローチは，多くの場合，SE側が行ってきた。筆者は十数年前，あるインテグレータの新人SEだった。その当時から5年前に記者に身を転じて今に至るまで，「SEには業務知識が不可欠」というのは，何度も耳にした言葉だった。

　SEが業務の内容やその優先度を知ることは，システムを作るために当然必要なことである。ただ，それだけでユーザーとうまく合意できるわけではない。業務をシステムの言葉に置き換えた設計書の妥当性は，最終的にはユーザーが主体的に判断しなければならない。

　SEが業務知識を学ぶのと同時に，ユーザーにはもっと自分が使うシステムや情報技術をきちんと知ってほしい。これが筆者の意見である。何も，データベースの仕組みやオブジェクト指向のソフト開発，あるいはJavaなどの言語を，SEと同じレベルで理解してほしい，と言っているわけではない。仕事に必要な機能がきちんとシステムに盛り込まれているか，を自らの責任できちんと判断できるようになってもらいたいのだ。

　そして，そのようにユーザーが“育つ”のを支援する。これもSEの重要な仕事だと思う。

　最初のうちは，システムの内容を，業務の言葉に置き換えてSEが説明する必要がある。例えば，UML(Unified Modeling Language，[用語解説])で顧客が商品を発注するクラス図を書いたとしよう。SEは，「ひとりの顧客は複数の注文を出し，次に・・・」のように読み解いていく。この作業を繰り返していくことで，ユーザーにも矢印の意味や多重度の見方などが分かってくるだろう。

NOと言える信頼関係を築く

　開発途中で発生する変更要求への対応でも，SEがうまくユーザーをリードする必要がある。変更の内容は，機能の改善や追加，レア・ケースへの対応，ユーザーの“趣味”や“気まぐれ”，バグへの対応など様々だ。

　もちろん，その中には，冒頭にあげた(2)，(3)など，やむを得ない変更要求もあるし，仕様が変わること自体，必ずしも悪いこととは言えない。今日では，時代の変化とともに柔軟に変化・進化できることも，システムに求められる価値となっている。従ってSEには，オブジェクト指向技術の採用など，柔軟な変更に耐え得るシステム基盤を整備する必要がある。

　だが，ユーザーからの不合理な仕様変更の要求には，あえて「NO」と言うことも必要だ。稼働期日の遅延やプログラム品質の低下を引き起こすリスクが高まることをきちんと説明した上で，そのような変更が結局はユーザーにとって不利益をもたらすことを，SEはもっと勇気を持ってアピールすべきではないだろうか。
　
　それでも，“お客様”であるユーザーに押し切られるケースが多いという現実は分かっている。しかし，ユーザー自らがシステム構築におけるリスクやコストに無関心であれば，使い手にとってベストなシステムが作れるはずがない。このような意識を高めるために，SEはもっと“ユーザーを育てる”ことに力を入れてもよい。

　「ユーザーにNOと言う」「ユーザーを育てる」など傲慢だ，とお感じになるかもしれない。「それを言うならまず，SE自身がもっと力をつけろ」，と。

　もちろん，その通りである。なんでも「できません」「無理です」と言えばよい，ということではない。本当に「NO」と言うのは，SE自身が常に自らを高める努力をし，“システムのプロ”としてユーザーからの信頼を勝ち取っていてこそできることである。

　「育てる」のも一方通行ではない。ユーザーはその道のプロなのだから，SEもまた，ユーザーに育てられることを忘れてはならない。突き詰めれば，業務のプロであるユーザーと，システムのプロであるSEがお互いをプロとして認め，“育てあう”信頼関係を築くことが重要だと思う。“お客様”と“業者”の関係ではだめだ，ということだ。

　「NO」と言える信頼関係の上で，SEがユーザーを“育てる”。そうしなければ，“予算を付けて丸投げすればシステムができる”という考えで臨むユーザーは減らない。むやみに仕様を膨らませる，あるいは安易に仕様変更することは，無駄遣いであることにユーザーは気付いてほしい。

　SEがユーザーに歩み寄る姿勢は，これまでと変わらず大切だ。そのなかで，ユーザー・サイドのITに対する意識を変えるという，SEにしかできない役割をもっと強調してもよいと思う。劇的に変えることは難しいが，結局はそれがSEとユーザー双方のためになる。

（森山　徹＝日経オープンシステム副編集長）