ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
この記事は、以下サイトの機械翻訳です。 何を作るか（あるいは次に何を作るか）を決めることは、プロダクトマネージャーの仕事の中で最も重要な部分の一つです。インパクトを与えるチャンスは何度もありません。だからこそ、賢く選択して、チャンスを最大限に生かすことが重要なのです。 プロダクトの優先順位を決めるには、さまざまな要素を考慮する必要があります。しかし、何よりもまず、お客様の真の問題を解決することを優先しなければなりません。多くの企業では、このプロダクト開発の基本方針が守られていません。おそらく、価値よりも革新性を優先しているからでしょう。私たちは皆、自分たちが最先端の先駆者であると他人に思われたいと思っていますが、市場が求めているのは必ずしもそうではありません。 市場が求めているのは、すでに機能しているものを適度に改良することだったりします。究極のゲームチェンジャーを追い求めるのではなく、フ
トヨタはハードウェアアジャイルをどう強みにしているか？ 自動車開発におけるスクラムとモブの実践 - Agile Journey
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
開発爆速化を支える経営会議や週次定例の方法論 〜LayerXの透明性への取り組みについて〜 - LayerX エンジニアブログ
こんにちは。松本(@y_matsuwitter)です。GWはカレーを沢山作っていました。スパイスから作るカレー、思ったよりも手間が掛からないですね。インド料理にハマる波が数年置きにやってきます。 本日は、最近いくつかのイベントでの議論を通じて感じた、開発組織づくりにおいて見られる共通のパターンについて触れつつ、LayerXが意識している取り組みを書いてみようと思います。 最近toBなスタートアップ各社と会った中で、組織の指向性に色々と共通の傾向が見られる気がする。 ・透明性への狂気的な取り組み、公開だけでなく情報整理とチャネル整備 ・採用は技術力そのものよりもカルチャーフィットと学習意欲（もちろん両立が理想だけども） ・開発では速度を最も意識— 松本 勇気 | LayerXはSaaSとFintechの会社です (@y_matsuwitter) 2021年4月22日 各社で見られる最近の組織
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに
ryuzeeさんの記事で紹介されていたスクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。 38個すべてに一度に答えていこうとするとかなりハードですが、1日1個ずつこつこつと、回答をしていっています。 この回答は、年月を重ねることに変わっていくかもしれません。 2019/12時点の回答がこちらです。 スクラムマスターの役割について 1. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ スクラムマスターはプロセスを順守する・させるためだけの存在ではありません。プロセスを順守する行為は「どのように行うのか（How）」を守らせることに注力してしまいがちですが、「なんのために行うのか（Why）」のほうを重視すべきです。 アジャイルにおけるチームの成功は、「よいプロ
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
2023年も様々なフリーゲームやインディーゲームが登場した。ゲームアツマールの終了や投票企画フリゲ20XXの最終回などフリーゲームを取り巻く環境には少なくない変化のあった1年だが、その中にあっても創作の灯は途絶えることなく続いていく。これからも人々を楽しませる作品が生まれてくることを願うばかりである。 本稿では、もぐらゲームスの執筆陣が、2023年にプレイしたゲームの中で特におすすめできるフリーゲーム・インディーゲーム17作品を一挙特集する。 各執筆者が2023年に遊んだ中で心に残った作品の数々を紹介していくので、気になった作品があればぜひ手に取って遊んでみていただきたい。 昨年の記事はこちら。 もぐらゲームス執筆陣の選ぶ 2022年おすすめフリゲ・インディゲーム19選 17に咲ク！ 『17に咲ク！』はしょーへー90.9氏が制作したブラウザ上でプレイするRPG。2023年4月29日より同氏
Nuxt.js で開発されていたAI受診相談ユビーのフロントエンドを Next.js で作り直しました。 まだまだ仮説検証を繰り返すフェーズのスタートアップのため、機能開発を止めて一気に置き換えることはできず、機能ごとに少しずつ置き換えてリリースをしました。結果、5人のプロダクト開発チームによる機能開発と並走して、全体の移行を1人で1ヶ月の短期間で終わらせることができたので、その意思決定や過程、工夫を紹介します。 移行前の課題 まず前提として、移行前の Nuxt.js による実装は 2018 年に立ち上がったもので、当時 toC の Web サービスを持っていなかった Ubie が ほぼ 1 人の小さいチームで PoC 的に作り始めたものでした。また、当時の Next.js は今ほど多機能ではないプレーンなフレームワークでした。 これらを踏まえて、当時の状況で MVP を最速で作るための技
小中新規開発グループ (a.k.a. tara チーム) の qsona です。 tara チームでは、スタディサプリ中学講座というプロダクトを開発しており、約1年前 (2022-02) に本リリースして以来、継続してプロダクト開発を続けています。 tara チームのプロダクト開発は、基本的にスクラムの手法にのっとる形で行っています。ビジネス的な境界により分けられた3つのスクラムチームが存在します。 スクラムの運用については、それぞれの現場において悩みごとが起きがちだと思いますが、tara チームでもご多分に漏れず、うまくいっていること・いっていないことが存在します。今回は、その3つのうちの1つのチームである「学習コアチーム」において存在した、Sprint Planning に関する (あるいはそこから掘り出された) 課題と、それに対してどう対処したかについて書きたいと思います。 なお、本
Re:Backlogs というプロジェクト管理(タスク管理)ツールを OSS としてリリースしました - saino.me (kaishuu0123)
自分の Qiita 記事からブログへの転載です。そこそこいいものが作れたなぁと思っています (∩´∀｀)∩ qiita.com 読み方: Re:Backlogs (リ・バックログ) https://github.com/kaishuu0123/rebacklogs 2019/12/23: 使い方の記事を書きました。 Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します 画面紹介 マスターバックログ カンバン (Kanban) プロジェクト設定画面 説明 セットアップ方法 開発動機 ソースコード 使っている技術 実装してて楽しかったところ Drag & Drop による操作と、バックエンドのソート順保持 見やすい色を自動的に決めるアルゴリズム webpacker でのパフォーマンスチューニング 開発者なりにユーザビリティを考えること 最後に 2019/01/
SmartHRの基本機能と呼ばれるプロダクトでエンジニアリングマネージャーをしている @sugamasao (id:seiunsky) です。 この文章はSmartHR Advent Calendar 2022の2日目のエントリーとして書いています。 はじめに、いくつか前提となる状態をお伝えすると、私の所属している「基本機能」プロダクトはScrumを拡張したLeSSというフレームワークを使っており、現在は6チームで1つのプロダクトを開発しています。 さらに、私は今はエンジニアリングマネージャーという立場にいますが、少し前まではこの6チームのうちの1チームに所属するメンバーでした。そのため、これ以降に記載している取り組みは私がチームに所属していた時にはじめたものという認識をしていただけますと幸いです。 テックな話題 #とは リモートワーク主体で仕事をしていると意識的に雑談によるコミュニケーシ
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合本版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの？ データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが本命なの？ 中央値と平均値 分析データ観察編 01 生産性は性癖が出る？ 生産性 02 バグを愛したソース 信頼性（不具合密度） 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間（工期） 06 ウォーターフォールってつおい？ ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08
長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog
弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン
これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。 今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。 壁1. 「相対見積もり」の考え方を理解できない 壁2. ストーリーポイントが「何を見積もる手段か」を理解していない 壁3. 見積もりをコミットメントと捉えてしまう まとめ 壁1. 「相対見積もり」の考え方を理解できない バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇
開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
はじめにSNS(twitter)でPCゲームについて追えるタイムラインを構築するとSteamレビューに関する話題が目につくことが非常に多く感じます。 「日本人の不評レビュー比率が高い！」「ウケ狙いで不評レビューを書くやつがいる！」「圧倒的好評を開発者は目指している！」等々…。 私もゲームをSteamで販売している身ですが、こういった話題は統計データの好評/不評の比率だけを見て話をしているケースやそもそもデータに基づかず感情論のみで議論されているケースが多いように感じていました。 せっかく議論するならSNSのマウンティングの道具としてではなく、より良いゲームを作るためにユーザーがどういった点を不満に思っているのか吸い上げを行ったほうがゲーム品質向上の役に立つのではないかなと考えました。 そこで私がゲームを出している周辺環境に絞って「何故その人は不評レビューを書くに至ったか」を調べて見ると面白
「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence Advent Calendar 2022 の 15日目の記事です。 qiita.com 筆者は過去に、中〜小規模のWebアプリケーションでレガシーフロントエンドの改善作業を業務でやっていた。その経験を元に技術同人誌を作成し、それがきっかけで「レガシーフロントエンド安全改善ガイド」という書籍を出した。 初版から数年経ってしまい、詳細な利用技術などの説明は少し古くなってしまっているのだが、ベースとなる考え方の部分は今でも変わっていないと思う。 一方で自分自身は、その経験が他の環境でも通用するのかを試してみたくなり、転職して一年強ほど大規模なフロントエンド刷新に関わっていた。 あまりにも規模が大きいため完遂を見届けたわけでもないが、現段階でも学びや得られたものは
※ スクラムフェス仙台2023 で登壇した際の資料です。 スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。 しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。 これを引き起こすのは、スタートアップ特有の個人分担制です。 多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個
フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート
より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。 - Qiita
リモートワークでも生産性を上げる！スクラム創始者直伝の実践ノウハウを日本語化して入門者向けにまとめました。プロジェクト管理スクラムリモートワークコミュニケーションコロナウイルス はじめに 認定スクラムマスター(LSM)取得者向けに「Distributed Teams: Mitigating Business Risk in Uncertain Times」と題したウェビナーがスクラム創始者の Jeff Sutherland 氏を交えて3月に行われました。 この投稿はウェビナーの内容を噛み砕き、リモートワーク環境でもスクラムの実践がスタートできる内容を目指しました。チームリーダーやマネージャーとしてスクラムを推進している方や、これから導入を検討している方のご参考になれば幸いです。 まずは結論から リモートワークでより成果を上げる働き方は可能なの？ 可能。→ リモートチームを成功させた企業のユ
みなさんこんにちは。@ryuzeeです。 よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。 まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。 理由を順番に見ていきましょう。 1. 開発に使える時間がかなり少ないスクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。 チームによって時間は変わ
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
はじめに 研究開発チームの関です。古川未鈴さんの結婚、ニジマス大門果琳さんの卒業、uijinの解散とアイドル業界も激動の秋を迎えていますね。 2019年8月4日から5日間、アメリカはアラスカ州アンカレッジで開催されたデータマイニング領域のトップカンファレンスであるKDD2019にGunosyから北田と関が参加・発表してきました。 これまでに2つのレポートを公開しています。 data.gunosy.io data.gunosy.io 本レポートではTutorialとして開催された「Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments」の内容をレポートします。 内容は現在のA/Bテストのガイドラインと言ってもいい内容で、非常に参考になるポイントが多かったです。
なぜ今、日本に「デザイン」が必要なのか | 日本
日本企業はイノベーションを強化し、顧客との関係を再構築しようとしている。デザインはこれらを実現する上で極めて有効な手段となる。 日本の経営幹部の多くが、従来のコア事業の外に成長の源を求めるようになっている。他社との差別化と競争優位性を生み出す源として、イノベーションが果たす役割が重要視されている。イノベーションは、単に科学的な発明を意味するのではなく、顧客ニーズに新しい解決策を提供することを意味する。新しい解決策は、新しい技術によって実現されることもあれば、既存のテクノロジーを従来とは違う組み合わせることで実現される場合もある。 残念ながら、日本はかつてのトップイノベーターとしての地位を失っている。WIPO (World Intellectual Property Organization、世界知的所有権機関) が公表している2021 年のグローバルイノベーションインデックスでは、日本は1
エンジニアに伝えたい！プロダクトマネージャーの頭の中 - プロダクトをもう一段階成長させる仮説の立て方｜Tably
Tablyの小城久美子(@ozyozyo)です。 デブサミでは多くの方にチャットやTwitterで盛り上げて頂けたので大変お話しやすかったですし、何よりとても楽しかったです。ありがとうございます！ 資料のダウンロードはアンケートに回答された方への特典とのことなので、登壇内容の一部を抜粋してまとめます。ご参考頂けますと幸いです😊 どんなセッションでしたか？エンジニアからプロダクトマネージャーに転身した私が、エンジニアだった頃に知っておきたかった「プロダクトづくり」についてお話するセッションです。 「プロダクトをつくる」フローとは？ プロダクトをつくるとは、大きく2つに分かれます。上図の上側にあるプロダクトを育てていくものと、それを下支えするプロダクト志向な組織を維持することです。 上側にある、プロダクトを育てるステップとして、まずは明確なゴールを設定すること、そしてそれをもとに豊かな仮説を
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
【資料公開】ベロシティ Deep Dive
みなさんこんにちは。@ryuzeeです。 2024年1月10日〜12日開催のRegional Scrum Gathering Tokyo 2024の登壇資料を公開します。 「ベロシティ Deep Dive」ということで過去のDeep Diveシリーズの続きになっています。 過去のDeep Diveシリーズはこちらからご覧ください。 プロダクトバックログ Deep Dive スプリントプランニング Deep Dive スプリントレビュー Deep Dive セッション資料は以下になります。 結論から言うと、「ベロシティなんかにDeep Diveせず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
タスクに「〜対応」という名前をつけるのを避けたい理由 - kymmt
プロダクトオーナーを兼務する技術、あるいはその反省 - SmartHR Tech Blog
「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に答える - Qiita
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
仕事納めとスクラムの話 - imog
「終わらなかったから次のスプリントにまわそう」なんてありえない
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
もぐらゲームス執筆陣の選ぶ 2023年おすすめフリゲ・インディーゲーム17選 – もぐらゲームス
150万MAUのNuxt.js製サービスを機能開発を止めずに1ヶ月&1人でNext.jsに置き換えた話
Sprint Planning をやめた話 - スタディサプリ Product Team Blog
チーム内にテックな話題を話す場を作っておよそ半年が経ちました - SmartHR Tech Blog
「こうしてスクラムが終わってしまう」前にすべきこと
IPAマンガでわかるソフトウェア開発データ分析38編.pdf
スクラムチームがぶち当たる「相対見積もり」の壁と、私たちの乗り越え方
優先順位が口癖になる危機感 - ジンジャー研究室
Steam不評レビューには何が書かれているのか？~日本発インディーゲームの場合~｜離水ひつじ
規模感の違う脱レガシーで必要なこと - memo_md
個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
開発プロセスをインクリメンタルに改善する - 一休.com Developers Blog
A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ
“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