PrAha Inc.

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

なぜPrAha Challengeを作ったのか

こんばんは!

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

 

この度、自走できるITエンジニアを育成するオンラインブートキャンプ「PrAha Challenge」の提供を開始しました

 

prtimes.jp

 

 

今回は「なぜPrAha Challengeを作ろうと思ったのか」を書き残しておこうと思います。




ITエンジニアの成長は努力5割、環境5割

僕は個人的に、IT エンジニアの成長を決める要素は、個人の努力が5割、環境が5割だと考えています。

 

どれだけ毎日独学する人がいたとしても、独学は

 

・なかなか理解できず詰まる

・誤解する

・学ぶ価値の低い知識に時間を割いてしまう

 

などの理由から効率が低く、よほど学習能力の高い人でなければ必要な知識を短期間で習得できません。

 

逆にどれだけ恵まれた環境に身を置けても、自発的な努力をしない人がその恩恵を受けることはありません。せっかく指導を受けても、その内容を自分で復習したり、理解しようとしなければ、せっかくの環境が無駄になってしまいます。

 

どちらか片方では不十分で、努力する人が良い環境に身を置いた時に、人は最も効率的に成長できると考えています。

 

こうした考え方の背景には、私の個人的な経験もあります。私のエンジニアとしてのキャリアは「リクルートテクノロジーズ」という会社で始まりました。当時の環境が本当に優れていて、

 

・きちんと設計を考え抜いたコードを毎日見ながら働ける

・大半の作業が自動化されていて、コードを書くことに集中できる

単体テストが充実しているため、初学者でも安心してコードを書ける

・厳しく丁寧に指導してくれる先輩

・少しずつ今の自分にはできない課題に取り組ませてくれる上長

・学習意欲が高く、一緒に個人開発をしてくれた同期

 

などなど、エンジニアとして成長するために必要な要素が揃っている素晴らしい環境でした。

 

弊社(株式会社プラハ)も幸い学習意欲に満ちたメンバーが多く、輪読会、勉強会、ドメイン駆動設計のケーススタディなどが活発に行われています。実務においても日々メンバーと技術的な議論を交わすことを通じて、様々な知識を吸収できています。

 

こうして改めて自分のエンジニアとしての足跡を振り返ってみると、「良い環境で」努力を続けたからこそ、効率よく成長できたのだと感じています。もし環境が違えば、ここまで成長することはなかったかもしれません(勿論、まだまだ未熟な点ばかりですが)

環境は自由がきかない

ここまで成長には「良い環境」と「努力」が必要だと述べましたが、環境はなかなか自由がききません。

 

・全くコードレビューを受けられない

・テストを書く、設計を考える、リファクタリング、作業自動化など、質の高いサービスを作ろうとする文化がない

・モチベーション高く開発を学ぼうとする人が周りにいない

・難易度の低い仕事しか任されず、良い経験が積めない

 

こうした環境を抜けて、高い熱量を持った人たちと切磋琢磨できる環境を求めて弊社の採用面接を受けてくださる方がこれまで沢山いましたが、残念ながら弊社が求める技術経験を持たず「こんなテーマを学んでから、また面接しましょう!」と伝える事が多々ありました。

 

「恵まれた環境に身を置けない方が、効率的に技術を学ぶ手段は無いのか?」

「あえて転職という手段を取らなくても済むよう、良い環境を社外でも提供できないか?」

「転職という一歩を踏み出せないだけで、こうした不満を抱えている人は沢山いるのではないか?」

 

こう考えた末に、PrAha Challengeの設立を決意しました




PrAha Challengeが目指すもの

PrAha Challengeは上述の「良い環境」を社外で提供することを目的としています。

 

・熱量の高い仲間と教え合いながら、時には議論を通して理解を深める

・少しずつ難易度の高い課題に挑戦していく

・どうしても詰まってしまった時は経験豊富なメンターに相談できる

 

こうした取り組みを通じて学習を妨げる障害物を取り除き、 努力が成長に直結しやすいように支援して、質の高いサービスを開発できるエンジニアを増やしたいと考えています。




なぜ質の高いサービスを開発できるエンジニアを増やしたいのか

これまた個人的な話で恐縮ですが、プラハを立ち上げるに至った経緯をお話ししたいと思います。

 

エンジニアとして少しずつ開発経験を積んできた頃、起業した知人から「それなりに名の通った開発会社に数千万円出して開発を頼んだが、全くモノが出来上がらなかった。助けて欲しい」といった相談を何度も受けました。

 

