新しい組織の形を研究する宇田川元一さん（埼玉大学大学院人文社会科学研究科准教授）から、ソニックガーデン代表の倉貫義人さんへのインタビュー。中編は、「リモートチーム」というワークスタイルや「納品のない受託開発」というビジネスモデルを支える人材採用や育成の話をお伝えする。
（「1.働き方編」はこちら）

Webで課題をクリアしたら面接に進む、独自の採用プロセス

宇田川： 『リモートチームでうまくいく』には、社員がそれぞれ「日記」を書いてお互いに共有しているとありました。日記にどんなことを書いてるのか、すごく気になります。

倉貫： 個人的なことから仕事のことまで、なんでも書きますね。もともとは「日報」と言っていたんですが、日報だと仕事のことしか報告しない。報告なんかなくてもちゃんと仕事しているのは知ってるから、ということで日記にして、その人が感じていることを書いてもらっています。
その人がどういうことを考えてるのかとか、今日どういうことがあるのかとかが分かるようになるんです。

宇田川： そういうことって、大事ですよね。

倉貫： チームで働く時に、お互いのバックグラウンドや考え方を知るということは、とても大事です。僕らが家族ぐるみで旅行に行ったりするのも、「子どもが熱をだしたので、今日休みます」と言われた時に家族に会ったことがあれば「◯◯ちゃんだったらしょうがないか」と、優しい気持ちになれますよね、
でも、これは別にリモートかどうかは関係なく、普通の会社でも大事なことなんですよね。みんなやらないけど。

宇田川： そう思います。でも、日記にプライベートなことを書いて共有するということを、躊躇する人もいますよね。

倉貫： そうですね。でも、そういう人は採用の段階で振い落とされていると思います。

宇田川： どうやって？

倉貫： 会社で家族ぐるみのイベントをしたりといったことは、僕もブログにたくさん書いているので、それを知った上で来ているでしょうし。

宇田川： そもそも応募してこない？

倉貫： そうです。それと採用の仕方もちょっと変わっていて、応募されてから実際に入るまで半年以上かけるんですね。

宇田川： 長いですね。

倉貫： 僕らの会社は履歴書を一切見ないので、今いるメンバーも前職や出身大学を知らない人ばかりなんです。どうやって選考するのかというと、いきなり面談をするのではなく、「トライアウト」というしくみがあって、まずは必要な課題をやってもらいます。
会社のホームページには採用に関してたくさんのことが書いてあるんですけど、最後まで読むと「トライアウトに挑戦する」というボタンがあります。これを押すと、例えば「こういうプログラムは書けますか？」というような技術的なチェック項目がたくさんあって、これをひとつひとつ実行して結果を入力してもらいます。もうひとつ、作文の課題があって、「エンジニアが提供する価値は何だと思いますか？」とか「強みは何だと思いますか？」といった質問に文章で答えてもらいます。
この質問のひとつに、「家族が一緒に旅行に行ったりするイベントは、どう思いますか」というのもあるんです。そこで、「僕はそういうの、あんまり好きじゃないです」とか、「プラベートと仕事は分けたいです」と書いてあったら、「うちで働くのは、ちょっと難しいかもしれないですね」と言います。
みんなこのトライアウトを受けて、その後でようやくオンラインで面談するんです。このとき、どうしても対面で会いたいという人は、不採用です。会わないと情熱伝えられない人は、その後やっていけないので。

宇田川： なるほど。

プログラミングが大好きで、お金よりも時間が大事だと思っている人に来てほしい

宇田川： 他に、「こんな人はソニックガーデンで働けない」というのはありますか？

倉貫： プログラミングが好きじゃない人は働けないですね。
それから、チームで仕事することが大事なので、コミュニケーションが嫌いという人は、採用できないです。よく勘違いされるんですけど、人と触れ合わなくていいのでリモートワークをしたいと言われたら、「無理だよ」と言います。むしろコラボレーションとかチームワークは非常に多いので、人と話すのが好きな人でないと無理ですよと。
それと、大金持ちになりたい人は僕らの会社では採用できません。「フェラーリ買いたいです」という若者がいたんですけど、うちでは絶対買えない（笑）。「フェラーリ買いたかったら、死ぬほど働けるか、一山あてるかできる会社に行った方がいいよ」と言いました。
上場してみんなでお金持ちになろうという会社じゃないし、外資系みたいにバリバリ働いてその分稼ぐということもできない。お金よりも時間の方が大事だと思ってる人じゃないと働けないですね。

