CTOが聞く Vol.5 fluct 笹本 & 尾池「顧客から圧倒的に信頼されるプロダクトをつくるために取り組んでいるfluctのエンジニアに話を聞いてみた」

CARTA HOLDINGSで働くエンジニアたちにCTOが「最近なにやってるの？」をざっくばらんに聞いていくシリーズです。今回はCARTA HOLDINGS CTOのすずけんが、事業子会社の一つであるfluctのCREチームの話を聞きました。「fluct」についてはこちら

インタビュアー：鈴木健太 Twitter ID @suzu_v（写真右）
株式会社CARTA HOLDINGS 執行役員CTO / 株式会社fluct取締役CTO。社内では「すずけん」と呼ばれる。「みんなのGo言語」「データ分析基盤入門」共著者。ウェブ技術全般に明るい。ポッドキャスト「ajitofm」をやっています。

インタビュイー：笹本将平（写真中央）
株式会社CARTA HOLDINGS / 株式会社fluctCREチームリーダー社内だと「さっさー(saxsir)」とか「さっさーさん」と呼ばれている。2016年に新卒入社してfluctでエンジニアをやったあと、不思議な経緯で採用人事をやって、またfluctに帰ってきました。

インタビュイー：尾池俊行（写真左）
株式会社CARTA HOLDINGS / 株式会社fluct CRE社内ではそのまま「おいけ(oike)」と呼ばれている。2020年の新卒入社で、笹本さんと同じように初めはfluctで配信周りやレポート周りを触っていて、1年くらい働いたあとにCREチームにジョイン。

鈴木（以下、すずけん）：CTOが聞く第5回、今日はfluctのCRE、Customer Reliability Engineering(顧客信頼性エンジニアリング) *1 チームの笹本さん、尾池さんと一緒にやっていきます。よろしくお願いいたします。

fluctでCREを作った背景とは？
CREチームの実際の仕事について
新しいツール、知識のキャッチアップをどうしているか
新プロダクトBID STRAPの立ち上げにCREがどう関わっていったのか
fluct CREチームの課題とこれから
顧客のやりたいことを分解して本当にやりたいことに近づけていく
CREにはどんな人に来てほしいか
PR

fluctでCREを作った背景とは？

すずけん：じゃあさっそくなんだけど、fluctにCREを作った流れとか背景とか、それから「そもそもどんな仕事なの？」というのを聞きたい。目新しいロールだと思うからね。そのあたりをざっと話してもらってもいいかな？

笹本将平（以下、さっさー）：fluctのお客様であるメディアに、広告配信に使うGoogleのアドサーバーをどんどん導入して収益を作っていくフェーズがまずありました。その後、周辺領域のソリューション、例えばHeader Bidding(ヘッダービディング)など、エンジニアがいないと導入が難しいようなものがいろいろと出てきて、当時のfluctの事業環境としてもそこに注力してやっていこうと、CREの前身として「テックソリューションチーム」というがあったんです。僕がジョインしたのは、テックソリューションの前任者が退職するというタイミングでしたね。

すずけん：2020年ごろ？

さっさー：はい。fluctの広告を入れてくれているメディアさんとしても、技術的な知識がないとどういう風にタグを貼ればいいのかわからないことがあります。fluct側のコンサル担当者もすべてを解決するのは難しくて、サポートとして試しにエンジニアを一人いれてみたらうまくワークしました。それが競合優位性になっていくだろうという判断でCREというチームを作りました。

すずけん：それはつまり、事業的に扱っているプロダクトの複雑性が増したタイミングだよね。fluct SSPというのが「タグを貼れば広告がでます」というサービスなんですけど、それに加えてGoogleアドマネージャー、つまり広告サーバー(アドサーバー)と言われているものを挟んで出すのがかなり主流になっていったのが2015年以降。グローバルな広告業界でも「アドマネージャーを使うとより一層いろんなことができるんだ」と、たくさんツールが出てきて、僕ら(= fluct、すずけんはfluct CTO)もそれをセットで提案することが増えていったんだよね。

さっさー：そうですね。戻ってきたらすごく難しい世界になっていました(笑)

すずけん：(笑) たしかに。さっさーが人事に異動したのが2018年？

さっさー：2018年ですね。ちょうどGAM(ガム、Googleアドマネージャーの略称)というか、当時のDFPとアドエックス(Ad Exchange)を売り始めた時期。そのときにもうテックソリューションは機能としてはあって。

