人月単価で80万円ぐらいの仕事
Twitterでこういうことを書いたら、そこそこ反応があった。
今のご時世、技術難易度が並ぐらい(一人でWebシステムが構築できる程度)で、2‐3人月ぐらいの小さなシステムを一人でヒアリング~実装~運用引き渡しができて、説明責任ちゃんと果たせれば、人月単価換算で80万円ぐらいは一杯転がってる(常にあるとは言ってない)し、その他要因で単価はもっと上がる
— てるろー (@terurou) 2018年4月17日
意図通りには伝わらないだろうなぁと思いつつ、所詮Twitterだしなーと思いぶん投げたんだけど、想定してた範疇の誤解が広まってきたので、一応補足する。
「人月単価で80万円ぐらいの仕事」の難易度
ちゃんと書いてないから伝わらなくて当然といえば当然なんだけど、行間をちゃんと補うと、
- エンドユーザー直案件
- 技術難易度的には、いわゆるマスタメンテナンス機能に毛の生えた程度のもの
- 実装技術とは別で、現状の業務分析であったり、システム化後の運用フローがどうなるかを考えたり、開発完了後の導入やユーザー教育(操作方法レクチャー)を行うことが必要
割と具体的な例を出すと、経費精算みたいな社内業務。
こんな感じの業務を、業務フローを見直しつつ、システム化していくみたいな話。この要件を80万円で1か月で作るという話ではないし、ヒアリングしたら印刷が必要だとか会計システムとはAPI連携が必要だとか、ミッションクリティカルなシステムだとか、セキュリティの事をちゃんと考えないとダメだとか、技術難易度が上がる要素があれば当然その部分は単価を80万円から割り増しする。
上記の業務例を、単価レンジ80万円で対応できる内容に落とすと、
- ユーザーロールは一般ユーザーと承認者の2つ
- 一般ユーザーはWebフォームに申請内容を入力し、入力ができたら申請ボタンを押す
- 承認者は一覧画面で未承認のデータが検索でき、個別に内容を確認して承認ボタンを押す
- 一覧画面で年月を指定して承認済みデータが検索でき、該当データの一覧がCSVファイルとして出力できる
- あわよくば会計・給与システムと連携できるCSVフォーマットになっているとよい
- インターネット非公開(社内からしかアクセスできない)サーバーに配置して、サーバーにアクセスできる人ならデータ自体は誰でも見えてOK
- サーバー構築は不要(今時だと何らかのSaaS上に構築するみたいのが多いと思う)
- 対応ブラウザはPC版Chromeのみ
という程度のシステム化具合。業務要件のヒアリング・設計・開発・システムテスト・ユーザーテスト兼ユーザー教育・導入初期の運用・不具合サポートみたいなところをもろもろやると、2-3人月かかるよねぇ、単価と期間を掛け算して最終的な請求額は200万円ぐらいかなぁ、という感じ。実装部分だけ抜き出すと1か月分相当ぐらいだろうし、使うフレームワークやSaaSや技術の練度によってはもっと期間短縮したりできるとは思う。あと、フル稼働が必要な部分は実装~システムテストの部分だけで、それ以外はお客さんからの回答待ちや待機のような拘束時間には変わりはないが実質何もしてないみたいな時間もある。
人月単価80万円ぐらいという相場感
前述の例のような紙やらExcelで日常業務を回してるところは大量に存在していて、当人たちも効率が悪いことは自覚していてシステム化も検討してはいる。しかし、SIerに相談するとクソ高い見積もりが出てくるとか、仕事のロットが小さすぎるから請けてくれないとか、過去発注したシステムが金をかけた割にクソだった経験があるとかで、結局放置されていることが本当に良くある。
そういった相手に話をする際に、基準となってくるのが80万円ぐらいかなぁというのが個人の肌感覚である。もちろん仕事でやっていく際は、相手の懐具合を見て多めに要求することもある(実際には相手が大きな会社だと、AD連携がどうとか、瑕疵の保証がどうとかの要素が増えてくるので、懐具合関係なしに割増が生じる)し、逆に予算がほぼないところもある。
ここまで書いて、会社によって営業費とか間接費のかけ方が違うので「人月単価80万円では安すぎる」という話はあるでしょう。ただ、繰り返しになるが、ある程度の規模のSIerだと単価レンジが80万円の2-3倍ぐらいになるはず(前述の例だと請求額で500万円を超えてきたりとか)で、これが高すぎるからシステム化出来てないみたいのは腐るほど存在している。
80万円という単価レンジは、クライアントから見ると割安な価格設定に見える。同時に営業費用をあまりかけていない会社であっても単価80万円を割ってくると、おちんぎんが少なくなるので、ここは守らないといけないラインかなと設定している。
人月単価80万円ぐらいの仕事を工夫して、割の良い仕事にする
ジョイゾーさん
直接話をしたことはないので私が勝手にそう思ってるだけですが、ジョイゾーさんのKintone SIがこんな費用感をベースにやっている認識です。
まともに開発すると2-3か月かかるような話をテンプレートを適用していくことで開発工数を減らすものと、テンプレートではどうにもならないものを1週間20万円で対応しますよというもの。
弊社の例
アジャイル開発契約というか、ソニックガーデンさんの「納品のない受託開発」もどきというか、みたいな定額制の契約モデルで請けているお客さんがいる(全てではない)。
「納品のない受託開発」もどきの定額制の契約モデルというのは、
- 納品自体はしている
- 月額費用は数十万円ぐらい(作業ボリュームに合わせて調整)
- 開発初期はどうしても労力が大きいので、ギリギリ赤字にならないレベルの額を初期費用として請求している
- 最低限の機能を実装した段階でお客さんに納め、運用しながら改善をしていく
- 毎月1回定期訪問して、改善点等のヒアリングを行う
- 月間に対応できる改善工数に上限値があり、それをどうしても超えたい場合は別途お見積りで対応
- 対応速度はベストエフォート(手が空いている場合は即日対応、契約上は10営業日以内に着手)
というように、費用・開発規模共にスモールスタートでやって長期的に改善をおこなっていき、売上的には初期導入費用+月額サブスクリプションみたいな感じになっていて、トータルで見たときに単価80万円ぐらいに設定している。効率的に仕事を捌けば実際の作業に対する売上効率は良くなる。
これの良いところは、
- 初期費用を抑えていて、納品後も機能追加を継続的に行うことが前提になってるので、開発スコープの絞り込みで合意が取りやすい
- 「とりあえず優先順位の高いこれに絞りましょう」「実際に使い始めて足りなかったら機能追加しましょう」
- 安定稼働して、ユーザーもシステムに慣れてくると、やることがかなり減ってくる
- 継続的な収入があって、構造的に作りすぎが発生しにくいので、瑕疵対応がつらくない(お客さん側も機能改善の一環として見てくれることが多い
- 毎月1回定期訪問すると、納品したものとは別のシステム化の話が出てくるので、お金をもらいながら営業してる状況になる
といったところ。
悪いところ?としては、プログラミング言語の知識とかを生かすことがほぼなくて、本当にITコンサルタント的な動き方になるので、技術だけやりたいみたいな人だとやりたがらない。
追記:運用・改善フェーズに入ったら、 月々の実稼働が1日と想定して10万円みたいな価格設定 になっている(実際の想定日数とか、技術難易度とかで割り増しはある)。当然運用は長期になるので、大儲けはないが効率の良いお仕事。あと、運用してる間に「あれもシステム化したい」みたいな話は当然出てくるので、「それも初期開発は別料金になりますねー」みたいなサイクルが続く。
追記2:この話の文脈
HaxeのUnitTestライブラリ(2018年版)
2018年におけるHaxeのUnitTestライブラリについて書く。この記事を書いている時点ではutestを使っている。
この記事で挙げているものはすべて試したが、多少機能は少ないが枯れていて面倒が少ないのはutest、高機能なものがよければbuddyという感じかなという印象。tink_unittestは使いやすいAPIなんだけど、枯れてないので将来に期待という印象。
utest
Assertion Style(JUnit風)。API設計も素直なので、学習コストが低い。ユーザー数も多く、十分に枯れている。
ただ、テスト内容を日本語で書けない点が欠点と言えば欠点。Haxeは識別子に日本語を使えないので、クラス名・メソッド名ベースでテストレポートを出力するutestでは日本語出力はできない。
buddy
BDD Style。シンタックスが若干変態的だが、テスト内容を日本語で書ける。非同期テストでtimeoutが設定出来たり、コンパイルエラーが発生することがテストできたり、高機能。
Browserテストサポートが若干弱く、レポートがconsole.log()に出力される。
2018-10-26 追記
1000件ぐらいある非同期テストを書いて、Nekoターゲットでテストを実行したら、GC fatal error: Too many threads
で落ちる現象を確認した。Thread Poolを使ってもダメ。問題の切り分けのために、Thread数千個立てるだけの単純なプログラムを動かてしてみても落ちることはないし、他のUnit Testライブラリ(tink_unittest)で同様のテストを書いても落ちることはなし、Buddy固有の問題のようだ。しんどい。
JavaScriptターゲットであれば動くのだが、マルチターゲットを想定した場合は使わない方がよさそう。ある程度調べてみたが、原因はよく分からなかった。Buddyが内部で使っているpromhxの方(もしくはpromhxの使い方)に何か問題がありそうな感じはしている。
2018-10-31追記
Issueを投げてやり取りしてるうちに原因が分かったので、非同期テストがこける問題は修正された。これで無事におすすめできるようになった。
Fix a bug that crash neko when it runs many async test cases. by terurou · Pull Request #75 · ciscoheat/buddy · GitHub
tink_unittest
Assertion Style。Haxeをがっつりやってると必ず目にするTinkerbell系のライブラリ。@:describeでテスト内容を日本語を設定したり、assertionがマクロになっていたり、非同期テストでtimeoutが設定できたり、こちらも高機能。
ただ、どうもv0.5.5の時点では、JS出力でBrowserテストに対応してないっぽい(Browserify通せば行けそうだが)。
MassiveUnit(munit)
数年前はこれがデファクトスタンダードという状況だった。おそらく今でも一番ユーザー数が多いと思われるが、いかんせん設計が古い面が否めない。個人的には、既に役目を終えつつあるものと認識している。
2019-03-24追記
Haxe公式でもutestと並んで紹介されていたり、OpenFL(Flash APIのマルチプラットフォーム実装)で標準であったり、ユーザー数が多いことには間違いはない。
haxe.unit
Haxe標準ライブラリに含まれるUnitTest。機能不足過ぎ、Haxe 4.0で廃止が決まっているため、使う理由はない。
Breaking changes in Haxe 4.0.0 · HaxeFoundation/haxe Wiki · GitHub
補足
日本語の扱いについて記述しているが、実際に試してみたところ、NekoVMでは日本語がコンソールに正しく出力されなかった。Node.jsでは大丈夫だった。
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は、JSONで id
が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);
「労働者側の裁量で深夜労働もできる勤務体系」をまじめに考えるとクッソ大変な話
これを読んだ。
就業規則おじさん枠として、「労働者側の裁量で深夜労働もできる勤務体系」について言及しようと思う。労働法のエキスパートではないので、実際に検討をする場合は社労士と相談が必須。
お前誰よ
過去にこんなことをした。
本業ではないので労働法のエキスパートではないが、
- 自分で就業規則をゼロから書き起こした零細企業実務者
- 就業規則は執筆中~施行前まで社労士チェックが何度も行われている
- みなさんが期待する裁量労働制・なんでもありフレックスタイムを本気で検討したが、制度設計・運用がともに無理だと思ったので断念した
という前置きで。
蛇足だが、就業規則を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
に切り替える。(結構時間がかかる)
次に アプリケーション設定
を開いて、 WEBSITE_DEFAULT_NODE_VERSION
に使いたいNode.jsのバージョンを指定して、保存する。
これだけで完了。念のため プラットフォーム機能
から コンソール
を開いて、正しく設定されているかを確認。
> node -v