見える化

情報分野に関する委員会のメンバーに選ばれ、２回目の会議に参加してきた。
Webプログラミングに関するものですが、正直、プログラミングは面倒でとっつきにくい。

今回は何をするのだろうと、少々不安を抱えながら会場へ向かった。
IBMの元社員の方で、現在はNPO法人ですごいプロジェクトを進めてみえる方やベンチャー企業の社長さん（私より歳は一つ上）の貴重な話を聞くことができた。

今回のお話で特に興味深いのは「UML」である。

なんやそれ？
「統一モデリング言語」と訳されるのかな。世界で標準化されたドキュメント（書類）の表記法のことです。

お客さんの「やりたいこと」「ほしいもの」など要求を「形」にする時、文書で書くとあいまいに表記されることが多い。
例えば「モダン」な感じとか「使いやすい」とか、それはイメージであってどうにでもとれます。
文書の書き方によっては人によって捉え方も変わり、それがゆくゆく「こんなはずじゃなかった」とお互いに問題になる種になるわけです。

それを誰もがわかるように図示して表記していくこと。

家作りに置き換えてみてもわかりやすいと思いますよ。

「どんな家を作りたいか」と聞かれても、はっきりと詳細に、誰もが間違わないように要求を伝えることは難しいですよね。そもそも専門的な知識はないのですから...。
それはメーカーからみても同じでしょう。100％クライアントが商品を理解できているなんてことありえまるでしょうか。

家作りの時、たくさんの図面や仕様書を見せていただきながら打ち合わせをしていきますが、業界の人しかわからないものも少なくありません。
大切なのは、上流の行程で（はじめに）クライアントからもメーカーからも、誰がみても理解しやすい形でドキュメント化することが大切だということです。UMLのドキュメントの表記法は世界標準ですから、アメリカでもインドでも同じ解釈ができるものです。
会社で都合のよいように独自に作成された仕様書では、クライアントはもとより業界の人でも間違いがおきる可能性が高いですよね。

（事実として、そいうったことが原因で「無駄」が生じたことは少なくなかったと思います。）

ITの世界のプログラミングと従来の「もの作り」とは性質が違うかと思いますし、どの職種にも適用できるかどうかわかりませんが、私の職場でも多いにヒントになるものだと思いました。
ほかにも、ビジネスとして興味深い話がたくさんありましたが、今回はこの標準化されたドキュメントの表記法の必要性について、ちょっとだけ書きました。

「わかっているけど、そんなことできないよ」

なんて思ったら、もうすでに時代に取り残されているかもしれません。
サービスをいかに「見える化」するか。
大変な課題ですが、当たり前のことかもしれませんね。この当たり前のことにこれまでと違ったアプローチがあり「未来」があるような気がしました。