また、これまで私が企画職として携わった新規事業においても、ちょっとしたエンハンスに何ヶ月もかかる、すぐに不具合が発生する、といった開発側の事情が仮説検証の足枷になり、事業が競争力を失っていく状況を何度も目の当たりにしました。

 

せっかく良いアイデアがあり、良いチームが揃い、資金を用意したのに、開発力の欠如が全てを台無しにしてしまう。こうした状況が一人の開発者として我慢なりませんでした。

 

もちろん開発は企画側との相性の問題があるため、一概に開発者のせいとは言い切れませんが

 

「質の高い技術者に巡り会えないことが、事業の足かせになっているのではないか?」 

「特に採用力がない新規事業やスタートアップほど、深刻な課題を抱えているのではないか?」

「新規事業に特化して質の高いサービスを作れる集団があれば、この課題を解決できるのではないか?」

 

こうした仮説を持ったのが株式会社プラハの創業理由の一つです。

 

一方、弊社でエンジニアを採用して受託開発することで少しずつ目的達成に近づけるものの、今のペースでは何年経っても根本的な解決には至りません。そこで自社の開発ノウハウをカリキュラムとして社外に提供する事で、所属を問わず幅広くエンジニアの開発能力の底上げに貢献する事を決意しました。

 

PrAha Challengeを通して開発能力を高めたエンジニアが新規事業の開発を担い、仮説検証を繰り返せる強靭なサービスを作る。こうした状態に少しでも近づけていけたら大変嬉しく思います。



 

もし興味をお持ちいただけたら、ぜひご応募ください!

praha-challenge.com

なぜ議論が大切なのか、そして効果的な議論の方法

どうも、PrAha. Inc CEOの松原です。

 

先日、社内向けに「なぜ議論が大切なのか」を明文化ところ、思った以上に好評だったため、内容をそのまま以下に転載します。

 

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

 

今回はチームとして働く上で避けて通れない「意見を主張してぶつけあう事」、つまり議論に関して考えていることを明文化してみます 。

 

アメリカ式の教育では何を教わるのか

僕は自己主張が非常に激しい方です。それは多分教育の影響が強いと考えています。

 

僕は幼稚園から高校までずっとアメリカンスクールに通い、意見を言わないことは失礼だと叩き込まれて育ちました。

 

授業が終わるまでに一度も自分の意見を主張しないと先生に呼び出されて怒られるし、数学の授業であっても「自分とは解法が違う人を見つけてどちらの解法が優れているか議論しなさい」とか、ディベートの部活も盛んだったし、とにかく議論することが生活の中心にある学校生活でした 。

 

アメリカ型の価値観では、自分の意見を述べないことには二つの解釈がなされます。

 

一つ目は 「この人は何も考えていない」
二つ目は「この人は失礼だ」

 

何も言わないということは何も考えていないということだ」と解釈されるので、日本のように「 何も言わない人も言わないなりに考えているはずだ」 とは考えてくれません。なので間違った意見をたくさん言う人よりも、意見を言わない人の方が低い評価を受けてしまいます。

 

また「何も意見がないと言うことは、相手の発言に無関心か、真剣に聞いてないからだ。なんて失礼なやつだ」とも解釈されます。

 

「意見を述べない人は低評価」
「自分の意見を述べることは礼儀」

 

こんな文化圏で育った僕にとって、自分の意見を述べることは呼吸と同じくらいの感覚で染み付いています。

 

なので僕の自己主張の強さに驚く人が居たとしたら、「こういう教育背景から作られた人格なんだな」と見てもらえたらちょうど良いのではないか、と思います。

 

意見を主張することは、「人の集まり」から「チーム」になるために最も重要

こうした背景に加えて、僕は意見を述べること、議論する事を「人の集まり」から「チーム」になる上で最重要だと考えています。

 

各々が自分の意見を主張する事なく、自分の仕事範囲に止まって黙々と作業するのはチームではなく「人の集まり」の状態です。烏合の衆とも言いますね。

 

そうではなく、各々が持ち寄った意見を全力でぶつけあう事で、より良いアイデアに育てていく。異なる視点を持ち合うことで、一人では気づけなかった問題に気付き、それらをまとめて解決する新しいアイデアを生み出していく。

 

こういう事を安心して出来るのがチームで、チームになるためには全力の議論が欠かせないと考えています。

 

