統制語彙を使った情報設計・開発の取り組み

書籍の紹介

ちなみに、Abby Covert先生による「今日から始める情報設計」という書籍も出版されています。ワークショップの内容もこの書籍に沿って進められ、更に理解を深められるよう紹介されました。（ちなみにワークショップにて、ちゃっかり先生のサインを頂きました！）

今回このブログで紹介するのは、ワークショップや書籍で紹介された考え方をベースとしたアプリケーション開発例ですが、書籍では様々な参考例や解決方法について触れた内容になっていますので、興味のある方はぜひご覧になってみてください。

どのような表現・表記が正解なのか？で統一する

よくある簡単な例でいうと、サービス名などです。アシアルでは「Monaca」というサービスを提供しているのですが、「Monaca」が正式な表記なので、「monaca」や「もなか」、「モナカ」、「最中」という記載をしないようにしようということです。

キーワードを統一せずに記載すると、人によっては異なるサービスが複数あるように感じたり、「正式な表記はどれなんだろう」と混乱する人が出てくると思います。

スマートフォンアプリ開発時の統制語彙

スマートフォンアプリ開発の例では、アプリを開いて必ず最初に表示されるページのことを「マイページ」と呼んだりすることがあると思いますが、開発チームのメンバーが複数人いると、この「マイページ」のことを「トップページ」や「ダッシュボード」と呼ぶ人もいます。

しかし、「このアプリでは、マイページと呼ぶことにしましょう！」と決めておき、ほかの呼び方はしないようにしたとします。

これらの決まりごとを要件定義などで設定したら、画面遷移図や画面設計書などの資料を作成する時も、同じキーワードで記載します。もちろん開発チームのメンバーが各自で作成する様々な資料も同様です。そして、スマートフォンアプリを実装する時も、キーワードは統一して制作します。

これで、違う種類の資料を沢山用意しても、同じキーワードで記載した名称などは、同じ物事を指していることがわかりやすくなりますし、資料を作成した当事者以外の人が読んでも、時間がだいぶたった後で自分が忘れてしまって読み返したときにも情報の把握がしやすくなります。

統制語彙を使わない開発時のデメリット

キーワードが統一されてない開発はどういったデメリットが発生するかというと、余計な工数が発生したりします。

例えば、先ほどのスマートフォンアプリ開発の例であげた「マイページ」のことを別の画面では「ダッシュボード」と記載するよう指示書が作成されていたら、他の開発チームのメンバーから「ダッシュボードの画面なんてありましたっけ？」「そこへの遷移はどこにありましたっけ？」みたいな質問時間がお互いに多くなったり、最悪、確認が行き届いてないとマイページではない謎のダッシュボード画面らしき何かが仮実装されてしまうわけです。

また、出来上がったアプリケーションを利用するお客様からみても、「マイページ」と「ダッシュボード」は違う画面だと認識しまい、アプリ内で迷子にさせてしまうかもしれません。

このようなデメリットが、扱う情報量が多くなるごとに膨れ上がるわけです。。。

取り組みは、こういったことを避けるために序盤の工程から意識して開発を進めましょうということです。