[2020.12.8 追記] ブコメでEMが何かわからないと書かれていたので補足。EM = Engineering Managerです。EM菌ではありません！！！ [追記ここまで] 今の会社でお世話になったEMの人たちのマネジメントがとてもよかったので育休で全てを忘れる前にメモを残す。EMの話題はよく見かけるけれど、マネジメントされる側の視点で語られることがあまりなかった気がするのでいい記録になるかもしれない。 前提 自分: メンバー（マネジメントされる側）。Androidエンジニア。ある程度放置されても自走できる。 EM: 一人ではなく複数。（歴代という意味。同時に複数人のEMにマネジメントされたという意味ではない。）彼らはみなAndroidエンジニアではないがモバイルもしくはフロントエンドのエンジニア。なので技術の相談はしないが、開発業務そのものについてはとても詳しい。 組織: エンジ

こんにちは。Treasure Dataサポートエンジニアの佐藤です。 タイトル通りですが、mixiさん主催のCustomer Support Tech Meetupというイベントに参加してきました。 mixi.connpass.com このイベントは「CREがどのようにしてCS課題を解決しているのか？」というところにフォーカスして最新情報をシェアする目的で開催されているイベントのようです。素晴らしいイベントですね！ ちなみに私はCREではないのですが、今回CREにやや近しいプロジェクトに関わる機会があったので今回発表させていただきました。 イベントのライブ動画のアーカイブはこちらになります。 https://www.youtube.com/watch?v=T78ArR9LUCc&feature=youtu.be&t=2310&ab_channel=mixiTechTalk 発表内容について

オペレーション部　江口です。 去る8月27日、ミクシィさん主催のMeetup 「Customer Support Tech Meetup」がオンライン開催されました。 最近当社オペ部メンバーでは「CRE」（Customer Reliability Engineering）に興味を持っています。このイベントではミクシィさんのCREへの取り組みのお話も聞けるとあって、オペ部有志でSlackでリアルタイムに実況しながら視聴させていただきました。というわけで折角なのでその模様をブログでレポートしたいと思います。 ※1つ1つセッションの感想など書いていたら結構なボリュームになってしまったので、前半と後半の2回に分けて投稿します。 Customer Support Tech Meetupとは 以下、Conpassのイベントページ（下記参照）からの引用となります。 カスタマーサポート（CS）の現場には、

先日ミクシィ主催で「Customer Support Tech Meetup #2」を開催しました。 mixi.connpass.com 僕は「問い合わせ対応のデータを宝の山にするために」というタイトルで#1に引き続き発表しました。 発表内容について データを活用して何かをするにあたり、まずは正しいデータを収集しなければデータを活用することはできません。 大量のデータがあるから分析したいという時に泥臭いデータクレンジングから始まると思いますがデータの質のよっては全て再収集する必要があります。 今回はデータの質の問題でデータ活用ができなかった事例を通して、質の悪いデータが生まれるいくつかのパターンについて紹介しました。 紹介した事例は以前ブログで紹介されている事例だったのですが、少し掘り下げて詳しく話をしました。 medium.com 発表の裏話: なぜこのトピックで発表したのか 今回このト

10代から知っておきたい あなたを閉じこめる 「ずるい言葉」という本を読みました。 www.wave-publishers.co.jp 「もっともらしいことを言われているようだけど」 「自分のことを考えて言ってくれているようだけど」 何だかモヤっとする。 そんな経験ないでしょうか？ この本では、そういった納得のいかないモヤモヤする言葉を「ずるい言葉」と名づけています。 そして、その「ずるい言葉」を見抜いて対処していく考え方が書かれています。 「ずるい言葉」に惑わされないために、どのような言葉が「ずるい言葉」なのか見ていきましょう。 この本では「ずるい言葉」を以下の8つのカテゴリに分けて説明しています。 第1章　“上から目線”がカクレた言葉 あなたのためを思って言っているんだよ / そんな言い方じゃ聞き入れてもらえないよ どちらにも問題あるんじゃないの? / はっきり言わないあなたが悪い 言