チームの定義に関して僕は「タックマンモデル」を参考にしていますが、ここで説明すると長くなりすぎるので今回は割愛します。 興味のある人は是非こちらの入門書を読んでみてください 。


議論する上でとても大事な考え方

ただの人の集まりからチームになるために大事なのは、全力で自分の意見を主張してぶつけるのを(議論する事を)恐れないことです。この時、いくつかの考え方を大事にする必要があります。

 

・全力で自分の意見を主張する
・意見の否定を、人格の否定と切り離す
・個人的に攻撃しない
・行動を提案すること


全力で自分の意見を主張する

周りから見ると僕は「何が何でも自分の意見を通そうとする人 」に見えるかもしれません。

 

その通りです。僕は意見を言う時は、全力で自分の意見を通そうとするのが礼儀だと考えています。

 

「どちらでもいいんだけど」とか「あんま考えてないジャストアイデアなんだけど」みたいな予防線を張ってから自分の意見を言う人が日本には多い気がしますが、これと同じ事を僕の母校で続けると 「じゃあ言わなくていいよ。ここは真剣に意見を言う場だから」と止められます。

 

”Say what you mean”って言われます。直訳で「本心を言ってよ」ですが「本気で言いたいことを言ってよ」「本気になれよ!もっと熱くなれよ!(CV:松岡修造)」みたいな意味でも使われます。

 

スポーツだって同じですよね。本気で練習した方が効果は高いはずです。全員が本気で練習している中に一人だけ本気じゃない人が混じったら、怒られますよね。

 

全員が全力で自分の意見を通そうとするからこそ、議論が白熱して新しいアイデアが生まれる。

だから意見を主張する時は、全力で意見を通そうとすることに躊躇しないでください 。健全なエゴを持つことを恥じる必要はありせん。

 

ただし議論が終わったら、後腐れなしです。


ドイツで働いてた頃、 会議で大声を張り上げて相手の意見を否定していた人同士が、翌朝には仲良くコーヒー飲みながら談笑している姿を何度も見ました 。河川敷で殴り合った後に仲良くなる不良に近い感覚なのでしょうか。

 

「全力で議論するけれども尾を引かない」

 

どうすればこんな事ができるのでしょうか?次のポイントで解説します


意見の否定を、人格の否定と切り離す

人との衝突を避けたいがために議論そのものを避けている人が日本には多いように感じます。これは議論の場数を踏んでいないから起きる「あること」が原因です。

 

それは、意見を否定されるのに慣れていないことです。

 

日本人は圧倒的に意見を否定される経験が少ない。

逆にアメリカ人は意見を否定される経験が豊富です。

僕が12年の学校教育で意見を否定された回数なんて数え切れません。

 

議論を通じて意見を否定される経験を積み重ねていくと、 否定されるたびに心底へこんでいては心がもたないので

 

「意見を否定されただけで個人の人格を否定されたわけではないさ」

 

と気楽に捉えて議論に挑めるようになります。

 

日本では、自分の意見を否定されると怒る(もしくは悲しむ)人をよく見かけます。
これは意見の否定と人格の否定を切り分けられていない人の防御反応だと思います。
確かにこういう人が周りに多いと、自分の意見を言いづらくなりますよね。

 

だからまずは、自分の意見が否定された時に、自分個人が否定されたと思わないように心がけてください。そうして意見を否定されることに慣れてください。意見を否定されることに慣れてくれば、主張するのも楽になるはずです。

 

PrAha Inc.は本当に人の良い社員がそろっているので「相手の意見を否定したら傷つくのではないか」 と遠慮してしまう気持ちは理解できます。だからこそ 「自分は特殊な訓練を受けているので否定されても特に傷つきません」 と言える人が増えてくれば、 より議論しやすくなるのではないでしょうか 。

 

もしどうしても誰かの意見を否定することに不安があればまず僕の意見を否定してください。僕は特殊な訓練(?)を受けているので、 意見を否定されることに抵抗はありません 。

 

ただし前述の通り、全力で意見を主張することが議論の礼儀だと考えているので、おかしいと思った事には全力で反論して、僕の意見を通そうとします。そしたら、あなたも自分の意見を全力で通そうとしてください 。そうして議論を楽しんでいきましょう。

 

