PrAha Inc.

PrAha Inc. のブログ、あるいは社員の観察日記

炎上しないプロジェクトの進め方

株式会社プラハ代表兼エンジニアの松原です。

 

いろんなWEBサービスを開発する中で「こうすればプロジェクトの炎上を防げるのでは?」と感じる行動や考え方が見えてきたので、それをチェックリスト化して社内で運用し始めました。

全ての開発現場が炎上から無縁になりますように。

 

https://www.notion.so/128a7aaa68434230bc5dfce322bd1811

採用弱者の採用方法(母集団形成編)

弊社(PrAha Inc.)は2018年10月にリクルート出身者5名で創業しました。

 

約2年の採用活動を経て、内定者を含めると現時点のメンバー数は10名。採用経路はこんな感じです:

 

・一人目:リファラル(社員による紹介)

・二人目:Twitter経由の応募

・三人目:Twitterスカウト

・四人目:Twitterスカウト

・五人目:Twitterスカウト

 

あと2名ほど選考中の方が居て、いずれも社員によるリファラルです。

 

採用の全てがリファラルもしくはTwitterという典型的なスタートアップ採用で、今回はそこに到るまでの変遷を「採用弱者の採用方法」としてまとめてみました。

 

 

世の中には採用強者と採用弱者が居る

採用強者とは「応募が簡単に集まる企業」です。海外でいえばGAFA、日本で言えばトヨタリクルート等の大手企業でしょうか。

 

採用弱者とは弊社のように「会社の存在自体が知られておらず、何もしなければ誰も応募してこない企業」です。

 

採用弱者が何に困るか。母集団形成です。応募してくれる人が居ないので、選考する相手が居ません。

 

求人サイトに掲載する

弊社は創業以来、常にエンジニアが不足していたので、まずは試しにベンチャー界隈で名の知れた求人サイトに掲載してみました。

 

当時の弊社の売りは「自由」であること。

 

出社時間が自由、有給自由、副業自由、出社は週1回のみなど、とにかく自由で楽しいことを前面に押し出しました。

 

合衆国の演説のように自由をアピールしまくった結果、サイト全体のランキング2位まで到達し、1年平均で400件近くの応募が集まりました。

 

2位じゃダメなんですか おお、求人サイト出稿イケるやん!」と思ったものの、蓋を開けてみると、447応募からの採用はインターンの学生が1名だけ。

 

他の媒体も試したものの、30名ほどの応募から採用は0名。

 

スカウトメールも試したものの、50通送って返信は5通程度、採用は0名。

 

蛇足ですが、履歴書に書いてもいないのに「Javaの経験を拝見して」とスカウトしてくる企業が僕は嫌いです。

逆の立場に立った時、自社が「あぁ、見境も分別もなくスカウトばらまいてる会社ね」と覚えられることだけは嫌だったので、スカウトメールは全てカスタマイズし、相手の情報に全てを目を通し、1通あたり30分から1時間近くかけて書き上げた魂のスカウトを送りました。

 

にも関わらず、開封も返信もない。

たまに返信をいただけても、当時の弊社は面接過程で業務委託契約を締結し、1ヶ月一緒に働いてから内定を出していたため、選考途中で他社に決まってしまう方が多々おりました。

 

これは流石に費用対効果が悪いと判断して、現在は媒体出稿は全て止めています。

 

 

求人媒体は需要過多のレッドオーシャン

求人媒体は「今の職場に不満がある人」しか登録しないので、そもそもの供給が少ない。

 

求人媒体に登録したユーザーは、その媒体に登録しているすべての企業からアプローチ可能、つまり欲しがる人が多い。

 

要は需給バランスの崩れたレッドオーシャンです。少ない登録者を多くの企業が奪い合うため、優秀な人ほど瞬時に転職市場から消えます

 

しかも僕らは採用弱者なので、採用強者と媒体上で横並びに比較されて選ばれる確率は低い。

 

「年収700万円」と「年収1000万円」を並べられたら1000万円の方がクリックされるし、「よく知らない会社」と「誰もが知っている会社」が並べられたら後者に注目が集まります。

 

「競争が加熱した市場に進出してはいけないんだぞ」と偉い人が言っていたように、競争が激しい場所(求人サイト)で採用弱者が戦うのは得策ではありません。

 

 

いかに転職潜在層にアプローチするか

求人サイトも人材紹介も使えないスタートアップは転職潜在層、つまり求人媒体に登録していないユーザにアプローチする手段を探す事になります。

 

手法は大きく分けて2つ:

・目立つ

・自社に合う人を自力で探して、声をかける

 

 

目立つパターンで真っ先に思い浮かぶのは面白法人カヤックみたいな、際立った採用手法や社内制度で目立つ方法です。

 

弊社も社内ブログを積極的に更新して、僕が土下座したり恥ずかしげもなく変顔を晒す事である程度のアクセスは集まったのですが

 

praha-inc.hatenablog.com

 

 

 

昨今は採用に限らずあらゆる企業が「目立つ」ことを至上命令として取り組んでいるため、企業主体のオウンドメディアやらインスタアカウントやら乱立していて、一人当たりの可処分時間や可処分感情の奪い合いが激化しています。

 

そんな競争に打ち勝って目立てるなら、そちらを事業にした方が良いと思います。

 

それにウケ狙いの人事制度や採用手法ばかり繰り返して、「良い人を採用する」ことが後回しになってしまうのも考えものです。

 

 

なので自社に合う人を自力で探す方向に弊社は舵を切りました。

 

 

 

自社に合う人とは

まずはこれを定義します。

弊社の場合は創業以来「モノ作りが好きな人」と決まっていたので、この一点に絞って探す事にしました。

 

