本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz

ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad

2021/9/23プロジェクトリードにおける考察について取り入れた2021/10/11職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート2021/12/10プロフェッショナルの年収を520~550万を520~570万に変更チーフプロフェッショナルの年収を550~600万を570~620万に変更マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニアの年収上限を950万から1000万に変更アーキテクト、リードアーキテクトの職位ガイドラインの詳細（暫定）を追加2022/4/11リードエンジニアの年収レンジを650-700万についてを、650-720万に変更チーフリードエンジニアの年収レンジを超える700-800万から、720-800万に変更2023/3/13 プロフェッショナルのチームコラボレーション（主体性）に追加

こんにちは！アンドパッドの荒瀧です。 「ANDPAD TECH TALK」第5回の配信です！ 出演 モデレーター: 荒瀧 (EM 兼 エンジニア採用マネージャー)・ 中野 (HR) ゲスト: 彌冨(テックリード) ハイライト 第5回は、アンドパッドの中間期に入社以降、プロダクト開発とエンジニア組織作り両面の最前線からキャリアをスタートし、今も第一線で「ANDPAD受発注」の開発をリードしている彌冨さんの登場です。 アンドパッドの急成長を推進し続けてきたエンジニアのここだけでしか聞けない急成長ベンチャーの開発秘話が盛りだくさんの回となっております！ モルガン・スタンレーからアンドパッドへ。大手金融外資から建設SaaSベンチャーに転職した理由 アンドパッド自転車部は体育会系ではなく筋肉会系!? 私ごとで恐縮ですが、剱岳山頂でプロポーズしました！ 入社直後、引合い粗利管理チームにジョインし、経営