すずけん：うん。顧客ニーズもかなり高まっていったので、これを専門として、テクニカルにこなすチームが欲しいなというのが当時のコンテキストだったと思います。そして、もとはテックソリューションチームだったのを「CRE」というラベリングに変えたのが2020年だったよね？

さっさー：そうですね。

尾池俊行（以下、おいけ）：そのタイミングで僕が入りました。

すずけん：最初はふたりのチームとしてスタートだったかな？チームというかペアじゃん、という(笑)

さっさー：もともとコンサル付けでエンジニアが二人いたのを、組織としても独立させた流れですね。二人だけど。

すずけん：そうだね、二人でもとりあえず「チーム」と言い切るのが大事かなと(笑)

おいけ：今はいっぱいいますからね。

すずけん：僕もそのときfluct CTOとしてさっさーと相談しながら「CREチームを作ったほうがいいんじゃないか？」と相談をしていましたね。

さっさー：そうでしたね。

CREチームの実際の仕事について

すずけん：さて、じゃあ実際にCREチームはどんな仕事をしているのか、イメージが湧きやすい形で伝えられるといいなと思うんだけど。

おいけ：はい。チームのミッションは「エンジニアリングを軸に顧客の課題を解決する」です。メディアからくる様々な要望に対して、技術を軸にして本質的な課題を見つけて提案・解決していくことですが、もう少し具体的にお話すると、メディアもいろんなバックグラウンドを持っているので、単純に広告を導入しようとしても「こっちのメディアでは広告が表示されるけど、あっちは出ない」みたいなこともよくあるんです。あとは「この広告はメディアに合わないから表示の仕方を変えてほしい」という要望へ対応したり、ツールを作ったりというのが主な仕事ですね。

すずけん：うんうん、ありがとう。CREチームは、普段誰と話す機会が多いの？メディアさんと直接話したり、あるいは社内のコンサルのメンバーなのか。

おいけ：一番多いのはコンサルメンバーですね。要望があればメディアの方とも話します。メディアさんに開発担当がいたらその方と直接話すのが早いので、そういう場合はコンサルと一緒に同席して話すこともあります。

すずけん：ふむふむ。ではもう少しテクニカルな内容も深掘りしていければと思うんだけど、メディアさんの言う「広告の入れづらさ」ってどんなかんじなんだろう？

さっさー：どこのメディアさんでも広告タグって既に入れているものがありますよね。なのでよくある「広告の入れづらさ」というのは、先に入っている広告の表示を壊さないように、ということです。まるっとfluctで置き換える場合もあれば、他社さんの広告とfluctの広告が一緒に配信されるケースもあるので、既に貼ってあるタグと競合しないように入れるのが難しいですね。

すずけん：なるほど、既存タグの挙動を壊さずに、僕らのタグもうまく動くようにね。

さっさー：そうです。メディアの担当者さんも入れている広告タグがどういう動きをしているかまでは、エンジニアじゃないので分からないと思うんですよね。なので、僕らが他社の広告タグの仕様を把握するところから始めます。「これはどういうときに表示されるんですか？」から始まり、それと競合しないようにfluctのタグを貼るにはどうしようかね、と。そして実際にタグをうまく貼ってもらうために、わかりやすくdiff (差分)を書いたコメントを渡して貼ってもらえるようにします。

すずけん：diff command渡してパッチ当てられるみたいな？

さっさー：「ここを消してこうしてください」という場合もあるし、渡す相手がエンジニアさんであれば、まるっと完成形で投げたりとか。

すずけん：ああ、なるほどね。

さっさー：そういう意味では、新規で立ち上げるメディアだとそこまで難しいことはないかもしれないですね。貼るタグがfluctだけなので「これを貼れば大丈夫です！」と。

すずけん：それはかなり、ソフトウェアエンジニアリングそのものに近いよね。既存で5年間開発されたものに付け足すのと、まっさらなところに貼るのとね。しかもメディア側の担当者さんが変わってたりとかね。「いやこれ前の担当者が貼ったタグなんですよね・・・・・・」とかありそう(笑)

さっさー：意味ありげに貼ってあるけどまったく動いてないタグもたまにあって、「これは外してもいいのか？？？」と(笑)

すずけん：僕も身に覚えがある(笑) 5年前くらいに渡したタグがまだ入っているけど動いてないとか、ありましたね〜。

おいけ：不安になりますよね〜。

すずけん：ね。あとは自分たちの広告をいれるときに、広告を入れるにあたっての問題だけではないと気づくこともあるんじゃない？メディアさんのWEBの実装そのものを見るわけだから。「こっち直したほうがいいんじゃないか？」って思うこともある？

