様々な業態の会社さんからご相談をいただきますが、ここのところ「これまで掲げていたエンジニアファーストを撤回したい」というご相談を頂くようになりました。 エンジニアファーストとは2010年代中盤から多用された言葉であり、下記のようなものを掲げながらエンジニア中心の組織づくりを目指すものでした。 給与 休み 業務内容 福利厚生 残業0、もしくは1分単位の残業代精算 稼働時間のn%を自由に使って良い 今回はエンジニアファーストの撤回を考える企業の思惑と、今後についてお話していきます。 アベノミクスとコロナ禍での金余り現象に支えられた「エンジニアファースト」2010年代後半にはエンジニアの採用人数を追うことを目的に、候補者の目を引くワードとして多用されていきました。 エンジニア界隈で行くと、2015年のアベノミクスとコロナ禍での金余りの投資先として新規事業やDX関連が存在しており、その向かった先と

Cron scripts are responsible for critical Slack functionality. They ensure reminders execute on time, email notifications are sent, and databases are cleaned up, among other things. Over the years, both the number of cron scripts and the amount of data these scripts process have increased. While generally these cron scripts executed as expected, over time the reliability of their execution has occ

アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏：みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 （会場拍手） 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ

追記 with.workdir: は with.work-dir: に変更になっています https://t.co/RsAqx9wVhT の v1 リリース作業をしている— k1LoW (@k1LoW) 2024年1月24日 octocov-action v1 をリリースしました。octocov-actionはoctocovをGitHub Actionsで使う際に使用するActionです。 github.com 今回、何が変わったかを紹介します。 Docker container actionからComposite actionに変更 Actionの実装方式をDocker container actionからComposite actionに変更しました。 これにおける効果は大きく2つあります。 octocovのバージョン指定が可能になった 1つ目は octocov のバージョンを柔軟に指

以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

はてなブログ独自の集計による人気記事のランキング。1月21日（日）から1月27日（土）〔2024年1月第4週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 ホットクックを3年近く使い倒してる俺がいまだに感動しまくってる利点を教えよう - 狐の王国 by id:KoshianX 2 DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog by id:bengo4 3 クックパッドを退職しました - 昼メシ物語 by id:mirakui 4 【読書感想】安楽死が合法の国で起こっていること ☆☆☆☆☆ - 琥珀色の戯言 by id:fujipon 5 パルワールドはパクリゲーか？ - 雑炊閣下備忘録 by id:wakamotoinoti 6 心理的安全性の高い職場はどのように作られているか？ - Techtouch Developers Blog

前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」 という文が紹介されました。 つくっているプロダクトで得られる売り上げよりも、 変更などにかかるコストが上回っている状態なわけだから、 お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。 で、事前に負債解消

コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか？」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか？」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には？クレームが来る、という事でしょうか？」 営業「まあ、そうかもしれません。」 企画「か