既存の手法やフレークワークを安易に取り入れるのではなく、最高のアウトプットに向けて自分たちの頭を使ってゼロベースで、フルスクラッチで考えるーー これはプレイドのソフトウェア開発において、軸となっている思想です。

決して真新しいことを言っているわけではありませんが、徹底するのは思っている以上に大変で、面倒。だからこそやりがいや、面白さも大きい。開発体制をリードする門脇はそのように話します。

今回はそんな門脇にプレイドの開発体制と、その背景にある考え方について聞きました。

【門脇 恒平】プレイド ソフトウェアエンジニア / テックリード

同志社大学大学院工学研究科修士課程修了。2012年に共同創業者兼CTOとして株式会社シェアウィズを起業。2014年に株式会社リクルートテクノロジーズに入社しタウンワーク開発チームのTech Leadを務める。2017年4月にプレイド参画。

常に最適なやり方を選べる“可変組織”
ーー 早速ですが、実際の開発体制やプロジェクトの進め方について教えてください

門脇：まず大前提に「その時の状況に応じて各々がもっとも良いと思った方法・やり方を決めて取り組む」という考え方がベースにあります。とはいえ、俯瞰的に見た際の枠みたいなものはあるので、最初に紹介しますね。

現在プレイドには約30名強のエンジニアがいて、全体的な「KARTEをどのように進化させていきたいか」という方針のもと、いくつかのチームに分かれます。たとえば、KARTEの面を広げるための新機能を作る軸、お客さんが増える中で既存のKARTEをもっと強くする軸、非連続な成長を生み出すために全く新しいことをやる軸、といった形で軸を決めて複数のチームを作るんです。このチームのことをプレイドでは「フォーカス」と呼んでいます。

そして一定期間ごとにサイクルを区切って、何回も何回も繰り返す。今は1回のサイクルを2ヶ月間としていて、少しややこしいのですがこの期間のことも「フォーカス」と名付けています（1フォーカス=2ヶ月）。

まず最初に各チームで「この2ヶ月間でどういった状態を達成したいのか、それが達成したと言える具体的な判断基準は何か」を決めてもらって、あとは2ヶ月間それぞれに適したスタイルでひたすら突っ走る。僕やCTOの柴山が全体を俯瞰的に見てサポートすることもありますが、僕たち自身も特定のチームに属して実際に手を動かしているので、基本的に個々のやり方はけっこうバラバラで各自に任せています。

ーー たとえばどのようなチームがあるんですか？

門脇：一例をあげると3月に立ち上げた「KARTE for App」という新規プロダクトを開発しているチームがあります。機能面だけでなく販売や営業戦略も含めて担当しているのですが、このチームも最初はビジネスサイドのメンバーとエンジニアが1人ずつの2人体制でスタートしたんです。

本当に力を入れる価値があるのか、プロトタイプなどを作って検証しながら拡大して、今は10人ほどのチームになりました。もはや社内の中に小さなスタートアップがもう1つできたような感覚で動いています。

そんなチームもあれば、一方で1人のチームもあるんですよ。そのエンジニアは最近GDPRや個人情報の取り扱いに課題意識を持っていて、その領域で何かしらやりたいという思いで取り組んでいます。

ーー 人数もそうですが、チームごとに取り組んでいる内容の具体度もだいぶ違いますね

門脇：何かやりたいということで、じゃあやってみようぜと。この2ヶ月でまずは形を作ってみるところから始めて、次のフォーカスでより具体的な状態にすることを目標にしてみましょう、といったように進めています。

先ほどのKARTE for Appにしても最初はそんな感じで始まっていますし、何かガチガチに要件や計画を決めて取り組むということはほとんどないです。

進め方も、これまでの延長線上で考えないということを大事にしているので、その時々で本当に1番いいやり方を選べるようにしたいと思っています。極端な話、今の体制がめちゃくちゃ変わる可能性もありますし、僕自身も今後がどうなるかはわからない（笑）。

フォーカスは手段であって目的ではないので、ゼロベースで考えた時に別のやり方のほうが良ければ、そっちの方がいいと思っています。実際この1年の間でも進め方はかなりカスタマイズされてきていて、1フォーカスの期間も以前は4ヶ月、その前は半年以上でした。

自分たちにとっての最適は、自らフルスクラッチで考える
ーー 「ゼロベース」というのはプレイドの開発組織において重要なキーワードですね

門脇：「自分たちの頭でフルスクラッチで、ゼロベースで考えよう」という思想は、開発だけでなく全社的に浸透しているかなと思っています。開発体制に関してお話すると、様々なシーンで「世間一般で使われるような言葉をなるべく使わず、あえて別の名前をつけてみる」ようにしているんですね。

