仕事抱え込むのをやめたい
「顧客の要望を全部聞いて、仕様書を細かく書いて、優先順位を決めて、開発スケジュールを引いて、エンジニアとのやり取りも顧客へのコミュニケーションも全部自分でやって、全部中途半端になった」――仕事抱え込み系プロダクトマネージャーの僕は、こんな爆死を幾度となく繰り返しています。結局フロントメンバーから『本当にお客さんはこれが欲しいんですか・・・？』と訝しまれ、エンジニアからは『これ作って何が変わるの・・・？』と冷たい目線を浴び、心身ともにヘトヘトになったのを思い出します。嘘です、全部フィクションです。
はじめまして。キャディの荘司です。CADDi Drawerのプロダクトマネージャーをしています。プロダクトマネージャーとして仕事をしていると日々悩みが尽きませんね…。
最近、会社のエンジニアリングマネージャーに勧められて『UNIXという考え方』という本を初めて読みました。UNIXの設計思想である「何をしているのか分からないのなら、ここにいるべきではない」を筆頭に、刺激的な話が多く、非常に勉強になりました。特に印象的だったのが、課題を小さく、そしてさらに細かく分割するという考え方です。課題解決やプロダクトマネジメントにも、そのまま応用できる考え方だなと。
今回は、UNIXに限らずコンピュータサイエンス業界でよく言われる「Divide and Conquer（ディバイドアンドコンカー）」と、『嫌われる勇気』に書かれた「課題の分離」という2つのアプローチに焦点を当ててみます。2025年こそ爆死したくない、この一心です。
Divide and Conquer
Divide and Conquer は、大きな問題を小さなパーツに分けて、それぞれ一つずつ統治していく、という考え方です。もともとはコンピュータサイエンスで使われる手法で、検索エンジンでウェブページを探す仕組みにも応用されているようです。検索エンジンでは、膨大なウェブページをキーワードやカテゴリごとに細かく分類し、それぞれのカテゴリ内でさらに特定の条件で絞り込むというように、問題を小分けにして解決しています。
これ、もはや森羅万象すべての仕事、課題解決、作業に適用すべきだなと。例えば、「大掃除」を「リビング」と「キッチン」→「ダイニングテーブル」と「床」と「シンク」と「食洗機」みたいに分けていくとか、「仕事」を「今週やること」「来週でいいこと」→「今日やること」に細分化するとか。
もう少し具体的に自分の仕事に置き換えてみるとこんな感じ：
顧客をセグメントに分類する: 市場を細かい顧客層に分けて、それぞれに合った戦略を立てる。売上規模で分けたり、産業で分けたり、部署で分けたり、レイヤー（役員、部長、課長など）でわけたりなど。
ロードマップを作成する: 長期的な状態目標の達成のために、短期的なマイルストーンに分ける。
フィードバック整理: ユーザーの要望を分類して、価値の高いものをピックアップする。機能別で分類したり、顧客の部門ごとに分類したり、分類軸は様々ある。
こうやって問題を細かくしていくと、おぼろげにやるべきことが見えてくる、ような気がしてきます。
課題の分離
「課題の分離」は『嫌われる勇気』で紹介されている考え方です。「何が自分の課題で、何が他人の課題かをハッキリさせよう」という話。本の中では、こう紹介されています。
哲人 たとえば、なかなか勉強しない子どもがいる。授業は聞かず、宿題もやらず、教科書すらも学校に置いてくる。さて、もしもあなたが親だったら、どうされますか？
青年 もちろん、あらゆる手を尽くして勉強させますよ。塾に通わせるなり、家庭教師を雇うなり、場合によっては耳を引っぱってでも。それが親の責務というものでしょう。現に、わたしだってそうやって育てられましたからね。その日の宿題を終えるまで、晩ごはんを食べさせてもらえませんでした。
哲人 では、もうひとつ質問させてください。そうした強権的な手法で勉強させられた結果、あなたは勉強が好きになりましたか？
青年 残念ながら好きにはなれませんでした。学校や受験のための勉強は、ルーティーンのようにこなしていただけです。
哲人 わかりました。それでは、アドラー心理学の基本的なスタンスからお話ししておきます。たとえば目の前に「勉強する」という課題があったとき、アドラー心理学では「これは誰の課題なのか？」という観点から考えを進めていきます。
青年 誰の課題なのか？
哲人 子どもが勉強するのかしないのか。あるいは、友達と遊びに行くのか行かないのか。本来これは「子どもの課題」であって、親の課題ではありません。
青年 子どもがやるべきこと、ということですか？
哲人 端的にいえば、そうです。子どもの代わりに親が勉強しても意味がありませんよね？
青年 まあ、それはそうです。
哲人 勉強することは子どもの課題です。そこに対して親が「勉強しなさい」と命じるのは、他者の課題に対して、いわば土足で踏み込むような行為です。これでは衝突を避けることはできないでしょう。われわれは「これは誰の課題なのか？」という視点から、自分の課題と他者の課題とを分離していく必要があるのです。
青年 分離して、どうするのです？
哲人 他者の課題には踏み込まない。それだけです。
青年 ……それだけ、ですか？
本書では、「課題の分離」を自身の幸せの探求を目的として使用しています。そのため、他者の幸せを探求すべきプロダクトマネジメントに転用するのはやや目的が異なりますが、それでも効果的な考え方だと感じます。プロダクトマネージャーとして、エンジニアや営業からさまざまな意見が集まってきます。その中で、自分が決めるべきこと、自分が取り組むべきこと、他の人に任せるべきことを切り分ける。これをしないと、課題を切り分けたところで、全部自分で抱え込んで爆死してしまいますので・・・。
こうした考え方を取り入れてから、随分と仕事が楽になり、より大事なことに集中できるようになった気がします。が、最近は注意が必要だとも感じています。
「課題の分離」は、ともすれば「これは自分の仕事じゃない」と、無責任な考え方になってしまう可能性があります。課題を分離することで、自分の逃げ道を作ってしまったり、他者に甘えるだけになっていないか、本当にその課題が解決できる最善の分離になっているのか、といった視点が必要です。
課題を分離し、自分が解決すべき課題を明確にする。それができた次のステップでは、「自分が解決できる範囲を広げていく」ことが重要です。
どうやって課題をdivideするか
課題をdivideするのって、かなりセンスが問われるスキルだと思います。訓練が必要です。細かく分けすぎると管理が複雑になるし、全体像が見えなくなる。分け方についても、課題を五十音でdivideするのは多くの場合において意味がない。課題をどこまで細かく分けるか、そしてどう分けるかという2つがとても難しいなと感じます。たとえば、顧客のセグメント分けで考えてみます：
売上高で分ける: 大手企業向け、中小企業向けといった形で分類する。「エンプラ（エンタープライズ）」、「SMB（Small and Medium Business）」などはよく聞く分け方ですね。
産業や部署で分ける: 製造業、IT業界、またはマーケティング部門、人事部門などで分類する。
レイヤーで分ける: 経営層、部長、課長、現場メンバーなど。実際に商品を使う人と、お金を出す人が異なるレイヤーであるケースで良く使われる分類のように思います。
プロダクトロードマップなら、長期的な状態目標を細かくブレイクダウンできます：
短期目標ごとに分ける: 3ヶ月以内に達成するべき状態目標に分ける。例えば一年先に顧客に提供する価値に対し、3ヶ月後にリリースしておくべき機能群に分類する。
ユーザー種別ごとに分ける: 新規顧客むけ、既存顧客向け、社内ユーザー向けといった分類が考えられる。
2025年こそ爆死しないために
課題をdivideすることにこだわっていると、結果的に自分の解ける課題の範囲が広がっていると感じることがあります。かなり一足飛びですが、こんなステップを踏んでいきたい（願望）：
目の前の仕事に集中: 小さなタスクをしっかりこなして信頼を得る
チーム全体の課題に関わる: 他チームと連携してロードマップを作るとか
会社全体の戦略に関与: 顧客との折衝や、会社の目標設定に貢献する
「Divide and Conquer」と「課題の分離」は、2025の僕を支える問題解決の強力なツールになりそうです
リストアップ: まず、抱えている課題を書き出す
分類と優先順位付け: 小さく分けて、重要なものをピックアップ
小さなゴールを設定: 自分がやるべきこと、すぐやるべきことを決める
仕事を依頼する: 自分がやらない課題を適切な誰かに依頼する
振り返り: 自分の進捗を見直して改善する
Divide and Conquerで、爆死しない、ないしは効率的に進められる、それだけじゃなく、仕事の幅も広げていけそうです。2025年は次の課題に向けて、もう一歩を踏み出してみようと思います。
以上、ただDivide and Conquerって言いたいだけの記事でした。皆様良いお年をお迎えください。