開発が行き詰まる前に考えよう -サービス改善はコミュニケーションを変えることから始まる-
コンウェイの法則というものを聞いたことがありますか？
ざっくり言うと、サービスやプロダクトの性質はそれを作る組織の性質と同じような形態になるというものです。
具体的な例で言うと、機能がたくさんある大規模システムで機能ごとに開発チームを分けた組織構造である場合、そのシステムも機能ごとに独立した構造になっており、UIやデザインのテイスト、表示テキストの使い方がそれぞれで異なった状況になってしまうことです。
このように組織の構造がそのままサービスやプロダクトに反映され、写し鏡のようになることをコンウェイの法則といいます。
組織の構造＝コミュニケーションの形態
ユーザーにとって使いにくいサービスや機能過多になっているプロダクトはこのような状況になっていることが多いです。
サービス改善の依頼をされた時、現状のサービスそのものを詳しく見ることと同時に、クライアントがどのような組織構造でサービスを作ってきたか、そしてこれまでの開発プロセスにおいてどのようにコミュニケーションをとってきたかを詳しくヒアリングします。
そうすると前述のようなことが明らかになります。
つまり、縦割りの組織構造で作ってきたシステムは機能間の一貫性がなく、ユーザーが本来やりたいことがスムーズにできない状況です。
そして多くの場合、開発の情報共有では操作フローや画面UIを見える化しておらず、円滑なコミュニケーションができていません。
開発チームのメンバーは機能単位でしか情報を把握しておらず、サービス全体の操作フローや体験を具体的に答えることができない場合もあります。
機能は目的ではない
サービスを作る目的は機能を作るためではありません。
そのサービスを使うユーザーが使う前と比べてどのようになるのか、どんな体験を経て結果としてユーザーはどうなるのか、その体験と結果を提供するためにサービス（機能）を作るのです。
この当たり前の概念「機能はあくまでも手段である」は、サービスが大きくなってくると抜け落ちやすくなります。そうなると、いかに機能を効率よく作るかに比重が置かれいつのまにか誰が何のために使うのかわからない肥大化した物体が出来上がってしまいます。
体験整理と見える化のためのコミュニケーション
この状況を打破するためには開発のコミュニケーションをやり直す必要があります。サービスの目的を言語化し、ユーザーに提供したい体験のフローと結果を見える化します。それを軸にコミュニケーションと開発の意思決定を行うのです。
言葉にすると簡単なのですが、長年取り組んできたサービスやプロダクトだと客観的に整理することが難しい場合も多く、デザイナーやエンジニアの間で認識の齟齬が出てくることもしばしばあります。
そういった不足点、歪み、膿も全て見える化することで本当の課題とやるべきことが明らかになります。
サービスの目的と体験の整理はそんなに難しいことではありません。既存のフレームワークなどを使えばある程度整理できますので、また別の記事で紹介していきます。