※ 本記事は、Dentsu Digital Advent Calendar  7日目の記事となります。 こんにちは、電通デジタルでバックエンド開発をしている関本です。普段は技術寄りの話題が多い当ブログですが、今回は『オンラインハッカソンの開催を検討、運営を担当する方々』に向けて、 を主題として弊社開発部内の取り組みの様子とその結果についてお話させていただきます。 まずはじめに、業務で忙殺されている方に向けて心得3箇条からお伝えしていきます。 【オンラインハッカソン開催の心得3箇条】 1. ハッカソン期間中は外界との交流を完全シャットアウトすべし！ 2. 運営の事前準備、お題策定には時間をかけるべし！ 3. 当日の「霊圧問題」に対処すべし！それではハッカソン開催に至った経緯、事前準備や当日の様子等の詳細について順を追って、お話していきます。少し長めの文章となりますが、お時間ある方は最後までお

電通デジタルでSREをしている神田です。 この記事は電通デジタルアドベントカレンダーの4日目の記事です。前回の記事は「Reactアプリケーション内でGoogle Analytics計測をする際、react-gaを使わず、gtag.jsを利用した方法とその選択理由」でした。 電通デジタルのいくつかの開発プロジェクトでは、データ処理のためのワークフローエンジンとしてAirflowが採用されています。 この記事では、Airflow 2.0で改善された機能の1つである、スケジューラーのHA(High Availability)対応について解説します。 Airflow 2.0で提供される機能について詳しく知りたい方はAirflow 2.0 Planningを参照してください。 そもそも、スケジューラーって何をしているの？スケジューラーは、DAGやタスクを監視し依存関係をもとに実行可能なTaskIns

電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。 電通デジタルアドベントカレンダー20202日目の記事になります。前回の記事は「Dentsu Digital Tech Advent Calendar 2020開始します！」でした。 本記事では2020年にSREチームで作ったDevOps内製ツールについてご紹介させていただきたいと思います。内部プロダクトのユーティリティーなど細々したものは色々あるのですが、今回は日常的に利用頻度の高い以下2つのツール ・Auth0をIdPにしたAWSマルチアカウントSSOのクレデンシャル取得ツール(auth02aws) ・オンデマンドでBastionホストを起動して使うツール(bastion-session.sh) を紹介させていただきます。 Auth0をIdPにしたAWSマルチアカウントSSOのクレデンシャル取

でご紹介したGo言語でのgRPCコード生成の状況の続報(2020年末)をお伝えしたいと思います。 概要としては前回の記事に記載した通りで ・Protocol Buffer側のレポジトリは golang/protobuf から protocolbuffers/protobuf-go に移行 ・gPRC側のレポジトリのgrpc/grpc-goに新たにprotoc-gen-go-grpcコマンドができた なのですが、以下が追加になりました。 ・gPRC用のコードを生成するには Protocol Buffersのメッセージやシリアライズに protocolbuffers/protobuf-go のprotoc-gen-go、gPRCのサーバ/クライアントに grpc/grpc-goのprotoc-gen-go-grpc、と両方を使うことになった 以降で詳細をご紹介します。 経緯2020年3月のpr

電通デジタルでバックエンド開発をしている平沼です。 私は、4/1(水) に電通デジタルに中途入社しました。初日のオリエンテーション以降、入社 2 日目から今までリモートワークをしてきた中で感じたことをお伝えします。私としては、このままリモートワークが続いてもよいと考えています。 入社までの話私は、前職までは SIer として仕事をしており、今までリモートワークをしたことはありませんでした。プロジェクトでは、Mattermost という Slack ライクなチャットツールを立ててやり取りをすることはありましたが、基本的にはメールや対面での打合せがほとんどを占めていました。 今回転職するにあたって、入社直前までフルリモートワークになるということは全く想像していませんでした。弊社は、働き方改革を推進しており、そのなかでリモートワークの導入を計画していたことから、新型コロナウィルスの影響下でも比較

プロダクト作りにおけるターンアラウンド（働きかけて、結果から学ぶ）を短くするためには「考える」と「つくる」を分断させてしまったり、その行き来に時間をかけてしまうことを避けたい。 しかも、時間だけの話ではなく、ターンアラウンドが長いほど、また情報の受け渡しをやっているほど、その過程に誤謬が入る可能性が高まる。理想は自身が理解した内容を解像度を落とさず、濁らせずに、実現することだ。 そのためには「考える」と「つくる」どちらかに偏ることなく、両方を受け持てるようでありたい。その状態のことを「両利き」と呼んでいる。 実際のところ両利きの内容、つまり右手と左手でそれぞれ何をつかめるようにするかは、求められる役割によって異なる。プロダクトマネージャーであれば「仮説検証」と「アジャイル開発」を挙げるが、そのほかの役割であれば、例えば「プロダクトバックログを作る」と「コードを書く」という両利きが考えられる

電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。 先日(8/5)に7/22開催のAWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料が公開されました。 資料中では以下の内容を説明しています。 ・AWSではアカウントに個別のIAMユーザを作成してログインする代わりに、IDプロバイダ(IdP)を使用し、シングルサインオンができること ・シングルサインオンは組織に独自のID基盤がある場合や、複数のAWSアカウントを使用している場合に有効であること ・シングルサインオンの実現の方法にはいくつかパターンがあり、運用をふまえながら何を選択するのがよいかであること 弊社の自社開発部署もAWSをマルチアカウント構成-シングルサインオンで運用しています。今回はその事例を上記資料の選定パターンチャート

この前の日経の記事でプリファードの西川CEOが「AIブームはもう終わる」と発言していたのが、とても象徴的なできごとだと感じた。AIブームが終わるというのは、誰もが分かっていて、話題にも良くなっていたが、AIに直接関わっている当事者としては、言い出しにくい雰囲気があった。