宇田川： 変な風に聞こえたら恐縮なんですけど、「一人前」になれば給料は一律で、みんなお金のことを気にせずに目の前の仕事に一生懸命になれるというお話を聞いて、ある意味理想的な共産主義に近いのかな、と感じました。

倉貫： たまに言われます（笑）

宇田川： ですよね。ソ連みたいなところが大失敗したのは、要するにモチベートするものをうまく作れなかったということですよね。だけど、みんなエンジニアで、いいものを作って喜んでもらえることにモチベートされているから、むしろこの方が楽しく仕事ができると。

倉貫： そうです。だから僕らは、プログラマーの仕事が天職だと思ってる人を採用しているんです。
僕らの会社のビジョンのひとつに「プログラマーを一生の仕事にする」というのがあります。プログラマーの仕事が楽しくて誇りに思っているので、どこかで引退するのではなくて、死ぬ間際まで細々とでもずっと続けていきたい、そんな人たちが集まっている会社なんです。プログラミングを頑張ること、そのスキルを上げることが一番のモチベーションなので、もう外発的動機は要らない。みんな放っておいても仕事するわけです。

3つの契約形態に関わらず、全員社員としての権利と義務を持つ

倉貫： 長く一緒に仕事をしたいと思っているので、「ソニックガーデンで経験を積んで、他に行きたいです」という人もお断りしています。自由な会社なので、やりたいことがあればうちの会社でやればいいし、住む場所も自由。価値感さえ合っていれば、辞める必要がないんです。

宇田川： 辞める人はいないんですか？

倉貫： 「修行中」で辛くて辞めちゃう人はいますけど、「一人前」になって辞めた人はいないですね。
ただ、入る時に会社との契約関係を選べるようにしています。普通の雇用契約を結ぶか、フリーランスとして契約を結ぶか、会社と会社で契約を結ぶか、その3パターンで「どの契約書がいい？」と言って選んでもらうんです。「自分で会社を持っているので、その会社から請求書を出す形で契約したい」という人もいれば「今までフリーランスとして青色申告に慣れているので、そのままでいきたい」という人もいる。逆に「子どもを保育園に入れるのに雇用証明が必要だから雇用契約にしたい」という人もいますね。
どの契約でも、ソニックガーデンのメンバーとして平等に扱われます。同じ仕事内容で、名刺も持てる、ホームページにも載る、社内で見られる情報や使える経費も同じ、合宿にも参加します。給料も一緒です。雇用契約だと保険料が天引きされて、フリーランスの人は天引きされずに自分で払うので、そこは調整して、手取り額が同じになるようにしています。
あらゆる権利が一緒で、信頼関係があれば、社員なのかフリーランスなのか、他の会社の経営者なのかって、あんまり関係ないんですね。物理的な契約書が違うだけ。僕らはそれを「論理社員」と呼んでいます。そういう感じなので、日本の法制度上の会社と会社員の関係では、もはやないんです。

宇田川： そうなんだ（笑）

倉貫： 普通の人からすると意味がわからない状態かもしれないですが（笑）

宇田川： 考えるスピードが追いつかないですけど、まあでも、そうか……。

トップチームとファーム、レベル別チームで、助け合いの起きる組織に

宇田川： さっきのお話ですごく興味が湧いたのが、「一人前」と「修行中」という制度です。ジェダイの騎士（映画『スター・ウォーズ』シリーズでフォースを操って戦う人々）みたいですよね。『リモートチームでうまくいく』を読んでいても感じたんですが、ソニックガーデンというのは、徒弟制に近いというか、ジェダイコミュニティみたいです。ある種のヨーダ（ジェダイの最高指導者）のような中心に向かって、みんなが必要に応じて学び、高みを目指すというような、そんな雰囲気。
向いていない人は雇わないとは言え、新しい人が入ったら最初から一人前ではないわけですよね。入社後は、どんなところが変わっていくんでしょう？

倉貫： 確かに徒弟制なんですけど、教えることはあまりしてないですね。
まだ10人ぐらいの時はチームがひとつしかなくて、中途採用で入ってきたらみんなで教えていました。プログラマー連中なので、手取り足取りというよりは、背中を見せて育てるみたいな感じでしたね。
20人超えてきた頃からは、1チームでやるのが難しくなりました。できる人とできない人のレベル差ができすぎちゃったんですね。昔からいる人たちも腕を磨き続けるので、ずっとレベル高くなっていきます。そうすると、トップクラスの人と中途で入ってきた人の差が結構大きくなっちゃって。お互い助け合おうと言っているわりには、できる人の方は助けるばかりになります。自分のことをもっと頑張りたいのに、人の面倒を見なきゃいけなくなってしまう。助けられる方は、助けられるばかりで自分は役に立たない人間だと感じちゃう。それは良くないので、どうしようかと考えて、会社をチーム分けすることにしたんです。
普通の会社の発想だとA事業部、B事業部、C事業部に分け、各チームでちゃんと教育と管理をしようという形で、それぞれに部長を付けて、ベテランと新しく入った人をバランス良く配置をするんだと思います。

