ユニラボの魅力を人の面から探る公式連載、「ユニラボメンバー紹介」。今回は、エンジニアの二村敦司さんの自己紹介です。

・・・

こんにちは、ユニラボエンジニアの二村敦司です。

エンジニアとして開発を行いながら、採用担当として、入社を希望されるエンジニアさんともお会いしてお話をさせていただいています。

私がユニラボに惹かれた理由は、”受発注を変革するインフラを作る”という明確な課題にワクワク感を感じられたからです。

これはユニラボのエンジニアに共通することではあるんですが、やはりただ開発をするのではなくその先の大きな目標に向かって頑張りたい、という人が多いんですよね。

私自身も、その場限りでなく長くずっと使っていくサービスを大切に作っていきたい、という思いがあったので、ユニラボのビジョンに惹かれました。

世の中に役立つサービスを作りたい

大学では情報社会学を学び、情報社会化がこのまま進むと、私たちの生活はどのように変容するのかなどを勉強していました。

就職先は、時代の流れを肌で感じたいと考え、東京のITベンチャー企業に決めました。その会社はSEOなどWeb集客業務をメインとしており、私はSEOの内部指示書を作成したり、リスティング広告の運用、アクセス解析など、誰も教えてくれる人がいない中で、独学で書籍を読んだりなどして、必死にキャッチアップする日々でした。

がむしゃらにやってきたものの、Webについて根本的な理解ができていない自分に非常にもどかしさを感じていました。そこで、Webサイトがどのような仕組みで動いているのかを理解し、自分の幅を広げたいと考え、プログラマーへの転身を決意しました。

半年間専門学校でWebプログラミング全般を勉強した後、SIer企業への就職が決まりました。これで自分も、当時流行っていたTwitterなどのような世の中に役立つサービスが作れるようになったんだと、だいぶ浮き足立っていた思い出があります。

マネジメントへの挑戦

無事に某Webサービス運営企業への常駐が決定し、最初はテスト業務から入り、その後開発業務にアサインされました。専門学校で身につけてきた知識は全く通用せず、毎日上司に詰められながらも、必死に食らいついていました。三年ほど経ち、現場にも業務にもかなり慣れてきた時、自分の中でこのままで良いのかと疑問に感じることが多くなってきました。

客先常駐というスタイルのため、自社への帰属意識を持つことができませんでした。また、プロダクトへの貢献に関しても外注という立ち位置のため、エンドユーザーの声を直接聞くことはできず、依頼されたものをどう作るかというところまでが自分の手が及ぶ限界でした。

外注という立場に限界を感じていた私は、事業会社への転職を決意しました。規模的にも小さい事業会社だったため、営業もマーケもエンジニアもひとつのチームとして、まっすぐに意見を出し合ってサービス作りをしている環境に感動しました。

その事業会社には、エンジニア組織というものはなく、事業部にエンジニアが所属する形になっていました。この体制は、ビジネス側とエンジニア側との間に垣根がないため、チームの一体感を感じつつ、一気通貫で進めることができる一方、エンジニア同士のチームを跨いだ横の繋がりは皆無に近く、助け合いや技術共有などが文化としても存在しないことに課題感を感じていました。

そこで、社長に提言して、エンジニアたちを事業部から切り出して、エンジニア組織を作り、そのマネジメントを担うことになりました。エンジニア同士の横のつながりができたことで、エンジニアの新人も入りやすくなったり、インフラ面の共通リソースを自分ごととして捉えて改善する動きなどがみられるようになりました。

しかし、ここで問題が起きてしまいました。エンジニア同士の横のつながりができた分、ビジネス側との縦のつながりが希薄になり、社内であるにも関わらず、依頼する側とそれを受ける側という受発注の関係になってしまい、それこそSIer時代に感じていたディスコミュニケーションによる問題が発生する頻度が高くなってしまいました。

そのため、エンジニア組織は維持しつつ、各事業部にエンジニアをアサインするやり方に変更し、マトリックス型組織を目指しました。

正しいものを、正しく作れる組織にしたい

その後、ご縁あってユニラボに入社することになりました。はじめはWebエンジニアとして、リニューアルプロジェクトのリードを担当していましたが、途中から徐々にエンジニア採用やチームビルディングを任されるようになってきました。

チームビルディングを任されて一番に感じたことは、エンジニアのみんながタスクを持ちすぎていて、窮屈そうだなというものでした。なので、まずはやることとやらないことを明確にし、やることをしっかり絞って効果を出して行こうと考えました。その中で、チームの目標をOKRとして打ち出し、可視化し、定例MTGを通して進捗を報告してもらうような形式に変更しました。やることが明確化したことで、動きもクリアになり、皆さんきちんとリーダーシップを発揮できるようになり、より効果的な施策を打てるようになったと感じています。日々のタスクで追われているとリーダーシップを発揮できず、消化することでいっぱいいっぱいになってしまうのだと勉強にもなりました。

前職と比べて規模感も大きく、非常にやりがいを持って取り組めています。前職でも感じていましたが、エンジニアだけのことを考えていると、ビジネス側との断絶が一層強まってしまい、会社にとってマイナスになってしまいます。なので、エンジニアも会社という組織のシステムの一部として捉え、うまく連動し、協働した上で、ビジョン達成に向けて、より貢献できるチームを作っていきたいと考えています。

私の目指す組織（エンジニア組織ではなくプロダクト開発組織）は、「正しいものを、正しく作れる組織」です。多人数が関わるプロダクト開発をしていると、大局が見えにくくなり、目先の自分や周辺の利益を先行してしまいがちです。このようになっていくと、中途半端なプロダクトになってしまいます。そうならないために、全員が大局で物事を捉え、目標達成に手段を問わず、意見をまっすぐに言い合えるような、心理的安全性が高い組織を目指していきたいなと考えております。

本来、エンジニアリングとは物を作ることではありません。Wikipediaに記載のある通り、エンジニアリングとは「数学と自然科学を基礎とし、ときには人文科学・社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問」であり、技術や知識を使ってどうやって目的を達成するかを考えることです。

エンジニアがもっと自由に発想しエンジニアリングできる環境を作ることができれば、世の中をもっと変えることができると信じています。

なぜユニラボか

ユニラボには「受発注を変革するインフラを作る」という明確な課題解決型のビジョンがあります。エンジニアにとっては、こういった具体的な課題が設定されていることは、それだけですごくワクワクできることだと思います。

受注者も発注者もWin-Winの関係になれるよう、マッチング精度の向上など、技術的な可能性も秘めています。これから大きくなるにつれて研究開発などにも積極的に投資ができると思います。

まだまだこれからではあるのですが、ユニラボは絶対これから大きくなっていくと思います。その時に大きくなったのは自分が貢献したからだと強く感じられることができ、そのようなユニラボが大きくなっていくフェーズを至近距離で見ることで貴重な経験が得られると思います。