WEBの世界は日進月歩のため、継続的に学習できる人、努力を努力と感じないぐらいモノ作りが好きなことが重要だと考えます。そうでなければ旧世代の技術に取り残されてしまい、生産性が落ちるからです。

 

では、ものづくりが好きな人をどうやって探すのか。弊社が注目したのはTwitterです。

 

 

Twitterは宝の山

技術的なハマりどころや新しく学んだことをTwitterにアウトプットしているエンジニアが多く、割とTwitterを眺めているだけで「お、この人エンジニアだ」と分かるので、僕はTwitterの住民と化しました。

 

2019年からTwitterを使い始めたものの、完全なSNSオンチのため最初は「リツイートってなんだ?」とか思いながら地道にツイートを続け

 

f:id:praha-inc:20200707091800p:plain

 

「この人はエンジニアっぽいな」と思ったらフォローする日々が続きました。1年半ほど経過したあたりで、Twitter経由で気軽に多くのエンジニアと繋がれるようになり

 

f:id:praha-inc:20200707092002p:plain

 

 

求人広告をツイートすると

 

f:id:praha-inc:20200707092053p:plain

 

5万PVほど集まるようになりました。普通の求人媒体に無名企業が140文字の求人広告を出稿した場合、無料で5万PVは間違いなく集まらないでしょう。

 

ちなみに七夕の日には短冊っぽい求人ツイートをしたり、色々と遊べて楽しいです。こんな求人、審査通りませんからね...

 

f:id:praha-inc:20200707093824p:plain

 

 

 

ちなみに今までで一番バズったこのツイート

 

 

 

なぜか560万PV集まりました

f:id:praha-inc:20200707092359p:plain

 

 

560万回も自社名が露出するなんて通常の媒体ではあり得ないので、Twitter国に移住して本当によかったなぁと思いました。「あぁ犬のオシッコの会社ね!」と覚えられる事に、果たして何の意味があるかは分かりませんが。

 

 

 

TwitterBOTを開発

地道にTwitterを眺めてエンジニアっぽい人を探す作業が辛くなってきたので「そろそろ自動化するか」と思い、週末にTwitterアプリを開発しました。

 

このアプリはTwitterAPIを使用して「特定の単語を多く呟くTwitterアカウントを集計してランキング化」するので、強いエンジニアが使いそうな言葉をよく使うTwitterアカウントの一覧が完成します。

 

 

 

あとはランキング上位からTwitterアカウントを覗き、過去のツイート、GitHubやQiitaを読み込み、自社に合いそうな方に声をかけることで、採用活動が効率化されました。

 

結果的に2期目以降の採用は全員がTwitter経由です。Twitterにいくらか払った方がいいかもしれません。

 

Twitterの良いところは、何と言っても過去ツイートです。「言葉は身の文」と言うように、ツイートの言葉尻や内容を読めば、批判が好きで攻撃的な方は一目で分かります。

 

マウンティングが好きな人が一人でも組織に入ると「マウンティングされる前にマウンティングする」負のサイクルが回るため、どれだけ技術的に優れていても、一緒に働きたくない人を組織に入れてはいけません。

 

その一次フィルタリングとして、ツイッターは良い材料だと考えています。 

 

 

GitHubの見方

正直、GitHubに関しては「土日に活動しているか」を重視していますが、レポジトリなどは参考程度に覗いているだけです。

 

エンジニアがPublicレポジトリに掲載するのは、基本的に遊びか実験的な内容だけ。非公開のPrivateレポジトリを見ない限りエンジニアの実力は測れません。そして普通のエンジニアはPrivateレポジトリの中身を社外に漏らすことはありません。

 

Publicレポジトリを見て実力を判断できるのは一部のOSSコミッターだけなので、OSSコミッターが欲しい場合を除き、GitHubは眺める程度に留めていますが、土日の活動履歴が活発なアカウントは業務時間外も研鑽を続けている証なので、加点要素として扱っています。土日もひたすら働かされている可能性もありますが...)

 

ちなみに弊社はエンジニア系の役員4名もこれを体現しており、土日は基本的に会社の仕事とは別に、個人開発や勉強をしています。

 

 

 

 

 

リファラルに関して思うこと

このように弊社ではTwitterを活用していますが、おそらく最良の採用経路はリファラです。社員の紹介を経由しているため、信頼できること、技術力が分かっていることは大きなアドバンテージです。

 

弊社は年間平均で4,5名リファラル経由の応募があります。

 

当然リファラルはどの企業も出来るわけではありません。「知り合いを勧めたい会社であること」が絶対条件です。

 

弊社は創業以来「ものづくりが好きな人にとって心地よい環境を作る」ことを目指しているため、

 

・一人当たり毎月10万円を自由に物作りに使える枠を用意する(ほぼ使われなかったため廃止。数多のラズパイやarduinoが引き出しに眠る)

・出社をなくす(通勤ラッシュが嫌いなメンバーが多いため)

・副業自由(作りたいものが多いため)

 

などなど、働きやすい環境作りに腐心してきました。

 

一部企業では「紹介経由で入社したら、紹介した社員にxx万円支給」などの制度がありますが、これは例えば「魅力度が100に到達した会社でリファラルが始まるとして、魅力度99の会社」が取り組むべき施策(最後の一押し)で、

 

魅力度が20の会社がマネても「仲間は・・・売れねぇ(ドンッ!)」みたいな話になります。

 

 

採用は実力主義に移行しつつある

ここ20年の採用は「マーケティング」や「ハッタリの勝負」だったように感じます。

 

どれだけ内情がひどくても、求人媒体にお金を出して綺麗な求人を載せて、キラキラ社員を前面に押し出せば、採用できる時代でした。

 

