開発一筋10年選手がいきなりPMになって思ったこと
こんにちは、胡椒です。
ナビタイムジャパンでアプリ版『NAVITIME Travel』を担当しています。
はじめに
この記事を書こうと思ったのは、タイトルの通り、これまでアプリ開発を中心に仕事をしてきましたが、心機一転プロジェクトマネージャー（以下PM）という立場に転向してから約1年が経過したからです。
この1年でPMとしてのタスクをスムーズに行うために、どうすれば良いと感じたのかを中心に記載します。まだ1年というのもありますので、あくまでもPM1年目の振り返り程度に捉えていただけますと幸いです。
なぜPMになろうと思ったのか
将来への不安 - 今までの生存戦略
よくあるキャリアプランの議論として「スペシャリストを目指すのか？ゼネラリストを目指すのか？」というものがあるかと思います。
私はスペシャリストとして生き残る自分自身をイメージできなかったため、組織の遊撃手として生き残ると決めてこれまでの開発に取り組んできました。具体的にはAndroid開発のみならずiOS開発も同時に行い、さらにはサーバーサイド開発も行う、と開発できることを増やし、組織の開発リソースに空きがあればどこにでも入ることができるようにする。というスタイルです。
将来への不安 - 開発ができることの価値への疑念
ところが近年、この「何でも開発できる」ということの価値が揺らいできたと感じるようになりました。開発以外の職種の方が開発に入り活躍されている事例が増えました。さらに、生成AIの登場で知識がなくても一定レベルの開発ができるようになることのハードルは格段に下がりました。
これらを踏まえて、少なくとも自分の技術レベルでは開発のみできるだけでは価値を提供し続けられないと思うようになったのです。
遊撃手としての範囲を広げる
そこで「遊撃手」としての幅を広げてみようと思いました。ちょうど良くPMができる機会に恵まれたので、まずは1年やってみようというつもりでPMを始めてみることにしました。
プレイングマネージャーとして生き残る
私は開発をメインに仕事をしてきました。PMになったからといって開発を一切辞めてしまうのはもったいない。
そこで、開発は行いつつPMとしてプロジェクトの運営を回せるように工夫をしてきました。（前述の通り、あくまでもPM1年の振り返り程度に捉えていただけますと幸いです。）
PMになりたてのタイミングで感じたのは「思っていた以上に開発に集中できないな？」ということでした。原因を考えた結果、タスク調整など、PMとしての業務に追われて単純に開発時間が取れないこと、開発オンリーの時と比べて開発にのみ集中する時間が確保できていないことの2点が原因であると考えられました。
そこで後述する工夫をとりいれることで、それまでは週5日のうち、1日も開発に集中できている実感がなかったのですが、現在は、開発に集中することができる日を2~3日確保できるようになり、開発者として最低限のパフォーマンスは発揮できるようになったと感じています。
軸を決める。集中する
大まかな方針はなるべく管理コストを減らして自分の開発時間に充てるというものです。
プロダクトを運営するにあたり、やりたいことや組織的に求められることが多々あると思います。その中で重要なのは、最優先の事だけを進めることです。それ以外は一旦、後回しにします。これにより、何かタスクが発生したとしても優先順位が低いため一旦後回しにできるようになります。
ただここで気をつけたいのは、関係者全員に合意を取るという点です。すべての人間が同じ方向に目を向けているようにし、調整することを減らすのです。
私のプロジェクトの場合は初めの半年間はプロダクトの主要機能の1つのUX改善にのみ集中するように進めました。現在はプロジェクト目標を複数設定し、その中でも特に注力したい項目を決めました。目標実現のための施策検討はメンバーに一任しています。実際のメンバーの取り組みや心境については下記記事でよくまとめてくれているので、よろしければご覧ください。
ボトムアップ土壌を作る
サービスには定期的なアップデートが不可欠です。どういったアップデートをしていくのか？という点はマネージャーが中心になって検討することになりがちです。
私のプロジェクトの場合は誰でもアイデアを書き込める場所を用意し、そこから次のアップデートで取り入れる内容を決めるようにしています。
ただ、用意するだけでは誰も記入してくれないものです。そこで、アイデアが自然に出てくるような時間をなるべく確保するようにしました。
自身のプロダクトを触り、気になった点をメモする
競合プロダクトを触り、良かった点をメモする
プロダクトに取り入れたいことに対するブレーンストーミング
ユーザーへのアンケート結果を全員で確認する
これらを効率よく実現するためにも、前述の軸を決めるという点が重要になってくると思っています。
私が開発だけ担当していた頃にも、よくプロダクトのアップデートについてのミーティングはありました。しかし、その頃はどうしても自分から建設的なアイデアを出したり積極的にミーティングに参加することができず歯がゆい思いをしてきました。
今回PMの立場になり、当時の私のような思いをするメンバーが出ないようにしたいという思いがあり、こういった取り組みをするようになりました。当時の経験から、アイデアが出てこない原因は、そもそもプロダクトのことを知らないから、何が足りないのかなどそもそも考えるベースが無かったからだと気がつきました。
そこで、自主的にではなく、業務としてプロダクトに触り、アップデートについて各自が常に考えられるように仕組み化することを検討しました。業務としてやることがポイントです。
メンバーの得意、不得意、意志を把握する
発生するタスクの多くはメンバーに依頼することが多いと思います。自分の時間を確保するためには、なるべく多くのタスクをメンバーにやってもらいたいところです。そのためにはメンバーがどういったタスクが得意なのかはメンバーのことを知る、という点で特に重要だと思っています。
また、それとは別にメンバーがやりたいことかどうかという点もチームの生産性を上げていくためには知っておきたいポイントです。やりたいことであればある程度難易度が高かったり時間がかかることでもスムーズに取り組めるようになり、通常よりも早く、より高度なタスクをこなせるようになってくるからです。なるべくメンバーが高いモチベーションでタスクをこなせるように調整し、余ったタスクを自分が引き取るという形がちょうど良いのではないかと思っています。
頼むことは信頼することである
メンバーにタスクを依頼したら、そのタスクについて、完了の報告があるまではこちらからアクションしません。頼んだ物事に対してあれこれ詮索するのは頼んだ相手を疑っていることの裏返しであるように感じられ、モチベーションを下げる要因になりうると思っています。なによりも、細かい進捗確認は自分と相手両方の時間を使ってしまうため、自分の時間を確保するという目的に反していると思っています。
また、完成度についても程度によりますが完璧を求めません。言語という媒体を通している以上、自分の意図が完璧に伝わっていることはあり得ないという前提で依頼します。まずは完成してから、不足があれば次のアクションを検討するようにします。私のプロジェクトの場合は、開発内容によってはメンバー全員でお触り会を実施し、フィードバックをし合い完成度を高める取り組みを行うこともあります。これに関しても、こちらから伝えるというよりはその場でメンバーに自覚してもらって自主的に完成度アップに取り組んでもらいます。
仕事は抱えない。どうせやれないから
ここからは、自分の力量をわきまえるという内容です。
プレイングマネージャーになるということは、マネジメント、開発それぞれに割ける時間が半分になるということです。生産性はそう簡単には倍になりませんので自分は大したことはやれないというスタンスでいることが重要だと思っています。細かいタスクは抱えたくなりがちですが、努めてメンバーに依頼するようにし、なるべく自分のリソースには余裕がある状態を維持します。
首を突っ込まない。見守る
前述の内容と重なりますが、メンバーが抱えていることを詮索しません。所属プロジェクト以外のタスクを抱えていることも往々にしてありますし、仮に自分が入ってもそれで生産性が上がる保証は全くありません。苦しい状況なのであればメンバーから言ってもらえるように構えておく程度の触れ方がちょうど良いのではないかと思っています。詮索はしない。放置もしない。メンバーが見えないところで様子を見る。そのくらいの関わり方を目指します。
上記の介入バランスは難しく、実際にプロジェクトの進行で失敗したこともありました。昨年度、プランの共同編集を含めた数ヶ月に亘る大改修を行いました。その際に特定のメンバーに開発タスクを集中させすぎてしまい、2週間程度予定が遅れそうであることが発覚しました。詮索しすぎなかった結果、メンバーのキャパオーバーを検知するのが遅れてしまい、若干スケジュールを変更せざるを得なくなりました。その際は、私が開発ヘルプとして入り、かなりスケジュールの遅れを抑えることができました。前述の通り、「自分のリソースに余裕がある状態を維持」していたのが活きた経験でした。
上記の失敗を経て、毎週開発者間で週単位のタスク整理と情報共有をする時間を確保するようにしました。メンバーの手持ちタスクや優先度をチェックするのは基本的にこの時間のみにしています。
開発者の立場でPMにしてもらえると嬉しいこと
プレイングマネージャーとして1年ということで、ある程度双方の視点に立って考えることができるタイミングであると思いますので、両者の立場で思ったことを記載していきます。
こちらの項目は開発者としての私が開発に集中するために気にしていた項目でもあるため、やや個人的な意向が強いところかもしれません。
要件が明確
なにをすれば完了なのかをはっきりと伝えることが重要です。それ以外の余計な情報はできるだけ減らして依頼します。必須項目、進捗次第でドロップ可能な項目、できれば理想な項目まで出したいところですが、依頼する時点では何が必須かだけでも伝わっていれば十分な気がしています。
優先度が明確
一度に複数のタスクを依頼することがありますが、何が優先なのかを決めて依頼するのはPMの責任であると思っています。また、なぜそのタスクを急いでやる必要があるのか？という点はメンバーのモチベーションに関わる要素です。裏を返すと理由がないタスクは急いでやる必要がない=優先度が低いタスクであると言うことができます。
時間を奪わない
開発に集中している時にコミュニケーションが増えると生産性に悪影響を与えます。対話的コミュニケーションをとる時間は特定の日に集中させ、開発にのみ集中できる時間をなるべく長く確保することはPMの責任であると思っています。また、これは前述の「信頼すること」という点にもつながってきます。私の場合は、所謂定例ミーティング以外の時間はなるべく取らないようした上で火曜と木曜に集中して時間を確保するようにしています。
PMの立場で開発者にしてもらえると嬉しいこと
バッファ込みで見積もってくれる
依頼したタスクがどれくらい時間がかかるのか？と言う点はプロジェクト進行においてPMがかなり気にするところです。そこで、自分が100%の力を出せばこなせるスケジュールで作業を見積もることは避けた方が良いです。作業する自分自身を苦しめることになりますし、プロジェクト進行においては予定されている作業時間が長いことよりも予定より遅れることのほうが影響度が大きいです。
これに関しては私が開発を始めて間もない頃の経験からくるものです。当時は気合いで開発を終わらせるのが正しいと思っている節があり、期日に間に合わなさそうでも無理やり時間を確保して総労働時間も長くなってしまいました。それが精神的に辛くなってしまったので、自衛策としてなるべく余裕をもって予定を確保するようにしました。結果的に無理なく開発できるようになり、驚いたことに当時のPMから「開発スピードが速くなった」とまで言ってもらえるようになったのです。
スコープを決めて作業してくれる
依頼されたタスクに関して、どこまでやれば完成なのか？という合意形成を作業開始前に行っておくことで手戻りが少なくなります。また、決めたこと以上のことをやらないことも重要です。
開発をしていると、ちょっと気を利かせて機能を増やしてしまう、ということがありがちですが、増やしたくなったら増やす前に確認した方が良いです。下手をすると技術的負債や差分になりかねませんし、なによりもスケジュールの進行に影響を与えます。
こちらも私が開発を始めて間もない頃の経験からくるものです。当時はAndroid開発のみ担当しておりましたが、沢山やり方を調べて時間をかければ再現できるが、機能としては必須ではない程度のUIを特に確認を取らず開発してしまいました。その実装がiOSでは再現できず、当時の開発者には無駄な時間を取らせてしまいました。
ヤバくなる手前でアラートをあげてくれる
スケジュールが遅れそうなときは遅れそうな気配を察知した時点で言ってしまって良いと思います。タスクが進行してからは調整がし辛いからです。ただし、メンバーのキャパオーバーを察知するのはPMの仕事でもあると思います。「何かあったら言って」と丸投げするだけにはならないように気を配りたいものです。
おわりに
当初は1年も続けられるか不安でしたが、目の前の仕事をこなしているうちに気がつけばPMを始めて1年が経過し、もう1年続けられるかも？と思えるようになってきました。関係者の皆様、PMを続けさせてくれてありがとうございます。