はじめに

GENIEE インフラチーム片岡です。2019年に新卒として入社し、最初の二年間は DSP のフロントチームで管理画面の開発をしていましたが、2021年中頃からチームを異動し、今はインフラ寄りのお仕事をしています。
そのころから、DSP のレポート集計基盤を刷新するプロジェクトが動いており、なんやかんやあって遂に数ヶ月前にリプレイスが終わりました。今回はこれについてお話をしたいと思います。

片岡　崇史／高知工科大学大学院を卒業後 2019 年に新卒入社。R&D アドプラットフォームサプライサイド開発部 DevOps チーム所属。

レポート集計基盤について

弊社では、オープンソースの列指向 DBMS のひとつである ClickHouse を使ってレポートデータを閲覧できるようにしています。
過去の ClickHouse の利用については以下をご覧ください。

• MySQLを捨てClickHouseでレポートAPIのレスポンスを1000倍高速化した話
• ClickHouseのテーブル構成を考え直してみた

レポート集計基盤は、弊社の DSP から配信された広告の成果ログから成果を集計し、最終的に ClickHouse のレポートテーブルに結果を入れます。

旧レポート集計基盤

旧レポート集計基盤は以下のような流れになっていました（図1）。ログを出力するサーバは、ログを Logstash によって Kafka に転送します（図1①）。Flink は Kafka からログを読んで集計処理を行います（図1②）。Flink アプリケーションの処理は大きく分けて、重複排除を行うステップ、数値を集約するステップ、ClickHouse のレポート DB に格納するデータの形に変換するステップがあります。各ステップの処理結果は kafka に転送され、次のステップは先のステップの結果を Kafka から読んで処理を行います。最後に ClickHouse は集計結果を Kafka から読み、レポートテーブルに格納します（図1③）。

↑図1

旧レポート集計基盤の辛かったところ

旧レポート集計基盤では主に以下が問題になっていました。

1. 成果ログを使った調査が面倒
2. Flink を運用保守できる人が少ない（再集計が必要になったときの作業が面倒）
3. Logstash が何故か安定しない

運用上、生の成果ログを使った調査を行いたいことがしばしばあります。しかし、ログファイルは大きいので調査対象の期間が長くなると検索するだけで何十分と時間がかかることもあります。
２つ目の問題として、Flink アプリケーションの保守＆運用が難しく、誰も触りたがらないものとなってしまっていてなんとかしなければいけません。
また、ログパイプライン上で何か問題が起きて流れているログが一部欠損したような場合は、その時間帯のログからレポートを再集計する必要がありますが、そのときの手順も複雑でかなり面倒なものとなっていました。この手順のミスで再び再集計作業が必要になることもありました。
ログパイプライン上で問題が起きやすかったのは、ログ転送エージェントとして利用していた Logstash です。突然ログの転送が停止し、「よくわからないが再起動したらなおったのでﾖｼ」ということもしばしばありました。バージョンアップやチューニング、Logstash のソースコード調査などを行いましたが、結局解決されず原因は謎のままです。

方針と期待する効果

新しいレポート集計基盤の方針としては以下のようになりました。

1. Flink は撤廃し、成果ログをそのまま ClickHouse に流し、ClickHouse 上で集計を行う
   a. ClickHouse に成果ログを保持するテーブルを設けることで、成果ログの調査 が簡単になる
   b. Kafka のストレージ容量・通信量が削減される
2. ログ転送エージェントを Logstash から td-agent-bit に変える
3. ログ形式を JSON に変更する

まず Flink は撤廃することにします（さようなら）。代わりに成果ログの処理を行うのは ClickHouse で行うことにしました。弊社ではこれまで ClickHouse をレポート閲覧・分析用の DB としてのみ利用していたので新しい使い方にはなりますが、先輩方のこれまでの知見もありこれ自体に大きな問題もなく実現することができました。使い方としては基本的に普通の SQL なのでチームの人員に入れ替わりがあっても対応できそうです。
これに伴い、生の成果ログを ClickHouse に流すことになるわけですが、この成果ログを ClickHouse のログテーブルとして一定期間保持するようにすることにしました。これによって、その保持期間の間は調査に必要なログを SQL を使って取得することができます。成果ログを頻繁に調査する人にとっては結構嬉しい改善です。
先に述べたように、旧集計基盤の Flink アプリケーションは、各ステップの処理結果のデータが Flink と Kafka の間で往復していました。今回の変更はこのやりとりを無くすことになるので、Kafka のストレージ容量と通信量が大きく削減されます。
ログ転送エージェントの Logstash が安定しない問題の対策として、これを td-agent-bit (fluent-bit) に置き換えることにしました。弊社ではログ転送エージェントに td-agent (fluentd) を使っている部分が多いですが、以下の理由で td-agent-bit を選択しました。

