インボイス対応を経て感じたPjMとPdMの違い

この記事はクラウドワークスAdvent Calendar 2023 シリーズ2の19日目の記事です。

こんにちは。crowdworks.jp プロダクトマネジメントチームのチャンタマ（@tmchannel）です。プロダクトマネージャーとしていろんなことをやってます。

世は師走、今年を振り返ってみると、やはり一番に思い浮かぶのはインボイス制度ですね。 なんといっても、誰が何を言おうと、何がなんでもインボイスです。
（とまで書いている段階で、今年の漢字2023が「税」と発表されました。ですよね）

2022年10月頃からインボイス対応の担当として（それはもう、本当に！あちこち）駆け回ってきたなかで、PdM5年目にして多くの学び、気づき、そして反省...がありました。 今回は、インボイス制度対応を経て得た気付きをしたためて、今年の締めくくりとしたいと思います。

※臨場感演出のため、以降ではです・ます調ではなく、だ・である調で書きます

自分ならできるやろと思っていた、あの夏

（以下、プロジェクトマネージャー、プロダクトマネージャーをそれぞれPjM、PdMとします）

2022年10月、マネージャーからこんな相談が。

マネージャー「チャンタマさん、インボイスの担当、お願いしてもいいですか？」
チャンタマ「おーっす」

2016年に新卒としてクラウドワークスに入社し、マーケやクライアントワーク、PdMとしてはWebサイト改善もモバイルアプリ改善も、ユーザー向け機能も社内向け機能も、と幅広い経験をしてきたことが少なからず自信に繋がっていた頃だった。

だが、私はエンジニア経験がない。
大規模なシステム開発はおろか、PjMと呼ばれる人と一緒に仕事をしたこともない。
私に本当に求められていることが何なのか、私は完全には理解できていなかったことを後に知ることになる。

インボイス対応で求められたこと

crowdworks.jp のサービス開発は、スクラムを組んでアジャイルに進められている。
PO1人、エンジニア2~4人、デザイナー1人。
だいたいこのような編成で、毎日デイリーを行い、スプリントごとにプランニングと振り返りを行い、必要に応じてチーム外のステークホルダーとコミュニケーションをとるが、基本的にはチーム内で完結する。

だがインボイス対応はこれまでとは異なる様相を呈していた。

絶対に遅れられない期限がそこにはある

インボイス制度の開始は2023年10月。それが絶対だった。

ふだんのcrowdworks.jp のサービス開発にももちろん期限はあるが、そこはアジャイルに、向かう方向が間違っていることに気づいたらやるべきことを見直し、スケジュールを立て直すもの。

だがここはやはり公的制度対応。日本全国のあらゆる課税事業者、経理部署、開発部署が足並み揃えてインボイスの対応をする中で、絶対に遅れられない。ユーザーに迷惑はかけられない。
いつも以上にシビアにスコープを見定め、前提を疑いまくり、国税庁の資料を読み込む日々だった。

ものすごく複雑で、ありえないほどでかい

crowdworks.jpというサービスは、2011年のリリース以降、基幹部分はほとんどそのままで増改築が繰り返されてきた。

今回のインボイス対応に関連するところだけにフォーカスしても、取引の種類は5種類、支払い方法は5種類あり、加えてインボイス発行が可能かどうかの判定¹ã‚’含めると、単純計算で50パターンのケースを考慮する必要がある。 実際には他にも分岐があり、機械的に作成したパターン表は300行にも渡っていた。（最終的にはスコープを削るなどして減らした）

加えて、帳票を発行できる画面が8画面ほどあること、帳票周りのテーブルを新たに作り直す必要があった²ã“となどから、1チームで対応できる範疇をはるかに超えていた。

最終的に、インボイス対応初期から活動していたプロジェクトチームに加え、3チームに協力いただくことになった。関わった人数はマネージャーや経理メンバーも含め総勢30名弱である。

あとあと聞いた話だが、昔をよく知るエンジニア曰く、ここまでの数のチームを横断する機能開発はcrowdworks.jpではほとんどなかったとのことだった。

インボイス制度対応で私に求められたのはPjM的動きだった

• 23å¹´10月の期限は変えられないこと
• サービスの複雑性が高く、影響範囲も広いため複数チーム横断的に動く必要があったこと

この2点から、私はこれまで経験したことのない頭の使い方をする必要があった。

crowdworks.jpのPdMの思考

