曖昧な要求への応え方
SHARES
大前提として、世の中には「言語化できていない状態で要求される場合がある」ことを認識する。
特に職位が上がっていくことで不確実な課題に向き合う機会が増えている場合や、全く異なる文脈やバックグラウンドの人と協業して仕事を進める場合に遭遇しやすい現象。
「〇〇がしたい」だけで依頼が来るのがその例。
言葉からゴールまで連想できるなら、この課題は解決だ。それはきっと依頼主と自身の間に相応の ”共有力” が備わっているため、きっと上手くいく。
仮に最初の頃に上手くいかなくても、双方のノリ成分で上手くパスワークや個人突破をするシーンが生まれることによって、ほとんどの課題状況は解決に向かうだろう。
そうではなく、共有力が足りない場合にどうするか？をここでは考えたい。
自分は言葉の定義が不足している中で、共有力が足りない状態、そしてその不足を補う手段が限定的である状況が苦手だ。苦手意識がある中で、自分なりに理性でコントロールし、経験を重ねてある程度耐性を身につけ、その対策を講じて突破できるところまでやってきた。
将来読み返すために、今時点で意識していることを整理しておく。
心構え
「これは要求されているけど定義が曖昧だ」話を受けて少しでもそう感じたら、探索成分が多い課題である前提を置こう。心構えとして認識を持つこと (= 気づくこと) は非常に重要。なぜなら以降のコミュニケーションスタイルを大きく変える起点になるから。
話を進めていくと探索が不要だったとなる場合も全然ある。それでも探索することを前提に置いていた方が切り替えが楽になるので、先に構えていた方が良い。
気づくための現象はいくつかある。
「要求の抽象度が高く、具体成果イメージがない」「成果は要求されるが具体制約がない、なのに期限は決められている」「情報共有量が少ない、もしくはない」
この状況に遭遇したら、ほぼ間違いなく探索成分を多く含む要求だと思った方が良い。特に抽象と具象の紐付きが曖昧だったり、説明が乏しい (短い, 曖昧, 無秩序) 場合は、ほぼ決定に近い。なお、要求側は探索成分が多くあることを認識できていない場合がほとんどで、わざわざ「探索も含めてお願いします」などと言葉で要求することはない。
時間をかける
解決する課題に探索成分が多く含まれていること自体は悪いことではない。むしろそういう課題に向き合う機会があることの方が健全であると言える。なぜなら、物事を前に進めようとしないと遭遇できない課題だからだ。前に進んでいる状況でこそ、探索成分を含む課題の解決が求められる。
一方で、課題であるという認識を持てる場合、それを探索成分が多い課題と少ない課題を一緒に扱おうとすること自体は問題だ。そもそもの性質が異なるものを一緒に扱うのは、水と油を混ぜるようなもので、混ぜて良いことはない。
探索成分は比率のようなイメージで、30%のものもあれば、80%を占める場合もある。
探索の必要性は課題解決に “相応の時間を消費すること” を意味する。
答えを探すところからスタートするのだから、単に解決に向かう以上に時間を消費するのは当然だと思えるのだが、そう認識できていない人が実は多くいる。
ここで認識できていないことを嘆くのではなく、「時間を使いますよ」とあらかじめ期待値を揃えにいこう。もし相手がそれを飲めないのなら、課題を解く合意を取ってはいけない。お互いに不幸になるだけだ。
課題の探索
ここでの「課題の探索」とは「課題から成果までを物語で説明できるようになり、納得感を得ること」だと定義する。単なる説明ではなく、”物語性” を含むことが重要。
物語性とは、特別な状況や状態設定のことで、求めなくとも設定状況が自然に物語性を構成する場合もある。なぜ重要であるかは、納得感を得るためで、納得感があるということは欲しい課題解決成果に辿り着いていることを保証することを意味する。物語性がなくとも説明できているのであれば、そもそも課題解決の相談自体が間違っており、自身で解決することを提案しよう。誰でも解決できる課題の付加価値は低い。
“探索” の具体は、相手が何がわかっていて (求めていて) 、何がわかっていないか (求めていないか) を理解して把握すること。問いを投げてヒアリングする場合もあれば、集めた情報から仮説を作って、成果を当てに行くこともそう。あらゆる手段を使って、情報収集と検証を繰り返す。機能開発であれば機能を簡単に作って使ってもらうのも探索といえる。報告資料であればフォーマット、中身を仮に作ってみて読んでもらうこと、そして感想をもらうことも探索になる。
肯定だけでなく、否定も扱った方が良い。あえて振り切って「No」と言ってもらう。Noと言われそうという仮説のもとで成果を作り、あえて当てに行く。「No」の線引きがわかると「Yes」が際立って見えるからだ。早い段階で否定の意見や感想も集めておくと探索は進捗しやすい。
小さく試す
100ある課題を解ける解法を1度に証明できるなら、これほどエレガントなものはない。
エレガントに解こうとすること自体は否定しない。それができる場合もあるし、解いている人を実際に見たこともある。ただし、今の自分が同じように解けるかどうかは別問題であるのと、エレガントに解くことがゴールではなく、課題が定義できて、”解き切れる” ことがゴールであることを改めて認識しよう。そう捉え直した場合の手筋は “小さく試す” だ。
この時、100ある課題を解き切るために小さくするということを守らなければいけない。あくまで100の課題を解くための10、もしくは3の課題であるという “位置付け” で課題を解く。布石を打つ意識を忘れてはいけない。
この位置付けを持った上で探索を繰り返す。小さい方が早く済ませられる。早く修正を効かせられるようにするために、小さくしている。それ以外の理由はない。解く側としても100を修正するより10修正した方が1/10になるので (当たり前だが) 楽になるのはその通りである。
エレガントさにロマンを求めてしまいがちだが、実際に必要なのは泥臭さで、それは ”試す” ところに現れる。難しく解こうとしていると感じたら立ち返って、課題を小さく定義し直そう。その立ち返りが良い方向に向かう起点になるはずだ。
(後記)
最近は Technical Product Manager 的な仕事が中心になってきている。
プロダクトは toC or toBという大別がメジャーだが、toT(Technical or Technology) の話はあまり見かけないのはなぜなのか？たぶん、外に話すほどのことじゃないと役職者の人は思っているから、表に出ないだけなのかもしれない。
今のTPMの仕事は、これまで培ってきた知識と経験値をフルに使って、機能要件,非機能要件,移管,運用,システム間連携といった要素を持つあらゆる複雑系の課題を言葉と成果物で解く。(これが結構大変)
Tech Leadに外交要素 (交渉, 提案, 承諾, 相談) を追加で求められるので、外交官的な資質を持つ人には活躍する素地があるように思う。
ここで書いた内容はそんなTPMという役職で求められる “突破力” を自分の経験を踏まえて、今時点の手触り感を残したくて書いた。