こんにちは！いい生活エンジニア採用・広報担当の黒江です🍒

今回は前回に引き続き、いい生活 賃貸/売買クラウド 営業支援（以下：営業支援）のプロダクトオーナーの上屋さんと松崎さんに、営業支援について語ってもらいました！

営業支援の対談は、3つの記事に分けてご紹介させていただいています。

こちらの記事は後編ですが、
前編と中編をまだ見られていない方は以下よりご覧ください👀

攻めの開発と守りの開発をバランスよく行う

テストの大変さ

松崎さん（以下 松崎）：
さっきリリースを週1で行ってるっていう話があったけど、それで思ったのが、結構テストとか大変になってないのかな、って点。実際どう？

上屋さん（以下 上屋）：
はい、テストは大変ですね。
リグレッションテストを必ずやってからリリースをしているんですけども、やっぱりバグを出してしまうこともあります。

自動テストで問題を防ぐ試みもしているのですが、それなりにメンテナンスコストもかかるので大変です。
また、リグレッションテストでは機能の100%を評価してはいません。
もし、もっと短いスパンでリリースをやりたいとなったら、そのあたりが課題になってくるかなと思いますね。

松崎：
この辺の設計で言うとさ、品質を高める意味では「事前によくテストをする。なるべく頻度高く、CI に組み込んで何か修正するたびにちゃんとテストする」ってのが王道だし、もちろん戦略の1つとしていいと思う。

でも一方でそのテストで絶対に100点が取れるかっていうと、100%そうではないじゃない？

そこでよく言われるのが、「もしリリース後に問題があったときにどれだけ切り戻しを容易に素早くできるか？」というデプロイ・リリース戦略や、「問題があるかどうか、早期に検知するためにいわゆるオブザーバビリティを上げる」みたいなことも合わせて検討すべき、という話。
この辺で何か工夫していこうとかってあったりする？

上屋：
それに関しては 今はエラー分析用に Sentry っていうツールを使っています。
ユーザーの環境で起きたエラーについて、一般的なバグだけでなく、環境特有のエッジケースに関する問題も検出するために、ログを収集してアラートを上げる体制を取っています。

それによって、「こんな問題が起きる！早く直さなきゃ！」みたいなことをやって、もし問題が起きたときにも素早く直せる体制をとっています。

松崎：
バックエンドは、ログの収集は比較的容易なので、可視化は当然としても、SPA 特有のクライアントサイドで起きている問題をどう捕捉するかも大事だものね。
別に普通に動いてるように見えて、Chrome の Devツールでコンソールを見てみたら真っ赤みたいなこともありえるからね。

ちなみに、「これをやろうぜ！」って言い出したのは、やっぱり上屋くん？

上屋：
フロントエンドは特に若手のメンバーで構成されているので、これも僕発信ですね。

松崎：
どういう観点があるかというところと、どういう道具が世の中にあるのかというかというところの勘所、それに対するカードの量みたいな話だと思うので、今後若手のメンバーが上屋くんの背中を見て、学んでくれたらいいよね。

コードの品質担保をする上で苦労していること

松崎：
実際の開発をしてる上で時間が経過していくと、どうしてもコードの品質を担保するのが難しいと思うんだけど、何か苦労してることがある？

例えばリファクタリングをするのに割けるコストがなかなか取れないとか、逆に結構アグレッシブにやっていいよみたいな体制にしているのか。
機能開発のような攻めの開発と、ソフトウェアを健全な状態に保つための守りの開発、どちらも頑張っていかなきゃいけないけど、その辺の苦労とかあったりする？

上屋：
今一番苦しいのは、「こういう機能があればより多くのユーザーに使っていただける」ということで、営業やマーケティング目線のところがやや強くなっていて、機能追加の、攻めの開発がどんどん増えています。

もちろん攻めも大事なのですが、それを続けてしまうと、どうしてもコードは荒れてしまい、バグが生まれて、追加したい機能も出せないようになってしまいます。

攻めと守りのバランスをとらない限りは、1週間で毎週リリースしてっていうのが維持できないと思うので、守りも一定数を入れるっていうところを大事にしています。

