目標設定や評価制度がなく、給与は自己申告して決定する――株式会社ゆめみのユニークな取り組みは、メディアでもたびたび取り上げられ、先日ゆめみオープン・ハンドブック内に公開された「アプリケーション・エンジニア職位ガイドライン」も大変話題になりました。

企業の内製化支援を行う同社は、エンジニアにとってどのような環境なのでしょうか。今回はゆめみでCTO兼アーキテクトを務める大城信孝氏にお話を伺いました。

従来の受託開発にとどまらない、新しい事業の形

――まずは、株式会社ゆめみの事業内容について教えてください。以前から「内製化支援のリーディングカンパニー」というのを掲げていらっしゃいますよね。

大城信孝氏(以下、「大城」):事業は大きく分けるとふたつあります。ひとつめは、いわゆる受託開発の形でお客さまからお話をいただいて要件を定義し、システム開発・納品、そして保守・運用まで一気通貫でおこなうもの。もうひとつは、さきほどあげていただいた内製化支援ですね。

受託開発とはいうものの、当社は課題の発見からお客さまと一緒に始めまして、ヒアリングによる問題の本質の見極め、課題設定を経て、要件定義や設計に入っていきます。そのためモノを作って納品するというよりは、お客さまと一緒に課題解決をしていくのが基本的なスタンスです。わたしたちはこれを「BnB2C」(ビー・アンド・ビー・トゥー・シー)と呼んでいます。

内製化支援につきましては、事業をさらに大きくしていく、もしくは新規事業を立ち上げようとしている企業さまに対して、コンサルティング、あるいは実際に当社のエンジニアがお客さまのチームに入り開発をしていくことで内製化を支援しています。最近は特に急成長のスタートアップ企業さまの支援に注力しています。

――たとえば、もとは開発を外注していて、いずれは内製化していきたいという、その移行期にゆめみさんに協力を求めるイメージでしょうか。

大城:もちろんそういったパターンもありますし、すでに内製化している企業さまに対して、さらに事業を加速させていくための支援をさせていただくこともあります。最近の事例では、急成長のスタートアップ企業である株式会社マクアケ様との案件がそれに該当しますね。

参考情報:マクアケ|スマートフォンアプリ「Makuake」 アタラシイ共創でMakuakeアプリの持続可能な成長を実現

上司・部下の関係はない、職位は自分で名乗るもの

――ここからは、エンジニア組織について伺っていきたいと思います。現在の組織構成について教えてください。

大城:サーバサイドエンジニア、フロントエンドエンジニア、iOSアプリエンジニア、Androidアプリエンジニアなど、エンジニアの職能ごとにチームが構成されています。エンジニア以外にもUX/UIデザイナーチーム、営業チーム、PMチームなど多くのチームがあります。

そこから何名かずつ出て、プロジェクト用のチームが構成されます。要は職能ごとのチームからプロジェクトにアサインされて、プロジェクトチームができあがるといった状態です。

さらにチーム横断で組織課題を解決するためのチーム、当社では「委員会」と呼んでいるものにも所属する形になります。たとえば、サーバサイド委員会であればサーバサイド全体に関する課題を解決をするチームですし、カイゼン委員会といって職能を横断してチーム間の課題を解決するチームもあります。

現在、社員数は約250名前後ですが、一人ひとりがそのように複数のチームに所属しています。

――つづいて、上司・部下の関係がない組織について、詳しくお聞きしたいと思います。当初からずっとこのような形だったんでしょうか。

大城:わたしが入社したのは2016年12月ですが、基本的にはずっとこの組織体制ですね。一応日報や経費精算の承認者的な役割の人はいるんですけども、厳密な意味での上司・部下の関係はありません。当社では何か上から与えられるのではなく、「わたしはこの仕事をやりたいです!」というのをアピールして仕事をやっていきます。

職位も自分で名乗るものなんですよね。入社時だけは、応募時の職種とそのときのスキルから、アソシエイトなのかプロフェッショナルなのかといった職位を決めてはいくのですが、暫定でしかありません。そのあと、自分が職位を変えたいと思ったタイミングで、「今日からこう呼んでください」と変わることが結構あるかなと思います。