• Kafka にログ転送を行うにあたり、td-agent-bit は librdkafka のバージョンが新しいものが使われていてかつ細かい設定が可能である
• CPU 使用率が大きく減少した。遅延が減ると期待できる

また、元々のログ形式は LTSV でしたが、これを JSON にすることにしました。多少ログのサイズが大きくなることが予想されましたが、代わりにログを扱いやすくすることを目指しました。

新しいログパイプラインとレポート集計系

以上を踏まえて設計すると以下のようになりました。（図2）

↑図2Kafka にログを流すところまでは、ログ転送エージェントが変わったこと以外は基本的に同じです。
上で述べたように、生ログの処理も ClickHouse で行うのですが、これまでレポート閲覧に使っていた ClickHouse クラスタ（以下、閲覧用クラスタと呼ぶ）とは別に、新しくログ処理のための ClickHouse クラスタ（以下、ログ処理用クラスタと呼ぶ）を作りました。Kafka からログを読むのはこのログ処理用クラスタのみになります（図2②）。このクラスタは Kafka から読んだログをパースして一定期間保持します。また、パース済みログを ClickHouse の Materialized View を利用して結果を閲覧用クラスタのレポートテーブルに挿入します（図2③）。このレポートテーブルはテーブルエンジンに SummingMergeTree を使っており、ここで数値が集計されます（後にもう少し詳しく説明します）。このようにクラスタを分けることにより、多くのレポート分析クエリが走って負荷が大きくなってもログ処理系に影響が出ないようにしました（その逆も同様）。
旧レポート集計系の良くなかったところとして、広告配信コストの計算のようなビジネスロジックの一部を Flink で行っていたということがあります。基本的にビジネスロジックは、ログを作るアプリケーション側で処理をして結果をログに落とすという形を取っていたので、ビジネスロジックを処理する場所が分散していました。そのため、今回 Flink に残っているビジネスロジックは全てログを作るアプリケーション側に寄せる変更を行いました。これによって、ClickHouse の集計はログに書いてある値を集約するだけで可能になりました。

ClickHouse 上でのレポート集計に使った機能

簡単にですが、ClickHouse 上でのレポート集計を支える機能の一部をご紹介します。

Kafka table engine

Kafka からログを読むのは Kafka table engine を利用しています。このテーブルを select することで Kafka のデータを consume して読むことができます。consume するので同じデータが読めるのは一度だけで、実際には以下で説明する Materialized View を使ってデータを読みます。

Materialized View

一般的な DB の Materialized View は、クエリ結果を期限付きでキャッシュする形で動作しますが、ClickHouse はそうではありません。ClickHouse の Materialized View は参照しているテーブルにレコードが挿入されたのをトリガーとして、そのレコードのみに対して処理を行い、結果をその Materialized View または指定する別テーブルに挿入します（別テーブルに挿入した結果はもちろん消えることはありません）。差分に対してのみ処理が行われるため高速に処理してくれます。

新レポート集計基盤では主に以下の用途で Materialized View を使っています。

1. 生ログテーブルを読み、パースしてパース済みのログテーブルに挿入する
2. パース済みのログテーブルを読み、レポートテーブル（SummingMergeTree table engine）に挿入する

1 では JSON 形式のログをパースして、必要なプロパティをカラムにしてログテーブルに挿入しています。
最終的なレポートテーブルは SummingMergeTree table engine を使っています。SummingMergeTree table engine は、挿入されたレコードを、テーブル定義の中で明示的に指定した特定のカラム（数値の型）のみ足し上げてくれます。2 の Materialized View が各成果情報を SummingMergeTree のレポートテーブルに挿入することによって、レポートテーブル上で必要な各種広告配信の指標（インプレッション数やクリック数、その他配信費など）が足し上げられ、結果が閲覧できます。

JSON を扱うための関数群

ClickHouse では JSON を扱うための SQL の関数が用意されており、我々はこれを利用して JSON のパースを行っています。C++ や simdjson を使って実装されているため、大量のログも高速に処理できています。

