ASP.NET Core 2.1をhttps://localhostで動かす

青柳 @ShinichiAoyagi です。

Developing locally with ASP.NET Core under HTTPS, SSL, and Self-Signed Certs
この記事のまんまなんですがちょっとハマったのでメモ（技術的な記事を書くのはずいぶん久しぶりかも）

最近はなんでもHTTPSで動かせとなってます。ならば、開発中もHTTPSで動かした方が間違いがないよね、ということでASP.NET Coreには簡単にlocalhostでHTTPSを使えるようにしてくれる機能があります。

まず、これはASP.NET Core 2.1の機能なので2.0じゃダメです。最初、 dotnet --version ってやったら2.1.201と表示されたのでてっきり2.1だと思ってやっていたらぜんぜんうまくいかず、調べたらSDK 2.1.201は2.0でした。

dotnet --versionってしたら2.1.201と表示されたからてっきり.NET Core 2.1だと思って操作してたらなんかおかしい。って、.NET Core SDK 2.1.201のランタイムは.NET Core 2.0.xだったのね。紛らわしいなぁ。どうしてこうなった。 https://t.co/j1jZ5oujWG

— 青柳臣一 (@ShinichiAoyagi) 2018年8月7日

これは2.1をインストールするしか手がないので http://dot.net にて最新の.NET Core SDKをインストール（現時点だと2.1.302）

これで大丈夫かと思って既存のプロジェクト（ASP.NET Core 2.0で作ったもの）で試してみると以下のようになりました。

> dotnet run
Hosting environment: Production
Content root path: C:\TestProject
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Application is shutting down...

従来どおりHTTPだけです。うまくいけば Now listening on: https://localhost:5001 と出るはずなんですが出ません。
って、そりゃそうです。2.0で作ったものは2.0で動くので2.1の機能は使えないですね。
ASP.NET Core 2.1で新規に作成（ dotnet new razor ）したプロジェクトであれば何もしなくてもHTTPSもリッスンしてくれました。

> dotnet new razor
（略）
> dotnet run
Hosting environment: Development
Content root path: C:\TestProject2_1
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

どちらも気づいてしまえば当たり前のことなんですが。。。

ちなみに、ASP.NET Core 2.0と2.1はこまごまといろいろ変わってますが以下の手順で2.1にできるそうです（私はやったことないですが）。
ASP.NET Core 2.0 から 2.1 への移行

なお、初回には dotnet dev-certs https --trust を実行する必要があります。
これを実行すると「証明書をインストールするか？」と聞かれるので「はい」します。Windowsだと証明書ストアに、Macだとキーチェインに、localhostで使う証明書がインストールされます（Linuxの場合はディストリビューションごとにやり方が違うそうです）。
見てみたら発行者・発行先とにもlocalhostで1年間有効の証明書が「個人」のところにインストールされていました（正確に言うとインストールされる証明書はlocalhostで使う証明書を証明する証明機関の証明書ですかね）。

この証明書が入っていない状態でChromeで https://localhost:5001 にアクセスすると以下のようになります。

ディーバでは正社員を募集しています

青柳 @ShinichiAoyagi です。

現在（2018/08/02） ディーバ では正社員を募集しています。

募集内容

デベロッパーを募集しています。というか、現時点ではディーバにはデベロッパーしかいません。私を含めて4名（男性3名、女性1名）の小さな会社ですが全員がデベロッパーです。

ディーバにはオリジナルのソフトウエア（ 給排水設備CAD 管彩 など）もありますがこれらについては当面バージョンアップなどの作業予定はありません。ちなみにこのCADはC#/WPF製です。