議論は相手を打ち負かすためにあるのではありません。自分一人では気づけなかったことに気づき、 より良いものを生み出すのが議論の目的です。意見を否定された時は「その否定意見も併せて解決する方法はないか」と考えるチャンスと捉えて、新しいアイデアを考える方が楽しいのではないでしょうか。

 

議論も「ものづくり」の一環です。一人では生まれなかったアイデアを生み出して、その誕生を一緒に楽しんでいきましょう。


個人攻撃をしない

全力で議論することに慣れてくると一度は発生するのが個人攻撃です。

 

議論が白熱してくると「 どうして理解できないんだ、頭悪いな! 」とか「この間失敗したくせに何偉そうなことを言っているんだ」とか、相手を傷つけるために言葉を使う瞬間が出てくるかもしれません。

 

(逆にこんな事を言いかけた事が一度もなければ、それはまだ本気で議論していない証拠かもしれません)

 

相手の意見ではなく相手そのものを否定したり、「君の話だから聞かない」みたいな相手に合わせた議論をし始めると、 議論の前提にある信頼関係が崩れます。これが「 心理的安全性 」が欠けている状態ですね 。

 

これだけはしないように注意しましょう。

一度でも個人攻撃をすると信頼が失われて、 その信頼は長い時間をかけないと取り戻せないと考えてください。


行動を提案する

日本の会社で議論する人を眺めていると 「行動を提案していない 」人をよく見かけます。

 

例えば「新商品を作ろう」と誰かが提案した時に「こんなリスクがあるぞ」と指摘されて、喧々諤々の話し合いが始まったとしましょう。

 

僕はこれを「議論」だとは考えていません。

 

議論はお互いに「こうすべきだ」と行動を主張し合うことが原則です。
片方が行動を主張して、もう片方がその問題点を指摘しているのは議論ではありません。質疑応答です。

 

もし問題を指摘した方が「今は既存商品にリソースを集中しよう」と行動まで言い切っていたなら、議論が成立していると思います。もしくは「何もしない」事を主張するのも、有効な行動提案です。

 

でも実は質疑応答をしているだけなのに、自分は議論をしていると勘違いしてしまうのは不健全です。これまた母校の話ですが、質問ばかりしている人は「で、あなたの意見は?」と聞かれます。

 

ラクラシーの議論も、質問と反対フェーズに別れていますよね。あれはすごく明確にアメリカ式の討論のフォーマットに則っているなぁ、と思いました。

 

相手の主張を理解するために質問することは非常に重要です。でも意見を言うことを忘れて、質問だけで終わらないように気をつけてください。


まとめ

以上が僕の議論に対する考え方です。

 

・僕は議論をする事が当然の環境で育った

・だから僕の主張の強さに驚くことがあったら、そういう環境で育ったからなんだなと考えてもらえたらちょうどいいかもしれない

・議論は、「人の集まり」から「チーム」になる上で最も重要

・議論をするためには4つの考え方が大事

 ・全力で主張する事

 ・意見の否定を人格の否定と切り離す

 ・個人攻撃をしない

 ・行動を提案する

 

PrAha Inc.が日本で最も活発に議論が交わされるチームになってくれたら嬉しいです。

プラハは社員に対してどんな前提を持っているのか

どうも、株式会社プラハCEOの松原です。

 

今回はプラハが自社社員に対してどんな前提に成り立っているか、まとめてみます。(社内向けに発信したメッセージをこちらに転記してます)

 

内定者を含めると16名を迎えたプラハでは、2ヶ月ほど前から全社的にホラクラシーを取り入れ始めました。

ティール組織の一つとして挙げられるホラクラシーは、一般的な組織構造とは様々な前提条件が異なるため、その前提を事前に共有しておくことが大切だと考え、ここに明文化します。(内容の大半は書籍「ティール組織」から拝借しています)

 

 

ヒエラルキー組織の前提

一般的なヒエラルキー組織(管理職がいて、社員は何をするにしても上長の許可が必要な組織)は、以下のような前提に成り立っています。

 

社員は子供である。 子供が親の保護を必要としているのと全く同じように、社員は保護を必要としている

 ・例:重大な決断を行う際にはヒエラルキーのトップを通す必要がある。そうしないとアホな判断をしてしまう

 

・社員は怠け者なので見張られていないと勤勉に働かない

 ・例:労働時間の管理とか、オフィスが必要とか

 

・ 社員はお金を得るためだけに働く。自分がなるべくたくさんのお金を稼ぐために必要なことをする

 ・例:本業をサボって副業や個人の仕事をする、会社のお金を着服する

 