僕のプロダクトオーナーとしての役割として苦労しているところですが、プロダクトマネージャーと「マーケティングでそれが大事なのはもちろんわかるけど、今週はこれだけは守らせてほしい」のように、よく戦っていますね。

その次の週には、「この前言われたこの機能開発をしていきます」といったように調整をしています。

松崎：
でも、そうしないと、大変なことにもなるから、そこは大事だよね。

あとは似たような話なんだけど TypeScript、JavaScript 界隈、Web フロントエンド界隈のありがちなものとして多数の OSS を使ってるよね。

Vite を入れたりとか Turborepo を入れたりとかして、ビルドプロセス自体は改善してるって話はさっき聞いたけど、ツールチェインとは別に、アプリコードを書く上で使ってるライブラリ類もバージョンアップ自体は頻繁でしょ。

その辺の依存性管理とかを楽にするって意味で、今って Renovate を使ってるんだっけ？

上屋：
はい、 Renovate を使っていますね。

松崎：
そうすると依存ライブラリとかも、アップデートが来たらなるべく腐る前に新しいバージョンに入れ替えていってるのかな？

上屋：
まだそんなに重たい機能があるわけじゃないので、リグレッションテストでやってみておかしいところがなければ、「入れ替えよう！」といったように、ちょっとずつ更新するというところを心がけていますね。

プロダクトを守るために

松崎：
ソフトウェアが腐らないようにするために、適切に生きた状態を担保するためにライブラリの定期アップデートを行うんだけど、そのアップデートが意外とアグレッシブなんだね（笑）

これ以外にも、ここまで出てきたビルドプロセスの整備、CI によるテストの自動化、切り戻しの容易性を担保したデプロイ、リリース後の観測性の担保、など、よく言われていることをきちんとやる、守りのための攻めみたいなことをきちんとやってるのも素晴らしいね。

でもさ、守りのための攻めってちょっと難しいところだよね。
さっきのプロダクトマネージャーと会話する中で出てきたような、技術的な部分で僕やエンジニアは理解できるけど、エンジニア以外には説明しづらい守りたいところがあるときに、マーケティングや営業は機能をより良くしたいみたいな状況だと、その綱引きが結構大変そうなんだけど、どうかな？

上屋：
でも実際にバグが起きたときの対応を目の当たりにしているので、ユーザーの不動産会社から毎週、毎月の定例で「あのときの問題がさあ…」みたいなことを伝えられると、やっぱりそのときの顔が浮かぶと思うんですよね。

その問題を起こしたくないっていう思いはやっぱりあるみたいで、「機能は大事だけどそれだったら…」という風に納得してもらっています。

松崎：
そう言う意味での状態のモニタリングがちゃんとできている上で、そこにプラスしてユーザーとの対話のチャネルがあることによって、顧客のためにちゃんと使える状態に維持しようって力学がちゃんと働いているんだね。

ひとりひとりの技術の向上のために

プロダクトチームでの勉強会の開催

黒江：
営業支援のチームでは積極的に勉強会を行うと聞きましたが、具体的にはどのようなことを行っているのでしょうか？

上屋：
いい生活にはコードレビューをする文化があって、営業支援では僕が、他のメンバーの書いたコードをレビューをしています。
それを見ると、手続き的なコード、これをここに代入、これをこうしてああして…と全部順番で書かれていて、「うん。これでもいいんだけど…動くんだけど…」というものが上がってくるんです。

それはプログラミングの経験が浅いと、そういう風になっちゃうんですよね。
それに対して「これはこういうことをしてるからここに切り出して、ここはさっきと同じことを使ってこうして」とか抽象化をもっとするようにコメントをしていたんですよね。
コードレビューするときに、毎回そのようにコメントしても、もちろんいいんですが、キリがないなと思いまして。

多くのメンバーが結構そんな状態だったので、勉強会をするようになりました。
一般的な書き方、「なんでこのコードは駄目なのか？いいのか？」ということを分かるようにするっていうので、隔週に1時間、そのメンバーで集まっています。
「このコードの書き方をしっかりやりましょう」「問題が起きにくい構造ってのはこういう感じなのでこれを守りましょう」というのをやって、それとずれてたらコメントをする、というのをやってますね。

