デンキヤギの採用の考え方 2018-08-11版

このイベントに弊社も出てきた。いい機会なので、会社説明時に説明しているようなことを書いておく。

nagoya-career.connpass.com

発表資料

他社がキレイなスライドで発表している中、弊社は私がTwitterをしながら3時間ぐらいで新規で書き起こしたスライドを持っていった。

www.slideshare.net

発表資料の補足

フリータイム中に質問されたことを思い出しながら、補足していく。

想定する会社規模、求人自体の考え方

求人イベントに出ておいて言うのは何だが、現状は何が何でも人を採用したいという状況ではない。当然、社内ニーズや社風にマッチする人間が、会社の状況を理解したうえで入社してくれるというのであれば採用したいし、社員が10人ぐらいまでは増えてもいいかなという感じでも考えている。

受託開発が売上100%の状況のため、人員不足で案件受注を見送ってきた面もあるし、人員が増えればその分の営業・管理が大変になる面もあるので、人が増えれば単純に良いという考え方は持っていない。10人というのは、2-3チームぐらいが構成できる人数感で、もしこれ以上スケールさせるには管理職を増やさないといけないが、現状は社内に自分以外の適任が居ない。

とはいえ、自社開発が軌道に乗ったらと言うことが変わると思う。

キラキラを求める人はマッチしない

社員旅行やBBQなどの社内の一体感!みたいなイベントをする気は一切ない。社内行事としての飲み会は、人が増えたときの歓迎会をやる程度で、会社が全額費用を負担する。

技術者採用

現状の社内人員は技術好きな人で偏ってしまっている傾向があり、顧客と折衝できるタイプの人が限られてしまっている。理想を言えば、一人親方もしくは2-3人程度のチームで顧客と調整を行いながら技術もやる現場リーダー経験者、もしくはそれができそうな人が採用したい。

ただ、ある程度技術を抑えているうえで調整事ができる人間なんて存在自体が希少なことも理解しているので、最低限としてはチーム開発に興味がある、技術が好き、本意ではない技術選択をせざるを得ない状況でも仕事として淡々とこなせる人を求める事になる。いくら「この技術がやりたい!」と思っていようが、(ある程度は配慮はするが)その仕事が割り当たるとは限らないし、プロジェクト全体の最適解で技術選択を行ってそれに従ってもらうことになる。ここが割り切れない人は向いていないので他社をあたった方が良い。

また、会社サイトの取引実績にも書いてある取り、今回の求人イベントに出ていた来栖川電算さんなどと取引をしている。弊社に入って、いきなり来栖川電算さんの仕事をするというケースも普通に考えられる。もちろん、違う仕事も色々あるのだが、この辺りに違和感を感じてしまう人も、素直に他社をあたった方が良い。

総務採用

代表取締役の私が色々雑務をやりすぎなので、それをお任せするために雇いたい意思がある。電話応対、来客対応(宅配物受け取りと飛び込み営業への塩対応がほとんど)、売掛/買掛の管理、物理媒体を納品しなければならない場合の出荷作業、郵便物チェック、書類の郵送、社内の備品管理、福利厚生設備の導入計画(例えばコーヒーサーバーとか、どれを買ってどこに置くのとか)、日程調整、スポンサーイベントの運営準備、社内清掃(ルンバのメンテやゴミ出し程度)など、定型・非定型業務に関わらず多岐に渡る。

ただ、現状はフルタイムにするほどの仕事量がないのも事実なので、短時間正社員か、何か他の業務と兼務してくれると助かる。総務 兼 技術支援みたいな人が一番都合がよい。

給与水準

給与は、ベース給与+業績連動賞与という構成になっている。

今期の計画では、役職なしフルタイムプログラマー職の場合、ベース給与が各種手当込みの額面で年350-450万円ぐらい、業績連動賞与が年100万円以上ぐらいで設定している。ベース給与は確定で支給するが、業績連動賞与は業績が極端に悪い時は0円もありうるし、業績が計画よりも良ければ増えることになる。

給与としては低い訳でもないが、特段高い訳でもない。あくまでも目安額なので、採用条件によってはこれ以上出すこともあるだろうし、その逆もある。

人事評価制度の設計は非常に難しいのだが、デンキヤギの売上が受託に完全依存している関係上、各個人の受託単価(に各種事情の補正をかけた推定の市場価値)を基準に給与額を設定している。これが絶対的に正しいとは思っていないのだが、現状はこれがシンプルだろうという判断をしている。

短時間正社員

短時間正社員の勤務時間は、特に週何時間と決まっている訳ではなく、採用都度の相談となる。

ストックオプション

今のところ発行予定がない。受託が売上100%の状況でストックオプションとか訳がわからないので、給与(というか賞与)で還元する方針になっている。

将来的に自社サービスが流れに乗って、VCから資本調達して出口戦略がどうとかを考える状況が来た場合は、その時に改めて考える。

受託案件

いわゆるSI業界における多重下請け構造の案件は原則請けていない。基本的には、エンドユーザーと直接取引するプライム案件と、プライムベンダーと直接契約する技術支援系の案件が大半になっている。ただ、過去に全く無かったかというと、残念ながらそういうこともなく、どうしても営業タイミングが合わず繋ぎで請けたケースも僅かにある。