おいけ：どこまで手を入れるかはけっこう悩ましいと思っていますね。気づきはしますし、クリティカルな問題なら指摘しますが、そのままでも問題なさそうであればそっと閉じますね。

すずけん：うん、そこが難しいところだよね。CREっていう観点でいうとしっかり安全、安心に広告タグを入れてもらって、広告を出して収益が出るように、というベースラインはやりつつ、やっぱりメディアを運営している人たちにコンサルティングをしているなかで「ここはこうしたほうがいいですよ」という指摘も、当然サービスに含まれていくじゃない？テクニカルな指摘のなかでそれをどこまで深堀りするか。深堀りすればコストも掛かるし。その塩梅やコントロールはCREを見ているとけっこう難しいのではないかと思ったんだよね。

さっさー：そういう場合は、もちろんコンサル担当には伝えて、そこから先の判断は任せることが多いですね。メディアさんのことを一番よく知っているのはコンサルなので。その情報を伝えてメディアさんが嬉しいなら伝えてもらって、ちょっと面倒だと受け取られそうならコンサル担当の胸にしまってもらう。

すずけん：そうだね、結局やりたいかを判断するのはメディアの方だしね。けっこうCREという仕事は、チームの名前とかやっている内容を聞くと受け身の仕事に感じられるかもしれないけど、実際はかなり探索的なことをやっているよね。「やりたいことはこれ(広告)を出すことなんですよ」と言われて実際見ていくと、そんなに単純じゃないと分かる。ツールが複雑だということももちろんあるし、コンサル担当やメディアの方もそこまで技術に詳しくない場合、それを知識として伝えたりとか、ケースによっても仕事の仕方が変わるよね。かなり自分たちの知識をベースに伝えていく側面も多いと思うけど、そのあたりはどういう風に感じてる？

おいけ：そうですね。必要な知識はめちゃくちゃ広いです。fluct SSPだけを知っていればいいかというと全くそうではなくて、アドマネージャーも知らなくちゃいけないし、メディア固有の事情も知らなければならない。Header Biddingとか最近だとBrowsi(ブラウジー)とか。いろんなサードパーティツールを使っていくという話もあるので、そういうものを能動的に調べていく動きはどうしても必要になります。なので受け身ということはないかなと。

corp.fluct.jp

新しいツール、知識のキャッチアップをどうしているか

すずけん：新しいツールって海外からぽんぽん出てきて(笑)、まあそれを日本に持ち込んでいるのも僕ら(fluct)という側面はあるんだけれども。ツールを見つけてくるのは経営メンバーとかアライアンス担当だったりするんだけど、ツールの使い方とか実際に導入するならこういう工夫はしなきゃいけないなとか、テクニカルなキャッチアップに関してはCREのなかで共有したりしている？勉強会とか。

おいけ：勉強会まではしていないですが、一連の動作や挙動は見ますね。コンサル担当から質問がきたら答えられるようにある程度は見ておいて、でも中身がブラックボックスだと外側から見た挙動だけではわからないことも多々あるので、広告ツールのベンダーのエンジニアに質問を投げることもありますね。

さっさー：CRE内だと30分〜1時間くらいで週次の共有会もやっているので、そこでキャッチアップはできますね。「おいけさんがこの1週間にやったこと」とか共有する時間があるので、そこで事例の共有や質問をしあう。「このメディアでこれを入れたらこうなって困りました。詳細はチケットみてね」というかんじ。

すずけん：なるほどね。ツールベンダーとかツール系のなかのエンジニアと直接やりとりする。PrebidのときはBrowsiのエンジニアの人たちとしばらく話をしていたり、けっこうCREで巻き取って話をしていたよね。BID STRAPを作るときとか。

おいけ：そうですね。BID STRAPを作るにあたり、メディアに近い部分はCREで巻き取っておいたほうが後々良さそうということだったかと思います。

さっさー：Prebidの配信の仕組みを考えたら、Browsiの挙動はどうなるんだろうね？とか、このやり方でやるとここは競合しそうじゃない？など、疑問や気づいたことをもってMTGに臨むという動きが、fluctの新しいプロダクトを作るときには多かったですね。

新プロダクトBID STRAPの立ち上げにCREがどう関わっていったのか

すずけん：うんうん。今しれっと新プロダクト作ってそれを持っていったぞ、という話が出たんだけど(笑)、このBID STRAP自体も説明しないとね？BID STRAP自体もHeader Bidding Wrapperのプロダクトだよね。

