ソフトウェアのリリース頻度が上がるとなぜ嬉しいのか、どう実現するのか : 『入門 継続的デリバリー』に絡めて - TechとPoemeの間
ソフトウェア開発において、リリース（出荷）をどの程度の頻度で行うかには、様々な考え方がある。 ここでは、話を単純にするために、古典的な3層ウェブアプリケーションを題材にして考えてみよう。 リリースをどう捉えるか そもそも、リリースを通じてソフトウェアに変更を加えることには、リスクが伴なう。それまで「問題なく*1」動作していたソフトウェアに変更を加えることで、その状態が損なわれる可能性がある。事なかれ主義に走るのなら、うまく動いているソフトウェアにわざわざ手をいれる必要は無いのだ。 一方で、ソフトウェアのリリースを全くしないことには、新しい機能をユーザーに届けたり、これまで問題があった部分を修正することができないのも事実だ。「リリース」という行為に消極的になったり、その頻度を落とすということは、「ソフトウェアの変更を失敗する」というリスクからは自由になるが、その分ソフトウェアの成長も放棄して
「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」 - TechとPoemeの間
スクラムにて効果的なスプリントバックログを書き出すには？という話です。スクラムに則っていることを前提とします。 スプリントバックログとはどうあるものか スプリントバックログ (以下: SBL) は「スプリントに設定された目標1を達成するために必要だとチームが考えている作業の一覧」です。スクラムではこのスプリントに設定された目標を達成するために取り組むプロダクトバックログ (以下: PBL) を選定するので、SBLの大半は「PBL を完了させるために必要な作業」となります。2 PBLを完遂するためのSBLを書く ただし応用として、複数のPBLの上流となる作業が生じることもあるし、PBLとは直接関係しない作業もSBLとして扱うこともあります3。単純なPBLとSBLによるツリー構造になるとは限らないことに注意したいです。 PBLとSBLは必ずしもツリーではない 有用なSBLを書き出すことで、PB
相対見積もりが機能するために必要そうなこと - TechとPoemeの間
この1年、様々なチームを支援する中で共通して出てくる話題もなんとなく見えてきて、そのひとつが「相対見積もり」の取り組み方に関することだ。そして、テクニックの話の前に、相対見積もりに対する「発想」や「スタンス」に問題があって機能不全や逆効果に結果することが多いと思っていて、その話をしたい。 ちなみに、個人的には「相対見積もり」のことを「ストーリーポイント」と呼ぶのは好きじゃないんだけど、その話はまたどこかで。 ベロシティはスプリント計画の「予算」 1つのスプリントが終わった時にそのスプリント内で「完了」したプロダクト・バックログの相対見積もり値の合計のことを「ベロシティ実績」と呼ぼう。次のスプリントを計画するときに、直近の数スプリントのベロシティ実績から、次のスプリントで実現できそうなベロシティを予想する。例えば直近最大5スプリントの平均値をこのスプリントの予想ベロシティとしよう。スプリント
「アジャイル」の入り口に立つ / Entrance for "Agile"
2022-06-17 に非公開の勉強会で行った講演のスライドです。 アジャイルマニフェスト https://agilemanifesto.org アジャイルマニフェストはどう生まれたのか https://kawaguti.hateblo.jp/entry/20110213/1297531229 50分でふりかえるアジャイルムーブメントの歴史 2017年版https://www.slideshare.net/fkino/brief-history-of-agile-movement-2017 Modern Agile https://modernagile.org/ アジャイルの「ライトウィング」と「レフトウィング」https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html 『More E
Re: エンジニアリングマネージャーとして会社にジョインするのは難しい - TechとPoemeの間
6月から、 株式会社ココペリ というところで働いています。 そういえば6月からこんな会社で働いています (Twitterに書いてなかった pic.twitter.com/C67PL4ARrb— むらみん (@Mura_Mi) June 15, 2021 mobile.twitter.com これまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。 ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の
Rust についてカジュアル面談で頻繁に訊かれる質問と、それに対する個人的な回答 - CADDi Tech Blog
エンジニアリングマネージャーの村上 (@mura_mi) です。採用関連で面談に出ることが多いのですが、大体7割くらいの確率で 「なんで Rust 使ってるのですか？」「Rust 使っててどうですか」と聞かれるので先回りして書いておこうと思った記事です。 なんで Rust を選んだの Rust をエンジニアリングチームの武器の中心に据える意思決定がされたのは私の入社前ですが、伝え聞いている話しと自分の解釈を混ぜ合わせた話を書きます。 「データ指向アプリケーションを堅牢に作るのに必要な型システムを求めたこと」と、「キャディがもともと C++ の会社だったこと」の2つが、キャディが Rust を使っていることの背景にあったのだと理解しています。 後述しますが、キャディが 原価計算システム やサプライチェーン・マネジメントシステム を Rust を使って開発しはじめたのは、2019年の中頃だった
「良いチーム開発」を実現するための「組織的学習」と「自己組織化」の話 - CADDi Tech Blog
こんにちは。CADDi でエンジニアリングマネジメントをしている村上です。 この記事は CADDi Advent Calendar 2日目の記事です。昨日は、いなむさんによる C++20 Approach to Units of Measurement でした！ キャディでは、メンバーが持ち回りで発表する勉強会「STUDDi」と、特定領域について講師役を設定してシリーズ物でレクチャーを行う「STUDDi ゼミ」の2種類の勉強会をそれぞれ週1回のペースで行っています。 これまで「インフラ知識」や「ドメイン駆動設計」について扱ってきた「STUDDi ゼミ」ですが、私が9月に4回に渡って紹介したのが「良いチーム開発を実現するためのアジャイル」というテーマでした。その内容の一部として、より良い "チーム開発" を実現するために必要な「組織的な学習」と「自己組織化」について話したことをダイジェストで
とりあえず 2020年版の Scrum Guide を読んだのでざっくり感想 - TechとPoemeの間
www.scrumguides.org Product Goal という新要素。3つの作成物である Product Backlog, Sprint Backlog, Increment にそれぞれ Product Goal, Sprint Goal, Definition of Done という "Commitment" を設けようという話。 Product を構築する上で、そのプロダクトをなぜ作るのかを意識しないことってそんなに無いとは思う。 けれども、Product Goal が Product Backlog に記載されていることで、「なんとなくこの Product Backlog Item をやりたい」という寄り道をせず、Product Goal の達成のために何をするかに思考を集中させるのだよ、という矯正ができるのは良さそう。 実際、いい感じに Scrum の Sprint がワ
2020年秋、エンジニア職の評価制度運用を改善した話 - CADDi Tech Blog
キャディのテクノロジー本部でエンジニアリングマネジメントをしている むらみん (@mura_mi) です。 Tech Blog ではありますが、技術者をマネジメントする立場として、最近取り組んだ 評価制度の改善についてご紹介します。 大事な話を先に！ キャディでは、各領域のソフトウェアエンジニアのみならず、 エンジニアリング・マネージャーも絶賛採用中です!! この記事で紹介しているような、エンジニアリング職メンバーの生産性やキャリア開発に直接関わるような仕事を日々頑張っています。少しでも興味をお持ちいただけたら、当ブログ右上のリンクや、Wantedly の求人記事からカジュアル面談申込みいただけると幸いです。 状況 キャディには "HELIX" という人事評価制度と, ミッショングレード制度があります。 https://twitter.com/yushirodesu1/status/126
突貫工事な Firebase Functions の負債を返していこう！まずは宣言的バリデーションと機能テストを導入した話 - CADDi Tech Blog
はじめまして。むらみんです。CADDi に入って最初に着手したコードを書く仕事で色々とハマったのでまとめておこうかと思います。 コンテキスト CADDi では、顧客から受注した製品の製作フロー管理 (サプライチェーン管理といいます) を営業系 SaaS を用いて行っています。その中で、実際に部品の加工を行っていただくサプライパートナーへの発注は、SaaS の画面上に設置したリンクから Firebase 上にホストしたウェブアプリと Firebase Functions を通じて帳票発行を行う外部システムの API を呼び出すことで実現しています。 この Firebase Function で実現している API は、TypeScript で書かれた Express を用いた一般的な REST API です。 きっかけとなった開発案件 本来は顧客との営業活動管理を目的とした SaaS をサプ
ありふれたもの、未だ見ぬもの: FOLIO プロダクト開発の現場から
FOLIO 開催のイベント「Scramble! #3 FOLIO 流 複雑なドメインとの戦い方」で行ったトーク「ありふれたもの、未だ見ぬもの: FOLIO プロダクト開発の現場から」にて利用したスライドです。
FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬 - TechとPoemeの間
この記事は何 昨日， Engineering Manager Advent Calendar 2018 にて 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました．その記事の続編かつ実践編として，本記事では， FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し，課題を抱え，その解決のためにどのようなアプローチを取ってきて，更にその後どのような課題に取り組もうとしているかを紹介しようと思います．自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので，その点はご留意ください． この記事は, FOLIO Advent Calendar 2018 14日目の記事です． adventar.org この記事は何 βリリースまで: 職能組織 プロジェクト体制 組織組成においてプロジェクト
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン
社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み - TechとPoemeの間
今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。 この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。 adventar.org 組織の「100人の壁」 自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアま
Head First LeSS
以下のような状況で実施した LeSS の紹介を行う勉強会の資料です． * 参加者は15名程度の希望者 * 1時間で行われる講習会 * 参加者の半分はスクラムの基礎的な知識を学んだことがある * イテレーション開発はみんな経験がある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムにおける「完了」と「出荷」の話 / About Definition of Done
スポニチ面担さん on Twitter: "【#プロ野球】#日本シリーズ 現地観戦のハマの面担に、代打（今日は忙しかった）G党面担です。 大興奮のハマスタを一気にどうぞ！ #baystars #SoftBank https://t.co/jSU3E5OFSM"
Scala と Microservices でつくる 証券会社とスタートアップ / FOLIO in JJUG CCC 2018 Fall - Speaker Deck
Scala でつくる証券会社とスタートアップ / Securities and Startup with Scala - Speaker Deck
スクラムマスター、アジャイルコーチはどう組織をつくるのか？ 現場に求められる組織論の実学ーFOLIO 村上 拓也氏 - Forkwell Press