エンジニアにとって、本当に「働きやすい環境」ってどんなのだろう？ という疑問を解消すべく、組織づくりや職場環境に秀でたTech企業にインタビューを敢行するこの企画。インタビュアーは、エンジニアのためのポートフォリオサイト『Forkwell』や、エンジニア目線の求人・転職サイト『Forkwell Jobs』を運営する株式会社garbs取締役おおかゆかさん。エンジニアが「幸せに働ける職場」のあり方を探る！

株式会社garbs　取締役 Forkwellプロダクトマネージャー
おおか ゆかさん

関西学院大学経済学部を卒業後、独立系SIerを経てインフォシーク社に入社。楽天による買収後も含めて、インフォシークのログイン周辺機能や各種コミュニティサービスの開発を担当。その後フリーランスとして活動、業務委託で入ったgarbsで提案したエンジニアのスキルマッチングの企画が採用され、そのサービス『Forkwell』のプロダクトマネージャーとなり現在に至る。公式ブログ『表参道フォークウヱル別館』でエンジニア採用について辛辣に語る記事も評判

おおか　KAIZEN platform（以下、KAIZEN）さんは最近、A/Bテストのクラウドソーシングサービス『planBCD』の勢いがすごいだけでなく、他社でCTOを務めていたクラスの凄腕エンジニアが続々とジョインしていることでも話題です。今回は、その辺の事情をお話いただけたらと思っています。まずご同席くださった伊藤直也さんは、なぜKAIZENで技術顧問をされることに？

伊藤　実は、CTOの石橋さんがたまたま大学の先輩で。

おおか　へー、そうなんですか。

伊藤　在学中、同じバンドサークルに所属していたんです。当時、僕が住んでいた部屋が大学に一番近かったこともあって、石橋さんを含めてサークル仲間がちょくちょく来て、ずっとゲームやってたんですよ。

おおか　なるほど。石橋さんはKAIZENのCTOになられる前、リクルートのメディアテクノロジーラボに在籍していらしたと聞いていたので、どこで伊藤さんとつながっていたのか不思議でした。

石橋　まぁ、先輩・後輩の関係はさておき、技術面では僕よりも伊藤の方が断然知識があるので、最初は「ここが分からないから教えてほしい」ってお願いから始まりまして。

伊藤　石橋さんが僕のオフィスにたびたび遊びに来てくれたので、そのうち一緒にご飯を食べるようになって。そしたらある日、『planBCD』の事業企画書をいきなり渡されたんです。で、いつの間にか顧問契約を結んでました。

おおか　ほかのエンジニアも、そうやって口説いてきたんですか（笑）？

石橋　伊藤のようなつながりは特殊なケースで。初期のメンバーは元同僚や仕事仲間で、時の巡り合わせが良くて即意気投合、というケースが多かったです。その次は、地道に知り合いの紹介ベースで採用していました。KAIZENは毎月1回、平日にホテルの会議室を借り切って、合宿のような「戦略会議」を丸1日かけてやってるんですね。その会議には、KAIZENのスタッフそれぞれが知り合いや呼びたい人を招いていいことになっていまして。

おおか　平日の昼間だと、来られる人が限られるんじゃ……!?

石橋　それがそうでもないんですよ。わざわざ有給を取って来てくださる人もいます。気付くとゲストがミーティングを仕切ってくれたりと、皆さんモチベーションが高いんですね。

おおか　では、その戦略会議がきっかけになって、入社する方が多いわけですか。

石橋　ええ。この会議では、KAIZENの事業展開や『planBCD』のプロダクトロードマップなどについて、けっこう突っ込んだ課題をディスカッションするんです。もちろん、議論に必要ならばKAIZENの現状について包み隠さず話すので、「じゃあ俺が何とかしよう」と思ってくれる方が多いのかもしれません。

伊藤　KAIZENは立ち上がったばかりの会社ですし、突っ込みどころが多いんですよ、きっと（笑）。

今、スタートアップに30代以上の経験豊富なエンジニアが集まる理由

おおか　ところで最近、伊藤さんのグリー時代のご同僚でもある大場光一郎さんがクラウドワークスのCTOになられたように、スタートアップにも経験豊富なエンジニアがジョインするようになっていますよね。KAIZENさんもその好例だと思うのですが、なぜだと思われますか？

伊藤　うーん、何ででしょうね。僕がはてなで働いていた2000年代半ばに比べれば、投資環境の面でスタートアップのエコシステムがかなりでき上がってきた感がありますよね。最近は、スタートアップしたばかりの会社も、資金調達がしやすくなってますし。

石橋　そうかもしれませんね。

伊藤　それに、ネットの歴史を振り返ると、90年代は既存事業のWeb化がメインで、エンジニアは「会社の中心」にはなれなかったじゃないですか。それが2000年代に入って、少しずつエンジニアが中心になって作るWebサービスが脚光を浴び出した。そして、2010年代になった今は、エンジニアがいないといろんなサービスが存続し得ないほどになっている。

おおか　確かに。

