マイナンバーカードへの保険証統合と、旧保健証廃止に思うこと

マイナンバーカードと保険証を統合して、既存の保険証を原則廃止しようという計画がニュースになってる。落としたら不安とか、再発行に時間がかかりすぎるとか、個人情報が:・・とか色々と反対意見が出てるけど、IT側からの話しをしたい。

IT担当者側からすると「保険証を統合して、既存の保険証を原則廃止する」というのは、かなり酷い仕様変更である。保険証とマイナンバーカードに求められる非機能要件がまったく異なるためだ。

マイナンバーカードは行政業務効率化を目的に設計されている。効率化が目的なので、実は無くても困らない。電子証明書としての機能が使えなくなったとしても、旧来の非効率な業務で仕事をするために、公務員の残業が増えるだけだ。関わるのは申請者本人と行政担当者だけなので、多少の問題は当事者間の交渉で解決できる。本人確認のための身分証としての機能や、印刷されているマイナンバーなんておまけに過ぎない。

保険証は医療保険を使用するときの本人認証と、医療保険の決済手続を目的に設計されている。認証できないと十分な医療を受けられず、健康を損ねたり、人命にかかわる場合もあり得る。また認証上右方に誤りがあると、1件でも数万円~数千万円の損失が発生する。そのためオフラインでの作業も誤りなく行えることが求められる。事業規模的にIT専任担当者を常駐できないことが多い。

要件をざっくり書き出すとこんなに違う。

マイナンバーカード

  • 平日日中16時間稼働、それ以外は止めても問題は少ない。(稼働率99%程度でもよい)
  • 接続拠点数、5,000箇所(1718市町村、出張所や税務署など含めても3倍程度と推測)
  • 希望者のみが使用する。使わない方は従来通りの方法で手続き。
  • 使用頻度は多くても年に数回。使用時のみ携行する。
  • 障害時には従来通り書類手続きで処理。

マイナンバーカード&保険証(旧保険証原則廃止)

  • 24時間365日無停止。保守点検のための停止も難しい。(稼働率99.99%程度は必要か?)
  • 接続拠点数、266,000箇所(病院8,000、診療所102,000、歯科91,000、調剤薬局60,000、自治体など)
  • 全国民が使用する。未成年者や障碍者(おもに視覚障碍者、知的障碍者、認知症患者、四肢麻痺)への配慮が必要。
  • 使用頻度は多ければ毎月。旅行時など常に携行する必要がある。
  • 障害時にはオフライン認証の仕組みが必要。

導入時点でも無茶をすると思ったが、併用ならまだ突貫工事でも(ぶっちゃけシステムが止まっても)なんとかなる。しかし旧保険証を排除するとなると、非機能要件の差が重くのしかかってくるはずだ。

やっかいなのは病院側のセキュリティ対応だ。今の日本のセキュリティ関連の法律は、情報漏洩をさせた場合の罰則が非常に弱い。「セキュリティパッチを当てていない。」「ログインパスワードを共有していた。」など初歩的セキュリティ対策を怠っていたとして、それで善管注意義務として処罰されることは希であるし、情報漏洩に限らず法人に対する罰則は緩いものが多い。現マイナンバー法でも故意に漏洩させたのでは無い限り罰則は無い。現行のままでは早晩情報漏洩を起こすであろうし、かといって厳しくすれば殆どの病院が対応出来なくなる可能性が高い。

良くある非難への反証

マイナンバーカードの再発行には2週間~1ヵ月もかかる。紛失したらどうするのか?→実は健康保険証の再発行にも1週間~2週間かかる。健康保険証を紛失した場合には「健康保険被保険者資格証明書」を即日発行して対応している。「健康保険被保険者資格証明書」の有効期間は1週間程度と極めて短い。同様の代替手段を整備する必要は有るだろう。

Stable Diffusion+Windows 10+AMD GPUの環境で動かす

Stable DiffusionをWindows 10とAMD GPU上で動作させている記事、Running Stable Diffusion on Windows with an AMD GPUを見つけたので、実践。以下は作成してみたサンプル。

stable_diffusion_sample

事前準備

まずは実行環境を確認。
・メモリ6GB以上のAMD GPU
・Pythonの3.7、3.8、3.9、3.10がインストールされている
・Gitがインストールされている。
・Hugging Face(Stable Diffusionの学習済みモデルを公開している)のアカウント
・6GBの学習モデルをダウンロード&変換する勇気

と言うわけでPythonのインストール。PythonはMicrosoft StoreからPython 3.10をインストールしてしまうのが手がかからない。