反響の大きかった「アプリケーション・エンジニア職位ガイドライン」もあれをすべて満たさなければその職位にはなれないというものではなく、「自分は総合的に判断してこのあたりだな」と自己申告に基づいて決まっていると思っていただくとよいのではないでしょうか。

もうひとつのパターンとしては、他のメンバーから「そろそろプロフェッショナルを名乗ってもいいのでは」とフィードバックを得て名乗ることもあります。

ゆめみはティール組織の「助言プロセス」を採用しており、フィードバックの文化があります。「わたしはこう考えています」とSlackに投稿すると、それに対していろいろな助言をもらうことができるんです。その中で「あなたはプロフェッショナルぐらいのレベルがあるよね」という話になれば名乗るやり方ですね。

自分の市場価値を知り給与を自己決定する

大城:ここで「給与自己決定制度」についてもお話をしておきましょう。

さきほどの職位ガイドラインが少しひとり歩きしてしまったかもしれませんが、職位ガイドラインと給与自己決定は基本的にはセットで考えるものです。給与を自己決定するための職位ガイドラインなので、他者ではなく、あくまで自分で決めるというのがベースなんです。給与を上げていくタイミングでプロフェッショナルやチーフに変えるなど、そうやって自分で職位を決定しています。

――今回、職位ガイドラインの公開ではっきりと明文化されたように思うのですが、いつからこのような形で運用されていたんでしょうか。

大城:当社は、2018年10月1日に「アジャイル組織宣言」を出しまして、合わせてさまざまな制度を導入しました。そのタイミングでだんだん変わってきましたね。

実はそれ以前は一般的な給与テーブルや評価指標でやっていたこともありました。「今期はこういう目標を立てて、その目標に対してどれぐらいの成果を出せたから、じゃあ評価はS・A・B・CのAですね」といったものです。自己評価をして、さらにPMに確認してもらうやり方です。結局は形骸化してしまって、運用するのが難しいなと感じていました。

――2018年当時、ルールが大きく変わって、エンジニアの皆さんはどういった反応でしたか?

大城:代表がわりと「えいや」で決断したものではあったんですが、戸惑いはありつつも、大きな反対はなかったと記憶しています。わたし自身はおもしろい試みだなと思っていました。

もちろん自己主張が得意な人・不得手な人で感じ方は違うと思います。自分の考えを言葉に出すのが得意な人はこのやり方が好きでしょうし、苦手な人は苦労しているかもしれません。そういった点で難しさもありますが、職位の中で非常に生産性が高い方、著しい成果を出している方には見合った給与を出すことを重視しているのでカバーする体制はあります。

制度導入時に代表がよく話していたのは、ゆめみのこの制度は毎月転職しているようなものだと捉えると分かりやすいと。転職したら年収が100万、200万上がることってエンジニアにとってはそう珍しくはないですよね。それが同じ会社にいたら年で50万円も上がらないとなれば、転職を考えるのもやむをえないと思います。そこで当社では、自分の市場価値が現状と差があるかを認識するために、他社のカジュアル面談にいくのもよしというスタンスをとっています。それで自分の価値を知り、それに見合う給与を改めて宣言してもらえればいいです。

要は実力があって、転職市場での価値も高いと分かれば、宣言をして相応の給与を得られるということです。

細かいルールはいくつかありますが、誰かが承認するフローではないので、常識の範囲内に収まっているのであれば基本的には通ります。こういったところがわたしはおもしろいと感じていますね。

自主性を重んじる働き方は採用基準にも直結

――さきほどプロジェクトチームを作る話があったと思うのですが、ここに関しても宣言というか、やりたいと手を挙げた人が優先的にアサインされるのでしょうか?

大城:そうですね。基本的には案件ごとに、たとえば、サーバーサイドは何名必要、フロントエンドは何名必要という形で公表されて、それを見てやりたいですと手を挙げます。スキルセットが条件を満たしてるか、今回の案件に合うかなどはPMと話をしますが、基本的には手を挙げてやりたいと言った人が優先です。見つからないときは、指名される場合もあります。