伊藤　キャッシュフローが回りやすくなって、エンジニアの存在価値も上がってきたから、「これは！」と思えるスタートアップの開発現場に、経験豊富なエンジニアがチャレンジしやすくなったんじゃないかと。

石橋　そういえば、KAIZENは今、エンジニアが10人で20代は1人もいないんですよ。入社してきた時点で、奥さんや子どもがいる人も多い。

おおか　それはすごいですね。

石橋　もともと、KAIZENは創業当時からグローバル展開を視野に入れていて、開発もリモートワークを前提にした体制にしてきたので、マネジメントしなくても自走できる中堅エンジニアが採用の中軸になっていたというのもあります。

開発の質を上げるために行った、コミュニケーションデザイン

おおか　でも、他社でエース級の仕事ができるエンジニアばかりだと、チームとしてまとめるのが大変じゃないですか？ 実はForkwellも、開発チームにはRuby・Railsのコミッターでもある松田明をはじめ、業務委託のベテラン勢には実力派がそろっているので、けっこう舵取りが難しいんです。

石橋　KAIZENもそこが一番大変（笑）。それに僕の場合、前職のメディアテクノロジーラボでは少数人数で開発をやっていたので、この人数のチームで開発をした経験がほとんどないんですね。だから、チームマネジメントは今まさに勉強中です。

おおか　伊藤さんは前職のグリーで、大規模なチーム開発を経験されていますよね？

伊藤　そうですね。僕のKAIZENでの役割は、その経験則をチーム全体に伝えることが最も大きいかもしれません。

石橋　あ、それはホントそうで、だいぶ助けられてます。伊藤の役割を一口で言うと、KAIZENの軍師ですね。

おおか　官兵衛的な（笑）？

伊藤　まぁ、僕は20代のころから「俺がマネジメントやらなきゃ現場が回んないじゃん」という状況を経験しているので、チーム開発でどこが落とし穴になるかが肌感覚で分かっている方だと思います。

おおか　先ほど、石橋さんがチームメンバーを「マネジメントしなくても自走できる人たち」と評していましたが、そんなチームでも気を付けなければならないことはありますか？

伊藤　やっぱり、コミュニケーションの部分ですね。エンジニアには、よく「コードがあれば分かり合える」みたいに言う人がいますけど、そんなわけないでしょ、と。

おおか　じゃあ、ドキュメントなどもきちんと用意しておく体制に変えた？

伊藤　ええ。ただ、仕様書一つを取っても、形式的に書くだけなら意味がない。あれって、結局作った人の意図が伝わらなくて、現場が機能しなくなるじゃないですか。だから、「何でこういう仕様にしたのか」、「何で違う仕様にしなかったのか」という作り手の考えまでシェアしないとダメで。KAIZENは、いずれリモートワークを推進していく意向なので、なおさらこの辺のコミュニケーションデザインは大事になるだろうと。

石橋　伊藤が来る前も、開発チームでは2週間ごとに一回、それぞれのタスクの洗い出しと次の開発ミッションを全員で共有し合っていました。でも、チーム内のコミュニケーション法を変えてからは、2週間の“スプリント”がより濃密になったし、開発にもより継続性が出てきましたね。

コミュニケーションの粒度を上げるには、「履歴」より「意図」を記す

おおか　具体的に、伊藤さんが来てからどう変わったのか、ぜひ聞いてみたいです。

伊藤　まずやったのは、小さな突っ込みを入れることでしたね。「その機能変更の意図はみんなに話した？」とか、「ここのドキュメントはチーム全員に共有しておいた方がいいよ」、「自分でタイムボックス作ってやってる？」みたいな一言があるだけで、チーム開発は円滑になっていきます。

おおか　意識を変えることから始めたわけですね。

伊藤　ええ。その次にやったのは、『Qiita:Team』の導入です。僕が来る前、KAIZENではコラボレーションツールとしてConfluenceを使っていましたが、ツールの良しあし以前の問題として、みんなでドキュメントを残すという習慣がなかったみたいで。だから、コミュニケーションの粒度を上げるには、『Qiita:Team』がいいんじゃないかって提案をしました。

おおか　なぜ『Qiita:Team』がいいと？

伊藤　個人的な感覚として、触り心地の良いツールだったからです。もともと、はてなのエンジニアの間では、何か一つ開発したらすぐドキュメントをブログに残すスタイルが浸透していたんですね。

で、『Qiita:Team』を作っているIncrementsの海野（弘成氏・代表取締役）くんは、はてなでインターンをやっていたことがあるので、僕の感覚に近いんだと思います。

おおか　実際、導入後はコミュニケーションの粒度は上がりましたか？

石橋　すぐには上がらなかったですよ。最初は、伊藤なり僕なりがいろいろ書き込みながら、チーム全員の習慣を少しずつ変えていったという感覚です。

伊藤　そうですね。たまにどうでもいいことまで書いたりしながら。そういうのも、みんなが参加しやすくする要素の一つになりますから。僕がインフラにChefを導入する手伝いをしていた時も、「なぜ入れるのか」から「何に気を付けてこういう仕様にしたのか」など、すべての考え方をドキュメントに残すようにしてみたり。

