出社方針変更への拒否反応

インターネッツはいつでも騒がしい。

L社が出社方針に切り替えるとのこと。ｴｯｸｽ上では阿鼻叫喚という印象で、転職の声も上がっていた。

「週5出社だとこれくらいの反発はあるよなぁ」と思って中身を読んでみたら、"原則週1"出社で当面はつよい強制力もなさそうだった。正直自分は「週1くらい行けばええやん」くらいに思ってしまっていて、インターネッツ上の反応とはだいぶギャップがあって少し驚いた。

出社方針の変更というのはそれほどセンシティブなトピックだということなのだろう。そもそも全員が両手で受け入れられるものではない。個々人の事情も複雑に絡み合っている。一方で、個社の方針そのもの以外にも"拒否反応"の要因があると思っていて、想像して雑に書き出してみる。労働者観点、経営/労務観点それぞれについて、自分に抜けている感覚や情報を補完したい。

---

• 今となっては"週1"でも電車に乗って通勤するのがとにかく嫌
• 感染予防観点で、本当に必要なタイミング以外の通勤は避けたい
• 通勤があるとリモート前提で組んだ育児などの生活リズムに影響してしまうので厳しい
• フルリモート前提でオフィスから遠い居住地だった / 居住地を変えてしまった
• 快適な作業環境の整った自宅より劣るオフィスに行く意味を感じない
• "コミュニケーションの促進" みたいな感じでポジティブなメッセージングをしているのが納得できないし癇に障る
• これまでフルリモートを推進する方針だったのに、手のひらを返したような変更に納得できない
• リモートでのコミュニケーションを上手くやる工夫の余地がまだあると思うのに、やることやらないでとりあえず出社みたいな楽な方に流れてしまっているようで嫌
• 海外のBigTech企業の方針変更に乗っかっているだけみたいに感じる
• リモートワーク前提の手当なども廃止・変更されるのが嫌
• 遠方から出社しないといけないのに交通費で全額をまかなえなかったり宿泊費が出なかったり制度が整えられていない
• 自分が納得できる説明をされないまま決定されているのが嫌
• そもそも人と直接会うのがストレスになる
• 出社するなら身だしなみを整えないといけなくて面倒
• 入社前に聞いていた話と違う
• 今困ってなくて出社する意味を感じないのに半ば強制されるのが嫌
• 最初は"週1"でも、ここからどんどん出社方針に切り替わっていくことが予想できる
• やはりフルリモートには限界があるのかと思わされてガッカリしてしまった
• これに限らず色々あって経営や人事労務への信用が落ちていたところにこの件で完全に信用できなくなってしまった

---

自分が想像できていない個々人の事情もあるだろうし、そんなに単純化して考えられるものではない。実際の制度や対応については、"原則"出社なので公開されていない細かい配慮もたくさんあると思う。

大きい会社ならば育児や介護といったライフステージに合わせた制度設計も別途整えられていそうな気もする。個社具体の話は中にいる当事者以外が想像でああだこうだ言ってもあまり意味がない。

フルリモート前提でオフィスから遠い居住地だった / 居住地を変えてしまった については、片道2時間半以上かかるならたしかに週1はしんどいかもしれない。最初は"週1"でも、ここからどんどん出社方針に切り替わっていくことが予想できる も合わせると、自分でも職を変える判断をするかもしれない。それも折り込み済みでの方針意思決定だと思う。

入社前に聞いていた話と違う については、就業規則上どう書かれているかによっては拒否反応のような個々人の話ではなくて "不利益変更にあたるかどうか" が争点になるという話もある。こういった方針変更が何でもまかりとおってしまうと労働者としての権利が守られなくなってしまう。ここは就業規則や雇用契約の内容、労働組合のあり方などにもよるので、想像では何とも言えないところである*1。特に大きい会社ではとても重要だが扱いが難しい。こういった必ず一定は拒否される意思決定方針を実行していっている人たちはめちゃくちゃ大変だと思うし、心労察して余りある。

ともあれ、自分の考えとしては、"個々人の事情があるのは承知の上で、サラリーマンやってるなら受け入れる前提でどうするか考える方がいいのではないか" である。転職を考える人がいるのはもちろん理解はできるし否定もしない。けれどこの方針の変更要請が厳しいとしたら、転職よりも独立の方が向いているかもしれないとも思う。個々人の事情や志向にもよるし、そんなに単純に結論を出せるものではないけれど。

