今回は、セブンリッチグループに存在する様々な事業を技術で支える「SRACテクノロジーズ」という組織の丹（たん）さんと豊福さんにお話を伺いました。

「目の前のお客さんにすぐ価値を届けられたらいいのになと思って」

—SRACテクノロジーって何やってる組織なんですか？

丹　SRACテクノロジーズ（以下テクノロジーズ）は、簡単に言うとセブンリッチの技術横断組織です。主に社内受託で、社内の事業と組んでプロダクト開発しています。社外でも、セブンリッチとつながりのある会社と連携してプロダクトを開発したりしています。

—いわゆる遊軍ですね！テクノロジーズって、もともと丹さん1人から始まったチームですよね。なんでこの形をやりはじめたんですか？

丹　元々、割とでかい組織でエンジニアをやっていたんです。その頃、もっと自由が効いて、目の前のお客さんにすぐ価値を届けられたらいいのになと思っていました。仕方ないのですが、規模が大きいだけに、ステークホルダーも増えていくので各所調整が発生したりして。

その点、セブンリッチではそれぞれの社内事業と直通で、なんなら中の人同然で関わっていけるイメージが持てたので、この形で始めました。

「ドンズバのソリューションを最優先で作れる」

—確かに。僕もいろんな事業部と関わること多いですが、一つ一つは独立組織でありながら中の人でもあって、同じような気持ちです。最近はどんなことしているんですか？

丹　今はウェルネスのチームと組んでプロダクト開発しています。いわゆる業務改善ツールなんですが、これが面白いんですよ。実際に担当の人に1日密着して業務を把握したり、トレーナーにもヒアリングして業務を把握し、プロダクトに落とし込む感じにできていて。

—案件が発生するたびに、インハウス的な動きをするんですね。

丹　受託の「いろいろな案件を、いろいろな技術で」という点と、インハウスの「業務ドメインに突っ込んで」の両方ができるのがうちのいいところだと思います。

—クライアントと距離がないというのは素晴らしいですね。

丹　美談ではないんですが、最近すごくそれを感じるエピソードがあって。
例えば、いわゆる「通常、プロダクトのリリース計画的には後の方になりがちなオプション系」みたいな機能があったんですが、現場の強い課題感をボトムアップで受けとって優先度を変更したんですよね。

—まさに現場に近いからできる動きですね！

丹　いわゆる「当初の計画で決めたスケジュールを問題なくこなす」的な動きだけではできなかったなと思って。事実だけを見ると、シンプルに我々の優先順位付けと現場の優先順位がずれていたことに他ならないんですが、クライアントがすぐそこにいて、課題のヒアリングがすぐにでき、ドンズバのソリューションを最優先で作れる感覚がありました。

—よりクライアントの課題にフィットする開発ができている？

丹　最初はいち業務効率化ツールとしてスタートしたのですが、課題を深ぼるうちに経営改善的なツールにも近くなっていて。組織の開発姿勢も視座高まってますね。

—会社の人がアーリーアダプターになる事業開発って言う感じですよね。

丹　まさにそうですね。いわゆる受託だと、案件ガチャ、みたいな感覚ってあると思うのですが、うちはそういうのはなく、しっかり向き合う形がとれています。

「当然、技術面もチャレンジのある環境に」

—ちなみに、技術の面ではどうなんですか？技術は手段、みたいな感じなんでしょうか。

丹　当然、技術の面もチャレンジのある環境にしていきたいです！経営課題と向き合うと言う話をすると、技術は手段でしょ、という感じがして、最新技術をないがしろにする感じがするかと思うのですが、そこは否定します。

—技術的なチャレンジも忘れない環境なんですね

丹　受託のいいところって、一つの技術スタックに縛られないことでもあるので、そこはチャレンジの姿勢をもっていきたいです。
今はTypeScript x Reactの鉄板構成ですが、今後も動向を見て何を取り入れていくかは都度考えていきますし、サーバーサイドも事業に合わせた適切な選択をしていきたいですね。技術的成長もしていける環境です！

—現状、具体的にはどんな感じか教えてもらえますか？

丹　例えば、今話題にしてたウェルネスのプロダクトってばちばちにイベント駆動なサーバレスなんですよね。

API Gateway + lambda + dynamo (dynamoに入ったデータの一部をdynamo stream経由で非同期でaurora serverlessに同期)の割と王道な構成です。

一方で、今動き始めてる他の案件で「とある領域の予約サービス」があります。既存のサービスとがっつり連携するという制約があり、そのあたりの解決として、サービス連携をイベント駆動にして独立させつつ（dynamo stream駆動でstep functions + lambdaでビジネスロジックを組んで動かす）、メインの予約部分はappsync + dynamoベースでさくっと、という形をとりました。

こんな感じで、思考停止で手癖でつくるようなことなく、事業に合わせて柔軟かつ適切な技術選択をしているのが現状です！

「事業をやる以上は、お互いがオーナーシップ持つことを忘れてはならない」

—ちなみに、今抱えている課題ってなんですか？

丹　顧客との一体感があるって、ある側面では難しいなと思ってます。

—メリットばかりではない？

丹　というより、これはまだ仕組みができていないと捉えているのですが、ガバナンスをどのように保っていくかは課題だなと思っています。別に問題が起こっていることはないんですが、一歩間違うと、言うとなんでもやってくれる魔法の組織、になるのではという懸念ですね。

—責任範囲が曖昧にならないようにしていきたいということですか？

丹　やっぱり事業をやる以上は、お互いがオーナーシップ持つことを忘れてはならないなと。相手の成長機会を奪うような動きをせず、こちらもコミュニケーションをサボってしまうような動きにならず、という適切な関係性を保つ仕組みを考えることは課題ですね。未来のメンバーとは、そこも一緒に考えていきたいな。

GIVEできるものは「技術的にチャレンジできる環境」と「顧客とスクラムを組んでプロダクト開発を行える環境」

—今後はどんなことをやっていきたいですか？

丹　業務改善コンサル的な動きだけではなくて、シンプルに技術的な施策も行いたいと考えています。コストの見直しとか、経営フローだけでなく技術で改善できることもたくさんあるので。

—どんな人がマッチして働けると思いますか？

丹　私たちがGIVEできるものは「技術的にチャレンジできる環境」と「顧客とスクラムを組んでプロダクト開発を行える環境」です。ちょっと今、受託だけど距離遠いな〜とか、もっと色んな技術を取り入れたいな〜という人は是非お話したいですね。

豊福　あとは、案件ごとに事業課題を自分ごとにしながら物づくりに向き合いたい！という人がマッチすると思います。ビジネス課題の解決にも興味がある人。マルチな技術を持ちながら、お客さんと密にコミュニケーション取れる人は力を発揮できます。

—エンジニアだけでなく、デザイナーもチャレンジできる環境なのでは？と思いました

丹　もちろん、デザイナーの方もマッチしそうだと思った方はお話したいです！ユースケース分析してドメイン理解した上でのインターフェース設計など、むしろデザイン視点で力発揮できる瞬間が非常に多いです。

—興味を持ったらどうしたらいいですか？

丹　まずはお話ししたいですね。お互いにマッチしていることが大事だと思うので、面接とかじゃなくて。

豊福　今どういう課題感を持っていて、どういう風にスキルを生かしたいとか、どういう風に働きたいと思っているか、みたいな話題から話していけるといいなと思っています。私も悩んでいた頃はあるし、そこの相談は乗っていけます！

—ありがとうございました！