宇田川： そうですね。

倉貫： それも一瞬考えたんですけど、やめたんですね。それをすると、管理職が生まれてくるんですよ。僕は管理するのが嫌いです。働いている方も管理されたいと思って仕事してるわけじゃないし、特に中間管理職って世の中の必要悪の代表で、そんなものは無くせばいいと思ってます。だけど、さっきの縦に割るチーム分けをすると管理職ができちゃう。エンジニアの人たちは、せっかくソニックガーデンでプログラマーを一生の仕事にできる、腕を磨けると思って入ったのに、キャリアアップしたらマネージャーにならないとダメだって言われると、「何のためにうちに転職してきたの？」となっちゃう。
一生プレイヤーでいたいという人たちばかりの世界を、どうチーム分けすればいいのか考えた結果、「一人前」と「修行中」でチームを分けることにしました。
一人前の人たちのチームを「トップチーム」と呼んでいます。修行中の人たちのチームのことを、なんと「ファーム」と呼んでます。プロ野球で二軍のことです。会社の中を一軍と二軍で分けて、普通の会社だったら、やる気が起きなくなっちゃいそうですけど、僕らは別に全然問題ない。実力の違いは本人たち自身がよく分かっているので、分けましょうと。
トップチームはトップチームで仕事をする。そうすると、これまで助けるだけだった人たちが、同じトップの人同士、助け合いができるようになります。助け合って頑張ればいいので、管理者はいりません。
ファームはファームで、決してここで終わりじゃなくて、みんなトップチームを目指して努力します。それまでは、中堅ぐらいの人が伸び悩んでたんですね。トップクラスと入りたての人がかなりレベル差がある中で、中間ぐらいの人はどっちつかず。頼られることもないし、頼るのも難しいみたいな状態だったんです。でも、ファームの中では中間ぐらいの人が先輩になるので、「自分がなんとかしなきゃ」という意識が芽生えてくる。中高一貫だと中学3年って、あんまり自立心が芽生えないですけど、中学と高校が分かれていると中3はがんばりますよね。だからファームはファームで助け合いが起き、情報共有できるようになって、そこもマネジメントは要らないんです。
だから、あんまり教育してないですね。それぞれのチームで自分たちで努力してもらう、勉強してもらうという感じです。

求められるのはプログラミングとコンサルティングの能力、助け合いの精神

宇田川： できるできないというのは、いいプログラムを書けるかどうかの違いだけですか？

倉貫： いいプログラムを書けることと、コンサルティング能力ですね。
エンジニアが直接お客さんから話を聞き出して、なんだったら「こうした方がいいんじゃないですか？」と提案をして、問題解決の手段としてプログラムを作ってあげないといけないので、コンサルティング能力とプログラミングの腕は必須です。

宇田川： 助け合うこととかはどうなんでしょうか？　そういうのもやっぱり能力というか、一人前には必要なことですか？

倉貫： そうですね。助け合うって具体的に何をしてるかというと、一番わかりやすいのはソースコードのレビューです。
僕らはドキュメントを一切書かない会社なので、成果物はプログラムしかない。自分が作って、自分しか見ていないプログラムをそのまま運用するのはやっぱり怖いので、必ず誰かがチェックしましょうということをやっています。
トップチームならトップチームの中で、「コードレビューお願いします」って投げたら、時間が空いてる人が「自分が見ます」と言って自主的に見るので、他人のコードを見るという助け合いの精神は、必要ですね。

宇田川： それは、プログラミングが好きだと面白いんでしょうね。僕も大学院の後輩とかの論文を、「ちょっと学会誌に投稿する前に読んでコメントください」とか言われて見ることがありますが、それが結構面白いんです。

倉貫： 人のソースコードをレビューするのは、面白いですし、自分の勉強にもなりますね。「なんだ、こんなライブラリー使えるんだ」とか。

宇田川： そうそう、「こんな文献あるんだ」みたいな。結構似てますね（笑）

