「もっと成果を出さなきゃ」「スキルを増やさなきゃ」。そんな焦りに押され、やることを積み重ねていないでしょうか？けれど、本当に働き方を変えるのは“足し算”ではなく、“引き算”かもしれません。この企画では、エンジニアたちがあえてやめたことと、その後に訪れた変化をたどります。ムダをそぎ落とした先に残る、本当に大切な仕事や自分らしい働き方とは。誰かの“やらない選択”が、あなたの次の一歩を軽くし、前向きに進むヒントになりますように。
こんにちは！いくお(@dora_e_m)です。現在、株式会社カケハシにSCM DomainのHoE（Head of Engineering）として所属しています。マネジメントで禄を食むようになってから10年以上になります。マネージャーという役割を担っていると割り込みがやってくるのは日常茶飯事です。もともと、それなりにタスクをもっている中でさらに割り込み作業が積み上がることになるため、得てして身動きがとれない状態になりがちです。
いや、「マネージャーという役割を担っていると」と書きましたが、ふりかえってみるとソフトウェアエンジニアとしてコードを書くことがメインだった頃も、タスクは溢れていたと記憶しています。タスクが溢れている状況は、しばしば「時間がない」という言葉となってため息とともに吐き出されます。スクラムフェス新潟2022では「時間がない症候群」というタイトルで時間のなさ、タイムマネジメントについてお話させていただきましたが、非常に多くの方から反響をいただきました。それだけ、「時間がない」ということが多くの人にとって身近な課題だということです。
人に与えられた時間は平等、1日は24時間で過ぎ去っていきます。積み上げられたタスクすべてを完了するのに必要な時間が自身の可処分時間を超過するとき、人はタスク溢れの状態に陥ります。そこをなんとかやりきるのがプロフェッショナルだとする向きもありますし、ある程度の負荷を乗り越えることで成長することもあるでしょう。
ですが、私自身は「積み上げたものを“力 is Power”で全部やりきる」というよりは、何をなすべきか、何を「やらない」ことにするかを見極めて余白をつくり出し、その余白を活用して自身やチームを成長させるというスタンスをとってきました。
本稿では、私がこれまで「やらない」と決めたこと、それがもたらした効果をいくつか紹介していきます。
チームの「やらないこと」を決める
私は、チームの目の前に積み上げられたタスクを減らし、メンバーが本質的な仕事に集中できる環境をつくることはマネージャーにとって大切な仕事だと考えています。
基本的に、「全く要らないタスク」というものは存在しません。稀に存在したとして、要らないということが自明であればタスクリストから削除すればいいだけです。多くのタスクは「やったほうがいい」「あったほうがいい」ものです。なので、タスクが溢れているので棚卸しをしよう、となったときに「要るか／要らないか」を判断軸に置くと、ほとんどのタスクが「要る」判定になってしまいます。だからこそ、「やらないこと」を決めるのは難しいのです。
チームの当たり前を点検する
チームには多くの「当たり前に行う定期的なタスク」が存在しています。定例会議、週報の提出、リリース説明資料の作成、全員での見積もり…。どれも「やったほうがいい」し「あったほうがいい」ものです。おそらく、そのタスクに取り組み始めた頃には「やらなければいけない」という必然性があったのでしょう。そして、「やらなければいけない」として定期的なタスクが追加されることが続いていくと、いつしかチームのプロセスは重厚になり、一日のうち半分は開発以外のタスクに時間を取られている・・・なんてことにもなりかねません。
チームを取り巻く状況は時々刻々と変わっていきます。また、チーム自身も成長し、変化し続けています。時の流れの中で、ある時点で必要だったものが不要になり、作業だけが形骸化して残るということが起こります。
やめたこと1: リリース説明資料の廃止
以前所属していたチームでは、開発物をリリースする際にステークホルダーに共有する「リリース説明資料」を作成していました。バリューストリームマッピングでチーム全体のタスクを洗い出していく中で、この「リリース説明資料」の作成がそれなりに大きいボリュームであることがわかりました。
前回リリースからの差分については、Gitで管理されたリリースノートに簡潔に記載されています。コードを追いたければコミットを辿ればよいですし、詳細な経緯はJiraやConfluenceにまとめられています。そこに加えて、画像のスクリーンショットなどを交えた詳細な資料を作成しているのは、いささか過剰な作業であると感じられました。
「開発目線ではなくしたい作業だけど、ステークホルダーが必要としている」ことを理由に作成が継続されていた資料ですが、それならステークホルダーに「これをなくすとどのような影響があるか」を確認してみよう、となりました。
ここでステークホルダーから返ってきた言葉は衝撃的なもので、「資料は見ていない」「存在を知らなかった」というものでした。それこそ、リリースノートなどで状況が確認できるため、ステークホルダーにとっても不要なものになっていたのです。
資料作成はリリースのたびに半日〜1日ほどとられており、リリースサイクルを高速化するにあたっての障壁となっていましたが、ステークホルダーに確認することで「やらないことリスト」に加わり、チームがより高速にリリースサイクルをまわすきっかけとなりました。
やめたこと2: ミーティング時間の大幅削減
現在所属しているチームは規模が大きく、チーム内でいくつかのサブチームが設置されています。各サブチームは職能横断で構成されています。
基本的には各サブチームで開発を進めていくのですが、開発を進めていくうえで同じ職能(フロントエンド／バックエンドなど)のメンバーに相談したい機会や、サブチームには落とし込まれていない横断的な課題を取り扱う場を設けるために、いくつかの定例が設定されていました。これらのミーティングは必要だと判断して設定されたものばかりですが、多くのミーティングが積み上げられることで以下のような課題が発生していました。
- ミーティングに割く時間が多く開発時間が短くなってしまう
- すぐに共有したほうがよいことも「定例で共有しよう」と寝かせてしまう
- すでに定例がたくさんあり、予定を確保するコストが高くなっている
そこで、既存のミーティングを「同期コミュニケーションが必要か／非同期コミュニケーションでよいか」「定期的に実施したいか／不定期で必要に応じて実施したいか」で分類し、「同期コミュニケーションが必要」かつ「定期的に実施したい」ものだけを定例として残すことにしました。
メンバーへの説明、お試し期間を経て本格的に実施した定例ミーティングの削減は、それぞれのミーティングにアサインされていたメンバーの空いた時間を総和すると1人月相当にものぼり、おおげさにいうと「人を1人採用した」くらいのインパクトが生まれました。
メンバーからも「作業時間をとりやすくなった」「集中がミーティングで途切れることがなくなった」といった声がよせられ、効果的な施策となりました。
カケハシのブログでも本施策について触れているので、よかったらご覧ください。
なお、本施策を実施してから数ヶ月が経過した現在では、必要に応じていくつかの定例会議が復活しています。以前と異なる動きとして、「復活させた定例会議を不要だと判断したら、メンバーが自主的に廃止している」という点が挙げられます。大切なのは「ミーティングを減らす」という行為の部分ではなく、「それが自分たちにとって必要か考え続ける」という点です。
自分の「やらないこと」を決める
チームの目の前に積み上げられたタスクを減らすためには、自分自身のタスクもコントロールしておく必要があります。仕事に追われ続けている状態だと、自分やチームの状態をメタ認知し抜本的な変化を仕掛けていくことが難しいからです。
やめたこと1: Slackとの適切な距離をとる
マネージャーのSlackは、常に「スッコココ」と唸りを上げています。参加するチャンネルはどんどん増えていき、その分通知の数も膨れ上がっていきます。
仕事をしているときに、今取り組んでいるタスクとは直接関わりがないチャンネルの情報収集に勤しんでしまったり同僚の分報を読むことに時間が取られてしまったり、という経験はないでしょうか。
あらゆるチャンネルに参加していると、脳が常に情報収集モードになり、一種の情報収集中毒になっていきます。どの情報も「知っていたほうが良いもの」ではあるので、その情報を得ること自体が目的化し、自分の脳のリソースと時間を食いつぶしていきます。
そのため私は、定期的に参加するチャンネルの棚卸しをしています。
究極的には、すぐ反応をする必要があるもの（インシデント情報などが流れてくる）、自分が所属しているチームに関連したチャンネルに絞り込めます。気をつけたいのが、フルリモートの環境でここまでストイックに絞り込むと今この瞬間に関わっている組織以外の情報が入ってこず、サイロ化に向けてまっしぐらになってしまいます。
なのである程度の隣接組織のチャンネルへの参加は許容しつつ、数カ月間そのチャンネルへの投稿がない・自分へのメンションがない場合は一度思い切って抜けるようにしています。（そして、そのようにしてチャンネルを抜けてから困ったことは今のところ一度もありません）
もう1つSlackまわりで気を付けているのが「休暇中に見ない」という点です。普段のSlackの流量を知っていると、「自分がいない間に何か起きているのではないか」という心配からついついSlackを見たくなってしまうのですが、そうすると脳がリセットされなくなってしまいます。FOMO（Fear of Missing out）を断ち切り、鉄の意志でSlackを見ないようにしています。（緊急連絡先は共有しておく必要がありますが。）
個人的に、このようにして休暇中に仕事の文脈から離れることは大切にしています。距離を置くことで、いざ仕事に戻ったときにフラットな視点で関わることができるからです。休みをとると仕事が溜まってしまうから・・・と休暇を取ること自体をためらう方もいらっしゃいますが、休暇が取れないほど仕事が蓄積する状態がそもそも健全か？から見直したいところです。
手をあけること自体が大切な仕事であると認識する
マネージャーとして「やらないこと」を決める際にキーワードとなるのが「権限移譲」です。チームの「やらないこと」の項では、そのタスク自体を「やらない」と決定したケーススタディを紹介しました。マネージャーの場合、自分が抱えているタスクの多くは「やらない」という判断が難しいものです。なので、「やらないこと」には「『自分が』やらないこと」という限定がつき、同僚やメンバー、場合によっては上司に移譲していくことになります。
この「人に移譲する」ことに居心地の悪さを覚える人は少なくありません。どこか、自分がやるべき仕事を他人に押し付けているような感覚に陥るのでしょう。
マネージャーにとって、自分が自由に使える時間を確保することは非常に重要です。中長期的な展望を検討したり、または突発的に発生したトラブルへ即時対応したり。長い時間軸と短い時間軸、どちらにおいてもコミットメントを求められる立場だからこそ、時間をあけておくことは大切です。
やめたこと2: 目標のオーナーシップを渡す
前職でも現職でも、チームが持つ目標のオーナーシップはなるべくメンバーに移譲するようにしています。チーム全体でもってもらう場合もあれば、テックリードなど特定の個人に渡す場合もあります。
組織全体の方向性とのアラインメントには関与しますが、どのような状態を目指すかの検討（Objective）、その状態に到達していると言える指標の探索と設定（Key Results）はチーム・メンバー主導で実施します。
このやり方をとっている理由はいくつかあります。
- 現場の課題を一番よく知っているのは現場
- メンバー自ら目標を設定することで主体性が生まれる
- マネージャーがフラットな目線で目標の妥当性をレビューできる
現在所属しているチームでも、「利用拡大に耐えうるシステム品質向上」、「AI活用などによる開発プロセスのアップデート」という2つの目標テーマのオーナーシップをメンバーに移譲しました。この移譲は明確なオーナーシップを生み出し、これまで手がつけられていなかった負荷低減が実現したり、「何かひとつ成果が出せたらいいね」くらいに考えていたAI活用がチームのプロセスに完全に溶け込んだりと、私が期待していた以上の効果が生まれました。
権限移譲は、マネージャー自身のタスクを減らすということ以上にメンバーのオーナーシップ発揮を促すという意味で、ぜひ取り組みたいアクションです。
それをやらないとどうなるか？を問い続ける
私が「やらない」と決めたことやその影響について、チームに対して、そして自分自身に対しての取り組みを紹介してきました。
目の前にある仕事はそのほとんどが「やったほうがいい」「あったほうがいい」ものです。それゆえ、「やらない」と判断することには勇気がいりますし、「自分は責任感が足りないのではないか」という不安にも駆られます。確かに、目の前にある仕事をすべて受けきり、やりきり、それで成果を出し圧倒的に成長するのは素晴らしいことです。ですが、自分自身のケイパビリティを超えてやりきろうとしたときに、どこかに無理が出てきてしまいます。成果の質が低かったり、結局やりきれないものが出てきたり。自分自身に無理が返ってきて、体や心を壊してしまうことだってあります。
目の前にある仕事に対して、それを今やらないとどうなるのか？を問い続けましょう。今じゃないなら、またやらなくてもなんとかなるなら、いったん脇においておきましょう。「やらないと何が起こるか」を観察すること自体が、タスク選択の審美眼を磨く大切な経験になっていきます。
余白をつくり、余白を活用し、自身を、チームを成長させていきましょう。本稿で紹介した私の経験や考え方が、みなさんが「やらないこと」を決める一助になれば幸いです。
まず、何からやめてみますか？