一つ前のエントリーWhatを列挙するときにHowを列挙すべきでないをあんなに長々書いたのは、実は研究室で学生に教えているときの悩みがやっと解決されたため。悩みとは「私が要求分析と機能定義として学生に教えていることは、企業ではまったく役に立たない話なのではないか」というもの。この悩みは、5年前に学生から言われた言葉から始まった。
私の所属研究室では、ソフトウェア開発系の論文を書くことが多い。どういう内容の論文を出すかというとすごく簡単にまとめると「こういうソフトウェアがあるべきだよね。」というもの。現実世界で解決すべき問題を設定し、その問題を解決／緩和するためのソフトウェアの要求と機能を列挙し、定義した機能に基づきそのソフトウェアのアーキテクチャ（かなり抽象度が高い状態でのもの）を提案し、そのアーキテクチャを持ったソフトウェアの実現について論じる、あるいはプロトタイプを作って、ソフトウェアの有用性を論じるというスタイルの論文。雑誌に掲載するのは難しいけれども、IEEE-CS出版から会議録がでる程度の国際会議やSpringerの出している会議録シリーズLecture Note in Computer Scienceで会議録がでる程度の国際会議ならば通る（もちろん、会議の趣旨にかなり依存する）。
このときに重要なのが、みんなが確かに開発すべきだと思うソフトウェアを提案することと、現在の技術や先行研究の成果とその理想的なソフトウェアの間にギャップが広く開いていることを見せることだ。そもそも「そんなソフトウェア不要だよね」と思われたら当然ダメ。現在の技術と理想的なソフトウェアの間にギャップがないならば、さっさと作りあげてみせないと価値がないし、たぶん、どこかの企業が既にそれを開発して売っている。ギャップが広ければ広いほど、難しいテーマとなる。うちのボスの口癖だけど「難しいから研究として価値があると評価される。簡単ならば誰も評価しない」。なので、私は学生に要求分析のときには「利用者の視点から、そのソフトウェアが満たさなければならない条件を列挙しなさい」、機能定義のときには「開発者の視点から、列挙された要求をどうやって満たすのかを列挙しなさい」と教え、実際にやらせている。
前フリが長くなったけど、論文にするぐらいだから、理想的なソフトウェアの実現と現在の技術の間にはギャップがあり今すぐ埋められない。そのときに学生に言われたのが「いくら、そのソフトウェアが必要だったとしても、それが実現できないならば要求分析や機能定義をしても何の意味もないじゃないですか！」というもの。論文を書かせるために「研究と企業のソフトウェア開発は違う」と説明して、研究を続けさせたけど、どうにもうまく説明した気がしなかった（実際に、「どう違うのか」を説明していないし）。
で、先ほどのエントリー「Whatを列挙するときにHowを列挙すべきでない」につながる。そして、この考えがまとまって、やっと「必要だけれども、今は実現できないソフトウェアの要求分析や機能定義」にも価値があるということを自分の言葉で伝えられるようになった。利潤を追求し、製品を実現させてみなければならないという制限がある企業ですら「HowにとらわれないWhatの列挙をできる人材」を求めている。まさに今現在私が教えている要求分析と機能定義の考え方は学生をそのような人材にする（人材になるきっかけを与える）ことだ。
もちろん、私が教えているのは自己流の話なので洗練されていないだろうし、企業の現場に入ってすぐに役立てられるものじゃないだろう。でも、考え方の本質的な点はとらえられているはず。
以上、5年間の悩みがとりあえず晴れたのでながながと書いてみた。さて、今度、時間を見つけてシステム工学と要求工学を勉強しよう
