WindowsにMSYSのrsyncとsshをインストール

WindowsVagrant Rsync Synced Foldersを使いたかったので、MSYSのrsyncsshを入れた。Gowとかで済ませようと思ってたのだけど、rsyncが入ってなかった…。

  1. mingw-get-setupでmingw-getをインストール
    • MinGW Installerが立ち上がってくるが、閉じてOK
  2. cmdで以下のコマンドを実行
    • mingw-get install msys-base msys-openssl msys-openssh msys-rsync
  3. C:\MinGW\msys\1.0\bin にパスを通す

これだけやればRsync Synced Foldersが使えるようになる。

GitHubに置いた就業規則に対して、GitHub対応社労士さんからツッコミが来た

無料相談状態なので、ありがたい話ですね。

GitHub対応の社労士として就業規則にプルリクしてみた - Uchibe.net

レス的なところ。

例えば、客先に常駐した時の労働時間に関する規定ですが、客先に常駐という状態をもって、事業場外みなし労働とする事は出来ない可能性があります。さらに、常駐先の時間が短いケースでは、働かなかったとされる時間については、どのような取り扱いになるのでしょうか。ナドナド………。(この問題だけでもそれなりのボリュームになりますので割愛。)

SI業界でありがちな、「請負なんだけど客先の勤務時間・休憩時間に従わざるを得ないので、自社の勤務時間と適合しない」的な、いやそれ実態が派遣じゃないですか、というのを想定して書いてます。相談していた社労士さんにも「これでいいの?」と確認されたポイントではあるんですが、SI業界の構造はそうなっちゃっているという説明をしたところ、「まぁそれなら…」という回答を貰っているので、あの書き方になっています。

とはいえ、常駐イコール上記のようなケースになるとは限らないのは事実なので、追記した方が良さそうですね。

もう一つだけ挙げますと、年次有給休暇の比例付与もつけたしておいた方が良さそうです。所定休日に祝祭日が含まれていたりするので、パートさんであっても週の所定日数が現実的にはマチマチになることが予想されます。ですので、年間の所定も記載しておいた方が良いでしょう。(書いていて損はない。)

 もちろん、実際に週でビシッと所定日数が決まるのであれば、不要です。ですので、Pull Requestするには至らないのかなと思います。

これも微妙なところなのですが、弊社の状況的に、現在~近い将来でアルバイト・パートさんを雇う予定がない事と、やはり無料相談だけでは限界があるので最低限のことだけ書いて先送り状態になっているというのが実態です。相談していた社労士さんにも、実際にパートさんを雇用することになりそうなら、その前に直した方が良いとはアドバイスされています。

ちなみに現状は、パートさんよりも短時間正社員に対応できる規則にする作業を優先している感じです。

GitHubに会社の就業規則を公開した

これです。

ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。

なんで就業規則を公開したのか

  • マトモな規則が作ってあれば公開しても特にデメリットはない
    • むしろマトモな会社アピールができてよい
      • 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている
  • 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり)
    • いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず
      • これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた
  • GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然

零細企業就業規則って要らないんじゃないの?

従業員が10人未満であれば、労基署への提出義務はありません。ただ、それが就業規則は不要と結びつくかと言えば微妙なところで、仮に明文化なされていなくても、「給与額はどう決めるの?」「残業代は?」「有給日数は何日?」のような取り決めは必要です。もし、ルールが明文化されていない場合は、従業員側は雇用者が毎回違う事を言っていたとしても従わざるを得ない状況になる可能性があります。

無用な雇用トラブルを避け、かつ、従業員のことを考えるのであれば、ルールの明文化は必須で、それが正に就業規則そのものになります。

就業規則を自分で作ること

コスト感

結果から言うと、無料(自分の工数だけ)で就業規則を策定することは可能です。サンプルを元に自分で規則を執筆して、地方公共団体の無償中小企業支援を利用して規則をチェックしてもらうという形式であれば、委託費はかかりません。

