2021年度リクルート エンジニアコース新人研修の講義資料です
2021年度リクルート エンジニアコース新人研修の講義資料です
本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。 ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。 無駄なく、効率的にと思っても、ついつい発生しちゃう。 こういうの、オーバーエンジニアリングって言うらしいよ!? でも、どこからオーバーで、どこまではオーバーじゃないんだ!! ということで、勝手にオーバーエンジニアリングを定義してみようと思います。 作り過ぎて、時間や金を無駄にすること???? とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。 wikipedia(英語版) Overengineering - Wikipedia 一部抜粋。 Overengineering (or over-engineering,[1]
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
本ポストは特に私が所属する組織の見解ではなく、私が今までの経験&自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く