開発チームにこそ、コミュニケーション能力が必要!？

こんにちは。 株式会社ソニー・ミュージックソリューションズで、スマートフォンAppの開発を担当している「かずのこ」といいます。よろしくお願いします。

私の所属している部署は、いわゆるコストセンターの立ち位置となり、プロフィットセンターの各事業部から開発依頼を受け、各事業部が担当するアーティストやイベントなどを扱った案件内で展開するスマートフォンAppの開発をしています。携わっているスマートフォンAppは、アーティストの情報を発信するAppや、アーティストのライブを楽しむためのApp、音楽配信サービスのAppなどさまざまです。

またコードをごりごり書いていくという感じではなく、もっと上流の工程である「要件定義」や「基本設計」を担当しています。事業部からの依頼内容をもとに、要求仕様をまとめ基本設計に落とし込む（Appの画面構成／一覧、機能一覧、サーバ側の構成およびクライアントとのAPI仕様、各種業務／運用設計や運用マニュアル作成など）ことがメイン業務となります。要は、「各事業部の思いを正しく開発会社さんに伝え、思い通りのAppを開発する」が主な仕事です。

開発は、山あり谷あり

このような仕事をしていると、何事もなく終わるプロジェクトもあれば、一波乱おこるプロジェクトもあります。正直、何事もなく終わるプロジェクトのほうが少ないくらいなのではないでしょうか？　そんな「一波乱」を細分化するとさまざまな問題がありますが、いわゆる“あるある”のレベルで言うと

• 事業部のイメージと違うものができあがった
• 大きく手戻りの発生する仕様変更が開発途中でおきた
• 事業部に開発スケジュールが意識されておらず、現状の進捗が伝わっていなかった

というようなことがほとんどです。

手戻りの発生する仕様変更などが起きると、開発側の負担は大きくなります。負担が大きくなるとフラストレーションがたまり、悪いサイクルに入ってしまうケースもあります。事業部と開発側では立場が違うので、しょうがない部分はあるにしても、こういった問題から関係性が悪くなり、コミュニケーションが雑になったりします。ここで対処をしないと、いろいろな余波を招き、結果的に誰も幸せにならないという悪循環が生まれます。実際、そこまでこじれてしまうことは滅多にありませんが、そうなりかねないトラブルは日常的に発生しています。

特に多いのが、急な仕様変更依頼です。

「Appを触ってみて、やっぱりなんか違う。こうするのはどうだろうか？」
「クライアントからの要求が変わったから、こうしてくれ」
「他のAppで実現しているこの機能も欲しい。追加してくれ」

などなど。

エンタテインメント要素の強いコンテンツをメインに扱っているので、エンドユーザーに「楽しみ」や「感動」を与えたいという思いが強い分、こういったことが多くなるのかなと感じています。また最初から、それらの思いを言葉として表現するのは、非常に難しいことなので、仕方ない部分もあるように感じます。どうしても自身と他者では、表現方法が異なりますし、ましてや感覚的な要素のつよいエンタテインメントの分野では、より伝えることが難しくなると思います。

友人や知人に、自身が体験した感動を伝えようとしても、なかなか伝えられず、本当の意味での共感を得るのは難しいですしね。

相手が考えていることを理解しよう

先にも書かせていただいたように、自分の思いを他者に100%正しく伝える方法はないと思います。ただ、何もしないといつまでたっても解決しない根の深い問題となり、それこそエンドユーザーを含め、誰も幸せになりません。 ※一番の被害者はエンドユーザーかもしれませんが。

それを踏まえた上で私は、問題が100％起こらなくすることはできなくても、何かしらの工夫をすることで、問題が起こる頻度を少なくすることはできるし、そうするべきだと思っています。それがプロジェクトの健全な姿で、エンドユーザーの満足度にもつながると考えているからです。

そのように考えている私が今までの経験の中から、大切だなと思ったポイントをいくつか紹介できればと思います。

プロジェクト目線でやるべきことを見極めよう

まず一番重要なのが、「事業部が達成したいミッションやゴールのイメージ共有」だと私は考えています。ここが不明瞭になればなるほど、方向性にズレが出てきます。 私の場合、自身の頭の整理として以下のような内容をまとめています。

• このプロジェクトのミッション
• ステークホルダーおよびお金の流れ
• エンドユーザーのライフサイクル／体験できる内容

「このプロジェクトのミッション」については、いわゆる5W1H、すなわちの「いつ・どこで・誰が・何を・なぜ・どのように」整理です。

この際私は、これを開発目線ではなく、プロジェクト目線でまとめることをしています。 ※このプロジェクト目線というのが重要になります。

たとえば、『アーティストの情報を発信するApp』を開発するとした場合を例とすると。

開発目線の「5W1H」は以下となります。 ※ここまで極端ではないかもしれませんが……

「決められた公開日に」
「App Storeにて」
「〇〇のアカウントを使って」
「〇〇App ver. 1.0.0を」
「依頼があったから」
「公開設定をして公開する」

これに対して私の考えるプロジェクト目線の「5W1H」は以下のようになります。

「〇月から始まるアーティストのツアーの〇週間前に」
「エンドユーザーが手に入れやすい場所で」
「ソニー・ミュージックソリューションズが」
「アーティストの魅力的な情報を」
「エンドユーザーにより楽しんで／親しんでもらえるよう」
「届ける」

