💁‍♂️ 5 7 5 完全リモートワーク、始まる 完全リモートワークに移行して2週間が経ちました。 私のチームはエンジニア5名という小さめのチームですが、割とうまく移行できている気がするので、振り返りを兼ねて取り組んだことなど書いてみたいと思います。 リモートワークは2週目以降が本番 リモートワークが始まって最初の1週間が終わり、2週目に入るとメンタルに変化が表れてくる気がしています。 最初の1週間は出社しなくていいという環境の変化に感動してハイになっていたのが、コミュニケーション量・質の低下によるストレスと、いつ終わるか知れない閉塞感にげんなりする感じでしょうか。 なので、リモートワークのポイントを最初の1週間と2週目以降で分けて書いてみます。 最初の1週間はとにかく環境を整える リモートワークが始まってすぐ気が付くのは、オフィスと自宅の環境の違いです。 例えば、椅子が悪くて腰が痛くな

3月25日(水)に、技術を駆使してカスタマーサポートの課題解決事例を紹介する「Customer Support Tech Meetup #1」を開催しました。 mixi.connpass.com オンライン開催にもかかわらず、当日はYouTubeの視聴者数が70人を超え、多くの人のCS課題への関心の高さが感じられました。 このエントリでは、Customer Support Tech Meetupの発表資料や開催時のツイート、付録資料、ブログをまとめます。 YouTube www.youtube.com 発表資料 プロダクトと同時にバージョンアップは当たり前、これからの管理ツール作りとは / How to create cs tools to support creativity - Speaker Deck 一人ひとりに寄り添ったCRMツールによるカスタマーサポートの新しい形 / New

「あなたたちは技術力がない」 2019年を振り返って真っ先に思い浮かぶのは、普段一緒に働いてない人に、面と向かってこう言われたことだ。 みなさんはそんな経験あるだろうか？ エンジニアの中でも特に優れたエンジニアのことをスーパーエンジニアという。スーパーエンジニアとは抜きん出て「技術力がある」エンジニアのことだ。 「技術力がある」って言葉、わかってるつもりでつい使っちゃうんだけど、みなさんはどうだろう？ 例えば最近Twitterで話題になっていたこちらのツイート。 スーパーエンジニアが通った跡には誰もメンテできない超絶コードが残ったりするので、チームでパフォーマンス出せないスーパーエンジニアをありがたがるのって、ミーハーな経営者くらいしかそもそもいないのでは。— 大岡由佳『りあクト! 第3版』技術書典9までに刊行 (@oukayuka) 2019年12月25日 私の知っているスーパーエンジニ

GitHub Actionsのワークフロー設定ファイルは、以前はHCL形式でしたが今はYAML形式になっています。 このエントリでは、GitHub Actions(setup-terraform)でTerraform plan/applyを自動化する方法を紹介します。 手っ取り早くworkflowファイルのサンプルだけ欲しいという方は下記をご覧ください。 GitHub - otoyo/github-actions: GitHub Actions samples 前提条件と注意点 クラウドリソースをすでにTerraformで管理している まだという方は下記を参考にTerraform管理にしてください。 既存のAWS環境を後からTerraformでコード化する | Developers.IO tfstateファイルをS3などリモートで管理している ローカルにある人は下記を参考に移行してください

令和になり、CREという役割はときどき耳にするようになってきました。GoogleがCREを発表したのが3年前、はてなに続き2017年末に私がミクシィでCREを立ち上げてから1年半が経っています。 今日は、以前からカスタマーサポート(CS)エンジニアとしてCSに携わってきた私が、ミクシィCREのこれからについて思うことを振り返りとともに書いてみたいと思います。 CSの宿命 私がミクシィに入社してCSエンジニアとしてのキャリアを歩み始めたのは25歳のときで、2013年2月でした。覚えている方もいらっしゃるかもしれませんが、ミクシィが初めて赤字転落し大きく報道された年でもありました。その後、モンストのヒットによりV字回復を遂げるのですが、それまでの暗澹たる雰囲気は、入社したばかりで為すすべもなかった苦々しい記憶として今でもよく覚えています。 私は経営についてはわからないのですが、経営が悪化したと