改善されたこと

当初の狙いだった以下のことについては達成することができました。

1. 成果ログの調査が楽になった
2. レポート集計基盤が安定し、再集計が必要になることがなくなった
3. Flink を完全撤廃することができた（以前より運用しやすい状態になった）

上記以外では、Kafka の転送量が減ったことによって Kafka のサーバ台数も減らすことができました。Kafka サーバは約半数減、Flink サーバ全台撤廃、ClickHouse の集計用クラスタに数台のサーバを追加となり、全体のサーバの増減としては 10 台以上のサーバ減となりました。
また、ログが落ちてからレポートに反映されるまでの遅延が大幅に短くなりました。旧レポート集計基盤ではピークタイムに約 30 分の遅延がありましたが、新レポート集計基盤では基本的に 2 分以内に収まっています。

おわりに

レポート集計基盤の刷新した件について、新旧の違いと改善できたこと等を説明しました。と、まあ全てが上手くいったような書き方をしてきましたが、間で多々問題があったので着手から完了までかなり時間がかかり、関係各所にはご迷惑をおかけしました。今回は多くの勉強・反省することがあったので、今後これを活かして頑張っていきたいと思います。

GENIEE DOOH開発チームの朴（パク）です。
現在、DOOHチームでAndroidアプリの開発をしています。
今回、GENIEE DOOHに興味がある方向けにプロダクトの構成と、スケジュール登録からコンテンツ放映までの流れを説明しようと思います。
^{※本記事はコンテンツがスクリーンに表示されるまでの説明になるため、メディア向けのサービス（DOOH SSP）に重点を置いて説明しています。}

Contents

１. DOOHとは
２. GENIEE DOOHの構成
３. スケジュール登録
４. STBとDOOHアプリ

１. DOOHとは

DOOHはDigital Out Of Homeの略で屋外デジタル広告のことです。

２. GENIEE DOOHの構成

GENIEE DOOHプラットフォームの構成要素は3つに大別されます。具体的には①コンソール画面、②バックエンドサーバー、③DOOHアプリになります。エンジニアの技術区分で言うと、Front-End、Back-End、Appになります。

①コンソール画面はSSP（Supply Side Platform）とDSP（Demand Side Platform）に別れて、SSPでは広告配信できる媒体を持っているメディア向けのサービスを、DSPでは広告を入稿したい広告主または代理店向けのサービスを提供しています。
②バックエンドサーバーは、コンソール画面で登録したスクリーンの情報、広告の単価、予算、広告枠、空き枠の時間を計算して、スクリーン（配信を行う画面）ごとにスケジュールを作成して、配信側でデータを取得できるように変換してくれます。また、配信が終わった広告の集計やレポート作成など、目には見えない計算とコンソール画面と配信アプリ間のデータ連携を担っています。
③最後に、DOOHアプリはコンソール画面で設定したスケジュール通りに広告を配信し、配信された結果を定期的にサーバーに送信しています。

３. スケジュール登録

前章でも少し触れていますが、サイネージでコンテンツの放映をするためには、いつ、どのスクリーンで、どのコンテンツを流すかを決める「スケジュール」が必要です。
ここからは実際のコンソール画面を用いてSSP側でのスケジュール登録と商品作成手順を説明します。
まず、SSP側の画面でメディアと広告を流したいスクリーンの情報（名称、営業時間、デモグラフィック情報、入稿可能動画形式など）を入力して保存します。

その後、配信したいクリエイティブがあれば、入稿をしておきます。

このまま「タイムライン設定」ページに進んで、スケジュール設定も可能ですが、一定時間ごとに固定のクリエイティブを流したい場合（例：1時間ごとに同じスケジュールにしたい場合）には、先にロールを作成します。
ロールにクリエイティブを配置したら名前をつけて保存します。

広告枠はDSP経由で商品として販売することができます。商品は、「純広告」（パッケージ販売）と「PMP(PD)」（imp/CPM販売）の２種類で販売可能です。

時間ごとにコンテンツ枠、広告枠、ロールが決まったら、いよいよ「タイムライン」ページに進んで、放映時期と放映するスクリーンを選んでスケジュールを登録します。登録したスケジュールは翌日分から配信に反映されます。

４. STBとDOOHアプリ

