blog.8-p.info

問題点と解決策の分離

仕事をしていると問題点と解決策の分離の大切さを強く感じる。しかし人間は愚かな生き物なので、問題点と解決策を分離することができず、解決策ベースで話を進めてしまう。ある問題点に対して、最初に思いついた解決策が正しいとは限らないのに、その解決策を実行することが目的化してしまう。

プロダクトマネージャーっぽい悩みだなあ、と思ったけど、考えたら最近に自分もそういうことが何回かあったので書いてみる。

私はそんなに偉いわけではないので「とにかく困っています!」というよりは「こういう問題があって、こういう解決策があると思うんですが、どうでしょうか」くらいの抽象度になった問題を解決することが多い。それで「いやー、できるんじゃないですか。ここがこうなって…」みたいな話をして、いざ進めようとすると、もうちょっとシニアなエンジニアが出てきて「うーん、これは…」みたいにブレーキをかけられることがある。

文章を書こう

実際のところ、問題点と解決策を完全に分離することは難しいと思う。「ここがだめです」という話ばかりをするのは辛い。

私の場合は、やろうとすることを文章にまとめて、人々とミーティングという、昔ながらの方法をとることが多い。プロトタイプを Lisp で一晩で作るハッカーになる予定だったのに…と思わなくもないけれど、文章にする方法は社内で広く普及しているので、まあ平和だし、もっというと私の意向にかかわらず、周囲から求められがちだ。

なので、ブレーキというのも、実際はミーティングで突っ込まれるくらい。実装が終わってからコードレビューで前提をひっくり返されるよりはマシだと、自分を納得させている。

書くのは、いわゆる PR-FAQ ではなくて、もうちょっと普通の

  • 問題の背景
  • こんなやりかたがあると思いますよ
  • やりかた1
    • 利点/欠点
  • やりかた2
    • 利点/欠点
  • FAQ

みたいなやつ。自分があんまりよくないと思っているやりかたを列挙していくのは正直だるいけれど、書いてみると実はそこまで悪くないことに気づけることもある。思えなかったときは本命案の引き立て役として書きましょう。

また、反対にそういうミーティングに呼ばれる立場になって、他人の書いた文章を読むと、やっぱり複数の方法が列挙してあって、利点/欠点を比較検討できた方が、読者としては納得感がある。

こうやっても、結局のところ問題と解決策は一緒になっているんだけど、1つの解決策に全賭けする感じはちょっとなくなると思います。

問題だけを考える方法はあるのか

どうなんでしょう。スプリントのふりかえりとかだと、問題を列挙する時間と、解決策を考える時間を分けたりもするけれど、でもそれは短い時間だからできることであって、問題だけを何日も何週間も扱うのは辛い。

メトリクスの類をグラフにしたダッシュボードはちょっと良くて「このページの読み込みに何秒かかります」とか「この導線ここで何パーセントくらい離脱してます」とかは、問題だけを扱う辛みが薄いように思う。問題になる前の、否定的な価値判断がついてこない、なんというか「現状」だからだろうか。