続いてGitのインストール。私はVisual Studioと一緒にインストールされてしまっているが、単独でインストールするならGit for Windowsをインストールするのが良いかと思う。

さらにHugging Faceにユーザー登録する。ユーザー登録自体は無料。

インストール作業

ますはインストール先となるフォルダを作成する。私はD:\stable-diffusionにした。インストールには15GB程度の空き容量が必要になるはずなので、十分に空きのあるドライブを選ぶこと。PowerShellからコマンドプロンプトを開いて、インストール先フォルダに移動します。

Microsoft’s DirectMLに対応したOnnx runtimeをhttps://aiinfra.visualstudio.com/PublicPackages/_artifacts/feed/ORT-Nightlyからonnxruntime-directmlをダウンロードする。ダウンロードするランタイムはPythonのバージョンによって異なる。Python 3.10.xをインストールしているなら、cp310(onnxruntime_directml-1.12.0-cp310-cp310-win_amd64.whl)をダウンロードする。

コマンドプロンプトまたはPowerShellのプロンプトを開いて以下のコマンドを実行。

python -m venv ./virtualenv
./virtualenv/Scripts/Activate.ps1 または virtualenv\Scripts\activate.bat
pip install diffusers==0.3.0
pip install transformers
pip install onnxruntime
pip install protobuf<3.20.x
pip install onnx
pip install pathToYourDownloadedFile/ort_nightly_whatever_version_you_got.whl --force-reinstall

Stable Diffusionの学習済みモデルをダウンロードするには、ライセンス条項に同意する必要があります。ライセンス条項を確認した上で、Hugging Faceのhttps://huggingface.co/CompVis/stable-diffusion-v1-4のページにアクセスして、「 have read the License and agree with its terms」にチェックをして、Access Repositoryをクリック。

Hugging FaceのAccess Tokenを発行する必要があります。Hugging FaceのWEBページ右上のユーザーアイコンから「Settings→Access Tokens」に進み、Access Tokenを発行します。

プロンプトから以下のコマンドを実行します。

huggingface-cli.exe login

Token:とプロンプトが表示されるので、先ほど発行したAccess Tokenを入力します。「Your token has been saved to ~」と表示されれば大丈夫です。

Stable DiffusionをOnnixに変換するためのスクリプトを「https://raw.githubusercontent.com/huggingface/diffusers/main/scripts/convert_stable_diffusion_checkpoint_to_onnx.py」からダウンロードします。

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

python convert_stable_diffusion_checkpoint_to_onnx.py --model_path="CompVis/stable-diffusion-v1-4" --output_path="./stable_diffusion_onnx"

学習モデルのダウンロードと変換に数時間かかります。気長に待ってください。

試しに画像を生成してみます。以下の内容をtext2img.pyとして保存して、プロンプトから実行してみてください。output.pngが無事に生成されればインストール成功です。

from diffusers import StableDiffusionOnnxPipeline
pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", provider="DmlExecutionProvider")

prompt = "A happy celebrating robot on a mountaintop, happy, landscape, dramatic lighting, art by artgerm greg rutkowski alphonse mucha, 4k uhd'"

image = pipe(prompt).images[0] 
image.save("output.png")

生成する画像サイズや、反復計算する回数などのパラメータを指定する事もできます。それらを指定する場合には以下のコードを参考に書き換えてください。

from diffusers import StableDiffusionOnnxPipeline
import numpy as np