デザインツール Figma の基本的な使い方から、エンジニアと協力して開発に組み込む際の活用方法などをまとめています。

前回、プロダクトマネージャーのスキルの全体像とその中に含まれるTeam & Collaborationのうち、主に個人として持つべきスキルを紹介した。今回は、前回の記事で紹介したプロダクトの強い軸で「Cooperation」と説明している、チームを率い、社内外の関係者と協力関係を構築していく部分について解説しよう。これはプロダクトマネージャーの役割の1つとなる。筆者らは、プロダクトマネージャー向けの研修などを通じて、多くのプロダクトマネージャーの方々と対話をする機会があり、皆さんがこの「Cooperation」の部分で非常に苦労されていることを理解した。今回の記事が皆さんの日々の業務に少しでも参考になれば幸いだ。 前回記事 第7回「プロダクトマネージャーに必要な能力とは何か？ スキルセットの全体像を解説」 プロダクトチームのあり方とプロダクトマネージャーの役割 さて、この連載ではプロダクト

こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。 弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。 テレワーク環境で私たちのエンジニア部門で急務と感じた課題テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様

エンジニア版の採用ピッチ資料を記事として制作する「kiitok review」ですが、ここ1ヶ月で新たにAnyflow、Kanmu、メダップ、キャディ、Voicyの各社さまの開発チームのレビュー記事を制作しました。 （制作済みのレビュー記事の一覧はこちら） （エンジニアの採用やブランディングに関するお仕事相談はこちら） 毎回各社のCTOや技術責任者の方とお話をさせていただく中で、みえてきた「魅力的なエンジニア組織」の要素を9つにして言語化してみました。 1.ユーザーに喜ばれる開発に時間を使えているチームエンジニアなら、一度は経験があるユーザーに求められないものをつくってしまう徒労感。逆に、開発したプロダクトや機能をユーザーに喜んで使ってもらえた時の幸福感。 エンジニアとして苦労してつくった機能をより多くの人に喜んでもらえる環境があるチームは魅力的です。もちろん、そういったものをつくらないと

帰ってきた optional - Protocol Buffers v3.12 から Field presence が導入 電通デジタルでバックエンド開発をしている齋藤です。 今回は Protocol Buffers v3.12 のリリースで追加された Field presence 機能について調べたことをご紹介します。 前提：v3.12 以前の Protocol Buffers v3 における optional な値の扱いProtocol Buffers v3 (proto3) では v2 (proto2) にはあった optional ながなくなり、optional を扱うにはひと工夫必要でした。加えて、Message の Filed に値を入れなかった場合は、Fieldの型のディフォルト値が送られてきたとみなす仕様になっています(各型のディフォルト値はこちら)。 そのため、開発者は

電通デジタルで機械学習エンジニアをしている今井です。 本記事では、BigQueryでUplift Modeling分析を行うための方法について紹介します。 広告効果を上げるためには？ 広告効果とは、広告に接触した場合と接触していない場合とのその後のコンバージョン（CV）の差である、と言えます。 介入が無作為に割り当てられるランダム化比較試験（randomized controlled trial, RCT）において、広告効果は平均処置効果（average treatment effect, ATE）として推定できます。 詳しくは過去記事[1]にまとめています。 Uplift Modelingは「広告施策において、その効果を上げるためには誰を広告配信対象とするべきか」を推定するための方法です。 ユーザーの特徴量を 𝐱𝑖 とすると、Uplift Scoreは下記のように算出されます。 Up

はじめにTIG DXユニットの真野です。フューチャー技術ブログの運営の1人です。未来報を運営している岡田さんなどと一緒に、気持ちは草の根活動で外部発信に携わっています。 IT企業の技術ブログ運営は、ある一定の質をキープしながらも、投稿頻度を高め・それを継続することが求められ、周囲の期待値もあるので中々気を抜けない仕事だと思います。単発ならともかく、継続することは忍耐が必要なので特に大変です。運営していてこれはナレッジだなと感じたことをまとめていきます。 2020/09/08 続編を公開しました: フューチャー技術ブログで行っている連載企画が良いよって話 技術ブログの大変なところ≒記事ネタを探すところ熱心な寄稿者が複数いて、運営からの声掛け無しで記事が集まるのであれば非常に楽ですが、たいていの組織やチームはそうでないと思います。また、本業は記事を書くことではなく、自社プロダクトの開発やシステ

「プロダクトマネージャーに任命されたが何をする役割であるのか分からない」「これからどのような知識を学べば良いのか分からない」「PMをどう評価すればいいのか分からない」といった悩みを聞くことがある。これは、プロダクトマネージャーの役割が明確に定義されていないことにより生じる問題だ。また、悩みをよくよく聞いてみると、任されている仕事がプロダクトマネージャーとしての役割からは程遠く、名前だけのプロダクトマネージャーになっており、プロダクトの成功が心配になってしまうこともある。まだ認知度が高いとは言えない中、このようにプロダクトマネージャー像がぼやけてしまうことは、プロダクト力が重要となったグローバル市場での競争力を考えると、良いこととは言えない。第2回となる今回の記事では、改めてプロダクトマネージャーとは何かを解説しよう。 なぜ、プロダクトマネージャーの役割は曖昧であるのか プロダクトマネージャ

プロダクトを長期運用するには、必要な知識やスキルをいかにチーム内でとどめておくかという視点が必要になります。本稿では、はてなの「Mackerel」というプロダクトで培った経験をもとに、「スキルマップ」と「ソフトウェア式年遷宮」という2つのアプローチを紹介します。（編集部） プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが