こんにちは。
プロダクト戦略開発室でデータアナリストをしています、白石です。
今回は昨年10月にリリースされたMicrosoft TeamsとSansanとのプロダクト連携の企画の裏側について書いてみようと思います。
ちなみに本業はデータアナリストですが、プロダクト戦略開発室の業務は多岐に渡っておりログ解析はもちろん、他サービスの調査やマーケットの調査なども含まれます。そのためログ解析や他サービス調査などの結果から起案されたプロダクトの企画なども担当することがあります。
今までもいくつかプロダクトの企画をしてきたのですが、今回初めて他社プロダクトとの連携の企画を進めてみて、いつも以上に確認ポイントや注意点が多く、反省も多かったのでそれをまとめてみました。
プロジェクトの管理
Sansanでは、通常社内メンバーしか関与しない開発プロジェクトであればコミュニケーションのパスやルールがある程度決まっており、フローに乗っ取ってプロジェクトが進行していきます。そのため、全てのタスクの進捗を細かく確認する必要はありません。
一方、他社プロダクトと連携する場合、多くのメンバーが関わりながらプロジェクトが進みます。プロダクトを作るために開発はもちろんですが、アライアンスや営業、CS、広報やマーケメンバーとも連携して進める必要があります。
さらに、当たり前ですが社外のメンバーとのやりとりも多く発生する為、私を含めた数名のメンバーが先方とのやりとりの対面に立ち進めていきます。そのため全てのタスクの状況を把握しておく必要があります。いつも通り必要な情報をとりまとめて連携するだけではなく、並行で走っている様々なやりとりを把握しなければなりません。
上記の違いやプロジェクトの進行の全体像が把握できていないと、いつもと同じような準備で進めていくうちに状況のキャッチアップが追いつかなくなり、単純にタスク漏れが発生するだけでなく、想定よりタスクが多く捌き切れなくなります。
外部と連携する場合は、通常の企画、開発よりもアテンションをはらないといけないことが多いので、自分のタスクに余裕を持たせておく必要があります。
プロダクトの理解
次に他プロダクトと連携する場合、先方の営業やCSメンバーがSansanについての質問を受けたり、Sansan連携を提案することになるので、まずはSansanについて知ってもらう必要があり、先方のCSや営業メンバー向けに勉強会を企画し、デモを交えて説明する機会をもらいました。
事前に勉強会を実施することで想定される質問などを洗い出すことができ、想定問答集を作成できたので、リリース後のQA対応も比較的スムーズに進みました。
また先方が利用する営業資料などの準備もありましたが、これも事前に作成しておいたのでリリース翌日から営業活動にご利用いただけました。
反対に、SansanメンバーがTeamsのことを質問されることもあり得るので社内向けにTeamsの勉強会を実施する必要があります。
この点が抜け落ると、リリース後に関係各所からQAを受けることになってしまいます。
関わっているメンバーは連携するプロダクトについて調べたり、機能の問い合わせたりしながらプロジェクトを進めているので理解が深まっていますが、他のメンバーはそうではないので、社内メンバーへの勉強会は必要です。
PR
他社連携の場合、プレスリリースを出すことがあります。また、共同のセミナーやイベントでの露出、コミュニティサイトへの記事掲載など、通常の社内の開発よりもPR活動が活発に実施されます。今回もプレスリリースやイベントでの発表などが予定されていました。
複数の記事や原稿などが事前に準備されるのですが、ギリギリまで仕様変更が発生しており、準備していた資料の差し替えが生じました。社内の複数の部署で並列に準備が進んでいるため、チェックや連携が漏れないよう調整しなければなりません。
リリース
通常、Sansanではリリーススケジュールについてはコミットしません。社内用のスケジュールはあるもののそれを社外に公開したり、お客様へお約束することはなく、開発が完了したものからリリースされます。
今回は、上記で記載したように他社も関係してのPR活動が実施される都合上、リリース日を決める必要がありました。
日程や進捗の共有はこまめに実施していたつもりですが、当初想定していた仕様だとリリーススケジュールが厳しいことがわかりました。
今回は初めから全ての要件を盛り込んだ完全版でのリリースではなく、1stのリリース後ユーザーの反応をみて2ndリリースというような流れを予定していました。1stリリースに必須の条件をしっかり確認し、開発状況を確認しながら2ndリリースにまわすものを判断する必要があります。先方とは、初期の段階でこのリリースの基準や内容について認識合わせをしておかなければなりません。
今回は開発メンバーが頑張って対応してくれましたが、最初から1stリリースに必須な仕様かどうかを決めておけば、開発メンバーの負担も少なく進められます。
通常の案件であれば、自社内の調整だけでリリース要件を決められますが、他社連携の場合はリリースの必須要件や、どの状態をリリースと呼ぶかも異なります。他社連携ではそこをしっかり認識合わせする必要があります。
最後に
反省点を書き連ねましたが、1回体験してみないことには気づけなかったことが多かったと思いました。また、見通しが甘く作業がオーバフローしていたのでミスが連鎖していたと思います。基本ですが、まずは余裕を持ったスケジュールとタスクの管理が重要だと思いました。
今回あげた点は、(もう動き出してますが)次の連携で活かしながら進めていますが、何より毎回振り回している開発メンバーのフォロー力がアップしているので、漏れているタスクは先に気づいてフォローしてくれます。感謝でいっぱいです。