新しい年度が始まり、SNS上では「○○にチャレンジします！」といった意気込みがよく見られるようになりました。4月の風物詩ですね。「やります！」と宣言した人のうち、何割が実際に「やった」人になるのでしょうか。私は「やります！」よりも「やった」と言える人に憧れます。「やる」と心の中で思ったならッ！その時すでに行動は終わっているんだッ！ 仕事が大好きで寝食忘れて仕事したいという人は少ないと思います。口には出さないものの、働かなくていいのなら働きたくないという人が大半でしょうし、ソフトウェアエンジニアの三大美徳には「怠惰」があるので、ソフトウェアエンジニアは全員そうでしょう。私はそうです。 「AIに仕事を奪われる」というフレーズはもはや聞き飽き、「だったら早く仕事を代わってくれよ」と思いつつも、実際に労働から解放されるにはまだ時間がかかるでしょう。それまで私のように意識が低い人でも、この先生きのこ

マネージャーの評価にチームメンバーからの評価も入れようという動きが見られるようになってきた。 この評価の方法は、評価される側である被評価者が、逆に評価者を評価するという意味で「逆評価」と呼ばれる。評価者・被評価者だけでなく、もっと広く同僚や関係部署などあらゆる方向からの評価も加える「360度評価」というのもある。 逆評価や360度評価は、いろんな人の意見を評価に反映させるので公平で良い制度のように思える。だからこそ、いくつかの企業が取り入れているのだろう。 でも本当にそうだろうか？今日は、行き過ぎた逆評価はチームを滅ぼすのでやるなら慎重にという話をしたい。 評価の目的とは？ 評価される側にとって、評価というイベントはどうしても給与を決定する「査定」の印象が強い。結果として給与の増減はあれど、評価は査定ではない。 評価の目的は、被評価者の成果を振り返り、課題をフィードバックし、被評価者に次の

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。 「入門 監視」は、監視の基礎をアンチパターンから順にわかりやすく説明してくれます。 このエントリでは、「入門 監視」の内容をまとめます。 1章 監視のアンチパターン 監視するだけでは壊れたものは直せない ツールに依存しても監視の仕組みはよくならない 監視ツールに銀の弾丸はない 監視ツールによくある間違い 成功したチームや会社は、ツールや手順によって成功したのだという間違った考え方によって、そういったチームや会社が使っているツールや手順を採用して、同じ方法で自分たちのチームを成功させようとしてしまうのです。 観察者効果は気にしない 観察者効果とは、監視する行為が監視対象を変化させてしまうこと。現代のシステムは負荷が増えても処理できるため観察者効果は気にしなくて良い

自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけれど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。 こんな心境の吐露を「エンジニアリングマネージャのキャリアについての悩み」で拝見して、私も何か発信しなければと思ったのがこの記事のきっかけである。筆者のdaiksyさんは、 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです？ とも述べていて、これら2つのメッセージに込められた心の葛藤は、全てのエンジニアリングマネージャー(以下EM)が感じていることではないかと私は思う。少なくともEMの一人として私

2018年は、私が観測する中ではランサーズさん、Reproさん、メルカリさんがCREを発足し、CREが世の中に徐々に広まりつつあるなと感じた年でした。 CREはなぜ広まったのか？ 広まったことで何が起こったのか？ 今後この広まりはどうなっていくのか？ 今日は、一年間CREの盛り上がりを見守ってきた一人として、これらの疑問に対する考えを書いてみたいと思います。 1. CREはなぜ広まったのか？ 2017年に私がミクシィでCREを立ち上げたとき、1つの仮説と確信がありました。 私はCREになる前から、CS向けのシステム開発などを担当する部署にいましたが、残念ながら、社外はおろか、社内でもその存在はあまり認知されていませんでした。 どんなサービスもCSやCSを支えるエンジニアがあってこそ持続可能なのに。 私が立てた仮説はこうでした。 社外にもきっと自分と同じくCSに関わるエンジニアがいるのではな