おいけ：そもそもHeader Bidding Wrapperがなんなのか、ということで言うと、メディア側がHeader Biddingを導入するときにいくつかの困りポイントがあるんですけど、例えばタグがけっこう複雑だったりとか、いろんなBidderとの契約を交わさなければいけないとか、デバックが難しいとか。そういう困るポイントをまるっと解消するのがHeader Bidding Wrapperというソリューションですね。それをfluctで作ったのが「BID STRAP」という新プロダクトの名前です。

さっさー： そうですね、様々なメディアをお手伝いしてるのでHeaderBidding導入時のハマりポイントはめっちゃ踏み抜いていて(笑)、相談が来ていたんですよね。なのでBID STRAPはそれがないようにしようと。

すずけん：運用のペインとかも含めてね。こういう風に、CREというチームの機能自体、僕からみたときに「いわゆるテクニカルサポート的な部署だよね」と社内的にも社外的にもわかりやすくラベリングされるものでもあるんだけど、新しいプロダクトを作るときに、顧客ペインもわかっているし、プロダクトペインもわかっているし、自分たちでテクノロジーも持っている。なので、プロダクトを作るときは「CREに聞けばわかる」という状態だったのがBID STRAPを作っているときの印象としては強いですね。知識を貯める機能が社内にあるのはすごく強い構造だなと思います。

おいけ：なかなかメディアに対して直接話しを聞く機会はないので、その部分を担えているのは大きいのかなと思いますね。

さっさー：たしかに、社内機能としてだと本当に便利ですよね(笑)

すずけん：関連して話を展開していくと、普段fluctってSSPの開発チームがあって、CREのチームとは別になっているじゃない？開発のエンジニア陣とのやりとりってどんなかんじなの？あまりない？

さっさー：意外と少ないような気もします。配信に関する見た目の部分とかをメディアの要望で開発するときもあるけど、だいたいCREでやっちゃうので、開発チームとのやりとりはあまりないですね。

おいけ：メディア側からみて配信サーバーのなかの動きに対して要望があることってほぼなくて、ほとんどは見た目の部分。必要であればSSPの機能としてそこを組み込むとかはあるかもしれない。

さっさー：たまにSSPの機能について質問することはあります(笑)「こういう配信したいんだけど、できたっけ？」みたいな。

すずけん：そうそう(笑)最近、fluct SSP も高度化しているから。ターゲティング機能とか、ajiyoshiさんが2年くらいかけてやってたりね。CREと開発チームって実は近いようでもはやサービスベースのやりとりになっているよね。個々のコミュニケーションというよりも「fluctサービスとしてこれをやってもらってケイパビリティだけもらえれば、あとはこっちでやっておきます」みたいな。

おいけ：CREは他のプロダクト、GAMとかも見ているので、そもそも見ている範囲が全然違うなとは思います。

すずけん：そうだよね。チーム構成としても、fluctのコンサルメンバーの隣にいるくらいに近くにいるし、かつ、fluct SSPのプロダクトチームでいうと、そこはもはやサービスとして使っていて、それくらい立ち位置がメディア、顧客側にいる開発チームだよね。価値の提供をCRE単体で閉じてできるようになっているのが非常にすばらしい話だと思ってます。

おいけ：そう思います。

corp.fluct.jp

fluct CREチームの課題とこれから

すずけん：じゃあ次は「実際にCREってどう？」という話を聞きたいと思ってます。CREのチームとして仕事をしていて、うまくやれている？あるいは「もっとこういうふうにしたいな」という課題があったりする？

おいけ：バリューは出せていると思っています。つい先日社内のコンサル担当からフィードバックがあったんですが、fluctと他社さんのコンペがあったときに、そのときの資料に「CREという技術サポートがありますよ」というアピールがされていて、実際にそれがあることによって、先方のエンジニアさんの不安が解消されてfluctを選びましたと言っていただけて。そういうところでfluctの競争力にバリューを出せていて、ワークはしていると思います。一方で、もっと事業拡大していこうとしているなかで、CREチームはその拡大スピードに追いつけているかというとそうではないので、今後の課題ですね。

すずけん：そうだよね。仕事の比率としては、どうしても自分たちの頭で考えて対応していかなきゃいけない部分があるから、案件とかメディアが増えていくとCREのキャパシティを超えちゃうっていうことだよね。ちなみに、あと何倍にしたいとかあるの？

