こんにちは！TECH Street編集部です！
2023年8月18日（金）に開催した、 「プロジェクトマネージャー勉強会 ～各社の取り組みや課題から学ぶ会～」では「他社のプロジェクトってどうしているのだろう」 「他社のPM業務や課題と対策について知りたい」などのお声をいただきました。そこで、開発現場で活躍している各社のPMが集まり、日々の業務で得た知見や事例、工夫などを発表いただきましたのでその様子をレポートいたします。
登壇者はこちらの方々！
久松佑輝さん／コミューン株式会社
三村亮太さん／パーソルキャリア株式会社
樋口義久さん／株式会社セゾン情報システムズ
まずはロードマップ完遂のポイントについて、コミューン株式会社、久松さんの発表の様子をレポートいたします。
いかにロードマップを完遂するか
久松：まずは我々が提供しているプロダクト「commmune」をご紹介いたします。「commmune」は企業がコミュニティを簡単に立ち上げることができるSaaSです。
ノーコードでコミュニティを簡単に構築できて、目的にあわせたデザインや機能をカスタマイズできることが特徴であり、日本で最も選ばれているコミュニティサクセスプラットフォームです。
ここからは本題に移りますが、プロダクト提供する過程でロードマップを予定通り完遂するのは難しいと日々感じています。
我々のチームでは私がロードマップを作成します。そしてチームリーダーがどれを担当するかを決めてもらい、その後は各スクラムチームのプロダクトマネージャーが要件定義から最後のデリバリーまでを担当しています。
しかし開発サイドとしては、予期せぬことが発生し、想定通りいかないことも多いため、なるべく具体的なロードマップを伝えたくないという心情もあります。3カ月ごとにロードマップを引いていても、予定通りに進むのはとても難しいです。
一方でSaaSは現時点のプロダクトに満足いただくことも重要ですが、弊社のようなスタートアップの場合は、将来の期待値も含めてご利用いただいているということも多分にあると考えます。そのため「いかに解像度高くプロダクトの進化について伝えるか」は重要であり、ロードマップを完遂することが必要です。
そこで、ロードマップ完遂のポイントを５つお伝えします！
ロードマップ完遂ポイント
完遂ポイント①テックリードと粗い見積もりをする
プロダクトマネージャーだけでロードマップを書いてしまうと、つい内容を詰め込んだものを作ってしまいがちになります。「着手する前に頓挫する」ということにならないためにも、私たちは必ず事前にテックリードと粗い工数見積もりをしています。粒度としては、一般的にシステム要求が整理されている状況までプロダクトマネージャーが情報を整理して、それをテックリードと相談するようにしています。
ゴールに紐づくシナリオを設定した段階でテックリードとコミュニケーションを取り、どれくらいかかるかを整理しています。その後、実際にロードマップに乗ったら、スクラムチームのエンジニアやデザイナーとコミュニケーションを取りながら、要件を詰めていきます。
完遂ポイント②確実なものだけロードマップに入れる
次に、確実なものだけをロードマップに入れていきます。
新規のお客様と既存のお客様では、情報量を変えています。しかしそれではプロダクトの進化が見えにくいこともあるので、進化を肌で感じてもらうためにも期待値を調整しながらコミュニケーションを取ることもあります。
SHIP（クライアントと弊社社員のコミュニティ）を活用したコミュニケーション例
上図のように、弊社のプロダクトである「commmune」をクライアントの皆さまとコミューン社員のコミュニティとして利用しています。
そこで私から定期的に情報発信をしていて、この３カ月の機能開発やリリース手前の機能などを随時シェアしています。そうすることで、我々のプロダクトへの期待値を持ち続けていただくような工夫をしています。
完遂ポイント③PRDを常に最新の状態にし続ける
弊社はリモートでの開発がほとんどで、意識しないと「情報がSlackのチャンネル上に点在している」といったことが発生してしまいます。しかし、それでは途中から参画してきたメンバーたちは何が正解かわからなくなってしまうので、必ず｢PRDを読めばわかる｣という状態にしています。
完遂ポイント④Goal単位で優先順位をつける
PRDをきちんと書いているからこそ、優先順位や開発スコープの調整がしやすくなります。
スコープを調整する際に、requirements単位で優先順位をつけて、スコープ調整をすることが多いと思います。しかし我々はGoalにも優先順位をつけています。そしてそのGoalに対して「どのUserScenarioを紐づいているのか」に対しても優先順位をつけています。Goal、Userscenario、requirementsを紐づけておくことで、ドラスティックな意思決定を可能にしています。
完遂ポイント⑤ビジネスサイドと密に連携する
弊社にはプロダクトマーケティングマネージャー(PMM)というポジションがあり、ビジネスサイドとのコミュニケーションや、「製品をどう外に出していくのか」というGo To Marketを担っているチームがあります。私たちはPMMと定例でコミュニケーションを取っており、進捗にアップデートがあるとすぐに連携して、QCDを調整しています。
当然ですが、リスクを放っておくと対処法も限定的になりますし被害も大きくなるので、必要に応じて顧客コミュニケーションをアップデートし、真摯なコミュニケーションを徹底しています。
まとめ
完遂までのそれぞれのポイントと達成される目的をまとめると以下の通りです。
- テックリードと粗い見積もりをする → 無理なロードマップの作成リスクを下げる
- 確実なものだけロードマップに入れる → ロードマップ遅延リスクを下げる
- PRDを常に最新の状態にし続ける → 開発時のコミュニケーションコストを下げる
- Goal単位で優先順位をつける → スコープをドラスティックに調整できる
- ビジネスサイドと密に連携する → 遅延による影響を最小限にすることができる
この5点のポイントを抑えることでロードマップの完遂可能性を高め、クライアント・エンドユーザーからの信頼を得ることができます。
久松さんありがとうございました！
次にパーソルキャリア株式会社、三村さんより横断プロジェクトのステークホルダー管理について発表いただきました。
複数事業横断系プロジェクトのPMが行うステークホルダー管理
三村：まずは、パーソルキャリアのPMとステークホルダーの立ち位置について説明いたします。
プロジェクトマネージャーはさまざまな環境に置かれることがあり、ステークホルダーとのコミュニケーションをとりながらプロジェクトを円滑に進めることが求められます。
そんなPMの担当業務は…
- 「企画と開発」「経営層とPO」「POとPJTメンバー」「PJTと他事業」など様々な関係性の中でPJTの情報整理を行う
- 炎上PJTの場合、「炎上原因を特定し鎮火～立て直しを行う」
- PJTメンバーだけではできない範囲が出てきたときは、PMが広いPJTを推進する
大まかに分ければこのようになっており、「ステークホルダーを特定し何が求められるか、もしくは不足しているかを見つけて情報を整理して伝える」ということがメインの業務といえます。
パーソルキャリアPMの悩み事あるある
上図は、とある基幹システムプロジェクトのシステム構成図です。基幹システムCの改修を例にパーソルキャリアPMのあるあるをご紹介します。
上図の通り、基幹システムのABCがトライアングルになっていて、基幹システムCはABどちらともやり取りをしています。
改修にあたってシステム調査や企画共有もしていて全体的に合意して進んでいたはずでしたが、なぜかプロジェクトに申し立てが多い状況が続きました。
それぞれ言っていることは正しいけれども、言い分のすべてを実現しようとすると、仕様が決められず品質とスケジュールに響いてしまい、開発量が増えてコスト増加にも繋がります。
そこで「どうしてこんなことが起きるのか？」を振り返り、少し見方を変えてみてステークホルダー視点を可視化してみることにしました。
このようにステークホルダー目線、つまり外からプロジェクトを見てみると、問題点が見えてきました。
社内のステークホルダーが特定できておらず様々な影響を多様な箇所に与えてしまい、事業責任者や業務担当からのクレームに繋がっており、顧客メリットはあっても事業にとってデメリットでしかなく事業協力を得づらい状況が発生していたのです。
ステークホルダー管理において大事なこと
ステークホルダー管理において大事なことは
- ステークホルダーの特定
- ステークホルダーの期待値コントロール
- ステークホルダーとのコミュニケーション
であると考えます。
ステークホルダーの特定
- 誰にどのような影響がでるのか、様々な観点から確認し、影響する人を探す。
- システムの主管部門の企画と開発で有識者を探す。
ステークホルダーの期待値コントロール
- プロジェクトの内容が「事業にとってどういう影響がでて」「どういう対策をとるか」などの目線を揃える。
ステークホルダーとのコミュニケーション
- プロジェクトの内容について、事業にとってのメリット・デメリットも説明する。
- またプロジェクトの情報を共有し、事業内で影響するものがないかは監視する。
三村さんありがとうございました！
次に株式会社セゾン情報システムズ、樋口さんの発表の様子をレポートいたします。
プロジェクトのゴミ拾い 引き取り手のいない仕事をどう捌くか？
樋口：我々が提供しているプロダクト「HULFT」ついて、まずはご紹介します。
様々なプラットフォームで安全・確実に、ファイル転送による業務連携を行うミドルウェアというのが「HULFT」です。
品質が安定しておりサポート対応も手厚いのが特徴で、MFT（ManagedFileTransferSuites）市場シェアも世界第4位を誇ります。
今まではパッケージ製品の開発をしていましたが、近年はその製品が持っていたノウハウをプラットフォーム上で提供するサービスとして、クラウド型のデータ連携プラットフォームの提供を開始しました。
この製品の企画、開発、販売、サポートのすべてを自社で行っています。
本日お話するのは、このHULFT Squareの開発を進める中でのお話です。
会社組織とプロジェクトステークホルダー
製品を開発するとなったときは、部門を横断してメンバーをアサインし、各部門で体制を作ってもらって開発を行います。しかし、「機能組織で横断して開発をする」というやり方では課題も生まれます。
組織横断活動の課題として、組織の役割からこぼれる業務が発生しやすく、特に今までとは違ったことを行うときに起きやすいです。気付いたら、大事な業務なのに誰もやっていないということが起きてしまいます…
そこで「プロジェクトのゴミ拾い」です。
プロジェクトのゴミ拾いとは？
プロジェクトのゴミ拾いは「発見」「担当割り当て」「処理」のフローで進んでいきます。
ゴミ拾いフロー①発見
まず、発見での注意点としては心理的安全性を確保し、話しやすい環境を整備しておくことが重要です。
PMがこぼれた仕事を把握できれば対処できますが、気づいているのに誰も言わないとなると大問題になってしまうので、それを発生させないことが大事だと考えています。
気づいているのに言わないという状況には2パターンあります。それは「負の感情がある」パターンと、「無関心」なパターンです。言った人に仕事を押し付けるような文化だと、マイナスの感情が働いて知っていても言わなくなってしまいます。また、黙っていても自分は困らないという無関心のパターンもあるので、こういったものをプロジェクト全体で払拭して、話しやすい環境をいかに整えるかが大事です。
ゴミ拾いフロー②担当割当
発見したあとは「担当割当」です。
必要なら自分で処理もしますが、最終的にどこで誰がやるかを考えた上で実施することが大事です。
毎回PMがやってしまうと、それが当たり前になってしまうこともあるので恒久対応としてどうあるべきかを考えて、それをメンバー間で認識を合わせて仕事をすることがポイントです。
ゴミ拾いフロー③処理
割り当てた後はひたすらに処理をこなすこととなります。プロジェクト内でタスクになってしまえば、あとはスケジュール管理をして進めるのみです。
まとめ
見つからなければ対処もできないので、いかに言ってもらえる環境を整えるかが大事なポイントです。
この一連のプロセスを実現できるかが、プロジェクト成功のカギになると思っています。
樋口さん、ありがとうございました！
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）炎上察知能力！！過去最悪の炎上PJってどんなのでした？
久松：急にリクエストが大量発生してさばけなくなってしまい、サービスがダウンしたことがありました。そういう場合も、どこがネックなのか、どこを先に着手すべきなのか、情報を整理して優先順位をつけて対応しました。
（Q）開発体制はどんな規模なのですか？まだ若い企業さんですよね。今のところロードマップ完遂率は実際どんな感じですか？
久松：コミューンでは、ウェブブラウザ、モバイルアプリでの提供をしています。一部アメリカへも展開。国内が２チーム、USチーム向けが１チーム、モバイルアプリ（toC）が２チームあります。
2年前に入社し、そのときにひいたロードマップが障害対応により一度白紙になったこともありました。それらの経験をもとにチームでかなり密にコミュニケーションをとるようになったので、完遂率は安定しています。
（Q）RequirementだけでなくGoalなどもまとめて優先順位をつけるとのことですが、何かツールを使って管理されていらっしゃるのでしょうか？
久松：RequirementはNotionを使っています。
エンジニアはJiraを使っているので、Notionの対応項目をURLで紐づけています。
（Q）パーソルさん、グループ全体でもかなり開発部署も多そう、各PJでの横断組織（品質とか管理とか標準化の横断組織）なんてありますか？
三村：横断組織を管理する組織はないです。
（Q）個人情報もかなり多く扱うかと思いますが、そういう点でPMとして注意している意識等ありますでしょうか？
三村：個人情報を取り扱う場合、コンプライアンスのチェックを必ずしています。
（Q）表面上出てないけど水面下で冷戦的なステークホルダーの揉め事というか食い違いを事前に察知して事前対策、なんて可能でしょうか？アドバイスあればぜひ
三村：パーソルでもあります。ステークホルダーを特定していくときに、何度か出てくる方はその人たちに話を聞きにいきます。そのように品質を担保しています。
（Q）複数のステークホルダーで、言い分が対立してしまい、手を付けられない状態になったことはありますでしょうか？もしあれば、どのように対応していらっしゃいましたか？
三村：対立が起きたこともあります。代表者の方と3者面談して落としどころを見つけていきます。
（Q）コミュニケーション難しい...この人きついなぁ...に対する最善なコミュニケーション手段技で「実はこんなことも有効」を聞かせてください
三村：プロジェクトメンバー間でよくあること、文章を使わずに絵を描く。「図で説明して」という形で理解度を確認して、タスクレベルを下げたりしています。
（Q）ステークホルダーとの調整は、対面での会話が主体でしょうか。それとも何かしらのプレゼン資料を用意して説明されるのでしょうか
三村：最初に話す時は、ペライチの資料を作ります。それを用いて感触をつかんでから、詳細を作り込んでいます。
（Q）ユーザーとコミットしなければならないことは膨大ですが、打ち合わせはどのようにされていますか？やっぱり事前に次第を配布して、ある程度ユーザーに考えをまとめておいてもらうべきでしょうか？
三村：資料は基本MTGのその日に出てくることが多いです。事前配布はしていません。決めることを冒頭に話して、ゴールを見せてMTGに入ります。
（Q）ある程度関係構築ができてしまえばやりやすくなると思いますが、関係構築前の最初の接点時は相手の出方や反応、伝達・交渉方法など不安になる点も色々あると思います。最初の関係構築のためにどのようなことを意識していますか？
三村：ファーストステップは、「相手にとってデメリットの話をしにいく」という意識を持っています。話をしたあとに相手の出方をみて、交渉方法を考えています。
（Q）HULFT！使ってます！
樋口：ありがとうございます！
（Q）確か独自の転送方式でしたよね。全銀連とかで採用って事は品質意識はハンパないかなと思うのですが、そういう品質面についてPM視点で「これ超大変」みたいなお話聞いてみたいです
樋口：品質面には気を使っています。何かあると日本中の銀行に支障が出ます。「品質が一番大事です」の認識合わせを必ずします。品質をある程度保てないと、リリースしないという強い意志を伝えます。もしバグが出たら、それをいかに早く直すかというのも大切にしています。これが出た時が結構大変です。
（Q）機能型組織、初めて知りました。開発当初からこういった組織体制だったのですか？それとも何かの契機で変わった、などでしょうか？
樋口：リリースして30年、何度も変わっています。その時々で組織体制は変わっています。人数が多いと機能型組織です。
（Q）こぼれた仕事に気づかないまま時間が経過するケースもあると思いますが、早く見つけるために取り組んでいることはありますでしょうか？
樋口：基本的には、一般的のプロジェクト管理と大差ないです。「課題ありますか？」という聞き方はしません。本人が課題と思っていないと出てこないので。「何か気になってることはありますか？仕事を進めるうえでの懸念はありますか？」など聞き方を工夫しています。
（Q）心理的安全性、コミュニケーション施策が大事ですよね。こういうのを配慮したプロジェクト内コミュニケーションとか社内コミュニケーションの意識なんてありますでしょうか？対話の仕組みとかオンラインコミュニケーションの仕組みとか。
樋口：基本リモートになって、オンラインのコミュニケーションが主です。Zoomで話さない人、新しいメンバーはなるべく会ったり、集まるタイミングを作ったりしています。手探りで頑張っています。
（Q）セゾン情報さん、昔関わったことありましたが軍隊的なきちっとしたSIerで炎上案件とか全く無さそうなイメージでした。（炎上なんてありました？）
樋口：SIerの部門は別部門となり詳しくはありませんが、例えば製品開発では性能要件が満たせていない事がPJ後半に判明し炎上したことなどあります。
（Q）Slackとかフル活用ですか？
樋口：Slackフル活用です！基本ここでコミュニケーションを行っています。
（Q）チーム組成（メンバー）によって役割（守備範囲）も変わりますか？
久松：都度本人のwillも重視しながら、調整をかけます。
樋口：組織範囲でカバーできない業務などが発生することもあるので、その都度守備範囲は合意形成取ります
（Q）並行プロジェクトで、リソース(要員)が、複数プロジェクト兼務の際に、進捗改善の方策が、ございましたら、ご教授頂きたいです。
久松：優先度を整理し、マイルストーンを細かめに引いて、どっちつかずにならないようにしています。
樋口：該当要員の上長に申し入れ、合意形成取るようにします
（Q）他人事化する人員のやる気を引き出す方法/運用保守プロジェクトにおけるメンバーのモチベーション向上が課題です。テクニックや事例などあればご紹介お願いいたします。
久松：WHYをとにかく伝える。その上で本人のWillに合わせて伝え方を調整する。刺さるポイントを作る。
樋口：PJの意義を伝えるしか無いとは思いますが、その人のモチベーションの源泉がどこにあるのかは人それぞれなので、その人にあった方法を考えて伝えます（社会的な意義、本人の成長、誰か身近な人の役に立つなど）
（Q）みなさま、プロジェクトマネージャーをどのように教育されていますか？
久松：毎週の輪読会 + 失敗することを前提にアサインして、実戦経験を積んでもらいます。(最悪僕がケツを拭けるところまでは割りと好き勝手やってもらっています)
樋口：研修形式でのPJ管理の初歩の学習、PMBOKの学習、後は実践です
（Q）プロジェクト内容を社外に公開できる会社がうらやましいです。。。 プロジェクト管理ツールは何を利用されていますか？
久松： Notion、Jiraを利用しています。
樋口：JIRAとConfluenceを利用しています。
（Q）各開発のPMが同時に介する機会、対話はありますか？
久松：PMが揃って毎朝、朝会をしています。毎週定例会も行っています。他のチームのPMと意見交換しています。毎週ロードマップをみて確認しています。
三村：システムごとにプロジェクトが分かれているので、そこのPMが週一で集まっています。
樋口：プロダクトの担当者が集まっている部署なので、課の定例会などで日常的に会話しています。
（Q）PMは様々な職種を束ねていく役割になると思います。個性豊かで価値観が異なる人材に、どう安心感や希望を与えていくか、MTGセットなど含め話を聞きたく思います。
久松：3ヶ月ごとに目標をセットし、私としてこうなって欲しい姿と、各メンバーがこうなりたい姿の共通部分をまず作ります。そのうえで、その共通部分に向かえているかどうかを毎週の1on1で確認し、調整するようにしています。
樋口：1on1を実施し、他の回答にあるような相手によって好むコミュニケーションを取るように注意しています
（Q）プロジェクトマネジメントを体系的に学習する方法
久松：私自身は叩き上げ+社外のPMに教えてもらっていました。メンバーへは、私が課題図書を決めて、定期的に輪読会を開催しています。
三村：PMBOK。社内研修を行っています。興味がある分野をチームで学習して深めています。
樋口：PMBOK。アジャイルになったとしても、体系立てて学べる。ある程度実践をしつつ、PMBOKを学ぶのがおすすめです。
（Q）チーム内でモチベーションが低いメンバーがいた場合、何か行動しますか。
久松：1on1を毎週行っており、そこでモチベーションの確認をしています。具体で困っていても、抽象度を上げると納得感が出てくるポイントがあると考えており、とにかく対話が重要だと考えています。
三村：1on1。その人のモチベーションをモニタリングしています。それでも難しい場合、その人がやりたいことを探したり、無理だった場合は他のプロジェクトを探すこともあります。
樋口：プロジェクトの目的や意義を伝える。相手が好む伝え方をする。社会の貢献度なのか、社内の誰かなのか、世の中に響くのか、どこに響くものなのかを伝えるようにしています。
（Q）プロジェクトとマネジメントの基礎how-toも、もちろん大切だと思いますが、 非協力的な人財がいた場合の建設的な対応方法、具体的な例を知りたいです。多様性とは云うものの、どれだけ優秀でも調和しない場合はチームメンバーとしない方が良いという意見も多く聞き、実際にその通りだったこともあります。 非協力的な内容もそれぞれだと思いますので、その辺りの具体例、対応例、解決例を知りたいです。
樋口：やる気がない、プラスの感情がない人はモチベーションを上げてもらう必要がある。技術力はあるんだけど、コミュニケーションに難ありの人もいたりする。その場合は、この人とコミュニケーションを上手に取れる人（猛獣使い）を用意します。
三村：コミュニケーションをとっていくなかで、その人のスキルややりたいことはヒアリングして把握する。その人に合うようなタスクを振る。また、知識をつけてあげて取っ掛かりやすくしてあげる。やる気を出す工夫をしています。
久松：スタートアップの小さな会社はカルチャーにフィットしているのかを重視しています。他の人に-1%与えてしまうと、いない方がいいくらいの判断をしています。期待値を明確にして、現状の評価と照らし合わせるようにしています。
（Q）PMのやりがいと、PMをやる上での一番抑えないといけない急所は何ですか？
樋口：やりがいは、自分にある程度の決断権限があるところです。抑えるべき点は、やり切る力が求められます。新しいことや今までにないものを作り上げる仕事です。未知のものがやってきたと感じる人たちもいるので、いかに自分が目指すものを作り上げるかだと思います。
三村：プロジェクトが終わったら解散してしまう。その後もチームの関係性を繋げていくことが大切。コミュニケーションが自分の強みだと考えています。相手を尊重することを意識しています。
久松：ロードマップを決めて、お客さんに使ってもらうものをつくれているところが面白いと思います。
WHYにこだわった上で、納得感の醸成をいかにできるか。様々なスキルはあるが、納得させて目標に達成に向けて推進していく力。
（Q）どうしたらユーザ部署・責任者にFit in Standard の理解を促すことができるのか現行システムでの業務が当たり前で、業務ステップが変わる事を心配し、受け入れてもらうための説明会に時間がかかる。皆様はどうやって納得させていますか。
久松： プロダクトのあるべき姿を解像度高くキーマンに伝えて納得感を醸成しにいきます。
樋口：全員を説得するのは大変なので、該当部門のキーマンが誰なのかを把握した上でそのキーマンの説得に注力します。後はキーマンから部門内に展開してもらうようお願いします。
（Q）ユーザ部署・責任者はシステムプロジェクトは業務範疇外として、プロジェクト定例会への参加率が大変少ない。UAT直前にしてこれでは業務ができないとクレームを受ける。ヒアリング・要件定義から積極参加させるにはどうしたらいいですか。
久松：弊社の場合、「プロダクトこそ経営」のスローガンのもと、プロダクト価値を全社で高めることを最優先にしているので、このような状態に陥っていないため回答できないです。
樋口：PJの初期段階で受け入れテストのテストケースを作成し、ユーザ部門レビューを受けて合意を取った上で以降はテストケースが変更になる場合のみ、定例会に出てもらうなどいかがでしょう？
ユーザ部門としても必要性の薄い会議に出続けるのはつらいかと思います。必要な時に必要な理由を説明して出てもらうようにしてはいかがでしょうか。
（Q）いちばん大変だったプロジェクトは何か そのとき、どう乗り越えたか ・「この会社だから達成できた」と感じたものはあるか
久松：毎週不具合が発生し、新規開発をストップせざるを得ない状況に過去に一度陥ったことです。
その際は、1Qの開発リソースをすべて不具合に対する恒久対応に費やしました。もちろんすべてのクライアント様から納得いただけたわけではないですが、カスタマーサクセス部が協力して クライアント様へ丁寧な説明を行ってもらえたことによって、被害を最小限にすることができました。
樋口：製品の開発終了間際に経営層からPJ要件の認識が違うと指摘を受けたときです。
関係各所と協議、PJ内での対応出来ることできないことの整理、今後のリリースロードマップでの取り込み提示など様々な人を巻き込んで何とかリリースにこぎつけました。
これも開発、サポート、販売などすべての機能を自社で持っているからこそできた対応があったと思っています。
（Q）クライアントから無理を言われても飲んでしまい、後でチームや会社に迷惑をかけて、後悔することが多いです。 交渉が大変苦手なのですが、クライアントの満足を満たしつつ、自社の言い分を通す方法として、どのようなことがありますでしょうか？ また、交渉を学ぶ方法はありますでしょうか？
樋口：SIerではないので、「自分たちの製品がどうあるべきか」を判断軸にしています。要望はお断りすることもあります。ただやみくもにNOを出すのではなく、どんな製品で、何を目指しているからこの製品があるのかを説明し、未来を目指している姿もお話して納得してもらいます。
三村：事業として読み替えての回答です。事業が何を望んでいて、何を求めているのかを整理して、期待値調整をしています。スケジュールで足が出てしまう場合、複数案を提案して、落としどころを作ります。
久松：SaaSなので、個別開発は基本的にお断りしています。要望は製品への期待でもあるので、実現したいプロダクトの世界に沿っているのか？という観点でみて、優先順位を上げることもあります。ビジョンを明確にして、そこと上がった要望を照らし合わせています。
Q&Aコーナーは以上です。
次回のイベントレポートもお楽しみに♪