今現在ある案件はお客様からご依頼されたソフトウエアを作るというものです。ただSIer経由ではありませんのでExcel方眼紙の設計書などはありません。お客様からどんな機能が必要かをヒアリングし、あとはそれを実現するにはどうすればいいかを自分たちで考えて実装します。極端なことを言うと私から「○○できるアプリを作って。デザインはいい感じにしといてくれればそれでいいから。じゃ、よろしく」みたいに口頭で言われて作り始めるなんてこともあります。ですからなにもないところからクリエイトする力が必要です。そうでないとディーバでの仕事はできません。
（2018/08/06追記）ちょっと表現が乱暴だったかもしれないので追記しておきます。上記は「じゃ、よろしく」と丸投げしてそれ以後放置とか、一人っきりで自分だけでなんとかしろとかそういう意味では決してありませんので。あくまでも、要望を実現するにはどうすればいいかを自分の頭で考えることができないとダメという意味です。言い換えると、設計書を見ながらでないとプログラムを書けないような人では務まらないということです。（追記ここまで）
現在はWPF、ASP.NET Core、Xamarin、UWPの案件が並行して走っています。どれもC#です。ここ1年ほどはC#しかやっていません。ただし、C#以外がないというわけではなくお客様の要望によってはどんな言語でも使います（Java、PHP、Ruby、Python、Go、Kotlin、Swiftなどなど）。
ソフトウエアのジャンルとしてはビジネス向けが主です。ある企業の社内や社員さんが使用するためのアプリです。ただ、AppStoreやGoogle Playで一般向けに配布するようなコンシューマー向けアプリも中にはあります。

SIerからの下請け案件もないわけではありません。2年近く下請け案件は請けていませんがあえて避けているというわけでもありませんので状況によっては今後こういった案件を受注する可能性はあります。
このような案件の場合はSEが書いたExcel設計書を見ながら実装したり、逆にSEとしてExcel設計書を書いたりすることになります。技術的にはおもしろいことやチャレンジングなことはない場合が多いですが、だからといっていい加減なコードを書いていいわけではありません。そこはプロとして美しいコードを書くように心がける必要があります。少なくとも私はそうしています。

どのような案件だったとしても客先常駐はありません。
お客様のところに打ち合わせに行くとか、現地に行かないと環境がないから何日間か詰めてテストするとか、そういったことはありますが基本的に作業は自社にておこないます。

担当の案件のみをやっていればいいという専任制ではありません。複数の案件を掛け持ってもらったり途中から他の案件に移ったりと状況に応じて臨機応変に対応しています。1つの案件をライフワークのようにやり続けたいという人も中にはいるかもしれませんがどちらかというとディーバではその時々でやることが変わると思っていただいた方がいいかと思います。

求めるスキル

業務としてコードを書いたことがあるかどうかはまったく問いません。
業務であるかどうかは関係なく、自分で1つのアプリケーションを作る能力のある方を募集します。たとえば、簡単なものであってもスマホアプリを作ってリリースしたことがあるとか、ちょっとした掲示板を作ってAzureにデプロイして動かしているとか、そういった「起動してから終了するまで一連の流れを自分で作ったことがある」ような人を求めます。ライブラリを作ってGitHubやNuGetなどで公開しているといったことでも構いません。パブリックに公開しているのであればぜひソースコードを見せてください。もちろん、公開できるコードはないけど同様のことを業務でやっていたというのでも構いません。その場合は可能な範囲で内容を聞かせてください。

給与

業績に連動して変動します。
今年度（昨年10月～今年9月）の年収は450万～500万円程度でした。
詳細は以下をご覧ください。
「ディーバではこうやって給与を決めています」

通勤時や客先訪問時の交通費は給与とは別に実費分を支給します。

勤務日数・時間

コアタイムなしのフレックスタイム制です。
休日は土曜日、日曜日、祝日、夏季休暇（4日間）、年末年始休暇（12月29日～1月4日）です。ただし、勤務時間だけでなくいつ休むかも1月の勤務時間を超えず業務に支障がなければ自分の判断で自由に調整できます。詳しくは以下をご覧ください。
「ディーバはフレックスタイム制になりました」
なお、休む場合の届け出は「いついつ休みますね」の一言をSlackに書くだけです。
有給休暇も定められた日数内であれば自由に取得できます。

また、時短勤務についても相談に応じます。
たとえば「週5日ではなく4日勤務にしたい」や「1日6時間勤務にしたい」などです。単純に勤務時間が減る分だけ給与も減ると考えてください。

服装

自由です。普段はTシャツジーパンなどでもOKです。

