仕事の引き継ぎは、その業務だけじゃなく、責務にも注目すると良さそう、という話

ものづくり組織をいい感じにしていきたい菅沢です。普段は、エンジニア採用やプロダクト組織の強化にまつわる必要なことを必要に応じて突破するマンみたいなことをしています。
この記事は、Speee Advent Calendar 2022の1日目の記事です！
今年もやってきましたね！AdventCalendar！
Speeeは去年2年ぶりの参加、5年ぶりの完走ができました！🎉🎉

tech.speee.jp

今年も完走目指してみんなで楽しくやっていきたいと思います！そんな2年連続の完走を目指したAdventCalendarの初日です！やるぞーーー！（🙋‍♀️：おーーー！）

個人的に2022年を振り返ると、複数の新たな取組や新たなメンバーのJOINがあり「仕事を引き継ぐ」というシーンに多く関わった年でした。そういった中で、仕事の引き継ぎは、その業務だけじゃなく、責務に注目するのが良さそう だな、と思いまして、その学びをブログとしてアウトプットしようと思います。

私自身今の役割の前は3～4年ほどPdMをしていて、ある瞬間はプロダクト開発に注力して動き、ある瞬間はBizDev的に営業やマーケに注力していて、、という動き方をしており、今思うとイケてない引き継ぎをしてしまったなあと反省しています。そういったやっちまった経験もしている中で、こういう考え方や向き合い方で対峙するのが個人的に捉えやすいなと感じた話になります。

私と同様に、PdMだったりPjMだったり、複数のステークホルダーとの協力が必要になる方の「そういう考え方もあるなあ」みたいな発想の切り口になるといいなと思っています。

業務と責務
なぜ業務だけではなく、責務にも注目するのか
- 引き継ぎを業務だけに注目した場合
- 引き継ぎを責務にも注目した場合
責務を引き継ぐ上で個人的に大事にしたい3つのポイント
まとめ
お決まりの

業務と責務

本来の言葉の意味とはずれているのかもなのですが、、、

本記事内では、業務という言葉を「様式の決まったタスク」や「（ある一定の決まった）手続き」を意味するものとして扱います。例えば、XXXの報告や、開発Issueを作る、みたいなそういうイメージです。

同じく、責務という言葉を「単一の目的を達成する活動」を意味するものとして扱います。
例えば、月曜日のXX時までにプロダクトチームが今週のスプリントで取り組むバックログからタスク分割ができる状態にする、みたいなそういうイメージです。

なぜ業務だけではなく、責務にも注目するのか

なぜ責務にも注目すると良さそうなのか？という部分を整理したいと思います。
シーンとして、

あるプロダクト開発チームのPjMの交代にともなう引き継ぎ

を前提に話していきます。

先に結論を書くと、仕事は基本的に、Why-What-Howの一貫性 を保ち続けることが重要だと思っていて、その全体像を見通すためには、責務にも注目すると良さそうだと考えています。

引き継ぎを業務だけに注目した場合

まず、業務に注目した場合です。

PjMの業務は会社や、人によって異なるかと思いますが、ざっくり以下のようなものがあるかとと思います。

営業やマーケをはじめとする関連部門からの開発要求の吸い上げ、ヒアリングを通じて課題発見する
一定期間（数ヶ月程度）の開発計画をプロダクト開発チームと作成する
上記を関係部門と合意形成する
開発計画の進捗を報告する
開発計画に対する課題へのアクションをプロダクト開発チームと考え、実行する
ユーザーストーリーや開発Issueといった、開発要件を作成する、、、etc

業務に着目する場合、これらをタスク的に一覧化し、どうやってやるか？をマニュアル的にまとめ、
そのこなし方を引き継ぎ先の方に伝達していく、という動きになると考えています。

良い点は、

「引き継ぎの時点」での、手順や業務のやり方は網羅的に引き継がれる
マニュアルというドキュメントを常に参照することで、もともとやっていた業務を同じように実施することが可能になる

といったところでしょうか。

ただ、成長著しい会社だと、サービスの変化、組織の変化が多く、その業務も常に変化していきます。
そうなると、引き継がれた先の方は、その変化の中でもともとのマニュアルを土台に業務を改善していったりすることになります。
つまり、業務というのはあくまでHowであり、変化するものだと捉えることができます。

そうすると、大事なのは、変化しながらもWhy-What-Howの一貫性 を保ち続けることになります。
そこで大事なのが「なぜその業務が、そういった手順や内容で実施する必要があるのか？」という視点です。

どうしても組織が拡大したり、サービスが変化すると、もともとやっていた業務の連携先が増えたり、手順が増えたり、、、と肥大化しやすいと感じています。業務が肥大化し、無駄な手続きが増え、本来果たしたいと考えていた責務を果たしづらい状況に自ら追い込んでいってしまう、、、という状況を避ける必要があります。

そこで、そもそもその業務を取り巻く、Why-What を捉えようとしたときに、視点として責務にも注目したいと考えるようになりました。

引き継ぎを責務にも注目した場合

責務にも注目した場合は、前述のような業務だけでなく、 PjMが担っている責務に注目して整理します。

PjMの責務は会社や、人によって異なるかと思いますが、ざっくり以下のようなものがあるかと思います。主にその人が担っている事業のKPIに紐づくものになることが多いです。

