10数名規模から組織拡大後も安定運用されるフレックス制度を設計!〜大事なのは労務知識だけじゃない!言語化とイメージ共有の重要性〜

何故フレックスを導入するのか

現在、少子高齢化がますます進行することが予測される未来に働き手を確保するという目的で、 政府主導で働き方改革が推し進められています。

それに伴って労働者自身が始業時刻と終業時刻を決め、自由な働き方を実現できるフレックスタイム制にも注目が集まり、導入する企業が増えてきました。

しかしWeb上でフレックスタイムを検索すると、法律の話やメリット・デメリットの話が多く、 結局自社に導入する際の開始手順について、どこから手をつければいいのか分からなかったり、 そもそも自社に向いているのか判断できないというスタートアップ人事の方々が多いように感じています。

私もその一人であり、労務の知識はかじった程度で、給与計算や休日の概念、勤務形態等、全く知りませんでした。

本記事では、労務の知識は浅くてよくわからないけどフレックスを導入したいという人事の皆様に向けて 少しでもお力になれるといいなという想いを込め、私がAzit社にフレックス制度を導入したストーリを公開します。

人事の経験が長い私から見た労務の世界を表現させていただくため、本業の労務の方からはズレている見方と受け取られるところもあるかもしれませんが、温かい目で流していただけると幸いです。

設計前に把握したい前提知識

フレックスの話を始める前に、前提知識を頭にいれていただき、見ている景色をあわせていきたいと思います。 まず勤務形態の種類を頭にいれると考えやすいです。

カテゴリの大小が混ざっているので気持ち悪いかもしれませんが、ものすごく大雑把にくくると①〜③の3つの種類があります。 勤務形態とは違うのですが、管理監督者の扱いもこの並びで把握しておくと分かりやすいので併せて記載します。

変形労働時間制

  • 働いた時間に対して給与を支払う契約
  • 全部で4種類、労働時間をどの単位で区切るか、どちらに勤務時間の裁量があるかによって変わる
    • 変形労働時間制(1ヶ月平均で週40時間以内)※雇用者が勤務時間を決定する ※①
    • 変形労働時間制(1週間平均で週40時間以内) ※雇用者が勤務時間を決定する
    • 変形労働時間制(1年間平均で週40時間以内)※雇用者が勤務時間を決定する
    • フレックスタイム制      ※労働者が勤務時間を決定する ※②

裁量労働制 ※③

  • 働いた時間ではなく、アウトプットで判断し給与を支払う契約
  • 全部で2種類あり、職務内容によって振り分けられる
    • 企画型
    • 専門型

時間が関係ない働き方ではあるものの、予め取り決めた労働時間を逸脱しないようきちんと管理しているか、会社の体制が厳しく見られる

管理監督者

  • 労基法上の定義で経営と一体的な立場にある人は管理監督者となる
  • 管理監督者は法律上の労働時間等の制限を受けない

①②は時間の管理権限が雇用者にあるか、労働者にあるかが大きな違いです。 ①②は働いた時間に対して給与をお支払いしますが、③はアウトプットに対して給与をお支払いします。 しかしながら、残業時間が関係ないわけではなく、きちんと勤怠の管理ができる体制が必要になります。

日本の労基法が毎年アップデートされる中で勤務時間の管理や本当にその職種が裁量労働制に当てはまる職種なのかの見極めが厳しくなってきました。 きちんとした勤怠管理ができないと却って、労務リスクになりかねません。

勤務形態の選択肢を理解すると自分の会社にはどんな勤務形態が適切なのか考えやすくなります。

当時のAzitの状況

現在のAzitは社員数は50名程度、契約社員も10名ほどいます。 正社員はフレックスタイム制(コアタイム12時〜16時)、契約社員には週40時間の変形労働時間制を導入しました。

ここに至るまでの当時のAzitは社員数10名以下、契約社員もいて、全員の働き方を網羅したような雇用形態でした。

しかし実態は、正社員はみんな好きな時間に出社、リモートも多用している状況。 一方で「10時に出社」「モラル守っていこう」といったルールを意識したメッセージも散見され、 新入社員は「何を守ればいいの…?」と混乱の嵐。 採用も進む中、この状況をなんとかしなければいけないと思い、就業形態を整えることにしました。

当時、今いる社員とこれから入ってくるであろう社員にとって良い環境とはどのようなものなのかを考えていました。 なるべく今ある実態を制度に落とし込みつつ、人が増えても破綻しない状態を目指したいと思っていたので、 ぼんやりと正社員はフレックスタイム制、契約社員は週40時間の変形労働時間制がいいだろうと考えていました。

ただ、いきなり決めてリリースしても、当時10名程度の社員数で全員の声が聞ける環境だからこそ、それぞれの思惑がぶつかって着地しない事態になりかねません。

