リクルートを退職しました - 下町柚子黄昏記 by @yuzutas0
今まで長いことお世話になりました！ リクルートグループを退職しました！ これからもよろしくお願い致します！ Graduate from Recruit! pic.twitter.com/ZfNlLXS6OF— ゆずたそ (@yuzutas0) February 25, 2019 はじめに 自己紹介 ITmedia著者紹介欄から引用します。 リクルートテクノロジーズ プロダクトエンジニアリング部所属 途上国から限界集落まで各地放浪、ベンチャーキャピタルから投資を受けての起業や会社経営、リクルートグループ会社における複数の新規事業の立ち上げを経て、現職。 現在は急成長プロダクトを対象に、システムアーキテクチャの再構築やエンジニアチームの立ち上げ、立て直しに従事。 他エントリーやTwitterもご覧くださいませ。 誰に何を伝えたいか 私を知っている人たち、これまで私がお世話になった人たちに「懐か
新規事業の担当者に「差別化の罠」を伝えたい - 下町柚子黄昏記 by @yuzutas0
この記事はProduct Manager Advent Calendar 2018 - 25日目の記事です。 PMではなかったはずなのにズルズルとPM代行業をやることになって、新規事業の立ち上げで四苦八苦しながら綴ったポエムになります。 お願い 何歩も前を進んでいる先輩方からすると、この記事の言い分はアンチパターンなのかもしれません。 読んでいて「こいつはまだまだ青いな」と思ったら、ぜひツッコミをください！ 背景 2018年には社内外でいくつかの新規事業に関わりました。 そこで多くのエンジニアが「xxxと同じものを作るだけではないか」と不満を持っているのを見ました。 中にはプロダクトマネージャー自身が「差別化の罠」に陥っているところもありました。 差別化の罠 「差別化の罠」と私が呼ぶのは、その名の通り「差別化にこだわったせいでかえって企画が失敗する」というアンチパターンのことです。 「この
データ基盤の3分類と進化的データモデリング - 下町柚子黄昏記 by @yuzutas0
この記事は、下書き供養 Advent Calendar 2018 - Adventarの2日目の記事です。 めっちゃ専門的な内容になってしまいました。ごめんなさい。 某Slackでの議論内容をブログに書こうとしたのですが、下書きのまま放置していました。 Wednesday, August 15th と書いてあるので、約半年前の内容となります。 もくじ もくじ はじめに 「データ基盤の3分類」と「（一般的な）技術要素」 1.データレイク（Data Lake） 2.データウェアハウス（Data Warehouse） 3.データマート（Data Mart） 私が考えるデータ基盤の定義 私が考える「あるべき構成」 技術要素を分けるのはアンチパターン 進化的データモデリングを容易にしよう チームとアーキテクチャを選ぶ まとめ 参考 余談 追記 はじめに データ基盤と世間一般で言われるシステムには分類
データ基盤を改善するアルバイトを募集中です - 下町柚子黄昏記 by @yuzutas0
データ基盤を改善するSREのアルバイトを募集中です。 春休みにひと稼ぎしたい・腕試しをしたい学生さんなど、お知り合いにいましたらぜひご紹介頂けると有難いです。 <仕事の魅力> こちらのエントリーをご参照ください！ yuzutas0.hatenablog.com <募集概要> 【想定対象】 データ基盤に興味のある学生エンジニア 【テーマ】 課題発見・解決型（SRE） 【仕事の流れ】 データ基盤チームの抱えるシステム課題（Problemチケット）から挑戦したいものを1つ選ぶ（もしくは起案する） 関係者ヒアリングや技術調査を行い、改善案・設計の叩き台を作る ホワイトボードで設計ディスカッション → TODOを洗い出す TODOを捌いてProblemを解決する 成果をまとめて社内勉強会でプレゼンテーションする（可能であれば外部登壇などもご相談） 【技術環境】 開発言語: Python, Node.
データ基盤エンジニアの面白さ - 下町柚子黄昏記 by @yuzutas0
データ基盤エンジニアという仕事の魅力について、質問を受ける機会がありました。 何が魅力なのか。どういう面白さがあるのか。どこにモチベーションがあるのか。 せっかくなので自分なりに考えをまとめてみます。 5つの面白さ ざっくりまとめると、データ基盤エンジニア（あるいは：分析基盤エンジニア・データエンジニア）というのは、「主体的に働きやすく」「スキルを(伸ばし/広げ)やすく」「キャリアアップに繋げやすい」仕事だと思います。 1. データ活用担当への第一歩として データ分析や機械学習を仕事としてやりたい。だけど、職務経歴としてはアプリケーション開発やインフラに強みがある。 この立場の人がキャリアをピボットするための踊り場として、データ基盤の担当になることがあります。 持ち前のスキルを活かしてデータ基盤の構築・運用に関わるところから始めます。 データ仕様に詳しくなっていき、徐々に活用側へと染み出し
勝ち癖をつける - 下町柚子黄昏記 by @yuzutas0
ポエム第三弾。 「何をするか」よりも「誰とするか」 企画や仕事に取り組むとき、何をするかということ以上に大切なのは、誰と一緒にするかだと思っています。 『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』ではGoogleのチームが円滑に回るには謙虚・尊敬・信頼（HRT）が必要だと述べている 『Yコンビネーター シリコンバレー最強のスタートアップ養成スクール』ではYコンビネーターが案件内容ではなくチームを見て投資先を選定することがあると述べている ではどのような人とコラボレーションしたいか。 1人1人、性格や得意なことは違うので、一概にこうだと言うのは難しいものです。 それでもあえて私自身の考えを挙げるとするならば「勝ち癖がある人」と一緒にいたいです。 勝ち癖がある 言い方は色々あります。勝ち癖がある。成功体質である。勝ち方を知っている。 要するにPDSサイクルを回
データの民主化とサービスレベルについて話しました＠分析基盤Meetup #shinjukugl - 下町柚子黄昏記 by @yuzutas0
セプテーニ・オリジナル様が主催する新宿Geek Lounge#4 分析基盤MeetupでLTをしました。 スライド 『データ基盤を支える民主化とサービスレベル』 「いかにビジネス価値を最大化し続けるか」という本来の目的から、データ基盤1を見直すキッカケになればと思います。 PyCon JP 2017でベストトークアワード優秀賞を受賞した発表（構築編）の続き（運用編）をチラ見せです。 データ基盤は使われてこそ意味がある 世の流れは「やってみた」から「価値創出・運用」志向に推移しています（例：DataOps、機械学習工学、MLOps） 「俺の考えた最強のダッシュボード」では1週間で誰も見なくなります データの民主化 事務スタッフ（非エンジニア）がBigQueryを叩いています！すごい浸透！ チームごとの民主化状況をモニタリングして必要なアクションを実施しています 民主化には3つの壁があることが
学生インターンを受け入れました - 下町柚子黄昏記 by @yuzutas0
以下ブログ記事に対するアンサーエントリーです。 リクルートのインターンに参加しました | monolog ※本稿は個人の見解であり、所属する組織を代表するものではありません。 うちのチームで先月までインターンをしていた @sukukyon から献本が届いたw pic.twitter.com/80XqVaz9Em— ゆずたそ (@yuzutas0) 2018年4月4日 短い期間ではありましたが、インターン生である@sukukyonのメンターを務めました。 あまりメンターらしいことは出来なかった気もしますが、何とか無事に修了しました。 総論：最高のインターンだった 最高のインターンで最高にやっていきを発揮して最高の成果を出しました。 ということで、概ね上手くいきました。 成功要因としては「関係者全員がお互いをリスペクトできたから」だと思っています。 非常に良い関係性を築けていました。 まず何よ
サービスレベル：設計と運用のプラクティス - 下町柚子黄昏記 by @yuzutas0
概要 サービスレベルをいかに設計し、いかに運用するか。自分なりの考えの整理です。 尋常ではない長さになりました。随時アップデートします。たぶん。 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) 作者: John Allspaw,Jesse Robbins,角征典出版社/メーカー: オライリージャパン発売日: 2011/05/14メディア: 大型本購入: 10人 クリック: 923回この商品を含むブログ (50件) を見る もくじ 概要 もくじ SLAとは何か 関係者が同じ目線を持つためのもの 火の一ヶ月間を経て…… SLAは契約ではなく、目標の合意に過ぎない SLA：設計のプラクティス サービスのレベルを設計する 機能観点でのレベル分け コア機能を定義する 非機能観点でのレベル分け オペレーションのレベルを設計する 対応速度のレベル分け 3
プロダクトオーナーに入門する - 下町柚子黄昏記 by @yuzutas0
この記事はRecruit Engineers Advent Calendar 2017の5日目の記事です。 4日目はy_kabutoya先輩の環境依存情報をコードから分離するというエントリーでした。 本エントリーは「プロダクトオーナーとは何ぞや」という話の整理になります。 認定プロダクトオーナー研修の内容をもとに、社内有志でディスカッションした内容に基づいております。 前提 スクラムとPO ROI(投資対効果) ManageとControll InvestmentのコントロールによるROI最大化 チーム スプリントセレモニーでのROI最大化 プロダクトバックログでのROI最大化 プロダクトバックログ PBI→PBL→プロダクト→Return PBI PBL ACとDD リリース戦略でのROI最大化 QCDSの関係性 リリースの方程式 見えにくいUndone（ムダ・ムラ・ムリ）を排除する ス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