ちなみに自分個人はどう考えているかというと、リモートワークによって家庭事情に合わせて柔軟な働き方ができて非常にありがたいと思っている。それは間違いない。子どもの保育園の送り迎えもあるし、週4~5の出社はさすがに今は厳しい。

一方で、あくまで個人の志向の話でしかないけれどオフィスでお菓子をつまみながら雑談したりホワイトボード囲んでﾔﾝﾔﾔﾝﾔ議論したりするのも好きなんだよな。前職ではよく同僚氏とオフィス近くのハナマサまで散歩に行って、でかい肉を見ながら組織やエンジニアリング、アニメなどの雑談をするのがとても楽しかった。あと同僚にお菓子や飲み物を差し入れするとかもまたやりたい。そう考えられるのは、自分が今も出社できる距離に居住しているからではあるけれど。

なので出社方針に切り替わったとしても、自分はいったんそれに合わせようとするとは思う。というか楽しめるように切り替えるという感じ。何事も自分でコントロールできることを探したほうが楽。簡単な話ではないが、職を変える決断も含めて。

*1:こういった労働関連法まわりの観点を自分は最初はわかっておらず、トモダチに教えてもらいました

人に共感してもらって満足しない

誰かに何かを相談して共感してもらうと心が楽になる。

「わかる」、「あるある」、「それな」のような反応とともに一緒に考えてもらえる人がいるのは素晴らしい。社内の同期と雑談したり、社外のコミュニティの懇親会で話したりできるのはとても幸せなことである。

一方で、ちょっと"痛み止め"的なところもあるので用法用量には注意が必要。共感を得ると気持ちは楽になるが、それだけでは根本解決しないことも多い。本来は一人で向き合って深く解決を考えていかなければいけないのに、無意識に楽になるために人と話して安心してしまったりする。

自分もそうなることがあって、そういう時は新海誠監督が半年以上一人でひたすら絵コンテを描くという話を思い出して切り替えている。

意識して気分転換したり思考を広げたりするといった目的をもって話すのはいいと思う。話せるトモダチも必要。ただし人間強度は下がらないように気をつけねばならない。

上司に期待する振る舞いを伝える

上司を頼ってうまく使うという話は聞くんだけれど、なかなか難しい。具体的にどうしたらいいかわからない人も多いと思う。

1つの考え方として、何か相談をする時に「上司に何を期待してどう振る舞ってほしいか」を明確に伝えるといいかもしれない。

もちろん上司によるので万人に適用できないとは思うが、上司への期待はいくつかに分類できるので雑に書き出してみる。

ただ話を聞いてほしい

• まずは共有だけしたい時や吐き出したい時に使う
• 聞いてもらうだけで思考の整理になったりするし、自分で解決しないといけないとわかっている時などにオススメ

まず意見を聞きたい

• 何かの提案などに対してどう思うか意見を聞きたい時に使う
• どれだけ意見をもらっても、そういうモードだしなと思えて気も楽なのでオススメ

具体的なアドバイスがほしい

• 一緒に考えてもらって具体的な意見がほしい時に使う
• 存分にアドバイスしてよいと伝えると上司も話しやすいのでオススメ

意思決定してほしい

• 何かを決めてほしい時に使う
• 意思決定を誰がするか認識が擦り合っていない場合も補正できるのでオススメ

---

他にもありそうだけどパッと思いつくのはこのくらい。

定期的に1on1で話しているなら、共有や相談内容とセットでこれらの"期待する振る舞い"をラベリングして伝えておくといいかもしれない。

こんなん伝えて対応できる上司はおらんと言われるかもしれない。まあたしかに上司の力量に依存するとは思う。けどちゃんと組織の成果を最大化させることを考えている上司であれば、むしろ感謝してくれると思う。自分ならめちゃくちゃやりやすくてありがたいよ。うまく期待に応えられるかはわからないけど。

生産性は期間と範囲をセットで考える

