スペシャリストというキャリアパス

青柳 @ShinichiAoyagi です。

「プログラマー35才定年説」なんてことが言われたりしますが、まったくもってナンセンスですよね。
そりゃ、年齢がいくと頭が固くなるとか記憶力が落ちるとかは確かにあります。けど、そんなことは人それぞれですし、何才でどうなるかなんて明確になっているわけでもありません。まぁ、そういうことではなく、35才くらいで管理職になったりとかそういうところから来てるんでしょうけどね。
ちなみに、Windows NTを作ったデビッド・カトラー氏は当時46才だったそうです。その様子は名著「闘うプログラマー」に詳しくあります。

闘うプログラマー[新装版]

（こんなデスマーチを今のアメリカでやったら裁判起こされたりとかいろいろと大変なことになりそうですが）
今現在、氏がどうされているかはわかりませんが、少なくとも2012年時点（当時69才くらい）では現役だそうです。プログラマーなのかはわかりませんが。
Windows NTの開発者「デヴィッド・カトラー」は戦い続ける

35才定年説とはちょっと毛色が違いますが、「テスターやプログラマーは下っ端。SEの方が偉い。マネージャーはもっと偉い」なんてことも言われたりするみたいですね。
これまたまったくもっておかしな話です。
マネージャー・SE・プログラマー・テスターなんていうのは役割の名称です。どれが偉いなんてことはないです。ただ、日本語のややこしいところで「マネージャー」を「部長や課長といった管理職」だと捉えると偉い人ということになります。けど、「マネージャー」を「チームをマネージメントするという役割の人」と捉えると偉いとか偉くないとかは関係ない「役割」の名前ということになります。もちろん、ここではこの意味での「マネージャー」です。

役職はピラミッド型組織の上下関係を表すものです。だから部長は課長より偉い。
しかし、役割は違います。役割が上下関係を表すことはありません。プログラマーの方がテスターより偉いなんてことはないわけです。
と思ってるんですが、給与体系がマネージャー＞SE＞プログラマー＞テスターで格差をつけるようになっている会社もあるみたいですね。給与ではないですが、SIerからの案件だと「SE単価」「PG単価」なんてのは普通にあったりします（もちろんSEの方が高い）。

役職と役割をごちゃ混ぜにしちゃダメですよね。
より良いチームにするには各々が与えられた役割としての責任をしっかりと全うする必要があります。そこに上下関係はありません。へぼいプログラムコードを書くプログラマーがいたらテスターはどやしつけに行って構いません。反対に、へぼいテスト計画しか立てられないテスターがいたらプログラマーはどやしつけに行くことになりますが。いや、別に喧嘩しろと言ってるわけじゃありませんけど（笑）
それに役割は固定的なものではありません。あるプロジェクトにはSEとして参加している人が別のプロジェクトにはプログラマーとして参加するといったこともあるでしょう。プロジェクトによって内容や性質も異なるでしょうから、適材適所（もしくは本人の希望）で役割を決めればそういうこともあるはずです。いろいろな役割を同時に掛け持ちすることだってあるかもしれません。

ディーバの場合

ディーバ には今ところ部長・課長といった役職はありません。今だけでなく今後も役職を設けるつもりはありません。
人数が少ないからというわけでなく、仮に会社が大きくなっても部長とか課長とかはいらないんじゃないかと思っています。ホラクラシー組織とかティール組織とかいうやつです。

もちろん役割はあります。
今のところ「あなたはマネージャーです」とかそういう風に役割を明確にしているわけではありませんが、今後必要があれば役割を明確にすることもあるかもしれません。
けど、明確にしたとしてもマネージャーとデベロッパーくらいかな。営業・経理・総務とかそういうのもありますが。
デベロッパーをSE・プログラマー・テスターといった風に細分化する必要はあまりないかな？プロジェクトの規模が大きくなってくるとそれなりには役割を細分化する必要は出てくると思いますがそれにしたって「設計だけしかしないSE」とかはありえないですからあまり細かく線引きする必要はないと思っています。

さて、部長や課長といった役職がないということはそういった意味での昇進はないということになります。
上述したように役割の違いでも上下関係や給与差は生まれません。
しかし、「すごい人」と「普通の人」といった差はあります。肩書としては「スペシャリスト」とかになるでしょうか。マネージメントのスペシャリストとか、デベロップメントのスペシャリストとか、いろいろな役割ごとのスペシャリストが考えられます。
まだ評価基準や給与体系などはできていませんがこういった部分で評価し給与差をつけていきたいと考えています。簡単に数値化できるものではないのですごく難しいんですけどね。

そしてどの道に進みたいかは基本的に本人の希望を尊重します。マネージメントに重きを置きたい人、デベロップメントを極めたい人、その他いろいろ、人それぞれだと思いますし、進みたくない道を無理強いしても何もいいことはないと思いますから。
もし「現状維持でこれ以上前に進むつもりはない」という人がいたとしたらそれはそれでその人の道ということになります。いろいろと思うところはありますが仕方ないとしか言えません。

ということで、ようやくタイトル回収です。
ディーバは、各々が行きたいと思うキャリアパスに向かって進んでもらい（もちろん途中で進路変更してもぜんぜんOK）、そしてその進みに応じてそれに見合う報酬が貰える、そういう組織であろうと思っています。