・ 社員は組織にとって何がベストかよりも自分の利益を優先させる。社員は自分さえよければ良いと思っている

 ・例:会社の誰かが困っていようと、自分に直接の関係がなければ放置する

 

・ 社員は会社の業績に影響を及ぼすような責任が重い仕事をしたがらない

 ・例:エンジニアなら開発に関することだけ、デザイナーならデザインに関することだけ考えたいはずだ

 

・ 社員は何をいつどうするべきか、命令される必要がある



プラハの前提

一方でプラハは自社の社員に対してこんな前提に成り立っています:

 

プラハの社員は信頼に足る大人である。創造的で思慮深く、重要な意思決定を下す能力を持っている

 

プラハの社員は管理しなくても、仕事をサボらない。自分の責任を全力で全うしようとする

 

・ 自分の判断と行動に対する説明義務を果たし責任を取れる

 

・何か必要なことがあれば、誰かが助けてくれるのを待つのではなく、自発的に解決できる

 

・失敗しても構わない。最も悪いのは失敗することではなく、何もしないこと

 

・自分たちの才能と技術と想像力を使って会社と世界に貢献したいと考えている

 

・お金以上に大切にしているものがある



なのでプラハには統制のためのルールがほとんどありません。

 

・まずオフィスがありません。物理的に労働時間や勤務態度を相互監視しなくても、プラハの社員は自分で判断して、責任を全うする人だと信じています。

 

・休暇日の上限もありません。仕事に支障のない範囲を自分で見極めて休みを取れる人だと信じています。

 

・ホラクラシーに基づいているため、意思決定の際に上長の判断を仰ぐ必要はありません。自分が責任を持ったロールである限り、自分で判断して物事を進めてもらって構いません。

 

・受託開発の案件の継続可否、人員の追加や離任などは現場の方が決定権を持っています。社員が「案件の継続をしない」と判断したら、代表の僕であっても、その判断に従います。



要は、統制するか、信頼するかの違いだと考えています。

 

統制があるのは社員に対する信頼が無いから。

統制が無いのは社員に対する信頼があるから。

 

プラハが統制しない(ルールが殆ど無い)のは、社員を信頼に足る大人だとする前提があるからです。

 

「これはダメ、これはOK」と手取り足取り子供のように教える必要はなく、プラハの社員は自主的に判断して物事を考えられるという土台に組織が成り立っています。

 

この前提を保ったまま、心地よい会社を作って行けたら嬉しいです。

なぜPrAha Inc.のエンジニアは設計を学ぶのか

こんにちは!株式会社プラハCEOの松原です。

 

PrAha Inc.では日々「エンジニアの設計力の強化」に取り組んでいます。

 

今年の冬には2ヶ月ほど毎週2時間近くかけてDDDにまつわる質疑応答会を実施したり、設計に関する技術書籍の輪読会を行ったり、3人ずつの小さなグループに別れて全社員でモデリングに取り組んだり...

 

 

 

なぜPrAha Inc.では設計を学ぶのでしょうか?

 

設計を学ぶ事は無駄にならない

WEBサービスを作る時にiOSアプリを開発する知識は不要だし、pythonで書かれたAPIを作る時にGo言語の知識は不要だし、バックエンドを全てlambdaで作成するならオンプレミスサーバの構築に関する知識は(一部を除いて)不要です。

 

作るサービス次第では、自分の保持している知識が無駄になる可能性があります。せっかく学ぶなら、何を作るにしても使える知識を習得したいものです。

 

それがソフトウェア設計です。

 

凝集度、結合度、デメテルの法則、SOLID、VIPER、クリーンアーキテクチャ、DDD、アトミックデザインに基づいた設計...

 

「変更しやすいコードを書く技術」は何を作る上でも役に立ちます。

 

今後AR/VRやDappsや未知の技術が現れたとしても、そこにソフトウェアが関わる以上、設計に関する知識が無駄になる事はありません。

 

「絶対に無駄にならないことから勉強した方が効率的だよね」と考えた末に、設計を学ぶことに決めました。

 

設計は、失敗した時の影響が大きい

ファットコントローラをリファクタした経験はありますか?

ビジネスロジックを大量に含んだフロントエンドを改修した経験は?

nullによる虫喰いだらけのDBをメンテナンスした経験は?

テストすら書けないコードを変更した経験は?

 

