Node.jsのcallbackスタイルAPIをPromiseに変換するHaxe macroが書けた

執筆時のバージョン情報: Haxe 3.4.6

Node.jsのcallbackスタイルAPIを毎回手でPromiseに変換するのがダルすぎる。

最初はNode.jsの util.promisify() を使おうかなと思ってたんだけど、Promiseを返す関数に変換するだけで、そのままcallしてくれるわけではないのと、型がどうしても付けづらいのでやめた。次の方法として、マクロでどうにかならないか試していたら、思いのほか良いものができた。

import haxe.macro.Expr;
import haxe.macro.Context;

class PromiseTools {
    public static macro function callAsPromise<T>(
            fn: Expr, ?params: ExprOf<Array<Dynamic>>, ?cb: ExprOf<Array<Dynamic> -> T>): ExprOf<js.Promise<T>> {
        var args = (if (isNull(params)) {
            [];
        } else {
            switch (params.expr) {
                case ExprDef.EArrayDecl(exprs): exprs;
                case _: Context.error("params must be EArrayDecl", params.pos);
            }   
        }).concat([
            if (isNull(cb)) {
                macro function (error, result) {
                    if (untyped error) {
                        reject(error);
                    } else {
                        // workaround for `Error -> Void -> Void` callback.
                        resolve(untyped result);
                    }
                }
            } else {
                macro untyped function (error) {
                    if (untyped error) {
                        reject(error);
                    } else {
                        var data = untyped __js__("Array.from(arguments).slice(1)");
                        resolve((${cb})(data));
                    }
                }
            }
        ]);

        return macro new js.Promise(function (resolve, reject) {
            $e{ {expr: ExprDef.ECall(fn, args), pos: fn.pos} };
        });
    }

    static function isNull(expr: Expr): Bool {
        return switch (expr.expr) {
            case ExprDef.EConst(CIdent("null")): true;
            case _: false;
        }
    }
}

usingを使えば、割とすっきりとしたコードになる。

import js.node.Fs;

using PromiseTools;

class Main {
    static function main() {
        Fs.readFile.callAsPromise(["test.txt"]).then(function (data) {
            trace(data);
        });
    }
}

コールバックが Error -> T -> Void ではなく、Error -> T -> Dynamic -> Void みたいな引数が2個を超える変形パターン(Cosmos DBのNode.js SDKがこんな感じ)にも対応できた。

// var client: DocumentClient = ...;

client.readDatabase.callAsPromise([DATABASE_URI], function (ret): Database {
    trace(ret[0]);
    trace(ret[1]);
    return ret[0];
});

これでだいぶ治安が良くなった。

Haxeで型パラメータに構造的部分型を指定した時の挙動

執筆時のバージョン情報: Haxe 3.4.6

Haxe/JSでCosmos DBクライアント(npm documentdb)のexternを書いているのだが、Haxeでexternを書くたびにたまにハマることがある(ハマるたびにググってる)ので、メモを残しとく。

DocumentClient#createDocument() というAPIは、JSONid がrequired、ttl がoptional、あとは任意をフィールドを指定できる(指定した値がCosmos DBに保存される)インターフェースになっている。

これを何も考えずにexternに落とすと(というか、TypeScriptの.d.tsを下手に書き直すと)こんな感じになる。
※説明用に簡略化しているため、実際のnpmのインターフェースとは異なっているので注意。

@:jsRequire("documentdb", "DocumentClient")
extern class DocumentClient {
    function createDocument(link: String, body: Document): Void;
}

typedef Document = {
    var id: String;
    @:optional var ttl: Int;
    /* id以外のフィールドは動的設定可能 */
}

これをこんな感じで使おうとするとコンパイルが通らない。

// var client: DocumentClient = ...;
// var link = "...";

client.createDocument(link, {
    id: "xxxx",
    name: "hoge"
});

こんな感じのコンパイルエラーが出る。 name なんていうフィールドが余計についとるよと怒られる。

{ name : String, id : String } has extra field name

で、 Haxeのマニュアル に従ってexternを書き直すとこんな感じになる。

createDocument()の型パラメータとして <TBody: Document> を指定している。TBodyはDocument型で定義されたフィールドを最低限持ってれば、他に余計なフィールドを持っててもいいよという定義になる。