昨今はSNSの普及で個々の発信力が増したことで、嘘や、人事と現場の乖離は看破されやすくなり、ハッタリが効かない実力主義に戻りつつあるように感じます。

 

特にWEB業界は非常に狭い。めちゃくちゃ活発に情報共有が行われています。

 

働いて楽しくない会社に人を増やしても、それは目の粗いザルで砂を掬っているようなものです。退職者が悪評を広めるほど、ザルの目も広がります。

 

良い会社を作ることが一番の採用戦略

 

これが弊社の採用に関する基本方針です。

 

 

ちなみに僕が3年半ほど働いたリクルートは退職者を「卒業生」と呼んで快く送り出すなど、退職者との関係性の保ち方が素晴らしい会社です。

 

以前新卒向けのサービスを作っていた頃、よく大学生の就活相談に乗っていた時期があり、しょっちゅうリクルートを勧めました。本当に多くのことを学べる、良い会社だと思うので。

 

こうした「単純に良い会社だから採用が強い」パターンが今後は主流化していくのかなと想像しています。

 

僕たちが独立した時も、退職時に役員も含め多くの方々が「頑張れよ!」「困ったら相談しろよ!」と声をかけてくださり、なんて懐が深いんだろうと感動したことを覚えています。「同期5人で独立します」って言われたら、普通の会社は代表を八つ裂きにすると思います。

 

この会社が大きくなった時に「リクルートで多くのことを学びました」と言うことが一番の恩返しだと思い、日々勤しんでいます。

 

 

求人の4要素

僕は求人を作成するとき、4つの要素で競合と比較しています。

 

・ブランド
・給料

・仕事の面白さ
・福利厚生、勤務条件

 

 

ブランド

言うまでもなく、ブランドのある企業は強い。大抵の人は有名な会社で働きたいものです。自尊心をくすぐられます。

 

給料

これも重要な要素です。誰だって年収の高い会社で働きたいものです。

 

弊社エンジニアの年収レンジは540~721万円です。

 

弊社は全ての開発依頼をインバウンドか紹介で頂いているため営業がおらず、仕事を仲介する媒体なども利用したことがないため、中間コストがほとんどかかりません。

 

そのため設立2期目の会社にしては社員の給料を高く設定できていますが、それでも上場企業には劣ります。そこで張り合ってはいけません。

 

採用弱者は、「ブランド」と「給与」の欠点をいかに覆すかが勝負ではないでしょうか。

 

続く2要素が成否を分けます。

 

仕事の面白さ

どんなに有名な企業で給料が高くても、肝心の仕事内容が退屈だと魅力は弱まるでしょう。

 

「仕事の面白さ」は非常に主観的で切り口が様々なので、企業側で事前に定義しておくと良いでしょう。弊社が「仕事が面白い」と定義するのは以下のような状態です:


・新しい事を学び、活用できる

・切磋琢磨できる仲間が居る

・ものづくりの意欲に満ちた仲間が居る

・利用者に愛される、役立つモノを作れる

・友人のような関係性で、互いを尊敬し合いながら働ける

 

 

 

 

 

弊社は役員全員が週末も個人開発をしたり、社外でも創作活動に勤しんでいます。

 

DDDや設計原則など学ぶべきテーマを決めて、社内勉強会で毎週2時間ずつ集中的に学ぶ期間を2ヶ月ほど取ったり、顧客と合同で技術勉強会を開催したり、日々技能向上に時間を割いています。

 

設計周りのコードレビュー、テストなどをはじめソフトウェアの品質を重視して、良いものを作れる術を身につけられる組織を目指しています。

 

こうした環境を「面白い」と感じてくれる人が居れば、ブランドや給与面で劣っていても弊社を選んでくれる可能性があります。

 

もちろん、ここに面白みを感じない人も居るでしょう。お金を稼げることや、どでかいサービスを作れることを仕事の面白さと考える人も居るはずです。

 

こうした方に対しては今の弊社では給与やブランドを上回れないので、「来て欲しいけど、今は採用できない」ことを受け入れるしかありません。

 

 

ちなみに弊社は定期的に自社に関するアンケートをとってます:

 

f:id:praha-inc:20200707113445p:plain

 

f:id:praha-inc:20200707113605p:plain

 

 

勤務環境

遠方の優秀な人に選んでもらうため、弊社は創業以来リモートが基本で、コロナ騒動の前から出社は週1日でした。

 

弊社には内定者を含めて大阪在住の優秀なエンジニアが2名います。現在選考中の方も、大阪在住の方がいらっしゃいます。

 

いかにブランドがあり給与が高い企業でも、引っ越したくない人に引越しを強制しては、選んでいただけない事もあるでしょう。こうした方には、リモートで働ける弊社は選択肢に挙がるかもしれません。

 

出社をやめた経緯には「通勤時間が無駄」と考えたことも含まれています。

 

弊社は「ものづくりが好きな人」の会社です。通勤で毎日1時間近く無駄にするより、その時間をものづくりに充てたい。

 

「どういう人を採用したいのか」「採用したい人が魅力に感じる制度なのか」と、制度の枝葉末節にも一貫した意思を通わせることが採用弱者には重要だと感じます。

 

一方でリモート勤務により社員同士の仲間意識が薄れないよう、週に1度はリモートランチをしたり、定例を行ったり、月に1度の高級焼肉、半年に1度の社員旅行を通じて、一緒に働くことを楽しめる会社作りに取り組んでいます。

 

弊社としては「友人であり、一緒に働く仲間である」ぐらいの距離感で働きたいため、こうした環境を良しと感じる方であれば、ブランド・給与で劣る弊社を選んでくれるかもしれません。

 

 

 

まとめ