オンライン会議に同席し、コンサルティングの仕方を学ぶ

宇田川： プログラミングやコードレビューをできる能力とコンサルティング能力は、関連しているんですか？

倉貫： いえ、それはあまりないです。さっきレベル差があるという話をしましたが、そうは言っても僕らの会社に来る人達って、プログラミングではエース級の人たちなんですね。どこかの会社でCTOをやってましたとか、フリーランスですごい稼いでましたみたいな人が入ってくるので、技術力は相当高い。でもコンサルティングの方は未知数の人が多くて、入ってから経験を積んでもらう必要があります。
難しいのは、コンサルティングは正解がないんですね。こうしたら絶対うまくいくというパターンもないし、お客さんや、お客さんがの課題によっても違うので、毎回自分で考えて解決しなければいけない。プログラマーが苦労するのは、そこです。ロジックが好きなので正解を欲しがるんですけど、「正解はない」というのを認めなければいけないのが、結構みんな苦労するところです。

宇田川： それについては、コードレビューみたいに、みんなで助け合える場があるんですか？

倉貫： あります。コンサルティング能力を磨くには実地でやるしかないと考えまして、お客様との打ち合わせにメインの担当者だけでなく、必ずサポートのメンバーも出るようにしています。話すのはメインの担当者ですが、横でメモを書いたり、何かあったときに代わりにものを作ったりできるようにするためのサポート要員。そこに修行中の人が入って、先輩のやり方を学んでいます。それも、僕らがリモートでやっているから、やりやすいんです。

宇田川： マニュアル化できないものってありますよね、感覚みたいなもの。同席することでそれを学んでいくということでしょうか？

倉貫： そんな感じですね。うちの会社はマニュアルがない、というかマニュアル化できる仕事がないんですね。マニュアル化できる仕事は、全部プログラムを組んで自動化しちゃうので、人がやるルーチンワークとか雑用ってないんですよ。

振り返り（KPT）で組織の価値感を伝える

宇田川： そうやって実地で学んでいく他に、本に書かれていた振り返りとか、日記、合宿なんかも、教育の機会になっているんじゃないですか？

倉貫： はい。振り返りというのは僕らの教育の一貫で、先輩社員と入りたての社員が、マンツーマンでやるんですね。最初は週に1回ぐらいのペースで「1週間やってみてどうだったか？」とか。
KeepとProblemとTry の頭文字をとった「KPT」というフレームワークを使って、業務の内容というよりも、自分の対応の仕方の良し悪しについてメタな視点で振り返ってもらいます。過去1週間について、まずは良かったことをリストアップしてもらいます。それがキープ（K）ですね。次にプロブレム（P）、良くなかったことを挙げてもらいます。本人がKとPを出したところで、先輩社員がそれについて、「確かに良かった」とか、「これは本当に問題なのか？」とか、「これはキープって書いてあるけど実は問題じゃないか」とか、そこで軌道修正をしてあげるんです。
そこで僕らがやっているのは、会社のカルチャーだとか、価値観だとかを伝えるということなんですね。そしてそのフィードバックを踏まえて、トライ（T）ということで、来週やること、改善することを決めます。つまり、KPTというのは個人個人の改善プロセスなんです。
若い人とか中途の人でよくあるんですけど、「お客さんが困っていて、どうしてもやってほしいと言われた。だから夜も頑張ってなんとか翌日に仕上げました」というのを、「良かったこと（Keep）」として出してくるわけです。でも、先輩社員は「うちの会社では、それはKじゃないよ」と言ってあげるんですね。そんなことしちゃうと麻薬みたいなもので、ずるずると時間をかけて仕事をするようになるし、お客さんも言えばやってくれるものだと思っちゃうので、良くない。ソニックガーデンとしてはProblemですと。
言われた方は、もしかすると以前の会社では褒められていたことが、ソニックガーデンだと怒られるという経験をして、結構ショックを受けます。その時その時で、これはいいよ、これは違うよっていうのを伝えて、価値観の矯正をしているわけです。

一生懸命真面目にやるよりチートしよう

宇田川： お客さんから「何とかやってくれないか」と言われた時に、どう対応するのがソニックガーデン的には正しいんですか？

倉貫： 僕らの場合、「そもそもそれ、本当に必要なんですか？」と聞きますね。「本当に明日までに全部必要なんですか？」と聞いて、「どうしても全部やれ」と言うようなお客さんだとしたら、「無理なものは無理ですよ」と言うしかない。だけど、「実はこういう理由があって、ここだけユーザーに見せなきゃいけないんだ」とったことであれば、その部分だけまず作りましょうといった話をします。
「そもそも」というのも僕らの会社のキーワードです。「そもそもそれ必要ですか？」って、良く聞きますね。なぜなぜ分析をしてもあんまりいいことはなくて、「そもそも」を考えて仕事しましょうということです。