crowdworks.jpのPdMは施策検討を行う際、ゴールデンサークルでいうWhyの部分を特に重視している。
「なぜやるのか」
「誰のどんな課題を解決するのか」
「誰にどのような価値を届けたいのか」

これは持論だが、Whyさえ定義できていれば、具体的なHow, WhatはPdMだけが考える必要はない、むしろエンジニア・デザイナーと一緒に考えるべきとさえ思っている。

このWhyを重視する思考が全く役に立たなかったわけではないが、インボイス対応において重要だったのはむしろHow, Whatの部分だった。 自身の主戦場としてきた「Whyの定義」が、インボイス対応全体の中では比重が軽かったのである。

そういえばPjMとPdMってどう違うんだっけ

自分のWhy思考があまり役に立たないかもしれないことに少し気がつき始めた頃、ふと思い立って調べた「プロジェクトマネージャー」の定義にこんなことが書かれていた。

IT分野での開発を行うプロジェクトチームの責任者として、プロジェクト実行計画の作成、予算、要員、進捗の管理などを行う。短く、PMと表記されることもある。

具体的な仕事は、開発計画に基づいてプロジェクトの実行計画を作成し、その計画の遂行に必要な人員やリソース（資源）を調達し、プロジェクトの体制を作る。プロジェクトが動き出すと予算、納期、要員、品質等の管理をしながら、プロジェクトが円滑に進むようにする。進捗管理は重要であり、問題や将来見込まれる課題を早期に把握し、適切な対策を事前に講じて、プロジェクトが計画通り進むようにする。

（厚労省による職業情報提供サイトからの引用。太字装飾は筆者による）

やっぱりそうか、と思った。 なんとなく感じていたうまくいってない感の原因はプロジェクトマネジメントにあったのか、とひどく腹落ちした。
PdMがゴールデンサークルのWhyに主軸を置いているとするならば、PjMとはHowのプロフェッショナルなんだろう、と解釈した。

もちろん、スケジュールや予算・品質の管理をやったことがないわけではない。PdMの役割の中に含まれているとは思う。 しかしながら今回の規模では、今までのやり方では太刀打ちできなかったのだ。

今回インボイス対応をおこなった各チームはそれぞれ、フロントエンドも対応可能 / フロントエンドが得意なメンバーがほぼいない / 技術的負債解消をミッションにしている、などの特徴があり、エンジニア経験がなく浅い知識しか持たない私には各チームにどのようにお願いしていいのかすら大変悩ましかった。

適切なタスク分解や複数チーム横断のタスク差配の難易度が高く、サービスの複雑度により見積もりも出しづらい中で、どうやってスケジュールに間に合わせるか、私には打ち手の引き出しが少なかったのである。

最終的に、@hihats さんやEMの方々のお力添えにより、残タスクを全てmiroに洗い出し、どのチームが対応しているか、見積もりがどのようになっているか、まだアサインできていないタスクはどれか、を可視化することでなんとかリリースすることができた。
（その節は、本当に、本当にお世話になりました）

まとめ

インボイス対応の経験を経た、個人的なPdMとPjMの違いは以下の通りである。

• PdMとPjMは、同じ業務内容をすることはあっても思考の主軸が違うため、それぞれの強みを持っている
• PdMはユーザーへの価値提供に責任を持ち、Why（なぜやるのか、誰のどんな課題を解決するのか）に強みを持つ
• PjMはプロジェクトの遂行に責任を持ち、How（実行計画や人員、リソース、品質などの管理をどのように行うか）に強みを持つ

そして施策や機能によっては、PdMやPjMという役割にとらわれずに、目の前の仕事のために何をすべきか愚直に考え取り組むことが重要であると改めて感じた。

これまでに経験したことがないほどの、そして今後もあまり経験することが無いであろう規模の機能開発を経験できたことは、本当に良かったと思う。
今後もcrowdworks.jpの発展のため、全力で取り組んでいきたい

---

【We're hiring!】
クラウドワークスでは様々な仲間を募集しております。
ご興味のある方は以下のリンクからご応募ください！
https://crowdworks.co.jp/careers/

---

1. crowdworks.jpでは、媒介者交付特例を用いているため、受注者がインボイス事業者かどうかによってインボイスを発行してもよいか判定を行う必要がある。弊社自体がインボイス発行事業者であっても、すべての帳票をインボイスにできるわけではない。↩
2. 帳票発行機能は機能リリース当初からほぼ手が加えられておらず、今回のインボイス対応にそのまま耐えうる設計にはなっていなかった。↩