@:jsRequire("documentdb", "DocumentClient")
extern class DocumentClient {
    function createDocument<TBody: Document>(link: String, body: TBody): Void;
}

typedef Document = {
    var id: String;
    @:optional var ttl: Int;
    /* id以外のフィールドは動的設定可能 */
}

で、これでめでたしめでたしかと思いきや、コンパイルが通らない。

client.createDocument(link, {
    id: "xxxx",
    name: "hoge"
});
Constraint check failure for createDocument.TBody
{ name : String, id : String } should be js.npm.documentdb.Document
{ name : String, id : String } should be { ?ttl : Null<Int>, id : String }
{ name : String, id : String } has no field ttl

ttl フィールドがねーぞと怒られる。@:optionalだから許してくれてもいい気がするんだがー…。

仕方ないので、利用側のコードでこういう感じに書いて回避する。

client.createDocument(link, {
    id: "xxxx",
    ttl: js.Lib.undefined,  //nullだと期待通りに動作しないライブラリがある
    name: "hoge"
});

もしくは、次のようにDocumentをカスケーディングした型を定義して、型が自明になるようなコードにする。ここでは変数に型を明示しているが、関数を作って引数の型として指定するようなコードでも当然良い。

typedef User = {>Document,
    var name: String;
}
var user: User = {
    id: "xxxx",
    name: "hoge"
}

client.createDocument(link, user);

「労働者側の裁量で深夜労働もできる勤務体系」をまじめに考えるとクッソ大変な話

これを読んだ。

tech.grooves.com

就業規則おじさん枠として、「労働者側の裁量で深夜労働もできる勤務体系」について言及しようと思う。労働法のエキスパートではないので、実際に検討をする場合は社労士と相談が必須。

お前誰よ

過去にこんなことをした。

terurou.hateblo.jp

本業ではないので労働法のエキスパートではないが、

  • 自分で就業規則をゼロから書き起こした零細企業実務者
    • 就業規則は執筆中~施行前まで社労士チェックが何度も行われている
  • みなさんが期待する裁量労働制・なんでもありフレックスタイムを本気で検討したが、制度設計・運用がともに無理だと思ったので断念した

という前置きで。

蛇足だが、就業規則GitHubをした影響で本業の社労士さんからコメントを頂くことがチョイチョイあるが、「ちょっと気になるところがあるけど、大体こんなところだよね」という評価である。

元記事に対する個人的な総評

  • 着手開始から実質3-4か月程度で制度導入が完了していることを考えると、会社としてはすごくスピーディにやっていて評価できる
  • ただ、軽微な誤り(フレックスタイム制コアタイムが必須は誤り)があったり、省略しただろうなぁという行間を感じる部分がある
  • はてブやらTwitterでの言及を見ていると好意的な反応が多いが、ちらほら「法があるのはわかったが、もっとできるはず」「まだ厳密な労働時間管理なんて」「なんで今頃知ったみたいなこと言ってんの」みたいな、ほぼ言いがかりなコメントもついていて、社会の厳しさを感じる

就業規則の変更に必要なこと

就業規則の変更には、労使間の同意(と労基署への提出)が必要で、変更の際、

  • 合理的な理由および労使間の合意がなく、労働条件の不利益変更はできない
  • 同一労働同一賃金(特定個人のみの待遇が良い・悪いがあってはならない)

という原則は厳守する必要がある。

追記:法的義務は「労働者側の話を聴かなければならない」までなので、会社側は話を聴いた上で無視することも可能だが、不利益変更や特定人物のみに損得が発生することをごり押しするような会社に人が残るかというのは…。それこそ労働問題で訴訟リスクも発生するので、ごり押しするメリットは会社側には薄い。

深夜労働の法規制

そもそも深夜労働(深夜業)は法規制の対象で、健康を害する危険があるからアカンというスタンスである。その上で、どうしても深夜労働を行う場合は、

  • 深夜労働には割増賃金の支払いと労務管理が必要
  • 年少者や妊産婦の深夜労働は禁止
  • 常時500人以上の深夜労働に従事する労働者がいる事業所では、産業医の設置と6か月で1回以上の健康診断の義務
  • 6か月間で月平均4日以上の深夜労働をしている労働者が自発的に健康診断を受け、診断結果に異常があり、それを会社に提出した場合は、会社側は深夜労働を減らすなどの対策を講じる必要がある