うちはこの方法で就業規則を作成しましたが、費用をケチった分の労力に見合うかというと、かなり微妙なところです。

就業規則の作成を社労士事務所に委託すると、ひな形に穴埋めするだけでも30万円程度が相場です。更に会社の実態に合わせていったり、理想とする制度の設計までをやっていくと、最悪ケースで100万円ぐらいはかかってきます。

うちの場合、制度設計をがっつりやった面はありますが、完成まで9ヵ月間、実働工数で2人月分ぐらいはかかっています。売上的には何も生まない2人月分の作業が100万円程度で済むのであれば、どっちが良いのかは微妙なところかと思います。

仮にテンプレートやサンプルに穴埋めするだけと仮定しても、実働で2人週とかはかかると思います。これが30万円で済むと考えると、やはり微妙なところになるかと思います。

テンプレートを修正するだけでも、そんなに時間がかかるの?

うちも当初は「世の中にあるテンプレートを修正するだけならすぐに終わるでしょ」という目論見で作業していたのですが、結果は前述の通りです。

まず前提として、就業規則を作ったら、必ず社労士にチェックしてもらう必要があります。これは絶対です。

理由としては、条文を自然言語で書くので当然解釈のゆれが発生しうる内容を書いてしまう場合もありますし、そもそも条項の考慮漏れ(仕様バグ・脆弱性)が発生する可能性があります。もし、これを放置したまま就業規則を施行すると、無限有給・青天井給与みたいな事が可能になります。

例えば、

  • 無断欠勤が解雇事由に相当する旨の記載がない
  • 欠勤時の賃金減額の条項が甘く、1か月丸々出勤していなくても交通費は減額されないことになっている

みたいな組み合わせで、無断欠勤していても解雇することができず、交通費をずっと払い続けざるをえない状況が発生し得ます。仮に裁判に持ち込んでも和解が落としどころで、ある程度の金額を払わざるを得なくなる可能性があるでしょう。

追記:その他、ありがちな例として「無限祝い金」があります。結婚すると祝い金が出る=離婚+結婚を繰り返すと、無限に祝い金が引き出せます。対処法としては、上限回数を設けることになります。

更に厄介なことに、労働者保護の観点から、就業規則は不利益変更(従業員の不利益に繋がる条項改定)は、従業員の同意がないと、無効と判定されます。つまり、就業規則脆弱性を抱えていて、悪意のある従業員が存在したら、零細会社であれば普通に破滅です。

2つ目の理由としては、テンプレート自体にも問題があります。

就業規則のテンプレートはググれば多々出てきます。厚労省地方公共団体が配布しているものや、社労士事務所のWebサイトで公開されているものもあります。Web以外には書籍の付録としても配布されています。これらが軒並みそのまま使い物にはなりません。

厚労省地方公共団体が配布しているものは、あくまでも従業員に不利益が生じないようには考えられています。一方で、雇用者側の視点は欠けた記述となっているため、考慮漏れが多々存在します。

Webや書籍の情報についても、最新の法運用Validな記述になっているか怪しい面があります。そもそも彼らの飯の種でもあるため、あえて記述が甘くなっている可能性も否定できません。

そのため、テンプレートを元に記述した場合であっても必ず社労士チェックが必要ですし、チェックしてもらった結果、ダメなポイントが大量出てきます。指摘してもらったところは当然手直しが必要になります。

うちの場合、2時間の無料相談×4回でやっと「内容的にはだいたいOKだけど、TYPOとかはありますね」というところまで持って行けましたが、初回はほんとに死ぬかと思いました。

就業規則を自分で作ったメリット

なんだかんだ言っても、零細企業で30万円だとか100万円だとか払うのは辛いので、その費用が浮くのは大きいです。あと、自分で書かざるを得ない以上、規則の内容を完全に把握することになるので、将来的に規則を改定していく際に雇用側の意向を完全に反映させた改定がやりやすく、委託するにしても「丸投げしか選択肢がない」という状態は避けられます。

