この記事は 食べログアドベントカレンダー2023 の14日目の記事です🎅🎄
こんにちは。食べログシステム本部 アプリ開発部の基盤チームに所属している saten です。
食べログiOSアプリを担当していますが、基盤チームでは機能開発はあまり行わず、リファクタリングや開発環境（IDEやCI/CDなど）の整備、ライブラリ選定、アーキテクチャ設計など、食べログアプリの下支えをしているチームになります。
今回は基盤チームにおける大事な役割である改善についてお伝えしようと思います。
目次
アジャイル開発でも述べられている小さく早く改善を回す大切さ
多くの方もご存知のようにプロダクトを市場に素早くフィットさせるためには、アジャイル開発のように素早く開発と検証を繰り返してプロダクトを開発していくことが大事です。そのためには、小さく早く改善を回していくことが大事です。
基盤チームはプロダクトの改善が中心ではないですが、プロダクトを開発するチームの開発者体験の向上をすることが大事な役割の１つだと思います。開発者体験を向上することで、プロダクトの開発のサイクルをさらに早めます。また、基盤チームも開発者体験の向上を素早くするためには小さく早く改善を回すことが大切なのです。
優先順位のダブルマトリックスの法則
その上でタスクの優先順位を決める際に、役に立つのが「優先順位のダブルマトリックスの法則」です。1段階目としては下記のような重要度＆緊急度の一般的な優先順位のマトリックスがあります。
ダイヤモンド・オンライン 【効果絶大】仕事が遅い人でも、突然、成果が上がり始める“優先順位”のつけ方（https://diamond.jp/articles/-/312596） 図表4 一般的な優先順位のマトリックスをもとに加工して作成
１番優先すべきなのは緊急度が高くて重要度が高いものなのですが、２番目に優先すべきなのは、緊急度が高くて重要度が低いものではなくて、緊急度が低くて重要度が高いものであるという法則です。さらにもう一つの判断基準として2段目のマトリックスがあります。費用対効果を簡単に予測できていれば良いのですが、それが難しい場合、判断基準の参考となると思います。
ダイヤモンド・オンライン 頭よさげなのに実は考えが浅い人が知らない【優先順位のダブルマトリックス】の法則（https://diamond.jp/articles/-/312598） 図表5 2段階目の優先順位のマトリックスをもとに加工して作成
１番優先すべきなのは、もちろん重要度＆緊急度が高くてかかる時間が短いものなのですが、 ２番目に優先すべきなのは、重要度＆緊急度が高くてかかる時間が長いものではなくて、 重要度＆緊急度が低くても掛かる時間が短いものであるという法則です。 何故重要度＆緊急度が低くても掛かる時間が短いものを優先すべきかというと、以下理由なのですが、
1 先にやることですぐに結果が得られ、こなせる案件数が圧倒的に増える
2 「発生→タスク管理→実行」が「発生→実行」となるので、タスク管理の手間が省け、キャパが増える
3 タスクが完了することで次のタスクが生まれ、大きな目で見ると仕事全体が進む
4 記憶が鮮明なうちに仕事が終わるので、短時間で漏れなく精度の高い仕事ができる。後でやろうとすると記憶が薄れ、アイドルタイムが発生し、精度も下がる引用元：頭よさげなのに実は考えが浅い人が知らない【優先順位のダブルマトリックス】の法則 ダイヤモンド・オンライン https://diamond.jp/articles/-/312598
自分がそれ以外に特に大事だと思うのは以下2点です。
- アジャイル開発もフィードバックをもらって市場にフィットさせるように、開発者体験もフィードバックをもらってプロダクト開発の求められている形に早くフィットさせることができます。
- 早く改善効果を得られることで、サイクルを回すスピードが早い段階でより速くすることができます。
例えば、毎月100時間が掛かる作業を1ヶ月で1時間短縮できる改善と、10ヶ月で10時間短縮できる改善を積み重ねるのを25ヶ月間やった場合で、同じ期間で異なる効果が得られます。
[1ヶ月で1時間短縮できる改善効果]
0 + 1 + 2 + 3 + 4 ... + 24 = 合計300時間短縮
[10ヶ月で10時間短縮できる改善効果]
0 x 10 + 10 x 10 + 20 x 5 = 合計200時間短縮
細かくサイクルを回した方が大きなリスクも無く、より早く求められている開発者体験にフィットでき、早く効果も得ることができます。
具体的にどのように行動するか
改善の観点
以下のような改善の観点を持つことで改善できる点を見つけやすいです。
- ボトルネックになっているのはどこか？
- そもそもこのフローや作業が必要か？
- ツールで解決できないか？
- 自動化できないか？
日々改善アイディアを貯めておく
以下のような様々な時にふと改善アイディアが出てくることがあると思います。 その場で流して忘れてしまうのではなく、ちゃんとまずはタスク化しましょう。
- 誰かが困っていそうな時(課題点を考え改善するチャンス)
- 誰かが言った改善アイディア
- 作業中にふと気づいたことや思ったこと
- カンファレンスや勉強会で新しい話を聞いた時
より短い時間で高い効果が得られると思うものでざっくり優先順位付け
その中で先ほどの優先順位のダブルマトリックスの法則に従い軽く優先順位付けしましょう。掛かる時間の短いタスクを素早く片付けることが大事なので、短い時間のタスク同士で優先順位に大して差が無いものを無理に時間を掛けて順番を付けなくても良いです。時間を掛けすぎることよりも片付けることを優先しましょう。時間の掛かるタスクを行う場合は他のタスクとの優先順位をしっかり考えて実施した方が良いです。
改善アイディアを共有・実施
その中の優先度の高いと思うタスクの改善アイディアを軽くまとめ、共有しましょう。 食べログアプリでは毎週OS毎の改善定例があるので、そこで共有しています。 いきなり改変を行うのではなく、ここでプロダクトの開発するチームの反応をみておくことで本当に求められている改変か確認します。
その際に、フィードバックを頂けたらより良い改善にするために改善内容を修正しましょう。また、実はあまり求められていない改変だった場合は、無理に改変を進めず、課題点の情報を残しつつどのような条件だったら適切な改善ができるかをタスクにメモして保留やCloseなどしましょう。
もし、反応を待つまでに待ち時間が生じる場合は、その間に違うタスクや次の優先順位のタスクを着手しておきましょう。概ね改善のアイディアの反応が悪くなかったら改善の方を実際に実施しましょう。
改善後のフィードバック
改善後は改善内容を共有してフィードバックをもらいます。その際に問題などがあったら適時修正やタスク化を行いましょう。本当は感想なども聞けると良いかもしれないです。
しばらくしたら、改善効果を簡単に静的な数値で改善の効果を示せれば一番良いですが、難しい場合は、改善後にしばらく経ったら関係者にアンケートを取りましょう。その際に、開発者体験の変化度などの評価の数値と自由な意見の記入欄を設けると良いかもしれません。食べログでは改善内容毎に関係した人に開発者体験がどうなったか以下5段階評価を出してもらっています。
1(前よりもとても悪くなった)〜3(変わらない)〜5(前よりもとても良くなった)
数値で評価してもらうことで静的に評価を出しやすくなります。またその改善に 意見のある人が自由に記入できるフォーム を設け、ダメな点やさらなる改善案などのフィードバックを頂いて、次のより良い改善に繋げます。
小さな改善毎にアンケートを取っていたら大変なので、食べログアプリでは半期毎にまとめてその半期にやった改善に対してアンケートを取っています。これはそれぞれの改善がどのくらい効果があったか以外にも、半期毎にどのくらい改善をされているかを意識してもらう良い振り返りにもなります。でも本当はもっと短いスパンでアンケートを取れると良いかもしれないです。
まとめ
基盤チームのような開発者体験の向上をすることが大事な役割のチームでも、アジャイル開発同様、いきなり時間やコストの掛かる大きなことをするのではなく、小さく早く改善を提供し開発者体験を素早く向上していくことが大事です。
最後に
常に日々試行錯誤で進めています。本記事が皆様のお役に立てれば幸いです。
明日は @yohei7328 さんの「食べログの文章生成業務に生成AIを取り入れるときに、プロジェクトの各ステップで意識したポイントと、プロジェクトを通して得た気づき」です。お楽しみに!
