工夫と規律で「システム用語辞書」を実現せよ：ユーザーサイド・プロジェクト推進ガイド（18）（1/2 ページ）

ユーザー企業がシステムのために用語辞書を整備するのは、大変な困難が伴う。それを乗り越えるには、相応の工夫が必要だ。

[山村秀樹，＠IT]

　用語辞書の作成は“面倒くさい”作業です。その面倒以上のメリットを作成者自身が実感・享受できなければ、面倒くささゆえに手抜きが横行し、やがて用語辞書の作成は放棄されることになります。

　また単なる面倒さ以上の問題として、用語辞書の作成には膨大な時間とエネルギーが必要だということがあります。時間制約の厳しいプロジェクトでは、いくら用語辞書が有用なものであることが分かっていても、作成し切れないことがあります。

　そこで、用語辞書にはプロジェクト作業内においても有効に活用できるようにする“工夫”が必要になるのです。

用語辞書が作成、運用できない理由

　用語辞書を運用するうえで最も重要なことは、業務で使う用語はここに登録する──逆にいえば、ここに登録されていない用語をシステムで採用しないというルールを徹底することです。

　しかし、「自分たちで用語辞書を作って用語を統一しよう」と方針決定しても、いざ用語辞書を作る段になるとなかなかできない、あるいは苦労して作った用語辞書が使わないままといったケースは多いことでしょう。チームとして決定したことが、なし崩しに守られなくなるのです。

　その言い訳はいくつかあるでしょう。中には「もともと用語辞書の作成に反対していた。できもしないことをやりたがるやつらが決めた」という声もあるかもしれません。

　そうした人々は、どうして反対のマインドを持っているのでしょうか？ やはり大変そうだと思うのでしょう。用語辞書の作成が大変な作業であることは、未経験者でも容易に想像できます。

　まず、用語を洗い出す作業だけでも、かなりのボリュームになります。既存の画面や帳票、会話に出てくる用語をすべてチェックしなければなりません。それらの用語は事前に意図的な制限や命名規則がなければ、膨大な数になるでしょう。収集した用語を用語辞書に記載する際には、すでに洗い出し済みであるかどうかのチェックも行わなければなりません。

　また、機能要求仕様書などプロジェクトで使うドキュメントを作成する際にも、登録用語を使うように、絶えず用語辞書でチェックしなければなりません。思い付くままの言葉で書いていくことに比べれば、ストレスはかなり大きく、気の進まない作業であることは否めません。

　しかも、大変な思いをして用語辞書を作成し、機能要求仕様書などのドキュメントに正確に適用させようと努力しても、なかなかうまくいきません。プロジェクトには、見直し、考え直し、やり直しが付きものです。加えて用語の追加、変更、削除があれば、それに合わせて関係するドキュメントも改訂しなければなりません。その手間たるや相当なものです。慎重に作業しても間違ってしまうことはあり、そのときにリーダーから「慎重にやらなければダメじゃないか」と怒られてしまうと、やる気もなくなります。

　時間もかなり費やすことになります。用語を抜き出して、それを用語辞書へ入力するだけでもかなりの工数が必要です。その後、プロジェクトチーム内で用語の適否を検討して、用語辞書のたたき台を作成、続いて関係部署に説明し、検討や理解を求めなければなりません。ドキュメントが多いと、用語変更があった際の用語置き換え作業にも莫大な時間を取られます。

　ユーザーサイドのコア作業ともいえる業務プロセスに関する調査、検討、決定作業は、用語関連作業以上の時間を必要とします。プロジェクトが本格化すれば、これらの作業に向けて時間を確保しておかなければならず、用語辞書ばかりに執着することはできません。用語辞書に費やせる時間は、もともとの作業ボリュームから推定すれば、そんなに多くはないはずです。しかも、この連載で想定しているプロジェクトチームのように、管理部や総務課のようなほかの部／課の中に存在する場合、ルーチン作業を主とするほかのグループとの兼ね合いや上級職の無理解などで、時間を調達することは難しいのです。

　簡単にいってしまえば、用語辞書の作成は「作業の大変さ」のために、手を尽くすことができないのです。そして、目的はないがしろにされ、ユーザーサイドのプロジェクト作業という限定された範囲でコストとメリットが計られ、その結果、ユーザーサイドでできなくても仕方のない作業と位置付けられてしまいます。たとえ担当者が用語辞書の目的や効果をいったんは納得したとしても、あまりにも時間がかかったり、担当者自らがその作業の恩恵を感じられなかったりすれば、簡単に挫折してしまうのです。

　しかし、あえて強調するなら、用語辞書を作成できなかった時点で、そのプロジェクトの成功はおぼつかない──と考えてください。本来ならば、何とか時間を調達してでも用語辞書を完成させるべきです。そのためには工夫が必要です。

やらない理由より、やるための工夫を考えよう

　「決めたことを守る」ことは簡単なようで難しいものです。決めたことが守られないことは珍しいことではありません。あちこちの企業で、○○活動目標として「決めたことを守る風土づくり」が挙げられていたり、ルールとして「決めたことを守る」が挙げられていたりします。

　決めたことを守れない／守らない理由は何でしょうか。決定そのものを知らない、決定が実行不可能、決定が間違っている、別の決定と矛盾している、もっと良い案がある、決定の目的や理由が不明確あるいは納得できない、窮屈、面倒、手間暇コストが掛かる、そもそも仕事がつまらない……などなど、いろいろありそうです。

　いかに「決定だ」「ルールだ」といっても、もともと実行が困難で、かつ実行することによってほかの作業にしわ寄せがいくようでは、その実行は難しいものです。トートロジーのようですが、一言でいえば「難しいことを実行することは難しい」のです。

　しかし皆さんの身近にも、難しいことを簡単にやってしまう人はいるはずです。その人たちは、困難なことを実施するには工夫が必要であることを知っていて、そのノウハウを持ち、そして実際に行動しているのです。実行の難しい決定事項は、どうにかして、手間暇コストを掛けなくても円滑に実行できるように、相対的なレベルを変更しなければなりません。難しい作業をそのままにしていては、いつまでたっても難しいままです。

　要は工夫することです。成果物に対して工夫を付加するだけでなく、仕事のやり方を工夫します。本来、システム担当部署には、できそうに思えない相談を受け、できるように方策を考えて実施する習慣が備わっているはずです。それを自らの作業に適用します。

　さて、作業レベルを変更する即効的な手法としては、ツールの工夫や導入があります。以前は困難と思われていたことでも、いまでも困難なこととは限りません。特にコンピュータ関係ではいろいろと便利なツールが増えました。できないと思われていたことや面倒なことでも、ツールを利用すれば、それが何のこともなく可能な場合があります。

　とはいっても、ツールの導入に障壁があるのも事実です。技術に関するノウハウやアンテナを喪失していれば、まず製品を捜し出すこと自体が難しく、費用や操作の習熟に要する時間も問題になります。また、自分たちで作ろうとすると技術力が問題になります。

　そこで、見積要求仕様書（RFP）で作業の工夫やツールの提案を要求し、各ベンダから意見やアイデアを聞いて比較してみてはどうでしょうか。また、通常のベンダからの見積もりでは、用語辞書や業務プロセスフローチャートをベンダで作成することを前提にしていますが、これらをユーザー側で作成することを明確にし、その場合の見積金額とそうでない場合の金額を比較してみることも面白いと思います。用語辞書作成のメリットが明確になるかもしれません。