筆者が経営する会社に数年ぶりに新卒社員が入社した。我が社は小規模なITコンサルティング会社なので中途採用で入ってくるケースが多く、新卒社員用の研修カリキュラムが準備されているわけではない。そこで、筆者と数人の社員が分担して教育に当たることになった。

 まずはITの基礎をきちんと学ばせようと情報処理技術者試験の「ITパスポート」を受験させることを決め、市販の教材を使って教えることにした。そして事前に教材をチェックしておこうとぱらぱら斜め読みして、二つのことを感じた。

 一つは「さすがに25年もITの仕事をしていると、ITパスポートレベルのことはほとんど理解できる」。もう一つは「しかし、用語などは知らなかったり忘れていたりするもの、正しく使っていなかったものがいくつもある」ことだ。いまさらながら、人に教えることは自分の勉強にもなると再認識した。

 さて、新人教育のにわか先生をやっている中で、教えるのに一番苦労したのが、実は筆者がメインで仕事をしているマネジメントの領域だったという笑い話のようなことがあった。

 教材には「マネージメント」という章があり、この中でシステム企画と開発のプロセスを説明するのに、情報処理推進機構(IPA)が策定した「共通フレーム2007」(以下、共通フレーム)による定義が用いられていた。共通フレームにおけるソフトウエアライフサイクルの主なプロセスは、企画→要件定義→開発→運用→保守となる。このうち、要件定義プロセスと開発プロセスの部分の説明が少しばかりややこしいのである。その一例が「要件定義」という言葉が上記二つのプロセスの中で複数の用語に使われていることだ。「要件定義プロセス」と、開発プロセスの中の「システム要件定義」「ソフトウエア要件定義」の三つである。

 共通フレームでいう「要件定義プロセス」は、新たに構築したいシステムの仕様や業務、システム化の範囲などを決めるフェーズを指している。いわば、RFP(提案依頼書)に記載する内容を決めるフェーズである。

 一方、開発プロセスの中にある「システム要件定義」はIT業界で一般に「要件定義」と呼ばれるフェーズを指しているようだ。そして「ソフトウエア要件定義」は「利用者の視点から、ソフトウエアに必要な機能や能力、インタフェースを決定する」とある。つまり、基本設計や外部設計と呼ばれるフェーズを指している。

 この三つの「要件定義」の違いについて、筆者自身は作成側の意図や狙いを理解することはできた。だがこれを新卒社員に説明することは非常に難しく、苦労したのである。まずなんといっても同じ「要件定義」という言葉が3回も出てくること、そして上位概念のプロセス名と、そのプロセスとは別のプロセスの下位概念の中に二つも要件定義という言葉が入っていることだ。

 さらに言えばこの共通フレームの表現は、実際にはほとんど普及せず、現場の提案書や計画書で見ることはまれである。だから、教えていてどうしてもピンとこない。そもそも共通フレームは、ベンダーやユーザーがシステム構築プロジェクトで使う用語や意味を共通化する意図で作られたもの。しかし残念ながら、その試みは成功しているとは言い難いのが現実だろう。

 なぜ普及しないのかといえば、正確に表現することにこだわり過ぎて、分かりやすさや使いやすさへの配慮が今ひとつだからではないか。

 共通フレームのような「物差し」は、普及して使われないことにはどんなに良いものでも価値は発揮されない。それこそユーザビリティーの問題である。今のままだと、「試験勉強では『ソフトウエア要件定義』と覚えなさい。でも現場では『外部設計または基本設計』というからね」と教えざるを得ない。共通フレームの志は高いだけに、なんとももったいないことだ。

永井 昭弘(ながい あきひろ)
1963年東京都出身。イントリーグ代表取締役社長兼CEO、NPO法人全国異業種グループネットワークフォーラム(INF)副理事長。日本IBMの金融担当SEを経て、ベンチャー系ITコンサルのイントリーグに参画、96年社長に就任。多数のIT案件のコーディネーションおよびコンサルティング、RFP作成支援などを手掛ける。著書に「事例で学ぶRFP作成術実践マニュアル」「RFP&提案書完全マニュアル」(日経BP社)、