フレックス制度の設計〜導入まで

そこで、作りたい環境を社員とすり合わせて、それを制度+ルールに落とし込みAzitらしいフレックスタイム制を作ろうと考え下記手順で進めました。

  • 作りたい環境を書き出す
  • そのための問題点を書き出す
  • 足りない情報を集める
  • ルールを作る
  • 期間を決めてテスト導入
  • ルールのチューニング
  • 制度に落とし込む

おおまかに、アクションとしては上記に記載した通りですが、 ここからはよりイメージが湧くように更に詳細な流れをご説明します。

スムーズに進めるための目線合わせと期待値調整

テキスト共有ツールを使って、イメージしているフレックス制度を書いていきます。 組織によると思いますが、Azitはフレックスとリモートの概念も混ざっていたので

  • フレックスは勤務時間に関するもの
  • リモートは働く場所に関するもの

というざっくりしたところから書きました。

次に「フレックス導入に伴う考え方」「フレックス導入した後の使用イメージ」と表現し、思い描いている環境の輪郭をなるべく社員に伝わるようにしました。

フレックス導入に伴う考え方と導入イメージ

これを踏まえた上で制度として、以下の図のように具体的な内容を書いていきます。 このとき、冒頭で勉強した勤務形態を意識してルールを最初に定義することとで、労務的に絶対不可能な着地にならないようにコントロールするのがポイントです。 また逆に労務の概念に引っ張られ過ぎないように叶えたい状態を書いていくのも大事です。 こうすることで、どこまでを制度にして、どこまでを運用でカバーするかを社労士にスムーズに相談できました。

ただこの段階ではまだ何も決まっていることはないです。 社員にそれぞれヒアリングをしコアタイムを決めてもらい、このルールで期間を決めソフトランディングしてみよう、という期待値で進めました。 そのため本職の労務の方から見ると、「それフレックスの概念からずれてるじゃん」という内容もこの段階では明文化しています。

Azitの理想とした環境イメージ

課題抽出と軌道修正

2つ目の図の一番下に記載のある『各グループのコアタイム』をご覧頂くと分かる通り、 この段階では各グループ、コアタイムにしたい時間幅や時間帯にばらつきがある状態でした。

ここで議論をして着地させる方法もあるかと思いますが、せっかく実験できる規模だったので全員の意見を一度受け止めた上で、本当にこれでうまく仕事ができるのか試してみました。

ソフトランディング期間を経て、社員に気になることをコメントしてもらい、結果、制度としてはフレックスタイム制(コアタイム:12:00〜16:00)、ルールとしてコアタイムはあるものの運用上の制約はあまりかけない方針で着地しました。

運用結果

ソフトランディングしてわかったことですが、だいたい12時までにはみんな出社します。 CREWが夜動くプロダクトなので、夜中出社しないとのルールにした上でフルフレックスにしてもいいのではないか?というアイデアもありました。

しかしながら、人が増えたときに逸脱した行為をする方がいた場合、ルールだけでは行いを指摘できないので 就業規則は固めに作り、ルールでフルフレックスを良しとする運用にしました。

これにはあとがきで、ルールはアップデートされるものとし、社員みんなでこのルールが長く運用できるようにがんばろう、というメッセージを送りました。

現在、社員数が当時の5倍になっていますが同じルールで運用ができているので、社員に馴染んだ制度になったと思っています。

実は、同じタイミングでリモートワークについても制度を作っています。

こちらはソフトランディング後に作成したものから3ヶ月ほどたって、すぐに見直しを行いました。 その組織にとってちょうどいい軸を定めるのはそんなに簡単ではないので、どんな制度であれシステムと同じでアップデートするという概念を持つのは大事だと思っています。

最後に

制度を作ってみて気づいたことですが、労務側からのアプローチは法律の定規の上で、どこまで広げていくかを考えていくので、私のようにピンポイントの必要な情報だけちょっと勉強したところで、とてもマネできる芸当ではないと思いました。

なので、人事らしく実現できるかどうかはおいておいて、どんな環境を作りたいかのイメージを他者にも伝わるように明文化し、最高の、社労士に相談しながら理想を現実にしていくアプローチがうまくいきました。

とはいえ、やはり労務の知識ゼロでは社労士とのすり合わせや、社員の意見の受け止め方がブレてしまい時間が相当かかっていたかと思います。

プロダクトづくりのPMとエンジニア&デザイナーの関係のように、制度作りについては人事がPMで、エンジニア&デザイナーが労務の関係です。 PMにプログラミングやデザインをしろとは思いませんが、せめて性質はわかっていてほしいと望むように、人事も労務の性質をわかっていると制度作りの精度とスピードが上がると思います。

人事も労務に丸投げするのではなく、補完しあいながら進めることが制度設計の近道なのかと感じました。

Page 5 of 12