開発環境

MacBook Pro + 外付けディスプレイ×2程度の環境を用意します。
詳細は以下をご覧ください。
ディーバの開発環境

勤務地

基本的に弊社事務所です。
〒541-0042 大阪府大阪市中央区淡路町3-2-8 トーア紡第2ビル 201
Google Map

在宅勤務、リモート勤務も相談に応じます。
ただし、まだ体制としては完全とは言えません。すでに在宅勤務を主としている社員もいるのですがコミュニケーションの方法など改善すべきところがいくつかあります。そのため至れり尽くせりで在宅勤務できるわけではなく当初は不自由に思う部分があると思います。むしろ人柱となって一緒に試行錯誤してくれることが在宅勤務の条件になると考えてください。
また、開発環境の問題があります。在宅勤務時にMacBook Proを持ち帰ることは可能ですが外付けディスプレイなどは今のところ自前で用意していただくことになります。在宅勤務の場合、交通費がほぼ不要になるのでその分を自宅環境整備の補助として出せないかといったことは考えていますがまだ制度化できていません。
いずれにしても在宅勤務、リモート勤務は前向きに考えていますので希望する方は遠慮なくおっしゃってください。

その他

• 書籍購入費としてAmazonギフト券を支給します。「社員のみんなにAmazonギフト券1万円分をプレゼント」
• 「ゆとりタイム（仮）」という制度があります。毎週木曜日の午後は自由にテーマを設定してその作業に充てられるというものです。テーマは普段の業務と無関係のもので構いません。詳細は後日ブログにまとめます。
• 2018年5月のde:codeに私と社員1名で参加しました。参加費、交通費、宿泊費は会社負担です。今後も同様にカンファレンスや勉強会への参加を補助していくつもりです。「de:code 2018に参加してきました」

最後に

30年以上前、中学生の頃からプログラミングにハマり、いつの間にか趣味が仕事となり、ソフト開発会社を友人と立ち上げ、マイクロソフト社からMicrosoft MVPなんて賞をもらったりし、いろいろあって友人から社長を引き継ぎ、、、ディーバはそんな人間が社長をやっている会社です。（昔話は「社長になって丸7年が経ちました」）

私自身、C#や.NETが大好きで社長業の傍らコードを書いたりしてるわけですが、当然のようにC#や.NETが中心な会社になりました（例外もあるけど）。

そんな会社に興味がある方はぜひお気軽にお問い合わせください。
お問い合わせは私のTwitterやディーバWebサイトに記載のメールまでお願いします（私のTwitterは誰からでもDM受けられるようにしてあります）。

ディーバではこうやって給与を決めています

青柳 @ShinichiAoyagi です。

給与の決め方はいろいろありますが ディーバ では業績に基づいて決めています。もちろん個人ではなく会社全体の業績です。

月給は30万円/人

まず、月額は30万円/人が基本です。勤続年数などで変えるつもりはないのでベースアップはありません。もちろん、個人のスキルや希望、状況などで調整することはありますし相談にも応じます。
この月給は基本的に固定とし、業績に基づいて年2回の賞与で上乗せします（ディーバの賞与月は7月と12月で、評価期間はそれぞれ前年10月～3月と4月～9月です）。

ちなみに残業はありません。サービス残業しろという意味ではなく、社員のみんなには残業自体がないように勤務してくださいとお願いしています。月の総労働時間を定めるタイプのコアタイムなしフレックスタイム制なのでどうとでも調整できます。詳細は以下にて。

「ディーバはフレックスタイム制になりました」

賞与額の決め方

上述の通り月給は基本的に固定とし、会社の業績に応じて賞与額を決めるわけですが、具体的には以下のように決めています。

下図は27期（2017/10～2018/9）の構成です（8月、9月分は予測）（単位は千円）。
あまり生々しい値を出すのはどうかと思いましたが、まぁ、別に害があるわけじゃないですしいいでしょう。上場企業や大企業は決算書の開示義務があるんですし、零細企業だって銀行や取引先から求められれば提出するわけですし。

