はじめに
モチベーションクラウドシリーズ Advent Calendar 2019の9日目担当の柴田です。
ぼくは、チームワーククラウドという製品のプロダクトマネージャーをやっています。
さて、プロダクトマネージャーという職業柄、ビジネスサイドと開発サイドを接続するコミュニケーションも大事な仕事の1つです。ただ、そのなかで、以下のことで苦労することが多くあります。
「ビジネスサイドにシステム開発の常識が通じない！」
というものです。
弊社に限らず多くの企業において、営業やコンサルタントなど現場のビジネスサイドの方と開発サイドでは、求められる知識や経験が当然異なっています。したがって、ぼくら開発側が常識だと思っていることが、まったく理解されないといった場面は多々発生します。
ただ、そのまま自分たちの尺度を押し付けてしまうと、関係性が悪化しがちです。本来はお互いに協力関係であるべきところを、「アイツラには話が通じない」と溝を深め、現場と開発が対立するという残念な状況になりかねません。
ここで大事なのは、ギャップからではなく、共有できる部分に目を向けるということです。
異なる領域の人たちがコミュニケーションをすると、「あれも通じない」「これも知らない」と両者が交わらない部分ばかりが気になります。ただ、それよりは「これはお互いが理解できる」という部分をまず見つけるべきです。すぐに見つからない場合は、新たに共通の基準やゴールをつくってもよいでしょう。
と言われても、具体例がないとイメージできないですよね？
では、ぼくの経験したケースにおいて、どのようなときに「システム開発の常識」が通じず、それをどんなやり方で「共通の常識」を見出していったか、それぞれ解説していきます！
ケース１：システム用語は知っておくべきという常識
まずは、言葉が伝わらないというものです。
例えば、「製品デモをする環境が使えないんですけど」という現場からの問い合わせに対し、「stagingはいまdeploy中なんで、productionのmigration環境ならsandbox的に使っていいですよ」といった回答しても、相手には１ミリも通じません。ルー大柴と思われます。
では、現場の人たちにシステム用語の知識がまったく不要かといえば、そんなことはありません。というのも、顧客に聞かれたら回答しないといけない場面は多くあるからです。
したがって、システム用語も自分たちの常識を押しつけるのではなく、「顧客が使ってくる用語」をベースに共通のリテラシーを設けるとよいでしょう。さらに、FAQや用語集なんかを作っておくと喜ばれますし、何度も同じ説明を繰り返さなくて済むようになります。
⇒対策：顧客が使う用語をベースに、FAQや用語集をつくろう！
ケース2：不具合はすぐには直らないという常識
システム開発に一度でも関わっていると、単に「不具合を直す」とうものがいかに大変なものか、その「システム開発の常識」はよくご存知だと思います。ごく単純なプロセスに分解しても、少なくとも以下のステップを踏む必要がありますよね。
再現調査 ⇒ 原因特定 ⇒ 影響調査 ⇒ コード修正 ⇒ テスト ⇒ リリース
ただ、そのプロセスは自身で体験しないと、上記のステップがイメージできません。不具合を見つけたら、以下で直ると捉えています。
直す ⇒ 出す
したがって、不具合をなぜすぐに直さないのか、と現場は「常識的」に思うわけです。
これは、不具合を修正することに対するトレードオフが伝わっていないことが、現場と開発の認識齟齬を生み出しています。
人によっては、システムの不具合を、単なる誤字脱字のようなミスと思っている人も少なくありません。そこには、不具合を修正することによる開発工数への圧迫や、デグレ発生のリスクなど、システム開発全体への影響という観点を持ちあわせていないわけです。
したがって、不具合を「ミス」ではなく、「ビジネス上の課題」として扱って、共通の「ビジネスの常識」にしたがってコミュニケーションすることを心がけましょう。そうすると、その課題の解決が、ビジネス全体にトレードオフで影響を与えるというのは、とても自然な考え方になります。
システム開発が特殊な営みではなく、一般的なビジネス活動そのものであるという前提で話したほうが、同じ目線で議論ができるようになるはずです。
⇒対策：システム開発を、トレードオフが存在する一般的なビジネス活動と同じものとして話そう！
ケース3：時間が経っても、すべての課題は解決されないという常識
確かにSaaSはローンチしてからもどんどんアップデートを行い、機能は追加され、UXも改善されていきます。
ただ、その表層上の印象で、「使いづらい」「機能が足りない」「不具合が多い」などシステムに対するあるゆる課題は、時間さえ経てばすべて解決していくはずと思われがちです。
「時間をかけても解決しづらい課題がある」あるいは「時間が経つにつれ、もっと複雑化する課題が多くある」というシステム開発の闇は、なかなかビジネスサイドの人たちには理解されづらいものがあります。
つまり、あんなにたくさんのお金を投じて開発してきたソフトウェアが、「資産」になることはあっても、まさか多くの「負債」を抱えることになっていたとは、夢にも思わないわけです。こうして書くと、たしかに非常識な気もします。。。
だからこそ、システム側だけでは「時間をかけても、解決しづらい課題」であることを理解してもらったうえで、開発以外のチームも巻き込んで問題を解決していくことが非常に大切です。つまり、システムの資産の部分も負債の部分も、みんなで抱えていくという発想を持つべきです。
例えば、営業には顧客の期待値を調整してもらったり、カスタマーサクセスには現行機能の範囲での推奨運用で誘導してもらったり、サポートで不具合の回避方法を案内してもらったり、などいくらでもやり方はあります。
システムの課題は、チームの課題です。自分たちだけで抱え込まず、バリューチェーン全体で解決していきましょう。
⇒対策：課題はみんなで解決しよう！
まとめ
言葉が違う、常識が違う、バックボーンが違う。
そんなのは大した差異ではありません。きちんと共通部分を見出して歩み寄れば、これらは適切にすり合わせることができます。
もっとも大切なのは、バリューチェーンに関わる全員が同じゴールを見ていることです。実現したい世界観、ユーザーに届けたい価値など、それさえ一致していれば、どんな問題も組織で解決することができます。
目線があえば、それぞれの「異なる常識」も理解が深まってきます。もちろん、完全にはわかりえない部分があっても、そこは互いの専門性として任せるというリスペクトが生まれます。
このようなビジネスサイドとエンジニアサイドが相互信頼しあうチームワークこそが、企業やサービスにおける競争力の源泉となっていくはずです！
みんな、仲良くしましょう！
以上です。ありがとうございました。