松崎：
いわゆるリーダブルコード、クリーンコードとか言われるものだよね。

書籍など含めていろんな表現されるものの、言ってることは大体同じで、名前を適切につける、関心の分離と責務の集中、変数の再利用を避ける、引数のミューテーションを極力しない、とかかな。

あと、変数の宣言と利用が離れすぎてたり、一時変数が乱発してたりすると、コードの流れを読んでいるときに脳内にスタックしなきゃいけない変数の量が増えて読みづらいし、該当箇所の修正の際に、レビューするときに修正部分周辺だけしか diff で出てこないことで、副作用やロジックの綻びを見落とすリスクがあるから、その辺を気をつけましょう、とかもありそう。

で、もしそういうことを勉強会でやってるのなら、営業支援のチームのフロントエンドエンジニアのためだけのものとも、多分本質的には違うというか、もったいない気がするなぁ。
もっと言うとフロントかどうかすらもあまり関わりがないんじゃないかな？

お題としては、TypeScript で書かれたフロントエンドのコードなんだろうけど、内容的にはどの言語で書かれてるかの本質はあんまり関係がないと思うんだよね。

というのも、今どきの言語であればある程度マルチパラダイムになってるんで、ベースとしては関数型だったりオブジェクト指向だったりしてもエッセンスは大体全部入ってる。
なのでそういう状態からすると、汎用的・普遍的な話な気がします。

上屋：
営業支援のバックエンドのメンバーも、使用言語は違うんですけど、実際に聞きに来てくれました。
コードを書き直すことについて聞きに来てくれて、すごく面白かったって言ってましたね。

松崎：
他のチームはどうだろう。そこは巻き込めなかったのかな？

上屋：
他のチームのコードレビューまではできなかったのもあり、他のチームまでは巻き込めなかったんですね。

松崎：
そうね、でももうちょっとそれを広げられるといいよね。

人ってさ、知らない、聞けない状態になる時に、2つパターンがあると思うんだよね。
1つは、そもそも知らないので、質問とかそこがまずいって言うことに気づかないっていう、「純粋に知らない」パターン。
もう1つはボーダー・境界線を引いてしまうパターン。

人間ってどうしても、心理的安全性の高さを重視してしまう側面が、多かれ少なかれあると思ってる。
「自分のチーム」みたいな線が引かれると、どうしてもその枠に自分を収めようとする心理的なベクトルが働くと思うんだよね。

僕は比較的いろんなボーダーを超えていこうと意識してるんだけど、そういう人は世の中全体で多分1割ぐらいしかいなくて、9割ぐらいはやっぱり線が引かれてるとその線の中に入ろうとするんじゃないかと。
割合は適当だけど、どっちが多数派かと言えば、ボーダーを超える人は少数派だと思う。

それこそ Slack のオープンなチャネルでやってるから誰でも見られるし、社内のドキュメント共有ツールの DocBase にも共有されてるから、情報自体の公開はされてるよね。

そこに加えて「誰でもウェルカムだよ」という姿勢も見せることで、他のチームのメンバーにも入ってきてもらえるのかなぁ、と。

ちなみに、僕も実際その共有されている記事を見て、「なるほどあの資料のここ引用しているんだ」やってるのね、なんて思うことはあるね。

上屋：
確かにそうですね。
他に、勉強会で実際にやったこととしては React のバージョンアップ、17から18にあがったときに React のドキュメントサイトが新しくなったのでその読み合わせをしました。

1日15分ぐらい時間を作って、その読み合わせを結構横断的にやってましたね。
それをやらないとアウトプットが出ないと思ったのもあって、多少時間かけてやりました。

攻め、守り、新たな学びを行う苦労

松崎：
なかなか難しいね。
さっきも話してた、プロダクトとして新しい機能を公開しなきゃいけないことと、その守りのためにしなきゃいけないことを両立させてて、さらに週1回のリリースもある。
そういう中で、「実際に何か勉強しようぜ」みたいな気持ちを醸成させるのはパワーがいることだし、実際にそれをやる時間を作るっていうのも大変な気がするんだけど、その辺はどういう風に進めたの？