さっさー：いまはエンジニア三人とサポート一人で四人体制ですね。コンサルがもうひとつ大型案件をもってきたら破綻しそう(苦笑)

おいけ：あと二人くらいいてもいいのかなとは思いますね。余裕をもって仕事するには。

すずけん：フィールドエンジニアリングとかテクニカルサポートとかも同じだと思うけど、あるなら使いたいチームになっているからね。コンサルからすると「え、CRE余裕あるの？じゃあ、案件とってくるわ」みたいな(笑) もちろん、CREのサポートをいれなくても取れる案件もあるけど、ちょっと複雑性が高いプロジェクトになってくると「CRE来てください！」となるからね。そうなると人が欲しくなるよね。

さっさー：10人いたらいたで相談件数が増えてくるんだろうなと思いますね(笑)いままで遠慮していたものが出てくる、みたいな。

すずけん：比例して事業が伸びてくるなら、というのは経営の考え方としてはあるけど今度は人数以上の効率が出ないという話にもなってくるからね。課題としてありそうだなと思ったのは、CREひとりあたりの生産性。ひとりができる仕事の幅とか質とか量をあげるための仕組みとか仕掛けはCREのなかで考えていたりするの？

おいけ：ひとりあたりの生産性をあげるという視点では、システムを作って効率化していきたいよねと話しています。今はメディアさんと直接やりとりするうえでのコミュニケーションコストが掛かっているんですよね。依頼がきて、それに対してソリューションを提示して実装してほしいという話をするときに、まずメディアさんからコンサルに話がきて、コンサルからCREに相談がきて、CREが必要であればタグをつくってコンサルからメディアに納品する、問題があれば連絡がきて、タグを修正して・・・・・・という繰り返し。修正も大変ですし、単純にミスがないようにメディアさんに対して張り替えの文面を考えるとかもコストを使っているので、そういうコストをなくせるように改善していこうという話をしています。

すずけん：つまり課題としてはコミュニケーションコスト、必ずプロキシとしてコンサルが入っていて、本当はCREと直接やりとりしたら早いけど、そうすると今度はCREの人手が足りなくなる。そこは伝達できる仕組みなり枠組みなりを用意したいって話だよね。あとやっぱりメディアさんの実装を修正するとなったら、そこを透過的にできたほうが手間が省けるということだよね。

おいけ：そうですね。こちらで裏側を直せたらこちらも嬉しいし、メディアさんも嬉しいのではないかなと。

すずけん：ただもちろん、メディアさんに信用してもらわないと「勝手に壊しましたね！」ともなってしまうから。そこは信頼に基づいてやる必要はあるけども、やりとりを通じてこちらから直すことができる方がいいよね。つまりこれは、タグ改編のリードタイムを縮めたいという話。

おいけ：そうです。

すずけん：たしかに、この方向性はひとつストレートに効いてきそうだよね。CREというよりはカスタマーサポートにも近い問題構造かと思う。問題が起きたときに問い合わせを受けてレスポンスを返して、なにかを試してもらう。例えば「このスマートフォンが壊れたんだけど」って問い合わせきて「充電されてますか？」って返して充電してもらって「直りません」と(笑) そういうやりとりをすると問題解決までに時間がかかるというのが構造としてあって。そういうのはウェブのシステムの仕組みをうまく使ってデリバリーとかリードタイムを短くして、こちらで調整できるというのはアプローチのしがいがある環境だと思うね。

顧客のやりたいことを分解して本当にやりたいことに近づけていく

さっさー：あとは、例えば「収益をあげるためにこういう施策をやりたい」というのがポーンとくるんですけど、そういう顧客のやりたいことを分解して要求定義するところからCREが入っていて。「ブラウザの戻るボタンを押したときだけインステ(広告)出したい」という具体例だったとすると、「検索から流入したときはどうするんですか？」とか「記事内の遷移ではどうするんですか？」とか最初の依頼段階では分からない。そういう細かい仕様を深堀りしてヒアリングしていったり。それが決まったら技術的にそれをどう実現するか要件定義をしたり。ウォーターフォールでいう、要求・要件から、設計、開発、テストみたいに、わりと1回を小さくまわしていくし、CREはチーム単位でサイクルがぐるぐる、ぐるぐる回っていく。そのへんはおもしろいですね。

すずけん：デリバリーするものの単位が、最終的には広告タグとかだから、ある意味ソフトウェア自体、モノをまるっと作ってAPIを書くよりももっと短いよね。