1つでも当てはまるなら、地獄を見たはずです。

 

初期段階の設計に失敗し、ゴミの上にゴミを重ねたコードを渡されたら、どれだけ優秀なエンジニアでも品質を維持するのは困難でしょう。

 

枝葉末節の実装に関するミスは簡単に直せます。

設計のミスは簡単には直せません。

 

だからこそ影響が大きい設計を学ぶべきだと考えました。

 

 

枝葉末節の技術は、どんどん自動化されていく

「コードを書くコード」はどんどん増えるでしょう。

 

bubble などのnocodeをはじめ、JS版のRailsライクなnest.jsfeathersjsOpenAIによるコード自動生成など、「人がコードを書く機会」は今後どんどん減っていくと考えています。ここまでの品質でなくても、ボイラープレートを自動生成するぐらいなら、僕のような何ちゃってエンジニアでも3時間程度でnpmパッケージとして公開できます。

 

自動化が進むと、例えば自分で最高のソートアルゴリズムを考えなくても、既に汎用化された最高のソートアルゴリズムが自動化に組み込まれていれば済むので、機械に近い低レイヤーの知識ほど習得する必要は薄れていくと考えます。

(勿論ソートがサービスの基幹であれば時間をかけて考えるべきですし、レガシーサービス、超大規模なサービスに関わる方々には必要な知識であり続けると思います)

 

機械に近い仕事ほど早く失われるとしたら、機械から最も遠いITエンジニアの仕事領域はどこか?と問われれば、それは設計です。

 

どんなツールをどう組み合わせてアイデアを形にするのか考える事。これがITエンジニアに残される最後の仕事ではないでしょうか。

(頑なに進化を拒むITサービスが時代の流れに抗い続けることで機械に近い仕事も残るとは思いますが、そうした不健全な生き残りについてはここでは言及しない...)

 

ヒトと機械のインターフェースが残る

より広義に捉えると、ヒトの世界と機械の世界のインターフェースが最後に残ると考えています。

 

盛んに騒がれる機械学習も大量の綺麗なデータが無ければ本領を発揮できませんが(最近はそうでも無いかもしれません?)「大量の綺麗なデータ」ほど現実世界で得難いモノも無い気がします。

 

機械は例外や汚れに弱い世界で生きています。複雑な現実世界をどうやって潔癖な機械の世界に落とし込むか。そこはITエンジニアの力量が問われる分野として残り続けると思います。

 

僕はITエンジニアの仕事が大好きです。コードを書くのは楽しいし、どう作るか考えるのも楽しい。この仕事を出来る限り続けたいと考えています。だからこそ、エンジニアであり続けるために必要な事(設計)から優先的に学びたいと考えています。

 

設計は、全員で学ぶ

少し細かい話に戻ると、設計は「全エンジニア」で「同時に」学ばないと効果が薄いと考えています。

 

例えば会社に1人だけ設計を意識しているエンジニアがいて、他の10人が一切設計のことは考えず、自由にコードを書く会社があったとしましょう。設計をきちんと考える1人のエンジニアはどうするでしょうか?多分、退職すると思います。

 

設計をきちんと意識する人にとって、設計に対する意識が低い相手と議論するほど消耗する事はありません。きちんと整理整頓する人の部屋に、汚部屋の主が引っ越してきて、家を荒らし回るような状況です。相当なストレスです。

 

かといって汚部屋の主を放置すると汚コードが量産されてしまうので、コードレビューで食い止めようとするかもしれません。

 

しかしコードレビューで設計を担保しようとすると、一人に注意した内容を何度も別の人に指摘する羽目になるため推奨しません。コードレビューは「明らかなミスがない事」などの確認に留めるべきで、設計の議論をする場としては非効率です。

 

最も効率的なのは全員で同時に学ぶ事です。一度認識が揃ってしまえば「どこにコードを書くべきか」という時間を取りやすい指摘事項が減らせるので、チームの開発効率も格段に上がります。ファイル名やディレクトリを見た瞬間に「多分こんなことが書いてあるんだろうな」と想像できる世界は幸せです。

 

それに、一人で学ぶより大勢で学んだ方が楽しいですしね。

 

 

まとめ

 

質問:

なぜ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にしよう!」と言われたら、どんな開発会社でもお手上げです。いかに優れた開発会社でも、明らかな無理難題には対応できません。

 

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

 

 

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

 

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

 

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

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

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

 

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