「全員がコードを書く」より「機能をどれだけ早く出すか」が重要　“シニアがいない”開発組織で、手戻りを起こさない工夫

半年で3つのサービスをリリースするために組織面で意識したこと

横江亮佑氏（以下、横江）：他になにか「こういうところを工夫したよ」みたいなところはありました？　最初は未経験のエンジニアの方も多いじゃないですか。

村下瑛氏（以下、村下）：どうだろうな。けっこうGraphQLのオンボコスト（オンボーディングのコスト）は低かった印象があって。クライアントが自動生成できるのも大きかったんですかね。特にフロントエンドはほとんどオンボーディングする必要なくキャッチアップしてくれた印象はあるんですけれど。なんかありますかね。

横江：定期的に勉強会を開いたりとかはなかったんですかね。

村下：スポットで支援（する）みたいなことはやっていましたが、特別なことは特にないかもしれない。でもそれでいうと組織図のことが大きかったかなとは思っています。

（スライドを示して）これもなんかちょっと恥ずかしいんですが、僕はあまり図を作るのが得意じゃないのでテキストで書いているんですけど。

横江：いや、わかりやすいですよ。

村下：組織面で工夫したことの1個は、1つずつ実装を知るというところですね。「チーム全員で1つの機能を実装しようぜ」というところは、けっこう大切にしていたかなと思っています。

リソース効率とフロー効率というものがあるんですけれど、急いでいるとリソース効率を上げてしまいがちだなと思っていて。要は「みんなが100パーセント、コードを書いている状態がいいよね」というところで、機能を分担して進めようとしがちだと思うんですけど。

横江：そうですね。だいたいの会社で普通はそうしますよね。

村下：僕はそれはけっこう効率が悪いと思っていて。やはりチームワークがおざなりになっちゃうんですよね。例えばレビューとか、「他人のレビューをするより自分の実装しなきゃ」みたいな気持ちになっちゃうし。あと文言調整とか、「オペレーション的にこれじゃダメじゃない？」みたいなことに気付きづらくなっちゃったり。

結果、みんなコードをメッチャ書いているけど、実は遅いみたいなことって多くなるかなと思っています。

本当に必要なのはフロー効率というか、「その機能がどれぐらい早く出たのか」が一番大事だと思っています。弊社はけっこうそこを重視しているので、基本的に1チームで1つずつやっていくスタイルですね。

横江：それは何ですか？　モブプロみたいなことなんですか？　どういうイメージですか？

村下：タスク単位ではもちろん分担するんですが、APIとフロントとかで分担をして、でもレビューは最優先するとか。ペアプロはもちろんやるんですが、例えば機能を1人ずつ担当して並行実装するみたいなことはしない感じですかね。

横江：1機能を作ることを分担するイメージなんですかね。

村下：そうですね。できる限り1つのことをみんなでやるみたいな。

横江：すごいですね。初めて聞くな。それはなかなか分担も大変そうですね。

村下：そうですね。でもそれによって、例えばジュニアの子がつまずいたとしても、他のチームメンバーに助けてもらいやすくなるとかの効果もあったり。だからペアプロで一緒に解消したり、そういうところでけっこうオンボ（オンボーディング）がしやすくなった部分もあるかなとは思っています。

横江：メッチャおもしろいですね。ちょっと参考にしたいな。

1チームで1機能ずつ開発を行う場合のタスクの切り分け方

横江：質問がきていますね。「その場合のタスクの切り分け方とかが気になります」。そうですよね。そこ（タスクの切り分け方）は実際難しいなと思う。このやり方は今も続けているんですか？　

村下：けっこう続けていて、タスクの切り分け……。そうだな。ストーリーという単位だと、確かに1つずつはけっこう限界があると思っているんですが、Epic単位ではやっていくイメージです。

フロントエンド、バックエンド、あとスキーマ定義とか。でも、そんなにメチャクチャ高度な切り分けはしていません。なんでしょうね。ちょっと最近の良い例はありますかね。