さっさー：そうです。週に何回かそのループをまわすので。ひとつどーん、というかんじではないからおもしろいし、いいトレーニングになるなと。

すずけん：「やりたい」と言われたことをそのままやるんじゃなくて、どうあるのが理想的ですか？というのをメディアの方と対話しながら詰めていく。そこの精度をどんどんあげることが、fluctとしてもプラスになるし、メディアからの信頼にも繋がる。ここをぐるぐる回せていることは事業にとって非常に重要だよね。

さっさー：コンサルも、経験があがると要求定義の練度もあがるし。

すずけん：コンサル自体も知識、知見がついていって「このパターンだとこうだな」というような提案のレベルがあがっていくということも起きているということだよね。

さっさー：その件数が溜まったり、コンサル内でそういう共有があると、fluctのプロダクトがパッケージ化されて提案に持っていけるようになります。さっきの「戻るボタン〜」のような事例も、何件かメディアで導入実績があると、このやり方でできるんだとパッケージ化される。そうすると全メディアへ提案できる。

すずけん：そうだね。次はさらに提案資料に載っているとかね。いわゆるフィージビリティができて、こうやったらできるなとなったものが今度はスケールする段階になっていく。ここの流れは営業チームを見ていると非常にスムーズにやっているなと思うよね。

おいけ：早いですよね、動きが。

すずけん：そうそう。水を得た魚みたいな(笑)

さっさー：で、件数が増えると慌ててCREが「ちょっと管理画面からいけるようにしよう！」みたいな(笑)

すずけん：広告タグのオプションでこれもいけるようにしよう、と手書きで変えられるようにしているけど管理画面からはできないとかね。スイッチングできるレイヤーを変えていたりするよね。

さっさー：最初はタグを書き換えてもらって、広く展開できるようなら管理画面で誰でもポチポチできるようにしたり。

すずけん：機能のスケールのレイヤーと、営業のスケールのレイヤーをCREが辻褄あわせているっていう(笑) そういう印象があるね。

さっさー：そうですね。

すずけん：CREで鍛えられる力という点では、たしかに要求を噛み砕く、要件を噛み砕いていくっていう、ここのトレーディングがすごく育つポジションだなと聞いていて思った。

さっさー：解決に使うツールが内部プロダクトではないので。Googleのアドサーバーだったりとか、ただのJavascriptだったりもしますけど。そのへんは鍛えられますね。

おいけ：謎にMinifyされたスクリプトを読んだり。

さっさー：調査能力身に付くよね。メディアからMinifyされたjsを読んで、なんかこのへんでやってそうだな〜みたいな。Chromeのデバッグツールにはめっちゃ詳しくなりますね(笑)

すずけん：そうだよね、Chromeのデバッグツールを触っている時間が一番長いんじゃないかな(笑)

おいけ：長いですね(笑)

すずけん：CREで身に付く力っていうのはすごくいいですね。

CREにはどんな人に来てほしいか

すずけん: ありがとう。じゃあ最後はCREにどんな人が来てほしいか聞きましょうか。

さっさー：そうですね。いま言ったみたいな、メディアのやりたいことを噛み砕いて「つまりこういうことがやりたいんですよね？」と解決していくのが楽しい人、そういう人に合っていると思いますね。逆にいうと技術的に難しい問題はあんまりないです。どちらかというと、何をやりたいのか噛み砕いて整理するのが一番難しいチームだなと思います。言われたことをそのままやるとよく分からないものができあがる。ソフトウェアエンジニアってみんなそうだと思いますけど。顧客、つまりfluctの場合はメディアさんのために、やりたいことを整理してあげて、実際に彼らが嬉しくなるように提案してあげたりとか解決してあげたりとか。もしくはそれが社内のコンサルも喜んでくれることになる。隣のチームの人が喜んでくれてうれしいって思う人にむいているんじゃないかと思いますね。それが週に何回も繰り返されるので。そういうのが好きな人にはすごく楽しいと思います。

すずけん：はい。皆さんお待ちしてます！(笑)

おいけ：お待ちしてます！

すずけん：テクニカルに難しいという話もあったけど、むしろ、テクニカルに難しい手段をとったら負けというか。問題解決レイヤーでちゃんと噛み砕かないと無限にはまっていく世界だと思うので、そこの判断能力が非常に大事なポジションかなと理解しています。はい。ということで、今日はfluct CREチームの二人に話を聞きました。どうもありがとうございました。

さっさー＆おいけありがとうございました！