こんにちは！エンジニアの両角(もろずみ)です。
2018年9月にLAPRASに入社し現在はクローラーの開発を担当しています。
この記事では私がLAPRASに入社するまでの経緯と入社してから感じたことについて書こうと思います。
2017年7月頃にLAPRAS SCOUT(当時の名称はscouty)を通して、LAPRASからスカウトメールが送られてきたことがきっかけで会社とサービスを知りました。当時全く転職を考えていなかったのですが、誰にも見られることはないと思っていた私の GitHub リポジトリについてメールの中で言及されていたり、LAPRAS SCOUTのサービスにも興味を持ったので一度技術的な話を聞いてみたいと思いカジュアル面談に応じて CEO の島田と話しました。
ちょうどその頃に前職でエンジニア採用を課題に感じており「Twitter のデータを解析することでエンジニアの候補者リストが作れるかも？」と考えてTwitterのデータからエンジニアかどうかを判定するプログラムを個人で作り始めていた時だったので、カジュアル面談でLAPRAS SCOUTのサービスについて詳細を聞くと自分が考えていたものと非常に近く「これだ！」と思いました。
面談の後すぐに前職にLAPRAS SCOUTを導入し、私自身がユーザーとしてしばらくスカウトメールの運用をしていたのです。
そこからはユーザーとしてLAPRASと関わることになり、LAPRASが主催するイベントにたまに参加したりSNS上でのゆるい繋がりが続いていました。その中でCTOの伊藤やその他のメンバーの方々と話したりSNSで発信される開発チームや組織に関する記事を通して面白そうな取り組みをしている会社だなと思い興味を持つようになっていきました。
そして転職活動を始めた時には、以前から興味を持っていたのもあり転職先の候補としてLAPRASも考え選考を受けることにしました。転職活動では昨今のエンジニアの超売り手市場のおかげで有難いことにLAPRASも含めていくつかの会社から内定を頂くことができ、正直どの会社に行くかとても迷いました。
いろいろと考えた結果、LAPRAS SCOUTはとても良いサービスだとユーザーの視点で感じていましたし、これまでに関わってきた中で経営層や社員の方と面識があったことや、経営や組織づくりへの姿勢と取り組みに魅力を感じ自分もその環境で働いてみたいと思ったことが決め手となりLAPRASへの入社に至りました。
入社してから感じたLAPRASの個人的にとても良いと思っている点を3つご紹介します。
LAPRASでは「ホラクラシー」という手法で組織運営をしています。
ホラクラシー組織では全ての職務がロールとして定義され、それぞれロールの目的・権限・責任範囲が明文化されます。ロールにアサインされた担当者はそこに記述された範囲の権限を持っているため、ロール外のメンバーは社長であってもその決定を覆すことができません。
これは一見すると単純なようですが、経営層がこれを徹底する覚悟を持ち運用されなければ実現できないことです。例えば役員であれば会社法上で決定権を持っているので、裏で話を進めて独断で決定するとかちゃぶ台返しをすることも十分に可能で正当な行為なわけです。しかしLAPRASでは自分たちで定義したルールの下での運用が徹底されており役員であっても例外はなくこれを守っているので、ルールを逸脱したルートで意思決定がされることがありません。
このような運用をするには経営層のコミットメントが大前提で、これによってルールを守り運用を徹底する空気が組織にできて全員がフラットに議論できる土台が生まれていると感じます。
ちなみに、ホラクラシー組織は階層のないフラットな組織という誤解がよくあるのですが、ホラクラシー組織では人ではなくロールによる階層が作られます。なので「〇〇部長が決めたから」ということにはならず「xxロールが決めたから」となります。そして属するサークルやその上位のサークルの目的を理解し自分がアサインされたロールの計画や目標を担当者が自ら考えて自発的に行動することが求められます。上から降ってきたものに対して受動的に対応するようなスタンスでは成り立たちません。
会社全体は前述の通りホラクラシーのプロセスに沿って運用されており、プロダクト開発はスクラムに沿って進められています。どちらもホラクラシーの専門家や認定スクラムマスターが社内に元からいたわけではなく、最初は自分たちで調べたり外部の方にアドバイスをもらいながら自社に取り入れています。
例えば最近では DDD (ドメイン駆動設計) によるソフトウェア設計を取り入れるために、DDDに詳しい外部のエンジニアにコンサルティングをしてもらいながら私たちも勉強し徐々にサービスのコードに実際に取り入れていっています。
LAPRASでは何か新しいプロセスを取り入れる際に中途半端に部分だけ導入したりいきなり自己流でやるのではなく、まずはあくまでもオリジナルの理論やプロセスに沿って忠実に運用してみるというのが自然に行われています。一定期間オリジナルに沿った運用をした上で、効率が悪い部分があれば自分たちの状況に合わせてカスタマイズするように常に改善が続けられています。
そしてこれはエンジニアだけでなく、研究、デザイン、マーケティング、営業、CS、PR、経営管理などLAPRASの全ての領域で行われています。
オリジナルの理論や研究成果を忠実に取り入れ研究している姿勢にLAPRASの研究者らしい探究心が表れていてとてもいいと思っています。
主体的に仕事をしていると小さなことを含めて判断することが日々いくつもあり、どうするべきか判断が難しい場面にぶち当たる時もあると思います。例えば、プログラムを書いていても「何て名前をつけるか」という問題に毎日ぶち当たっています。
そういう時には「そもそも何を達成したいのか？」という原点の問いに立ち返る必要があると思っていて、ミッションはこの問いに対する最も大きなレベルでの答えだと考えています。わかりやすく明快でいつでも簡単に立ち返ることができるミッションがあることはとても重要で効果があります。
それでも1つ1つの判断全てに誰も異議なく全員が一致するということはまず有り得ないですが、「世の中のミスマッチをなくす」という大目的のレベルでメンバー全員の目線が一致していると分かっているだけでとても大きな安心感があります。
LAPRASの良いところから色々と書きましたが、もちろん不足している所もまだまだたくさんあり様々な課題を抱えています。その中でも特に私自身がフォーカスしたいと思っている課題についてご紹介します。
有難いことにLAPRAS SCOUTを利用していただいているユーザー企業数は徐々に増加していますが、まだまだ無くてはならないレベルのものにまでは到達できておらず、世の中に大きなインパクトを与えられるほどの成果は出ていません。ユーザーが抱えている本当のニーズを明らかにしていき、それをダイレクトに満たすサービスを提供し続けていくことができるかが課題だと感じています。
私はエンジニアのロールとして仕事をしていますが、エンジニアは問題解決の具体的な手段を提供でき、どんな役割の人ともコラボレーションできる存在だと思っています。むしろそれをすることがエンジニアの存在価値だと考えています。
そんなエンジニアがビジネスに貢献するためには、社内の様々なロールのメンバーと頻繁に話してそれぞれの状況と考えを知り、今自分たちの組織やサービスがどんな課題を抱えているかを把握し解決策を一緒に考える必要があるはずです。そして最終的に解決されるべき課題を理解するためにユーザーと直接話すことが必要なのも明らかです。
例えば、CSの担当者はユーザーの痛みをよく知っていますし、営業やマーケティングの担当者はビジネスへのインパクトが大きい課題をよく知っていますし、管理部門の担当者であれば財務へのインパクトが大きい課題が何かをよくわかっています。そしてユーザーのニーズはユーザーを通して理解することができるはずです。(ユーザーはニーズを自分で言語化できない前提だとしても)
そしてそれらの課題を解決することによるインパクトと難易度はどれもバラバラで、インパクトが大きいが実は簡単な方法で解決できたり相対的に手間がかからずに解決できるものが必ずあると思っています。エンジニアは解決のための手段を提供でき、手段自体も新たに生み出すこともできるので、どんな課題でもそのような「コスパが良い課題」に変換できる可能性があります。そのような活動にエンジニアが注力できたとしたらレバレッジが効いて大きな成果に繋げることができるはずです。
LAPRASでは様々な情報が文書化されて社員であれば誰でもアクセスできるようになっていますし、全てのメンバーと対等に話せる空気があるので自分から情報を取りにいくことのハードルがとても低いです。そして必要と思えば自分からどのロールに入ることもリクエストできるので、エンジニアだとしても各自が取れる行動への制限はありません。
そしてLAPRASのエンジニア以外のロールのメンバーもそれぞれ専門性があり優秀で尊敬できる仲間ばかりです。そんな彼らと問題解決の手段を提供できる自分たちエンジニアが協力することで間違いなくビジネスの成果に貢献できると確信しているので、自分がその力になれるよう貢献していきます。
私たちは個人や企業がインターネット上に公開されている様々な情報を収集・分析し、それを利用したサービスを提供しています。
もちろん大前提としてサービスが適法な状態を維持し提供していますが、私たちのサービスに対して抵抗感を示されている方がいることも把握しており、これを大きな課題と認識しています。
LAPRASがこのサービスを開始した背景には、能力が高いにも関わらず単に仕事の機会を知らないというだけでその能力を十分に発揮できていない方が世の中には多くいて、そういった方々に新たな選択肢を提示し、知らないことにより起きているミスマッチを解消したいという思いがあります。
様々なお声を頂いている現実から目を背けずに、改めて自分たちが解決しようとしている問題と向き合い、サービスそのものやLAPRASから発信する情報を通して私たちの考えを1人でも多くの方々に理解して頂く努力を継続し続けることが必要だと考えています。
私のこの記事もそのために少しでも貢献できればと思い書いています。
ティール組織やホラクラシー組織がバズワードになっていることでLAPRASを知っていただいた方もいると思いますが、それがどれだけ効果的な手法だったとしても結果が伴わなければ結局私たち自身もただの一過性のバズとして終わってしまいます。
今はまだ組織のサイズが小さいことやメンバーそれぞれの意思に依存してなんとかなっている部分が大いにあり、それに頼り切ってしまうといつか大幅に失速する日が来るはずです。
それを乗り越えてビジネスの成果と人の成長を生み出し永続的に発展し続けるためには、LAPRASが解決すべき問題とそれぞれが向き合い、問題を解決するための行動を文化として定義し、文化をシステムとして組織に実装し常に改善と変革を続けることができるかが試されていると思っています。
短期的なビジネスの成果のみに注力すればもっと手早く結果が出る方法があるのかもしれませんが、 LAPRASはそのような手段は取らず自分たちの理念に沿った方法で勝負しており「悪貨は良貨を駆逐する」というグレシャムの法則に真っ向から立ち向かおうとしています。
理想の状態にはまだまだ程遠いですが、私自身そんな組織を実現したいと思いLAPRASに入社しましたしその実現に向けて貢献していきます。
この記事では私がLAPRASに入社するまでの経緯と入社して感じた点について書きました。
私がスカウトメールをもらった経緯を入社後に改めて聞いてみたところ、当時クローラーの開発ができるエンジニアを探していたようで、たまたま私が趣味で書いてGitHubに公開していたクローラーのコードや技術ブログの記事があったことでLAPRAS SCOUTの検索条件に引っかかりコンタクトしてくれたようでした。
そこから様々なご縁が繋がり、結果的に今はクローラー開発者としてLAPRASで仕事をしています。
今見れば当時書いたコードもブログの文章も拙く決してレベルが高い内容ではありませんが、自分がアウトプットを公開していたことに加えて「LAPRAS SCOUT」があったことで今の環境で仕事をする機会を得ることができました。
コードやブログなどのアウトプットがきっかけでスカウトをもらい転職するというのは今や一部のトップレベルのエンジニアだけの話ではなく、私のように平凡なエンジニアでもアウトプットが誰かの目にとまり、今まで知らなかった環境での仕事の機会を得るということがすでに日々当たり前のように起きています。
私がユーザーだった時にLAPRAS SCOUTを使わなければ見つけられなかったエンジニアの方を採用できた経験がありますし、今導入頂いている企業でのLAPRAS SCOUTを利用した採用成功事例も増えてきて、少しづつ確実にエンジニアの方々の人生に影響を与えていると実感しています。
まだまだプロダクトも組織も解決すべき課題が山のようにありますが、LAPRAS SCOUTに関わった全ての方々の人生に少しでも良いインパクトが与えられるようにこれからも日々精進していきます。
4月10日に個人向けページを公開し、LAPRASが収集・解析している自分のデータが見れるようになりました。ぜひみなさんアクセスして日々の活動の参考にしてみてください！
/assets/images/1698386/original/821abe46-7e4c-4e35-bbcc-c4f459678505?1680567510)
/assets/images/1698386/original/821abe46-7e4c-4e35-bbcc-c4f459678505?1680567510)
