“やります”ドリブンで生まれた負の連鎖を断ち切るために　PMの「やるべき業務」「やらなくていい業務」を整理する

前川氏の自己紹介

前川裕一氏：では「業務範囲はどこまで？」という勉強会のところで、「やらないことを決める」みたいな、ふざけたタイトルでやります。アルプ株式会社の前川が発表を始めます。

アルプでPM（プロダクトマネージャー）をやっていて、サブスクリプションビジネスの契約・請求管理の仕組みの「Scalebase」を開発しております。もともとはエンジニアからPMになった枠ということで参加しています。

新卒からモバイルアプリエンジニアをやりつつ、アルプに来てからもバックエンドエンジニアをやって、アルプで2022年からPMにジョブチェンジをして、その開発経験を活かして（今は）外部システムとの連携などを主に担当しています。

2022年pmconfのスポットスタッフをやって、2023年は通年スタッフをやっております。よろしくお願いします。

なぜPMの業務は多いのか

「エンジニア出身PMの業務範囲は？」というと、「もともとPMの仕事って多いよね」ということが一貫していると思います。（スライドを示して）スマートバンクのPMの森口さん（森口貴之氏）の記事から持ってきた図ですが、色の付いているところをPMがやっているという話です。

ここにエンジニアの経験が入ってくると緑のカードの部分も入ってきて、「もうほぼやれないことないじゃん」みたいな感じになって。とにかくやろうと思えばやれることはなんでもできるという状況になりやすいです。

特に僕はアルプの創業期に入社をしているので、そのシステム側の話も一番わかるし、内容もわかっているみたいな感じなので、「本当になんでもやれます」という状況になってきています。

PM業務がなんで多いのかという話ですが、PMって、基本セカンドキャリアでやっている人が多いかなと思います。なので、その経験上、思考が広範囲に及んでいるし、例えば会社の歴史的背景を理解しているみたいな。2022年の大規模調査のレポートでも（PMになる）1、2、3個ぐらい前には別の仕事をやっていたという人はやはり多いなという印象です。

PMあるあるの「負の連鎖」

PMあるあるなんですが、“やりますドリブン”でがんばっていろいろなことをやっていくんですが、けっこう時間が足りないというような話になる。

時間が足りなくなってくると目の前の作業に追われてしまって、場当たり的な作業になって。僕は特に開発を含めてやっていたりしたので、場当たり的な作業がまた次の問題を起こしてしまって、それがまた目の前の作業になってきて、負のサイクルに入っていくみたいなことになりました。

「○○さん、いつも忙しそうなので声をかけられなかったです」みたいなことを言われたりすると、「あ、やばい……」みたいな。けっこうしんどい状況になってくる。

「やります！」と言うのは簡単なんですが、こうなる前に「やりません！」と言えるようになっていきたいなと考えて今回の発表をしています。

やらないことを決める重要性

やらないことを決める重要性は、やはりPMをやっているとプロダクト愛が強いので、何でも自分事化して、それがストレスになってしまうんですが、そこから（自分を）解放して、時間とか心身にまずはゆとりを持ちましょう、と。

チームや個人の目標、集中すべきことを明確にしていくことで時間ができた分、意思決定とかアウトプットの質が上がってくるかなと。それで自分がボトルネックになる状況も回避していけるかなと思います。

「やらないこと」をどのように決めるか

どのようにやらないことを決めるのかというのは、PMがけっこう曖昧な職種、どの会社でもけっこう違うので、社内でPMに求め（られ）ていることや、自分の職責をまずは定義してみましょう。その上で、自分のミッション、やりたいこととかを改めて整理する。その上で「自分が積極的に関わるのはここだよね」ということを整理していく。

そこまで来たら実際に、「じゃあどんな業務があるのか」というものをテーブルに乗せてみます。そして、やること・やらないこと、個人でやること・チームでやることに業務を分離していって（いけば）決めることができるかなと。

やるべき業務の整理方法

やるべき業務については、まず「自分がそもそも時間をどれぐらい作れるんだっけ」と。どうしてもやらなきゃいけないことはやはりあるので、そういうものを削り、どういうふうに時間を使えるのかを把握した上で、じゃあ業務は誰がやるべきなのか。自分で本当にやるべきなのか、それともより適した人がいるのか。もしいる場合は任せてしまいましょう。

その人自身ができないとしても、スキルトランスファーをしていくとか、委譲していく。そうした整理をした上でも、まだ「1週間で全部やりきるのは大変です」ということがあるのであれば、フォーカスを切り替えていきましょう。個人だったら、今週は実装をやって、来週は要件整理にする。チームだったらSwarmingしましょうという。

Swarmingが何かというと、例えば僕の場合は自分のチームでみんながやっていることを可視化していて。「この人はこの領域のこの開発をやっている、この人はこの領域のこれをやっている」ということを可視化しているんですけど、そこをできるだけ小さくして、みんなで一緒に入っていけるように（しています）。そうするとチームで助け合えるし、集中すべきことがどんどん少なくなっていく。それでアウトプットの質も上がっていくとなります。

なくせない業務がないかも考える

やらなくてもいい業務もあると思います。まず、そもそも（その業務自体を）なくせないかを考えていきましょう。なくせない場合は非同期でできないのか。例えば週次の定例で報告だけしているようなものだったら、参加しなくても「ここに書いておいたので、あとで読んでおいてください」というのもぜんぜんできるかなと。

あとは、そのチームでもいろいろ活動や仕事をしていると思うので、その中でやらないことの認識を合わせていく。例えば、やらないことリストを上げたり、デシジョンツリーを使ってやるべきこと・やらないべきことを判断する。RACI（Responsible、Accountable、Consulted、Informed）チャートで誰がどんな権限を持っているかを正しく把握する。それをやってみても「どうしてもなくせないよ」という場合はチームで持ち回りにしてみるとか。そういうアイデアがあるかなと思います。

（先ほど）ちょっと紹介した「やらないことリスト」と言っているものは、スクラム開発の文脈でよく言われるものです。チームで最初に集まってワークショップみたいなことをやって「このチームで大事にしていることは何だ」と（共有する）。その上で「こういうことはやらないよね」というものを言語化して、みんなで共有していくという会です。

デシジョンツリーとかは、何か仕事があった時に一番上に置いて、それをやる時にどんなプランがあるかを分岐して書いていって、それぞれの良いところと悪いところを上げて、それを判断した上で最終的にやるかやらないかというのを表にしていくようなツールです。

やらないことを決めた結果起きたこと

こういったことをやった上でやらないことをどんどん決めていった結果、僕自身でいえば（もともとは）週の半分以上を会議で使っていた時もあったんですが、半分以上を思考とか手を動かす時間にできた。やるべきことに充てる時間が増えました。

チームではベロシティが安定したり機能開発が安定化したことで、納期が読みやすくなって、以前よりチームのリリースが安定するようになってきました。

という感じで、やらないことを決めることもやることです！　というのが今日のお話でした。ありがとうございました。