上屋：
僕のやり方としては「このコードなんだけど、ちょっと読みにくくない？」っていうちょっと遠回しに聞いて、「こういうところが読みにくいです」「だよね」みたいな風に聞き出して、気づいてもらうようにしていますね。
そして、「やっぱりこういう風に書くといいね」っていうのを何人かと言いあって、「これをみんながこういう風にできるといいね」っていう風に広げてたっていうのは、実際にあったアクションではありますね。

松崎：
なるほど、やることの価値に気づいてもらう、か。
そう言われた方が、メンバーにとっても取り組みやすいのもあるかもしれないね。

まず共感を産むことから始めるっていうことは大事で、「そうだよね」って共感しているから「よしやろうぜ」って提案されたら、「そうですね」って納得するっていう話なんだろうなぁ。

一方で React ベースっていう前提で、今後開発を続けていく上で、技術的な面でこれ追加してみたいとか、今密かに「あれをやってやろう…！」と思ってることとかある？

上屋：
やってやろうと思ってるのは、コンポーネント共通化ってやつですね。React とか Vue.js とか問わずに、コンポーネントを共通言語で書いていきたいですね。

松崎：
確かにね。
うちのデザイナーのチーム、UXデザイン部はいわゆる単なるデザイナー集団じゃなくて、ちゃんとユーザーエクスペリエンスやユーザーインターフェースとかを、広範囲にその体験も含めて設計していこうとしている。

その中には、デザインシステムの確立とか、コンポーネントライブラリ整備みたいな話もビジョンとして持ってるものね。

実際、そこまでの話ではないけど、コンポーネントという意味では、 Storybook あたりをちょっとずつ使ってるんじゃなかったっけ？

上屋：
コンポーネントライブラリを使っていて、ちょっとごちゃごちゃしてるんですけど、こういうのを使うときはこれを使ってとかっていうのは準備してるんですよ。

去年、いい生活の会社全体がブランドを刷新して、それでプロダクトの他にもいろいろと統一しているんですよね。

そんな中、コンポーネントをそれぞれで作ってたら「ちょっとずつこれが違うな…」みたいなのがあるので、それだったら全体をまとめていくところはやっていきたいと思ってます。

松崎：
今リリースしてる Web の UI だと、いい生活賃貸クラウド 物件広告と営業支援が、画面要素数、コンポーネントのバリエーション、ユースケース数っていう観点で、2トップで大きいよね。

そういう意味ではライブラリ化できそうな部品としたものをお互いいろいろ持ってそうな状態だよね。
だからそこをどこかでまとめていきたい、と。

僕もやっぱりデザインシステムを確立して、コンポーネントライブラリにしても、社内で広く再利用可能にして、プロトタイプ設計レベルであれば、その辺の部品を使って画面を組める状態にしていった方が生産性は上がると思ったんだよね。

もちろんそのコンポーネントを作っていくにはパワーが必要だったりするし、理想を言えば、見た目の UI機能だけじゃなくて、コンポーネント固有のロジックとかをある程度抽象化して埋められるはず、とも思ってる。

なかなかハードな道のりだけど、そこまで行けば真の意味でコンポーズ可能な部品ライブラリになるよね。

ちなみに、そういう取り組みに対しては、若手のメンバーとか「実はそこがやりたかったんです！」っていう意見はあったりする？

上屋：
みんな割と穏健派ですかね。

いい生活のプロダクトにおける"教科書"のような存在

営業支援の開発スタイルは王道

松崎：
そうすると、若手メンバーにとって営業支援というプロダクトとチームは、きちんと考えられたたくさんのユースケースがあり、ユーザーにもちゃんと使われているビジネス向けの本格的プロダクトでありながら、今どきのモダンなデザインをしたアプリを作る経験ができる場、として映っているのかもね。