石橋　さすがに、「あのnaoyaがここまでやるんなら、僕らがやらないわけにはいかないでしょ」みたいな空気になっていったよね（笑）。

伊藤　その後も、自分のタスクについてドキュメントを残してくれた人には、「それをもっとユーザーのメリットとして説明するとしたら？」みたいな突っ込みを入れながら、粒度を上げていくための触媒役に徹していました。

おおか　単なる開発履歴やステータスを記すではなく、「なぜユーザーに対してこれが大切か」、「これをすることでチームにどう貢献したいのか」という考えを共有することが大事なんですね。

石橋　「社内で暗黙知を作るな！」っていうのが、伊藤の口ぐせで。

伊藤　やったことは全部『Qiita:Team』に書こうということ、そして自動化はマストでやろうという2点は、かなり口うるさく言い続けました。

石橋　リアルだろうとリモートだろうと、お互いに考えをぶつけ合わないと、良いサービスって作れないと思うんです。

伊藤　だから、コミュニケーションの粒度が高まるようなツールを選定するのも大事だったというか。

知識を横展開できる人が「優秀」であるという文化

おおか　大きな会社だと今でもそういうところはあると思いますが、情報が古参の社員の頭の中だけにあって、何かをするにつけ彼らにお伺いを立てる必要があるみたいな環境とはまったく正反対ですよね。ただそれでも、何から何までシェアすることに抵抗を感じるメンバーはいませんでしたか？

伊藤　一昔前の開発現場ならば、それが自分のジョブ・セキュリティになっていたかもしれないし、「コードを見て技を盗め」的な不文律もあったかもしれません。でも今って、OSSの世界しかり、いかに自分の知識を横展開できるかが「優秀さ」の指標になってると思うんです。だから、知識を自分だけで抱えておくのはナンセンスですよ。

石橋　KAIZENの中途採用でも、このオープンさみたいな面はかなり重視しています。

おおか　それを知る上で、面接で必ずされる質問とかはありますか？

石橋　よく聞くのは3つです。1つは、公開しているソースコードはあるか？ ということ。2つ目はスクラム、アジャイルでの開発経験はあるかどうか。3つ目が、ユニットテストをどれくらい尊重してきたか？です。

おおか　その3つで、ある程度はオープンさなり、ナレッジ共有の姿勢なりが垣間見えると？

石橋　ええ。

伊藤　そもそも、今のWebプログラミングでは、もうコードそのものに資産的価値ってないですよね。GitHubなんかが象徴的だと思うんですけど、公開して、Pull Requestされ、次々に機能追加されていくコードの方が価値がある。だから、どんどん知識をシェアして、みんなで手掛けるモノを良くしていこうって志向の人たちが集まらないと、「良いWebサービス」の開発って難しいと思うんです。

おおか　その通りですね。

石橋　僕は大学卒業後、リクルートの制作グループ会社に就職したのですが、そこでは50～60代くらいのベテラン社員しか知らない技術があって、その人がものすごい権限を持っていました。何をやるにも、そのベテランの機嫌を損ねたら前に進まない、みたいな。

伊藤　Webサービスでも、一時、インフラ担当者がめちゃくちゃ権限を握っていた時期がありましたよね。

おおか　アプリ側はどんどん課題をクリアしていきたいのに、インフラ担当者のご機嫌次第で止まっちゃうとか……（笑）。

伊藤　でもその制約って、サービスを発展させるという観点で考えたら、本来バカバカしい話で。

おおか　ホントそうですね。それでは最後に、この連載のテーマでもある「エンジニアの幸せな職場」とはどんなものかを伺って終わりにしたいと思います。

伊藤　僕の答えはたった1つで、エンジニアにとって幸せな職場って、自分のやっていることが会社の何に貢献しているかが分かる職場だと思います。「椅子が豪華だ」とか「PCがデュアルディスプレイだ」みたいな環境面の充実だけでは、絶対に作れない。

石橋　僕も同感です。KAIZENが提供している『planBCD』で言えば、個々のエンジニアが取り組んでいることが、A/Bテストの精度なりにどう寄与しているのかが理解できるってことこそが、エンジニアにとって幸せな職場なんだと思います。マネジメント側からすれば、その感覚をチーム全員に持ってもらうことも仕事の1つになる。

おおか　その点、『planBCD』は顧客との距離が近いし、サイト改善の結果もコンバージョンレートなどですぐに分かるサービスなので、中の人も貢献度が分かりやすいですね。

石橋　ええ。ユーザーからのフィードバックも伊藤trong>伊藤　それと、KAIZENはまだまだ少人数の開発チームだから、自動化やんなきゃねって話して、どんどん実践していくのも、「貢献」の一つですよね。

石橋　うん。ウチも今後はクロスブラウザなQuality Assuranceプロセスの自動化なんかもやっていかなければならないしね。

おおか　本日は、優秀な人材獲得法から円滑なチーム開発のやり方まで、いろんな切り口でお話いただきわたしも非常に参考になりました。どうもありがとうございました！

文／浦野孝嗣　撮影／竹井俊晴