PowerShellの色設定
VS Code標準の統合シェルがPowerShellなのだけど、ハイフン引数の色の視認性が悪すぎるので設定した。しばらく設定方法がわからなかったのだけど、PowerShell側の設定を変更して解決した。
プロファイルの作成
New-Item -Path $Profile -ItemType file -force
プロファイルのパスを確認
$profile
プロファイルをエディタで開いて、人間の目では読めないような色の設定を変更
Set-PSReadLineOption -Colors @{ "Parameter" = [ConsoleColor]::Cyan "Operator" = [ConsoleColor]::Gray }
マニュアルを見る限り、RGB値の設定も可能なようだ。
Haxe 4.0 JavaScriptターゲットでの変更点
はてなで書くのがしんどかったので、gistで書きました。
GitHub-readyな社労士 @Takashi_U に就業規則の改定を依頼した
デンキヤギという会社では、就業規則をGitHubで公開・管理しています。
就業規則というものは一回作れば終わりというものではなく、法改正や、運用後に気が付いた改善・考慮漏れに対応して、都度改定していく必要があります。ただし、改定するにも労働関連法やガイドライン等を逸脱しないようにする必要があるため、社労士のチェックが必要不可欠となります。
就業規則の初版を作成した際の流れは GitHubに会社の就業規則を公開した - terurouメモ でも書いていますが、名古屋市の中小企業向けの専門家派遣（同様の仕組みで中小企業庁 ミラサポにも専門家派遣がある）を使って作成しました。この時は、
というフローで回していて、正直かなりの苦行でした。
このフローを改定の度に回していたら消耗し続ける未来しかありません。GitHubで公開している以上はGitHub上で改定作業を行いたいし、打合せもオンラインで全て済ませたいというのは至極当然の発想となります。幸いにもGitHubに対応できる社労士 (@Takashi_U) の存在に心当たりがあり、就業規則も改定したい内容がたまってきていたので、改定作業を依頼してみることにしました。
蛇足ですが、なんで事前に認識していたかというと、2014年にGitHubへ就業規則を公開した時に、Twitterで「この記載で大丈夫？」という旨のDMを送ってきた社労士が @Takashi_U でした。
プロフィール追っていったら、既にGitHubアカウントを持っていたり、Rubyを書いている気配があったりというのが見えてきたので、「オッ、これはヤバい人間だな」と認識した流れになります。Twitterで雑にメンションやDMを飛ばす行為は仕事に繋がりますね。
発注から改定までの大まかな流れ
- Twitterで「就業規則改定したいんだけど」とDMを送る。
- Twiter DM上で、費用について認識合わせと大まかな方針決める。
- 改定作業はGitHubにIssueを立てて、ドラフトをプルリクエストで投げてもらう。メインの議論はGitHub Issue上で行うが、たまにTwitter DMでやり取りしたり、Discordでのボイスチャットも併用する。
- 改定内容が確定したら、施行日を設定して、masterへマージする。
- 全ての作業が完了したら、請求書を送付してもらって支払いをする。
ドラフトがほぼ固まった段階など、都度社内チャットに状況を流して社員にもチェックをしてもらうようにしていました。
就業規則の改定（2018年末） · Issue #23 · DenkiYagi/EmployeeHandbook · GitHub が直近の改定対象となったIssueです。GitHub上でソフトウェア開発するフローとなんら変わりのない使い方をしています。 就業規則がマイナンバー対応になっていない · Issue #17 · DenkiYagi/EmployeeHandbook · GitHub にログ残っているように「Issueの粒度が大きすぎるから分割してくれ」と社労士からツッコまれたりとかもしています。
今回の作業期間は、依頼してから大まかに半年ぐらいかかっていて、施行は2回に分割して出しています。半年かかったのは、こちらが特に急いでいる訳ではなく、あまり催促もしなかったので、結果的にこうなっただけです。最初の打ち合わせ時に期限を明確にしてやれば、もっと短期間でできるのではないかと思います。
まとめ
ITの会社は @Takashi_U に労務関連の仕事をどんどん依頼していきましょう。
顧客企業の求人情報から受託システム開発契約の単価を決める話（フリーランス・零細企業向け）
準委任契約でシステム開発を受託する際の契約単価、どう決めてますか？
相場といわれる額とか、過去の自分の実績額とか、もしくは自分の生活必要な年収からの逆算とか、勘や経験や度胸に近いもので決めてる人が大半なんじゃなかろうかと思います。ただ、それだけだと単価交渉する際に弱いんで、一例としてそれっぽい算出式を書いてみます。
フリーランスや零細企業が、いわゆる事業会社と直接契約するようなケースと考えてもらえばいいです。
算出式
(顧客企業の給与年額 × (1 + 休暇/残業係数 + 福利厚生係数 + 利益/リスク係数) + 受託側の一人当たりの年間経費)
これで年額が出るので、月額単価の場合は 12 で割って、時間単価の場合は 1920 (160h×12）で割ってください。顧客企業側の1日の基準労働時間が8hではなく、7.5hとか6hだったりする場合もあるので、その場合の時間単価の計算は適時修正してください。
なお、この計算式で算出された金額は、消費税は含まない税抜価格です。
顧客企業の給与年額
顧客企業の求人ページや転職者向けの口コミサイト等で、「もし正社員として採用された場合の」給与レンジや平均給与額等を調査します。賞与、住宅手当/家族手当等の各種手当や交通費等も全て含めた額面給与です。
これが一番重要な作業です。エンジニアにカネを払う気がない企業（もしくは単純にカネのない企業）がここから判定できます。カネを払う気がなければ、必然的に社員の給与額も下がり、外部委託業者への支払いも渋くなります。
当然、すべての情報が開示されているわけではないので、あくまで推定になります。雑にやると、求人ページに記載されている想定年収に、交通費等の30-40万円を足した金額で考えればいいかなと思います。
休暇/残業係数
いわゆる有給休暇の分を割増します。顧客企業の正社員には有給休暇があります。仮に有給休暇が20日ある場合は、年間に実際に労働しているのは12か月分ではなく11か月分です。受託側はこれを加味して金額を補正しないと、この分は無償奉仕してるのと同じ状態になります。
有給20日の場合、係数として 9-10% (12÷11－1=9.09%) ぐらいで考えます。
もし、残業（超過労働・深夜労働）が恒常的に発生することが見込まれる場合、正社員であれば割増賃金を払う必要があるため、当然その分を割増します。簡易的に残業割増率を50%として、月に20時間ぐらい発生が見込まれる場合は、6-7% (20÷160×0.5 = 6.25%) ぐらいは更に割増する必要があります。
福利厚生係数
社員を雇う場合、企業側には、法定内福利費（社保＋厚生年金）、法定外福利費（スポーツジム補助とか飲み会補助とか）、採用教育費がかかります。これも当然加味します。
会社経営において、額面給与額の2-3割 が会社負担の福利厚生費の目安額といわれるので、30% を係数として採用します。
この係数はよほど特殊なことをやっている会社でない限りは大して変わりません。無料の社食をやっていたりとかするケースもありますが、社食とかは完全にスケールメリットが効く領域なので、係数が変わるほどの影響はありません。
利益/リスク係数
正社員には解雇規制がありますが、外部委託する場合にはそんな法規制はありません。様々な要因で急な契約解除が出るリスクがあります。このリスク分を割増請求する必要があります。また、フリーランス・法人共に売上が上がれば所得税がかかるし、住民税もかかるので、それも加味して利益を確保する必要があります（ちなみにこの一連の計算をするは消費税は含まないようにしてください）。
ここはかなり幅が出る係数で、長期契約が見込まれる場合は係数を低めにしてもOKで、急に契約解除される可能性が高い場合は係数を高くする必要があります。
私個人の考え方としては、この係数の最低値は 20-25% と考えています。契約解除保証料（正社員に対する解雇補償金）が年額に対して約2.5-3.0か月分に設定していると考えればよいです。リスクが非常に高い場合は 50% ぐらいに設定しても妥当な数値かと思います。
受託側の一人当たりの年間経費
会計でいうところの、一人当たりの器具備品費＋販管費です。この項目は係数ではなく固定額となります。
オフィス賃料や電気代とかの固定費や、PC購入代やGitHub税やAdobe税やVisualStudio税とかも含めて考えます。経理や営業等の実働コストも含めます。フリーランスの場合、決算を自前でやっちゃってる人もいると思いますが、それも金額ベースに落とします。
私の感覚では、フリーランスから零細企業ぐらいだと、80-150万円ぐらいかかっている（年度計画時の予算として計上してる）かなぁという認識です。
試算
- 休暇/残業係数 : 10% （有給20日、稀に残業があるかも）
- 福利厚生係数 : 30%
- 利益/リスク係数 : 25% （急な契約解除が発生する可能性は低め）
- 受託側の一人当たりの年間経費 : 100万円
このようなリスクを低めにした想定で、顧客企業の給与年額を変化させていくと、
- 想定年収 500万円 -> 年商925万円（77.0万円/月）
- 想定年収 600万円 -> 年商1090万円（90.8万円/月）
- 想定年収 700万円 -> 年商1255万円（104.5万円/月）
- 想定年収 800万円 -> 年商1420万円（118.3万円/月）
- 想定年収 900万円 -> 年商1585万円（132.0万円/月）
- 想定年収 1000万円 -> 年商1750万円（145.8万円/月）
- 想定年収 1100万円 -> 年商1915万円（159.5万円/月）
- 想定年収 1200万円 -> 年商2080万円（173.3万円/月）
みたいな感じになります。繰り返しですが、顧客企業側の想定年収は交通費も含んだ額面だということと、年商の方は税別価格なので注意してください。
最近は東京23区内だと月単価の下限値で80万円を超えてきているという相場実態から考えても、こんなもんかなという感じがします。
「自分の給与額面の3倍の売上がないとダメ」みたいなコメントが付くことを想定して予め回答しておくと、広告宣伝費が零細企業とは全然違ったり、研究開発とかのファクターを考慮してなかったりするので、そのあたりは自分の状況合わせて計算式や係数を変えてください。あくまでもこれは、フリーランス・零細企業向けの計算例です。
まとめ
カネのある企業と付き合わないとカネにならんですね。社会は厳しい。
Azure Functions従量課金プランのコールドスタート時間が実用レベルになっていた
最近、サーバーレスでガッツリ開発を行っている取引先（元上司と元同僚が、うちとは別系統で独立した社）から、「Azure Functionsのコールドスタートが速くなった」という情報を聞いたので、試してみた。
計測方法
- Google Chromeの開発者ツールで手動でアクセスし、レスポンスタイムを測定。
- 2018/09/29-30の不定期に実施。Cold Startになるように20分以上測定時間をあける。
- 測定環境
- 愛知県名古屋市内
- いわゆる集合住宅のインターネット回線であまり品質は高くない。たびたびスローダウンする。
- 計測誤差が大きい環境であることは留意が必要。
- Azure Functionsは下記の通りに設定。
- 西日本
- 従量課金
- v2
- JavaScript
- PHP無効化
- FTP無効化
検証時に使ったコード
module.exports = async function (context, req) { context.log('JavaScript HTTP trigger function processed a request.'); context.res = { body: "hello" } };
計測結果
体感的には5-8sec。たまに速かったり遅かったり。ちなみに、コールドスタート完了後は数10～100msec程度でレスポンスが返ってくる。
| Item | Time[sec] |
|---|---|
| Average | 6.80 |
| Median | 6.16 |
| Max | 15.86 |
| Min | 4.25 |
| 80th percentile | 7.324 |
| 85th percentile | 8.755 |
| 90th percentile | 10.852 |
N = 105
まとめ
現時点ではコールドスタートは10秒程度を考えて設計すればよさそう。決して速い訳ではないが「まれに10秒程度待たされることがある」という程度ならば、Web APIとして使うとしても許容範囲内になってきたと思う。今後（半年スパンぐらい？で）、さらに改善されてくるはずなので、今から使い始めてみるのは悪くないタイミングではないかと思う。
Azure Functionsはざっくり、
- Azure App Service（もっと厳密にはWebJobs）上で実行されている
- JavaScriptの場合は、.NET Coreで実装されたサービスプロセスからNode.jsが実行されれる
- ユーザープログラムはコールドスタート時にAzure Filesから読みこむ
という構造になっている。Azure Filesが遅いと言われているのだが、いわゆるBundleを行って1ファイルにまとめたJavaScriptコードであれば、多少ファイルサイズが大きくなってもコールドスタート時間への影響は大きくないはずである。
しかし、過去に何度かAzure Functionsのコールドスタートを計測してきているのだが、サービス開始直後ぐらいは90秒ぐらいかかっていて、2017年11月ぐらいで20秒ぐらいかかっていた事を考えると、本当にめでたい。
Azure Functions従量課金プランのcold startでも10秒以内に収まるぐらいに改善したんだったら、割と積極的に使ってもいいかなぁという感じになる。前は60秒以上待たされてたからな…
— てるろー (@terurou) 2017年11月22日
Azure Functionsのcold start timeを何度か計測していて、母数が少ないのだけど、 ほぼ20secかなあという雰囲気。これに実行対象モジュールのロード（これも遅い）とか入るので…。という感じ。まぁでも、数か月前に計測してた時は60-90secぐらいかかってたので大分改善した
— てるろー (@terurou) 2017年11月23日
あわせて読みたい
次にソフトウェアエンジニア採用した際に教材にしたい本（基礎教養部分）
受託の仕事がひと段落したので、現実逃避がてら内容が古い・良くない社内図書の整理を行っていた。整理しながら「そういえば基礎教養部分の社員教育カリキュラムがまったく準備できてないなぁ」と思い、社内図書をベースに教育用に課す本を考えてみた。
以前から「日本語作文能力が足りない～」と言ってきていたのだが、それに対しての現時点の暫定解がこれかなぁと思っている。
世界一やさしい課題解決の授業
世界一やさしい問題解決の授業―自分で考え、行動する力が身につく
posted with amazlet at 18.09.25
とりあえず最初に読む本。ごく当たり前の話がサクっと書いてあるが、意識がないと全く身についてない話でもある。
読むだけなら数時間（読むのが早い人であれば、30分もあれば読める）、演習もやるなら1日～1.5日程度。
デキる大人の文章力教室（暫定、省略可）
類書は多いので、別にこれでなくてもよい。軽く数時間～半日読んで、手元に置いて必要時に読み返せれば十分。
新卒採用の初っ端によく見る「学生っぽい幼稚な文章表現」を矯正する（認知させる）ために使う。切り口は違うのだが、後述の「数学文章作法」と被る内容も多いので、教育時間がなかったり、2年ぐらいの業務経験がある人なら省略してもいいかもしれない。
数学文章作法 基礎編・推敲編
THE 基礎教養。仕事で日本語文章を書く全ての人間は読むべき。
ページ数が少ない本ではあるが、1日～2日程度かけてじっくり読んだ方がいい。時間的に早く読み終わってしまった場合は、休憩を挟んで読み直しさせるのもいいぐらい。
類書に有名な「理科系の作文技術」があるが、今なら「数学文章作法」だけで十分だと思う。「理科系の作文技術」は名著であることは間違いないのだが、エピソードトークみたいなものが若干多いせいで内容が分かりづらくなっている面もあり、「数学文章作法」の登場によって役目は果たしたのかなと思う。
「聞く技術」が人を動かす（暫定、省略可）
「聞く技術」が人を動かす―ビジネス・人間関係を制す最終兵器 (知恵の森文庫)
posted with amazlet at 18.09.25
伊東 明
光文社
売り上げランキング: 172,217
光文社
売り上げランキング: 172,217
端的には「相手を怒らせない」「相手のモチベーションを下げない」受け答えの仕方が書かれた本。教育側が「他人との会話が得意ではないな」と感じた場合は読ませた方がよい。話すのが得意なタイプであれば省略しても構わない。
数時間～半日程度で読んだら、手元に置いておいて何度も見返すタイプの本。ただ、この本は若干読みづらいなとは思っているので、もっと良い類書が見つかれば差し替えると思う。
メール文章力の基本 大切だけど、だれも教えてくれない77のルール（暫定、省略可）
メール文章力の基本 大切だけど、だれも教えてくれない77のルール
posted with amazlet at 18.09.25
類書は多いので、これも別にこの本でなくても構わない。これも数時間～半日程度読んで、手元に置いて必要時に読み直すタイプの本。
新卒採用の場合は必読として、中途採用でもメール文章を書くのが苦手な人（もしくはあまり書いてきてない人）は割と見かけるので、念のため読んでもらった方がいい。仕事で出すメールなんてほとんどのケースが定型なのだけど、定型文をちゃんと学習できてないことで、メールの往復回数が無駄に多くなって時間を無駄にしたり、「お前それ喧嘩売ってるよね」みたいな文章を平気で出してトラブルになってしまったりする事故を未然に防ぐことができる。
顧客折衝をガンガンやってきましたみたいな人の場合は、当然読まなくてよい。
考える技術・書く技術
考える技術・書く技術―問題解決力を伸ばすピラミッド原則
posted with amazlet at 18.09.25
ロジカルシンキング・ロジカルライティングの名著。前述までの本とは違って、一気に難易度が上がるのだが、世の中のロジカルシンキング・ロジカルライティング本は大体これの派生みたいな感じがあるので、最初からこれを読んだ方がよい。
できれば1週間ぐらいかけて、要約しながら読むという感じで進めたい。
プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと（省略可）
プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと
posted with amazlet at 18.09.25
これは厳密には基礎教養というよりかは、おっさんが話す「やらかさないようにこうした方がええで」とか「業界で食ってくならこういう立ち振る舞いをしたほうがええで」的な経験則に沿った内容を体系立てて1冊にまとめた本というべきか。受託開発ありきな内容に若干偏っているところがあり、ここが会社によっては合わないかもしれない。
これは半日ぐらいかけて読んでもらって、半年後とか1年後とかにもう一回読んでもらうとよさそう。時間にあまり余裕がない場合は、教える側の判断で後述の「エンジニアの知的生産術」と排他選択でよいと思う。
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする（省略可）
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
posted with amazlet at 18.09.25
どのように勉強したり思考したりすると良いのかが、人間の認知構造をベースに解説されている。
正直、読む人を選ぶなという感触があって、ボトムアップで思考する傾向のある人（もしくは内向的・自閉傾向がある人）に向いているなと思う。一方で前述の「プログラムは技術だけでは動かない」のようなトップダウン・経験則な面から入った方からとっつきやすいタイプもいるので、教える側の判断で排他選択でいいかなという気がしている。もちろん、時間が許せば両方読むに越したことはない。
この本は理詰めで書かれてる分、流し読みでは内容を理解することが難しいため、1日ぐらいかけて読んだ方がよさそう。
HaxeのマクロでPromise専用構文を作った
専用構文というか、マクロでF#のコンピュテーション式のサブセットライブラリ（Bind, Return, Zeroのみ）を実装して、その上にPromiseを載せたという表現の方が正確な説明です。
Promiseを使った非同期処理がこんな感じで書けます。hxgndでは、hxgnd.Promiseという独自実装のPromise型が提供されていますが、これはjs.Promiseと混在させることが可能です。
import hxgnd.Promise; class Main { public static function main() { Promise.compute({ var a = @await Promise.resolve(1); var b = @await js.Promise.resolve(2); var c = @await getValue(); (a + b + c) * 10; }).then(function (x) { trace(x); // 60 }); } static function getValue() { return new Promise(function (fulfill, _) { haxe.Timer.delay(function () fulfill(3), 100); }); } }
とりあえずこれがあれば、他人に無理やりHaxeを書かせる際に「Haxeってasync/awaitとかScalaのforがないじゃないですか」って言われるケースは封殺できるようになってめでたいです。あとはHaxe 4でアロー構文とfinalが入ってくるのを待つ感じです。