よく使われる「スクラム」や「イテレーション」だったり、目標管理の手法として知られる「OKR」だったり。これらの言葉の方がイメージはしやすいかもしれませんが、一般的な言葉のラベルが付いていることによって、どうしてもそのラベルに紐づく世間一般的な考え方に引っ張られてしまうのではないかという考えが根本にはあります。

外の世界で上手くいっているものをなぞることが、本当に良いのか。うちの会社の環境やメンバー、プロダクトの状況には何らかの特徴があって、必ずしも他で上手くいったことがハマるとは限りません。だから既存の枠組みでやることが目的にならないように、あえて名前を変えるんです。

「フォーカス」もまさにそうですし、あえてOKRではなく「ミッションと目標」という言葉を使っていたりします。自分たちの言葉だと定義が曖昧だったりすることもあって、なかなか外の人に伝えるのが難しい面もあるんですけどね（笑）。

ーー その点では既定の仕組みやルールを使った方が簡単というか、フルスクラッチでゼロから考えることによって自分たちで難易度をあげている側面もありますよね

門脇：それはよく思います。この会社に来る前には使ったことがなかった頭を使っているイメージがあって。前職でも開発スピードに課題がある事業に対して、機敏に動けるようにスクラムを導入する仕事をしていたんです。目的を考えるとスクラムだけにこだわる必要はなかったのに、今考えると無意識に「スクラムありき」で進めてしまっていた自分がいて。

それに比べると最高のアウトプットのために毎回ゼロベースで考えることは難しいし、1つひとつ説明しながら進めないといけないので、すごく大変なんですよね。1人ひとりが、1フォーカスごとに何を目指していているのかを踏まえて、毎回しっかりとコミュニケーションをとっていかないといけない。

そういった脳みそを使うということが、入社して1番のギャップでした。正直今でも全然できているとは思わないですが、それでも以前よりは成長していると感じられる。それがこの会社で開発をしていて1番のやりがいというか、面白いところです。

ーー 実際に最近何か面白さだったり、刺激を感じたようなシーンはありましたか？

門脇：一応全体のスケジュールのようなものはあるため、とあるチームで具体的に細かく見積もってから確実に進めたいという人がいたんですね。それに対して別のエンジニアから「それはやらない方がいい」という意見があって、議論をしたそうなんです。

エンジニアが言うには「見積もりを立ててスケジュールを引いてしまうと、レールができてしまう」ので、エンジニアの働き方やプロダクトもレールに乗ってしまう力学が働くのではないかと。

そのチームで作っていたのはまだ世に出したことのないプロダクトだったので、「自分たちもこの機能にどういった価値があるのか、可能性があるのかを全部わかっているわけではない。だからもっと自由に発想して新しい価値を生み出すことにフォーカスすべきで、それを抑制するような要素は微塵も入れるべきではない」という趣旨の話をしたらしいんです。

それを聞いた時にすごく刺激をもらったというか、心を動かされたんです。僕自身もやっぱりどこかで線を引いた方がいい、見積もった方がいいという前提がありましたが、その人は「この前提は本当か」と立ち返って考えたのだと思って。プレイドの開発チームで大切にしていることを、ものすごく体現しているシーンのような気がしたんですよね。

エンジニアが本質的な仕事に没頭できる環境を作る
ーー 門脇さんが入社してから約1年半の間でも、プレイドの開発組織はどんどんアップグレードしていますよね。門脇さん自身の考え方にも変化はありましたか？

門脇：もともと起業していたこともあって「どんなプロダクトを作るか」「どういう価値を生み出せるか」など、アウトプットに対する意識やこだわりは強かったんです。ただ意識はしていたけれど、どこか上手くいっていないような部分がありました。

その意味で目指している方向自体は大きく変わっていないですが、本気でアウトプットやプロダクトの価値に対してコミットした時に、「こういうやり方があるんだ」と新しい方法や考え方に気付けたのはプレイドに入ってからですね。

難しい道ではありつつも、突き詰めていけば他とは違う面白いもの、価値があるものを作れるんじゃないかという感覚もあって。とはいえ、まだまだ改善の余地もありますし、この先もしかしたら今の考え方や文化を変えていく必要がでてくるかもしれない。だからこそ、なるべく凝り固まらないように模索していきたいなと思います。

ーー 門脇さん自身はどのようなミッションを掲げていきたいですか？

門脇：まだ上手く整理できていない部分はありますが、このような開発体制をなるべく自分1人ないし2人くらいで全部フォローできるようにして、他の開発力が優れているメンバーや発想力に秀でているメンバー、ビジョンがすごいメンバーがそれだけに集中できるようになるといいですよね。

「圧倒的に突き進める尖った人たちが、プロダクトを尖らせるのに必要な本質的な仕事に没頭できる状況を作る」ということを1つの目標にしていきたいです。