長々と書きましたが、まとめに入ります。

 

・企業には採用強者と採用弱者がいる

・求人サイトは採用弱者に適した採用手法ではない

・採用弱者が採れる手段は「目立つ」か「自社に合った人を探す」か

・自社に合った人を探す上で、弊社はTwitterを活用している

リファラルも有効だが、効果は自社の魅力に依存する

・採用は「ハッタリ勝負」から「実力勝負」に移行しつつある

・求人の魅力は4要素で分解して考える

・いかに「ブランド」と「給与」をひっくり返すかが、採用弱者の勝負どころ

 

 

 

そんな弊社は常にWEBエンジニアを募集しております。

面白そうな会社だと思った、仲間と切磋琢磨したい、焼肉が食べたい。

そんな風に感じてくれた方がいたら、ぜひご応募ください!!

www.praha-inc.com

 

また今回の記事には触れませんでしたが、最近はデザイナーの採用も始めております!!ご興味をお持ちいただいたデザイナーの方がいましたら、DMでご連絡ください!

 

Twitter

https://twitter.com/dowanna6

 

 

ソフトウェア発注の心得

この記事は、これからWEBサービスを作る予定があり、その開発を外注しようと考えている企業に向けて綴ります。

 

 

ソフトウェア開発は家を建てる作業に似ています。

 

どんな工務店でも家は建てるスキルは持っているはずです。なのでお金を払えば、あなたが依頼した通りの壁色や間取りで家を作ってくれるでしょう。引き渡しの段階で工務店の腕に差が出ることはほとんど無いはずです。

 

工務店の腕の差が現れるのは、引き渡しから数年後です。

 

雨漏りした。床が傾いた。家の間取りを変えようとしたら「この壁を抜いたら家が崩れます」と言われた。素人目には判断できない水面下の手抜きや低品質が時間をかけて表面化するものです。

 

しばらく時間が経ってから、何かトラブルが起きた時に初めて「あの工務店はダメだった」と分かることが多いのでは無いでしょうか。

 

 

ソフトウェア開発も似たようなものです。サービスをリリースしてから一定期間が経った後、もしくはトラブルが起きた時に、初めてエンジニアの腕の差が現れます。

 

・追加機能を頼んだら「それは仕様変更なので、改修に数ヶ月かかります」と言われた時

・開発に時間がかかる理由を聞いたら「コードが複雑になってきたので」と言われた時

・バグが多い理由を聞いたら「スピードを優先して、テストを一切書いてないので」と言われた時

 

などなど・・・

 

では、トラブルが起きる前にエンジニアの腕を見極めるにはどうすれば良いのでしょうか?これも家づくりに例えて説明してみます。

 

 

あなたは一戸建てを建てようと考えました。2つの工務店から提案があったとします。

A工務店は2000万円。B工務店は3000万円。

 

あなたは何の説明も聞かず、安いからと迷わずA工務店を選ぶでしょうか?

 

恐らくそんな事はしませんよね。家づくりに関して様々なことを調べた上で、各工務店の提案を吟味するはずです。

 

家屋の設計、工法、法律などの関連知識を身につけ、工務店の担当者と納得いくまで議論するはずです。

 

そんな時間をかけず、全てを工務店に丸投げする人もいるでしょう。欲しいものだけ伝えて「細かいことは君たち(工務店)に任せるよ!」と。

 

良い工務店であれば何も問題は起きないのでしょうが、悪い工務店だったら、おそらくカモにされるでしょう。基礎工事は手を抜かれ、無駄な設備をつけられ、可能な限りお金をむしり取られた上で、数年後に床が傾く欠陥住宅を引き渡されるかもしれません。

 

家の完成度は完全な運任せ、ということになります。

 

 

ソフトウェア開発も全く同じです。

 

発注側がデータ管理の仕組みやプログラミングの基礎的な知識を何一つ調べずに丸投げすれば、全ては運任せになります。良い開発会社に巡り会えればよし。悪い開発会社に当たってしまった場合・・・・言うまでもありませんね。

 

テストもろくに書かず、スキーマ設計も滅茶苦茶、負債だらけのサービスを納品されるかもしれません。私が知っている酷い例では、海外の安い受託会社にこっそり再委託して、自分たちは何もせず中抜きしている開発会社がありました。勿論バグだらけで話にならない出来だったそうです。

 

(ちなみにその開発会社は某案件仲介サイトで「星5をつけない限りは納品しない」と発注側を脅したそうです)

 

 

 

今すぐ発注側が自分たちの事業を止めてまでプログラミングを勉強しろ、とは言いません。プログラミングではなく自分の本業に専念したい気持ちは痛いほどわかります。

 

ですが自身の身を守るためには知識武装が重要です。

 

深く理解する必要はありませんが「自分はある程度の知識を持っている」と相手に伝わるだけの知識は備えて欲しいと考えています。

 

少しだけ自分なりに調べたことを開発会社に質問して、相手の反応を見るだけでも十分効果を発揮するでしょう。

 

「今回採用するアーキテクチャをホワイトボードに書きながら説明していただけませんか?」

「ER図を見ながら大まかにスキーマの考え方を説明していただけないでしょうか?」

「CI/CDの構築を予定している場合、軽く流れを教えていただけないでしょうか?」

 

ここで大事なのは、発注側が質問の回答を完全に理解する必要はない事です。

 

悪質な開発会社は「この人は開発について何も知らない」という無知の香りに集まるものです。「開発を少し理解している」と匂わせるだけで自然と離れていきます。

 

「トンチンカンなことを質問していたらどうしよう」

「答えられても理解出来ないから、聞いても仕方ないかな」

「しつこく聞いたら怒られないかな」

 

こんな心配はしないでください。

 

