こんにちは、Free Standard株式会社(以降FS)でプロダクトチームのEMをしている伊藤です。
プロダクトチームは、BtoB, BtoBtoC向けSaaSである、FSのプロダクト「Retailor」の開発を行うチームで、様々なクライアント様へご提供するリコマースシステムの開発に日々取り組んでおります。
FSが企画しているブランドリコマースpopup Re:LIKE代官山の様子
FSはコアバリューに、 「Future Match: 未来を語ろう」「One More Step: 変化を楽しもう」「Receive Heart: 違いを認め合おう」 というVALUESを掲げています。
先日 「Future Match: 未来を語ろう」 というバリューに沿った、「開発チーム x 経営」で未来を語る Future Match会(以降FM会) を行って、それがとても良かったので簡単ではありますが記事にしてみました。
少しでもFSの雰囲気や考え方が伝わると嬉しいです！
こんなことを話しました
議題として大まかにいくつか出して、それを深掘りのような形でディスカッションが進んでいくという形で進んでいきました。
大きな議題はこんな感じです。
- 未来のエンジニアが活躍している状態とは？
- エンジニア満足度が高い会社って？
- 評価について
- エンジニア満足度が高い会社って？
議題を中心に、よりディスカッションが活発になったトピックを紹介していきます。
自由度のある環境
働く環境は、オフィス環境含めて[1]、働く上で最重要視する項目の一つですよね。
経営側からは 「エンジニアが、いつまでも学べる会社、環境を提供していきたい」 というポジティブなメッセージがあり、メンバーそれぞれ意見が出ました。
「学べる環境であるか？」「柔軟性を持った組織であるか？」など 環境的なイメージ と、「自主的に技術選択などに自由度があるか？」という アクション的なイメージ の性質を持った意見に大きく分けられた印象でした。
会議室エリアの様子
環境的な部分については、経営陣を含めて積極的に良い環境を用意していきたい、一緒に作っていきましょうという会話ができたのはよかったです。有料エディター、LLM系サービスの法人契約や、技術イベントへの登壇支援等いくつか話は上がりましたが、ひとまずプロダクトチーム側で意見をまとめてみようという話に。
環境という側面は人材採用にも影響するので、 組織醸成として、プロダクトチームと経営側で継続的にコミュニケーションをとって細かく連携していけると 良い環境を作っていけそうです。
アクション的な部分については、「SaaSの新しいプロダクトを積極的に利用していける環境か？」とか「生成AIをもっと活用して便利にしていきたい」といった、好奇心からくるものに対して積極的に取り組んでいける環境かどうかが一つの判別基準になりそうです。新しい技術は、触れていて面白いという単純な感覚もありますが、 エンジニアリング自体が新しい技術を取り入れないとあっという間に技術的やパフォーマンスとして取り残される危険性を持っているものなので、利害関係が一致している 項目に感じました。
一方で、代表の張本[2]がよく言う 「自由=責任=成果」 というワードがあり、ここでいう責任について議論を交わせたのは組織としてとても良かったです。
ここでいう責任については、新しいものを導入する際には「説明する責任」をセットで持ち合わせましょうという結論に。もう少し噛み砕くと、導入する 「活用ユースケースのメリット」「リスク・コスト」「全体周知・進捗共有」を説明/考えとして持ち合わせた上で始めよう という話になりました。
最終的にはまぁ当たり前には聞こえはするものの、自分の過去の経験をふまえても、意外とこの 「得たい成果」や「リスク」をしっかり言語化すること は忘れがちになってしまうので、成果につながる確率を高めた自由な環境を作っていけると感じました。
今回の議論で「具体的な制度やルールを作成」の手前までは到達したので、アップデートがあり次第またご紹介していきたいと思います。
プロダクトとモチベーションの関係性について
エンジニアリングとは別の要素として、関わっているプロダクトについての議論も面白かったです。エンジニアリングとは無関係にプロダクトの性質は存在していて、それはどのようにモチベーションに繋がるのかという視点で、私がいつもエンジニアに対して興味を持つ箇所でもあります。
総じて出た意見は、 「関わって作っていれば愛着が湧く」 というところで、割とこれじゃなきゃダメみたいなメンバーはいなかったです。
プロダクトの性質とは関係なく、業務をする上で 「仕様として納得できない」というコーディング指示 が仕事をしているとあったりするかと思いますが、そういう時にどのような対応を取れると良いかというところに多く意見が出ました。
「納得できない」という理由は、 「理屈として納得できない」「感情的に納得できない」の二種類に分かれる ねという議論に比較的早く辿り着き、さすがエンジニア、切り分けが上手いな、、と感心。
理屈のほうは、ロジックを丁寧に説明さえすれば納得できるとして、厄介なのは「感情的に納得できない」方で、完全には解決するのは難しそうですが、手掛かりになりそうな考え方のようなものは議論できました。
結論としては、 「納得できない！」は往々にしてコンテキストの共有・理解が足りていない、乖離している状況から発生する と考え、組織の考え方として 「なぜそうしなきゃいけないかの説明責任を徹底的に実施する文化」を作っていけると、心理的安全性も担保され、そもそも納得できない回数も減る可能性がありそう だね、という共通認識を持つ結果に。
コンテキストが雑だと、マインド的に良くないというのがプロダクト・コミュニケーション双方に共通してありそうで、そういった点にしっかり気を払っていける組織形成やチームとしての文化を形成していきたいところです。
業務スペースの様子
評価について
経営から、 評価を中間管理職のさじ加減にだけはしたくない というメッセージから始まりました。
営業だと「受注1件取れました」「新規アポ3件取れました」という定量化しやすいのに対して、エンジニアリングについては項目や内容が多岐にわたりすぎてなかなか策定が難しいというのが実情です。
なので割り切って完璧な仕組みにというよりは、大枠で定性的なグレードの定義を設けつつ、「マネージャーとメンバーが能力やパフォーマンスの変化を頻度高く経営側とすり合わせた上で評価が決定されていく」ことが大事かなと思っています。
定量化できない原因として、エンジニアという職種自体が、他職種視点として何をやっているか判断しずらい/できないという点が往々としてありますが、今回はその点について深めにディスカッションができて、ある程度相互理解が深まったように感じました。
エンジニアの作業は、「リリース」のようなわかりやすい明るい話もありますが、 「誰も手をつけようとしなかったリファクタリング・バグ潰し」といった本当に地味なもの まで存在していて、後者は伝えづらい/伝わりづらい性質だと思いますし、そもそもそういった地味なものをやるのが当たり前の職種ではあると思います。
リリースした機能が実際に利用されているといった、他部署にとってもわかりやすい指標はあるにしても、すべてがそれに当てはまるわけでもなく（頻度も含めて）ひとつひとつの小さい開発が大きなリリースにつながっているし、よく知られているバグから、細かいけれどクリティカルなバグまで、業務範囲が幅広いというところが本当に難しいです。
なかなかエンジニア間以外では本当の価値や貢献度が伝わりづらいこものが存在することから、エンジニア同士の評価だったり共有というところが適切かもねという話になりました。
とはいえ、EMとしては しっかりこういった側面も透明性高めて解像度高く共有していきたい と思っていて、FSでは月に一度全社員が各チームからの共有ができる「納会」[3]という、その月の振り返りを行うコンテンツを実施しているので、まずはこういった機会からでもうまく共有していきたいと思っています。
昨年行ったキャンプ納会の様子
給与
価格競争を始めたらきりがない項目ですが、評価とセットで適正な昇給ロジックを示すことが求められるところで、どこも苦労しているところかと思います。
FSでも、どのように制度化していこうか試行錯誤中ですが、次回のFM会の中心テーマにしてみようかという話があがりました。
時間にメリハリをつけよう
Free Standardはあまり残業が多い会社ではありませんが、多くのプロジェクトが動いているため、リリース前など勝負所ではそのチームの負荷がかかったりすることはあります。
ただ、長くやればいいというものではなく、あくまでも 成果やパフォーマンスで評価されることが真っ当ですし、評価する側もされる側も、互いにそう望んでいることを改めて確認し合いました。
また、残業が続く場合、その仕事を他のエンジニアに手伝ってもらいたいと思うかどうかという経営からの問いかけもありました。営業だとリサーチとか部分的に手伝う項目を切り出しやすい反面、プログラムは前提の地続きという性質上、中途半端な介入は説明の必要性やコードレビューの必要等、逆に効率が悪いのであまりそういう感情はないという総論に。
必要に応じて、適切にプロジェクト的に入ってもらうというのがヘルプの前提になる感じですね。
開発のクオリティについて
リリースについては、前提条件として納期だったりコストが決まっているので、かけられる時間等が決まっています。FSのエンジニアは、リリース後にサービスに対してポジ・ネガ含めて色々言われたりする環境で育ってきているので[4]、基本最低限外してはいけないクオリティ担保はできているように感じています。
現在当たり前にできている大事なクオリティ担保ですが、この先未経験の方が入社されたりなど、人に依存せずクオリティ担保として規則として決められる性質のものなのか？基準を設けて今より良いアウトプットをしていけるか？という問いがありました。
プロダクトやリリースの性質により100通り、1,000通りあるようなもののため、なかなか一定のルールを設けることは難しいという会話にはなったのですが、今当たり前にできている、 リリース後でも色々レビューとしていい意見、悪い意見は前提を度返しで言い合える文化がいい ですねという総論になりました。
何か事情があったにせよ、 「こうした方が良さそうだね」という共感覚を実際に会話するって大事 です。
私個人の経験として、大人数開発時代、全員で1Hほど設けてモンキーデバッグ会みたいなのをリリースのたびにしていたのですが、割とそれは良かったです。
みんな見る機会が平等に与えられている以上、真剣にレビューするし、何か起きたとしても自分ごととして捉えることができて、リリース後の会話もトゲがないというか、会話が自然になるんですよね。
その時は30人くらいのチームで、それなりのコストは払い出しますが、それを補えるほどの効果はあったように感じていました。開発体験という視点でUXとしてのデバック会はおすすめです、FSでもまだ制度的には導入できていないので導入を進めていこうと思っています。
FM会やってみて感じたこと
他にも色々白熱した議論などはあったのですが、総じて想像していたよりかなり良かったです。
- 会社全体ごととして、自分の事業部の決まりを作っていっている感覚
- 案に対しての意思決定までのスピードが異次元
- エンジニア同士であまり会話しないようなトピックを議論し合えて、より思考を知れた
FSはまだ15人ほどの組織で、あまり経営とチームでの壁みたいなのは存在しないのですが、それでも開発5人と経営2人が顔を突き合わせて会話するということは 機会を設けない限りありえない のですよね。
7人でディスカッションすることで、考えていることの共有が深くできて想像以上に良かった なぁという印象でした。
この収穫を、きちんと組織に反映していこうと思います。
-
代表取締役を務める張本貴雄（以下、張本）は、前職クルーズ株式会社で通販サイト「SHOPLIST.com」を企画から立ち上げ、年間 250億円の売上高に至るまでに成長させました。創業インタビュー ↩︎
-
数字含めて何も隠さない共有なのですが、社外からのゲスト参加も可能というかなりオープンなコンテンツです。もしご興味持っていただいた場合は、是非お問い合わせください。 ↩︎
-
月間数億円規模のソーシャルゲーム開発責任者や、年間170億円規模のECサイトのリードエンジニアなど熟練のエンジニアが揃っています。 ↩︎
Discussion