――ここまで本当に自主性、もちろん一定の能力は求められるとはいえ、エンジニアがやりたいことに真摯に向き合っている組織なんだなと感じています。

大城:そうですね。ゆめみが採用の段階で求める人材像として、自律・自学・自責の3つを定義した「プリンシプル(基本原則)」というものがあります。他責ではなく、物事を自分事として捉え、自分で学んでいけるエンジニアが集まっている環境ではあります。

逆に言うと、与えられるのを待っている人はつらいと感じるかもしれません。特に今はフルリモートで仕事をしていますので、SlackやZoomといったコミュニケーションツールを使って、自分の考えややっている仕事を積極的に伝えていく必要があります。

――大城さんが一緒に働きたいもしくは採用したいという観点で、エンジニアに必要な要素ってありますか。

大城:中途採用でしたら、ある程度の技術力は求めますが、やはり自分で考えて自分で動くことができる方ですかね。情報のキャッチアップが非常に早いとか、体系的に学んできた領域があるとか、いろいろなポイントはあるんですけど、大事なのは全部が満たされている必要はないというところです。むしろ得意と苦手がはっきりしていて、得意のレベルがすごく高くて尖っていると個人的にはひかれますね。

プリンシプルの話もそうですが、こうやってお話しさせていただくと、採用ハードルがかなり高いのではないかと言われることもあります。ただ、採用時点ですべてを満たしている方を求めているわけではなくて、将来的にそこにたどり着けるだろうという可能性や目指している方向性が合っているかといった部分も重視しています。

実はわたしはもともと自社サービス志向で転職活動をしていたんですが、紹介された中でゆめみだけが受託開発の企業だったんです。当時話題になっていた「ハネムーントラベラー」といって、世界一周しながらリモートで仕事をしている人がゆめみにいると聞いて、おもしろそうな会社だなと思いました。

あとは私が新しいもの好きでもあるので、プロジェクトごとに最適な技術を選んだり、新しい技術を試したりできると聞いて、ゆめみは一味違うと感じたんです。

普通受託開発というと、顧客の指示に従うイメージがありますが、任せていただくことも多くて裁量があると感じます。もちろんすべてがそういうわけではありませんし、長期的な保守・運用の観点からレガシーな技術を選ぶ場合もあります。それでも自分たちがやりたいこと・いいと思ったものを選ぶメンバーが集まっているので、新しい技術をちょっとずつでも取り入れていこうという雰囲気はありますね。

多くのユニークな制度や福利厚生が存在する理由

――次に、エンジニアの働く環境について聞かせてください。「勉強し放題制度」「全員CEO制度」「有給取り放題制度」と興味深いものばかりなんですが、順番に解説をお願いできますか。

大城:まず「勉強し放題制度」は、アウトプットをおこなう前提のあらゆるインプットに対して経費精算できるというものです。書籍や研修、セミナーはもちろん、外部のイベントやカンファレンスへの参加でも可能です。現時点の業務に直結しなくても将来的になんらかのつながりが見込めるものであれば対象となります。美術館・展示会なども対象の範囲ですし、実はミュージックフェス等の参加費用も対象になっています。

わたしは過去にこの制度を利用して、社内のエンジニアとAppleの開発者イベント「WWDC」に参加しました。また、AWSの年次イベント「re:Invent」に参加したメンバーもいます。そのときは参加後に社内報告会を行ったり、社外の勉強会で発表をしたメンバーもいました。

この制度について、より詳しくはこちらのページもごらんください。

大城:つづいて「全員CEO制度」ですね。ここまでお話をしてきたとおり、ゆめみはティール組織を自認しています。基本的に承認者はおらず、自分で物事を決めて進めていく、それを全メンバーができるという組織です。これが実現できるのは、各メンバーがCEO権限と同等のものを持っているためなんですね。実際に取締役会で全社員に代表取締役権限を付与する決議がされました。

これには、さきほども出てきた「助言プロセス」が重要になってきます。まず、Slackに「こういう制度を作りたいです」「こういう制度をこう変えたいです」といったことをGitHubの「プルリク」を模倣して「プロリク(プロポーザルリクエスト)」として投稿します。そうするとそれに対していろんなフィードバックを関係各位からもらうわけです。