横江：そうですね。そうなるとイメージがつきやすそうですね。あと私的には「プルリクとかをどうやって切り分けるんだろうな」とかも気になります。「プルリクを順番に出しちゃったらたぶんダメなのかな」みたいな。どうするんだろう。一斉にリリースするのかなとか。

村下：レビューのマージをけっこう優先するんですよね。なので、誰かがプルリクを出したら基本的にそれをマージする感じで。そうすると、コードベースが発散したりはしないじゃないですか。だから、けっこう細かくマージしていくことを（やっています）。

横江：細かくマージしているんですね。なるほどね。

村下：（画面を示して）こんな感じですね。基本的には上から順番にやっていくみたいな感じで。テーブル定義とかバックエンド、フロントエンドみたいなところを分割して、チームで担当を決めていくようなイメージです。なので、そんなにサプライズはありません。

重要なところでいうと、スキーマを最初に決めちゃいますね。スキーマが決まると、フロントエンドやバックエンドがわりと並行して進められるようになるので。こんな感じで分担しながら、できる限り1個ずつ（取り組んでいく）。もちろん分割が絶対無理なものはあるので、そういう時は分担をするけどという感じですね。

横江：本当に全員に分けているわけじゃないんですね。

村下：そうですね。そんなに無理に分けることはないです。「理想としてはそうですね」という感じですね。

横江：なるほど。びっくりした（笑）。

村下：ちょっと盛ってしまったかもしれないですね（笑）。

横江：でも、フロントとバックエンドは2人で分けて同時に実装を進めるとか、そういうことなんですね。

村下：うん。

横江：うちだと、大きな機能を1人ががんばって開発することが多いケースなので、すごくおもしろいなと思いました。なるほどね。そういうパターンもあるのか。

SHEの開発組織はプランニングにすごく時間をかける

村下：あと、僕らはプランニングにすごく時間をかけるところもあって、1.5ヶ月に2週間ぐらいを機能検討に費やします。

僕は他の人たちの意見を今日聞きたいなと思っているんですが、ウォーターフォールとして、プランニングにわりと時間をかけるのは嫌われがちだと思うんですが、僕はプランニングに時間をかけるほうがいい派なんですよね。

横江：プランニングというのは、実際何をするんですか？

村下：僕らでいうと「GraphQLスキーマまでは決めきる」みたいなことをします。

横江：先ほどの。はいはい。

村下：僕らはシニアが少ないというのもあると思うんですよね。メチャクチャつよつよなシニアだったら、大丈夫なケースもあるとたぶん思うんですけど、ふわっと認識をしたまま先に進めてしまって、あとで「違うじゃん」みたいなケースがよく起こるところがあって。アジャイルって、そこのリスクを先に検知することが、一番重要なところだと思っているんです。

なので、特にシニアが少ない状況では全員で時間をかけて、いったん実装の見通しを立てきるほうが、僕的には早いなとは思っています。

村下：（スライドを示して）だいたいこんなことを2週間でやりきります。みんなと最初にラフスケッチを書きながらストーリーとかEpicを整理する。

横江：ラフスケッチというのはどういうものですか？

村下：画面のイメージですね。

横江：エンジニアとかプランナーとか、全員を交えてやるということですかね。

村下：そうですね。ごめんなさい、ちょっとそこも補足なんですが、全員でやります。

横江：エンジニア、デザイナー、プランナー。みんな揃って、まずは画面のイメージを作っていく。

村下：ですね。というのと、イベントモデリングも基本的にはエンジニア、デザイナー、PdM、全員でやるようにしています。

横江：イベントモデリング⁉

村下：はい。これはけっこう重要なおすすめプラクティスなんですけど。（スライドを示して）こんな感じで、画面に対しての操作とデータの流れをモックを作る前に可視化していくみたいなワークなんですよね。