案件では、技術検証・プロトタイピング・新規事業立ち上げみたいなことに関わることが多い。これはデンキヤギの営業スタイルによるところが大きいと思われる。

代表取締役の私が、おもしろそうな会社に"遊び"に行って、ついでに「仕事がない?」かと聞いてくると、3社だか5社だかに1社ぐらいの割合で実際に仕事を出してくれる。ただ、仕事を出してくれる側も、取引実績もない会社にいきなり事業コアを任せるようなことはしてこない。いつかやろうと思っていたものや、技術検証してほしいみたいなものを、技量を測るにお試しで投げてくる事が多い。幸いなことに「思いの外いいやつが出てきた」と評価されることが多く、「じゃあこれを使って新規事業をやってみようか」というような流れで食わせてもらっている。

また、私が10年以上勉強会に出入りし続けている関係から、他社の技術キーマンの人と仲が良かったりするので、ありがたいことにバイネームで呼ばれることもある。また、他社では人手が足りずに請けきれなかった案件を丸々紹介してもらうこともある。

会社の規模が小さいので、成り立っている営業スタイルかもしれない。

自社開発

スライド動画配信をコア技術にしたサービスを開発している。スライドに音声とページ送りを記録して、動画として配信させることを、Webブラウザ単体で行うことができ、安価に使う事ができる。厳密には異なるのだが「音声付きで自動再生されるSlideShareみたいなやつ」といえばイメージできる人もいるかと思う。

元々は勉強会を簡単にネット配信するために作った技術である。カメラを買って、セッティングして、撮影して、ライブ配信して、後から編集してアップロードして、みたいなことを個人でやるのコストが高すぎてできねーだろという考え方から来ている。最近でこそYouTubeなどで高画質ライブ配信ができるようにはなったが、UStreamというものが現役だったころは折角ライブ配信しても「画質が悪すぎてスライドが読めねーぞクソ」という反応が多く、これでは配信側のモチベーションが続くわけがない状況だった。TV会議システムベースで簡単にWebinarができるというシステムも存在はするのだが、同時配信100人とかで考えると、とても個人が手を出せる価格帯ではない。

技術を作ったのはいいが、勉強会相手だけでは市場規模が小さすぎてビジネスとしては難しいだろうという判断があり、販売先を色々探してきた。だが、「動画はコストが高い」から「使ったことがない」ので「使う場面が想像できない」ため、要は文化がないという事がわかってきた。

なので、ここ最近腹を括ったこととしては、文化を創りにいく方針で進めることにした。正直、VCやらからは「実際に売ってから持ってこい」と全く見向きもされてないのだが、幸いなことに受託でそれなりに企業体力がついてきたことと、役員定額働きたい放題に毛が生えた程度で開発はできそうなので、その範囲でやっていく。

ここが許容できない人は他社をあたった方がよい。

技術

広義のWeb開発:Webフロントエンドからバックエンドまで

Haxe/JS, Scala(Scala.js), Javaを使ったWebシステム開発やWebフロントエンド開発が実績の大半を占める。複雑度の高いUI・ハイパフォーマンスが求められる開発対象でも、構造を破綻させずに作り切れる会社自体がなかなかないので、このあたりは技術的な強みとして言ってもよいかと思う。

昨今のニーズでビジュアライゼーション関係の開発にも関わることがある。サーバーサイドの設計構築を含め、大規模データセットでも破綻しないようにすることは得意としているが、社内にデザイナーが居ないため視覚的なところは強くない。ここは強化できるなら強化したいポイントではある。

サーバーサイドのランタイムはJVMやNode.jsを使う開発が多い。サーバーレス環境の開発が増えてきているので、Node.jsの比率が高まってきている。AWSとAzureは普通に使っているが、GCPは今のところ実績はない。

その他、AkkaやRabbitMQなどを使った分散システムの開発実績がある。Kafkaはタイミングが合わずに今のところ実績はない。ZooKeeperのような分散協調システムや、Cassandra, AWS DynamoDB, Azure Cosmos DB, Elasticsearchあたりの開発実績・知見もある。ErlangはちょっとだけRabbitMQやVerneMQのプラグインを書いた程度。

モバイルアプリ

モバイルアプリ開発は何故か今まで案件がマッチングしてこなかったため、会社としての開発実績がない。開発経験がある技術者も在籍しているので対応は可能だが、会社としてもあまり優先はしていないので、最新情報がキャッチアップできているわけではない。

.NET系技術

MS/.NET系の技術は私個人としては大好きなのだが、まともな案件が流れてくることが少なく、あまり実績がない。

機械学習

機械学習は積極的には手を出していない。機械学習のプロジェクトでWebフロントエンド開発を担当することはまぁまぁある。

開発言語

特に強いこだわりがある訳ではなく、技術選定では適切なものがあればそれを選択する。

プログラミング言語については、静的型付き言語が選択できる状況であれば、必ず選択するという考え方をしている。また、余程の理由がない限り、静的型付き言語が使えないプロジェクトは避ける方針で考えている。今のところ社内における第一公用語Scalaで、Haxeは全員がガリガリ書けるという訳ではない。