ここ最近は開発が佳境で、同僚とかなりの頻度でペアプロ（ペアプログラミング）（ここではペアオペも含む）している。主にTypeScriptを使ったNext.jsのコードを書いているが、もちろん設計もするし、もうちょっと大きいアーキテクチャみたいな相談もする。DBスキーマをどう割るか・・・みたいな話もしている。たいていみんな出社していないので、リモートでこれをやっている（国内だし全員日本語話者なので時差とかはない）。 いちおうどの面子もペアプロの心得はあったのだが、当初は微妙にギクシャクしたり、疲れきったりしていた。そんな中、同僚がRGST2025に行ったりする中でうまくいくようになってきたので共有する。 以前はペアプロやる？と聞かれるとウゲ〜面倒だな、とっとと終わらないかな、と思っていたのだが、今は完全にお気に入りの道具箱に入っていて、飛び出す機会を伺っている。 また、他にもオススメの知見があ
こんにちは！アルダグラムでレポートチームのエンジニアをしている志茂です。 レポートチームでは、お客様が利用されているExcelファイルをKANNA上にアップロードし、 Webから編集できるような機能を開発しております。 今回の記事のスコープ スクラムの話をする際に、取り組んでるかそうでないかの話をよく聞くのですが、 実際に導入した上で、今のチームには効果的だったが、前のチームにはあまり効果出来でなかったような、具体的なケースを前提とした話はあまり聞かないような気がするので、自分が過去に所属した開発チーム(現職も含め)の体制を振り返って、帰納的にこんなケースだとスクラム効くんじゃないかという話をしたいと思います。 なのでアジャイルサムライのような教本に載っているような話ではなく、あくまで個人の体験として、具体でこんなケースだと結構良かったなという体験談をまとめたものになります。 スクラム開発
ノーコードAI開発ツール「Node-AI」のプロダクト開発チーム（以下Node-AIチーム）は、 2024年1月から1年間採用していたLeSSでの開発体制を見直し、1チームによるスクラム体制で再出発しました。 本記事では、その背景についてご紹介します。 はじめに LeSSの課題 原因1 原因2 課題のまとめ チーム体制変更の検討 調査と決定 狙い 調整 今後に向けて おわりに はじめに こんにちは。Node-AIチームのスクラムマスター 中野と申します。 もともとはNode-AIの開発者でしたが、前任者の異動を機に、スクラムマスターに挑戦しています。 得意な分野はデータ分析や機械学習で、プロダクトに関連するログデータの分析にも取り組んでいます。 さて、Node-AIチームは2024年の1年、LeSS（Large-Scale Scrum）を採用しスクラムを運用していました。 確かに最初はうま
どうも、ばやしです。 先日@ryuzeeさんがこんな記事書いてましたね。 www.ryuzee.com 記事の内容に関して同意しかないので、自分も最初はKPTをやるけどそのうちやらなくなる理由を書いていきます。 なおレトロスペクティブの手法はファシリテーターの振る舞いで効果効能が変わると思うので、ここから書く話はあくまで自分がファシリをする場合の話です。本記事内で登場する「KPTは」という表現は「(私がファシリする)KPTは」の短縮表現なのでご承知おきのほどお願いします。 KPTから始める理由 わかりやすいから シンプルでいいですよね。ルールも簡単でレトロスペクティブのファシリをしたことない方でも取っ付きやすいです。また業務改善感が強いのがウケが良い理由のひとつだと感じています。業務中のMTGなんだから、業務が改善されるようなMTGをしようよという心理的な圧は多少なりともありますよね。 チ
「しかたないスクラム」じゃないアジャイル開発を求めて はじめまして。1月からカミナシでエンジニアリングマネージャ（EM)を担当している @daipresents と申します。 カミナシでは新規事業開発のEMとして、絶賛全力で開発を支援しています。カミナシはとても現場に近い開発環境なので、ご興味のある方はぜひカジュアル面談 をお願いします！ この記事では、僕が関わる「新規事業開発」で実際に行われている「開発プロセス」と、そこに行き着いた経緯や意図をまとめたいと思います。タイトルにあるように、チームは「スクラムじゃないアジャイル開発を求めて」きたように感じています。 チームの立ち上げ期 僕は10ヶ月ほど前から業務委託として参加しており、現在のチームに入る前に、別のチームの支援も行っていました。そこではスクラムが採用されていて、試行錯誤しながら自律したチームを目指していました（今もがんばっていま
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません
安全最優先ゆえの新技術導入に慎重な体質 関電システムズは関西電力100％出資の子会社として、関西電力向けシステム開発を専門とする機能子会社だ。2019年4月より関西電力と関電システムズの合同でDevOps推進が始まったが、当時の関電システムズと関西電力の関係は、IT部門再編に伴い役割分担が大きく見直された直後であったこともあり、西内氏が「完全なる親子関係」と振り返るほど強い上下関係だったという。 株式会社関電システムズ テクニカルラボ DevOps推進グループ テクノロジスト（プロフェッショナル）西内 慶子氏 そのため関電システムズの開発体制は決められたことを計画どおり進めていくウォーターフォール型が基本方針であり、技術面では「枯れた技術」の使用が推奨されているなど、新技術の導入にあまり積極的ではなかった。 こうした体質は以前から課題認識されており、関電システムズではDevOpsの推進前に
スクラムガイドをきっかけに「プロダクトエンジニア」の意味を考え直してみたこの記事はニーリーアドベントカレンダー2024の17日目 その1の記事です。 こんにちは、ニーリーのプロダクトエンジニアのりん（@TWBMT）です。 「いいや、限界だっ、買うね！！！」と心に決めてブラックフライデーに臨んだら欲しかったモニターが売り切れていました。悲しかったです。*1 最近、地元のスクラムコミュニティに参加した際に改めてスクラムガイドを読む機会がありました。 スクラムガイドには「プロダクト」という言葉の定義が書いてあり、その定義を基にすると「プロダクトエンジニアってこういうことなのかもな、普段使いしている「プロダクト」という言葉の解像度が上がって面白いな〜」と気づくことが多々ありました。 なので、今回はその話を書いていってみたいと思います。 プロダクトエンジニアというロールの面白さが少しでも伝わると嬉し
この記事では、僕が所属するチームで取り組んだスクラムの改善とその成果についてまとめています。 スクラム上手くいかない...という方の参考になれば幸いです。 課題 チームで話していて、下記の課題を感じていました。 スプリントレビューでスプリントゴールの実績を確認しているが、レビュー時点でそのスプリントは完了しているので、ゴールが達成できない場合にリカバリーができない スプリント中に スプリントゴールの達成率を上げるように各メンバーが行動できるようにしたい 上記の目的を果たすためにデイリースクラムがあるべきで、上手く機能していなかった やったこと デイリースクラムで、各メンバーのタスク確認をベースにしていたところを、スプリントゴールをベースにするように変えてみました。 （変更前）〇〇さんのタスクの進捗はどうですか？ （変更後）〇〇機能のスプリントゴールは達成できそうですか？ 狙い メンバーがス
アジャイルに取り組み始めると、必ず出てくる声に「ミーティングが多い、時間が長い」というものがある。プロダクトづくりでも出てくるし、組織アジャイルでもほぼ必ずと言って良いほど出てくる。 こうした声の流れあるいは背景には「ミーティングなんて無駄」という、会議=悪しき存在という考えが存在している。無目的で、無用なミーティングなんて、私も撲滅されれば良いのに、という立場を取るが、このことと、先述の状況は非なるものである。 ほとんどの場合、ミーティングの回数が多くなるのも、時間が長くなるのも、ファシリテートの問題だからだ。つまり、アジェンダ設計から、進行まで、内容のほうの問題だ。チームの「場」自体は必要であるし、一定のコストをかけて行うこともある。スクラムイベントはそちら側の話だ。 例えば、アジェンダがなければ、何をどこまで話すのかが分からないから、ミーティング中の濃淡をつけられず、時間切れで、おか
この話の重要なポイントは、 会社全体の機械をフルパワーで製造したほうがp2の製造能力は下がり、リードタイムも悪化してしまう ということである。そして、 フルパワーで製造してしまうほうが余計な在庫を持ってしまい、在庫コストも発生する ということである。したがって、ボトルネックを最初に特定し、そこから逆算ですべてを考えろ。というのが、制約理論の本懐である。 非ボトルネックの非経済性 ここには、もう1つの学びがある。 ボトルネックの処理能力を超えて、非ボトルネックを働かせるな。休ませろ。 ということである。 p2の製造ラインのみを取り出して考える。この時、Aを20個/時のフルパワーで製造する。しかし、Cが5個/時でしか製造できないため、Aは15個/時で在庫を作り続け、在庫の管理コストが発生し、非経済的になる。 また、フルパワーで製造した場合の、Dにかかわる部分だけを取り出してみる。Dは、B2から
こんにちは。freee人事労務でQAエンジニアをしているsaeです。 freee QA Advent Calendar2024の3日目です。 私は長いことSIerとしてPM/ITSMの道を歩んできましたが3年前にQAエンジニア（以下、QA）にキャリアチェンジしています。そして2024年の9月にfreeeにQAとして転職してきました。 アジャイル開発にとびこんでQAという職種に出会った当初、色んなことの曖昧さに戸惑いました。スクラム開発では職能の明確な線引きはないし、QAに求められる技量も見渡す限りチームによって様々。自分のスキルでどうやって組織に貢献して行ったらいいんだろう...？ と悩みはじめて3年目に突入... 今日は「アジャイルQAってなんだ？をみんなで考えた話」というタイトルで、freeeのQAにお悩みをぶつけて見えてきた”アジャイルQA像”と”QAのキャリア展望”をまとめてみまし
TOPインタビューアジャイルの基本「動くものを速く届ける」を愚直に守る。それを実現するための開発プロセスの工夫とは【UPSIDER VPoP 森大祐】 アジャイルの基本「動くものを速く届ける」を愚直に守る。それを実現するための開発プロセスの工夫とは【UPSIDER VPoP 森大祐】 2024年11月6日 株式会社UPSIDER VPoP 森 大祐 株式会社UPSIDER VPoP。新卒で株式会社ワークスアプリケーションズに入社後、会計システムを中心として、大手企業のERP、業務システムの開発をリード。いくつかのキャリアを経て、PKSHAグループにて複数のAI SaaSを立ち上げ、それらのプロダクト企画統括を務める。2023年に入社した株式会社UPSIDERではVPoPを務める。 X Notion 法人向けクレジットカード「UPSIDER」をはじめとする金融サービスを提供する、株式会社UP
この記事では、NeWork の開発チームがフルリモート環境でアジャイル開発するにあたり個人的に重要だと感じた部分を紹介します。 目次 目次 はじめに 背景 NeWork のチーム構成と動き方 コミュニケーションの工夫 オンラインの人を取り残さない各種ツールの利用 各種打合せ アイデア出し・情報共有・レトロスペクティブ 開発作業 話しやすいチームの文化づくり オープンな打合せ 話しかけやすく・呼び出しやすい環境 常に会話できることで雑談 データでみるコミュニケーション量 まとめ おわりに はじめに こんにちは、NeWork 開発チームの加藤です。私は普段、オンラインワークスペースサービス NeWork の開発エンジニアをしています。 NeWork は、手軽に話しかけることを重視したオンラインワークスペースサービスです。従来の Web 会議ツールとは異なり、話したいメンバーとすぐに話すことがで
2024/09/28「XP祭り2024」登壇資料 https://confengine.com/conferences/xp2024
先日「アジャイル入門」的な内容でお話しする機会があったのだけど、その中で「アジャイルかどうかは、どうすればわかる？」ということに悩んでいる方が多く、「難しいな〜」と思いながら以下のリストを（一つの提案として）ひねり出した。 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？ 毎日、学んだことを計画に反映し、最善の計画に更新しているか？ 計画変更のコストは、ゼロ（に限りなく近い）か？ 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？） 「これが正しい指標だ」と言うつもりはまったくなく*1、あくまで僕がこれまで学習や実践を重ねてきた中で、「このへんちゃうかな〜」と考えた提案であり、試案だ。 あくまで、「取り組んでみているけど、手応えがない」とか、「アジャイルできてる気はするけど、本当にそうなのか知りたい」といった悩みに
IT Leaders トップ ＞ テクノロジー一覧 ＞ システム構築／プロジェクトマネジメント ＞ 本当にアジャイルになるための処方箋 ＞ なぜ、アジャイルがうまくいかないのか？：第2回 システム構築／プロジェクトマネジメント システム構築／プロジェクトマネジメント記事一覧へ [本当にアジャイルになるための処方箋] なぜ、アジャイルがうまくいかないのか？：第2回 2024年9月19日(木)保坂 隆太（Gran Manibus CTO兼マネージングディレクター） リスト 「アジャイル（Agile）」の必要性と必然性は、テクノロジー関連の仕事に携わる人々の間で認知されているが、その実践・活用となると十分に進んでいるとは言いがたい。アジャイルはこれからの社会を築く中核であり、進化するテクノロジーを活用する唯一の方法であり、その定着は極めて重要である。本連載では、北米と日本の経験を基に、日本でアジ
はじめに 私はスタートアップを中心にWebエンジニアをしながら、アジャイルの展開をしています。いろいろな会社のいろいろなチームでアジャイルの展開をしてきました。今所属しているHITOTSU社ではVPoEやVPoTをやらせて頂きながら、開発エンジニアやスクラム寄りのアジャイルコーチをしています。 大体どのチームでも同じような話をさせて頂きまして、スクラムを始めるチームやスクラムが上手く回っていないチームに対して、アジャイルの価値観やマインドを理解せずに盲目的にスクラムイベントなどを実践するのは止めようという話をします。 まずアジャイルってなんだっけ 基本的にはアジャイルソフトウェア開発宣言(アジャイルマニフェスト)やアジャイルソフトウェアの12の原則）に則っていればアジャイルと言えます。 アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/m
スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
