社内で活躍するプロジェクトマネージャーへインタビュー！「ConnectPM」の取り組み
Sun*には若手からシニアまでさまざまなプロジェクトマネージャー（以下、PM）が在籍しています。メンバーの持つ経験に基づいた仕事術を明文化して、特に若手メンバーへ共有する社内イベントが「ConnectPM」です。さまざまな強みを持つPMメンバーへ公開インタビューを行い、マインドセット・価値観、具体的なスキル・ノウハウ、キャリア観などを掘り下げています。
今回は、2024年に新卒で入社し、翌年に開催した全社総会「Sun* Annual Award」でBest Rookie Award（最優秀新人賞）を受賞した岩佐へのインタビュー。岩佐は与えられた役割以上のバリューを発揮、アカウントマネジメントチームを兼務するなど、挑戦を重ねてきました。日々の壁の乗り越え方や役割を広げる工夫、そして仕事を楽しむマインドなど、たっぷり話を聞きました！
※この記事は、2026年4月に実施された社内向けイベント「ConnectPM」のインタビューを基に再構成しています。
OJTで学んだ「三方よし」の視点と、専門用語の壁を乗り越えた工夫
―まずは入社後のOJTのプロジェクトから教えてください。
私はエンハンス開発（機能改修）のフェーズのプロジェクトに入り、役割としては大きく2つありました。1つは、改修部分の画面のすり合わせや画面イメージを考えること。もう1つはベトナム側が作ってくれた表示項目などの日本語表記を変更する作業でした。OJTでの一番の学びは、当時のリードPMから教えてもらった「三方よし」の考え方で、今でもプロジェクトのなかですごく大事にしています。
―近江商人の言葉ですね。岩佐さんの「三方」とは具体的に何を指すのでしょうか？
プロダクトの開発を依頼してくださる「クライアント」、実際に完成したプロダクトを使う「エンドユーザー」、そして私たち「開発チーム」の三者です。プロジェクトに入って目の前のタスクに集中しすぎると、「とにかく仕様書通りに画面設計を書く」「テストを実行する」といった作業自体が目的化してしまいがちです。でも一歩引いて見たときに、「この仕様は本当にお客さんにとって価値があるのか？」「使うユーザーにとって使いやすいのか？」「開発チームにとって無理のない設計になっているか？」を客観視する大切さを教えてもらいました。
ただ言われたものを作るのではなく、関わる全員にとって良い関係性やプロダクトを作ることができているか常に確認する意識は、どのプロジェクトに携わる上でも活きていると感じます。
―OJTで感じた仕事の壁はありましたか？
ミーティングに出てくる単語が全く分からないのが最初の大きな壁でした（笑）。対策として、愚直に2つのことを実行しました。1つは、議事録を取りながら分からない単語をひたすら抽出し、自分専用の「単語帳」を作ること。もう1つは、その単語に連動する周辺知識もセットで調べることです。具体的にはスプレッドシートを開き、左列に単語、隣に意味、そして一番右に「どういう文脈でその単語が使われたか」というメモ列を作って管理していました。単語の意味だけでなく文脈まで残しておかないと、使うシーンによって解釈が変わってしまうことがあるので、文脈の記録は特に意識していましたね。
―並行してもう1つプロジェクトに入ったんですよね。
広告をAIで審査するシステム開発のプロジェクトに1カ月間入っていました。私の役割は大きく2つあって、1つはテスト、もう1つがプロンプトのチューニングでした。
プロンプトチューニングのためにやっていたことは大きく2つあります。1つは、どういう構成で書くとAIに指示が通りやすいのかを理解することです。当時のリードPMの方に教えていただきながら、プロンプトの型を学びました。もう1つは、プロンプトでどこまでできるのかを試すことです。例えば、審査したときに広告の指摘箇所を丸で囲んでほしいという要望があったら、それがそもそもできるのか、どういう形なら実現できるのかなど、「AIが今どこまでできるのか」をいろいろと試していました。
―広告審査の基準は複雑で曖昧だからこそ人が審査してきたと思うのですが、どうやって言語化や構造化を進めたのでしょうか？
まず、言語化については、とにかく曖昧な表現を潰すようにしました。例えば「恐怖心を与える表現はNG」といった曖昧な審査ルールに対し、具体的にどういう単語や事例が当てはまるのかをAIに学習させるため、過去のいろいろな広告を当てはめてみたり、一般的に出てくるワードをAIでリストアップしたりして、人の感覚を言語化していきました。
構造化については、「どのAIには、どういう文法や型で伝えなければいけないか」を整理してプロンプトの型を作ることを中心に進めていました。
多くのプロジェクトで重ねた試行錯誤と工夫
―次に、C社のプロジェクトはどのようなものでしたか？
エンハンスのフェーズで、ベトナムからのQA対応や、ベトナム側が作ってくれた画面設計書のレビューをしていました。このプロジェクトは、今まで入った中でも一番運用プロセスがしっかりしていました。
Backlogのチケット名やテンプレートがしっかりあって、各種ドキュメントもテキストではなくフロー図で細かく仕様整理されていて、お客様やベトナムと共通認識が取りやすくなっていました。情報も全部Backlogに集約されていて、決定事項もすべて書くスタイル。こうしたプロセスがうまく回って、エンハンスもうまくいっているな、と感じました。
―実際に、その後の案件で活かしたことはありますか？
「情報の集約」は他のプロジェクトでも参考にしています。Slack、Figma、スプレッドシートなどあちこちでやり取りしているものがあるので、どこか1つに情報を集約するように心がけています。
―次のD社はどのようなプロジェクトでしたか？
本開発フェーズのプロジェクトで、2週間単位のスプリント（2週間ごとに設計からテストまでを一通り行い成果物を出す進め方）でアジャイル開発を行っていました。私の主な役割は、テストケース作成・実行、受入要件の調整、デモ、ベトナムとの連携などです。 業務を進める上で、スプリントごとに対象機能を事前に把握し、「いつテストを作成し、いつ実行し、いつデモをするか」という一連のフローをスケジュールに落とし込みました。スプリントが変わってもこの運用フレームを崩さずルーティン化して回し続けることで、タイトなスケジュールでもブレずにタイムマネジメントを維持することができました。
―エンハンスと本開発の違いとして感じたことは？
本開発は、手探りなものが多いと感じました。例えばベトナムとのコミュニケーションでは、レビューフローが整備されていなかったので、どのタイミングでレビューするのかわからなかったり、お客様側でどの方がOKと言ったら進めて良いのかが不明確だったり。仕様も、作る人によってばらつきが出たり、ルール化されていなかったりと、確認・整備しながら進めるところに違いを感じました。
―次のプロジェクトは、2社同時に入っていますね。
F社は本当に立ち上げ段階の要件定義（要望・要求を整理して、開発するシステムの機能や仕様などを決定する上流工程の作業）フェーズで、E社は開発が終わったテストフェーズから入りました。E社はすでにモノがあり、テストしながら機能や仕様のキャッチアップがスムーズにできたので、どちらかというとF社の方に時間をかけていました。
―若手のPMがテストを行うことの意味をどう考えますか？
業務に慣れるステップとして、最初にテストを経験できたのはとても良かったと感じています。実際の仕様を深く理解できるからです。当時は指示通りに動かす作業としてこなすのではなく、「どういう構造になっているんだろう」と意識しながら進めていました。
もし単調に感じてしまう場合は、一旦テストケースから離れて「ここを操作したらどういう結果になるか」を自分で予想しながら触ってみるアプローチも面白いのかなと思います。予想と違った挙動から新たな仕様の分岐に気づくことも多いので、探求心を持ってゲーム感覚で動かしてみるのが個人的には好きです。
―次のG社ではどのようなことをしたのでしょう？
ビジネスの要求・要件定義のフェーズで、UXチームが作った機能のアイデアを開発に落とし込みました。業務フローを作ったり、全体のスケジュール管理やチケット管理、ドキュメント作成などを行っていました。
私以外にPMが2人いて、1人が全体統括のPM、もう1人がテックを見るPMの方で、3人で動きました。私は一緒に動いて、穴埋めをするようなところから、徐々に仕事を広げていきました。
―プロジェクトのなかで意識していたことは？
目の前のタスクをきちんとするのは大前提として、「今埋まっていないものは何だろう」と常に探しました。小さいところでは、メンバーが何のツールのどんなアカウントを持っているか一覧にまとめたり、プロジェクトメンバーの休みの予定を可視化したり、そういう整理から入っていきました。
あとは、みんなの頭のなかでは思っているけど資料化や図式化されておらず、共通認識が取れていないものをピックアップして、Miroなどで図を書いて確認したり。その上でリードの人たちに「私にできるタスクはありませんか？」と、巻き取れそうな内容を徐々にもらっていきました。
―次のH社についても教えてください。
主に追加開発のフェーズで、もともとの役割は画面設計に関するベトナムのレビューと進捗管理をする予定でした。ただ、クライアント側で追加開発の要件定義やデザインが終わっていなかったので、要件定義からやることになり、業務フローを書いたりワイヤーフレームを作ったりしていました。スクラムで回していたので、要件定義をしている機能もあれば、画面設計をしている機能、実装している機能もある、という感じです。
―一気通貫で関わるなかで、得られた視点はありますか？
情報の分断が起きないように運用フローを整えないといけない、と強く思いました。要件定義と画面設計でやり取りするお客様が違ったり、途中から入ってくる方がいたりして、情報が散乱しがちだったので、BacklogやSlack、QAシートのなかに情報を集約して分断が起きないように工夫しました。なおかつ、要件定義フェーズからリリースフェーズまで同じ情報量が保たれるのがすごく大事だと思うようになりました。
―フォーマットやルールの統一で工夫したことは？
スプレッドシートやSlackのcanvas（Slack内でテキスト、リンク、ファイルなどをまとめて共同編集できる専用スペース）にルールを書きました。案件でメインで使うドキュメント一覧と、各工程のルールを書いています。例えば、業務フローだったら「誰がOKしたら何のシートをどういうステータスに更新して次のステップに進むか」、画面設計だったら「修正時はどういうフローでコメントを入れるか」などをテキストでまとめました。
―ベトナムチームとのコミュニケーションで気をつけたことは？
2つあります。1つは端的に返す、長々と文章を書かないこと。もう1つは背景をちゃんと伝えることです。業務フローやワイヤーフレームを作ったのは日本側だったので、「ユーザーがどういう操作を期待しているか」「何をやってほしくてこれを作っているのか」という背景を伝えました。そうするとベトナム側から「こういう仕様もできるんじゃないか」と質問や提案をしてくれるようになり、より良くするためのきっかけとなったので、伝えて良かったです。
兼務で見えた「全体を俯瞰し、逆算して動く」視点
SAA（Sun* Annual Award）のBest Rookie Awardのトロフィーと
―PD（Principal Director：セールスやアカウントマネジメントを担う役割）のアシスタントを半年ほど兼務していましたよね
メインは新規提案のサポート（一緒に提案書を作ったり相談に乗ったり）と、既存のアカウントマネジメントのサポート（コストシート作成や契約確認、既存の提案）をしていました。
―新しく得られた視点はありましたか？
「全体を俯瞰して逆算する目線」が得られました。PMは目の前のタスクに集中してクリアすればOKと思いがちですが、PDは「いつまでに契約を締結するか」から逆算して、営業事務への見積依頼、そのための資料作成など全体を見ながら進める必要があるので、PMだけでは身につかなかった力だと思います。
―これまでのプロジェクトを振り返って、一番嬉しかったことは？
最近嬉しかったのは、関わる範囲を上流へ広げられるようになったことですね。
とあるプロジェクトに画面設計の段階から入る予定だったのですが、キャッチアップのために自分なりの業務フローやワイヤーフレームを作っていたんです。それをリードの人に見せたら「これだけやっているなら、この内容をもとに提案して、要件定義から入ろうよ」と言っていただき、結果的に要件定義から一緒に入れることになりました。
―素晴らしいですね！「自分でタスクを取りにいく」というマインドはどこから来ているのでしょうか？
元々、前に進まずストップしている状態やモヤモヤしていることが気になるタイプなんです。「悩んでいるならクリアにしたい」「とりあえず動かしてみよう」という部分が性格的にあると思います。また、過去のプロジェクトで「自分が動いて確認しに行けばよかった」と後悔した経験があるので、気になったことはタスク化して、自分から聞きに行こうと考えるようになりました。
PDを兼務したときの挑戦の原動力は、ただただ「仕事を楽しくやりたい」です。楽しくするために知りたいことを知りに行く、新しい景色が見えそうというワクワク感や好奇心が一番の原動力になっています。
―ハードな局面を乗り越えるときの向き合い方を教えてください。
「とりあえず動かす」ことを頭に置くようにしています。動かしてみた後の不安や感情は捨てて、やることに集中して物事を前に動かすよう心がけています。
―影響を受けた本などはありますか？
大学に入る前に読んだ、世界銀行で活躍された小野節子さんの手記です。当時の環境の中で、さまざまな壁を乗り越えながら世界に影響を与えていく姿をみて、「自分も色々挑戦してみよう」と思ったきっかけになりました。
―すべて振り返って、これまで学んだことを教えてください。
「ルール化することがプロジェクトをうまく回す」ということと、「まずやってみる」ことです。業務フローなどもベースを作ってみてダメなら修正すればいいし、良ければアップデートしていけばいい。こういう、どんどん動いていくスタイルは今後も継続したいです。完成度30%でもまず叩き台として試してみるのが大事だと思っています。
プロフィール
岩佐 杏花（いわさ きょうか）
関西の大学を卒業し、新卒でSun*へ入社。ポイ活アプリなどの開発プロジェクトにPMとして参加し、追加開発フェーズにおける要件定義からテストまで一例の工程を担当。また、人材サービスのビジネス要件定義工程において、BTC（Business/Technology/Creative）の各メンバーと連携し、要件整理・合意形成・進捗管理を推進。2025年SAA（Sun* Annual Award、年1回のオフライン社員総会）でBest Rookie Awardを受賞している。
ConnectPMスタッフ
Mr Keita（イベント主催・記事原文執筆）
矢島杏（イベント運営）
河合優大（デザイン）
記事に興味をお持ちいただけたら、Sun*の採用サイトもぜひご覧ください！