なお、この数字はキャッシュフローベースです。なので帳簿ベースの決算書とは合いません。帳簿ベースで考えてもいいんですが、私は普段はキャッシュフローベースで考えています。

人それぞれ考え方はあると思いますが、私は「粗利に対して経常利益25%、人件費55%、固定費20%」くらいにしたいと思っています。言い換えると労働分配率を55%にしたいということです。
粗利が決まって労働分配率が決まれば人件費の額も決まるのであとは社員のみんなにどう配分するか決めればいいだけです。ただ、27期は労働分配率55%だとちょっと予定していた給与水準に届かなかったので上図のとおり65%となりました。その分経常利益が少なくなってしまいましたがまぁ仕方ありません。

人件費には社会保険の会社負担分も含まれています。だいたい16%くらいですが私はざっくり考えるときは20%増しにしています。年収600万円の人の給与を払うためには会社は720万円用意しないといけないわけです。
また人件費には私（経営者）の給与も含んでいます。去年と今年は60万円/月（年収720万円）です。代表取締役に就任した2010～2013年は30万円/月の設定でしたが実際には2～3ヶ月に1度くらいしか給料取ってなかったので年収150万円くらいでした。その後は2014年～は40万円/月、2016年～は60万円/月で一応設定どおりには給料取っています。ただ、賞与は就任以後取ったことはありません。

賞与の配分

人件費の総額が決まれば賞与の総額も決まります。単純に人件費から月給の総額を引けば残りが賞与に使える金額です（社会保険の会社負担分の考慮も必要）。
あとは誰にどれだけ出すかを決めればいいだけです。
給与賞与はこのようにして求めています。「Aさんは優秀だから○○円にしよう」ではなく「業績的に賞与に××円出せるからそれをみんなに配分」という考え方ということです。
実績で言うと、今年度の業績では社員の皆さんの年収は450万～500万円程度でした。

最初の目標は平均年収600万円

私は社員の平均年収を少なくとも600万円にしたいと思っています。今年度は残念ながらそこまではいけませんでした。600万というのは零細企業にはかなり難しい数値だというのが実感です。けど、そこそこ優秀なデベロッパーならそれくらいはもらってないとおかしいじゃないかとも思いますし、感触的にはまったく不可能というわけでもないと感じています。ただ、この水準に行くのはもうちょっと組織としてレベルアップしないと難しいとも思っているところです。もちろん平均600万が達成できたら800万、1,000万とレベルアップしていきたいですね。

さて、賞与の額ですが今年度は全員一律としました。しかしもう少し給与水準が高くなってきたら評価や査定をおこなって差をつけるようにしていきます。全員が同額なのは今だけの予定です。

業績が悪化したとき

こういう業績連動型だと業績が悪くなれば報酬も少なくなります。内部留保がたくさんあれば（言い換えると貯金がたくさんあれば）そこから人件費を出せばいいのですがディーバのような零細企業ではなかなか難しいのが実際のところです。2、3ヶ月の短期であればどうとでもなりますが半年以上など長期になってくると資金繰りが苦しくなってきます。
また、毎年のように大きく年収が変動しては生活設計も難しくなってしまいます。なのでなるべく安定していた方がいいのは当然です。
これらの点は今後の課題だと思っています（けど、なるべく利益を残して内部留保を大きくして業績悪化時に備えるというくらいしか思いつきませんが。結局のところ「しんどいときに使えるお金をどれくらい残してあるか」に行き着いちゃうもんなぁ）。

労働分配率55%な訳

上でサクッと「労働分配率を55%にしたい」と書きましたがなぜ55%かというと明確な根拠があるわけではありません。いろいろ考えたらそれくらいが落とし所かなと思ったという程度です。

同じ図を再掲します。

以下、各項目の簡単な説明。
（きちんと会計を学んだことがあるわけではなく、最近になって本やWebを読んだりして勉強しただけなので間違ってるところもあるかもしれません）