自分の専門について詳しく聞かれて気分を害する人は居ませんプロであれば知っていることはスラスラ答えるし、知らないことは素直に「わからないので調べます」と言う筈です。

 

発注側には金銭の対価として「質問する権利」も付随することを忘れず、どんどん質問してください。

 

(勿論、相手の作業に支障をきたすほどの質問はいけませんが・・・)

 

 

 

最低限の開発知識を身につけることには「悪い開発会社を遠ざける」以外にも「良い開発会社と円滑に働ける」効果があります。

 

どの開発会社と組んでも開発に失敗する発注者が稀に居ます。こうした発注者は例外なく全員が「開発に関して何も知らない」人でした。

 

ECサイトを作りたかったんだけど、やっぱりSNSにしよう!」と言われたら、どんな開発会社でもお手上げです。いかに優れた開発会社でも、明らかな無理難題には対応できません。

 

無理難題を押し付けた結果、せっかく巡り会えた良い開発会社から「もう付き合えません・・・」と言われてしまっては勿体無いですよね。こうした不幸を防ぐためにも、発注側が最低限の知識を持つことは必要だと感じます。

 

 

それでは発注側として最低限勉強しておくべき「ソフトウェアの知識」とは具体的にどのようなものなのでしょうか?

 

これ以上は話が長くなりそうなので、もしこの記事に多くの方が興味を持ってもらえるようであれば、詳しく説明したいと思います。

 

・少しでも多くの企業が良いエンジニアとつながる

・良いエンジニアが正当に評価される

・より多くのアイデアが形になる

 

この記事がこれらの一助となれば幸いです。

srcsetとsizesが理解できなかった人のために、日本一分かりやすく解説してみた

レスポンシブイメージとは

  • 画面幅や端末(パソコン、スマホなど)に応じて表示するイメージを切り替えること

 なぜ重要なのか

  • スマホみたいな小さな画面で表示する時に5000x2500みたいな巨大画像を送りつけてしまうと、意味もなく通信時間がかかり、ユーザが可哀想
  • 逆にスマホ用の小さな画像をPCで開くと、画像がボケる
  • なので表示端末に応じて画像を切り替える必要がある

 そのために何を理解する必要があるのか

  • HTML5でimgに追加されたsrcset属性, sizes属性
  • ブラウザがどうやって画像を選択しているのか
  • Retinaについて

凄まじく短いですが、今回の記事用にGitHubのレポジトリ作っときました

 早速実装してみよう

続きはコチラ...

https://qiita.com/dowanna6/items/b9e132b4c56e67491027

100日後にリファクタリングするVuex(Vuexの使い方を間違えた件)

PrAha Inc. CEO、時々エンジニアのdowannaです。

nuxt initしたら勝手に付いてくるため無意識に使いがちなVuexですが、本来の用途を理解せず使うと、ただ労力が増えるだけで、さほど意味のない構成になります。僕は見事にそれをやりました。そんな僕を反面教師に、Vuexとの正しい付き合い方を感じてもらえたら幸いです。

 この記事で伝えたいこと

Vuexは「複数のcomponentでstateを共有すること」が本来の意図されたユースケースで、stateをcomponent間で共有しない場合は、無理にvuexを使わなくても構わない

 

続きはこちら・・・

qiita.com

エンジニアの技術力をどう測定するか?

f:id:praha-inc:20191121095209p:plain

エンジニアの技術力をどう測定するか


初めまして、株式会社
プラハ代表取締役兼エンジニアの松原(dowanna)です。

 

今日は全てのIT企業が悩む「エンジニアの技術力とは何か」「技術力をどう測定するか」に関して自論をまとめてみます。

 

 

なぜ技術力を定義する必要があるか

社内のエンジニアの技術力をあげたい!と考えた時、まず技術力を測定可能な定義に落とし込まないと始まらない。近づいていることを判断できない目標は目標ではない。

 

 

技術力とは、価値を生み出すスピード

僕個人の考えを最初に伝えると、技術力とは価値を生み出すスピードだ。何かが出来る/出来ないとか、知識の有無とか、そういう物は関係ない。スピードだけを見ている。

 

同じ人間である以上、誰かに出来ることは(大半は)基本的に誰にでも出来る。例えば僕は家の作り方を知らないけど、今から仕事を全部放棄して調べ始めれば、5年くらいで作れるだろう。でも建築技術の高い職人なら、今から半年で同じものを作れるかもしれない。

 

家という価値を生み出すのにかかる「半年」と「5年」の時間差が、技術力の差だ。似たように、同じWEBサービスを作るのに30日かかるエンジニアと1日で終わるエンジニアが居たら、後者の方が技術力が30倍高いと定義する。

 

 

現在価値と将来価値

でも価値を測る時、現在価値だけで計算してはいけない。将来価値も加味する必要がある。

 

開発者の書いたコードは本番公開した瞬間に価値を生むのではなく、本番公開してから価値を生み始める。将来も価値を提供し続けられなければ、開発者のコードに意味はない。

 

WEBサービスは本番稼働中も継続的に開発することが大半だから、改修に時間がかかるようなコードを書くことは将来価値を損ねる事になる。

 

図にするとこんな感じで、

 

f:id:praha-inc:20191120125220p:plain

現在価値 x 将来価値=エンジニアが生み出した価値(青い面積)

 

という具合に考えている。

 

1日でサービスを開発したエンジニアが、仮に一行もテストをかかず、共通化もせず、設計もデタラメで、その後の改修に著しく手間のかかるコードを書いたとする。そのエンジニアが生み出した価値はこうなる。

 

f:id:praha-inc:20191120130429p:plain

 