という規制に従わなければならない。 労働者が自由意志で深夜労働を行うということは、労働法で想定がされていないし、おそらく今後も想定されるとは思えないようなイレギュラーな話である。

「労働者側の裁量で深夜労働もできる勤務体系」での給与モデル

元記事でもあったが「能力は同じでも、自由意志で深夜に働いたか否かで給与額が異なる」というのは、「同一労働同一賃金に反して不平等(=特定個人だけ利益/不利益が生じる)」ということになる。

よって、これが生まれない給与モデルを考える必要があるが、現実的にとれる選択肢は「みなし残業(みなし深夜労働)」を導入するしかない。具体的には、「全ての労働日において深夜労働をしたものとみなす割増賃金」を最初から給与に織り込めばよい。

  • 深夜労働の割増率は25%
  • 深夜労働の対象は22時~翌5時の7時間
  • 一般的な8時間労働の事業所であれば、全ての労働日で深夜労働したとすると、7/8が深夜労働に該当する
  • 25% * 7 / 8 = 約21.9%

ということで、「労働者側の裁量で深夜労働もできる勤務体系」が適用される部門の全員に、給与額の21.9%分を固定手当として支給すれば要件は満たせる。

しかし、「労働者側の裁量で深夜労働もできる勤務体系」を導入するために、人件費がいきなり21.9%上がることを承認できる経営者はまず居ないと思う。上がった人件費以上に売上や何らかの価値が得られるのであれば喜んで承認すると思うが、ここの合理性を説明するのは相当ハードルが高い。

そうなると別の方法として、現行給与の支給額を変更せずに、手当の構成を変更するという方法しかない。例えば、現行の毎月給与の額面が40万円だったとして「基本給328,205円+みなし深夜労働71,795円の計40万円」とすれば、要件は満たせる。

ただ、この手法も「現行よりも基本給が下がる」という割と致命的な問題がある。基本給は割増賃金を算定する際の基準額となるので、深夜労働以外の超過労働や休日労働に係る割増賃金の額も下がってしまう。ただの給与の切り下げでしかないので、「深夜労働ができなくても何も問題がないよ」という社員からすると寝耳に水でしかない。

給与モデルの面から考えたときに、適用部門の全員がこれを望んでいるか「希望者のみに深夜労働もできるようにするよ。ただし自由な勤務が得られる代わりに、基本給が下がるから超過労働や休日労働をした場合に得られる給与額は減るよ。これを会社から強制適用することはないよ」という労使協定があれば、就業規則に盛り込めるのではないかと思う。ただ、社労士(と労基署)に確実に相談が必要となることは忘れてはいけない。

勤怠・給与計算のルール・システムの複雑化

給与モデルが決まったとしても、次の山として給与計算ルールが複雑化するという問題が生じる。勤怠システムを作ったことがある人間であれば既に気づいていると思うが、「深夜に仕事しても良く、翌日は遅く仕事しても良い」をやると、「一日の切れ間がわからなくなる」という問題ある。

極端な例を出すが、

  • 1/15 10:00-19:00
  • 1/16 17:00-26:00
  • 1/17 欠勤
  • 1/18 24:30-33:30
  • 1/19 21:00-30:00

みたいな勤怠を扱えなければならない。これをシステム化するとして、要件として書き出すと、

  • 24時以降の時間も入力可能とすること
  • 別の日付の勤怠の時間帯が重なっている場合は入力エラーとすること
  • 欠勤があったことが判定できること
  • 休日出勤を判定できること
  • みなし深夜労働手当者とそうでない勤務体系の従業員で遅刻・早退等の計算方法が切り替わること
  • ...

のような要件でシステム化を行う必要がある。業務システムの開発で良く見聞きする「この要件必要なんですか?実装すると工数が膨らむんですけど」「業務をパッケージの方に合わせろよ」という話が大型ブーメランとして返ってくる。

システム化の方から先に書いたが、これを就業規則として明文化しなければならず、さらに社労士チェックを通す必要がある。

社労士相談コストの増大

既に前述している通りだが「労働者側の裁量で深夜労働もできる勤務体系」は、労働法制上想定されていない(むしろ規制されている)イレギュラーな働き方で、システムも複雑になりすぎる。