• 売上 … ソフトウエアを開発したり販売したりしてその対価としていただいたお金です。ディーバの場合それ以外の売上はほとんどありません。
• 原価 … 飲食業なんかだと材料費になりますがディーバの場合は外注費です。去年2案件ほど外の人に手伝ってもらったのでそれで支払った分です。
• 粗利 … 売上から原価を引いたもの。なのでこの粗利が「ディーバのみんなが働いた対価としてもらったお金」ということになります。粗利は限界利益とか付加価値とも呼ばれます。
• 固定費 … 家賃や光熱費、PCやVisual Studioなんかの購入費です。固定費という名前ですが金額が固定という意味ではありません。ちなみに、物を売ったときに一緒になくなってしまうものは原価になります。物を売っても残るものが固定費です。
• 人件費 … 給料です。これには社会保険の会社負担分なども含みます。
• 経常利益 … 会社に残る利益です。ここから法人税なんかが引かれた金額が実際に会社に残る金額になります（税引き後の利益を純利益と言います）。
• 労働分配率 … 粗利に対する人件費の割り合い。

労働分配率は「これくらいが適正」という値があるわけではないそうですが「50～60%くらいであればいいんじゃないかな」くらいではあるようです（業種によって様々ですが）。いろいろ考えたところディーバの業態では55～60%くらいが妥当なところなのかなと思っています。
ちなみに人売りをしているSES企業とかだと労働分配率75%以上なんてところもあるようです。これは、人売りだと会社の取り分だけ抜いて残りはみんな給与として払っちゃうことができるからです。事務所に机もPCもいらないし交通費などの経費も客先に請求できるしとなると固定費がほとんどいらなくなります。その分を人件費に回せるわけです。派遣業なんかでも労働分配率は75%くらいになっているようです。

労働分配率も重要ですが経常利益も重要です。
経常利益率は25%は欲しいと思っています。
経常利益は会社に残るお金（実際にはここから税金を引いた額が残るお金）な訳ですがこれはすなわち今後のための余裕ということになります。業績不振のときに何とかするためのお金という側面もありますし、研究開発費や宣伝広告費として使ってより業績を伸ばすためのお金とも言えます。また新たに人を雇う場合でも雇った直後から売上が増えるわけではないので余裕がないと雇うこともできません。毎年成長を続けるためには毎年利益を出し続けて余裕を作り続ける必要があります。カツカツだと新たな一歩を踏み出すための研究開発費も出せなくなってしまいます。だから常に利益は出し続ける必要があると思っています。「今年は利益なしのとんとんでいいや」という小休止はナシだと思っています（結果的にそうなってしまうことはよくあるんですが）。
とは言うものの、経常利益率25%が妥当かどうかはわかりません。中小零細企業の社長向けの書籍なんかに「経常利益率は25%は取れるようにしろ」とあったのでそのままこの数字を使っています。規模が大きくなれば金額も大きくなるのでそうなったら25%にこだわる必要はないのかもしれません。有名な未来工業の故・山田社長は経常利益4,000万くらいは取れるようにしろとおっしゃってたそうなのでそれくらいが1つの目標なのかなとも思っています。

というわけで、労働分配率の面から見ても経常利益率の面から見ても「粗利に対して経常利益25%、人件費55%、固定費20%」くらいが妥当なところだと思えたのでこの値にしています。
割り合い自体は状況を見ながら調整していくことになると思いますが給与賞与の考え方自体は変わりません。

SOYJOY 職場応援キャンペーンに当選しました

「SOYJOY 職場応援キャンペーンキット（SOYJOY クリスピーピーチ12本+メッセージステッカー12種類入）」を、抽選で合計1,000の会社に当たる SOYJOY 職場応援キャンペーン に当選しました。ありがとうございます。

キャンペーンの特徴は、会社宛限定になっているところですね。また、上司から若手用・若手から上司用が選べます。社長の代わりに「上司から若手用」を応募しておきました。

メッセージステッカーが付いてます。

大塚製薬 ソイジョイ クリスピー ピーチ 25g×12個

MacBook Pro を修理に出した

購入してもうすぐ3年というところで MacBook Pro のディスプレイが表示されなくなり修理に出しました。ちなみに MacBook Pro は社員ひとりに1台割り当てられ持ち帰りや私用等は自由です。持ち帰って、自宅で起動したら表示されなくなっていました。SMC リセット等でも直らず。