放映するスケジュールが決まってサーバーに反映されたら、物理機器を操作して画面にコンテンツが表示されるように準備します。屋内用タブレット型サイネージも存在しますが、今回は屋外のビルボードを想定して説明します。
必要なものは①モニター、②STB（Android）、③HDMIケーブル、④DOOHアプリになります。
よく「STBって何ですか？」と聞かれますが、STBは「Set Top Box」の略で「小さいデスクトップPC」だと思って頂ければ分かりやすいです。屋外で見るビルボードは、いわゆる大きいモニターと、STBとを繋げてパソコンの画面を表示していることになります。（図はHDMIケーブルを使って表示しているサンプルです）

モニターとSTBを繋いで電源を入れたら、DOOHアプリをインストールします。

アプリの初回起動時には認証用の画面が表示されます。この画面ではコンソール画面で発行されたID/PASSを入力し、受け取るスケジュールを指定します。アプリはバックエンドサーバーから受け取ったスケジュールに基づいて、必要なクリエイティブをダウンロードし、登録された時間通りにクリエイティブを放映します。

^{※容量削減のためフレームレートを落としています}

５. おわりに

ここまでプロダクトの構成と、スケジュール登録 〜 コンテンツ放映までの流れをざっくり説明しました。もっと詳細のことを知りたい方や、デジタルサイネージに広告を出したい方はいつでもご連絡お待ちしております。

【GENIEE DOOH紹介ページはこちら】
https://geniee.co.jp/products/dooh.php
【メールでの問い合わせはこちら】
dooh@geniee.co.jp

2021年4月、ジーニーでは新たなCxOが誕生し、5人のCxO体制となりました。今後、ジーニーを牽引していくCxOを代表して、初のCPO（Chief Product Officer）に就任した大橋弘崇さんに、ジーニーの展望や全社のプロダクトの方向性について伺いました。

大橋 弘崇（おおはし・ひろたか）
執行役員CPO 兼 R&D本部 プロダクトマネジメント部 部長／アド・プラットフォーム開発部 LAMP開発グループ 部長／マーケティングテクノロジー事業本部 カスタマーサクセス部 部長／ビジネスサーチテクノロジ株式会社 取締役

ーー4月、CPOに就任されました。抱負を聞かせてください。

CPO（Chief Product Officer）はあまり日本でも就任者が少なく、馴染みがない方も多いと思いますが、海外ではメジャーな役割です。自分もまだ手探り状態ですが、自分がジーニーでやる仕事がCPOの仕事になっていく、と思ってやっています。

CPOとしてまず進めていきたいのは「発信」と「PMの育成」

二つ観点があると思っていて、一つは「発信」。
プロダクトのビジョンや重要な方針を全社に伝えていくべき立場になったと思っています。
各事業部の仕事が横でつながるようなビジョン、プロダクトの新機能やクライアントの声を発信できるような場を作りたいですね。

プロダクトは別に開発だけのものじゃない。使う人や売る人やサポートする人、関わる人全員のプロダクトなので、開発者と使い手、売り手を繋ぐ存在として全員が幸せになるようなプロダクト創りをしていきたいと思います。

もう一つの観点は、「プロダクトマネージャー（以下、PM）の育成」。事業の成長や成功の可否を握るPMについては代表取締役社長の工藤さんからも以前から話があり、ここはより力を入れて進めたいと思っています。

ーーPMの育成が大切だ、というメッセージをもう少し掘り下げて教えてください。

PMの役割は会社によって多少異なるんですが、共通しているのはプロダクトに関する最終決定を行い、責任を持つということ。プロダクトのロードマップ作りなどの計画策定、企画立案から、顧客体験の設計、ローンチ後の改善など、幅広い領域でやることやスキルが求められ、全ての領域で社内外のプロフェッショナルを巻き込んで推進していく必要がある。

今後ジーニーが時価総額1兆円の企業になっていくうえで、ジーニーの文化や財産である自社プロダクトという軸は非常に重要になります。そのプロダクトを中心で支える存在がPMです。1兆円企業になると、今よりも多数のプロダクトを世の中に提供している企業になるでしょう。その為にも現任のPMの人には非常に期待をしていますし、社内外から優秀な人材が集まってくるような部署にしたいと思っています。

PMの意思決定が事業の鍵を握る

１年程度で一領域では成果を出せるようになりますが、事業ドメインが変わると動き方や必要な知識、スキルも変わる。PMとして本当に仕事ができるようになるには、優秀な人でも３年くらいかかるんですよ。