これは返金機能を付ける例なんですが、「返金」を押すとダイアログが出てきて、そこの先にどういうデータが生み出されるのかみたいな。で、それがどういうふうに画面に反映されるのかを、Miroでカジュアルに整理していくんですよね。その中でどういうエッジケースがあるかとかもけっこう整理できますし、一番（メリットとして）大きいのはデータの流れが明確になるところです。

「ここで作るデータってどういうデータが必要なんだっけ」とか、「それがどこで使われるんだっけ」みたいなことを、チームメンバーで認識を合わせることができるんですよね。

これでざっくりデータの流れを合わせた上で、GraphQLのスキーマ定義まで落とし込んでいます。そうするとデータ構造もほとんどブレないし、GraphQLのスキーマも定義できているので、あとはもう本当に実装を粛々とするだけというモードになるから、わりとブレずに開発をやりきれるかなと思っています。

ここは議論の余地があると思うんですが、僕はけっこうちゃんとプランニングに時間をかけて、みんなの認識を比較的合わせた上でやるほうがいいのではという思想を持っていて。実際、爆速開発というか、けっこうスピーディなリリースでも、わりとそこは貢献してくれたなとは思っています。

横江：へ～、すごいですね。だいたいこういう図とかも、PMの方が（作成を）やることが多いじゃないですか。PMが1人でがんばって考えてやるパターンがけっこう多いと思うんですけれど、これはエンジニア、デザイナーがまじってチームでやっているのがけっこうすごいですね。

村下：そうですね。そこも「けっこう冗長だな」という見方もあると思うんですけど。UIで議論していると漏れちゃうことはやはりけっこう多いなという印象があって。データも、どういうデータが背景にあるかとか、UIを超えてどういうデータが作られて、どういうふうに動くのかという認識をチームで合わせておいたほうがやはり早いというのは僕らの学びですね。

横江：そして楽しいという。確かに。わりと何を作るかのイメージが揃うので、普通にちょっとモチベーション的にも高まるのは、副作用としてあるかなと思います。

仕様作成のミーティングの進め方

横江：先ほど、エンジニアでフロントとかバックエンドにわかれると言っていたじゃないですか。この仕様を作っていくミーティングって、どのぐらいの人数が参加されるんですか？　村下：チーム全員でやっています。僕らのチームサイズは5人前後なので、5人ぐらいで集まってやっている感じです。

横江：じゃあこの図を作るのは……。例えばPMの人もいるんですよね。

村下：はい。

横江：PMの人は最初になにか土台を用意しておくんですか？　ミーティングの時にゼロから作るんですか？　

村下：やはりストーリーの一覧とか、機能の一覧みたいなものは用意しておきます。そこはけっこう（事前）準備をしておくと思います。なので、「こういう機能を作りたい」というのはだいたい認識が合っている状態で、これを書き起こして、データの流れの認識を合わせるみたいなイメージです。

横江：でもすごいですね。その場でMiroをイチから作っていくんですね。

村下：うん。

横江：普通にすごいな。

村下：（スライドを示して）これはスクショを貼っているんですが、ワイヤーはメチャクチャ雑でもよくて。Miroのワイヤーフレーム機能を使って、ざっくり「こういう文言があるよね」みたいなものを書いていく。操作とデータの流れだけがわかればいいぐらいの感じで、そこはわりと雑にやっているかなと思いますね。

横江：へ～、おもしろいですね。なかなか人数が少ない組織だと、こういうことをやることはありますけど、SHEさんぐらいの規模になってやっているのはめずらしいと思うので、すごくおもしろいなと思いましたね。

1人しかエンジニアがいないから、エンジニア1人がこれを全部やっているみたいなことだったら、逆にあるかなと思うんですけど。

村下：僕らでいうと、これは定着して（いて）、今もずっとやっているプラクティスではあるかなと思いますね。

横江：ちょっと気になりますね。やってみたいな。なるほど。すごい。

（次回に続く）