フルフレックス（Full Flex） とは、特定の勤務時間帯を設けず、いつ働いても良いとする働き方です。
コアタイムはありません。また 事実上のコアタイム（de facto core time） もありません。フレックスを謳っていながらも、事実上チームやプロジェクトにコアタイムが存在するケースは非常に多いですが、そのようなあり方は詐欺であり、フルフレックスとは言えません。
フルフレックスには所定労働時間の義務もありません。非常に多くの企業では導入していますが、本来そのような法的制約は無いのです。たとえば日本では月 150 時間以上の所定労働時間を課すことが多いですが、日本の労働基準法にそのような制約はありません。
フルフレックスの構成要素を整理します。
一つ目は 一時的なコアタイム です。
フルフレックスにコアタイムはありませんが、かといって「一緒に過ごす時間」が全く無いのはさすがに不便です。必要に応じて設けることは許します。これはコアタイムを一時的につくると解釈できます。会議の調整と同様、事前にコアタイムを調整することで確保します。
よくあるアンチパターンが 定例イベント化 です。フルフレックスが上手く行っていることの目安は 定例イベントが一切無いこと です。わかりやすいですね。定期的なミーティングがある時点で、あなたのそれはフルフレックスではありません。フルフレックスは、各自が各自に合った時間帯で働くことができるというものであり、定例イベントはこの原則を壊します。アジャイルにおける朝会や、週に一度の定例会議や勉強会などは典型例です。ここで、
「自由参加制にすればいいのでは？」
と思われるかもしれませんが、いけません。定例イベントはそれ自体は Must または Should なものであり、そんなイベントに対して自由参加を導入すると、参加しない側がネガティブに扱われます。これは情報格差を生み、情報格差は政治を生みます。
二つ目は 計測可能な成果主義 です。
そもそも従業員に特定の勤務時間を課したりコアタイムを設けたりするのは、会社が従業員を信用していないからです。出社回帰もそうですが、会社は従業員という「本質的な怠惰な人間」を出来るだけ働かせるために、物理的に同じ場所と時間に拘束して相互監視させます。経営者目線ですと気持ちはわかるのですが、これは前時代的な搾取のあり方であり、抗わねばなりません。そうは言っても、拘束を解除するとサボタージュが大量発生します。どうすればいいでしょうか。
成果で測ればいいのです。日本の皆さんはともかく、英語圏の皆さんはすでに成果主義が当たり前かと思いますが、まだ足りません。サボタージュを防ぐための、相互監視的な意味合いを持つ仕組みが必要です。それが計測可能な成果主義です。
といっても単純な話で、普段のコミュニケーションを アウトプットベースで行う だけです。記録が残らない会話や、二者にしか見えない Slack や Teams のダイレクトメッセージではなく、チーム全員に見える場所でテキストコミュニケーションをします。または会議の場合は、必ず録画を残します。必ず です。
こうすると、普段のコミュニケーションは「アウトプットした何か」を介する形になります。つまり普段からちゃんと仕事をしている（仕事のためのコミュニケーションをしている）様子が残るようになるのです。これを計測することでサボタージュを防げます。勤務時間なんてどうでもいいんですよ。重要なのは、各自頭と手を動かして具体的な意見や結果――つまりはアウトプットを出せていることです。ならば、アウトプットを見れば良い。
この考え方は一見するとディストピアに見えるかもしれませんが、むしろ逆です。勤務時間やコアタイムで縛る方がディストピアです。計測可能な成果主義を導入すると、私たちは自分にとって過ごしやすい時間帯で働けるようになります。アウトプットを出さないといけないのは、仕事だから当然です。その手段が変わるだけです。時間で縛るディストピアから、各自の自律的な努力に任せるユートピアへと。
最後に、計測可能な成果主義における最重要事項を述べておきましょう。アウトプットを必ず残してもらうことです。必ず です。大事なので二回強調しました。私がナレッジ・アーキテクトとしてフルフレックスを設計するときは、（人事その他個人的なやり取りを除いて）プライベートでやり取りする者にはペナルティを与えます。アウトプットを出さないことは、遅刻と同じくらいの罪として扱います。
三つ目が 省力化された打刻 です。
これは労務の事情によるもので、従業員は通常労働時間を管理せねばならず、管理には定量的な記録が要求されます。日本に限らず、どの国でも法律として定まっていると思います。個人事業主や少人数のベンチャー企業でもなければ、労務管理の理からは逃れられないはずです。ですので、 フルフレックスであっても定量的な労働時間管理が必要 なのです。
もちろん、だからといってこの作業にコストをかけるのは愚かなことです。ですから省力化と名付けています。自動化ではなく 省力化 です。完全に自動化するのが一見すると望ましいですが、自動化と監視は表裏一体です。
一つ問いたいですが、あなたは勤怠管理が自動化されるからといって、自分の PC にエージェントツールをインストールしたいでしょうか？経営者や情シスの人は「はい」と答えるかもしれませんが、厳格な監視が生産性やエンゲージメントを高めることはありません。なぜなら恐怖政治にすぎないからです。
ですので、恐怖政治につながる自動化は避けて、省力化にします。私の感覚ですと、デジタルツールで出勤と退勤を打刻してもらうのが良いバランスだと思います。API やコマンドラインツールもサポートすれば、慣れたエンジニアは勝手に自動化します。打刻のインターフェースは究極的にシンプルにしてください。start_work() と end_work() の二つで足りるはずです。
打刻ツールのシームレスな呼び出しは、実はブルーオーシャンでもあります。たとえば打刻用の小さなボタンを製品として販売できたら、このジャンルで覇権を取れるでしょう。
フルフレックスのメリットは次のとおりです。
政治を減らせることも大きいですが、一番大きいのは 頭を使う仕事ができるようになること だと考えます。
私は スラック（Slack） と呼んでいますが、ただただがむしゃらに受身に仕事をするのではなく、変革的に前提を疑いつつ、創造性も発揮した「本質的に良い仕事」をするためには、物理的な余裕が必要です。時間も、精神も、体力も、認知資源もです。そして スラックは自分の生活リズムに合わない過ごし方に合わせることでゴリゴリと削られます。フルフレックスの最大のメリットは、この浪費を抑えられることなのです。
フルフレックスのデメリットは、従業員に自律性が要求されることです。
私は 雰囲気リマインド（Atmosphere Remind） と呼んでいますが、同じ時間を一緒に過ごすことで「場」が生まれ、「雰囲気」が生まれます。そこに浸っているだけで、次に何をすればいいかが自ずと決まりますし、従うのも楽です。子供は学校に通って、同じ時間割で過ごしますが、まさに同じことです。これは辛辣に言えば、自律的に動けない人を動かすために環境の力を使っている と言えます。
さて、フルフレックスはコアタイムを基本的になくすものですから、雰囲気リマインドもなくなります。計測可能な成果主義があるとはいえ、アウトプット自体は自ら動いて出していかねばならないわけです。フルリモートと合わせると、それこそひとりで、自宅で、自席で出すことになります。このような 「孤独に耐えながらも自律的に動いていける人」が実は圧倒的に少ない のです。
フルフレックスの実現が難しい点もまさにここにあります。自律的でない人のカバーも考えないといけないのです。私も確たる解はない（あれば巨万の富を築けます！）のですが、今のところ一時的なコアタイムを工夫して「密度の濃いコミュニケーションの機会」を設けるしかないと思います。
たとえば二日に一回、一時間くらいカジュアルに雑談するためだけの「雑談タイム」を都度設けることで、自律的でない人のフラストレーションを解消できます。他にもマネージャー側にオフィスアワーを開催させて、その間はいつでも誰でも会話しにいっていいですよ、としてもらうことも多いです。無論、実際はそんな単純ではなく、複数の機会とその頻度を入念に調整することになります。
フルフレックスはどのように実装していけばいいでしょうか。
組織次第なので一律には言えませんが、私がよく使う流れをご紹介します。
順に見ていきましょう。
まずは ミュートデイ（Mute Day） です。
これは 一日誰とも一言も喋らずに過ごす ことを意味します。もちろん、仕事なのでこれで仕事を成立させる必要もあります。
私がフルフレックスの導入をリードする際に、最初に課すのは以下です。
それができたら、続けて以下も課します。
そして最後に「ミュートウィーク（Mute Week） を成功させてください」と言います。
何がしたいかというと、もちろんフルフレックスをさせたいのです。ミュート的に過ごすということは、同じ時間を過ごさなくても仕事が成立できるようにすることとほぼ同義です。たとえばミーティングは行えないので、アウトプットをつくって非同期的にやりとりすることになります。そのために知恵を絞ったり、仕組みや体制を考えたりします。
なんだか丸投げのようですが、私の経験として、フルフレックスをどう実装するかの解は千差万別です。私が「こういう概念と仕組みに従えばいい」と提示したところで、あまり意味はありません。その組織の文化にあったやり方を、その組織自身がつくらねばならないのです。ミュートデイはそのための実践練習になります。ただし、完全な丸投げだと先に進めませんから、背中は押します（次項でコラムとして述べます）。
この段階で、フルフレックスの実装可否も判定できます。仮に「ミュートデイはどうしてもできない！」と主張する組織がいたとしたら、その組織ではフルフレックスはできません。逆を言えば、ミュートデイができるのだとしたら、もう 7 割、いえ 8 割はクリアしたようなものです。
余談ですが、私が仕事として携わるのも基本的にはここまでです。次で述べますが、以降では組織固有の事情に基づいた推進になるので、抽象的な概念を扱うナレッジ・アーキテクトはさして力になれないのです。アーキテクトは開拓こそしますが、推進はしませんし、するべきでもありません。両者の才能は完全に分かれています。推進は専門外です。
私がよく使うのはアイデア出しです。
3時間くらい確保して、仕事はいったん置いてもらって、飲食物も自由に持ち込めますし入退場も自由です、とした上で、アイデア出しを始めます。
テーマは「ミュートデイを実現するためには？」です。
いわゆるブレイン・ストーミングと考えて差し支えありませんが、重要なのは発言ではなく情報です。頑張ってファシリテーションしてひとりずつ喋ってもらうことに価値はありません。十中八九、口頭だけでは足らないので、私はノートやボードを用意して、そこに書いてもらうようにしています。つまり 3 時間のカジュアル・アイデア・ライティング大会 です。これを Casual Writing Camp（CwC）と呼びます。
CwC のゴールは「ミュートデイを再現性を持って成功させられそうだ、が見えること」です。もしくは「いやミュートデイはどう頑張っても無理そうだ、とわかること」でも構いません。一回の CwC で足りなければ、日をおいて複数回実施します。3 時間である必然性はありませんが、午前か午後を丸々使うくらいの余裕はほしいです。私は 3 時間をおすすめします。2 時間は短いですし、4 時間はダレます。
フルフレックスを適用すると、すでに述べたとおりコアタイムがほぼなくなります。ミーティングやペアプログラミング、モブプログラミングを始めたとした高密度なコラボレーションも（一時的なコアタイム以外では）しません。
では普段のやり取りはどうやるかというと、アウトプット・ベースド・コミュニケーションです。アウトプットをつくって、それを見てもらう形で、非同期でやりとりするのです。
ここで困るのが どういう型を使えばいいか という話です。たとえば 1on1 一つを取ってみても、どんな型が必要かは組織次第でしょう。
参考までに、私は 1on1 を「情報交換の場」ととらえた上で、テキスト1on1を開発しました。Q&A 形式でお互いに書き込むというものです。Q&A のテンプレートを複数用意すれば、1on1 に関するコミュニケーションはカバーしきれるでしょう。もちろん、テキストだけでは「非言語コミュニケーション」はカバーできませんから、その分は一時的なコアタイムを使います。では、一時的なコアタイムは具体的にどうやって使う？――ここにも型があるので、ちゃんと突き止めて、言語化して決めます。
ドメイン駆動開発のようなものだと思ってください。型の把握は、ドメイン知識の把握と同義です。つまりそれなりに深いコミュニケーションやヒアリングが要ります。この時点ではフルフレックスは難しいでしょう。ミュートデイもできません。ですので私もしっかり入り浸って、たっぷりお話を聞くことになります。もちろん、私に対してそれだけの用意をしてくれない組織の場合は、申し訳ないですがフルフレックスはつくれません。把握しきれないからです。
ともかく、型を整理できたら、全社的に共有かつ啓蒙します。これらの型を使い分ければ、仕事上のあらゆるやりとりをカバーできる――というところを検証します。できるようになるまで型を充実させてください。というより、このメンテナンスは一生続きます。
ここまでくると、あとは会社として正式にインセンティブをつくる段階です。
就業ルールと評価方法にフルフレックスを組み込みましょう。組織ごとに然るべきプロセスがあるはずです。人事と経営の仕事ですから、これ以上は割愛します。