TypeScriptで書かれていて、React を使ってるし、SWR も使っているでしょ。
Sentry でちゃんとフロントエンドモニタリングをしているし、テストの自動化も進めている。
ビルドの高速化とか、ライブラリの依存性管理とか、CI にまつわる諸々もある程度ツールで対応している。
APIドリブンだし、そこには型スキーマもある。

王道としてやった方がいいことは一通りやってたんじゃないかな。

それぞれの要素項目で100点を取れるほどではないけど、やっぱりある程度モダンな環境だと思う。

上屋：
よくある構成を真似することで、検索したときに、そういう情報が出てきて探しやすいのもあるし、逆に採用しやすいのもあって。

松崎：
ただ、王道だと分かっていても、なかなか王道をやり続けるのってなかなか難しいじゃない？
なので、きちんと王道的なアプローチをしながら、実際に多くのユーザーに利用され、60週ちゃんと週次リリースを続け、小さく漸進的な開発をできているっていうのは素晴らしいですね。

いい生活にとって、開発面で教科書的な立ち位置のプロダクトで、そういう教科書スタイルだからこそ、「こういうのを入れようぜ」という上屋くんみたいなグイグイ派の人が進めている、というのが営業支援なんだろうね。

上屋：
「流行ってるからやろうぜ」ぐらいでしたけど、結果的にそうなるんですね。

松崎：
そこはね、このチームのポイントかな。

学生時代から「Web もアプリもバックエンドもやったことあります！」みたいなタイプじゃないと営業支援のチームで働けないかと言えば、全然そういうわけじゃない。

そういう人だけじゃなく、プログラミングの経験が多少あるぐらいの人が実際に入っていく場所が必要という意味では、プロダクトとしてもチーム体制としても、教科書的なところがあっていいかな、と思いますね。

求める若手像

黒江：
若手や新卒のエンジニアで、こういう人が来てくれたらいいなっていう考えなどありますか？

上屋：
僕自身はプロダクトオーナーなので「こういうことを実現したい」となったときに、「それやるならこういう方法があるよ」って提案してくれる人だったりとか、あとはさっきの話でも言いましたが、「こういうことをやりたい」って言ってくれる、「自主的に動いてしてくれる人」を求めていますね。
スキルが欲しいわけじゃなくて、やりたいことに対して動ける人だと覚えるのが早いと思うし、その興味がある方向に今後どんどん尖っていける。
僕自身も尖った人が好きなのでそういう人がいいですね。

松崎：
いわゆるマインドセットの話だよね。
「これをやりたい」「これを作りたい」「これは絶対うまくいくはず」みたいな確信のようなものがあるといいよね。

でも、営業支援はいろんなタイプの人が混ざってていいかもしれない。
手堅いメンバーや若手のメンバー、攻めのメンバー、比較的社歴の長いメンバー、みたいな混成チームというか。

上屋：
いろんな人がいる方がやっぱりいいと思いますね。
僕自身は多分イケイケの方だと思うので、イケイケばかりが集まるのではなく、止めてくれる人も大事かなと。

松崎：
この相互補完関係は、どんなチームでも重要だと思うんだよね。
それって要はチームメンバーの多様性ってことだと思うので、一人一人違う「得意」をもった人が集まるチームとして成長していけるといいよね。

黒江：
お2人の話を聞いて、営業支援の開発で重視していることなど理解が深まりました！
ありがとうございました！

ここまで読んでいただき、ありがとうございました。
こちらの記事で営業支援について、上屋さんと松崎さんの対談は以上になります。

お2人の対談を通して、いい生活の技術について、そしてエンジニアの魅力をお伝えできていれば嬉しいです！

記事を読んで、いい生活に少しでも興味を持ってくださったそこのあなた！いい生活では、新卒/中途の採用を行っております😉
以下から気軽にご応募ください！

今回の記事を読んで、いい生活で働いてみたい！と思ってくれた方と出会えることを楽しみにしています！

読者のみなさまからの「いいnote」のフォローや「スキ」のリアクションも私たちの励みになります🥰
いつもありがとうございます！

それでは今回はこちらで失礼します！
次回の記事もお楽しみに💁‍♀️

撮影：杉山 泰之