この記事は、データ活用 Advent Calendar 2018 - 13日目の記事です。 最初に結論 ステークホルダーからフィードバックを得ると、様々な因子を洗い出すことができる。 結果として、より筋の良い仮説を立てることができ、データ分析の確度が上がる。 それゆえに社内政治は、データ分析の精度向上の有益な手段となるのではないか！ もくじ 最初に結論 もくじ 注意点 前提 データ分析とは 社内政治とは 足を使わないデータ分析のあり方 足を使うデータ分析のあり方 分析には仮説と検証が必要 合意を得るくらい情報収集をする 意外な因子を洗い出す まとめ（再掲） だから？ 注意点 ポエムです。データ分析関連の飲みの場で盛り上がったネタなので投下します。 ステークホルダーは最低限の論理的な会話が成り立つ人物であることを前提としています。想像を絶するほど言葉が通じない人間や組織は現実に存在するので、

この記事は、クローラー／Webスクレイピング＆RPA Advent Calendar 2018 Advent Calendar 2018 - Qiitaの6日目の記事です。 何を作ったか リポジトリはyuzutas0/sel2pupとなります。 SeleniumIDEをPuppeteerに変換するスクリプトを作りました。まだプロトタイプですが。ブラウザ操作の記録・自動実行を補助するツールです。データ収集RPAを継続的に保守するに当たって、マーケターなど非エンジニアが作業の一部を担えることを目指しています。https://t.co/rsh9ma7gL5— ゆずたそ (@yuzutas0) August 29, 2018 SeleniumIDEというツールを使うと、ブラウザ操作を記録して .side ファイルを出力します。 そのままでは記録しただけです。実行はできません。 そこで、記録ファイル

これは Supership株式会社 Advent Calendar 2018の25日目の記事です。 Supership株式会社 CTO @yamaz です。 広告システムエンジニアは絶対におもしろいと思う理由 という記事をちょうど10年前に書きました。 今回はあれから10年経って現在広告システムエンジニアをとりまく環境ははどうなっているかについて書きたいと思います。 TL;DR (３行で) 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域だよ。 広告テクノロジーをプレイヤーが切磋琢磨し続けてきた結果、大規模配信・集計技術もさることながら大規模データ分析や運用技術の領域も大事になってきたよ。 まだまだ課題満載な業界だけど、デジタルマーケティングに未来を感じてる人はぜひ広告業界へ応募を！ 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域である 10年前は

毎年恒例、Pythonの本と学び方のまとめ・2019年バージョンとなります. ※2021/1/11更新：2021年版あります ※2020/1/9更新：2020年版もあります, こちらもよろしくおねがいします！ ※ちなみに昨年版はこちら 改めましてこんにちは、Pythonと野球を仕事にしています、@shinyorke（Python歴おおよそ8年）ともうします. なお、Python その2 Advent Calendar 2018 12/24記事でもあります. このエントリーはそこそこ長いので、「最初の方をサクッと読んで、残りはつまみ読み」してもらえると良いかもです！*1 ※もちろん全部読んでも構いません！（それはそれで嬉しい） サクッとまとめると 入り口としての「独学プログラマー」は万人が読んだほうが良い名著 データ分析・解析やりたい人も、Webからやっておくと良いかも（特に前処理） Web

この記事はGoogle Cloud Platform その１ Advent Calendar 2018 - 18日目の記事です。 以前こういうブコメをしたのですが、言いっ放しだとダサいので、具体的なやり方を書きます。 "アカウントごと/日付ごとのBigQueryコストを可視化できるダッシュボード" なら Stackdriver + BQ + Datastudio を使うと作業時間10分・ほぼ無料で作れるので、うちはそのやり方を採用していますね。… https://t.co/9yoni22iw7— ゆずたそ (@yuzutas0) August 17, 2018 もくじ もくじ はじめに この記事のゴール 解決したい課題 課題の背景 実行方針 完成イメージ 作業手順 1: BQクエリ実行ログを流す 2: DataStudioでダッシュボードに表示する 応用編 1: 全体コストを可視化する 2

この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2018 の投稿記事です。 こんにちは。mactkgです。 みなさん毎日様々なツールを組み合わせて仕事されていると思いますが、Slackなどのチャットツールはもちろん、文章共有ツールも無くてはならないものですよね？　私はScrapboxというWikiを入社前から数年間使い続けています。とても便利で気に入ってることから社内でも使いたいとお願いしたところ、あっさり導入してみることになりました。今でも弊社リクルートマーケティングパートナーズの内製開発組織で活用されています。 はじめのうちは、興味がある一部の人や私と業務上関係のある人のみが使っているだけでした。しかし、ここ最近はそれ以上に様々な人に使われている様子が観測できており、この機会にScrapboxが社内でどのように活用されているのかをまとめ

