ジンジャー研究室

長めのつぶやき。難しいことは書きません。

優先順位が口癖になる危機感

開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。

以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない）

優先度が低いタスクに着手する機会が一生訪れない

仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する速度とタスクが積まれる速度を比較した時、「消化する速度＝積まれる速度」だとしたら、「３ヶ月後に着手可能」タスクは、３ヶ月経ってもやはり「３ヶ月後に着手可能」のままだ。さらに「消化する速度＜積まれる速度」の場合は、時間が経てば経つほど４ヶ月後、５ヶ月後、と着手予定日がどんどん延びていく。そういうわけで、一度優先順位を下げたら最後、なんらかの力学が働かない限りそのタスクに着手する機会は一生訪れない。

常に及第点の品質

すると、どうなるか。「今は 60 点だけど後で 90 点にしよう」と思っていた機能の品質は、その先もずっと 60 点のままだ。その機能を 90 点にする前に次の機能開発が始まる。そして、次の機能開発もやはり 60 点で終了する。このようにして常に及第点を取り続けてしまう。しかし、ここで期限を延長して 90 点を取るまで開発するという判断はできない。この機能を 60 点から 90 点にするよりも、次の機能を 0 点から 60 点にする方が優先順位が高いからだ。

表に出てこない UX の悪さ

ここで犠牲になるのが UX で、「とりあえず必要な機能を満たしているから大丈夫」という判断で使いにくい状態で機能がリリースされる。特に toB だと「業務が回る」ことが最優先され、運用者・決済者を満足させることに比べて利用者の体験は後回しにされがちだ。また、中途半端にスクラムなどを齧っていると（自戒）「最低限欲しいものから順に小出しにリリースしよう」という思考になるので危険だ。小出しにリリースしたいのは検証サイクルを早くするためであって、最低限で許してもらうためではないし、きちんと検証していなければ意味がない。しかし UX が悪いことによる影響を測るのはとても難しい。「ネガティブフィードバックがあったら考える」で運よくフィードバックをもらえることもあるが、多くは不便が顕在化して分かりやすい部分であって、残りは言語化されず深層意識の中に不満が蓄積されていく。ユーザーは「なんとなく使いづらい」と感じているが、それを直接フィードバックをすることなく利用をやめてしまい、「なんだか分からないけど定着率が悪いですねぇ」ということになる。A/B テストという方法はあるが、それが行われるのはユーザー体験にフォーカスした時のみで、優先順位の都合でユーザー体験を妥協した時ではない。

筋の悪い設計

内部品質も犠牲になる。新たに追加しようとしている機能が既存の設計に上手く乗らない場合、根本から考えて作るのはコストがかかるので、ちょっと誤魔化して筋の悪い設計で作ろうという判断になりがちだ。いわゆる技術的負債である。もちろんそうせざるを得ない場合もあるが、単に怠慢の場合も多い。隣のチームとコミュニケーションを取るのはコストがかかるし、なるべく面倒の少ない方法を取りたい。特に、当初開発コストを小さく見積もっていたが着手したらコストが大きいとわかった場合、とても焦る。「１日で終わると思っていたけど、ちゃんとした設計で作ると１週間だ」となった時に「今はちょっと誤魔化して実装して、後で設計を見直しましょう」となる。そして負債を返済する機会はなかなか訪れない。

強い人は最初から 90 点を取る

しかし、ちょっと賢い人々が「優先順位」を振りかざして「今は最低限の機能でリリースしましょう」「計測してから考えましょう」と色々こねくり回している間に、強々な人が最初から 90 点の品質で仕上げてくることを忘れてはいけない。並の人が作る初期品質は 60 点なので 90 点まで上げるのにとても時間がかかってしまう（ので残りはやらないという判断になる）が、最初から 90 点ならコストは問題にならない。そうすると、同じ時間で 60 点を取り続ける人と 90 点を取り続ける人がいて、それがそのままプロダクトの品質になる。「あの人は時間がない中で沢山レビューで指摘してきて面倒だな...」となった時に、それは自分が 60 点を取るからではないのかというのは自問した方が良い。エンジニアの話をしているが、デザイナーや PdM にも当てはまると思う。並の人が「やってみないと分からない」と言っているうちに、センス抜群の人がやらずに答えを出しているのではないかと思うことがある。

強くありたい

その場その場で「優先順位」をもとに判断するのはもちろん正しい。上手くマネジメントすれば後回しにしたものに着手する機会が生まれるかもしれない。が、そもそも品質の低いものをどうやってリリースするかに頭を捻られなくて済むだけの圧倒的な実力を身につけたいものである。