言葉の不統一がもたらす業務とシステムへの悪影響：ユーザーサイド・プロジェクト推進ガイド（16）（2/2 ページ）

[山村秀樹，＠IT]

用語が統一されていないシステムは手間が掛かる

　画面や帳票によって同じ項目を違う用語で表示したり、違う項目を同じ用語で表示しているシステムは、メンテナンス性に問題があります。

　システムにトラブルが発生すれば、状況を把握するために、どの画面でどのような入力をし、もしくはほかのシステムや設備から入力があり、どのような結果が出たのか調べます。画面や帳票の用語に一貫性がないシステムの場合、（トラブルに慣れることはいいことではありませんが）よっぽどトラブルに慣れていないと、この作業にてこずることになります。

　さらに、エンドユーザーなどの作業当事者が使う用語がシステムで使っている用語と違っているとなおさら面倒です。メンテナンス担当者はエンドユーザーから状況をヒアリングするわけですが、システムの画面や帳票にない用語で説明されると、経験の少ないメンテナンス担当者は、エンドユーザーのいっていることの理解に四苦八苦します。メンテナンス担当者はシステムを通じて業務を勉強していますが、それが通用しないのです。エンドユーザーに意味を1つ1つ確認しなければなりません。ときには、いらついたエンドユーザーから「こんなことも知らないのか」と怒鳴られます。

　コンピュータ・システムはいずれ更新の時期を迎えます。その際には、業務改革あるいは改善が検討されます。早いうちに用語を整理しておけば、次回のシステム更新時の調査が楽になります。しかし、用語の整理されてないシステムでは、再び時間をかけて用語を調べ直すことになります。大変な作業は繰り返したくないものです。

システム化は用語の統一を実現するチャンス

　これら用語に起因する無駄は、大きなロスとは気付かれていないのかもしれません。しかし、多くの企業が報奨金を出して改善提案活動をし、少しの無駄でも発見して省こうとしている中で、用語の整理（管理）がなされていないのは手抜かりの観があります。

　用語の整理は、業務効率に小さくはない効果をもたらします。内部統制は「ミスを犯さない、不正を犯すことのできないようにしなさい」ということですが、用語をしっかりと定義しておくことは、この観点からも重要なことです。

　これを実現するのにコンピュータ・システムの構築はいい機会です。

　用語の問題に気付くことができないのは、効率を職場単位でしか考えることがないからです。これでは前述したように慣れの問題と誤解されます。しかし、部門横断的なシステムを構築するためにキチンと業務調査をし、機能を実装することを考えれば、用語の混雑具合とその無駄さ加減を如実に思い知ることが出来ます。これは、ユーザーがベンダ任せにせずに業務を調査すべき大きな理由でもあります。

　そして、打ち合わせなどプロジェクトに直接かかわる人たちで問題意識を醸成し、システムには検討を経て統一された用語を採用するようにします。そのことによって、その用語がその企業における共通語であることをすべての業務従事者に認識するように仕向けます。

　それぞれの職場で独自の用語を使っていた人たちも、毎日使用するシステムが表示する画面や帳票の用語を見ているうちに、統一された用語を使うようになり、コミュニケーションが改善されます。

用語辞書はシステム開発の効率を向上する

　システムを開発する側にとっても、用語の混雑状態は業務を理解するうえで大きな障害です。その障害を乗り超えるには時間がかかります。少しでも効率よく作業を進めるツールが用語辞書です。なお、用語辞書が活躍するのはシステム開発の期間だけではありません。用語辞書はもっと長い寿命を持ちます。

　用語不統一の問題は、設計不備の原因となります。まったく違うと思っていた用語が同じことを示していたり、その逆に同じ用語で違う内容であったりすれば、設計をし直すことになります。

　戻り作業が発生すればスケジュールの遅延、コストの増大にかかわってきます。かといって、戻り作業を嫌って、修正を加えないと同じ意味なのに名称の違う項目が存在するクラスやテーブルとなって、後々のシステム改造の際に問題が発生する個所となります。

　これを防ぐために、ユーザー側のプロジェクトチーム自身が用語を把握することはもちろんのこと、ベンダにも業務で使われる用語を覚えてもらわなくてはなりません。もしかしたら、そのベンダは業界に精通しており用語に詳しいかもしれません。しかし、業界用語と実業務で使われている用語は同じとは限らないため、用語統一のフェイズは必須です。

　用語を整理・統一する作業は、ユーザーがあらかじめ行っておきます。その成果物が用語辞書です。ユーザーは用語辞書を使って、用語をベンダに説明します。ベンダにまずしっかりと用語を把握してもらうことは、作業準備期間を短縮するだけでなく、プロジェクトのあらゆる面で時間を節約します。

業務部門との打ち合わせをスムーズにする

　業務部門との打ち合わせの場を、ベンダの学習の場としてはいけません。ベンダが打ち合わせの前に、最低限必要な知識として用語と業務概要を修得しておくことは義務です。

　ベンダがヒアリングや打ち合わせなどで意味が分からず、聞き返したり、頭の中で「何のことだっけ」と戸惑っていたりしていては、時間がいくらあっても足りません。それでは貴重な時間を割いて、ヒアリングや打ち合わせに参加してくれた人たちに迷惑が掛かります。打ち合わせに参加してくれる人たちは、その職場のエース級の人たちで、ほかにいくつも仕事を抱えていて忙しいのです。

　業務部門内では、彼らエース級の人たちが、本来の仕事以外に時間を振り向けることは、もともと望ましく思われていません。打ち合わせに、あまりにも時間を取られてしまって本来の仕事がストップしては、プロジェクトへの協力を中止せざるを得ません。本人に協力する気があっても、周囲がそれを許してくれなくなるでしょう。初歩的な事柄に時間を消費する状態が続くと、真に大事な段階で協力を得ることが困難になります。

　次回は用語辞書の作成と運用について考察していきます。

筆者プロフィール

山村 秀樹（やまむら ひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

• 業務の可視化で、多くの関係者を巻き込め！
• 工夫と規律で「システム用語辞書」を実現せよ
• 社内用語を統一する「用語辞典」作成のポイント
• 言葉の不統一がもたらす業務とシステムへの悪影響
• ドキュメントを作成しないユーザーは、失敗する
• プロジェクトメンバーがそろう前に行っておく事前準備
• システム開発プロジェクトの魅力を伝えよう
• プロジェクトチームのマインドとルールを方向づけるには
• プロジェクトキックオフ！ オリエンテーションで話すこと
• プロジェクトリーダーは十二分な準備で自信を生み出せ
• プロジェクトチームのリーダーに向く人、向かない人
• プロジェクトチームにおける“システム担当者”の役割
• プロジェクトチーム結成──業務部門との関係を考える
• プロジェクトチームに付きまとう制約を打破するために
• タイプ別プロジェクトチームの問題点
• 不良システムを作らないプロジェクトの枠組み
• スケジュールとコストは、ユーザー側が始めからつかめ
• 最初が大切──構築システムの“概要”を作る
• ユーザー企業側プロジェクトチームの使命と役割