一定期間の開発計画をプロダクト開発チームと協力して完了させる
開発計画を実行する中で発生する追加の開発や、新規の問い合わせを適切に開発計画に折込み、チームが向き合うべき計画を明確にする
月曜日のXX時までに、プロダクトチームが今週のスプリントで取り組むバックログからタスク分割ができる状態にする、、、etc

これらの責務に注目し、

なぜその責務を担っているのか？　（＝Why-What）
どういった手順や業務によって現状その責務が担われているのか？（＝How）

をそれぞれ言語化していくことで、Why-What-How が整理された引き継ぐべき内容が明確になります。

このように、責務にも注目することで、引き継いた後での、サービスや組織の変化の中で、ブレずに向き合う軸としての「責務（Why-What）」と、それを担うための「現時点の業務（How）」が明確になりました。
そうすることで、

ただ、成長著しい会社だと、サービスの変化、組織の変化が多く、その業務も常に変化していきます。そうなると、引き継がれた後任の方は、その変化の中でもともとのマニュアルを土台に業務を改善していったりすることになります。つまり、業務というのはあくまでHowであり、変化するものだと捉えることができます。

というような、変化の中でも、引き継がれた後任の方としても Why-What-Howの一貫性 を意識しながら、自身の強みやチームの強みを活かしながらHowを工夫しやすくなるんじゃないかと考えています。

個人的には、よくいる引き継ぎの上手い人、引き継ぎマニュアルづくりの上手い人は、こういった観点をもっているからどんな状況でもいい感じに引き継ぎをされているんだろうな、と思ったりしています。

責務を引き継ぐ上で個人的に大事にしたい3つのポイント

全部引き継ぐことが大事ではない

責務を整理すると、ついつい全部を引き継ぎたくなってしまうのですが、大事なのは、Why-What-Howの一貫性 です。よって、目的に対してシャープでシンプルであることのほうがより重要だと考えています。

引き継ぎ元の方もサービスや組織の変化の中で、初期よりも多くの責務を担っていくことが多いと思います。それが無駄ということはないです。ただ「目的に対してシンプルにできるはずだ」という視点をもち、場合によっては責務を引き継がない、捨てる、という判断もできると良いと思っています。

Fatな責務は分割してチームで受ける

また、パワフルな方や長くいる方であれば、かなりモリモリな（Fatな）責務を担われていることも多いかと思います。それはその人だからこそなし得た状態であり、いい意味で属人的だということでもあると思います。

そういったある人でしか担えないFatな責務をまるっと引き継ごうとすると、基本的には「引き継ぎ先がいない、、、」みたいなことになります。そういった状況を放置するとよりFatになり、個人にとっても組織にとってもあまりヘルシーでない状況が加速していってしまいます。

そういった場合は、今になっているFatな責務を1つ1つ分割し、ある特定の個人に引き継ぐのではなく、複数の相手やチームの仕組みで担えるような引き継ぎ方が重要です。合わせて前述の

「目的に対してシンプルにできるはずだ」という視点をもち、場合によっては責務を引き継がない、捨てる、という判断

によって、できるだけシンプルにすることが重要です。

成長を前提に引き継ぐ

最後に、成長を前提に引き継ぐということです。
サービスも組織も、引き継ぐ後任の方も毎日成長していきます。
よって、引き継いだday1では担いきれないとしてもday30には、day100にはどうにかなっていることのほうが多いです。
そういった、未来に対してポジティブ、楽観的になる、という心持ちがとてもヘルシーだなと思っています。

むしろ、その過程のTry＆Errorで身につけた学びや成長があるからこそ、未来の大きな変化に適応することができるようになると思っています。
もちろんその分引き継いだあとのサポートを自ら担ったり、そういった責務をだれかにお願いしたり、といった工夫もセットになります。

引き継ぎというとその直後の上手く引き継げてない状況を心配になっちゃったりすることも多いのですが、そういった心持ちで前向きにやれると個人的にはすごくいいなと思っています！

まとめ

業務(How)の引き継ぎで責務(Why-What)にも注目して対峙するといい感じに向き合えるなと感じている、という話でした！
実際に数ヶ月前にPjMの方の引き継ぎをそのように行ったのですが、非常にいい感じにできました。

そしてお気づきの方もいるかなと思いますが、この考え方はシステム開発の考え方を多分にサンプリングさせてもらっています。

あるシステムを移行する際に、移行後もきちんとサービスが意図したように動き続けるように、どう移行していくのか？という取り組みが元ネタです。
また、Fatな責務とかも、よくある Fat Controller / Fat modelとの戦いのお話から学んだ観点です。

システム開発の多くの知見やプラクティスは、
変化し続けるサービスに対して、今も未来もそれに整合したシステムであろうとし続ける挑戦の歴史だと思っていまして、「変化に向き合う」上での多くの知見に溢れており、色々なシーンで活用できるな、と感じています。

こういった観点を得られたのも私自身が、PdMやHRといった色々な役割を1つの会社の中で体験させもらっているからだなと感じています。
貴重な体験で得た学びをきちんと言語化してちゃんと還元していきたいなと、改めてもっとアウトプットしていきたい所存です！