赤エンジニアが作ったWEBサービスは今日この瞬間、仕様を満たして動いている。だから現在価値は高い。でも継続的な開発には耐えない作りで、少し改修すればバグを生み、膨大なテスト工数を要する負債だらけのシステムだとしたら、将来価値は著しく低い。

 

一方、30日かけたエンジニアはテストもちゃんと書き、CI/CD環境も構築し、設計にも時間をかけて、インフラもコードで管理してる。とすれば、こんな図形になるかもしれない。

 

f:id:praha-inc:20191120131542p:plain
用意に保守・開発できるモノを開発した青いエンジニアは、現在価値に加えて、高い将来価値も生み出している。青いエンジニアの方が優秀そうに見える。

 

しかし、話はここで終わらない。それぞれの価値を費やした時間で割ってみよう。

 

f:id:praha-inc:20191120131016p:plain

結局青のエンジニアは30日もかけたから、1時間あたりに生み出す価値を計算すると赤と大した差がない。むしろ1時間あたりに生み出す価値の合計は赤を下回るかもしれない。

 

時間をかければ誰だって将来価値の高いコードは書ける。それを早く書けなければ意味がない。

 

これがエンジニアの技術力の要旨だと思う。

 

・現在価値 x 将来価値=価値

・価値 / 時間^2 =技術力

 

現在価値は生むが将来価値はそこまで生まない赤エンジニアは、実務経験が乏しい若手エンジニア。

 

将来価値は生んでいるが時間をかけすぎる青エンジニアは、技術中心に考えすぎて自身の成果に無頓着な職人気質エンジニアと見立てていいかもしれない。

 

いずれのエンジニアも技術力は低いと僕は思う。

 

僕が一緒に働いていて「技術力が高いな」と思うのは、1日で青エンジニアの成果を出す人だ。将来も見据えながら普通のエンジニア以上のスピードで開発できる人こそ「技術力が高い」と感じる。

 

 

 

短期評価の落とし穴

一般的な企業は半年に一回程度で目標を定めて、その達成度合いで給料を決める。こうした企業で評価されるのは赤エンジニアだ。爆速で開発して、その場で成果が出れば賞賛される。ひどいコードの尻を拭うのは他人だ。その頃には赤エンジニアは出世して現場に居ない。

 

多くの企業は短期評価を繰り返すから負債だらけのシステムが出来上がる。気づいた頃には負債が大きすぎて返済できず、簡単な開発に何ヶ月もかけるようになる。モタモタしているうちにスタートアップが玉砕覚悟で似たサービスを高速開発・低価格で攻めて市場を奪う。こういう構図を何度も見た。

 

青エンジニアが評価される企業は、エンジニアリングに対する理解が深いと思う。余程のバランス感覚がなければ出来ない。「Aさんが10日かけた仕事をBさんは1日で終わらせました」と報告されたら、誰だってBを評価したくなる。そこをグッと我慢して中身を確認する手間を割き、理解出来るマネジメント層は稀有だ。

 

青エンジニアのスピードをジャッジ出来る人は更に珍しい。技術的難易度の高い作業を実施しているエンジニアが、速いのか遅いのか。それは同じ難易度の技術的課題を解決した人にしか判断できないからだ。

 

 

エンジニアはビジネスを理解するべきか

取捨選択すればいいと思う。「僕はフロント一本で食うのでインフラはやりません」と宣言するエンジニアと同じだ。全てを自分で出来る必要はない。

 

でもビジネス側の心理を理解すれば「おそらくこんな仕様変更があるはずだから、この辺りは汎用性を高く設計しておこう」と予見しておける。こうした予見は自分の身を守る。

 

「仕様変更が多すぎて辛いです」とぼやく人をたまに見たけれど、申し訳ないけど、そういった方はビジネス観点が無いことが多い。

 

「この人すごいな」と思うエンジニアは「自分はフロントエンジニアです」とか言いながら、大体サーバもインフラも問題なく書ける。ビジネスに関しても同じだと思う。普通のビジネスマンと同程度の知識と勘所を持っていればいい。

 

ただ一つ言えるのは、技術力を「価値(役に立つもの)を生むスピード」と定義する場合、役に立たないものを作ることは技術力を損ねる事になる。この定義に沿うのであればビジネスを理解する必要性は高い。

 

例えば緑色の線が、自分が作っているプロダクトの価値を表すとする。

f:id:praha-inc:20191120133148p:plain

 

僕の大前提として、開発者が生み出す価値がプロダクトそのものの価値を上回ることはない。

 

1+1を計算して描画するWEBサービスをいかにマイクロサービス化しようとSSRしようと、そのプロダクトの価値が低ければ、どれだけ技術の粋を集めようと生み出す価値は低い。

 

だから結果的にこうなる

f:id:praha-inc:20191120133334p:plain

価値のない物を作っても意味はない。価値が0なら、先述の公式を当てはめると技術力も0だ。分子が0なら何で割っても0だ。(厳密には0で割れば無限だけど)

 

もちろん、この説は少し乱暴だと自覚している。1+1サービスを作る過程で得られた知見は、いつか価値の高いサービスを作るときに役立つかもしれない。

 

でも「いつか」が来る保証はない。不確定の未来である以上、現在の価値に換算する時には割引率を考慮するべきだ。今100の価値を生んでいるエンジニアと、いつか100の価値を生むかもしれないエンジニアの価値は、同じではない。(割引率の考え方はこの辺りが参考になりそう)

 

実装力はあるのに、たまたま運悪く価値のないサービスを作らされたエンジニアも居るだろう。でも本来自分が生み出せる最大の価値を生み出していないのだから、技術力を発揮できていない状況には違いない。

 