ジーニーの場合は、PMへの期待や裁量が比較的大きい方だと思いますが、まだまだロールモデルが曖昧なので、そもそもPMはどうあるべきかを定義して自ら体現し、若手を一人前のPMになるまで育成するのが自分の役目だと思っています。

一方で、事業の観点でプロダクトを見ると、ジーニーは複数のマーケティングプロダクトを抱えていますので、俯瞰して全体のバランスをとり、プロダクトのポートフォリオで戦っていく観点を磨き続ける必要があると思っています。

ジーニーに全て任せたい、といっていただけるように

大きな方向性としては、プロダクト単体ではなくジーニーの全プロダクトを使ってくれるお客様を増やしていきたいと思っています。これからもジーニーのプロダクトはマーケティングに必要な機能をどんどん追加していく予定です。

世間では企業が複数のSaaSツールを導入することが当たり前になってきましたが、反面統合管理が難しくなってきているという現実があります。先日、ある企業の方が「32種類のツールを部署ごとにバラバラに使っていてデータ管理が難しく、非効率なんだ」という課題を話してくれました。都度違う担当者と打ち合わせをしていくというのは、非常に難しいですし非効率。また、マーケティングの課題が明確にわかっている担当者であればどのツールがソリューションになりうるかがわかりますが、全てのマーケ担当者や営業担当者がそうではないと思います。

企業のDXが進めば自然と導入ツール数が増えると思いますが、それにより複数サービスの弊害に直面する企業は今後増えていくと思います。ジーニーがワンパッケージでソリューションを提供できるから、ジーニーに任せておけばマーケティングの課題は全て解決する、といってもらえる存在になりたいと思います。

最終的には各領域でもちろんNo.1を目指しますが、マーケティングツールはジーニーに全て任せる、といってくださるお客様の数を伸ばしていきたいと思っています。

そのためにはプロダクト同士の機能連携も強化していかないといけないし、連携できるからこそ提供できるバリューを強化していきたい。SFA/CRMのデータをMAのセグメントに使う等という基本的な連携は、その一例ですね。


ーージーニー流のNo.1の目指し方とはどういうものなんでしょうか？

ジーニーは、これまでプロダクトを作ったり改善したりしていく際に、GoogleやSalesforceなどのグローバルでトップシェアを持つ企業をベンチマークとして設定して成長してきました。海外の先行者を見習いつつ、ローカルのクライアントの声を聴きながらユーザー体験や機能の土台を顧客に合わせて創っていく、という戦い方がジーニー流のサービスの磨き方だと思います。

ーー今後の中長期の方針についても教えてください。

社のミッション「テクノロジーで新しい価値を創造し、クライアントの成功をともに創る」をより具体的なプロダクトビジョンという形で体現し、どんな世界をジーニーが目指していくのか、を社内外に対して発信していきたいです。

プロダクトを通じて、ジーニーのファンを増やしていくというのも重要な自分のミッション。ファンの顧客が増えていくことで更にプロダクトに投資ができ、ファンの顧客により価値を返すことができる、という好循環を創っていきたいですね。

今のビジネス活用における技術トレンドは人工知能やAI、機械学習です。
人がやっている単純作業を機械に置き換えようというDXの流れのまさに真っ只中を生きていると思います。昨年、ジーニーでは「GENIEE DSP」でAIを使った自動入札機能をリリース（※）しましたが、強みとなる最先端のテクノロジーをプロダクトに昇華させ、AIや自動化によって業務を効率化し、全ての働く人により創造的な仕事にフォーカスしてもらう環境を提供することで、クライアントの成功を共に創っていきたいと思います。

また、お客様の成功を作るには、ツールを提供して終わりではありません。常に「もっとお客様が楽になるにはどうすれば良いか、業績を上げるにはどういった使い方ができるだろうか」と言う提案設計が求められています。ジーニーではカスタマーサクセスの領域も積極的に強化しており、色々なことができる「製品」を顧客の課題を解決できる「サービス」に昇華させ、顧客の成功を共に創るまで伴走できる組織でありたいと思います。
その為にも、ジーニー社員が顧客の成功にフォーカスできるような体制や環境作りの一環としてジーニー自体のDXも更に推進していけるように社内外に働きかけを行っていきます。