def get_latents_from_seed(seed: int, width: int, height:int) -> np.ndarray:
    # 1 is batch size
    latents_shape = (1, 4, height // 8, width // 8)
    # Gotta use numpy instead of torch, because torch's randn() doesn't support DML
    rng = np.random.default_rng(seed)
    image_latents = rng.standard_normal(latents_shape).astype(np.float32)
    return image_latents

pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", provider="DmlExecutionProvider")
"""
prompt: Union[str, List[str]],
height: Optional[int] = 512,
width: Optional[int] = 512,
num_inference_steps: Optional[int] = 50,
guidance_scale: Optional[float] = 7.5, # This is also sometimes called the CFG value
eta: Optional[float] = 0.0,
latents: Optional[np.ndarray] = None,
output_type: Optional[str] = "pil",
"""

seed = 50033
# Generate our own latents so that we can provide a seed.
latents = get_latents_from_seed(seed, 512, 512)
prompt = "A happy celebrating robot on a mountaintop, happy, landscape, dramatic lighting, art by artgerm greg rutkowski alphonse mucha, 4k uhd"
image = pipe(prompt, num_inference_steps=25, guidance_scale=13, latents=latents).images[0]
image.save("output.png")

制限

この時点ではいくつかの制限があります。

生成画像解像度の制約

512×512以上の解像度の画像を生成することが出来ません。これはOnnixの制約です。より高解像度の画像が必要な場合には、waifu2xなどの超解像AIを併用するなどの工夫が必要です。

NSFW(職場閲覧注意)による制約

真っ黒な画像を生成することが頻繁にあります。標準で組み込まれているNSFW(職場閲覧注意)フィルタにブロックされていることが原因です。以下の様に1行追加する事でNSFWを無効に出来るようですが、Stable Diffusionの利用規約上NSFWを無効にして生成した画像の公開は慎重に行いましょう。NSFWを無効にすると相当に高速になるという副次的効果もあるようです。

pipe = StableDiffusionOnnxPipeline.from_pretrained("./stable_diffusion_onnx", device_map="auto", provider="DmlExecutionProvider", max_memory=max_memory_mapping)
pipe.safety_checker = lambda images, **kwargs: (images, [False] * len(images))

その他、細かなHackは続編のStable Diffusion Updatesに・・・・

いろいろな資格の投資対効果

半分趣味で資格を取るなら投資対効果なんて考える必要は無いが、賃金を増やす為に資格を取ろうと考えて居るなら投資対効果を考えるのは大事だ。中小企業診断士の資格が割に合わないと言う話しをTwitterで見かけたので、ざっくりと計算してみた。

各数字は凄く雑なので、細かい突っ込みは受け付けない。資格取得費用の大部分は勉強にかかる時間によって発生する機会損失である。今回は1時間2,500円で計算している。1年辺りの資格手当の額は求人などをざっくり見て中央付近を採用している。資格取得を切っ掛けに独立起業する事は想定していない。

資格名受験費用その他費用学習時間総費用資格手当維持費用増益投資効率
中小企業診断士302301,0002,760180561244%
公認会計士201503,0007,6701,2001201,08014%
税理士81102,0005,11860010050010%
社会保険労務士15301,0002,5453604032013%
情報処理安全確保支援士8205001,278180661149%
電気工事士二種11301002916006021%
公立大学2,5007,680217,0001,75001,7508%
金額は千円

なるほど、中小企業診断士の投資効率は4%と割りに合わなそうである。同じコストを投じて資格を取るなら、社会保険労務士の方がはるかにマシである。

工事士などのガテン系資格は資格取得による賃金増加額こそ小さいものの、投資効率は極めて高そうだ。工事士系資格で資格手当を貰えるような職場なら、確実に抑えていくのが良さそうだ。

あるていど勉強ができるなら当たり前のように大学進学を選択するが、投資効率は決して高くはない。在学中に勉強していることによる機会損失は意外に大きいのだ。投資効率を重視するなら、工業高校か高専でIT系資格を取得して就職するのが一番良いのかもしれない。

ボールペンリフィル(替え芯)の選び方

贈答品で頂いたボールペン、気に入って使っていてインクが無くなってしまったとき、何処にもメーカーも型番も書いていないし、替えインクを買いたくても諦めていたりしませんか?

ボールペンのインクの形状はJIS規格で定められており、A1、A2、B、D、E、F、G1、G2、Hの9種類に分かれています。同じ規格のリフィルであれば、他社製のリフィルでも使える可能性が高いです。HはA1~G2の何れにも一致しない規格ということなので、実質は8種類ですね。

ペン先直径、直径(一番太いところ)、全長の三つを計って以下のリストと比較してください。

規格ペン先の直径直径全長
A12.40mm3.20mm106.8mm
A21.60mm3.20mm106.8mm
B2.28mm3.00mm98.2mm
D2.35mm2.35mm67.0mm
E2.25mm3.00mm140.0mm
F2.30mm3.00mm143.0mm
G11.60mm5.00mm106.8mm
G22.54mm6.00mm98.1mm
H

だいたいG2規格が多いようです。A1~G2の規格に一致しない場合には、各メーカの独自規格と思われます。

その場合には日本筆記具工業会で公開している「油性ボールペン替芯互換表」「ゲルボールペン替芯互換表」を参照してみてください。各メーカーが出しているリフィルのペン先直径(外径)、直径(最大径)、全長が一覧表になっているので、その中から一致する型番を探してください。型番が絞られたらメーカーのページで、ペン先やお尻部分の形状が一致しているものを探す事になります。

PTAや自治会でIT活用が出来ない理由

2013年の国際成人力調査をご存じでしょうか?平均点で見ると、読解能力、数的思考力、IT活用能力の何れでも日本がトップなのです。調査結果は読解能力、数的思考を得点によってレベル1未満~レベル5までの6段階に、IT活用能力はレベル1未満~レベル3の4段階に分けて成人割合もだしています。各レベル毎の成人割合を見ると日本の特徴が際立ってきます。読解能力がレベル2以上となる成人割合は日本93.9%、ドイツ81.0%、米国78.3%。数的思考力がレベル2以上となる成人割合は日本90.6%、ドイツ80.1%、米国67.1%。IT活用能力がレベル2以上となる成人割合は日本34.6%、ドイツ36.0%、米国31.1%。

日本では読解能力、数的思考力が一様に高い水準にあり、レベル1やレベル1未満の割合が極端に少ないのです。

このことが日本においてPTA役員や自治会役員を持ち回りやくじ引きで決めることを可能にしています。紙と鉛筆で業務を行う限りにおいては、日本人ならほぼ誰でも業務を遂行できるだけの事務能力を持ち合わせているわけです。全員に一様に業務を割り振り、一人あたりの負担を減らすと共に、全員が公平に負担する仕組みを作ってきました。日本以外において、同じような役員の決め方をしたら、業務遂行能力を持たない役員が発生する確率が高く、成り立たないでしょう。

対して、IT活用能力においては、日本では成人の34.6%だけが高い能力を有しており、日本の平均値を世界でもトップレベルに引き上げています。

このことがPTA役員や町内会や自治会におけるIT活用の難問になります。ITを活用するなら、成人の35%しか業務を遂行できません。従来のように一様に全員が業務を負担することで公平性を保つ仕組みは維持できません。特定の人だけに業務が集中する事を容認し推奨するような価値観の変革が必要になるのです。

PowershellからBITS(Background Intelligent Transfer Service)を使用して大容量ファイルを配布する

BITSはMicrosoftがWindowsに標準機能として載せている分散ダウンロード機能です。WindowsUpdateもバックグラウンドでBITSを利用しており、LAN内の複数のPCからWindowsUpdateをダウンロードする場合には、他のパソコンが自動的にキャッシュサーバーとなることで、インターネットとの通信負荷を押させてくれます。このBITSはWindowsUpdate専用の機能というわけではなく、簡単なプログラムを用意すれば、大容量ファイルを配布するときに自由に活用することができます。

昨今、プログラムやセキュリティパッチのフットプリント(ファイルサイズ)が大きく鳴り続ける、パッチ配布のネットワーク負荷が原因でインターネットが輻輳するなんて事件もありましたね。社内ネットワーク(WAN)はその構造上、どうしても一か所に負荷が集中しやすく、分散ダウンロードができると随分と助かりますね。

BITSでダウンロードするための一連の流れは次のようになります。

  1. HTTPサーバー上にダウンロード元となるファイルを用意します。
  2. Start-BitsTransferでBITSに新しいダウンロード要求を登録します。
  3. 定期的にGet-BitsTransferを呼び出しダウンロードの完了を待ちます。
  4. ダウンロード完了後にComplete-BitsTransferでファイルに書き出します。

上記をPowershell Scriptで記述したのが下記です。このスクリプトをダウンロードが完了するまで定周期で実行します。

$displayName = 'BITS_Sample'; # BITSにダウンロード要求を登録する時の表示名
$fromURL = 'http://www.example.co.jp/BITS_Sample.zip'; # ダウンロード元のURL
$destFile = 'C:\TEMP\BITS_Sample.zip'; # ダウンロード先のファイル名
$logFile = 'C:\TEMP\BITS_Sample.log' # ログ出力先のファイル名

$noBitsInstance = $true;
$completeDownload = $false;

Add-Content -Path $logFile -Value ('Start Script:' + (Get-Date));

# ダウンロード先フォルダが無ければ作成しておく
if ($false -eq (Test-Path 'C:\TEMP')){
    mkdir 'C:\TEMP';
}

# ダウンロードファイルが
if ($false -eq (Test-Path $destFile)){
    # BITSへのダウンロード要求を列挙する
    Get-BitsTransfer | Where-Object {
        Add-Content -Path $logFile -Value ('BITS Status:' + $_.DisplayName + '-' + $_.JobState);
        # 表示名の一致しているダウンロード要求が転送終了になるまで待機
        if ($_.DisplayName -eq $displayName){
            $noBitsInstance = $false;
            if ($_.JobState -eq "Transferred") {
         # ダウンロード完了した転送要求を完了させる
                Complete-BitsTransfer $_;
                $completeDownload = $true;
            }
        }
    }

    # BITSにダウンロード要求が登録されていなければ、新たに登録する。
    if ($noBitsInstance -eq $true){
        $delayMinute = Get-Random -Maximum 240;
        $kickDateTime = (Get-Date).AddMinutes($delayMinute);

        # 新規ダウンロード登録までランダムに待機する
        Add-Content -Path $logFile -Value ('Wait ' + $delayMinute + ' Minutes');
        While ($kickDateTime -ge (Get-Date)){
            Add-Content -Path $logFile -Value ('delay - ' + (Get-Date));
            sleep 60;
        }

        # 新規にダウンロードを登録する
        Add-Content -Path $logFile -Value ('Start BitsTransfer:' + $displayName + '-' + $destFile);
        Start-BitsTransfer -Source $fromURL -Destination $destFile -Asynchronous -Priority Normal -DisplayName $displayName
    }

    if ($completeDownload -eq $true){
        # ダウンロード完了後の処理
        Add-Content -Path $logFile -Value ('Complte Download:' + $displayName + '-' + $destFile);
    }
}
Add-Content -Path $logFile -Value ('End Script:' + (Get-Date));

私はActive Directoryのグループポリシーでログオンスクリプトとして登録しました。コントロールパネルのタスクで定周期に起動してもよいでしょう。

BITSで使用する帯域の制限などはレジストリに記述するか、ActiveDirectoryのグループポリシーで定義します。

Nextcloudに大きなファイルをアップロードするとRequestTimeTooSkewedが発生する

NextcloudでストレージにS3を使用している場合に、約500MBを超える大きなファイルをアップロードすると、以下のようなエラーが発生する場合がある。

An exception occurred while uploading parts to a multipart upload. The following parts had errors:
- Part 1: Error executing "UploadPart" on "https://nextcloud-xxxx.s3.us-west-1.wasabisys.com/xxxx"; AWS HTTP error: Client error: `PUT https://nextcloud-xxxx.s3.us-west-1.wasabisys.com/xxxx` resulted in a `403 Forbidden` response:
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the reque (truncated...)
RequestTimeTooSkewed (client): The difference between the request time and the current time is too large. - <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the request time and the current time is too large.</Message><RequestTime>20220101T141414Z</RequestTime><ServerTime>2022-01-01T14:32:28Z</ServerTime><MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds><RequestId>xxxx</RequestId><HostId>xxxx/xxxx</HostId></Error>

この問題を解決するには./html/config/config.phpに以下の行を追加し、500MBよりも適当に小さなサイズで分割してアップロードするように設定する。下記の例では約20MBに設定を変更している。

    array (
      'bucket' => 'nextcloud-bucket',
      'key' => '{key}',
      'secret' => '{secret}',
      'region' => 'us-west-1',
      'hostname' => 's3.us-west-1.wasabisys.com',
      'port' => '443',
      'objectPrefix' => 'urn:oid:',
      'autocreate' => false,
      'use_ssl' => true,
      'use_path_style' => false,
      'legacy_auth' => false,
      'uploadPartSize' => 20971520,
    ),

S3にsinglepartでアップロードできるファイルサイズの上限は5GBとなり、より大きなファイルをアップロードするときにはmultipartでアップロードする必要がある。標準設定のNextcloudでは約500MBを超えるファイルをアップロードするときにはmultipartアップロード を使用する。

S3のmultipartアップロードがもつ仕様上の問題で、通信帯域の不足等によりデータのアップロードに約15分以上かかると、HTTPヘッダに記載されている時刻とAWS側サーバーとの時刻の差がMaxAllowedSkewMillisecondsを超えるために”RequestTimeTooSkewed: The difference between the reque (truncated…)
RequestTimeTooSkewed (client): The difference between the request time and the current time is too large.”のエラーが発生する。

MaxAllowedSkewMillisecondsは900000msに固定されいる。HTTPのリクエストデータを複製することによる第三者の攻撃を防ぐために設けられている値で、ユーザー側でこの値を任意に変更する事は出来ない。この問題を避けるには15分以内にアップロードが終わる程度の適当なサイズに分割してアップロードする必要がある。

ただし小さく分割するとS3にアップロードできる最大ファイルサイズが小さくなる事にも注意しなくてはならない。S3には最大で5TBのファイルを保管できるが、 multipart アップロード時には10,000分割以上に分ける事ができない。仮に上記のように20MBで分割した場合には、200GBを超えるファイルをアップロード出来ない。(Amazon S3 multipart upload limits

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

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

解雇規制の厳しさを表す国債指標がとして、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上で新旧のパスワード入力を求められるため、そこで旧パスワードを入力する必要があります。