システムではなく、コミュニケーションをデザインせよ

アーキテクトの仕事というと「システムを設計すること」と思われがちですが、実際にはそうではありません。アーキテクトがデザインすべきなのはコミュニケーションです。システムはコミュニケーションを実現するための手段に過ぎません。

多くのシステムは、データを登録し、それを取り出すということで成り立っています。では、ユーザーは何をしたいのでしょうか？ユーザーはデータを登録することも、データを取り出すことも望んでやっているわけではありません。彼らは、誰かとコミュニケーションをして、自分のやりたいことを前に進めたいと思っているだけです。ECサイトでカートボタンを押すのも、伝票の登録ボタンを押すのも、自分の得たいものを得るために「しかたなく」やっていることなのです。

ですから、アーキテクトはシステムをデザインする前に、コミュニケーションについて考えなくてはいけません。システムは道具です。道具をデザインするのに、その目的を知るのは当然のことでしょう。どんな人たちが、どんな目的で、どんなコミュニケーションをしているのかを知るのです。

しかし、残念ながらコミュニケーションを理解するのは簡単なことではありません。情報システム同士はメッセージやファイルをやりとりすることで会話します。人間も同じでしょうか？そんな単純ではないことを、皆さんは経験から学んで、いるはずです。盛り上がっている会話の輸があります。あなたがその輪に入りたいなら、まずは慎重に聞き耳を立てて、会話の流れを理解する必要があります。それが完了するまで、あなたは彼らが何の話をしているか、さっぱり分からないでしょう。しかし、一旦、会話の流れを理解できれば、容易に会話の意味が理解できるようになるのです。逆に、たいして理解もせずに思い込みだけで会話に参加すると、トンチンカンな受け答えをしてしまい、恥をかくことになります。

新しいシステムを設計するときも同じです。あなたは既にコミュニケーションが成立しているところに参加するのです。まずは聞き耳を立てて、その場の流れを理解する必要があります。一般的な知識や業界の知識が役立つこともあるでしょうが、思い込みは禁物です。「顧客」や「伝票」という一般的言葉が、その組織においてどういう意味を持つかは、会話に参加しない限りはっきりしないのです。

こうした組織における「会話の流れ」は文化や風土と呼ばれているものです。コミュニケーションをデザインするとは、まず、その組織の文化や風土を理解するということなのです。

こうして、コミュニケーションのことが理解できてきたら、それらをモデル化していきます。モデル化はコミュニケーシヨンの不整合や無駄を暴いてくれます。組織のメンバーは自分がコミュニケーションしている部分しか知らず、企業全体のコミュニケーションを理解しているわけではありません。そういったコミュニケーションの断片を集めてきて、組み立てていくとどうしても不整合や無駄が出てきます。ここを整理していくことで、より強固なシステムを作ることができます。このとき動的なモデル図が役に立ちます。クラス図よりもアクテイビティ図、配置図よりもシーケンス図が重要です。

私は、本来、「システムのユーザー」という存在はいないべきだと思っています。デザイナーの西村佳哲さんは、ユーザーについて次のように述べています。

書籍ユーザなんていない。いるのは、リーダーです。サーフボードユーザなんていない。いるのは、サーファーです。最終的なゴールは、「ユーザ」と呼ばれる存在のいない経験の総体をデザインすることだ。

システムも同じです。システムユーザーはいないほうがいい。いるのは「コミュニケーター（コミュニケーションをする人）」です。アーキテクトは、ユーザーと呼ばれる存在のいない、コミュニケーションの総体をデザインするべきなのです。