mixi.connpass.com はじめての外部発表でドキドキでした。 ご参加くださった皆様ありがとうございました！ speakerdeck.com 今回は具体的なチートや実装の話はせず、 チート対策のサポートをCREがどういう理念のもとで行っているかを、 過去の事例や将来やりたいことを織り交ぜつつお話させていただきました。 事前収録形式について 今回は事前に収録したものを流す形式でした。*1 私は発表に不慣れで原稿ベタ読みマンだったので、 当日Twitterで反応見るのに集中できてて個人的には良かったです。 玄人発表者の方であれば発表中にTwitterで質問拾いつつ話せるのかもしれません。 私には経験値が足りませんでした😇 当日頂いた質問・感想 当日もなかなか拾いきれない質問・反応があったので、 ブログでも軽くコメントさせていただきます。 「健全化」っていう響きはいいよなあと思う。B

2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ

English version 要約 dockerはデフォルトでセキュリティ機構（Spectre脆弱性の対策）を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります（実行時間が倍くらいになることがあります）。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合： $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker

はじめに この記事は、エンジニアがどのように技術を学べば良いのかということについて、おもに西尾泰和氏の書籍・記事で主張されている内容を元に、特定の問題を対象として自分の考えを加えて考察したものです。特定の問題としては、以下の3つを設定しています。 何を学べば良いのか分からない 技術書を読んでもすぐ忘れる 学習する時間がない もちろん、学ぶ上で考えるべきことは上記の問題にとどまりませんが、ここでは、比較的身近で耳にすることが多いと感じるものを問題として設定します。 定義 この記事ではスコープを特定の範囲に限定しているため、一般的な用語について、一部を以下のようにローカル定義しています。そのため、一般的な用語そのままの意味においては、この記事の内容はコンテキストを維持できないことがある点に注意してください。 エンジニア Web 系企業に勤めており、主にプログラミングをはじめとしたコンピュータサ

社内slackでGoについて質問されて、それなりに長文で回答したのでその内容を加筆修正したものをブログに残しておく。 質問内容としては以下のイメージ。 RubyだとRailsがあり、MVCを利用することになるが、Goだとそこらへんはどうなるのか? Go初心者なのでGoのモダンなアーキテクチャとフレームワークについて教えて欲しい。 これ系の質問はGo経験者であれば「あーこれなー」と思うだろーし、 Go初心者のときに一度は悩んだことがあるだろう。 なので、個人的な意見を残しておく。 自分の意見が正しいかどうかは自己判断して欲しい。 結論 アプリケーションアーキテクチャの複雑化とMVCフレームワーク システムアーキテクチャの複雑化とフルスタックなフレームワーク マイクロフレームワーク 改めて質問内容を振り返る pospomeが考えるGoのフレームワーク選定 pospomeが考えるGoのアーキテク

ストレングス・ファインダーをやってみました。 ストレングス・ファインダーの結果はチームで共有するとより活用できそうだと考えたので、それについて書きます。 ストレングス・ファインダーについての詳細はこちら。 現在はクリフトンストレングスという名称のようです。 結果 まずは結果を記載します。 資質 1. 最上志向 2. 慎重さ 3. アレンジ 4. 共感性 5. 適応性 領域 実行力: 物事を成し遂げるのに役立つ資質 影響力: 主導権を握り、はっきりと意見を表明し、確実に他の人の耳を傾けさせるのに役立つ資質 人間関係構築力: チームを団結させる強力な人間関係を構築するのに役立つ資質 戦略的思考力: 情報を取り入れ、分析し、より適切な判断を下すのに役立つ資質 結果をチームで共有しよう 私のチームでは、新しいメンバーが増えた時などのタイミングで「スタンス共有」をしています。 スタンス共有では、チー

