StorybookとChromaticの導入、GraphQLのSchema Stitchingの活用…　これからの爆速開発に向けた「無駄をなくす」技術投資

消耗してしまったメンバーが増えた時期があった

横江亮佑氏（以下、横江）：組織もなにか工夫したところはあるんですか？

村下瑛氏（以下、村下）：当時は5人のチームだったので、組織みたいな要素はほぼゼロというか。

横江：じゃあ、この開発を進めていく上でハレーションとかも特になかったんですか？

村下：でも、それでいうとやはりあって。

横江：この人数であったんですね。

村下：5人で小規模なチームではあったんですが、僕が開発にフルコミットみたいな感じではなくなりつつあるようなタイミングで、チームからすると、ややステークホルダー寄りみたいな頃がありました。

横江：ステークホルダー寄りってどんな感じですか？

村下：上司じゃないですが、進捗を報告するようなところがあった状態で。とはいえ、僕の目線としては今までどおり「同じ釜の飯を食うチームだよ」みたいな感じだったんですよね。

だから、けっこう無邪気に「このリリーススケジュールいけるっしょ」みたいなことを言っちゃった感じがあって。で、それがエンジニアにとってすごく負担が大きかったというか、疲れちゃった。消耗しちゃったメンバーがすごく増えました。

横江：確かにね。6ヶ月で3つもということは、約2ヶ月で開発ですもんね。それを3連続でやるからなおさらきついですよね。

村下：そうですね。ベースがきついのはもちろんあるし、スタートアップをやっていると、そういうことをやらなきゃいけないところももちろんあると思うんですけど。とはいえ、もっとうまくできたなと反省しているところはやはりあります。

横江：エンジニアがメチャクチャ負担を感じているのは、どこでわかったんですか？

村下：やはり1on1とかですかね。1on1でけっこう相談されたり。あと実際にちょっと業務委託の方とかで、辞めちゃう人も出てきたりして。

横江：そうなんですね。

村下：そうですね。そこはすごく反省しているところです。

反省を踏まえ今意識していること

横江：それを受けて、あきらさん（村下氏）はどうされたんですか？

村下：今は完全にそうしているんですが、やはりリリース期日を判断するのはチーム。やはり僕は「チームメンバーではないです」ということはちゃんと意識するようにしています。

「リリース期日を決めるのは誰か」といった時に、「それはチームだ」ということはすごく大切にしている考え方で、僕として（やるべきこと）はできる限り制約を伝えていくということかなと思っています。

なので今回の件でいうと、「必須機能はこれで、できる限り早く検証を始めたい」というところで、チームにプランニングを委ねる。あとそこで「もっと早くできる」と思ったことがあれば、チーム目線で提案をして判断をしてもらうみたいなところですかね。あくまでも「僕目線でこう見えているけど、どうかな」みたいなところを対話していく感じです。些細な違いに見えるんですが、けっこう違うなというところはあって。

確かにメンバー目線でいうと、「3ヶ月でやってくれ」と言われるのと、「3ヶ月でやれたら最高なんだけど、実際どこまで、どれぐらいいける？」みたいに言われて、チームで話して僕に提案をするのとではぜんぜん違うじゃないですか。

横江：違いますね。

村下：けっこう地味だけど、重要だなと思っているところですね。

横江：ちなみに、チームが疲弊したなと感じたあと、その時のメンタリングとか、気をつけた部分とかはありましたか？

村下：メンタリングとか気をつけた部分か……。なんでしょうね。

横江：大丈夫ですよ、ゆっくりで。

村下：すみません。でもやはり、プロジェクトの目的とか制約をちゃんと伝えつつ、メンバー一人ひとりに対しても、「主体的にこういうところをお願いしたい」と主体性を持ってもらうことは意識したかもしれないですね。

横江：いかに押しつけないかというところで、それぞれのなりたい姿をあらためて思い返してもらうことを意識したんですかね。

村下：そうですね。

横江：いいですね。なんかSHEの思想につながってきますね。それぞれのなりたい姿。

村下：ありがとうございます。確かにね。それはメッチャあるかもしれないです。メンバーにできる限り自分らしく生きてほしい。とはいえ、やはり制約もあるっていう中でどうするかみたいなことは確かに組織的なテーマだなと、今聞いていて思いました。

横江：そうなんですよね。マネージャーの大事なところってそこなんですよね。みんなの生活があるところを意識した上で、みんなの成長を見守りつつ、そこをどうやっていくか。楽しいところですよね。なるほど。ありがとうございます。

今後のSHEの爆速開発に向けてやっていこうとしていること

横江：先ほどちらっと見えたので、今後の話もしていきましょうか。今後のSHEの爆速開発に向けて、やっていこうとしていることを聞きたいなと思っています。

村下：そうですね。でも、開発のビジョンの構想とかはもちろんあるんですが、組織としてはリーンの徹底みたいなところを引き続き突き詰めていきたいなとは思っています。

「リーン（lean）」の元の意味って、無駄のないことみたいなことだと思うんですけど、レビュー待ち時間とか、仕様の要件齟齬とか。あとは退屈なファイルアップデートとか、とにかく無駄をなくしていき、開発が流れるようにしていく。

結果として、どんな機能であれ最速でリリースできるような強い開発組織を模索していきたいなとは思っています。それはもちろん精神論というわけではなくて、プラクティスとか、あと基盤技術とかにも積極的に投資をしていきたいなと思っています。

最近けっこう力を入れていることでいうと、1つはDesignOpsみたいなところです。先ほどの「モデリングをやったほうがいいよ」みたいな話もそうなんですけど、できる限り認識をこまめに合わせるのはメチャクチャ重要だなというところで、弊社はStorybookとChromaticみたいなものを導入していて、開発中のバージョンをデザイナーが即時にフィードバックできるような仕組みを作っていたりします。

