MSYS2とsbtの設定

sbt(Windows MSI版)とMSYS2の組み合わせで、JVMオプションを指定したい場合、.bashrcで以下のように指定するのが無難っぽい。

alias sbt="JAVA_OPTS='-Xms512M -Xmx1G -XX:ReservedCodeCacheSize=256M -Dinput.encoding=Cp1252' sbt"

${SBT_HOME}bin/sbt のソースを読む限り、conf/sbtconfig.txtは使われていないし、SBT_OPTSでの指定だと適用順の問題でメモリ設定が上書きされてしまうので、この設定に至った。これなら、カレントディレクトリに.sbtoptsファイルが置いてあれば、そちらの設定も優先される。

-Dinput.encoding=Cp1252は、始める sbt — 手動インストールを参照。

また、sbtの起動オプションに -Dfile.encoding=UTF-8指定しないのがポイント。これを指定してしまうと、コンソールで文字化けしてしまうので、以下のようにbuild.sbtでエンコーディングを指定するほうがよさそう。

javacOptions ++= Seq("-source", "1.8", "-target", "1.8", "-encoding", "UTF-8"),
scalacOptions ++= Seq("-encoding", "UTF-8")

安定寄りの零細IT会社を作って1年ちょいで得た知見

デンキヤギ株式会社という名のITの会社を作ってから1年強になった。

自社プロダクトを事業の中心に据えたいとは考えているが、まずは安定経営のため受託開発を優先してきたことにより得た知見をまとめておく。ちらほらと「会社を作ってどうよ」みたいな事は聞かれた際に、まともに答えてきていなかったという自覚があるので、その回答でもある。

設立以前から現在までのざっくりの状況

  • 中小SIerでサラリーマンエンジニア歴10年(うち5年ぐらいはR&D部門所属)
    • 名古屋ローカルではあるが、コミュニティ活動はガッツリやってきた方
  • まずは1人だけの株式会社を設立
  • 設立から1年ちょいの間に社員を2人採用
  • 現時点では受託開発中心で、安定に寄せた経営方針
  • 業績はボチボチ、倒産の危機とかはない程度には良い

とりあえず受託で食っていくために必要なもの

  • カネ
  • コネ
  • 相場・市況感
  • ちゃんと仕事を回してちゃんと納品する能力

さえあれば、受託中心の零細会社程度ならどうにかなる。

カネ

カネが多ければ多いほど選択肢が広がり精神的余裕も出るが、逆に少なくて良いことは一つもない。

開業するための資金(開業資金≒資本金、手元に残す資金、退職収入などを含めたもの)として、

  • 法人登記(株式会社だと最低21万円)
  • 初期設備費(PC、ソフトなど)
  • 最低6か月分の生活費および運転資金(給与、社会保険料、オフィス賃料、光熱費、通信費、インフラ費など)
  • その他雑費

を用意しておく必要がある。ぶっちゃけ「最低6か月分の生活費および運転資金」が一番重要である。

会社を作るといっても、「登記の準備~実営業開始まで」だけで2か月はかかるし、営業開始直後に「月末締め、支払いサイト30日」という理想に近い仕事を受注できたとしても着手から入金まで2か月かかる。よって、設立準備から理想的な形で進んだとしても、収入を得られるまで4か月はかかる。バッファを積むと6か月でギリギリということになる。

社会保険料についてもサラリーマンをしていると実感が伴わないのだが、健康保険と厚生年金の月負担額が、年収400万円で7-9万円程度、年収500万で9-11万円程度になる。サラリーマンの間は会社に50%を負担してもらえていたが、経営者になってしまったら全額を賄わなければならない。

開業資金の具体的な金額については、事業計画、開業スケジュール、配偶者・子供の有無などにもよるところがあるので一概には言えないし、適当な起業本を数冊読んで自分で考えた方が良いとは思うが、

  • 実家なり配偶者に養ってもらえるなら、100-150万円
  • 独り身or共働き世帯なら、200-300万円
  • 配偶者が専業主夫/婦なら、300-400万円

ぐらいが最低ラインではないかと思う。あくまで最低ラインなので、これの1.5-2倍ぐらいは用意できないと余裕はないとは思う。

コネ

いざ開業しても、コネ(営業チャネル)がないと事業が成り立たない。都市圏であればコネがなくても仕事が取れない訳ではないのだが、実績・信用がない以上、まともな単価・内容の仕事を取るのは不可能に近い。

月並みな話にはなるが、

  • 前職に頭を下げる
  • 前職で関わった顧客に営業をかける
  • 勉強会等で知り合った会社・人に営業をかけたり、同業他社の営業を紹介してもらう
  • まったく面識のない会社でも、職務経歴書+技術ブログやGitHubなどのPR情報をベースに問い合わせ窓口からアポ取り