正直なところ、今のディーバはこのあたりが弱いです。社長が日々の作業に追われてるようだとこういうところが弱々のままでなかなか先に進めないと最近痛感しています。そもそも、私は「一生プログラマー」と思ってたような人なのでいまだにマネージメントのことが全然わかってないというのもあるんですが（最近はそういう書籍もいろいろ読んでますが本読んだだけでできるようになったら誰も苦労しないんですよね）。
弱いとわかっているところを弱いまま放置しておくわけにはいかないので、少しづつでも進んでいかなきゃですね。

プロ生勉強会 第53回＠GMOインターネット（大阪）に参加しました

青柳 @ShinichiAoyagi です。

2018/9/1に開催された プロ生勉強会 第53回＠GMOインターネット（大阪） に参加してきました。
プロ生勉強会に参加するのはずいぶん久しぶりです。

今回は、セッションスピーカーもさせてもらいました。
Azure Functionsを中心にサーバーレスがテーマです。
今のところ仕事ではサーバーレスでシステムを作るという機会はないんですが、いずれはこうなっていくのかもと思ってちょこちょこと調べていたものがベースになっています。なので、私も突っ込んだところはまだまだこれからです。
セッション冒頭で「サーバーレスをちょっとでもいいから使っている人は？」と聞いてみたら2～3名でした。やっぱり、実際にサーバーレスでやるというのはまだこれからという感じみたいです。
セッション資料は以下にあります。

（今までは SlideShare に置いていたんですが、今回の資料はなぜかエラーが出てSlideShareにアップロードできませんでした。なのでSpeakerDeckに入れました）。

ごく簡単にですが他のセッションについて。

Oculus Go

Oculus Goのアプリ開発をUnityでのデモを中心に紹介したセッション。
やっぱりものすごくおもしろそう。Unityは少し触ったことがある程度ですが、デモを見ているとやっぱりマジカルというか、簡単にいろんなことができるけどなにをどうすればいいのか直感的にはわからないというか、結局は慣れの問題なのかな？
休憩時間にOculus Goを試せさてもらいましたが（Oculus Goは初めて）、やっぱり楽しいなぁ。

Blazor 触ってみた

Blazorは私も今一番気にしている技術です。
ブラウザーでC#を実行するという技術ですがSilverlightのようにプラグインで実現するのではなく、WebAssemblyとしてマネージドコードを実行するランタイムを実装して動かすというものです。なので、WebAssemblyが動かせる今どきのブラウザーであれば何もしなくても動きます。
もともと「ブラウザーでマネージドコードを動かす」から始まったはずなのに、Ver 0.5ではブラウザー側では最小限のところだけ動かしてC#のコード部分はサーバーサイドで実行するという機能が実装されました（サーバーとブラウザー間はSignalRで通信します）。ほんとに一周回って来た感じで「なんだってー！」ですよ。まだまだ実験的なプロジェクトですが今後が楽しみです。
つか、早く実際に使いたい。

ツールで防衛 クリーンアーキテクチャ

クリーンアーキテクチャの概要と、クリーンアーキテクチャをしっかり守ると文字通りアーキテクチャはきれいになるけど、コード書く量増えて面倒だよね。なら、なるべくコードは自動生成しちゃいましょう。というお話。
クリーンアーキテクチャについては名前しかしらない程度だったので普通に勉強になりました。

Vue.js + Azure Functions + Azure AD でサーバーレスWebアプリを作る

私のセッションです。

ITシステムを支える「時刻」の仕組み

今とてもホットな時刻についての話。
なにげに知らないこともいろいろあっておもしろかったです。
もし、日本にサマータイムが導入されたらですが、それなりに影響を受けるシステムは多いでしょうね。特に過去や未来のデータを参照するシステムはUTCで持つだけじゃなくtz dataとかを使ってないとダメになります。「2018年まではサマータイムないけど、2019年からのN年間はサマータイムあり」みたいになるのでサマータイム情報を時系列で持っている必要があるわけです（それがtz data）。けど、今のWindowsや.NETにはtz dataのような仕組みはないんですよね（正確には.NETには仕組みはあるけどタイムゾーンのデータは自分で用意してセットアップする必要がある）。私が昔そういった処理が必要になったときはLinux用のtz dataのソースを持ってきてVisual StudioでビルドできるようにしてP/Invokeで.NETから呼び出してました。今ならどうするのがいいんだろ？

（LT）Desktop Bridgeでストアで公開する話

UWPではないアプリをDesktop Bridgeでパッケージングしてストアに公開する話。 Desktop Bridge自体は簡単だけど、審査に出すのにフルトラストが必要な理由を英語で説明したり、説明しても放置されて忘れた頃に審査通ったりしたそうです。
フルトラストの問題はde:code 2018とかでもマイクロソフトの新井さんが言っていました。問題と言うか、レガシーアプリはほとんどの場合はフルトラストがないとセットアップできないし、ストアでは可能な限りフルトラストは認めたくないので今のところどうしようもないってことでしょうね。

懇親会

楽しかった。
ベーマガ最終巻が出てきたり。けど、最終巻って2003年なんですね。私に取っては2003年ってつい最近だわ（笑）

懇親会二次会

さらに二次会。
楽しかった。けど、ロシアンたこ焼きはいくらなんでも辛すぎ（笑）

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 が発表されたらそろそろ買い換えてほしいですね🤔