この記事は、真・エンジニアの登壇を応援する会 Advent Calendar 2018 - 14日目の記事です。 カンファレンス登壇を通した学んだことをまとめます。 サマリー アウトプットこそが最も効率的なインプットだ！ とにかく場数を踏んでいこう！ 最初にゴール設定→早い段階で方向性をレビュー→エレベータピッチから始めるアウトライン作成→王道に即したスライド作成→人を巻き込んでリハーサル→当日は心から楽しむ！ 実績 以下2つが代表実績となります。 どちらも国内有数規模のカンファレンスですので、私の言い分に関心を持ってくださる方はいるのではないか、と期待しています。 登壇内容はエンタープライズ寄りですが、このエントリーの内容はギークな方々にも通じるはずです。 ① PyCon JP 2017 ベストトークアワード優秀賞 ② Developer's Summit 2018 Summer アンケ

この記事はRecruit Engineers Advent Calendar 2018 - 13日目の記事です。 追記 本記事の内容にて、s-dev taksで登壇してきました speakerdeck.com 前書き 本記事は個人的な見解を示したものであり、所属する組織を代表するものではありません。内容には留意しておりますが、もし不適切な内容や誤りがあれば、私個人当てにご指摘のコメントをいただけますと幸いです。 超概要 カットオーバーから数年経ったtoCサービスにおいて、エンジニアオンリーのチームで企画・開発・分析、プロダクト改善のサイクル全てを担うチームの立ち上げを行いました 開発しか知らない僕らがよりよい価値を世に届けるために、企画や分析方面への染み出しを行う中での泥臭い取り組みや、やってみて分かった知見を共有します 経験ベースで築いてきた知見なので、理論を踏まえてなかったり、原理原則

はじめに きっかけ 執筆計画を立てる 1. 分析に興味がある人のペルソナを書く 2. 1が検索するであろうクェリの一覧をつくる 3. 検索ボリュームしらべる 4. カテゴリ分け 5. 作るべき記事のリスト（記事タイトルまでだいたいきめちゃう）をつくる 6. 記事を書く担当者とスケジュール引く おまけ おわりに はじめに こんにちは。グノシー事業部の大曽根です。好きな曲はザ・ディランⅡの「男らしいってわかるかい」です。 この記事はGunosy Advent Calendar 2018の12日目の記事です。 昨日はhongmhoonさんのiOSでNotificationを非同期で送ろうでした。 最近、プライベートや採用面談などで「会社で技術ブログなどを書きたいけど始められない (or 始めたけど続かない)」という相談を受けるので、弊ブログが如何にして立ち上がったかをまとめたいと思います。 ※本

この記事は、SRE 2 Advent Calendar 2018 - Qiitaの4日目の記事です。 主張 データ基盤の移管プロジェクトをやるときは、データサイエンティストではなくSRE人材が推進すべきだと思っています。 この記事の概要 SRE人材が介在しないまま、システム全体の運用・保守観点を踏まえずに、データ基盤の移管を進めるとどうなるか。 「データ基盤をHadoopからBigQueryに移管する」というプロジェクトで、とある現場が実際に踏んだアンチパターンをご紹介します。 語句の説明 「データレイク」（元データのコピー）と「データウェアハウス」（加工済みデータ）の概念を分けて考えます。 詳しくは以下のエントリーを参照ください。 yuzutas0.hatenablog.com 元の構成 いわゆるレガシーな20年モノのWebシステムで、DBはOracleを使っています。 バッチ処理でOr

今の会社に転職してきて驚いたのは、仕事の細々した部分がアナログで回っていたところだ。 「細々した部分」というのは、例えば伝言メモとか、社内・部署内回覧文書とか、そういう類のもの。有給を取った次の日に出社すると、デスクの上には沢山の付箋と紙が置いてある、という感じ。そして、データの受け渡しに実物のUSBメモリが行き来する。ゲーッ！今はもう平成も終わる2018年だぞ！！ また、「△△さん、株式会社〇〇のＡさんへ電話を入れてください」といった伝言を伝えるのに、該当部署に内線をかけるも不在、その折り返しをください、そしたら今度はこっちが離席・・・　といった無様なキャッチボールも頻繁に発生する環境。 自分の部署全員で共有する仕事も、「みなさんちょっと聞いてくださ～い」みたいに呼びかけて、資料を配って、説明して、そしたら途中で電話が入って説明が中断して、といった具合。非常に効率が悪い、というか、やって

この記事は eureka Advent Calendar 2018 11日目の記事です。 どうも、みなさん、おはこんばんにちは。 エウレカBIチームで、データ基盤をコソコソ作っているsotaroです。 今年一番みて良かったアニメは『ヴァイオレット・エヴァーガーデン』と『ゆるキャン△』です。一番といったのに二つ選んですみません。キャンプしたいです。 私は、主にPairsのデータを分析したり、分析するためのデータを作ったり整えたりするお仕事をしています。 特に最近では、Pairsのデータ基盤を刷新するプロジェクトに注力しており、今日はそのプロジェクトの中で最近導入&試験運用を始めたGCPのマネージドAirflow、Cloud Composerについてご紹介します。 なぜCloud Composerを使うことにしたのか？本題に入る前に、まずは「なぜ？何を？」などの外堀を埋めていきたいと思います。