ような事ができれば、どうにかなる気はする。「コネがなければコネを作る」ぐらいの事ができないと非常につらいし、それは無理だと思うような人は起業という選択はすべきではない。

あと蛇足だとは思うが、営業をかけるにしても、フリーランスに近い人間とでも取引してくれるような会社でなければ意味はないということは補足しておく。大企業の人間と付き合っても直接的な利益は生まないという事だ。まぁ、そこまで考えてるとだるいけど。

相場・市況感

いざ仕事が取れそうであっても、単価の安い仕事を請けてしまうと、ワーキングプアの世界へようこそになってしまう。相場・市況感を抑えておく必要がある。

そんなに難しい話ではなく、

  • 仕事をする地域・分野での底辺レベルの単価を抑えておく
  • 現在の市場が好況/不況なのか、人手は足りているか否か

さえ押さえておけば、あとは底辺にならないような仕事を取るだけである。

2014年末時点の底辺単価については、

  • 東京 … 54万円/月(時間単価3000円×180H)
  • 名古屋・大阪 … 48万円/月(時間単価3000円×160H)

といった感じだと私は認識している。これを下回るものも当然あるが、底辺の背比べをしても意味はないと思うし、今の市況なら実績ゼロに近くてもこの単価は取れるとは思う。

そして重要な事としては、底辺単価層には「if文が怪しい」レベルの人間が相当数おり、発注側もそれを認識したうえで発注を行っているという事実がある。底辺によればよるほどマトモな人間の割合は下がるし、マトモかつ実績のある人間ほど人手不足である。

これを前提として、ふっかけるぐらいの感覚で単価交渉を行っていかなければならない。実績ゼロであっても「基本単価は○○万円ですが、最初の1か月はディスカウントします。もしダメなら契約解除で構いません。」ぐらいの事は言う必要がある。底辺人材が欲しい発注者であれば契約には至らないだろうし、変な会社除けになると思う。

あと、単価が安い仕事ではそれ相応の内容の仕事しか担当できず、いくら積み重ねたところで実績にもならないという事も認識しておかなければならない。

ちゃんと仕事を回してちゃんと納品する能力

ごく当たり前の話だが、これが出来る人間はそれほど多い訳ではない。ホウレンソウは当然として、仕様調整・進捗管理・課題管理などのいわゆるSE能力とかディレクション能力が必須になる。

プロとしてプロジェクト・チーム開発を円滑に回せないようでは、いくら技術力が高くてもカネを稼ぐことは難しい。クオリティを上げることは重要だが、ビジネスである以上は「作業量・クオリティ・スケジュール」と「対価」が見合っていないようでは破滅しかない。

そんなに難しい話でもなくて、1-3人のチームで1-2か月程度のプロジェクトが滞りなく回せるようであれば、最低限の水準には達しているとは思う。あとは、その上で割り切りであったり、交渉であったりが出来ればよい。逆にこれぐらいのプロジェクト規模でも炎上を繰り返してしまうような人は、サラリーマンのままでいた方が幸せではないかと思う。

その他雑多な事項

独立すると雑務が増える

「独立すると雑務が増える」とはよく言われるが、確かに増える。ただ、雑務とは言っても、経理・社外営業・営業方針の検討といった経営上重要なものから、郵便物を出しに行ったり、掃除したりなどの「誰でもできるけど人が居ないから自分でやらざるを得ない」タスクまで様々ある。

また、会社を設立してからしばらくの間は全ての物事がルーチン化していないので、例えば経費精算するにも「経理のために何を残さないとダメなんだだっけ」「申請書テンプレWordファイルをダウンロードしてくるか…」みたいなことをイチイチ考えなければならず、非常に時間がかかる。うちも設立してから1年が経過したので、だいぶマシにはなってきたが、未だにルーチン化できていないことは多々ある。

土日のどちらかは事務処理なり社内環境整備の日というぐらいの覚悟はしておいた方が良いし、それぐらいでやらないと全然間に合わない。ここは事務員さんを雇うなどしたい領域なのだが、弊社ではまだ踏み込めていない。

社員を雇うか否か

社員を雇うとそれだけで緊張感が生じるので、よく働くようになると思う。マッタリしたいという感じなら、フリーランスの方が楽だと思うし、そもそもサラリーマンのままでええやん感がある。