だから僕は自社の社員には、自分が作るモノの価値を常に考えてほしいと思っている。価値を生み出せる商品を作らなければ、僕らの書くコードにも、デザイナーが描く作品にも価値は生まれない。心血を注ぐ対象を見極めることが、自分の技術力を最大限に証明し、最大限の報酬を勝ち取る近道になると思う。

 

自分さえ技術的に上達すれば何を作ろうと構わない。それはそれで一つの生き方だけど、技術の根本を見落としている気がする。

 

技術は人を幸せにしたり、生活を豊かにするためにある。人を幸せにも豊かにもしない技術に何の価値があるだろう。時間は有限なのだから、価値があるモノを作り、それを楽しむ人生を過ごして欲しいと思う。だから僕らは社内スローガンとして「誰かのために考えて、誰かのために作る」を設定している。誰を幸せにするのか考えずにモノを作るようになったら、それは技術ではなく遊びになってしまう。

 

もちろん遊びから始まったモノがいつか技術に昇華する例は多い。でもそれはやはり不確定な未来だから割引率を考えるべきだ。「目先の開発ばかりお金が集まって研究に予算が回らない。うちの組織は将来のことを考えていない」とぼやく研究者がたまに居るが、遠い将来の価値が低いのは割引率の概念を当てはめれば自明だ。

 

リファクタリングもこれに似ている。リファクタリングしても現在価値は変わらない。得られるのは将来価値だ。だからその価値を現在価値に置き直す時に割り引かれる。よほどメリットのあるリファクタリングでなければ、今すぐ価値を生む実装とは釣り合わない。

 

 

技術力をどう測定するか

現在価値は比較的容易い。issueにestimateをつけて消化数を累積したり、余裕があれば開発による売上連動を算出してもいい。

 

ただ売上のような複合的な指標を使うと、売上が伸びた時に雨後の筍のように「俺のおかげ俺のおかげ!!!」「いや俺!」「いや俺だ!」みたいな人が大量に現れて、アピールが上手い人が評価される会社になるので注意した方がいい。

 

将来価値の測定は凄く難しい。僕らも全く回答が見つかっていない。優れた実装によって将来浮く時間を予測しようにも、「雑な実装で開発していたら、本来はどれだけ時間がかかっていたか」が予測できない以上、コストカットでは測れない。

 

ここは定性評価を積み重ねて擬似的な定量評価にするしかないのかなと思う。エンジニア同士で高頻度に「この実装ヤベェ、イケてる。将来価値ぱねぇ」と思った瞬間を計測して、その集計を評価に使う。定性評価も、積み重ねれば十分な定量評価になる。

 

共通するのは、いずれの価値も非エンジニアには評価しづらいこと。非エンジニアが直接エンジニアを評価するのではなく、エンジニア同士の評価を正確に集計する仕組み作りに腐心したほうが良いと思う。そうしないとアピールが上手い人、現在価値しか生み出さない人が評価されてしまう。

 

 

 

 

たまには真面目なことも書いてみました。明日からはちゃんとギックリ腰の話とか茶番劇に戻ります!

 

 

 



 

 

人生に乱数を入れるデザイナー 〜Youは何しにプラハへ?〜

初めまして、株式会社プラハ代表取締役兼エンジニアの松原(dowanna)です。商標の限界に挑む「Youは何しにプラハへ?」シリーズでは、なぜ株式会社プラハに入社したのか、テレビ東京に怒られるまで社員一人一人に聞いて回ります。

 

今回の記事では、弊社のデザイナーでもあり紅一点、りかやんに話を聞いてみたいと思います。1週間ほど宮古島に滞在して働いていた時期だったので、今回のインタビューは宮古島からお届けします。

 

praha-inc.hatenablog.com

 

 

f:id:praha-inc:20191107152422j:plain

 

りかやん「よろしくお願いします」

 

松原「じゃあ早速だけど、どうしてりかやんはPrAha Inc.を共同創業したの?」

 

りかやん「松原さん。人生の豊かさって、なんだと思います?」

 

松原「えっ」

 

りかやん「なんだと思います?」

 

松原「(質問文に質問文で返された・・・ジョジョ好きなら絶対反応しちゃう・・・)じ、自分のしたことで誰かが喜んでくれた時、豊かな人生を過ごせているなぁと思います・・・!」

 

りかやん「私にとっては、選択肢の豊かさが人生の豊かさなんですよ」

 

松原「なるほど」

 

りかやん「人生の選択肢が多いことが豊かさに繋がる。そう思って、いつもの自分なら絶対に取らない選択肢を取ることを意識しているんです。

 

前職を選ぶ時もそうでした。工業系デザインを学んだので、周りはメーカー系のデザイナーになる人が多かったので、逆張りでIT系のリクルートを選びました」

 

松原「誕生日だけ生肉を食べるベジタリアンみたいなイメージだね!」

 

りかやん「変な例えを挟まなくて大丈夫です」

 

松原「ごめんなさい」

 

りかやん「日常生活でも、入ったことない店を選んだり、知らない道を選んでみたり。何かしら自分の人生に乱数を入れて、自分が歩いたことのない道を楽しんでいます

 

松原「僕たちは乱数だったんだね」

 

りかやん「乱数ですね」

 

f:id:praha-inc:20191107153356j:plain

「乱数だったのか〜」の図



松原「実際、プラハという乱数を入れてから人生は豊かになっている?」

 

りかやん「わかりません」

 

松原「えっ」

 

りかやん「その正解が分かるのは晩年じゃないですかね。選択自体は重要ではなくて、選択したあとにやり切ることが大事なんですよ」

 

松原「なるほど」

 