そのフィードバックの結果、修正をしたり納得いくならそのままコミット(適用)をしたり、逆に考え直したほうがいいのであれば取り下げたりとか、そういう形で物事を進めていきます。

ただし、これも誰かが承認するわけではありません。基本はやりたいことを言って、関係者に助言をもらう流れです。この「助言プロセス」を利用して、「全員CEO制度」を運用しています。権限や承認といったものがないので、面倒なプロセスを経る必要はありませんが、やりたいと言ったものには自分で責任を負う形です。

――自分たちで考えて、決定権まであるのは自由に思えますが、責任感も相当必要になってきますよね。

大城:ある程度は必要ですね。ただ一度決めたことに対して、別の人が上書きも可能ですし、見直しも適宜おこないます。決めたらそれっきりというわけではありません。

最後に「有給取り放題制度」ですが、成り立ちからお話しすると、親の介護や病気、育児でフルタイムで働けないから会社を辞めざるを得ないといった事態に対して、法定有給の期間を超えても会社がカバーする制度ですね。たとえば、突発的に数か月入院になってしまったら、法定有給を消化したあとって非常に不安になります。そこでこの制度を利用して安心して休んでいただいて、また会社に戻ってきていただくという感じです。

もしかしたら名称的には全員がずっと休んでいる時期があるみたいなイメージをされるかもしれませんが、実際の使われ方は少し違います。

――お聞きしていると、どちらかといえば社会保障的な制度に近そうですね。

大城:そうですね。あと、他の使い方としては、入社直後は法定有給がないので、新卒のメンバーがリフレッシュ休暇として利用するといったケースもあります。

特異な例ですが、アメリカで勤務をしたいからということで、そこへ行くあいだの部分を有給取り放題制度を使って、今はアメリカで働いている方もいますね。フルリモートなので、応募者の居住地も今はほとんど気にしていません。日本全国に社員がいますし、さきほどお話したとおり海外在住の者もいます。時差が大きすぎると合わない場合もありますが、プロジェクトによっては、保守を日本とは違う時間に分散するなどで有効に使える場合もあります。

特徴的な3つの制度をお伝えしましたが、他にもフレキシブルな働き方ができるよう「フルフレックス制」を採用していたり、リモートワーク環境を充実させるためにディスプレイや椅子の支給、またオンライン会議では音声が重要なのでいいコンデンサーマイクの購入費用が会社から出たりもします。また、「資格取得報奨金制度」では、対象となる資格や金額をさきほどの「全員CEO制度」で追加・変更も可能になっています。

※リモート下でも使える懇親会費用補助の「ミニレク」や、新入社員との懇親を目的とした「ウェルカムランチ制度」などを含め、記事内で紹介しきれなかったゆめみのユニークな制度についてはこちらをごらんください。

エンジニアの働きやすさのその先を見据えて

――それでは、最後に大城さんが考える、これからのゆめみのエンジニア組織の展望について教えてください。

大城:まずはなによりもお客さまに寄り添って、一緒にプロジェクトを進めていくことを大切にしていきたいですね。さらにその先にいるエンドユーザーに感動を届けるために、しっかりよいものを作っていけるチームでありたいと思っています。

そのためにもメンバーひとりひとりが技術力を高め、積極的にアウトプットをすることをより推奨していきたいと考えています。

今回、お話しさせていただく中でも「ゆめみオープン・ハンドブック」を何度か参照しましたが、こうして外部へ発信することで業界貢献につなげるため、情報の徹底的な透明性を大切にしています。今はまだまだ「ゆめみのユニークな制度」と言っていただくことが多いですが、仕組みや制度をオープンソースのように改良して広めていきたいとも考えています。もしゆめみのようなやり方を取り入れたい企業さんがいたら、一部だけでも参考にしていただいて、むしろわたしたちよりもっといいものを作ってほしいと思っています。

エンジニアの働きやすい環境をこれからも追求していくことはもちろんですが、最終的には社会全体がよくなることを目指しています。

――ありがとうございました。


Share