この記事はRecruit Engineers Advent Calendar 2018 - 8日目の記事です。 注意点 タイトルは煽りです。「新規事業におけるデータエンジニアリングの勘所」の方が正しいかもです。 クオリティというか記事の信頼度は、投稿時間がギリギリになってしまったことから察してもらえるとありがたいです。 本エントリーの内容は個人的な見解であり、所属する組織を代表するものではありません。データの取り扱いは非常にセンシティブなトピックでもあるため気軽に発信すべきではないということは重々承知しております。もし誤りや考慮不足だと感じる点があれば、それは全て私個人の力不足によるものですので、どうぞ私個人当てにご指摘のコメントをいただけると幸いです。 もくじ 注意点 もくじ 背景 前提 体制 システム 開発スコープ 機械学習WebAPIは分離 データ基盤設計 全体の設計ポリシー データ

この記事は 海外 Advent Calendar 2018 - 7日目 の記事です。 マッチングサイトの海外カンファレンス「iDate2018」に参加しました。 http://mobiledatingsummit.com/agenda-miami-2018.php 世界的に伸びているマーケットなので非常に興味深かったです。 事業プレイヤーが何を考え、何を行い、その背景にはどういう力学が働いているのか。 セッション聴講やディスカッションを通して考察することができました。 もくじ もくじ 注意点 カンファレンス概要 国際市場について オフラインのプレイヤーについて オンラインのプレイヤーについて オンライン > 機能面 オンライン > UX面 オンライン > データ分析面 オンライン > 経営面 オンライン > 長期トレンド サービス提供者が感じている悩み 技術的投資 Safety担保と機械学

※ この記事はすべて無料でお読みいただけます。投げ銭歓迎。 ※ またこの記事は「技術同人誌 Advent Calendar 2018」の4日目です。 ※ 12/4 22:34 追記・微修正 以下、技術同人誌を書きたい方・既に書いている方に向けて書いていきます。（Markdown一般の話に比べると、やや高度なことを説明しようとしています。あらかじめご了承ください） ---------------- 技術同人誌という存在を知り、自分でも書きたくなったITエンジニア（特にWeb系）にとって、 「技術同人誌を書くなら、Markdownで書きたい！」 という魂の叫びは当然のことでしょう。 Markdownを使ってブログを書き、簡単な図ならmermeidやPlantUMLで直書きし、プレゼン資料まで作ってしまうMarkdownフリークであれば、「技術同人誌ぐらい、Markdownで書けるはずだ！」とい

この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。 某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。 もくじ もくじ はじめに 「データ基盤の3分類」と「（一般的な）技術要素」 1.データレイク（Data Lake） 2.データウェアハウス（Data Warehouse） 3.データマート（Data Mart） 私が考えるデータ基盤の定義 私が考える「あるべき構成」 技術要素を分けるのはアンチパターン 進化的データモデリングを容易にしよう チームとアーキテクチャを選ぶ まとめ 参考 余談 追記 はじめに データ基盤と世間一般で言われるシステムには分類

かとうです。好きなスポーツは野球で、Gunosy野球部でのポジションはベンチです。 こちらの記事はGunosy Advent Calendar 2018の1日目の記事です。今年も去年同様完走したいなーと思っております。 さて、アドベントカレンダー1発目でいきなりポエムめいた話になってしまい恐縮ですが、エンジニア組織っぽい話をしていきます。 2018年9月よりGunosyでは新たな体制変更を行いまして、現在VP of Engineering（以下VPoE*1）というポジションを担当しております。 新たな組織に向けての背景や意気込みなどは、お時間あればこちらの記事もぜひ読んでいただきたいと思います。 gunosiru.gunosy.co.jp 今回は実際に新しい体制になって3ヶ月経ち、VPoE・新体制としてどういったことに取り組んでいったかについてご紹介していきたいと思います。 ところで最近話

そろそろだな

どうして新卒でリクルートという会社を選んだのか理由を語り始めたら、そもそもなぜweb業界に進んでエンジニアになったのかから書き始めてしまい、会社とはあまり関係無く、個人的な要素が強い内容だったので別記事に分けました。よろしければご覧ください。 僕がwebエンジニアとして、会社を選んでいた基準は最終的に以下のような内容でした。 1. 入社同期が多く、他にも良い仲間に出会うことができる確率が高い 2. 会社自体が大きくブランドが強い、ヒト・モノ・カネ・情報と言ったリソースが十分にある 3. 年齢に関係なく、努力や実力次第で `1.` に裁量権を持つ文化がある 要するに、名のある大企業だけどベンチャーのような風土のある会社といったところでしょうか。これを満たしていれば、あとは環境要因よりも己の努力要因が大きいと思っていました。なので条件を満たすと思っていたリクルートが受かった時点で特に他の会社を

運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて「モチベーションが続かない」「いつの間にか辛くなってくる」という個人開発あるあるについて話していました。 個人開発は「自分の作りたいもの」を「自分の使いたい技術」で「自分の好き」に作れる最高の舞台です。クリエイターならやらない手はないでしょう。 しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。 仕事でもなく「自分が作りたくて作っていた」はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで「え、なにこのクソコード」と毒づいてしまうほど荒れ果てたmas