本当にあった怖い話: Dockerイメージにはバージョンタグをつけろ!
こんにちは、ハコベル開発チームの坂東です。今日は、実際に私たちのチームで起きたちょっとした“怖い話”を共有しようと思います。 開発は順調に進んでいたはずだった… 私たちのチームでは、これまでプロダクトをローカル環境で動かす際、ファイルアップロード系の処理では開発用のAWS環境に直接アップロードするようにしていました。 しかし、複数のAWS環境を跨ぐような開発をする時にやりづらいので、効率化のためにローカル環境でAWSをエミュレートできるLocalStackを導入することにしました。LocalStackは、他のチームでも導入実績があったので、安心して導入に踏み切りました。 一人のメンバーがLocalStackを組み込んだPRを作ってくれ、みんなでその動作確認をすることになりました。ところが、全員が同じブランチで動作確認しているにもかかわらず、うまく動くメンバーと、うまくいかないメンバーが出て
働きたくない人の脳内｜Aki
これは私が普段いかに労働から逃げているかを示すものです。 前提となる考え方私は働きたくない。実際には仕事にやりがいを見出すこともあるので必ずしも働きたくないわけではないが、基本的には常に働きたくないと言っている。 ことプロダクト開発になるとこの傾向は顕著で、「何も作りたくない」「何も作らずにお金を稼ぎたい」などとよく言っている。プロダクトは作った瞬間に負債になる。世の中は絶えず変化・進化していくので、作った瞬間から陳腐化が始まる。それを防ぐために継続的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロダクトが負債以上に大きな果実つまり価値をもたらすからである。アジャイルの名のもとに incremental delivery などと言うと聞こえはいいが、要するに負債より多くの価値を生み出すための自転車操業をかっこよく言っただけである。少しトゲのある表現になったが
プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ
エンジニア主導で爆速開発を実現する - Tabelog Tech Blog
はじめに こんにちは。食べログ開発本部 ウェブ開発1部の羽澤です。 マネージャーという立場で働いておりまして、案件をリードしたり、一歩引いてメンバーや案件をサポートしたり、その時々で役割を変えながら日々過ごしております。 その中でいつも頭を悩ませているのが、いかに早く開発を進めるかということです。これは食べログだけでなくどんな組織でも常に考えている、永遠の課題だと思います。 今回は食べログの開発体制を紹介しながら、自分として爆速で進められたと感じている案件を紹介します。「なぜうまく行ったのか」を掘り下げることで見えてきた重要な視点を、「爆速で進める1つのポイント」としてまとめてみました。 プロジェクト体制の紹介 開発の話の前に、前提となる組織の形を紹介します。 私の所属するウェブ開発1部では、マトリクス型の組織を採用しております。 ウェブ開発1部の事例ではありませんが、以下の記事が参考にな
ITのひどい記事をみんながブクマしてキツイ
以下の記事、内容がひどくて空いた口が塞がらなかったのだが、 （はてブで）ブックマークして下手にホッテントリにでもなったら嫌だなと思いそっとブラウザのタブ閉じた。 が、しばらくすると残念ながらホッテントリ入りしてしまったので、はてブにコメントを軽く書こうとしたが100文字に収まらなかったので増田にした。 技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL まず、「特定条件下では MySQL は我々のプロダクトには不向き」を「MySQLを使うと会社は潰れる」なんて表現するのおかしいでしょ。 以下の記事からの引用だが Uber のエンジニアは「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない、MySQL＋InnoDBに変えたら全部解決した」と主張している。 UberエンジニアがブログでPostgre
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
Amazonは生成AIアシスタントで開発者4500人年の工数を節約し、年間2億6000万ドルもの効率向上を実現したって？ - YAMDAS現更新履歴
Amazon のアンディ・ジャシー CEO の以下の投稿が話題になっている。 One of the most tedious (but critical tasks) for software development teams is updating foundational software. It’s not new feature work, and it doesn’t feel like you’re moving the experience forward. As a result, this work is either dreaded or put off for more exciting work—or… pic.twitter.com/MJvsqNxgiT— Andy Jassy (@ajassy) August 22, 2024 ソフトウェア開発チームにとっても
リードについて - @m_seki の
リードについて 本書のエッセイをお願いされた時、リーダーシップとはなんだろう、リーダーとはなんだろうと考えました。きっとリードする人がリーダーですよね。うーん。どうも「リード」自体がよくわかってないようです。 私たちのチームには明示的なリーダーが存在しません。チームをリードする係の人がいないのです。そこで、チームの毎日をふりかえって、リードのようなものがなにかないだろうかと探してみました。 そういえば、メンバーの誰かがチームを変化させることがあります。いつもの 1 日 のちょっとした場面で、チームの安定を壊すような「言いにくいこと」を言うのです。 それは技術的な指摘であったり、ムードの問題であったり、執務環境のことであった り、体調のことであったり、いろいろありますが、どんな発言であってもそれを聞い てチームは新しい状態に変化します。私たちのチームにとって、チームを引っ張ると いうより、チ
フロー効率と経験資源の葛藤 - yigarashiのブログ
不確実性の高いプロダクト開発や、継続的な価値提供を行なっているサービスにおいては、フロー効率を重視するのが良いとされている。ある価値が早く顧客に届く方が、早くフィードバックを得られるとか、顧客が享受する価値の総量が大きくなるとか、様々な方向からメリットは説明され尽くしている。それには同意する。 開発プロセスの文脈でもフロー効率を重視するためのプラクティスは一般的だと思う。スクラムの言葉に従えば、スプリントゴールはなるべくシンプルにひとつにしようとか、ひとつのプロダクトバックログアイテムを複数人で片付けようとか、そういった話である。チームの付加価値生産性を最大化するために、こうしたやり方を採用するのは素朴には理にかなっていると思う。しかし最近、メンバーの育成や評価に対する責任が大きくなってきて、その立場から改めてこれらのプラクティスを考えると、手放しに最高とは言い切れないなと葛藤している。
ファインディの爆速開発を支えるモノレポ管理ツール「Nx」について - Findy Tech Blog
ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、ファインディで導入しているモノレポ管理ツール「 Nx 」について紹介します。 モノレポとは Nxとは Nxワークスペースの作成 Nxの機能 コード生成 変更検知 依存関係の管理 キャッシュ機構 自動マイグレーション まとめ モノレポとは モノレポは全てのコードベースを単一のリポジトリで管理する手法です。 monorepo.tools コードの共通化や可視化、ツール・ライブラリの標準化、一貫性のあるCI/CDパイプラインを構築できるといったメリットがあります。また、マイクロサービスと相性が良いとも言われています。 circleci.com ファインディでは主にフロントエンド系のリポジトリをモノレポとして運用しています。 アプリケーションとそれに関連するフィーチャー、UIライブラリがひとつに
プログラムの生産性を高めるためになにを勉強するか - きしだのHatena
用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
ウォータフォールはやめて2024年の開発をやろう！｜牛尾 剛
今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と
エンジニアのための十徳ナイフ「DevToys」がバージョン２になってクロスプラットフォームやCLI対応しさらに便利すぎる - Qiita
はじめに 以前紹介させていただき、2022年Qiitaのいいねランキング18位、ストックランキング20位を記録したこちらの記事の続編です！ DevToysはリリース後しばらく定期的なバージョンアップが続けられていましたが、去年の7月からぱったりとアップデートが止まっている状態でした。 リポジトリや作者のXを見るとバージョン２の開発を行っているようで、今か今かと待ち続けていましたが数日前リリース予告のポストを見つけて、今日ついにプレリリースされました！ ということで早速紹介していきます！ DevToysとは DevToysは「開発者のためのスイスアーミーナイフ」の紹介文の通り、開発時によく使うツールを十徳ナイフのようにまとめたアプリとなっています。 JSONの整形とかエンコードデコードetc... プログラミングや保守運用の調査でやりがちな作業をいちいち変換サイトを探したり、エディター拡張機
大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
なぜ1年でゲームを完成させようと思っても当然のように4年以上かかるのか｜じーくどらむす
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
生成AI時代のフロントエンド開発術
2022年11月にChatGPTがリリースされて、1年と約半年が経過しました。私はChatGPTが話題になった頃から、継続して利用しています。ChatGPTを使い続けていると、Webアプリケーションのフロントエンド開発に役立つことがありました。 そこで、本記事ではフロントエンド開発でChatGPTを活用して効率よく進める3つのパターンにまとめました。これらのパターンを紹介し、読者の皆さんの開発に役立ててもらえればと思います。 以下は、本記事で紹介するFigma、ソースコード、デプロイ先URLです。 Wireframing photo - Figma silverbirder/figma-photo-sample-app-for-ai - GitHub https://figma-photo-sample-app-for-ai.vercel.app ChatGPTを使う前に ChatGPTに
兼務による体制構築はプロジェクトの効率を損なわせる｜mtx2s
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オペミスの謝罪時 お客様が「そろそろペナルティを契約に盛り込みたい」とまで言い始めたときに上司がハートの強い反論をかましてくれた