macOS 12 Montereyがリリースされました。また2021年09月にはiOS 15もリリースされています。 2020年にリリースされたiOS 14 / macOS 11ではWebPのサポートを開始し、macOS 12ではOpusのサポートを開始しました。 また最近ではGoogle Chrome、FirefoxがAVIFのサポートを開始するなど、新たなメディアフォーマットも登場しています。 そこで2021年現在、Webにおける最適なメディアフォーマットを整理しようと思います。 TL; DR 画像: WebP もしくは SVG 音声: AAC - .mp4 動画: H.264 - AAC - .mp4 もしくは VP9 - AAC - .mp4 最適とは なるべく多くのデバイスとOSとブラウザでデフォルトで使える macOS: Chrome、Firefox、Safari、Edge (

さて、ついに退職エントリだ。私は米国のオープンソース・ムーブメントを日本で再現するためのコアを作るために民間企業へやってきたはずだった。それから21年、随分と長い航海になってしまったが、結局様々な尻拭いを続けてきたという感慨ばかりが起きてくる。一つの歴史として書き残すいいタイミングなのでその苦闘を振り返っておこう。 なお、長く付き合いが続いてしまう米国側法人は下記のように名称が変化している。なるべく頭に米国と付けて日本側法人と区別しやすいように記述するが、突然名称が変わったりするので注意してほしい。多くがもはや消滅した法人のことなので、さすがに一気読みするような酔狂な人はほぼいないと思うが。 VA Research　　　　　　Andover.net ↓　　　　　　　　　↙︎ (VAによる買収) VA Linux Systems ↓　　　　　　　　↘︎ (Andoverから社名変更) VA

こんにちはKARTE Blocksチームです。 日々プロダクトを開発していると新しい機能が増えます。 一方で古くなる機能も増えるため、負債となった部分がボトルネックとなり、新規開発へも影響してきます。 そのため、古くなった部分を解消しながら、新しい技術をインクリメンタルに取り込んでいく必要があります。 この記事は「KARTE Blocksリリースの裏側」という連載の2日目の記事です。全10回

# フロントエンドエンジニアのステップアップのための集合知 ジュニアとミドルはソフトスキル多めなのでフロントエンドエンジニアに限らなそうです - 期待役割 ... 該当ステップ内での TO BE - できてほしい ... 該当ステップ内での WANT (🔐は次ステップへ進む上では MUST) - 次のステップへの期待 ... 次のステップへ進む上での MUST ## ジュニア (ステップ1) ### 期待役割 - 指示された小さいタスクをこなすことができる - ~3人日くらいの影響範囲の閉じたタスクを想定 - 仕様が決まっている、あるいは不明な場合は質問できる ### できてほしい #### ハードスキル - 初歩的なセキュリティバグを生まない - #### キーワード - XSS - コード内に必要に応じて意図をコメントとして残せる - #### 🔐自立的にファイルや関数を分割ができ

先日の ua-parse-js のハイジャックの件 を受けて、業務の中で毎日動かしている On-premise Renovate の cron を土日祝に停止させたいという話が上がった。 業務の合間に書く時間がちょっと捻出できそうになかったこと、加えて汎用的なコードということもあり、プライベートでも使えそうだったので一般化した範囲でコードを書いてしまって、業務で社内用に調整する形で決着させたので、せっかくなので共有しておく。 社内が基本的に CircleCI なので特化したものと、一般的に使えるものでバリエーションごとに2つのパターンを用意した。 祝日に停止させるアプローチ ひとまず今回は内製の Bot の運用のため、以下のような特徴があった。 土日の設定自体は cron で曜日指定ができるため祝日にフォーカスして良い 厳密性を重視しない ミッションクリティカルな領域の話ではない 以上を考

Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか？」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか？」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS

人生は「偶然のゲーム」 私は麻雀プロの中でも「とくにメンタルが強い」と言われています。サイバーエージェント社長で、Mリーグ「渋谷ABEMAS」監督の藤田晋さんは、私のことを「鋼のメンタル」と評しました。強いか弱いかと問われれば、強いほうでしょう。自分でもそう思います。 しかし、本当に私のメンタルが強いのでしょうか？ 何か少し悪いことが起こっただけで、「もうダメだ」と落ち込んで、投げやりになってしまう。そういう人が多い印象です。 それは麻雀プロの中でも、例外ではありません。麻雀は「いい偶然」と「悪い偶然」が起こり続けるゲームです。なのに、なぜか悪いことが起こると「あの一手で心が揺れてしまった」とか、そういう表現をする人がとても多いのです。 先日、ある企業で営業マンをやっている友人と昼にばったり会ったので、ランチを共にしました。ランチの間、彼は自分のスマホ画面を見ながら、「あー今日はツイてない

応募を考えているみなさまへ LINEヤフーは日常生活のあらゆるシーンで活躍する多種多様なサービスを作っています。 今までのキャリアを生かし、より便利なサービスを創りたいという意欲がある方、ぜひLINEヤフーでともに働きませんか。 まずは応募および応募検討のための方法・機会についての案内「応募ガイド」をご覧ください。 応募ガイドを見る

こんにちは。Rimo合同会社で代表社員をしている相川です。 前回は、副業ファーストな制度設計の概念的な部分まで説明したので、 今日は、具体的にはどのようなことをやっているかについて説明してみたいと思います。 おさらい副業ファーストな制度に必要なことは、個々に納得できるルールを考えることでした。一概に公平なルールを当てはめるわけではなく、個々の納得で考える事が重要になります。 実際にやってみると、場所や時間については、あまり交渉せずに基本副業者の都合に合わせて設定するだけで決まります。例えば、沖縄にいる、ベトナムにいるみたいな人がいるのですが、それはそこでやってもらう以外方法がですし、土日やります、平日夜やりますみたいなことは雇うことを決めた以上は受けいれるだけです。 結局その上で仕事内容と給与をどうするかの交渉だけが問題になります。仕事内容を人に合わせるのは当然なので、結局給与の決め方を柔

こんにちは、こんにちは。フロントエンドとWebの可能性を信じる@yamanokuです。 最近気になっている W3C Working Draft はCSS Nesting Moduleです。*1 現在クラウドワークスのプロダクトで導入されているフロントエンドのlintツールはeslint、stylelintで、これらの規約に違反しているコードはCIによるチェックを通じて指摘されるようになってます。 今回このlintツールの中に新たに「markuplint」を追加した話をしようと思います。 markuplintについて 詳細については公式のリポジトリや作者による紹介（YouTube動画）を見ていただくのが一番なので、ここでは軽い紹介に留めます。 その名の通り「マークアップすること」に関するlintツールで、各種ルールについても柔軟に設定できるようになっています。 かつてフロントエンドチームでア

月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会（SEC）に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。 開発初期か

実質無料で使える Hosting Service の比較や使い分けの紹介 2021 (Firebase Hosting, Cloudflare Pages, Vercel, Netlify, GitHub Pages, Amplify, CloudRun)2021-10-04 ホスティングサービスに何を使えばいいのか分からないという話はよく目にしますし、僕もたまに思います。 そこでこれまで自分が使ったサービスの特徴や for me, not for me な点を紹介します。 静的ページ、および NextJS を前提としたサービス選定で、Firebase Hosting, Cloudflare Pages, Vercel, Netlify, GitHub Pages, Amplify, CloudRun を紹介します。 また、それらはフリープラン前提の話であり、not for me な点は課

みなさんこんにちは。@ryuzeeです。 スクラムに限らず開発プロセスそのものは目的を達成するための手段に過ぎないので、定義されたプロセスやプラクティスを単に守れば良いというわけではありません。 根底にある価値観や原則を理解することが重要です。 とはいえ、自分たちのプロセスが定義されたもの、一般的なものとどれだけ違うかを知ることは、改善のキッカケにもなります。 今回、スクラムチームが、自分たちの仕事のやり方を改善する際に参考にできるような、セルフアセスメントのチェックリストを作ったので共有します。 現時点では単なる試作品なので、ご利用は自己責任でお願いします（この記事に限らず当サイトの記事を参考にする場合も同様です）。 使えそうなら適宜更新していく予定です。 観点はスクラムの主要要素（3-5-3）にしています。フィードバックなどがありましたら、@ryuzeeまでお知らせください。 使い方使

This post is also available in 简体中文, 繁體中文, 日本語, and 한국어. By reading this, you are a participant of the web. It's amazing that we can write this blog and have it appear to you without operating a server or writing a line of code. In general, the web of today empowers us to participate more than we could at any point in the past. Last year, we mentioned the next phase of the Internet would be always