CX Night vol.2というイベントで「CREと歩むこれからのCS」というタイトルで発表しました。 発表資料は下記です。 speakerdeck.com mercari.connpass.com 会場はとてもおしゃれなバーのようなお店で、100人くらいの参加者で満席になっていました。 私はCXというワードは普段使っていなくて、それなのに自分が話しても良いのかなと思っていましたが、登壇後には数人の方からお話を聞けて良かったと言っていただいたので、ためになる話ができて良かったと思いました。 KPIやNPSに関する補足 パネルディスカッションや質疑応答ではKPIやNPSに関するテーマが多かった印象です。 実は私はNPSに対しては懐疑的な立場で、パネルのときにはまとめきれなかったので、理由について少し補足しておきたいと思います。 少数派と多数派のスコアに相関はあるのか？ NPSなどのアンケー

これから CRE を始めるにあたって、どんな人を集めれば良いでしょうか？ 私は先日のイベントでこんな質問を受けました。 もちろん「どんな人でもいい」わけではありません。 興味の方向性や自己実現の方法は人それぞれです。 アプリエンジニアにはアプリエンジニアの、インフラエンジニアにはインフラエンジニアの適性があるように、CRE には CRE の適性があります。 自分で言うのもなんですが、私の所属する CRE チームはよく自己組織化された素晴らしいチームです。 今日はどんな人が CRE に向いているか、この身近な CRE チームを見てきた私の考えをお話ししたいと思います。 CREに決まった形はない CRE と一口に言ってもその在り方は様々です。 例えば、はてなさんの CRE はサーバ監視サービスのセールスエンジニアから来ています。一方、私の所属する CRE は、元々は mixi 時代から存在する

エンジニアといえども社会人として働く上で避けては通れない人付き合い・人間関係。 今日20代を終えたばかりの筆者が、仕事で信頼を得るためにやってはいけない人付き合いの最低限のマナーをまとめました。20代の自分への戒めを込めて…… 1. 話を聞かない 20代前半の頃、私はとても嫌なやつでした。 人にきらわれたり、かげで笑われたり、軽蔑されたりしたかったら、つぎの条項をまもるにかぎる－－ 一、相手の話を、決して長くは聞かない。 一、終始自分のことだけをしゃべる。 一、相手が話しているあいだに、何か意見があれば、すぐに相手の話をさえぎる。 一、相手はこちらよりも頭の回転がにぶい。そんな人間のくだらんおしゃべりをいつまでも聞いている必要はない。話の途中で遠慮なく口をはさむ。 D・カーネギーの『人を動かす』では嫌なやつになるためにこんな方法が紹介されています。 上記4つのうち私はどれを実践していたか？

開発チームのリーダーになって2年半が過ぎ、それだけやっていると一通りのことは経験した気になってきます。 普段あまりこういうことは書かないし言わないのですが、このあたりでいったん私がこれまで感じた不安についてまとめておくことで、将来チームリーダーになる方々の心の準備になれば良いと思っています。 リーダーになって初めの1年ほどはエンジニアの上長で、実質的にはお守り付きみたいなものだったため、これといった不安もなく、いろいろなことにまだ気がつかない時期でもありました。 ほどなくして組織変更があり、非エンジニアの上長になりました。下記に挙げる3つの不安は、この独り立ちしなくてはならない期間に感じたものであります。 1. 業務内容の変化による不安 最初に訪れたのは、業務内容の変化から来る不安でした。以前の私は業務時間のほとんどを開発に充ててきました。今思えば、開発に集中できるように上長が環境を整えて