エンジニアもエンジニアではない多様な職種のメンバーたちも、エンジニアリング力を活用し、挑戦したいことに楽しく取り組める環境をつくる。
ユーザベースCEO稲垣氏のそのような想いから生まれた『Play Engineeringプロジェクト』。CEO稲垣氏の肩書にCTOが加わり、代表自らが旗振りをし注力していくプロジェクトとなっています。
本インタビューでは、Play Engineeringプロジェクトとはどのようなものか、またプロジェクト第一弾のプラスエンジニアリング制度の具体的な内容をご紹介。稲垣氏の想いや施策内容、プロジェクトの現状などもお伺いしていきます。
【人物紹介】稲垣 裕介 | 株式会社ユーザベース 代表取締役 Co-CEO/CTO
目次
「日本発の世界を代表するプロダクトを増やしたい」Play Engineeringプロジェクト発足の背景
ー本日はよろしくお願いします。まずは、稲垣さん自らが旗振りをされている「Play Engineeringプロジェクト」発足の背景を教えてください。
稲垣さん:背景としてはいくつかあるのですが、まずは国内企業の課題としてエンジニアが経営の意思決定に大きく関われていないということです。
もちろん、経営会議にも参加しているケースも多いと思いますが、経営の場において深く技術の話をすることはないですし、エンジニア起点でリードしていくこともありません。
そういった意味では、ビジネスとエンジニアの間にはある種の分断があるように感じています。
結果として、ソフトウェア領域で革新的なものが生まれにくく、日本発のグローバルプロダクトが非常に少ない要因となっているように思います。そもそも、グローバルに挑戦する機会も限られているのではないでしょうか。
次にエンジニアの待遇の部分です。今、日本とグローバルにおけるエンジニアの給与を見ると、日本の優秀なエンジニアは良くても800万〜1,000万円という年収レンジですが、海外だと2,000万〜3,000万円ぐらいでオファーがくることもあります。
経営にも深く入れないし、グローバルへのチャレンジも限られていて、賃金差も大きい。そんな中で、海外からヘッドハンティングのような形で声がかかって、今の年収の2倍から3倍で引き抜かれていくという現状があります。
そうなるとますます、日本発で世界を代表するような強いプロダクト・サービスをつくっていくことは難しい状況だと感じています。
稲垣さん:これが今起きている構図なのですが、このままでは本当に良いプロジェクトが生まれなくなってしまう危機感を持っていて、ここが課題意識の根幹にあるものになっています。
そういった背景を少しでも解消していきたいという想いから、Play Engineeringプロジェクトを立ち上げました。
Play Engineeringプロジェクトの根幹となる2つの軸
ーありがとうございます。では次に本プロジェクトの内容について教えてください。
稲垣さん:現状におけるPlay Engineeringプロジェクトの軸としては、大きく2つあります。
1つ目は、エンジニア全体の給与水準を上げていく動きです。これは「ただ給料を上げましょう」ということではなく、中身を伴う形で給与水準を上げていくものです。
2つ目は、エンジニアではない職種のメンバーたちも技術に対する感度を上げる動きです。
ビジネスサイドのメンバーたちが、技術に対する理解を持つことが大事だと思っていて、たとえば、エンジニアにお願いして各種ツールやWebサイト、プロダクト・サービスが改修されるのを待つ。すぐに改善して進めたいけど時間がかかる。
そこを、ちょっとした対応で自分の意思でどんどん変えていけるとしたら、すごく良いじゃないですか。
また、技術的な選択肢をビジネスサイドからも提案できたらプロダクトの質も上がると思います。
さらにそうなることによって、エンジニアサイドからしても、いわゆる「ちょっとした改修業務」みたいなものに割く工数が減り、よりコアな業務にリソースを集中できるようになります。
全体の技術水準を上げて、生産性を高めていく。そういうのがあるべき世界だと思って取り組んでいます。
保有スキルで給与が変わる?「プラスエンジニアリング手当」
ー本プロジェクトの第1弾として、2022年7月から「プラスエンジニアリング手当」がスタートしています。その内容についてもお伺いできますでしょうか?
稲垣さん:プラスエンジニアリング手当は、保有するエンジニアリングスキルのレベルによって、手当が支給される制度です。
稲垣さん:そもそもの考え方として、会社が何を重視して何を評価するのか、そのようなスタンスを示すことが大事だと思っています。
そう考えたときに、技術に対する加点された評価制度があるべきで、実態が伴うことによって、本気度や周囲の理解も深まります。
そのため、エンジニアリングに特化した手当の制度をつくりました。
こちらの詳細ですが、大きく3ステップです。
①データ取得スキル/プラス年収12万円
稲垣さん:1つ目は、いわゆるデータ取得のスキルで、MySQLやExcelのマクロといったものです。
自身が携わる業務やサービスに関するデータ構造を理解し、結合や条件フィルタリングを用いて業務に必要な指標やデータをデータベース内から抽出・作成することができるスキルを指します。
日常業務の中でデータを取得して加工するケースは多いと思いますが、これらのスキルを習得できると年12万の手当が加算されます。
②自動化スキル/プラス年収12万円
稲垣さん:2つ目は、自動化スキルです。
VBA や GAS・ローコードツールなどを利用し、さまざまな業務効率化や自動化をおこなっていきます。自分の仕事をいかに自動化できるか、その中でスクリプトベースのプログラミングをおこなっていきます。ボタン一つでバーっと処理できるイメージですね。
先程のデータ取得スキルと自動化スキルは並列の立ち位置で、こちらも年12万円となっており、両方取得すると年24万のプラスになります。
③アプリケーション開発スキル/プラス年収50万円
稲垣さん:①と②までプログラミングが組めていると、次のステップはいわゆるアプリケーション開発に入っていきます。
Webアプリケーションを、サーバサイドまたはフロントエンドにおいて機能開発をおこなうことができるスキルです。
このステップは、現状ですと年間で50万円が加算されます。
また、ここまでくるとエンジニア職の給与テーブルが適用されるようになり、エンジニアにおけるある程度の評価基準を満たしていることと同義になります。
ですので、技術を学んでいくと少しずつ加点されていって、最終的にアプリケーション開発に到達すると、エンジニアとして評価されるという仕組みです。
半年に一度、スキル取得の申請・評価を実施
ーどのように各メンバーのスキルを把握・評価していくのでしょうか?
稲垣さん:半年に1回のタイミングで、各メンバーから申請してもらい、審査をおこなっていきます。
ここでは、ただ勉強しただけでなく、ちゃんと実務で生かせたかどうかが大事だと考えています。
ですので、実務で何をして、どう生産性を高めたのかをファクトとして出してもらって、そちらをベースに判断していきます。
そこで認定されると手当として加点がされますし、たとえば自動化スキルであれば、今後、自動化をおこなう部分を責務として背負ってもらいます。
できる限り、実態とその職責を合わせるような形で判断をするような仕組みにしています。
ーちなみに、今回どのくらいの申請があったのですか?
稲垣さん:今回は初回の実施でしたが、申請者が62名で合格者が50名以上でした。今ユーザベースが1,000人ぐらいの規模ですので、6%ぐらいの申請、合格が5%ですかね。
ここから1年くらいかけて、合格者を10%くらいにあげていきたいですね。
そうなると、「各チームに一人、技術者がいる」という状態になり、自動化をはじめ生産性が高まる仕組みができるのではないかと思っています。
今回認定されたデータ取得スキル・自動化スキルの事例
稲垣さん:プラスエンジニアリング制度の認定者には、それぞれどのようなエンジニアリングスキルが認定されたのかを社内共有してもらっています。
■データ取得スキル
例えば、「データ取得スキル」での認定例では、以下のようなものがあげられます。
- Python、MySQL、GASを活用し、新規アサインされたタスクや〆切タスクがひと目で把握できるSlackアプリを作成
- 経済情報プラットフォーム「ミーミル」における、流入経路別のアクティブ率・リピート率がわかるシートの作成
- NewsPicks広告におけるさまざまな角度からの成果分析レポートの作成
■自動化スキル
他にも「自動化スキル」というカテゴリーでは以下のような施策が認定されています。
- Jenkins(自動化サーバ)とGAS(Google Apps Script)を活用して、データの妥当性の確認を自動化。
- • NewsPicksパブリッシングにおいて、RPAツールを活用して日次書籍別POSデータ、在庫情報の取得を自動化。複数書店の書籍売上数が 毎日わかるようになった。
- GASを用いて360FBの作業を効率化。各メンバーが数値を入力するシートをテンプレ化。入力された数値を自動集計できるようにし、評価会議で参考となる集計シートを作成。
社内メンバーは、どんな技術を身につけると認定されるのか、それが業務上どんなメリットがあるのか、詳細の内容を閲覧できるようになっています。
「研修にも注力」楽しんで自発的に学ぶ環境をいかに設けることができるか
ープラスエンジニアリング手当の推進と同時に、プログラミングを教える場も設けているとのことですが、どのような研修があるか教えてください。
稲垣さん:こちらは、本当にさまざまな形で研修を実施しています。
たとえば,今年の新卒メンバーがインターン中にSQLをずっと学んでいて、「みんなにも教えたい」と手を挙げてくれたので、「新卒メンバーが教えるSQL研修」を開催したり、もうちょっと手前のところで「そもそもプログラミングってなんだろう?」という入口になる「親子プログラミング教室」も開催しました。
プログラミングをやったことがない人には本当にわかりにくい領域だと思うので、子どもと一緒に学べる機会を設けたりもしています。
子どもが一生懸命学ぶ姿勢を見ながら、みんなで楽しんで学べるような、興味を持ってもらう工夫を常に考えています。
それ以外にも、「関数の使い方を学ぶエクセルの研修」も実施していますし、社内の特定のチームに対象を絞った研修もおこなっています。
研修ラインナップをそろえて、みんなが自由に学べるような形でできる限り準備して、一定の基礎まではしっかり学んでもらえる土台をつくりたいですね。
稲垣さんが感動したコーポレート部門における取り組み
稲垣さん:試験的なトライではあるのですが、コーポレートサイドでもエンジニアスキル取得の取り組みをはじめています。
人事情報や勤怠情報など多くのデータを扱う中で、ツールの活用も必須になってきますが、いかに使いこなせるかが重要です。
さらに、RPAなどを駆使して自動化できる動きも取り入れたほうが良いと思っています。
そこで、みんながツールの使い方を学んでいくのを応援する仕組みとして、試験的に「生産性向上大会」を開催しました。生産性を最も大きく向上できたチームにはインセンティブが発生します。
それでいざ、結果発表のプレゼンの場があったのですが、ものすごく感動したことがありました。
創業期に入社した女性メンバーがいて、私も13年ぐらい一緒にやっているのですが、そのメンバーが知らず知らずのうちに自動化をしていて、プレゼンで優勝したんです。
いわゆる秘書業務に近いことをやってくれているメンバーなのですが、日程調整をはじめとしたチェック・調整業務を自動化・可視化していて、「この生産性は技術の力で上げていたんだ」とそこではじめて知って、驚きました。
稲垣さん:その他のメンバーもさまざまな自動化にチャレンジしてきてくれて、普段なかなかの技術に関わらないチームが積極的に行動してくれたことが、私にとっては感動的な体験で、非常に良い場でした。
「バックオフィスだってできるんだ」と思いましたね。
技術を推進するとみんなが楽になるし、モノができると嬉しいじゃないですか。さらにスキルアップにつながって、それが評価されると手当もつく。そういった連鎖をつくれたことは、今回すごく良かったと感じました。
ユーザベースがロールモデルとなり、社会に貢献していきたい
ー最後に、Play Engineeringプロジェクトの今後の展望について伺えればと思います。
稲垣さん:「何かを変えたい」と思った際、まずは事例を調べると思うのですが、私たちがひとつのロールモデルでありたいと思っています。
少し前の話になりますが、私たちがIPOをするとき「ユーザベースの自由な働き方、今のカルチャーを維持したい」という想いがあって、そこの実現が一番の命題でした。
当然それは簡単なことではなく、「さすがにIPOしたらできないんじゃないか」という話もありました。
でも、試行錯誤し、監査法人の方たちと何度も会話して、何が自分たちにとって大事で、今の自分たちの文化のどの部分がある種の弱い部分となってしまっているのか。それをどう強く変えていけるのか。
そのような議論を重ねていった結果、カルチャーを維持する形でIPOができたんです。
そうしたところ、まだIPOしてない企業の方々から「ユーザベースは自由な文化を維持した状態でどうやってIPOできたんだ」という質問が数多く来るようになったんです。
ある意味それは、ひとつのロールモデルになれたことだと思っていて、それが波及して多くの企業の気づきやきっかけになったとしたら、すごく価値があることだと感じています。
稲垣さん:人に見てもらうためにやってるわけではなく、自分たちがやってることが価値あることであれば、世の中の人たちに対しても良い影響力を与え、業界の発展にもつながります。
そうなることで、社内のメンバーたちの誇りにつながりますし、取り組みへの想いの強度がより上がると思います。
今回のPlay Engineeringプロジェクトも、IPOのときと似たような感覚で見ていて、私たちが世の中のロールモデルになることで、良い影響が確実に広がっていくと感じています。
冒頭でお話した、技術者がもっと経営に入るような仕組みづくりや、業界的な課題も含めて、みんなで見直して全体で底上げできることにもつながるでしょう。
そのためには、まずは本プロジェクトを成功させることともに、ユーザベースの事業も成長していく必要があります。
私も伸びていない企業の施策は見ようとは思わないので、両輪まわしていく前提が必須になりますが、そのような存在になっていきたいですね。