これらを就業規則として盛り込むには、労働法に違反していないことを社労士にチェックしてもらう必要がある。下手に運用を開始すると、昨今のブラック企業取り締まりが強化されてきている状況下では一発レッドカードになりかねない。

一般的な就業モデルをパッケージ適用するのであれば簡単だが、イレギュラーケースの制度設計になるので、相談される社労士の方も慎重に進めていかなければならないため、相応のスキルと工数が必要になる。

これは確かなことは言えないのだが、一般的な就業規則パッケージをそのまま導入するのなら30-40万円で済むのに対して、「労働者側の裁量で深夜労働もできる勤務体系」を導入しようしたら、就業規則の完成までで数百万円+顧問契約料を割増で契約、作業期間は数か月~半年みたいなことになるのではないかと思う。これに更に労務管理部門での社内運用体制の構築が必要になる。

追記:制度の設計・運用を外部委託する部分だけの費用を書いたが、これに社内担当者の人件費もかかる。制度設計は総務・法務部門に丸投げできないので、直接部門の人間もかなり時間を取られる。

考えれば考えるほど「業務をパッケージの方に合わせろよ」と言いたくなる。

労務管理・コミュニケーションコストの増大

就業規則・システムの山を越えたとして、まだ考えないといけないことはある。

「労働者側の裁量で深夜労働もできる勤務体系」を導入と、勤務時間が人によってバラバラになるので、コミュニケーションが取りづらくなる。それこそ、昼勤・夜勤みたいな社内で2交代みたいな状態になる可能性もある。

深夜労働者に対して、管理監督者が同一時間帯に管理監督を行う義務はない(はず)なのだが、健康管理等の面で常に野放し状態にするという訳にもいかないので、毎日ではないせよ監督が必要になる。

コミュニケーションコストが増大した分だけ、組織としての生産性は下がる。これが解決していれば、リモートワークとかはもっと普及している。人材採用の幅を広げることと、生産性の低下・コスト増加のバランスが取れるかは、組織によってくると思う。

ここであえて書くが「朝に弱いから勤務時間を深夜でもOKにしてほしい」という人間がいる一方で「家族がいるから深夜勤務とかありえない」というような事情を持つ人間もいることは、念頭に置かねばならない。後者の人間が管理監督者で、前者の人間の労務管理・コミュニケーションのために深夜労働を行わざるを得ないという不幸が出ないようにしなくてはならない。管理監督者の方も前者タイプならいいんですが。

追記:ここはコミュニケーションがほぼ不要な業態なら大した懸念点にならない可能性はある。ただ、完全にコミュニケーション不要の仕事というのも考えられないし、労務管理からは逃げられないので、例えば週1回は決まった時間に打ち合わせを行うとかの制約は必要になってくる。

まとめ

「労働者側の裁量で深夜労働もできる勤務体系」について、

  • 社会システムで想定されていないイレギュラーな働き方であって、労働法制で規制すらされている
  • イレギュラーを通すには様々なコストがかかるし、会社全体の生産性が低下する可能性もある
  • コストを払ってでも得られるメリットがあるのか

という話で、「朝に弱いからやってほしい」というレベルで導入するは無理。

そもそも昼夜逆転は人体には悪いとされていて、健康の範疇の人間であれば朝に弱いといっても昼までには起きれるでしょ(起きられない人は何らかの病名が付くはずで、まずは通院すべき…)というところがあり、落としどころとしてはコアタイムの緩いフレックスタイムだよね、となるのが自然な流れだと思う。

とはいえ、深夜勤務完全OKという会社も実在しているので、そういう会社はこの記事で書いてきた山を全て超えてきたんでしょう(グレーなまま労使間の紳士協定でやってる可能性もある)。

Azure FunctionsでNode.jsのバージョンを変更する

Azure Functions v2 runtimeではNode.jsを任意バージョンに切り替えられるようになった。前から試そうと思ってたのと、いつまでたってもドキュメントに反映されないのと両方あるので、とりあえず手順を書いておく。

やること自体は、ここに書いてある通り。 github.com

Function App の設定 を開いて、ランタイムバージョンを v2 に切り替える。(結構時間がかかる) f:id:terurou:20171223195704p:plain

次に アプリケーション設定 を開いて、 WEBSITE_DEFAULT_NODE_VERSION に使いたいNode.jsのバージョンを指定して、保存する。f:id:terurou:20171223195912p:plain

