プロダクトを向上させて事業を成長させるために、"重要なことにフォーカスすること"は最も大事な事項のひとつだ、ということはみんなわかっていると思う。

にも関わらず、実際にはフォーカスを失ってしまうことがよくある。いくつかのパターンと解決策を書いてみたい。

1.隣人駆動開発(Neighbor Driven Development)パターン

エンジニアは、時として"身近な人に感謝される仕事"を優先してしまう。

例えば、サポートチームから「管理画面のこの機能がちょっと使いづらいので変えてくれないか」と言われる。

すぐに対応してリリースすると「ありがとう！頼りになります！」と言われる。当然、いい気持ちになる。

その後、ユーザー体験をよくするための重要な開発をやっている時に、またサポートチームから「ここをちょっと変えてほしい」と言われる。

今度は、今ちょっと手が空かないから待ってくれと言う。

そして、開発が無事に終わってリリース。実際にユーザーに「ありがとう！」と言ってもらえるわけではないが、データで見る限り、ユーザーの反応は上々だ。

それに対するサポートチームの反応は？

「へー…(よくわかってない顔で)すごいですね！　で、これでやっと私の依頼にとりかかれますかね！？」

微妙な反応でちょっと寂しい。そして、時間がとれるようになったのでサポートチームの要望に対応してリリースする。

すると、まためちゃくちゃ感謝される。今度は周囲の人にまで「あの人は私たちの要望に素早く対応してくれる良い人だ！」と喧伝してまわってくれているようだ。そうすると、当然、気分が良い。あれ？こっちをやってるほうが気分いいじゃん、仲良くなれるし。となる。

実際のところ、最も身近なユーザーは社内のメンバーなので、社内のメンバーの反応が最もダイレクトに実感できるユーザーの反応でもある。目の前でユーザーが喜べば、嬉しいのだ。

こうして、事業戦略上の重要な(より優先度の高い)開発よりも、隣の人に感謝される開発を優先してしまうようになる。

これに抗う方法は、誰かが"目の前の隣人の感謝"を振り切る強靭な精神でもって「私たちの戦略に基づくと、今最も重要なことはこれなんだ。申し訳ないがあなたの要望はこれに比べて重要ではないので、今取り組むことはできない。少し待ってほしい」と、関係者全員に向かって言い続けることだ。

一般的にはプロダクトマネージャーがやるといいと思う。

2.進捗ダメですパターン

一般的に、難しい問題に取り組むには、より長い時間がかかる。

例えば、開発要件の決定までに多くの調査が必要な場合、その間コードを書く機会がなかったり、リリースできるような目に見える成果物がなかったりして、進捗がないように感じてしまう。

目に見える成果物がないと、周囲に仕事の遅いやつだと思われてるような気になり、辛くなる。

辛いのは嫌なので、重要ではないが簡単ですぐにコードを書けてリリースができて進捗が実感できる仕事ばかりに取り組むようになる。そうでない仕事は避けたくなる。こうして重要なことへのフォーカスを失う。

この問題の解決策は、周囲の目を気にならないようにしてあげることと、進捗を見える化することだ。

まずは当人にその仕事に十分な時間をとっていいことを伝えよう。そして、難しい問題に取り組んでいるから時間がかかるのだということを、当人の周囲にも認識させることが大事になる。心理的安全性を確保してあげるのだ。

また、コードを書いたりリリースしたりはできないかもしれないが、実際には仕事が進んでいるんだということを見える化してあげるのも良いだろう。検討・調査系のタスクも、小さな単位に細切れにしてカンバンに並べよう。一日のおわりには、それをDoneのレーンに移動できるように。

3.ぼくがかんがえたさいきょうの◯◯パターン

エンジニアは、凝り性の人が多い。エンジニアにとっての美徳でもある。

レビューなどでコードや設計の良し悪しについて話し始めると、自分の知る限りのベスト、つまり、"ぼくがかんがえたさいきょうの○○"を語り尽くすまで止まらないことも、よくある。

最上の設計、最上のコード、最上のユーザー体験。これらを語るのは非常に有意義なことだ。

ただし、それらが今フォーカスすべきことと一致していれば。

「ユーザーのニーズが不確実なのでまずはMVPをリリースしよう」という時に、最上の設計、最上のコード、最上のユーザー体験は、おそらく必要ない。必要なのは、顧客価値を検証できるだけの最小限の実装だ。

こういうシーンで、最上の設計、最上のコード、最上のユーザー体験への議論を尽くし時間を浪費してしまうことは、ある意味「重要なことにフォーカスできていない状態」と言える。

この問題が起きるのは、その施策において何が重要でどういうロードマップを描いているのかという前提条件が共有できていない時だ。

なんの前提条件もなしにレビューを始めれば、最上を目指すのがエンジニアの本能だから。(たぶん、きっとそう)

まとめ

実際のところ、重要なことに常にフォーカスし続けるのは難しい。周囲にはフォーカスを失わせるような色々な誘惑が常にたくさんある。

精神力・意志力で乗り切れる人もいるだろうが、多くの人にとっては難しいだろう。常に自分自身に対して客観的であり続ける必要があるからだ。

もし個人で達成することが難しければ、チームで達成すればいい。

他のメンバーが重要なことにフォーカスできているか、常に気を配ろう。フォーカスを失っていたら、遠慮なく指摘しよう。

重要なことにフォーカスできていないのではと指摘を受けたら、真摯に受け止めよう。そして、フォーカスを再調整しよう。

Twitterです