※ 2020年11月、「GENIEE DSP」において AIを利用た自動入札機能の提供を開始
https://geniee.co.jp/news/20201111/259

何かをゼロから生み出す楽しさ、作り出したものを使ってもらえる喜び

何かをゼロからつくり出すって、すごく面白いことだと思うんですよ。プロダクト開発にはゼロイチでものを生み出す要素が詰まっていて、エンジニアが構想して「作れる」と言ったものは、時間がかかっても必ずできるんです。
そうして世に生み出したものを多くのお客様に使ってもらえると、すごく嬉しいし面白い。そんな体験にジーニー社員には関わってほしいし、それで顧客の成功を創りながら共に喜び、業界のNo.1を目指しにいけるってワクワクしますよね。ジーニーには確かな最先端のテクノロジーがあり、それを支えられる素晴らしい仲間が揃っています。一緒に戦ってくれる仲間は常に募集していますので、この記事を見て少しでもジーニーに興味を持ってくださったら嬉しいです。

11期上半期、「GENIEE DSP」は機械学習を活用した自動入札機能の正式提供を開始しました。企画から半年、驚異的なスピードでの機能リリースを成功させたエンジニア二人に、開発の裏話とチームでの取り組みを聞きました。

R&D本部　マネージャー代理　内木 正隆
「大規模なデータを使い様々な開発ができそう」と感じたことが、入社の決め手に。
R&D本部　リーダー　遠藤 悠平
「広告事業はデータ分析を実践的にできそうで面白そうだった」という思いでジーニーへ。

チームのミッションを教えてください。

遠藤 　担当プロダクトの指標、広告配信の指標であるCVとCPAを最適化することです。

自動入札開発チームは、上半期MVT（Most Valuable Team）を受賞しました。成果について、改めて説明をお願いします。

内木　機械学習の予測を用いて入札の価格づけを自動的に行う「自動入札機能」をジーニーとして初めて開発しました。今まで人手に頼っていた広告運用作業を部分的に自動化することで、工数削減と広告パフォーマンスの改善を実現できました。
遠藤　私達が入社する前から、DSPにこの機能を組み込むことはジーニーにとって悲願でした。しかしお客様にも納得していただけて、かつ運用チームの要望を実現するのは、技術的に難しいものでした。

かなりスピード感のある開発だったそうですが、なぜ短期間で成果を上げることができたのでしょうか。

内木　自動入札機能自体は企画から半年でリリースできたのですが、周辺の開発も含めると丸3年かかってようやくできたものなんです。第一弾としてCTR（クリック率）予測機能を開発し、その後プロトタイプであるCVR（コンバージョン率）予測機能をリリースしました。
遠藤　リリース後、もっとこういう機能があったらいいのではと二人で話し合い、他機能をいくつか追加した「自動入札」の企画を私が上げたのが4月です。
内木　PMとCTOが開発の大枠の方向性を決め、主に遠藤さんがアイディアの取りまとめや要件定義、スケジュール設定を行っています。
遠藤　チームは各々が専門的な知識を持っているので、企画についてミーティングやテキストで議論し、プロジェクトに関わるチームみんなで形を作っています。配信チームのメンバーには、非常に技術的に難しいところを実現してもらいました。私たちの作ったモデルが実際に機能するかどうかは配信にかかっています。1億、10億といったリクエストを捌けるような配信構成を取り、実装できたのは配信チームのおかげです。

プロジェクトが計画通り進まない時、どのようにして課題を解決し、進めていますか。

内木　プロダクト開発は積み重ねです。使えるものが一度でできることは滅多にありません。予測の精度は赤字に直結します。予測する範囲等のチューニングを繰り返し、チームを跨いだ話し合いと改善を何度も重ねました。計画通り進まないことの方がむしろ多いです。今回企画から半年、初回リリースでパフォーマンスを出せたことの方が驚きです。

数年来開発を積み重ね、一つひとつ技術を積み重ね、メンバーの皆さんが一体となって進めてきたことが、結実したのですね。

遠藤　そうですね。自チームだけでは解決しない課題も多いですし、他チームとのコミュニケーションがずれていてうまくいかない時もあります。実装に至るまでは多くの過程を経るので、周辺の知識や解決策を多く知り、積み上げていくことが成功につながると思います。それを乗り越えてうまくいった時は、やはり嬉しいですね。この時のためにやっていると言っても過言ではないです。

※役職・職務は取材時のものです