修理して新しくなった天板。

AppleCare 未加入で購入から日が経過しているので、まずは Web で予約して持ち込み修理しかできないようです。最寄りの Apple 正規サービスプロバイダへ持参しました（個人で修理して経費として清算します）。

その場で確認できる事項はすべてチェックしてくれるようで、約1時間かかりました。結果、本体の基板には問題がなさそうで、ディスプレイ部分（天板含めた MacBook 半分まるっと）の交換という判断になりました。

部品名は Display Assembly、価格 64,817円と、技術料 8,640円でした（受け取り時に支払い）。

もしディスプレイ部を交換して動作せず基板も交換となるとプラス5万円ぐらいで、その際は交換するかどうか電話で確認するが、部品を発注しているのでキャンセル料5000円とのことでした。

幸い？ 、見積もり通り、ディスプレイ部分の交換で済みました。消えて困るデータは入ってなかったですが、SSD の中身はそのままで、すぐに元通り使える状態です（もちろん、修理でデータが消えても保証はありません）。

修理期間は1週間と伝えられましたが、5日後には修理を終えてました。

ディスプレイ部のみ90日保証とのこと。

ちなみに店員からは、安い MacBook なら買い換えをお勧めしているが、ディスプレイ15インチ・メモリ16GB の Pro なので修理して使う方が良いかもですねって話もありました。新しい MacBook Pro が発表されたらそろそろ買い換えてほしいですね🤔

社員のみんなにAmazonギフト券1万円分をプレゼント

青柳 @ShinichiAoyagi です。

ディーバ の社員みんなに1万円分のAmazonギフト券を支給しました。 電子書籍を購入するためにこういった制度を導入している会社もそれなりにあるようなので真似てみました。

主にIT系の電子書籍を購入することを想定してはいますが、役に立つもの、勉強になるものを購入するのであればそれに限らず自由に使ってもらって構いません。 ただし、「購入したものをSlackで報告する」必要はあります。
レビューも投稿してくれると他の人の参考になりますし、さらにパブリックなブログとかに書いてくれるとなおいいな、とは思っていますがこれは強制ではありません。
一応、1年間で1万円としていますが期間や金額は様子を見て調整するつもりです。

もちろん、今までも要望があれば書籍や物品を会社で購入していました。もしくは、レシートや領収書を出してもらって精算してました。業務に直接関係するものはもちろんとして、多少関係なくても役に立つ・勉強になるものなら購入してました。これらは今後も変わりません。
けど、より気軽に買えるようにAmazonギフト券なりで支給するのはどうかと社員から提案をもらったんですね。確かに、電子書籍は自分のアカウントに紐付くこともあって会社に要望しにくい感じがあるし、事前に会社に「これ買っていいですか？」と確認するのが面倒に感じることもあるでしょう。なので「それはいいかもね」ということで支給することにしてみました。

ちなみに、税理士の先生に確認したところAmazonギフト券支給の場合でも図書費、もしくは、図書研修費で計上してまったく問題ないとのことでした。

ここからはちょっと余談
昔（私が社長に就任するよりずっと前）は毎月18日のお昼すぎくらいに本屋に行ってました。IT系の雑誌はだいたい18日発売なので。
一人で行くこともあれば何人かで行くこともありましたね。昼休みにちょっと抜けるとかではなく2時間くらい本を物色してるときもありました。
毎月買ってたのはC Magazine、MSDNマガジン、Software Design、Dr. Dobb's Journal、SQL Serverマガジンといったところでしょうか。懐かしいなぁ。
他にも気になった月刊誌や書籍は買ってましたから1月に数千円から1万円くらいは使ってたと思います。もちろん会社に出してもらってました。今と違って当時は月刊誌や書籍は重要な情報源でしたからね。
どんどんネットで取れる情報が充実していき、同時に月刊誌も休刊/廃刊されていき、いつの間にか毎月本屋に行くという習慣はなくなってしまいました。今でも本屋に行くこと自体は結構好きなんですが、購入はAmazonで済ませてしまうことがとても多くなりましたね。ほんと、時代の変化を感じます。