りかやん「組織に関しても同じで、多様性(乱数)が必要だと思うんです。例えばプラハには育児中の男性エンジニアが居るけど『子供がうつ伏せになっていることを検知するIoT機器が欲しい』と呟いてたので、育児中エンジニアならではの発想が今後自社サービスのアイデアになるかもしれない」

 

(子育てエンジニアのインタビューはコチラ)

praha-inc.hatenablog.com

 

 

f:id:praha-inc:20191107155227j:plain

一生懸命説明するデザイナーと、人文字でPを描こうとする代表

 

松原「逆に許容できない多様性はあるの?いくら多様性が欲しいからといっても、自動車のフロントガラスを割るのが趣味です!みたいな人は嫌だし・・・」

 

りかやん「惰性で働く人はいやですねー。今の会社をベーシックインカムだと思っている人とか・・・人のために何かを作りたい!という情熱は共通して持ちたいんですよね。情熱を持って、楽しく働いて、それでいて人間味がある会社であり続けたいです」

 

松原「人のために考えて作るというのはPrAha Inc.の社内スローガンにも設定しているけど、どういう人生経験を通じてその価値観が作られたの?」

 

りかやん「私は大学在学中にスコットランドグラスゴーに住んでいたんですけど」

 

f:id:praha-inc:20191107162828j:plain

キメるデザイナーと、PrAhaのhを人文字で描く代表

 

りかやん「グラスゴーはイギリスの中でも特に貧困層が多い地域なんです。参加していた半官半民のプロジェクトに参加では、リサーチを通してfuel porvety(燃料貧困=占める光熱費の割合が1/4以上を占めること)を課題として取り上げ、問題解決に取り組みました。

 

市民はそもそも貧困層生活に無頓着だったり、その問題が存在することを知らなかった。支援者・被支援者・市民・街・企業など様々な視点を1つのサービスにまとめ、市民を巻き込んだチャリティイベントをグラスゴー市役所に対して提案しました。ナイトランやチャリティクラウドファンディングなど、様々な活動を通じて光熱費と貧困に対する気づきを作ろうと工夫しました」

 

松原「楽しそう」

 

りかやん「そうしたプロジェクトを通じて、人々がまだ気づいていない問題を顕在化させるのもデザインの力だと気づきました。公共問題の多くは、そもそも問題が表面化していなかったり、複数の問題が複雑に絡み合いながら、社会に大きな悪影響を及ぼしていることが多い。そういう問題に興味を持ち続けてきたのが、人のために何かを作りたいと思う原体験かもしれません」

 

f:id:praha-inc:20191107162042j:plain

この辺がグラスゴーだとして・・・と、不要なボディランゲージで茶々を入れる

 

松原「じゃあ、いつかは公共問題に挑戦したいんだね」

 

りかやん「人生の長期目標で言えば、そうですね。短期間にはたくさんの手触り感あるサービス開発に関わりたいです」

 

松原「手触り感?」

 

りかやん「自分のコントロールが効く範囲の広いサービス、と言い換えてもいいかも。この小さな一分野だけ!という狭い範囲より、このサービスに今一番必要なんだったら、トイレ掃除でもやりまっせ!みたいな、共通認識を持ってなんでも取り組めるチームで働きたいです」

 

松原「なるほどー。週4日リモートで勤務しつつ週1日だけ集まる自由さと、スタートアップ特化の0->1受託開発と自社サービスを平行開発してチームとしてのまとまりも兼ね備えたプラハなら、申し分ない環境になりそうだね」

 

りかやん「唐突に宣伝臭さが漂いましたが、そうですね」

 

そんなりかやんの1日のスケジュール

7:30 起床。最近エスプレッソを淹れるのにはまってる
8:00 コーヒーを入れ直し、作業開始
12:00 ざっくりしたお昼ごはんを作って食べる
14:00 展示を見に出かける
17:00 帰宅して夜ご飯
18:00 作業再開
いい感じの時間か、きりのいいところで切り上げ。
ビールを飲みながらツイッターのネタを考えたり、個人制作をしたり、本を読んだり。

・12時前には寝る。

デザイナーたるものインプットを怠ってはいけない…という義務感と普通に趣味との半々な気持ちでよくデザインやアートの展示に行く

 

f:id:praha-inc:20191107161825j:plain

 

松原「何か最後に言い残すことはありますか?」

 

りかやん「ちょうど創業する直前に占いに行ったら『今年は大殺界。何をはじめてもうまく行かないから、転職も結婚もするな』と言われたんですよ」

 

松原「ほう」

 

りかやん「で、転職したらどうなるのかと聞いたら『まぁ大して続かないよ。もって5年だね』と言われたので、5年も続く会社なら創業してみようかなと

 

松原「時間の流れが違いすぎる。ITスタートアップあるあるだ。」

 

りかやん「大殺界ですが、今後もよろしくお願いいたします」

 

f:id:praha-inc:20191107163116j:plain

大殺界の人と関わらないよう、人文字はやめて大人しく見守る代表



=====================================================

 

株式会社プラハは「モノづくりが好きな人が、純粋にモノづくりを楽しめる環境を作る」ことを目的に設立しました。個人開発も活発で、ゴールデンウィークなどの長期休暇には社員がそれぞれ一人で一つずつ個人サービスを作って、アクセス数を競争します。

 

モノづくり以外の不純物を排除するため、人事制度も工夫しています。「社長の給料が一番低い」「社員の給料は一律同じ」「エンジニアは採用面接の時に社員全員とペアプロする」などなど。

 

現在はスタートアップに特化した受託開発や、エンジニアの信頼を可視化する自社サービスを開発中です。個人開発が大好きな人、宮古島で働きたい人、大殺界の人と会いたい人などなど。興味のある人は、ぜひオフィスに遊びにきてね!

 

www.wantedly.com