また、社員を雇うと「雇用責任ガー」とはよく言われるのだけど、どうせ本当にダメになった場合は退職給与とか払いようがないし、社会保険雇用保険に加入させるぐらいしかやれることないよね、と割り切ってしまっている。だって無理なものは無理だし。ただ、弊社の場合は、雇用保険的な位置づけで中小企業退職金共済を掛けることで、企業体力の範囲でできることはやっているつもりではある。

また、一旦人を雇うと解雇しづらいというのは事実ではあるのだけど、零細企業の場合は「給与に見合わない働きしかできない=雇い続けると収益に大きく影響が生じる」「配置転換しようにもそんなポストはない」ということから、十分に解雇要件は満たせてしまうため、正式な解雇手続きを行えば解雇できると認識している。

就業規則

GitHubに会社の就業規則を公開した - terurouメモにも書いた通り、弊社は就業規則GitHubに公開している。就業規則を作るのは非常に労力がかかるので万人にはおすすめできないのだが、社員を雇うのであれば賃金と有給の取り決めはキッチリ決めておいた方が良いと思う。

私の場合は、

  • 設立当初から社員を増やしたいという意図があった
  • 自分がサラリーマンなら就業規則のない会社は嫌だ
  • 受託の合間に自社プロダクト開発をしていくためには早いうちに片付けておくべきだろう

という考えがあったので優先した面がある。

就業規則を作ったことによるメリットは非常に大きかったのだが、反面、期間9か月・実働工数2人月もかかってしまい、自社プロダクト開発の着手が遅延した一因にもなってしまったので、人によって判断が割れると思う。

私は会社運営上のリスクを潰せた・顕在化させることが出来たことから、メリットの方が勝っていると思っている。

創業補助金

創業補助金をざっくり説明すると、300万円の経費(制限が多い)のうち200万円を国からキャッシュバックしてもらえる制度である。弊社もこれに採択されていて、補助金がもらえることがほぼ確定しているのだが、これについての詳細は実際に入金されてから別のエントリーで書きたい。

結論だけ書くと、事務処理なり事務局の意向に合わせた申請書作文にそれほど苦を感じない人であれば、選択肢として入れるのはありだし、そうではないのであれば近寄るべきではない。

役員報酬額

出来るだけ高く設定すべきである。少なくとも、理想ケースで仕事が取れた場合に会社収益がトントンか少し赤字になるぐらいの額には設定すべきである。変にリスクを織り込んで少なめの額に設定すべきではない。

会社というのは赤字になっても即座に倒産する訳ではなくて、運転資金が尽きたときに倒産するものである。仮に売上が足りず、そのまま役員報酬を支払ってしまうと会社の運転資金が尽きてしまうという状況が発生した場合、役員から会社に対して無利息貸付けを行う(=役員報酬を支払わず経理上は貸付扱いにする)ことで会社は潰れない。

会社は黒字になると法人税を支払う義務が生じるが、赤字なら最低限の税で済むし、赤字は翌年以降に持ち越すことができるので、売上が想定外に増えても過去の赤字で相殺することができる。赤字は一番の節税だと思う。

創業してから1-2年目までは赤字、3年目ぐらいで収支トントン、4年目ぐらいから単年度黒字ぐらいなら、世間では十分に普通の範疇だとみなしてもらえるので、過度に赤字を恐れることはないと思う。

ちなみに私の場合は、ビビッて初年度の役員報酬を低くし過ぎたため、この点はかなり失敗したなとは思っている。

まとめ

  • 起業するにはカネがないと無理だし、常にカネの事を考え続けなければならない
  • 会社を作れば権限は増えるが、その分の責任というか雑務が増える
  • 最初の1年目ぐらいは、雑務対応のせいでやりたいことに振り向ける時間はあんまりない

会社を作ることは手段でしかなくて、目的を果たすために他の手段が選択できるのあれば、わざわざ選択する理由はない。

Haxe/JavaScriptでSource Mapを出力するための設定

ざっくりこんな感じです。

-cp src
-main Main
-js bin/main.js
-debug
-D source-map-content

"-debug" オプションを付けると、Source Mapが生成されるのは皆さんご存知だとは思いますが、これだけだと、HTTPサーバに配置した場合にSource Mapが読み込めません。これは、Haxeの生成するSource Mapでは、sourceRoot が file:// になってしまっているせいです。

で、ちょっと楽ができないものか調べていたら、3.1.0から(?)、"-D source-map-content"オプションが増えていたようです。これを有効にすると、sourcesContentにソースコードが埋め込まれるようになる=そのままHTTPサーバに配置してもSource Mapが使えるようになります。

changesにも書かれてないし、普通は気が付けないですよねぇ。

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を発火すべきではあるのだけど、バインディングの問題に対処するのであれば、これで十分。