PG日誌

読者です 読者をやめる 読者になる 読者になる

PG日誌

主にc#の事を書いています

エンドユーザーにUMLを使ってシステムを説明する


「顧客を議論に巻き込むためにUMLを使おう!」って相手がソフトの専門家でもないのによくやるなぁ、、、って思った話です。だいたい愚痴です。

もうUMLブームが去ったのではないかと疑うくらい、昨今は大体お客さんがUML知ってる確率って昨今かなり低下してます。もう大体知らない。知ってても間違ってる。みたいな状態が多いです。ソフト屋が良かれと思ってあの箱が線でつながった図に棒人間が書かれてると、本当に知らない人だと馬鹿にしてるのかと思われるケースすら微妙にあります。

そんな冷え切った状態でUMLを持ち出して専門用語を交えながらシステムを説明するってもうギャグの領域なんですよね。

そういう時相手は結構ストレスを感じるみたいでこんな反応になります。

  1. 呆然と立ち尽くす。口が若干開いている。
  2. 怒り出す。意味を説明しろ!など
  3. 無視する。

ソフト屋が描いた理想とは裏腹に、UMLはエンドユーザーとの約束にはほとんど役に立たないですね。もっと小ぎれいに飾ったパワポのほうが全然マシです。だからもしソフトの立ち入った話をしたいなら

  1. まずはリストで提示する。紙芝居でもよい。パワポ、エクセル方眼の利用も積極的に検討する
  2. 長大で理解し難いリストは"線"と"箱"のみによって表現する
  3. 4つ以上の関連は分割して表現する
  4. 各種条件は保険の契約書の様に小さい文字でびっしりと正しく書く

しかも相手がUMLを理解しないからと言って、心中でさえも顧客の事をバカ呼ばわりしないほうがいいです。十中八九、相手もこっちの事を対し業務を理解しようとしないバカが来たと思っているからです。全然建設的じゃないです。

技術者同士の場合、話は別です

個人的経験で言いますが、特に最近の業務系エンジニアは図を書かないですね。フローチャート、DFD、イベントフローは古いと言って書かず、UMLも書こうとしません。
完全に地図なしで航海に出てるようなものです。

もし書いたとしても、UMLへ独自の解釈を試みたり、不適切な場面で不適切な図を選択したり。そして誰にも通じない独自の記述法を開発し記述を試みたり結構ひどいです。最後にコード読めって、自分あなたのお母さんじゃないんです。

その独自形式の線と箱の意味をいちいち解き明かすような時間もないですし、意味不明のコードを読む時間も無いのです。

なので共通言語として、ぜひUMLを勉強してほしいですね。

その場でつかえる しっかり学べるUML2.0

その場でつかえる しっかり学べるUML2.0