共通のコンポーネントはできる限りカタログ化して、「もうそれを使えばよい」という世界観にしていきましょうというところで、社内でデザインシステムの内製化をしていて、実際に10月ぐらいから運用をしていたりします。あとはけっこう、あ、やばい。ちょっと（スライドの作成が）途中のものとかもあって。申し訳ないです。

あとは、弊社は特に「学ぶ」と「働く」が別サービスで協調して動く、マイクロサービスみたいな世界線に徐々になってきているんですが、そこのデータの受け渡しみたいなところが、けっこう今の課題になってきていて。そこにGraphQLのSchema Stitchingというテクノロジーを投資しようと思っています。

横江：へぇ～、初めて聞いた。

村下：けっこうおもしろいんですよ。あるサービスのGraphQLにちょっとアノテーションを付けるだけで、別のサービスから使えるみたいなテクノロジーになっていて。「学ぶ」のデータをポートフォリオに入れたり、働いた実績を「学ぶ」で使うみたいなことがけっこう簡単にできるみたいな。

あとはチーム数もだんだん増えてきて、同じサービス、特にSHElikesの学習マイページとかは、いろいろなチームが使うようになってきたので、徐々にマイクロフロントエンドというか、チームが自分の機能だけを独立にデプロイできるような仕組みに（なるように）今は力を入れていたり。このあたりはけっこうPoCで、エキスパートの方に知見をもらいながら、進めている感じですね。

あとはデータのパイプラインとか、認証・認可のためのフレームワークを入れたりとか。けっこういろいろな軸で投資をしていたりします。

横江：いいっすね。やることやっていますね、なんか。

村下：やることやっているんですかね（笑）。

横江：すごい（笑）。自分は逆に「新しい技術を取り入れています」みたいなことをぜんぜんできていないので、すごいなって思いましたね。

村下：ありがとうございます。確かに、けっこう無駄というか、どういうところにのびしろがあるのかみたいなことをチームで話しながら。実際にこれで改善するとけっこう気持ちいいので、「無駄をなくそう」みたいなものをチームで話すのは楽しいし、リターンがあるなという印象はありますね。

新しいサービスをすごく作りやすい状態になっている

横江：ちなみにStorybookとChromaticを使っているのは、プルリクを出した時にChromaticで今のStorybookのページが見られて、それをデザイナーがフィードバックするみたいなイメージですか？

村下：そうですね。

横江：もしかして、デザイナー自身がStorybookのデザイン、コンポーネントの開発をしていたりもするんですか？

村下：コンポーネント開発はしていないですね。

横江：さすがにそこまで。

村下：ただ、スキーマでけっこうコンポーネントを意識してもらうようにはしていたりはしますが。

横江：でもいいっすね。いろいろな新しいサービスをすごく作りやすい状態になっていますね。

村下：そうだといいですね。徐々に良くなっているとは思います。

横江：やはり、Storybookとかを使ってデザインシステムをちゃんとしっかり運用しているとなると、けっこうコンポーネント化されていそうな感じがしますね。

村下：Storybook、コンポーネントもすごくいいなと思うんですが、実はけっこうページレベルでカタログ化するのも個人的にはすごく推しです。

横江：へぇ～、そういうこともできるんですね。

村下：そうなんです。特にGraphQLだとメチャクチャ相性が良くて。ちょっと見てもいいですか？

横江：ぜひぜひ。

村下：ありがとうございます。

横江：すごいな。ちゃんとDesignOpsって感じだわ。しっかりできてんな～。メチャメチャ洗練された開発環境って感じがする。

村下：僕らだとページをこんな感じで……。ページ自体をStorybookに起こすことが多いんですよ。（画面を示して）これは今の応募画面なんですが、応募画面の全体的なUI、例えばバリデーションがどうなるかとかを、ひととおりデザイナーに触って見てもらえるという。

横江：なるほど。実際のステージング画面にいかなくても、モックとして触れる感じですね。

村下：そうなんです。

横江：なるほど。

村下：けっこう良くないっすか？　バックエンドの開発を待たずに画面でモックとかを作れたりするし、基本的に挙動は全部デザイナーに見てもらえるので、やはり効率がいいなと思っています。

横江：へぇ～、こういう使い方もできるんだ。

村下：そうなんです。GraphQLのいいところは、型が全部ついているので、Mutationとかクエリのモックがすごく簡単にできるんですよね。なので、この応募フォームはGraphQLで取得しているんですが、それをモックして、あとサブミット時の処理もモックして、成功レスポンスの場合と失敗レスポンスの場合みたいなのをカタログ化するのがけっこう簡単にできるからいいですよ。

横江：へぇ、なるほど。そうなんだ。「defaultValue」と表示されているものは、（GraphQLで）取ってきているということなんですか？

村下：そうっす、そうっす。同じ通信の仕組みでモックしていて。だから、モッククライアントを使っている以外は、全部同じコードが動いている感じですね。

横江：すごいな。よく作ってあるな。

村下：これはけっこうおすすめです。

横江：これは爆速だわ（笑）。すごい。びっくりしちゃった。そうなんだ。すごいっすね。

村下：「これをやったら爆速になりました」みたいなものを、みなさんからもぜひちょっと聞きたい。他の人からも聞きたいなって思って。

横江：もっと爆速になるべく、みなさんの知恵をぜひ貸してもらえるとありがたいですね。なるほど。ありがとうございます。じゃあ資料としてはこれでひととおりかな。

村下：そうっすね、はい。

横江：オッケーです。じゃあ、ちょうど時間にもなりましたので、対談タイムはここで終わりにします。どうもありがとうございます。

村下：ありがとうございました。