当記事は 『プロダクトチーム制への移行とユーザー部門との連携強化に取り組みました！』 の後日談です。
1 年と少し前、私たちの開発体制は職能チーム制からプロダクトチーム制へと移行しました。その際、開発部門の制作物をオーナーシップ単位で「プロダクト」として分類する作業が行われました。プロダクトには SaaS や社内システム、Google Apps Script や Web サイトの制作物など、さまざまな種類のものが存在します。そして役割定義を明確にする試みとして、開発規模の大小にかかわらずそれぞれのプロダクトで PdM（プロダクトマネージャー） / PO（プロダクトオーナー） を設定しました。
私は プロダクトチーム体制の図 における PdM として、複数のプロダクトを引き受けることになりました。そのうちいくつかは作業軽減や時間短縮など業務効率化を目的とした社内開発です。一部の部門だけで使われる小規模なもので、社内ツールという表現が近いかもしれません。
PdM という役割を与えられたことで開発の進め方やステークホルダーとの関係性など、開発メンバーとして関わっていた頃とは少し違った景色が見えるようになりました。この 1 年を通して考えてきたことを、あらためて文章にしてみようと思います。
※「PdM」「PO」は私たちの組織内での責任範囲を示すために言葉を借りたもので、システム開発の文脈で使われる広義の意味とは違ったものになります。社内ツール開発におけるチームリーダーとドメインエキスパートなどに読み替えていただければと思います。
1. 最初の取り組み
私たちの開発組織における PdM の役割は システム開発に関するすべてに対する説明責任と結果責任 と定められています。いやしかし、具体的に何をすればいいのか当初はまったく想像がつきませんでした。
一人で担当できるような小さな制作物も含めると、引き受けたプロダクト数は 10 を超えていました。そして私は PdM というものを体験したことがなく、その分野ではまったくの素人です。
情報収集・ドキュメンテーション
最初に行ったのは、情報収集とドキュメンテーションです。CI やデプロイ方法、バックアップ格納先や成果物の出力先、開発に必要なアカウント、プロダクトの目的や関係者など、自分が知らないことを洗い出してひたすら情報収集していきました。ドキュメントの記録手段として選んだのはプロダクトごとの GitHub リポジトリです。README を起点にしてすべての情報を辿れるように書き起こしていきました。
情報収集から始めた理由は 全体像を知らないと誰に対しても説明ができない からです。オーバースペックな要求を引き受けたり、トラブルが起きてから慌てて仕組みを調べたりすることはできるだけ避けたいものです。
ドキュメントに起こした理由は 情報を可視化したほうがチームの資産として有効活用できる と考えたからです。バックアップ格納先の AWS S3 バケット名なんてしばらく経てば忘れますし、それは構築した開発メンバーでも同じことです。
担当プロダクトすべてのドキュメンテーションを終えるまでに 2 ヶ月を費やしました。けれどもこの作業と成果物のおかげで、ステークホルダーや開発メンバーからどんな質問を受けてもだいたい答えられるだろうという、ナレッジの基礎部分ができあがりました。
PO とのコミュニケーション
PO / PdM はプロダクトチーム体制にともなって創出された役割で会社組織上の肩書きには存在しません。
本来的に PO という役割は、プロダクト開発のゴールを設定し開発コストとリターンについて責任を持つものかもしれません。ただ、ちょっとした便利さを提供するような小さな社内ツールでリーダーシップを求めすぎてしまうと引き受けてくれる人の範囲も狭まってしまいます。ユーザーサイドとシステムをつなぐ窓口役にとどめたほうが協力しやすいのではないかと考えました。
そういった事情から、PO はプロダクトの関連業務の担当者に依頼しました。システム開発の上流工程に関わったことはなく、ツール利用者としての立ち位置からとつぜん「PO」の肩書きが割り当てられたことになります。おそらく最初は戸惑いを感じることでしょう。
そこで最初は、開発体制やトラブルの相談先を説明し メンテナーを明らかにすることで保守されている安心感を持ってもらうこと をコミュニケーション材料にしました。これには即効性の効果があり「開発の方どなたか、この件分かりますか…？」と控えめだった相談事がプロダクトの開発チームに届くようになりました。
機能拡張が活発でなく、日々稼働しているだけのプロダクトでも PO とは半年に 1 回コミュニケーションを取るようにしています。PdM からの報告として この半年にトラブルがあったか、安定稼働しているか というステータス、 PO への質問として プロダクトを使っているか？どれくらいの頻度で主に誰が？ という状況確認、これらのトピックは原則として含めるようにしています。「PO の XX さんは今どういうプロジェクトに関わっています？この業務からちょっと離れているって聞いたんですが」といった質問も入れたりします。
この業務絡みの雑談は、社内開発プロダクトのヒントをたくさん含んでいます。
開発部門のチーム体制に変化があったように、それ以外の部門でも体制や業務フローは刻々と変化しています。また Web 広告という自社の事業の特性上、広告媒体や IT の発展によって外部要因の変革を求められることも多々あります。PO もプロダクトも変化の荒波の中にあり「便利だったけど今は使わなくなったツール」や「事情が変わって別のプロジェクトの優先度が高くなった」というような状況が見えてくるのです。
2. 社内開発の特徴
私が 20 年来の業務経験で開発したものに機械制御のシステムがあり、ウォーターフォール型で要件定義・基本設計・詳細設計…と段階を踏んだのを覚えています。完成した機械の基盤を相手にするため仕様の変化がほとんどなく、漏れなく要件定義できることに重点が置かれました。それと比べて、業務効率化を目的とした社内開発はまったく違うものだと感じています。
PO の状況変化
社内開発では、マストだった機能開発が数カ月後に不要ステータスに変わります。あるいは検討中ステータスだった機能が来月までに準備できないと困る！と急展開します。
この要因は PO の置かれた状況（業務フローやタスク優先度）が刻々と変化 しているからだと思っています。ガッチリ要件定義して数ヶ月かけて開発しても、いざリリースすると使われない機能になることはよくあります。そして、いつの間にか業務フローが変わっているとか、開発チームが情報共有を受けていないとか、小さないざこざが発生します。
要件定義通りに実装することはシステム開発の定石ですが、リリースまでのスパンが長かったりリリース後のキャッチアップがおろそかになったりすると、状況変化に追いつけなくなってしまいます。
PO は指示役ではない
いつまでにどんな機能を実装すれば良いのか、PO に求めても正解を持っていない だろうと思うことが多くあります。PdM が自分ひとりですべての技術的解決を図ることはないのと等しく、PO もまたすべての指示を出すものではありません。私の担当プロダクトでは互いに業務におけるプレイヤーであり、テックリードや事業部長のようなリーダーシップを引き受けたつもりはないのです。
PO は作業軽減や時間短縮を実現したいと思っていても、そのためのシステムに指示は出せません。何か困っていますか？と聞いたところで、現在使っているツールでなんとかやれていますという回答が返ってきます。
開発スケジュールに関しても同様です。社内開発では、完成時期は問わないという納期フリーな場面がよくあります。PO にスケジュールの指示を求めても、明確な時期は出せない ことが多いのです。
PO は仕様を考える役ではない
開発者は「A を A’ に加工し、B を B’ に加工し、A’ と B’ をマージすると C ができる」という考え方をしています。プログラミングは規則性の適用の連続で、その積み重ねでシステムが構成されています。この考え方はデータフローや UI を作る時など日常的に現れます。
システム開発と異なる仕事をしている人は、A,B,C の データの相関が想像できなかったり、明らかに重複するデータや矛盾するデータに違和感を感じない ことがあります。実際にあった例として、インポート用データの日付フィールドに「月次」と書き込まれ、YYYY/MM/DD 形式を期待する処理がストップすることがありました。入力者にとっては「月次」は日常業務で使う正しい用語で、システムの規則性なんて知ったことではありません。バリデーションエラーで「日付が不正です」と表示したところでシステム的な言い分を示すものであって、何が間違っているのか分からないと困っている場面によく遭遇します。
開発者からシステムの仕様や挙動を示してこれでいいですかと確認を求めることがありますが、この聞き方には問題があります。質問を受けた側がシステムを十分に理解できないなら、決定ではなく右から左へと承認しているにすぎないからです。OK ですと答えたはずの PO が仕様をまったく覚えていなかったり、他の人に説明ができなかったり、そんなことが日常的に起こります。
業務担当者である PO に仕様決定を委ねるようなコミュニケーションには、少しずつ疑問を感じるようになりました。
3. PdM のしごと
私が担当している社内開発プロダクトは、つねに状況変化の中にありニーズや使い方が変わります。システム開発では「業務ドメイン」と表される部分で、これはシステムを主語に内側から外側を見た表現です。業務全体を主語にして外側から内側を見るとシステムとその周辺領域は全体のうちの一部であり、業務全体を表すのに「コンテキスト」という言葉がしっくりくるように思いました。
業務ドメイン（部分）を知っている人は多いのですがコンテキスト（全体）を説明できる人は希少で、PO に説明を求めてもその人が担当する範囲しか知らず他の部門の関係者やフローまで分からない、ということがよくあります。PO が自分の知っている範囲だけで受け答えし、システムを十分に理解できずに右から左へと承認しているのなら、なるほど「マストだった機能開発が不要ステータスになる」「検討中ステータスだった機能が急展開」ということになりますよね。それなら PdM の自分が、コンテキストを知ればいいのではないでしょうか…？
この気づきが、システム開発の駆動をトップダウンからボトムアップへと見直す転換点となりました。
これでいいですかは NG ワード
PO に対して「これでいいですか？」という聞き方はしなくなりました。「問題があれば教えてください」も同様に NG ワード扱いにしています。
代わりに使うようになったのは 「こういう機能を作りました、業務のこの部分が便利になるはずです」という提案 です。もしかしたら便利ではないかもしれないし使われないかもしれませんが、承知の上です。
私の担当プロダクトでいちばんアクティブに開発しているものは、請求書のデータ収集システムです。このシステムは請求書発行の時だけ使われます。月にほんの 1 回使うだけのシステムの仕様検討にユーザーは一生懸命にはならず、いいですかと聞いても Yes しか返ってこないのです。考えてみれば自分自身も月 1 回の頻度で使うシステム（たとえば経費精算アプリなど）から顧客満足度アンケートが届いても、あまり熱くフィードバックをすることはありません。アンケート項目に「画面をリニューアルしました。感想を聞かせてください。」とあっても、よほど使いづらくなければ空欄で回答するでしょう。
プロトタイプを作り続ける
社内開発プロダクトで定着してきたのは 開発サイドの提案ベースでプロトタイプを作っては壊す開発スタイル です。これはコンテキストが流動的でガチガチの要件定義ができないことへの、私なりのアンサーです。
実装が 6 割方完成したらリリースして使ってもらい、使っている様子がなければ壊して別のものに差し替えることもしばしばです。実装の 6 割というのは正常パターンの挙動で、残り 4 割はイレギュラーパターンの想定やログ出力が占めています。この状態でリリースするとデバッグ作業はしんどいのですが、まずユーザーに使ってもらうことを重視しています。
このやり方だと、仕様決定を誰かに求めることもなく開発サイドからのスケジュール提案もしやすくなります。自分たちが作っているものをプロトタイプと割り切れば、作ったものを捨てることの抵抗感も少なくなります。
観察とヒアリング
プロダクトを 誰がどのように使っているのか、あるいはなぜ使わないのか、観察とヒアリングは重要 です。プロダクトのコンテキストとなる実際の業務を知らずして効率化のためのシステムは作れません。
ヒアリングをしてみると別の業務で忙しくなったり、PO 自身も何かの決定を待っていたりすることがあります。そこで「PO の XX さんは今どういうプロジェクトに関わっています？」といった質問を投げかけています。実は別のプロジェクトで手一杯になっていて、そこで非効率な大量の手作業を行っているかもしれません。その情報は大事なヒントであり、少しずつ情報集めをすると次の機能開発のアイデアにつながります。
自分とは別の分野のプロフェッショナルが行っている業務を理解することは難しいものです。何度聞いても分からない用語も出てきますし、業務フローを聞いたところでボトルネックなんて簡単に見つかりません。私が気をつけているポイントは、誰がどんな役割で業務に関わっているのかヒアリングする事と、使っているツールや資料を積極的に見せてもらう事 です。ぼやけていても全体像を掴んでいくことが業務理解の最短ルートだと思うからです。
やらないことを決める
使われないプロダクトや機能は、ペンディング状態やクローズを検討します。
その部分に割いていた人的・時間的リソースを別のプロダクトや機能に割り当てたいと思うからです。やらないという決断は後ろ向きではなく、やると決めた他のものを活性化させる と考えています。
「やらない」にもいろいろな方法があります。最低限のメンテナンスだけ実施するとか、再開の余地を残して稼働を止めるとか、どういったステータスに持っていくのが最善なのかを考えます。私は ToDo 管理ツールに「その後どうなったか聞く」というタスクをよく登録しています。そして ToDo 実施日になったらコンテキストの変化を観察し、稼働再開やクローズのタイミングを見計らっています。
前回のやり方は不正解
恒常化していたステークホルダーとの定例ミーティングを廃止しました。
ステークホルダーはシステムに対して、開発者と同じだけの熱量を持ちません。アジェンダにトピックが活発に書き込まれることもなく、事前に読んでからミーティングに参加する人も少なく、ほとんどの人が情報共有を受けるためだけにゲスト参加しているような印象を受けたので、これを繰り返しても非効率だと思って廃止しました。
良し悪しの問題ではなく、自分が無意識に楽をするために前例をなぞっている事と、そのやり方には一考の余地がある、という話です。定例ミーティング廃止は 相談やヒアリングの機会を自ら作らないとプロダクトは何も動かない という戒めとして機能しています。
加えて 前回のやり方は現時点のコンテキストでは不正解 というマイルールを設定し、スケジュールの引き方や開発の進め方についても今の正解は何だろうと一度リセットしてから考えるようにしています。新しいやり方がいい時もあれば、やっぱり前回通りが良かったという時もあります。システム開発の成果物だけでなくプロセスにおける手段もまたプロトタイプです。作って壊して、そのプロダクトにしっくりくるようなやり方を模索しています。
コードを見るな
仕様を考える時やトラブルが起こった時、開発者はまずコードを確認します。コードを書く仕事なのだから当然ですよね。
コードを見ると自然とものごとを考える主語が「システム」になり、システムがどう振る舞うべきか、システムを正常稼働に戻すにはどこを修正すべきか、そういった観点で考えることが多くなります。システムが主語なら「日付が不正です」に違和感はありません。発生箇所を特定できない例外処理の「不明なエラーです」や「システム管理者に連絡してください」は開発者の常套句です。
そこであえて視点を変えて「ユーザー」を主語にするよう意識づけています。
ユーザーを主語にした場合は ユーザーと同じものを見て（インプットとして使うデータやツール、成果物としてアウトプットされるもの）、行動を想像（何を実現したいのか、タイムリミットがあるのか） します。エラーメッセージは「数分おいてやり直してください」のほうが自己解決率を上げられるかもしれないですし、システム復旧よりも別のリカバリー手段を優先させるほうが業務フローのダウンタイムを軽減できるかもしれません。
目指すものが見つかったらその達成手段としてコードを見に行きます。最初にコードではなくユーザーを見るというこの方法は、ユーザー視点の矯正メガネのように作用します。
開発チームの目標
担当プロダクトのひとつで「業務の繁忙期にメイン担当者に有給を取ってもらう」という開発チーム目標を設定しました。
業務効率化のための社内開発ではビジネスサイドから指標として何かを求められることは少なく KPI 設定の難しさがあります。ユーザー満足度やパフォーマンス改善などを設定してみても、それが正しい目標なのだろうかと開発者は迷い始めます。
掲げた目標は開発がある程度進んでから後付けで出てきたもので、なかなかにムーンショットな良いものだと思っています。私たちのプロダクトで作業時間を短縮しても、空いた時間を別のタスクで埋めてしまうでしょう。そこで考えている手段は、別の人に交代できるような体制の提案やツール提供、別の開発チームのプロダクトとの合わせ技で業務全体をさらに時間短縮することです。絶対に休めない繁忙期から、いざとなれば休める日に認識が変われば計画有給も取りやすくなります。
開発チームで「こうなったら嬉しいよね」を想像する のは楽しいものです。誰に期待された目標でもないのですが、開発者自身が望む状態なので迷いは生まれません。
4. 社内開発における PdM とは
プロダクト開発代表メンバー
PdM の私は PO に決定を求めることをやめて提案ベースに方針転換しました。そして PO を通してコンテキストの変化を観察し、新しい提案の材料を常に探しています。
開発メンバーのふるまいでも同じことが言えます。社内開発では開発メンバー全員がユーザーのほうを向いて、自分の開発した機能がどのように使われているのか、業務フローにどんな変化をもたらしたのかを観察し、提案し続けることが重要です。これはユーザーとの距離が非常に近い社内開発ならではのやり方です。PdM は技術的なリード役ではありませんし、仕様の取りまとめ役でもありません。ステークホルダーと協議が必要になった時、開発チームで決定が必要になった時、一歩前に出る 役割です。言うなれば「（P）プロダクト開発（D）代表（M）メンバー」でしょうか。
過去の職能チーム体制下ではプロダクトの判断が必要になった時、チームリーダーに一切合切の相談が持ち込まれていました。その分野のシニアエンジニアがリーダーに選ばれる傾向があったため自然な流れとも言えますが、開発メンバー同士が集まると自分が決定する根拠がないため「リーダーに相談しましょう」となるのが当たり前になっていた気がします。そしてチームリーダーはすべてのプロダクトの業務理解を持ち合わせないため、業務の正解ではなくシステムの技術的な正解としての回答を選びます。
プロダクトチーム体制に移行し PdM の役割を得ることで、自分が一歩前に出るモチベーションができました。私は プロダクトのコンテキスト（業務フローや変化の状況）に一番詳しい開発メンバー として行動します。この確信が 1 年間 PdM としてプロダクトに向き合ったことの成果です。
社内開発の楽しさ
PdM はさておき、社内開発には楽しさがあります。時には PO から「こんなことできたら便利なんだけど、できます？」とアイデアが持ち込まれ「それじゃなくてこっちのやり方のほうが早いかも、1 週間あればできます」「本当？めちゃくちゃ助かります〜」なんてやり取りがあります。
以前は「こういった機能を検討していますので、ミーティングをお願いいたします」という感じの会話だったので、だいぶ変わりました。恐縮したコミュニケーションでも、便利な機能が完成すればユーザーは喜んでくれます。でも「めちゃくちゃ助かります〜」が直接聞けるほうがとっても嬉しいのです。
私の担当プロダクトでは、まだメイン担当者の有給休暇を見かけていません。おかしいですね先月リリースした機能では足りなかったみたいですよ….と開発チームで話しながらその実現を楽しみに、あの手この手のアイデアを提案して社内開発を推し進めていこうと思っています。