ITエンジニアが働く環境を選ぶ際に「技術的な成長が期待できるかどうか？」はとても重要な指標です。技術的な裁量が大きいことや学習機会が用意されていることだけでなく、チーム編成や評価といった仕組みの部分にまでエンジニアを尊重した文化が浸透していれば、その企業は極めて働きやすいと言えるでしょう。
エンジニアが尊重される文化を醸成する仕組み作りの事例として、ペアプログラミングによる知見の共有を推し進め、プロダクトに導入する技術選択にもかなりの自由を持たせているユーザベースに、エンジニアを支える開発組織と企業文化について聞きました。
今回は、スペシャリストとしてFellowの肩書きを持つ矢野勉さん（上記画像左下）と、入社2年目の廣岡佑哉さん（左上）にそれぞれの働き方を語ってもらい、CTOの林尚之さん（右上）には組織としての考え方をうかがいました（※取材はWeb会議ツールでリモート実施しました）。
※ この記事は株式会社ユーザベースによるSponsoredContentです。
- 新しいプログラミング言語を社内で啓蒙して導入に
- 新しい技術を学べる機会は積極的に創出していく
- 週の半分を副業に使い京都から在宅のリモート勤務でOK
- 技術のことが好きなエンジニアは企業の競争力に直結する
- 数多くの仕組みがスキル向上を支えてくれる
- 透明性の高い評価制度で、キャリアの指針を明示
- エンジニアが挑戦できる環境がユーザベースにはある
※ 記事末に、Amazonギフト券500円分が当たるプレゼントのお知らせがあります。
新しいプログラミング言語を社内で啓蒙して導入に
──ユーザベースが提供する「SPEEDA」でニュース機能を改善した際に、記事の取り込みやBFF（Backends For Frontends）の実装にClojureが採用されました。そもそもこのプログラミング言語をユーザベース社内に普及させたのは矢野さんとのことですが。
矢野 私はもともとJavaのプログラマーで、勉強会にもたくさん参加してきました。Javaの言語そのものは割と好きなのですが、さすがに10年以上使っていると飽きてきて、全く違った言語を何か学ぼうとHaskellやErlangなどいくつか触ってみていたんです。
ちょうどScalaやKotlinのようなJVM（Javaの仮想マシン）で動作するプログラミング言語もはやり始めていましたが、これまでやってきたことの延長線上というイメージで、ワクワクする新しさが足りない。そんなときたまたまClojureに触れることがあって、これが非常に性に合ったのです。
──ClojureもJVMで動作する、LISP系のプログラミング言語ですよね。
矢野 私は言語仕様がシンプルな方が好みで、とはいえClojureのベースになっているLISPの文法は構成要素が少な過ぎて、私には少し難しさを感じていました。Clojureは最近の新しい言語の仕様も取り込みつつも、言語の構成要素はものすごく少ない。またオブジェクト指向言語ではないし、型もそれほど強くないのでJavaとはパラダイムが異なります。プログラムを書く際に、全く違う思考を求められることが新鮮でした。
さらに生産性も高いので、ぜひユーザベースで普及させたいと考えたのです。
──どのようにClojureを社内に広めたのでしょう？
矢野 ペアプログラミングと勉強会ですね。社内の勉強会は頻繁に開催されるので、何度か関連した発表をしました。Clojureがいかに良い言語なのかを伝えたり、コンピューターサイエンスの抽象的な概念をClojureの言語仕様と紐付けて説明したり、Clojureの作者であるリッチ・ヒッキー（Rich Hickey、@richhickey）の思想を紹介したり。
リッチ・ヒッキー氏は、ITエンジニアとして示唆に富んだ講演をすることでも知られている。次のリンク先の解説などを参照。
また直近の社内勉強会でも、関連した内容が発表されている。
そうした啓蒙活動を続けるうちに、社内で「Clojureは良さそうだ」という空気感が醸成されてきました。また、その前にプロダクト開発に使えることも示したくて、まず自分が携わったプロジェクトに導入していました。
そして業務内でペアプログラミングをしながら、同じプロジェクトのメンバーにClojureの利点や書き方を伝えていったのです。ユーザベースでは、ほとんどの作業をエンジニア同士がペアになって実施しますから（記事末の関連記事も参照）。
新しい技術を学べる機会は積極的に創出していく
──入社して数年の廣岡さんから見て、ペアプログラミングの印象はどうですか？
廣岡 ペアプログラミングで仕事をすると、一緒に作業するエンジニアから知見をたくさん吸収できるので、技術を効率的に習得できます。話し合う過程で自分の思考も整理されますし、何よりコミュニケーションしながら仕事をするのは楽しいですね。
ユーザベースのシステム開発ではたくさんの要素技術を扱いますが、もし1人だけで全てを学ぼうとしていたら、今でも分からないことがかなり残っていたかもしれません。
──社内の技術勉強会についてはどうでしょう？
廣岡 エンジニアが個人で調べられる技術領域には限界がありますから、自分が全く知らなかった知識をキャッチアップできるのは、本当にありがたいです。
社内勉強会はスキルの向上にかなり寄与していますし、ユーザベースでは勉強会じゃなくても社員同士が技術について積極的に情報交換しています。
──林さんにお聞きしたいのですが、技術的なキャッチアップが社内でできるように、そういった場を意識的に設けているのでしょうか？
林 よくエンジニアの間で「プライベートな時間を割いて、技術の勉強をするべきか？」というテーマが話題になりますよね。
私個人としては、個人のプライベートな時間はアンコントローラブルなものですし、業務時間の中でいかに技術を学習できる機会を創出するかを常に考えていきたいと思っています。業務時間内であれば組織としてコントローラブルなので。
例えば、家庭の事情などでプライベートな時間を勉強に当てることが難しいエンジニアもいるわけです。だからこそ、ユーザベースでは社内勉強会などを積極的に開催し、エンジニアが望めば技術について学べる機会も用意します。
技術が好きで優秀なエンジニアはそういった環境の企業に集まるはずですし、その仕組みが将来的にはサービスや事業の成長に寄与できる組織作りにつながるはずです。
週の半分を副業に使い京都から在宅のリモート勤務でOK
──続いて、矢野さんのキャリアや働き方についてお聞かせください。矢野さんはユーザベースのプロダクト開発に長らく携わっていますが、どのような経緯だったのでしょう。
矢野 私は東京でフリーランスのエンジニアとして、主にJavaの開発案件に携わっていました。Java関連の技術では、Apache Wicketというフレームワークに興味を持っていました。Wicketは、全てをJavaのコンポーネントで記述することが特徴のフレームワークです。
Wicketの勉強会もよく主催しており、その常連だったのが当時のユーザベースCTOの竹内秀行（@saascontrol）さんでした。竹内さんから、ユーザベースは「SPEEDA」の開発にWicketを採用していると聞き、技術的なチャレンジをする会社だと認識していました。
──それがきっかけでジョインされたのですね。
いえ。実は、その後まったく別のルートで現・代表取締役Co-CEOの稲垣裕介が連絡をくれたことがきっかけです。それが2011年ですから、もう10年になりますね。
──ところで、今回の取材はたまたまオンラインになったことで矢野さんにも参加いただけていますが、現在は京都に在住でリモート勤務されているんですよね。
矢野 そうです。ユーザベースで働いて数年という頃に、家庭の事情で関西に引っ越すことになりました。東京に通勤するのは難しいため、ユーザベースとの契約を更新しないつもりでした。
ところが稲垣が「引っ越し後も、リモートで働いてほしい」と言ってくれて、驚きましたが非常にうれしかったですね。実際に勤務形態についてかなり融通を利かせてくれたので、関西を拠点にリモートで働くようになりました。
稲垣からは、「制度や契約内容を調整することで解決できる問題ならば、会社としてメンバーに最大限寄り添う。それはエンジニアにとってもプラスになるし、長い間働いてくれた人を手放さなくて済むことは、会社にとっても利益があるから」という説明をされた記憶があります。
──その当時はまだフリーランスということですが、それから社員になったのですね。
矢野 はい。さらに数年が経過して、稲垣から「もう長い間働いているので、社員になりませんか？」と声をかけられました。しかし、私はその時点で自分が代表を務める法人を立ち上げていたので、フルタイムでユーザベースの仕事をするつもりはなかったんです。
それで社員になるのは難しいと説明すると「会社はそのまま続けてもらってかまわないし、ユーザベースの仕事をするのは週の半分になってもよいから、ぜひ社員になってほしい」ということを言われました。それで、現在は週の半分を自分の会社の仕事に、もう半分をユーザベースの仕事に割いています。
技術のことが好きなエンジニアは企業の競争力に直結する
──次に、廣岡さんのキャリアもお聞かせください。
廣岡 私は、2017年に新卒でSIerに入社し、2019年にユーザベースに転職しました。前職では各チームの役割が明確に分けられていて、開発チームは開発だけを、運用チームは運用だけを担っていました。私は開発業務の担当でしたが、より幅広い領域で仕事したいと思うようになったのです。
そのとき転職サイトで連絡をもらったユーザベースからのオファーに「コーディングから、運用、ビジネスのことまで、エンジニアが全て担当できる」とあったことが目を引いて、面談で社員と話をしたりする中で転職を決めました。
──社員との面談で、ユーザベースはどんな会社だと感じましたか？
廣岡 とにかく技術の好きな人が多いという印象でした。
林 確かにユーザベースでは、エンジニア採用において「技術が好きである」ことを非常に重視しています。
──それはなぜでしょう？
林 私たちエンジニアの役割は、技術力によって事業に貢献することです。その目的を達成するには、自分たちが競合他社のエンジニアよりも技術的に優れている必要があります。ITの世界では次々と新しい技術が登場しますから、好きでなければ情報をキャッチアップし続けられません。
だからこそ、技術が好きなエンジニアが集まっている組織の方が、長期にわたって高い生産性を発揮し、事業に貢献できると考えています。
──廣岡さんはユーザベースに転職したことで、働き方の変化はありましたか？
廣岡 そうですね。ペアプログラミングについては先ほどお話ししましたが、技術選定に対する考え方も大きく違うなと感じます。
前職はSIerだったこともあって、リスクを徹底的に避け、なるべく前例のある技術や枯れた技術を採用する傾向にありました。一方、ユーザベースでは技術的なチャレンジをすることになっても、エンジニア自身の「このプログラミング言語に挑戦してみたい」「このフレームワークが好きで、こういった利点があるから導入したい」といった思いが重視されます。
他には、ドキュメントをあまり書かなくなりました。SIerでは大量のドキュメントを業務の中で作成する必要がありますが、現在はUAT（ユーザー受け入れテスト）の自動テストを書くくらいでしょうか。カルチャーのギャップに驚きました。
数多くの仕組みがスキル向上を支えてくれる
──ドキュメントの話ですが、知識やノウハウを他のエンジニアに伝えるためにも文書化しなくてよい体制が構築できているということでしょうか？
廣岡 私たちB2B SaaS事業には複数のチームがありますが、チーム間におけるエンジニアの流動性が非常に高いのです。月に1度は必ずチームメンバーの入れ替えがあり、特定のメンバーが同一のプロダクトを6カ月以上担当することはほとんどありません。このため、あるプロダクトの開発経験があるエンジニアはチーム中に何人もいる状態になり、仕様などの知識に対する属人化が起こりにくいのです。
そして、先ほどお話ししたようにペアプログラミングの過程で自分の知見を他のメンバーに共有しますから、とくにエンジニア間で知識を共有するためにドキュメントを作成しなくてもよい開発体制が生まれています。とは言っても、私が今現在担当している「1人プロジェクト」は、エンジニアが1人しかいないので例外的にペアプロしないのですが。
──それはどんなプロジェクトなのでしょうか？
廣岡 単独のエンジニアが、社内の困りごと解消や業務改善のためのシステム開発を担当するものです。社内から挙がった要望をもとに、1人のエンジニアが対応方針を考え、技術選定や設計、実装、テスト、リリースまで全てやり切ります。この制度は最近立ち上がったもので、手を挙げれば誰でもこのプロジェクトを担当できます。
──インハウスの開発プロジェクトということですね。この制度の意図はどういったところにあるのか、林さんにお聞きしたいのですが。
林 目的は、エンジニア個々人の成長速度を向上させることです。
先ほどから再三語られているように、ユーザベースではチームの生産性を上げるうえでも知識の共有においてもペアプログラミングが効果的な取り組みだと考えていますが、一方でエンジニアには、誰の助けも借りずに自分の力だけでシステムを立ち上げる経験を積むことも重要です。
1人で1つの小さなシステムをゼロから構築すれば、システムを構築する上で何を考慮すれば円滑に開発が進むか、どうすればトラブルが少なくパフォーマンスに優れた設計・実装にできるかといった勘所を効率的に身に付けることができます。当然日々の作業でペアプロを通しても学ぶことができるのですが、その答え合わせを含めて1カ月という短い期間で集中的にスキルアップしてもらいたいと考えて、この制度を立ち上げたのです。
透明性の高い評価制度で、キャリアの指針を明示
──最後にエンジニアの評価について聞かせてください。エンジニアが尊重されていると感じるには、働きやすいだけでなく、働きが正当に評価されて見合った報酬が得られる必要があると思います。ユーザベースの評価制度や運用方法はどうなっているのでしょう？
林 特徴的な制度としては、360度評価を3カ月に1度、四半期ごとに実施しています。まず、各エンジニアがアンケートでフィードバックを受けたい相手（複数名）を指名します。ほとんどのエンジニアが同じチームで働いた同僚を希望しますね。このアンケートをもとに、どのエンジニアにもフェアにフィードバックが行き届くよう、割り当てを決めます。
360度評価では「経営」「運用」「エンジニアリング・マネジメント」「プロダクト・マネジメント」「アジャイル」「アーキテクチャー」など、かなりたくさんの観点で評価を行います。各項目は1〜7の等級に分かれており、数字が増えるにつれて、スキルに対して深さと広さが求められるように設計しています。
これは、ユーザベースで働くエンジニアに身に付けてもらいたいスキルを言語化したものです。例えば「AさんはスキルBにおいて非常に優れており、チームをリードしてくれる。したがって等級は7」というように、全項目でスコア付けしてフィードバックします。
廣岡 この観点や等級を策定するところから、社内のエンジニア全員が携わっているので、納得感も十分に高いですね。
林 さらに、等級を付けるだけではなく、その等級として評価したポジティブな理由、今後さらにスキルアップするための改善点、四半期の中でその人が輝いていた点や刺激を受けた点などを記述します。
エンジニアの給与も、肩書きによってではなく、360度評価での各項目の等級に応じて決まります。だからこそユーザベースでは、マネジメント職になるだけではなく、エンジニアとしてのスキルを徹底的に突き詰める方法でもキャリアアップが可能です。
ユーザベースのB2B SaaS事業では昨年、高い技術力を持ったエンジニアにFellowという役割を付与しましたが、それも技術特化したエンジニアを高く評価する姿勢の表れですね。
※Fellowとは、ユーザベースB2B SaaS事業で、エンジニア組織内に設置されたポジション。卓越した知見と技術力を生かして事業全体の技術クオリティーを高め、開発に深くコミットすることでプロダクトおよびエンジニアの成長を促す。UB Journalの記事も参照。
さらに、各人がどんな評価を受けているかを全社的にオープンにしています。つまり、各社員の給与もオープンになっているということです。
──徹底した透明性ですね。
林 評価制度を実施するからにはフェアであることを担保したいですし、評価する側の恣意性を可能な限り排除したいので、こういった形態にしています。他のエンジニアが受けた評価も詳細に把握できるため「このスキルが身に付けば、上の等級になれる」というように目指すべき目標やロールモデルも明確になります。
エンジニアが挑戦できる環境がユーザベースにはある
──最後に、今回話していただいたようなユーザベースの制度や取り組みが、エンジニアのキャリアにどんな好影響があるか、皆さんの考えを教えてください。
矢野 エンジニアには、いろいろなことに挑戦したいタイプの人が多いですよね。新しい技術に触れてみたいとか、クライアントの意見を直接聞ける環境でより良い機能を考えたいとか。ユーザベースはエンジニアの自由を尊重する会社であるため、エンジニアが自主的に挑戦できる環境作りを可能な限り続けています。
私たちが採用している各種の制度は、その自主性を支えるためのものです。エンジニアの意見が尊重される職場でなければ、そして透明性高く全ての情報がオープンにされていなければ、社員が自主的に何かを思考・行動できる状態にはならないはず。だからこそ、ユーザベースが取り組んでいることは、エンジニアの成長にとってプラスになると考えています。
廣岡 私も、ユーザベースは挑戦しやすい環境であり、かつ挑戦が推奨されていると感じます。もちろん、裁量が大きいからこそエンジニア個々人が考えるべきことの幅も広くなり、責任も伴うわけですが、そういった環境にやり甲斐を感じる人にとっては、非常に魅力的な職場です。
林 さまざまな制度や仕組みの目的は、エンジニア個々人を成長させ、事業や会社の成長に結び付けることです。評価の透明性や、挑戦を推奨する文化などは、絶対にエンジニアのキャリアにおいて意義があると思っています。こういった社風に興味を持ってくださる方、自分自身の創造性を発揮しつつも周囲とコミュニケーションをとってプロジェクトを進めるのが好きな方は、きっとユーザベースという会社にマッチしているはずです。
──エンジニアを尊重する開発組織では、エンジニアが主体性をより発揮できるということなのかもしれませんね。本日はありがとうございました。
ユーザベースで成長したいエンジニアを広く募集中！
- ▶B2B SaaS - ソフトウェアエンジニアの募集要項を見る
- ▶B2B SaaS - SREの募集要項を見る
- ▶B2B SaaS - データサイエンティストの募集要項を見る
- ▶B2B SaaS - テストエンジニアの募集要項を見る
オープンで透明性が高く自由と自主性が尊重させる開発組織。
- 矢野 勉（やの・つとむ、@t_yano、上記スクリーンショット上段右）
- 株式会社ユーザベース B2B SaaS事業 Fellow
自営業の開発者として金融・保険・ゲーム配信などの多様なシステム開発に携わり、同時にオープンソースのプログラミング活動へも参加してきた。Webアプリケーション・フレームワークApache Wicketコントリビュータ。日本語の書籍を執筆し普及に努める。現在はプログラミング言語Clojureコントリビュータとして活動。2011年よりユーザベースにて初期のSPEEDAの開発に参加し、現在まで参加している。現在、京都にて開発会社を設立し、ユーザベースでの開発と並行して、独自にアプリの開発も行っている。 - 廣岡 佑哉（ひろおか・ゆうや、同下段左）
- 株式会社ユーザベース SaaS Product Divisionエンジニア
龍谷大学理工学部卒業。2017年から、SIerでクレジットカード情報を取り扱うWebサービス開発に従事。その後、2019年にユーザベースに転職。現在はFORCAS Salesの開発に従事する。 - 林 尚之（はやし・たかゆき、同上段左）
- 株式会社ユーザベース B2B SaaS事業 執行役員 CTO
松山大学経済学部を卒業後、SIerを経て2009年に独立。エンタープライズ向けシステム開発等に従事した後、2013年からSPEEDAの開発にフリーランスとして参画。2017年1月に入社し、2018年1月より現職。
🎁 Amazonギフト券500円分が当たるプレゼントのお知らせ！
※プレゼント企画は終了しました。ご協力、ありがとうございました。
この記事で語られているユーザベースの開発文化や働き方について、みなさんはどのように感じたでしょうか？ ぜひ次のアンケート「ユーザベースで働くこと」にご回答ください。
アンケートに協力いただいた方の中から抽選で40名様に、Amazonギフト券500円分をプレゼントします。応募期間は2021年7月20日（火）まで。その他詳細は下記の応募要項をお読みください。
| 期間 | 2021年6月29日（火）から2021年7月20日（火）まで |
|---|---|
| 賞品 | Amazonギフト券500円分 ×40名様 |
| 応募方法 | 上記のアンケートにご回答ください ※ はてなのアカウントをお持ちでなくても応募できます。 |
| 当選 |
|
| 注意事項 |
|
[SponsoredContent] 企画・制作：はてな
取材・構成：中薗 昴
関連記事 - ユーザベースの開発文化とNewsPicksの開発者体験
本記事にも登場したペアプログラミングや技術選定など、ユーザベースのB2B SaaS事業における開発手法の詳細については、以前に掲載した記事を参照してください。
また「NewsPicks」開発チームへのインタビューも掲載しています。
どちらもあわせてお読みください。