変革期のエンジニアリング組織で「クイックウィン」をどう設計するか
最近、タスクフォースのような短期集中チームを率いたり、従来とは異なる目標を掲げたエンジニアリングチームの立ち上げを担当する機会がありました。今回は、そのような変革期のチームづくりの中で考えていることを言語化してみようと思います。
変革期において最も重要なこと
変革期で何より重要なのは、チームがその変化に熱意とモチベーションを持って向き合えるかどうかです。変革は必ずさまざまな壁にぶつかります。そして、それらの壁を乗り越える方法は、リーダーひとりの設計だけでは成立しません。メンバーひとりひとりが主体的に取り組むことによって、変革の成功率は大きく変わってくると感じています。
そこで、僕が意識しているのが「クイックウィンの設計」です。
これは単に「早く成果が出る施策を探す」ことではなく、変革の初動において、メンバーと達成感を共有できるような構造をあらかじめ仕込んでおくということです。小さくても確かな前進が、手応えや意欲、そして主体性の向上につながります。
なぜ「クイックウィンの設計」が必要なのか
チームとしてこれまでと異なる挑戦を始めると、「これまでできていたことができなくなる」という負の側面が表れやすくなります。
たとえば、負荷問題の調査のために開発案件を一時停止したり、AIエージェントの開発を加速させるために、人間によるコード修正を一時的に禁止したこともありました。
もちろん理想は、全員が納得し、デメリットを被らない状態をつくることですが、現実にはそううまくはいきません。
さらに、上層部がいくら「変革が必要だ」と語っても、現場では「この変化、本当に意味あるの?」という静かな疑念や疲労感が広がることもあります。
つまり、変革期とはチームにとって「正解が見えにくい時期」です。
このようなとき、リーダーとしてやるべきことは以下の2つだと感じています。
- 「ここまでやれば届く」という地点をチームに示すこと
- 前進したことが実感できるような、達成感の共有体験を設計すること
この目的のために、僕は次の3点を意識しています。
- 集中する方向を言語化する。注力しないことを言語化する。
- 短期間で達成できる成功体験を見つけて渡す
- 改善されたことを、誰の目にも見える形で可視化する
クイックウィンの設計で意識していること
クイックウィンが達成される前の段階で、まず意識するのは「その結果を達成したときに、メンバーが本当に喜べるかどうか」です。
「この取り組みがユーザーにどのような価値を届けるのか」「会社やチームにとってどれほど意味があるのか」「この人にとって、どんな成長体験になるのか」という問いかけを何度も繰り返します。
数字が出たとしても、「あれ、これって誰が嬉しいんだっけ?」となってしまうようでは、クイックウィンとは言えません。
技術的に“できる”ことでも、モチベーションが湧かなければ意味がありません。
重要なのは、「自分でやってみたくなるサイズ」にタスクを設計することです。
- 1日〜3日で完結する
- 誰かの役に立っている構造が見える
- うまくいったらSlackで共有したくなるような内容
こうした「挑戦のハードルが低く、成果の拡がりが大きい仕事」は、変革期にこそ強い推進力になります。
また、クイックウィンの設計で忘れてはならないのが、どう共有し、どう認識されるかの設計です。
- Slackで紹介してもらう
- 定例で「これは良かったね」と取り上げる
- 関連チームから感謝の声が届くように仕込む
成果を言語化し、他者からの承認を得られる場を整えることで、メンバーにとっての成功体験がより強く印象に残ります。
クイックウィンの外で意識していること
クイックウィンを意識しすぎると、簡単な改善に満足し、本来取り組みたかった改善が出来ていないことに気づけなくなることがあります。僕は何度もハマりました。そのため、メンバーがクイックウィンを達成できるようになったら、リーダーは変革の目的を見失わずに、今の進捗と方向がゴールに沿っているかどうかを常に確認することが重要だと考えています。
まとめ
変革には、たくさんの壁があり、そして時間がかかるものです。
大きな施策が動き出す前に、現場が“気持ちよく動ける状態”を整えることは、リーダーにとって非常に重要な仕事です。変革を主導する方に役立てれば幸いです。
Discussion