生き残るために「要求エンジニアリング」を学ぶ：上を目指すエンジニアのための要求エンジニアリング入門（1）（1/3 ページ）

上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。

[前田卓雄，＠IT]

　2009年、世界経済にとって厳しい年を迎えた。IT／ソフトウェア業界においても、ほかの業界と同じく厳しい時代になるだろう。この業界ではコストの大半を固定費である人件費が占めており、経済環境の変化に対応する力が弱い。だから、経済環境がいっそう厳しくなれば、プロジェクト価格の低下はもちろん、プロジェクト件数も減少し、ベンダ間の競争が激化する。企業は利益を出すために――いや、企業を存続させるために、多かれ少なかれ人件費の削減、時間単価の切り下げや時間当たりの生産性向上、人員そのものの削減まで行うことになるだろう。

　これまでも海外の技術者に比べて日本のIT／ソフトウェア技術者はコスト高であったが、昨今の円高によって一層、高いものになっている。その結果、日本製のIT／ソフトウェアのコストが高くなり、ものづくりのグローバルな競争力を大きく低下させている。また、ITや情報システムの利用の仕方が企業の優劣を決定づける時代では、開発プロジェクトが高コストになれば、開発の受託企業だけでなく、発注側である一般ユーザー企業の競争力も減衰させていくことになる。こうした環境で働いている日本の技術者は、厳しい試練に立ち向かい、選別の時代を生き抜くための戦略の再構築を迫られている。

自分の強みと弱みを分析する

　こうした時代をどう生き抜けばよいのだろうか。＠IT自分戦略研究所の読者は、その豊富な情報を生かして自分なりの戦略を構築し、自己の能力や競争力の強化に向けて動いていることだろう。自分の貴重な時間を目標なく無駄に消費するか、それとも積極的に何かに投資するか、まさに「自分戦略」が問われている。

図1　自分の強みを強化し、弱みを減らす――SWOT分析
出典：『ビジネスの基本を知っているSEは必ず成功する』 p.23

　図1はSWOT分析（注1）を表したものである。自分の「強み」「弱み」を確認し、「強み」をいっそう強く、「弱み」を克服するための目標を明確にし、自分戦略を実行しなければならない。もしこうした戦略を実施しないのであれば、現状がどこまでしっかりしたものかを再確認すること、そして現状の後に自分を弱くする何かが続いていないかを問い直し、確固とした基盤の上で自己の強みが形成されていることを確認する必要があろう。

　グローバル競争の厳しいIT／ソフトウェア環境でも生き延びるための「したたかな」戦略目標を持ったとしても、一朝一夕で実現することはできない。だからこそ、余裕がある間にその戦略目標を追求し、後悔のない技術者人生を過ごすことが必要だ。幸いにも現代はインターネット時代。自己の成長につながる、さまざまな情報や材料がネットワーク上には豊富に存在し、いつでも利用できる。

（注1） SWOT（S：Strength、W：Weakness、O：Opportunity、T：Threat）　通常、SWOT分析は企業などの事業体の強み・弱み・機会・脅威を明らかにするために実行する。ここでは、自分自身を仕事をする事業体と考え、自分の内部にある「強み」「弱み」、自分を取り巻いている外部環境にある「機会」「脅威」を分析することである。
　分析した結果、「弱み」は自助努力によって「強み」に変え、「強み」をさらに強化する。それには何をどうすればよいか。また、「脅威」を減少あるいは回避し、「機会」を生かす、または増大させるにはどうすればよいかを検討し、実践していくことが必要である。

「自分の強み」にこれだけは加えたい「要求エンジニアリング」

　技術者の立場で仕事を形成するには、技術的な仕事を依頼されることが必要である。他方、依頼する側からすれば、実現したいことを技術者に伝えることが必要になる。依頼者の要求をはっきりさせ、作るべきものをはっきりさせる仕事が要求エンジニアリングの対象領域である。需要があって初めて仕事があり得るとすれば、要求エンジニアリングとはまさに、技術者の需要を生み出す部分である。

　要求はもともとあいまいなものである。しかし、どんなにあいまいなものでも、なければ仕事を形成できない、厄介な代物である。また、要求を発する人／状況は多様であり、はっきりするまで待つとしても、要求をはっきりさせるための働き掛けをしなければ、要求を正しくつかむことはできない。これではいつまでも開発という仕事に取り掛かれない。このように、要求は世話が焼ける面倒なものでもある。

　はっきりしたと思えたとしても、抜けや重なりなどが潜在して、本当の要求を理解するにはさらに努力が必要である。IT／ソフトウェアにかかわる技術の習得や、後述するバグ対応に追われている多くの技術者が、「要求」と真正面から向き合うことを後回しにしがちなのも、もっともであるといえる。

　しかし、それでよいのか。読者諸君の技術は、それを必要とする「需要」があってこそ。まず需要の中身である「要求」を確かめた方がよいのではないか。少なくとも、要求を確かなものにする術を習得して損はないであろう。

　以上の理由により、本連載は読者が「要求エンジニアリング」の知識・実践能力・コツなどを獲得し、「自分の強み」に加えることを強く勧める。