優先順位が口癖になる危機感 - ジンジャー研究室
開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
martinfowler.com
Software development is a young profession, and we are still learning the techniques and building the tools to do it effectively. I've been involved in this activity for over three decades and in the last two I've been writing on this website about patterns and practices that make it easier to build useful software. The site began as a place to put my own writing, but I also use it to publish arti
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog
SmartHRの基本機能と呼ばれるプロダクトでエンジニアリングマネージャーをしている @sugamasao (id:seiunsky) です。 この文章はSmartHR Advent Calendar 2022の2日目のエントリーとして書いています。 はじめに、いくつか前提となる状態をお伝えすると、私の所属している「基本機能」プロダクトはScrumを拡張したLeSSというフレームワークを使っており、現在は6チームで1つのプロダクトを開発しています。 さらに、私は今はエンジニアリングマネージャーという立場にいますが、少し前まではこの6チームのうちの1チームに所属するメンバーでした。そのため、これ以降に記載している取り組みは私がチームに所属していた時にはじめたものという認識をしていただけますと幸いです。 テックな話題 #とは リモートワーク主体で仕事をしていると意識的に雑談によるコミュニケーシ
巷で聞く、Developer Productivity Engineeringとは何か - Blog::kobaken
この記事は、開発生産性アドベントカレンダー 2022の1日目の記事です。 最近、街のうわさで、Developer Productivity Engineering、略してDPEという言葉を耳にします。 海外の事例 Google Meta Microsoft Amazon Netflix Slack GitHub 国内の取り組み サイバーエージェントのDeveloper Productivity室 メルカリのDeveloper Productivity Engineering カンファレンス DPESummit 2022 Speakerを見るとBig Techが並んでいる Developers Summit 2022夏 Launchableの川口さんの「Developer Productivity 20年物語」の登壇が個人的には印象深い その他 Gradleが出しているDeveloper P
HERP における Nix 活用
HERP における開発では Nix が広く活用されている．Nix は非常に便利な代物なのだが，ドキュメントの貧弱さ，急峻な学習曲線，企業における採用事例の乏しさなどが相まって，広く普及しているとは言い難く，ましてや国内企業での採用事例を耳にする機会はほとんどない．しかし，Nix の利便性は，複数人での開発においてこそ，その本領が発揮されると考えている．この記事は，HERP における活用事例の紹介を通じて，Nix の利便性ならびに企業での活用可能性について紹介することを目的としている． Nix とは# Nix は "the purely functional package manager" と銘打たれたパケッジマネジャーである．GNU Linux および macOS 上で利用できる． ビルド# Nix は the purely functional "package manager" なの
デスクトップ環境をdisposableに保つ - あんパン
もう5年以上続けている取り組みのひとつにデスクトップ環境をdisposableに保つというのがある。いつでも何があっても即座に環境を捨てて作り直せるようにするということ。EC2やVPSのインスタンスに対してAnsibleでプロビジョニングできる状態にしておけば即座に新しいホストを立てて古いホストを捨てられる、そんな状態を目指すということ。具体的には以下のようなことを心がけている。 書類のマスターデータを端末上に置かない デスクトップ環境をdisposableに保つ第一歩は、とにかく手元になんらかのデータのマスターを置かないことにつきる。端末上にマスターデータを置いていると当然新しい環境を用意する際にデータ移行が必要になる。移行をしないためにはこれらを手元に置かないようにする。書類はGoogle DriveやNASに入れる、ソースコードは全てGitHubに上げておく、などなど。現代では機密情
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化
約1年前にGitHub Copilotのテクニカルプレビューを開始したとき、私たちはこのツールがソフトウェア開発者の役に立っているのかを明確にしたいと考えていました。アンケートと実験を組み合わせた調査を実施したところ、予想していた回答と予想外の回答の両方が導き出されました。 私たちは日々、より少ない労力でより多くのことを実現するために、ツールを活用したり工程を習慣化したりしています。ソフトウェア開発においては、作業の効率化のために非常に多くのツールとテクノロジーが生み出されており、それらを選択することに疲れを感じるほどになっています。2021年にGitHub Copilotのテクニカルプレビューを開始したとき、私たちは、これによって開発者の生産性が向上するだろうという仮説を立てました。実際、初期のユーザーから「生産性が向上した」という報告がありました。リリースから数か月後、私たちは、定量的
外部パートナーとのAPI連携時に気をつけるポイント - 10X Product Blog
はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境
放っておくと進まない仕事を進めるために - id:onk のはてなブログ
はてなは 7 月決算なので期のふりかえりをやっていたんだが、今期は「放っておくと進まない仕事を進めるために、時間を確保する」ことで進むようになった期だった。ちなみに前期は「放っておくと進まない仕事を進めるために、締切を設定する (強制力を持たせる)」ことで進めようとしていた期だった。 放っておくと進まない仕事とは、優先順位が低い仕事のこと。やってもやらなくても直ちに影響はない仕事をどうやったら進められるのかというのは長年ずっと課題だったが、やっと自分の中である程度答えが見えてきたかもしれないので記しておく。書き出してみたら至って普通なんだけど、以下をやっている。 見積もる 締切を作る 締切を宣言する 時間を押さえる 見積もる チームで見積もりを行い、まずはタスクの重さや実現方法についての共通認識を持つ。 タスクを分解する、とも言い換えられる。やるべきなんだけど気が重い仕事はとにかく分解しま
フロントエンド技術負債解消WG「除雪部」を立ち上げた話 - STORES Product Blog
はじめに hey のネットショップ開設サービス「STORES」 の開発フロントエンド組織で EMをしています、 daitasu と申します。 2022年の上半期、私たちのフロントエンドチームで「除雪部」という技術負債解消ワーキンググループ(以下、WGとします)を立ち上げました。 この記事では、「除雪部」とは何なのか、なぜ設立したのか、何をしているのか、半年間の振り返りをご紹介します。 「除雪部」とは 除雪部は、フロントエンド内で、通常のプロジェクト(以下、PJTとします) と並行して、有志数名で集まり、技術負債の解消をハンドリングするWGです。 フロントエンド関連で負債に感じている課題を集約し、優先度付け、必要な各所への連携やタスクの分解をして、「負債を各メンバーが対応可能な状態まで落とし込むこと」、「負債の解消を一歩でも前に進めること」を役割として動いています。 なぜ設立したのか STO
スクラムでベロシティを安定化するにはどうしたらよいか - 貳佰伍拾陸夜日記
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デプロイ今昔物語 〜CGIからサーバーレスまで〜 / The deployment technics
知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか？ / PHPerKaigi 2020
AWSの「隙間」を埋める隙間家具 OSS 開発 / AWS DevDay Tokyo 2019
LINE新銀行の勘定系システム、富士通との開発頓挫 - 日本経済新聞
仕事でバックエンド開発するときに考えていること / GEEK-SAI-2022-AUTUMN-yanyan-Backend-Study
PayPalエンジニアリングチームがプレモーテム分析を実装
