日本は解雇規制が厳しいのか?

非 正規労働者の増加とか、雇用の流動性低下とか、終身雇用なんかの話しになると、必ず「日本は解雇規制が厳しいから~」的な発言が出てくる。本当に日本の解雇規制が厳しいのだろうか?

解雇規制の厳しさを表す国債指標がとして、EPL 指標(Employment Protection Legislation Indicator)と言うものがある。2019年の調査結果では、日本のEPL指標は2.08、OECD平均が2.27だから、日本は解雇規制のやや緩い国といえる。日本が比較対象とする事の多い、米国は1.31、英国は1.90、独国は2.33、韓国は2.35だ。

日本は既に解雇規制がやや緩い国であって、安易にさらに解雇規制を緩めるべきでは無い。

正規労働者を解雇できない理由

日本で正社員の解雇が難しい要因は、かなりの部分で日本的な労働契約が原因になっている。能力や成果、職責、職務を明確にせずに雇用契約を結んでいるため、これらを解雇理由として解雇したり、雇用条件を変更することが出来ない。まだ判例が少なく、実際の線引きは難しいものがあるが、現に日本国内においても外資系企業は解雇を実施している。(判例:フォード自動車事件

国内企業も非正規労働者の解雇(雇い止め)を実施している。非正規労働者と正規労働者の間に法律上の差があるわけでは無い。非正規労働者は職務、職責、勤務地、雇用期間などを明確にして雇用契約を結んでいるからこそ、雇用契約に沿って解雇を行えているに過ぎない。

非正規労働者が増えている原因

平成21年度 年次経済財政報告」を見ると解雇規制の厳しい国は非正規労働者の割合が高くなる傾向にある。では日本は解雇規制が厳しいから非正規労働者の割合が高いのかというとそうではない。日本は解雇規制が緩いわりに、突出して非正規労働者の多い国になっている。

要員の一つは非正規雇用と正規雇用を比較した場合に、非正規雇用者の方が極端に解雇しやすくなっている事にある。非正規社員の方が解雇しやすいのであれば、非正規社員の比率が増える方向に働く。非正規社員を減らしたいのであれば、このバランスを取るように政策を定める事が望ましい。必要なのは正社員を解雇しやすくする事では無い。

例えば正社員を整理解雇するときに、会社側が特定の誰かを指定する事は出来ない。非正規社員にも同じ規制を設けるなら、契約満了するときに、契約更新する対象と、雇い止めする対象を、会社側が選択してはならないはずだ。

ちなみにドイツも非正規労働者の解雇規制の弱い国だが、非正規労働者率は低く抑えられている。調べてみると正規労働者を100とした場合、フルタイム非正規労働者の賃金は91と、同一労働同一賃金がかなり守られている。ただフルタイムでは無い非正規労働者の賃金は55と日本並みに低い。(参照:有期雇用の日独比較

正規社員の賃金を100とした場合、日本では非正規社員の賃金が56.6とかなり低い。この事も非正規労働差を増やす原因となっていると考えられる。(参照:地方公共団体の短時間勤務の在り方に関する研究会 同一労働同一賃金について

NextcloudでRedisによるLock管理を有効にする

NextcloudのWindowsアプリからフォルダの同期を行っている途中、~ Locked errorが度々表示されていました。Nextcloudはデフォルトだとmysqlを使用してロック管理をしていますが、高負荷時に問題がおこる場合があるようです。ファイルのロックにかかる問題を回避するために、Redisを導入してTransactional file lockingを有効にします。

Docker環境でRedisを有効にするにはdocker-conpose.ymlに、redisのイメージを追加し、nextcloudのenvironemntにREDIS_HOST、REDIS_HOST_PORT、REDIS_HOST_PASSWORDを、下記の様に追加します。

version: '3'

volumes:
  nextcloud:
  nextcloud-db:
  nextcloud-redis:

services:
  nextcloud-redis:
    image: redis
    ports:
      - 6379:6379
    volumes:
      - ./redis:/data

  nextcloud-db:
    image: mariadb
      ...

  nextcloud:
    image: nextcloud
      ...
    environment:
      - REDIS_HOST=nextcloud-redis
      - REDIS_HOST_PORT=6379
      - REDIS_HOST_PASSWORD=${redis_password}

その後、以下のコマンドを実行します。

$ sudo docker-compose up -d

docker-compose.ymlの設定だけでは Transactional file locking は有効になっていません。./html/config/config.phpを編集して、「’filelocking.enabled’ => true,」を追記します。

  'filelocking.enabled' => true,
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => 'nextcloud-redis',
    'password' => '',
    'port' => 6379,
  ),

Nextcloudの暗号化を有効にするときの覚書

Nextcloud:Encryption configuration

暗号鍵の保存場所

暗号化を有効にしたとき、暗号鍵は./html/data/files_encryptionおよび ./html/data/ユーザー名/files_encryptionに保存されます。基本的にアップロードしたデータと同じ場所に鍵も保管されるため、プライマリストレージをS3等のストレージに変更しているか、あるいは外部ストレージを使用していない限り暗号化によるセキュリティ向上の恩恵はありません。

またこれらの暗号鍵を安全な場所にバックアップしておく必要があります。

回復パスワードの保存

上記フォルダの暗号鍵はログインパスワードを元にして暗号化されているため、ログインパスワードが分からなくなった場合に、パスワードの初期化を行うと暗号化したファイルを読むことが出来なくなります。

これを避ける為には事前に回復パスワードを作成しておく必要があります。

LDAPなど外部の認証システムとの連携

前項の理由により、LDAPなど外部の認証システムと連携している場合に、ファイブのシステム上でパスワードの変更を行う場合、そのままでは暗号ファイルを読み取ることが出来なくなります。Nextcloud上で新旧のパスワード入力を求められるため、そこで旧パスワードを入力する必要があります。

NextCloudでアップロード時に不明なエラーが発生する。

大きなファイルをアップロードしていると「不明なエラー」が発生します。ログを見ると以下の様なエラーが発生していました。どうも帯域が狭いために、アップロード中にタイムアウトエラーが発生しているようです。

Sabre\DAV\Exception\BadRequest: Expected filesize of 10485760 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 5368032 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

10,485,760 bytesは標準のチャンクサイズです。Nextcloudではアップロードをチャンクサイズのデータに分解して処理しています。10MB分送信する前にタイムアウトが発生してしまっていたようです。

タイムアウトを長くしても良いのですが、設定対象が多岐に渡るので、ここはチャンクサイズを5MBに調整する方向で対処します。occコマンドで設定を変更できますので、以下のコマンドを実行してチャンクサイズを変更します。

$ sudo docker-compose exec --user www-data nextcloud php occ config:app:set files max_chunk_size --value 5242880
Config value max_chunk_size for app files set to 5242880

再度ファイルをアップロードしたところ、エラーになる事無く上手く動いているようです。

NextCloudのアクセスログ管理

Nextcloudには標準で監査ログ機能があります。インターネットから接続出来る状態で運用するなら、監理者の責任としてログぐらいは残して起きたいところです。Docker上で動作させているNextCloudのログ設定をおこないます。

監査ログ出力のための設定

「Auditing / Logging」プラグインが有効になっていることを確認して下さい。標準で有効になっているはずです。

以下のコマンドを実行してログの設定をログレベル:1、タイムズーんを日本に変更します。現時点(バージョン23.0.0)では–rotate-sizeの設定は機能しません。明示的にNextcloudのLog Rotateを無効にしておき、別にlogrotateを設定する事にします。

$ sudo docker-compose exec --user www-data nextcloud php occ log:manage --level=info --timezone Asia/Tokyo
Enabled logging backend: file
Log level: Info (1)
Log timezone: Asia/Tokyo

$ sudo docker-compose exec --user www-data nextcloud php occ log:file --rotate-size=0
Log backend file: enabled
Log file: /var/www/html/data/nextcloud.log
Rotate at: disabled

これで./html/data/audit.logに監査ログが出力されるようになるはずです。

Log Rotateの設定

/etc/logrotate.d/nextcloudを以下の通り作成します。パス名の/var/docker-nextcloudは自信の環境に置き換えて下さい。

/var/docker-nextcloud/html/data/nextcloud.log {
  monthly
  rotate 12
  missingok
  notifempty
  compress
  delaycompress
  postrotate
    touch /var/docker-nextcloud/html/data/nextcloud.log
    chown www-data:www-data /var/docker-nextcloud/html/data/nextcloud.log
    chmod 640 /var/docker-nextcloud/html/data/nextcloud.log
  endscript
}

/etc/logrotate.d/nextcloudauditを以下の通り作成します。

/var/docker-nextcloud/html/data/audit.log {
  monthly
  rotate 12
  missingok
  notifempty
  compress
  delaycompress
  postrotate
    touch /var/docker-nextcloud/html/data/audit.log
    chown www-data:www-data /var/docker-nextcloud/html/data/audit.log
    chmod 640 /var/docker-nextcloud/html/data/audit.log
  endscript
}

以下の通りlogrotateデーモンを再起動します。

$ sudo service logrotate restart

以上で毎月ログが圧縮されて別ファイルとなり、12ヶ月でローテーションされます。