ディーバはフレックスタイム制になりました

青柳 @ShinichiAoyagi です。

ディーバ は9:30～18:30（昼休憩1時間）でした。遅刻早退の場合はその時間分だけ給与から引かれます（有給を充てることは可）。前社長から引き継いだ時点では遅刻3回で1日欠勤扱いといったペナルティがあったんですが、今はペナルティはなしにして純粋に時間分だけ少なくなります（ちなみに、1分の遅刻でも半日分までは減額することができます。ただし、ペナルティとして減額できる合計金額は月給の1/10までです。という規定が労基法にあります）。

というのが2018年2月まで。

2018年3月からはフレックスタイム制に変更しました。
1ヶ月の労働時間計が必要時間になっていればそれでいいという形です。

• 1ヶ月の必要労働時間は「平日日数×8時間」で計算する。平日というのは土日祝と夏季休暇・年末年始休暇を除いた日のこと。
• 標準の勤務時間は9:30～18:30。別にきっちりじゃなくてもいいけど、特に理由がないならこの時間帯に仕事する感じで（コアタイムとかではなく単なる目安）。
• 業務に支障がない範囲で自由に始業時間・終業時間を変えてOK。ただし事前に連絡を（Slackに書いといてくれればOK）。
• 休憩時間は1日6時間を超え8時間以内のとき45分間以上、8時間を超えるとき1時間以上とする。これは労基法の規定なのでこれより下回ってはダメ。休憩は労働時間には含まない。
• 休憩時間が上記より多いのはOK。なので「12時から3時間休憩にして役所行ってきます」とかもOK。Slackに一言書いて。
• 原則として1日に10時間を超える労働はダメ（休憩時間を除いた時間が10時間まで）。
• 22時～翌5時の勤務（深夜勤務）も原則ダメ。
• 最低でも1週間に1日は休日にすること（毎週、日～土のどこかは休む）。
• 有給休暇は1時間単位で取得可能とする。「今月2時間足りないので有給を2時間だけ使う」とかって使い方もOK（けど、無駄に有給使わなくていいようにうまく調整してほしい）。
• 原則として残業は禁止。働きすぎないようにうまく調整を。

いちおう、「毎日10時間働いて週休3日にする」とか、「月～木は10時間勤務、金～月は4連休、火～金は10時間勤務、土日は2連休、、、という風に4連休と2連休をローテーションする」とか、そういうのもやってみたい人がいれば今のところはOK（労基法的にも平均8時間/日を超えなければ問題ないはず）。けど、毎日10時間勤務（休憩込みだと11時間）でパフォーマンスが落ちるようならちょっと考えるかも（「3日以上連続で8時間以上勤務はダメ」にするとか）。

これでディーバは服装は自由、時間はフレックスとなりました。次はどこででも働けるようにしていかなくちゃと思ってます。これもすでに一部は在宅で作業したりしていますがもう少しきちんと考えなくちゃいけないことが残ってますので。

裁量労働制と高度プロフェッショナル制度

裁量労働制はデベロッパーは対象外（ゲームデベロッパーやSEは対象ですが）、高度プロフェッショナル制度はまだ法案が可決してない（可決されても特定の業務、かつ、年収1,075万以上とかそんなのだし）、とそもそも使えないんですが。。。

仮に使えるとすればこういった時間縛りのない働き方もアリだとは思っています。むしろ開発系の仕事にはそういった働き方の方がむいているんじゃないかと思います。しかし、それをするには会社側からきちんと何をすべきなのかを提示し、そしてその結果が正しく求めたものになっているかを評価する、といったことが絶対に必要です。それなしだと何をいつまでにどれだけやればいいのかわからないので裁量もへったくれもなくなってしまいます。マイクロソフトなどんかがやっているような各自のジョブディスクリプションを明確にしてそれを評価するっていうやつですね。しかしこれをやるには相応の体制が必要です。なので思いつきで導入できるような制度ではないと思っています。けどいずれはこういった制度も取り入れられるように考えてはいきたいですね。