2つを見比べるとかなり表現方法が異なりますし、意味合いも違ってくると思います。 プロジェクト目線のものをより具体的にすると、一部の目的は開発目線のものにはなると思いますが、これをやることによってプロジェクトのミッションの明確化ができるような気がしています。

忘れちゃいけないお金の流れ

次に「ステークホルダーおよびお金の流れ」についてです。 ビジネスである以上、お金の流れは意識したほうがいいと私は考えています。必ずお金の話は付きまとうものですし、これを前提に意識していると事業部側ともコミュニケーションがとりやすくなります。また私の場合、別で業務設計もやることが多いのですが、ここでステークホルダーがまとめられているので、スムーズに設計に移れることが多いです。

エンドユーザーを軸に情報を整理しよう

最後に「エンドユーザーのライフサイクル／体験できる内容」についてです。 エンドユーザーに対して何を届けたいのかということの整理になります。 ※先の「プロジェクトのミッション」や「ステークホルダーやお金の流れの整理」と比べると、レイヤーが1つ下がっている気もしますが……

開発目線でいうと、「App内のこの画面でこの機能が使えること」のように機能設計になることが多いと思うのですが、私は「App軸で情報を整理」するのでなく、「エンドユーザー 軸に情報を整理」します。

これも先ほどと同じように『アーティストの情報を発信するApp』を例にして書きたいと思います。

上図はかつて私が実際に『アーティストの情報を発信するApp』に携わった際にまとめた図です。当時の私はこのように考えたようです。

人の行動サイクルにそって、「アーティストのファンになってもらうためには……」という流れで検討をしています。そのうえで、今回のAppがどの範囲の役割なのかという整理をしていました。情報発信と考えると、Appの役割は1の範囲（認知してもらって、興味関心を持って調べてもらう）が最低限必要になってくると思います。ただそのあとのエンドユーザーの行動を考えると、2（ライブチケットやグッズの購入などができる）や、３（同じファンで共有できる場所）などがあってもいいかもしれない……なんて考えていました。

致命的なコミュニケーションミスを引き起こさないために

ここまでまとめると、以下2点をいつも思います。

「作り物はサービスを実現するための道具にすぎない」
「サービス側と開発側でおこるコミュニケーションミスは、話をする起点が異なるためにおこる」

先にも書かせていただきました通り、ゴールは何か物（WebサイトだったりAppだったり）を作ることではなく、エンドユーザーに対して魅力的な体験や情報を届けることです。なので、WebサイトやAppは単なる手段や道具にすぎません。 ※もっというと、提供するサービスでされ、エンドユーザーの選択肢のうちの1つにしかすぎませんが。

App軸の考えだけではなく、エンドユーザー軸の考えを整理したうえでAppやWebサイトの作り物の仕様を検討することが私は重要だと思います。

またコミュニケーションをとる際に、前提や考え方が異なると、なかなか相手の言っている意味が分からず円滑なコミュニケーションができません。これは「サービス側と開発側で、話をする起点が異なるため」に起きていると私は考えています。

簡単なイメージは上になります。開発は「成果物の内容」から話をしがちですが、事業部は企画の内容やサービス要件からのアプローチになります。まずはこの違いを双方理解したうえで、コミュニケーションをとることが重要だと考えています。単語などの定義もお互い共通認識をしたほうがよいですし、事業部側がポイントだと思っている点を開発チームも理解したうえで、成果物の検討および提案をすべきだと思います。

頭の整理をし、だいぶ自分自身的には納得のできる内容になったところで、事業部側に自身の作った資料をもとに認識のすり合わせをしています。これをやることによって、認識のズレがなくなるとともに、事業部側で検討の漏れていた内容やこちらの認識が間違っている箇所が見えてくることもあります。また理解力が深まることはもちろんですが、今後のコミュニケーションも取りやすくなると個人的には思っています。情報をまとめたりするのには、ある程度の時間がかかるので大変な作業ですが、開発の効率は数段上がるはずです。

まとめ

ここまでつらつらとコミュニケーションの難しさと重要性について書かせていただきました。私自身も多くのコミュニケーションミスを引き起こしてしまった過去があり、やりざまを迷った時期がありました。

ただ歳をかさねるにつれ、「そもそもコミュニケーションは難しい、伝えられない前提で伝える努力をしよう」と考えるようになり、今回書かせていただいたようなことをやるようになりました。これらの活動によりコミュニケーションミスは格段に減り、開発も滞りなく進捗するようになりました。

またうれしいことに、エンタテインメント業界ということもあり、アプリを使ってくださる方には熱心な方が多く、様々なご意見をいただきます。「感動した」などのポジティブな言葉をもらえると、もちろん非常にうれしいのですが、時には厳しいお言葉をいただくこともあり。ただこれはネガティブな要素ではなく、そのぶん利用者との距離が近いということだと思っています。このように利用者との距離感が近いサービスは、サービス自体の成長はもちろん、サービスを支えるプロジェクトメンバーの成長にもつながる環境だと考えていますので、非常にありがたいことかなと感じます。この利用者との関係性は、まさにエンタテインメント業界でアプリ開発をする際の「喜び」や「醍醐味」だと思います。

今回書かせていただいたのは、私が普段やっている内容ですが、他の方法でも効果的にコミュニケーションをとる方法はあると思いますので、皆様もぜひ参考にしていただければと思います。