宇田川： 「その問い自体は、そもそも必要なのか」を考えるべきだ、ということですね。それは僕の領域では、「問題解決ではなく問題解消をせよ」という言い方をしますね。
問題解決、Problem Solvingは目の前の問題を何とか取り除くということだけど、問題解消はProblem Dis-solvingで、Dis-solve、つまり、解かないという意味と、Dissolveは融解する、溶けるという意味の両方がある言葉です。

倉貫： 問題そのものをなくしちゃえばいいんですよね。僕らのやり方は完全にそれです。生産性を上げようという話でも、普通の会社は100メートル走をどれだけ速く走れるのかを考えるんですね。でも、「50メートルでゴールなんじゃないの？」って考えたら圧倒的に生産性上がるよね、というのが僕らの発想なんです。ゴールを再定義する。僕らは会社の中では「チートしよう」と言うんですね。チートってゲーム用語ですけど。

宇田川： ズルですよね。「ドラクエ」とかちょっといじって、レベルがすごくあがるようにする、みたいな。

倉貫： 「スーパーマリオ」も1面1面ちゃんとクリアするよりも、2面で土管に入って一気に8面まで行くみたいな。

宇田川： （笑）

倉貫： そういう発想の方が偉いよっていうのも、KPTで言うんです、一生懸命真面目にやってる社員がいたら、「そんな真面目にやってどうするの？　ラクする方法を考えた方がいいんじゃないの？」って。ズルした方が偉くて、真面目な社員が怒られるんです。

宇田川： 真面目に一生懸命というのは、富国強兵とか、近代化の時代だったら必要かもしれないですけど、今は違いますからね。

倉貫： そう。仕事の種類が違うんです。僕は、とワークかナレッジワークの違いが大きな鍵だと思っています。ルーチンワークはズルできないので頑張るしかないけれど、ナレッジワークはできるだけズルした方がいいんじゃないかって。

宇田川： 逆に、ズルすることに、一生懸命取り組んだ方がいいってことですよね。

倉貫： プログラマーの世界の格言で、楽をするための苦労はいとわないっていう言葉があるんですね。同じソースコードを何回も書くぐらいだったらライブラリーにしちゃう方がいい。ライブラリーにするのは頭を使わなきゃいけないので結構大変だけど、真にラクをするために、そっちの苦労をするべきだということです。

宇田川： その感覚を身につけて頭の使い方が変わると、一人前にだんだん近づいてくわけですね。僕はプログラミングは分かりませんが、一生懸命書くんじゃなくて工夫すればシンプルで高機能なものができる、みたいなことがあるわけですよね。

倉貫： そうです。一般的に生産というと、たくさん作ることがいいことなんですけど、プログラムの場合は短い方がいいコードなんです。同じことを実現するのでも、コード量が少なければ少ない方がいい。なので、生産量をコード量で測っちゃうと、コピペでひどいコードをいっぱい書くというような、愚かしいことになってしまうんですね。これも、僕らの会社では評価がないというのと繋がっています（社員の評価をしないという話については「1. 働き方編」参照）。
プログラムはずっと使われ続けるので、もしかしたら1年後2年後にバージョンアップしたくなって直すということになるかもしれない。その時に、もとのソースコードが良ければ直すのも簡単ですが、ひどい場合は直すのにすごいコストがかかるんです。ということは、今作ったものが、1年後2年後に効いてくる可能性があって、この1ヶ月や2ヶ月という短期間でエンジニアを評価することはできないんですね。だから、エンジニアは評価しない方がいいんじゃないか、というのが僕らの考え方です。

（「3．組織風土・イノベーション編」へ）

☆☆
関連記事

• 経営学者が聞くソニックガーデンの哲学【1.働き方編】（宇田川元一埼玉大学准教授×倉貫義人ソニックガーデン代表）
• 経営学者が聞くソニックガーデンの哲学【3.組織風土・イノベーション編】（宇田川元一埼玉大学准教授×倉貫義人ソニックガーデン代表）
• 好きな場所に暮らし、好きな仕事に打ち込む働き方
• 在宅勤務・テレワークを導入するなら読んでおきたい『リモートチームでうまくいく』

☆☆
文・撮影／やつづか えり