約一年前、上司に「誰もやる人がいないならやります。」と返事をして、意識が低ーい状態から私のリーダーとしての仕事がスタートしました。 当時は人への関心が薄く、マネジメントにも興味がありませんでした。 ただ、自分のエンジニアとしてのスキルには不安があり、エンジニアリング以外のスキルも身につけないとなという漠然とした考えはありました。 やってみて自分には向いてないなと思えばやめようと考えていましたし、今でもそう考えています。 これまでやってみて「あー向いてないかもな…」と思うことはあっても、「どう考えても向いてないな」と思うことはまだないので続けています。 リーダーをやってみて1年(とちょっと)という区切りで、自分がどう変わっているのかを確認するという目的でふり返ってみます。 チームはいきもの チームには多様な価値観を持つメンバーが集まっていて、1人1人日によって状態が違うこともあれば、時間が経

2019/08/20 〜 2019/08/22の3日間、ドイツのケルンメッセで開催されるGamescomに参加してきました。 記憶が薄れないうちにレポートを書いておきたいと思います。 Gamescomとは？ 東京ゲームショウ、E3(Electronic Entertainment Expo)と並ぶ世界3大ゲームショウのひとつ 欧州最大級のゲームショウ、ゲームの見本市 各エリアのレポート マップ マップを見ていただけるとわかるように、とにかく広い！ 会場は1〜11までのエリアに分かれていて、複数のホールにまたがるエリアもあります。 今回は8/20 〜 22のトレードビジターチケットで参加しました。 8/20はメディアとトレードビジターのみ、8/21 〜 8/24がプライベートビジターも含めた全員に開放されます。 8/21以降はかなりの混雑となることを予想して、8/20に全てのエリアをざっと周

頼まれたことをすっかり忘れていた。 うっかり見落としていた。 わかったつもりが勘違いだった。 どうしてあんな判断をしたんだろう… 仕事でこんなミスなんてしたことはない、という人はまずいないだろう。 ミスをしたいと思っている人なんていないはずなのに、なぜか起きてしまうミス。 何となく「ミスは気をつけていれば防げるはずだ」なんて簡単なことではないな、というのはわかる。 ミス【miss】 [名] (スル)誤ること。まちがえること。失敗。ミステーク。「捕球をーする」「計算ー」 大辞泉 なるほど…しかし、ミスを防ぐ方法はわからない。 いい本はないものかと本屋をブラブラしていたら、都合よく「図解 仕事のミスが絶対なくなる頭の使い方」という本を見つけた。 これだ。 この本は「仕事のミスが絶対なくなる頭の使い方」に図解を加えてさらにシンプルにまとめたものだ。 1つの項目につき見開き2ページで左側が文章、右

みなさんのチームにはチームの方針はありますか？ チームのメンバーが理解して実践できるように共有されていますか？ 私たちのチームでは、新しい期が始まり少し経ってマネージャーから今期のチーム方針について共有がありました。 私はチームのリーダーになってからは、目標の1つとしてチームマネジメントを設定しています。 リーダーになって最初の半年は、1on1などを通して主に自分とメンバーとの信頼関係の構築に取り組みました。 次の半年、今期は1対1の関係から範囲を広げチーム作りに取り組みたいと思い、チームを作るとはどういうことなのかをあらためて考えてみました。 「THE CULTURE CODE 最強チームを作る方法」という本と「『一緒にいたい』と思われるリーダーになる。」という絵本を参考に引用しながら、チーム作りに必要なこと・リーダーとしてチーム作りにどう貢献していくかを書きたいと思います。 期初からも

こんにちは、初めまして。CREグループの神です。今はエンジニアチームでリーダーをやっています。 去年から少しずつチームマネジメントの役割を担うようになり、9月頃からチームメンバーとの1on1をするようになりました。 いざ自分がホストとして1on1をすることになると、「1on1って何のためにするの？どうすればいいの？」と考え過ぎて夢に出てくるくらい1on1について考えていました。 本を読んだり、人に聞いたり、記事を読んだり、半年ほど試行錯誤しながら1on1をしてみて、少しは知見を得られた気がするのでまとめてみたいと思います。 Photo by rawpixel on Unsplash何を目的に1on1をするのか1on1を始めるにあたって「何を目的に1on1をするのか」ということをゲスト・ホスト共通の認識として持っているとお互い有意義な1on1になるのではないかと考え、目的を定めることにしまし

inouetakuya.info 2023 著作権. 不許複製 プライバシーポリシー