このあたりは、外注ではなく自前でシステム作ると~みたいな話にまんま通じる話です。

就業規則を作成する上で知ったこと

就業規則を一度作ってから、それを厚労省の意向に合わせて改定をして人を雇うなりすると、補助金が貰えます。

正規雇用等転換コース
学生アルバイト(有期契約)を正社員として採用したケースでも補助金が貰える
短時間正社員
短時間正社員(フルタイム勤務ではない正社員)を新規採用or正社員から転換すると補助金が貰える

というのがIT系の会社では使いやすいところではないかと思います。

また、就業規則と関係はないのですが、人を新たに雇い入れると、法人税の免除が受けられることも知りました。

まとめ

スタートアップで一攫千金だ!!!!みたいな感じではなくて、割と手堅い路線でやっていく会社なら就業規則を作るべきだし、やましいところがなければ公開すればよいと思います。あと、せっかく公開したので、フォークするなり参考にするなりして頂ければ幸いな感じです。

就業規則のライセンスは忘れてたので、近日中に設定しておきます…。

追記:ライセンスの件はGitHubにIssueを立てたので、そちらをご覧ください。
ライセンスの明示 · Issue #4 · DenkiYagi/EmployeeHandbook · GitHub

追記2:GitHub就業規則を置いたのはファーストケースかもしれませんが、就業規則をWebに公開すること自体は以前から普通にあります。"就業規則 株式会社"等でググると採用ページに併記する形になっているものが見つかりますし、地方自治体・公立大学等の規則も公開されています。

JsViewsとTypeahead.jsを併用するとバインディングが期待通りに動かない

おそらくJsViewsに限った話ではなくて、双方向バインディングをやってくれるテンプレートエンジンなりフレームワーク全般にかかるであろう事案。

問題点

以下のイベント発火時に双方向バインディング(View -> Model)が動作しない。

  • typeahead:autocompleted
  • typeahead:selected

原因

上記イベントが発生する場合にchangeイベントが発火されないため、バインディングが動作しない。

対策

無理やりchangeイベントを発火する。

$(".suggest").on("typeahead:autocompleted", function (e) {
    $(e.target).trigger("change");
});
$(".suggest").on("typeahead:selected", function (e) {
    $(e.target).trigger("change");
});

厳密にやると、typeaheadのイベントを拾う→ユーザキー操作なしでblurが発生するタイミングでchangeを発火すべきではあるのだけど、バインディングの問題に対処するのであれば、これで十分。

JsViews(JsRender)の{{for}}タグの#data, #index

ちゃんとドキュメントに書かれてないのだけど、{{for}}タグでは、#data(カレント行)と#index(インデックス)を参照できる。