生産性が高い/低い、効率がいい/悪い といった話をする時は"対象とする期間"と"集計する範囲"をセットで考えたほうがいいと思っていて、その話を雑に書いておきたい。

一例として、「リモートワークのみと週1出社のどちらが生産性が高いか」という話を考えてみる。この例に答えはないし、実際には生産性以外の観点も考える必要がある。組織に応じて決断すべきことなのでこの例の結論はどうでもいい。

• 1日や1週間くらいの期間で個人の生産性を考えるとどうか
  • 自宅の方が生産性が高い。この4年くらいで自宅の作業環境はかなりよくなっている
  • 通勤時間も作業できるので作業に当てられる時間も増える
• 半年くらいの期間で所属チームの生産性を考えるとどうか
  • リモートワーク前提でもいいが、定期的に対面のコミュニケーションを取り入れた方が半年スパンの生産性は上がるかもしれない
  • 海外拠点のメンバーと3ヶ月に1回くらい会っておくとそのあとのコミュニケーションも楽になって全体として生産性が上がるのと同じ

あんまりうまくまとまらなかった。例が悪かったかもしれない。

大事なのは「個人がどうか」、「短期的にどうか」と考えるだけではなくてもう少し広げて考えてみること。生産性の話をする時には、どの期間でのどこの範囲の生産性なのかを揃えて話さないと議論が噛み合わなくなる。意識して切り替えて考えないと、つい個人の短期間での生産性を想定して話してしまいがち。

余談だけれど、自分は"生産性"より"生産力"の議論をした方がいいと思っている。たとえば"生産性"を上げる議論の中では、「人を採用して組織を作る」という話は出にくい。最終的には"生産量"を追求したいわけで、単位あたりの"生産性"について話すよりも"生産力"の話をすべきだと思う。

人に聞いた方が早いかもしれない時に使っているフレーズ

何かを調査している時など、人に聞いた方が早いかもしれないことはよくある。"かもしれない" というのがポイントで、もう少し自分で調べた方がいいかもという気持ちもちょっとあって判断がむずかしい。

経験上そういう時は聞いてしまったほうがよくて、聞くフレーズの引き出しを増やしておくと聞きやすくなる。自分が聞く時にチャットでも口頭でもよく使っているフレーズを雑にまとめてみる。

---

• 質問です！もしすぐわかったら教えてください
• いったん雑に聞いてしまうんですが
• もしもっと詳しい人や適切な人がいたら教えてください
• 何かこれを読むべしみたいな資料をもらえるだけでも助かります
• 以前に対応していたようなのでちょっと聞きたいんですが
• 頓珍漢な質問だったらすみません！
• もしテキストだと説明しづらかったら、シュッとhaddleやzoomで話させてください
• 30分だけ時間もらって相談させてもらっててもいいですか。もしOKなら準備しておきます

---

あくまで小手先の前置きのようなもので、こういう時は聞くべしみたいな指針を決めておいたり役割を明確にしたり内容を簡潔に書いたりするといった工夫も大事。

ちなみに使わないフレーズは「忙しい中すみません」と「一瞬いいですか」である。前者は必要な仕事ならそこまで申し訳なく思う必要はないし、対応優先度も含めて調整すればいいだけなのである程度関係性ができていれば使わない。後者は一瞬で済むことはないので使わない。「3分だけいいですか」とかも同じ。

提案前の頭出しでチューニングする

何かを提案する前に、関係しそうな人に頭出ししておくことがある。自分が頭出しをする時に何をしているかを雑に書いてみる。

頭出しでやっていることは1つで、「たたき台を見せてその人の立場で気になる観点を確認する」である。

何かを変える提案で気にする観点は、その人が所属するチームや立場によって違う。経営や経理なら予算や費用対効果を気にするかもしれないし、エンジニアなら実装難易度や実現したい時期を気にするかもしれない。人事労務なら従業員への影響や説明のプロセスが気になるかもしれない。人によっては、将来的な展望など未来からの逆算ができているかという観点での説明を大事に考えたりもする。

30点くらいのたたき台を持っていくと、その人が何を気にしているかが見えてくる。「全体としてどう思うか」、「どのあたりが一番気になるか/懸念があるか」、「考慮が足りてない観点があるか」という感じで聞いてみるとよい。

