本記事は BASE アドベントカレンダー 2024 の 24 日目の記事です。 こんにちは、エンジニアリングマネージャーの松原(@simezi9)です。 新型コロナウイルスの流行に端を発する世の中の変動からもうじき5年が経過しようとしています。 当時の感染対策の流れで多くの企業がリモートワーク制度の導入を進めました。この記事を読んでいる方の中にもそのタイミングではじめてリモートワークに取り組んだ方も多いのではないでしょうか。 私もその当時に、BASE株式会社のリモートワークへの取り組みをエントリとして公開したことがありました。 参考：エンジニアのリモートワーク in BASE このエントリを書いてから4年。その間、マネージャーという立場からリモートワークの制度を運用してきた経験を踏まえて、私がいまリモートワークというシステムに対して思っていることを率直に書いてみたいと思います。 この文章が

誰かの何かの行いに対して、至らない点が気になってしまうことは誰でもある。 たとえば、ソフトウェアの不具合を報告してくれた時に、「正直もう少し事象を整理したり原因の切り分けをして伝えてほしいな」と感じてしまったとか。不具合を見つけいち早く報告してくれたこと自体は素晴らしくて感謝すべきなのに、至らなかった点の方が気になって指摘してしまったりする。 何かの提案の内容がそこまでよくなかった時なども同じ。"よくなかった" という結果に目が行ってしまって、たたき台を作って準備してくれたことや提案してくれたことに対するリアクションが希薄化してしまったりする。 相手の行いのよかったところとよくなかったところを無意識のうちに "平均" した印象で評価してしまいがちなのだと思う。よくなかったところは目立って印象に残りやすいので当然と言えば当然である。 先の例で言えば、まずは「報告してくれてありがとうございます

正論は人を傷つける。いつだって── 正論を言われた方が傷つくのは想像しやすいかもしれないが、実は言う方もダメージを負ってしまうことがある。真面目な人ほど、正論を振りかざすだけになってしまうことを怖れている。 誰かに正論を伝える時に意識しておくとよいお作法みたいなものがいくつかあると思っていて、雑に書き出してみる。 1. 正論になっているかを確認する 実は自分の情報が足りていなくて正論になっていないこともあるのでいったん疑ってみる 「言っていることが全然的外れだったら教えてほしいんですが」のような感じで、認識が擦り合っているかをまず確認するとよい 相手に敬意をはらい、「すでに色々検討された結果かもしれないですが」のような枕詞をつけるのも切り出しやすい ここの認識が揃っていないまま話していくと、終わりのない議論が続いていきがちなので注意 2. 責める意図はないことを伝える 正論を伝えることは批

これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "

リファラルで候補者がたくさん来て採用につながり、入社後にも活躍してくれる状態は最高である。採用活動の理想と言ってもいい。 しかし、メンバー観点だとリファラルで人を誘うのをためらってしまうことも多い。いい会社/チームだと感じていたとしてもなかなか誘えないこともある。リファラルで人を誘うのをためらう理由を雑に書き出してみる。 1. 誘える組織ではないと思っている 中で働いていて、知り合いを誘える事業や組織ではないと判断していたら当然誘えない 組織自体はそこまで悪くないと感じていたとしても、「この人を誘えるレベルではないなあ」と尻込みしてしまったりもする たぶんこれがリファラルをためらう一番の理由で、"誘ってもいいと思える閾値" を超えていなければ話にならない 2. 誰にどう声をかけたらいいのかわからない どういうレベルのつながりに対して、どういう温度感でどのように声をかけたらいいのかわからない

こんにちは。プラットフォーム開発部 EMのchikaです。 今回は、誰もが避けたい話題、障害対応について書こうと思います。 はじめに 参考書籍 障害対応はなぜ難しいのか 経験することでしか身につかない 突然デビュー戦を迎える （おまけ）障害は空気を読んでくれない？ すぐ筋肉が落ちる、感覚が鈍る 障害対応の体制づくりの鉄則 一人でやらない インシデントコマンダーを決めて作業と窓口を切り離す インシデントコマンダーになるのは誰？ （補足）インシデントコマンダーとインシデントコマンドシステム（ICS）について 障害対応で覚えておきたいこと7つ 1. 初動は本当に重要 一報までの時間 初動を早めるために必要なこと （余談）一報するのも必死 2. 対策本部の設置 対策本部にはいつ集まればよいか？ 3. 情報発信の一元化 4. 報告タイミングと内容に迷ったら 定期状況報告で気をつけたいこと 5. 対応

2021年度リクルート エンジニアコース新人研修の講義資料です

コロプラが実践しているSpinnakerを用いたデプロイ戦略 / Deploy Strategy with Spinnaker at Colopl