<ul>
  {{for list}}
    <li>{{>#index}} - {{>#data}}</li>
  {{/for}}
</ul>

追記:他にも #parent がある。

ハイパフォーマンス ブラウザネットワーキング、読むべき本だった

Twitterで「なんかやばそうな本が出るぞ!!!」みたいな事を言っていたら、それが偶然拾われて、献本して頂く流れになりました。オライリーさん、ありがとうございます。

とりあえずざっと全体を流し読みした(と言っても3時間弱は読んだ)ので、書評っぽいことを書いておく。

読むべき人間

以下に該当する人間に対しては必読に値する本だと思う。

  • HTTPを扱うアプリケーション*1アーキテクチャを設計する人間
  • Webサーバ等のHTTPに関連するインフラを担当する人間
  • HTTP 2.0、WebSocket、Server-Sent Events、WebRTCのプロトコルについて日本語の文書が読みたい人間

普通に技術的な読み物としても面白い内容なので、Webの世界に近いエンジニアからネットワークを扱う組み込みエンジニアまで、軽く読んでおいて損はないと思う。ただし、読むにあたり最低限のネットワークの知識(OSI参照モデルとかそのあたり)は要求されるので、そのあたりの知識がない人間には読むのはつらいかなぁという感じがする。

個人的には、読書会をやると楽しそうな本だと思った。

内容について

とりあえず目次を。詳細な目次については オライリーのページを参照して欲しいのだが、この内容で380ページである。

I部 ネットワークの基礎
 1章 レイテンシ・帯域幅入門
 2章 TCPの構成要素
 3章 UDPの構成要素
 4章 TLS

II部 ワイヤレスネットワークのパフォーマンス
 5章 ワイヤレスネットワーク入門
 6章 WiFi
 7章 モバイルネットワーク
 8章 モバイルネットワークの最適化

III部 HTTP
 9章 HTTPの歴史
 10章 Webパフォーマンス入門
 11章 HTTP 1.x
 12章 HTTP 2.0
 13章 アプリケーション配信最適化

IV部 ブラウザAPIプロトコル
 14章 ブラウザネットワーク入門
 15章 XMLHttpRequest
 16章 Server-Sent Events
 17章 WebSocket
 18章 WebRTC

読む前は「えっ、こんなに広範なトピックを扱って、なんでこんな薄いの…?」と多少の心配はあった。しかし、実際に読んでみると「ネットワークのプロトコル及びパフォーマンスのみに話題を絞る」「チューニング方法については一般論のみ(具体的なチューニングツールの紹介はない)」という内容になっているため、非常にわかりやすく、かつシンプルにまとまったのだなぁと感じた。

全体の流れ

まず、冒頭で「スピードこそユーザエクスペリエンス!!」「Webのネットワークにおけるスピードとはレイテンシの改善である!!!(現在の数Mbps程度の回線速度が一般化している状況下において)」という旨の内容が書かれており、クーガーさんの事が思い出され本書の取り扱う問題点の明確化を行っている。その上で以下のような順序で解説が行われている。

  1. 物理層からトランスポート層TCP, UDP)+TLSまでのプロトコル及び「何で遅くなるの」の解説
  2. ワイヤレス/モバイルネットワーク(WiFi, 3G, 4G等)の解説から「通信遅いし通信するとバッテリーも浪費するがどうするか?」まで
  3. HTTP 1.xのプロトコル解説及びチューニングポイント
  4. HTTP 2.0のプロトコル解説及びHTTP1.x時代とのチューニングポイントの差異
  5. XMLHttpRequest、Server-Sent Service、WebSocket、WebRTCのプロトコル解説および使い分け
内容についての雑感

低レイヤーの話については「なんとなく内容は認識しているが、いきなり説明しろと言われても説明できない」ものが簡潔にまとめられており、他人に説明するときに便利だなーと思った。

また、Server-Sent ServiceプロトコルとWebRTCプロトコルの解説を初めて見たので、勉強になった。そもそもServer-Sent Serviceについては、本書で初めて知ったので、それだけでも結構な収穫だったと思う。

まとめ

良書っぽいので買いましょう。

*1:Webブラウザ、デスクトップ、モバイル等、全て該当

abstractを使ってDOMとjQueryを透過的に扱う

abstractを使うと、「C言語のunion」みたいなのを型安全かつ便利に書ける。引数をabstractで受けると非常に便利。

例として、js.html.Elementとjs.JQueryを透過的に扱ってみる。

abstract Html(Element) {
    inline function new(x: Element) {
        this = x;
    }

    @:from public static inline function fromElement(x: Element): Html {
        return new Html(x);
    }

    @:to public inline function toElement(): Element {
        return this;
    }

    @:from public static inline function fromJQuery(x: JQuery): Html {
        return new Html(x[0]);
    }

    @:to public inline function toJQuery(): JQuery {
        return new JQuery(this);
    }
}
function appendToBody(x: Html) {
    Browser.document.body.appendChild(x); //Html -> Element に暗黙の型変換
}

var div = new JQuery("<div></div>");
appendToBody(div); //JQuery -> Html に暗黙の型変換

ここでは "abstract Html(Element)" とElement型を主にしてみたけど、JQuery型を主にした方が良いかもって気もするし、NodeListも扱えた方が…とか色々あるのだけど、このあたりは好みですね。