提案時にすべての観点を盛り込む必要はないが、少なくとも誰が何を気にするかを把握した上でシナリオを練るのが大事。どこを重点的に話すか、どういう順番でどう強弱をつけるかといった感じで提案内容をチューニングする。

根回しや社内政治みたいで、頭出しをしなければならない組織状態があまり好きではないという人もいるかもしれない。頭出しすべき人数が多すぎたり、頭出しをしないと怒りだす人がいたりするならわからなくはないが、基本的には組織で物事を前に進めるためには必要なステップである。

関係する人やチームに周波数を合わせて提案の下準備をするというプロセスはどんな仕事でも求められる気がする。プロダクトや技術の方針を決める時。マネジメントがチーム体制やリーダーを決める時。採用活動時の候補者へのアトラクトなども全部そう。自分は経験がないが、営業でも窓口となる担当者や決裁権のあるキーマンといった登場人物の立場や考えを少しずつ明確にしながら動いているように見える。

何かを提案した時にはじき返されたりなんか変な空気になったりすることが多いという人は、提案前に関係する人に気になる観点を聞いて提案内容をチューニングするといいかもしれない。

しかしまあ実際には"それができれば苦労はしねえ"と思う。文字にすると華麗にやっているように見えるが、自分は結構しどろもどろな時もあるし失敗することも多い。かんばろう。

開発は問題解決の手段のひとつ

「開発は問題解決の手段のひとつ」という言葉がある。自分はこの言葉が言い訳のように感じてあまり好きではないのだが、開発業務を始めた頃に強烈に意識させられる出来事があった。思い出話として雑に書いてみることにする。

新卒で部署に配属されて半年くらい経った頃、とあるバッチ処理に時間がかかって顧客の業務に影響が出そうということで自分が取り組むことになった。背景としては、「導入顧客の従業員数が来年度に5倍になる予定で、日次で回しているバッチが翌日までに終わらないことが見えている」とのことだった。

当時バッチの並列化基盤を開発している部署が立ち上がっていたこともあって、上司とともに連携してパフォーマンス改善に取り組むことにした。開発業務を始めて間もない頃だったが、そもそも処理時間がかかりすぎで改善の余地が大きいのが素人目に見ても感じられたのである。

マルチスレッドで処理するように作り変えて、処理時間は 1/6 くらいになることが見えてきた。Javaで書かれたそのバッチはグローバル変数に状態を書き込みながら処理しているようなコードもあって、マルチスレッドで並列処理できるように作り変えるのはなかなか大変だったのを覚えている。今思い出してもがんばったと思う。

自分としては顧客の課題は解決できそうで安心していたが、部署の中間レビューではボロボロの結果だった。 「これはなんで速くしたの？」 と言われたのがとても印象に残っている。

「そのバッチはなぜ毎日回しているのか」、「5倍になる従業員すべてに必要な処理なのか」、「顧客のどういう業務のために毎日午前中に終わっている必要があるのか」、「その業務には代替手段はないのか」といった業務の深堀りがメインで、バッチの速度改善のことにはほとんど触れられなかった。自分は「どういうやり方で速度改善をしたか」、「これまでの動きと変わってしまうところがないか」といった開発関連の質問には答えられるよう準備していたが、全然違う方向に話が進んでぐぬぬぬ...となった。その場で議論しながら業務を深ぼっていった結果、「それならコンサルと同行して業務フローを見直す提案をしたら開発せずに解決できるかもしれないけど、その選択肢はなぜ取らなかったのか」というコメントをもらって葬式みたいな雰囲気のままKOって感じだった。

今考えると「もうちょっと早いタイミングでそのレビューやってくれよ」とも思うが、当時の自分はとにかく素直だったので「そういう考え方が大事なのか」と目から鱗だった。「要望をそのまま聞かない」、「裏のニーズを理解する」、「開発は問題解決の手段のひとつ」といった話を聞くと、自分はこの 「なんで速くしたの？」 と言われたレビューを思い出す。

この件は結局速度改善の方向で進めることになったのだが、開発のレビューで顧客の業務理解と課題解決にフォーカスした議論になるのはすごい組織だったと今になって強く思う。10年以上経った今でも思い出すような経験をさせてもらって感謝している。