これだけで完了。念のため プラットフォーム機能 から コンソール を開いて、正しく設定されているかを確認。

> node -v

f:id:terurou:20171223200033p:plain

Haxe/JSでMainなし(EntryPointなし)のプロジェクトを作る

2回ぐらいやり方を忘れてググるみたいな感じになっているので、いい加減メモっておく。

code.haxe.org

要は、通常のHaxeプロジェクトでは、.hxml を

-cp src
-main Main
-js bin/main.js

みたいに設定するところを、

-cp src
Main
-js bin/main.js

のように、-main を削った書き方にすればよい。

dynabook V82/Dを買って、Windows 10 1709をクリーンインストール

dynabook V82/Dを買いました。

元々はLet'snote RZ-5を使っていたんですが、10インチサイズの筐体が仇になり、キーボードが小さくてキー入力ミス率が上がっていたり、長時間キー打つのは疲れたり、打ち合わせ相手にディスプレイを見せるときに小さすぎて見えづらいと言われたり、割と散々な感じだったので、乗り換え先を探していて、候補に残った感じです。

  • いちおう開発もできるスペック
  • クラムシェル型
    • タイプカバーというかキックスタンドなタイプだと、新幹線で使いづらい
  • タブレットモードになる
    • 打ち合わせ相手に見せるときに便利
  • ペン入力ができる、しかもワコム
    • デザイナーと打ち合わせする際に、PDFに書き込みとかを割とやる
    • ペンは標準付属、某Surfaceみたいな別売りとは違う
    • 実際に書いてみたけど、確かにこだわっているだけあって、書きやすい
  • 本体1100g + ACアダプター260g + USB-Cアダプター100gぐらいで、ぎりぎり持ち運びができる許容範囲内
    • 買ってから気が付いたけど、筐体にHDMI/VGA出力がなくて、本体充電と共用のUSB-C/Thunderboltポート1つしか付いてない(MacBookと同じ)ので、プロジェクターに接続するような場合は、USB-C アダプターが必要
    • 専用のUSB-Cアダプターは標準で付属してたのと、実測で98gだったので、まぁ許容範囲内…
    • ACアダプタは260gぐらいあるけど、コンセントとつなぐ側のメガネケーブルが50g強あったので、L字プラグとかに変えると軽くなる
      • ACアダプタはUSB-C PD 45Wなので、純正ではない軽いやつに変更もできるはず
    • バッテリー公称17時間あるので、ケースが合えば本体のみの持ち運びも十分考えられる
  • 割と安い
    • キャンペーン中だったっぽいけど、税込17万円強
    • 同じぐらいのスペックで某Surfaceとかと比べると…

富士通のLIFEBOOK WU2/B1 or WU2/B3ともかなり迷ったんですが、軽さよりもペン入力を取ってdynabook V82/Dにしました。

で、この辺りはマイナスポイントですが、特に国内メーカーPCだと余計なソフトウェアが色々入っているので、買って早々にWindowsクリーンインストールしました。東芝PCのクセを把握せずに作業していたので、1回インストールに失敗して、リカバリーしたりしています…。

  1. TOSHIBA Recovery Media CreatorでUSBリカバリーメディアを作成する
  2. オリジナルドライバー、ソフトウェアをバックアップする
    • C:\TOSAPINS フォルダ全て
    • C:\Program Files\TOSHIBA\TOSAPINS フォルダ全て
  3. Windowsクリーンインストール
  4. バックアップしておいたオリジナルドライバー群を、元と同じパスに配置
  5. C:\TOSAPINS\HTML\SETUP\index_top.html を起動して、必要最低限のドライバーおよびソフトのみをインストール
    • 「ドライバ」タブに表示されているドライバー類全て
    • 「ユーティリティ」タブの以下
      • Intel Chipset SW Installation Utility(チップセットドライバー)
      • TOSHIBA System Settings
      • TOSHIBA eco Utility(いわゆるいたわり充電の設定に必須)
      • 任意:DTS Studio Sound(サウンド設定)
      • 任意:TOSHIBA Service Station(アップデート通知、ハードウェアチェック)
    • その他は必要ならインストール
  6. 4.で展開したオリジナルドライバー群のファイルを削除(当然残しておいても構わない)

これで必要最低限の環境になったはずですが、しばらく様子見を見します。