鈴木雄介アーキテクトの仕事というと「システムを設計すること」と思われがちですが、実際にはそうではありません。アーキテクトがデザインすべきなのはコミュニケーションです。システムはコミュニケーションを実現するための手段に過ぎません。多くのシステムは、データを登録し、それを取り出すということで成り立っています。ユーザーは何をしたいのでしょうか?ユーザーはデータを登録することも、データを取り出すことも望んでやっているわけではありません。彼らは、誰かとコミュニケーションをして、自分のやりたいことを前に進めたいと思っているだけです。ECサイトでカートボタンを押すのも、伝票の登録ボタンを押すのも、自分の得たいものを得るために「しかたなく」やっていることなのです。アーキテクトはシステムをデザインする前に、コミュニケーションについて考えなくてはいけません。道具をデザインするのに、その目的を知るのは当然のことでしょう。どんな人たちが、どんな目的で、どんなコミュニケーションをしているのかを知るのです。残念ながらコミュニケーションを理解するのは簡単なことではありません。情報システム同士はメッセージやファイルをやりとりすることで会話します。人間も同じでしょうか?そんな単純ではないことを、皆さんは経験から学んで、いるはずです。盛り上がっている会話の輸があります。あなたがその輪に入りたいなら、まずは慎重に聞き耳を立てて、会話の流れを理解する必要があります。それが完了するまで、あなたは彼らが何の話をしているか、さっぱり分からないでしょう。会話の流れを理解できれば、容易に会話の意味が理解できるようになるのです。逆に、たいして理解もせずに思い込みだけで会話に参加すると、トンチンカンな受け答えをしてしまい、恥をかくことになります。新しいシステムを設計するときも同じです。あなたは既にコミュニケーションが成立しているところに参加するのです。聞き耳を立てて、その場の流れを理解する必要があります。一般的な知識や業界の知識が役立つこともあるでしょうが、思い込みは禁物です。「顧客」や「伝票」という一般的言葉が、その組織においてどういう意味を持つかは、会話に参加しない限りはっきりしないのです。した組織における「会話の流れ」は文化や風土と呼ばれているものです。コミュニケーションをデザインするとは、まず、その組織の文化や風土を理解するということなのです。して、コミュニケーションのことが理解できてきたら、それらをモデル化していきます。モデル化はコミュニケーシヨンの不整合や無駄を暴いてくれます。組織のメンバーは自分がコミュニケーションしている部分しか知らず、企業全体のコミュニケーションを理解しているわけではありません。いったコミュニケーションの断片を集めてきて、組み立てていくとどうしても不整合や無駄が出てきます。ここを整理していくことで、より強固なシステムを作ることができます。このとき動的なモデル図が役に立ちます。クラス図よりもアクテイビティ図、配置図よりもシーケンス図が重要です。私は、本来、「システムのユーザー」という存在はいないべきだと思っています。デザイナーの西村佳哲さんは、ユーザーについて次のように述べています。書籍ユーザなんていない。いるのは、リーダーです。サーフボードユーザなんていない。いるのは、サーファーです。最終的なゴールは、「ユーザ」と呼ばれる存在のいない経験の総体をデザインすることだ。システムユーザーはいないほうがいい。いるのは「コミュニケーター(コミュニケーションをする人)」です。アーキテクトは、ユーザーと呼ばれる存在のいない、コミュニケーションの総体をデザインするべきなのです。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。