フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート
DXの流れも相まって、アジャイル開発に取り組む会社が増えてきています。自社にも取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことありませんか？正しいアジャイルって...
アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏：みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 （会場拍手） 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
Findy 開発生産性 Conference における発表です
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬（え？エンジニアどうしで話して認識合ってるのに？）って反応をされるし、僕自身も（大企業っぽいかなぁ？）って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー！やっ
アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 チーム・組織にプラクティスを導入し、根付かせるために！ 116の手法を一冊にまとめた“実践”の手引き チームでのアジャイル開発には、開発技術やツールなどの「技術プラクティス」の活用が重要です。 プラクティスはそれぞれの目的や役割を意識することで効果を発揮します。しかし、目まぐるしく状況が変化する開発では、当初の目的を忘れて、プラクティスに取り組むこと自体が目的化してしまうチームも少なくありません。 本書は、チーム・組織でアジャイル開発に取り組んできた著者が、プラクティスの効果的な選択・活用のしかたについて、自らの実践経験に基づいてまとめたガイドブックです。 架空の開発現場を舞台にしたマンガとともに、チーム開発の様々なシーンで役立てられるプラクティスを、幅広くかつわかりやすく解説しています。開発現場に備えておけば、
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み / Developers Summit 2023 Summer
2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
pmconf 2023 プロダクトと事業を無限にスケールするための最強のロードマップの作り方 / The Greatest Roadmap for Unlimited Scaling your Business and Products
プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する書籍が執筆され、日本でもプロダクトマネジメントが定着しつつある。特に課題発見からMVPローンチ、PMFまでのプロセスは、アジャイル開発関連の書籍の拡充あって、充実してきていると言える。一方で、一度PMFを迎えたプロダクトを更に進化させるためのロードマップの作り方については、未だ確立した方法論があるとは言えず、世界中で議論が続いている。本セッションでは、従来のロードマップの課題と近年議論されている対策を振り返り、その上で、プロダクトと事業を無限にスケールするための新しい考え方を導入し、状況に合わせて変更可
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
スキル差があるペア_モブプロで効果的な_ドライバーナビゲータ以外のロールの分け方.pdf
スクラムフェス三河2023の発表資料
この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。 こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。 この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。 それが「ただ話す」です。 ただ話す 「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。 大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。 (1) あなたは、チームBとの”調整が必要”なことに気づきます。 (2) 立ち上がって、 (3) チームBのところに歩い
ちょっとだけ読んでから積む「積⭐️読タイムアタック」で、タワーと化した購入書籍の未読圧のプレッシャーから解放されました
Four Keysを用いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ？」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津（@KawatsuYusuke）です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。 と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ？" が大事」についてお伝えします。 私たちの開発生産性向上のはじまりと、目指すべき状態の設定 Four
【資料公開】ベロシティ 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せず、もっと重要なところに集中しろ」です。 スクラムチームの状況を何らかの数値で表したいという考え自体は尊重しますし、それが役に立つこともあります。 ただし、数字遊びをしたところでプロダクトの価値を生み出せるわけではないので、ほどほどにしましょう。 ス
mikanデザイナーの"スクラムで回す1週間"を覗いて行きませんか？｜Ayaka Nagataki
はじめにこんにちは！株式会社mikanでデザイナーをしているayataki（@ag_ayakan）です。 主に英語アプリ「mikan」の体験設計やUIデザインの作成を行なっています。 カジュアル面談などで話す際に、「mikanのデザイナーさんてどんなことをやってるんでしょうか？」という質問をよくいただくようになりました。 社外への発信が少ないこともあり、イメージを持ってもらいづらい状況にあるのではないかなと感じています。 そこで今日は、mikanのデザイナーとして働くわたしの1週間のスケジュールについてご紹介します！実際にあった直近のスケジュールを具体例に出していきます。 mikanのデザイナーに少しでも興味のある方に、具体的なイメージを持ってもらえたら幸いです🍊 それでは行ってみましょう！ [前提] 仕事の環境ほぼリモートワーク mikanのメンバーは基本的にフルリモートワークで働いて
スクラムマスターの役割はスクラムを回すだけではない ─ Be Agileを志向するサイボウズの組織改編 - Agile Journey
サイボウズにおいてプロダクト開発を担当する開発本部では、2016年頃からスクラムを開発現場に導入してきました。チームにスクラムマスターがいない状況も続いていましたが、2022年にはエンジニアやデザイナーなどと同様の「職能」としてスクラムマスターをバックアップする組織改編に踏み切っています。 ▶ 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out これまでもサイボウズの開発本部ではマネージャー職をいったん撤廃するなど、組織のあり方に野心的な取り組みをしてきました。そういった組織改編の狙いや、スクラムマスター職能化から約1年でどのような効果があったのかを、開発本部副本部長の岡田勇樹さんと、シニアスクラムマスターの天野祐介さん、スクラムマスター職能化にともなって専任となったToshinariさんの3人に伺いました。 スクラムマスターがチー
デザイナーの帽子をかぶったわたしが、プロダクト開発するうえでスクラムチームに提供したいこと / what I want to provide to Scrum teams when developing products
Scrum Fest Fukuoka 2024の登壇資料です。 プロポーザル：https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19575
関連キーワード IT部門 | ネットワーク | ネットワーク管理 | ネットワーク監視 ネットワーク内のデバイスを管理するには、単にIPアドレスを割り当てるだけでは不十分だ。クラウドサービスやIoT（モノのインターネット）の利用が増加傾向にある中で、企業のネットワークは複雑化している。そのネットワークと、ネットワーク内のデバイスを管理する仕組みが重要になってきた。 IPアドレスベースのネットワーク管理を合理化するためには、「DNS」（Domain Name System：ドメインネームシステム）、「DHCP」（Dynamic Host Configuration Protocol：動的ホスト構成プロトコル）、「IPAM」（IP Address Management：IPアドレス管理）といったネットワークのプロトコルやシステムが欠かせない。以上3つを総称した用語が「DDI」だ。 DDIのそれ
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
自分がニッチだと思っているテーマについて発表する「Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜」。ここで株式会社ノーススターの古谷氏が登壇。個人開発の“つらみ”を解消するアジャイル開発・スクラム開発のエッセンスについて話します。 古谷氏の自己紹介 古谷聡希氏：「個人開発のつらみを経営計画とスクラムの手法で乗り切る技術」です。よろしくお願いします。 今日のテーマはニッチな技術ですが、私は（ニッチな技術と言いつつも）どちらかというと王道技術のニッチな活かし方なのかなと思って発表します。なので、そのように念頭に置いて聞いてもらえたらうれしいです。 あらためまして、古谷と申します。中小企業診断士で、いわゆる経営コンサルの国家資格と認定スクラムマスターを持って活動しています。 会社員としては三井物産株式会社のIT医療の領域の関連会社の株式会社ノーススターでエ
前書き🤔これは何RIZさんという一見AIイラストレーターを装った風来のシレン廃人にそそのかされて作ったちちぷいチャレンジが多数の愉快犯たちにおもちゃにされた結果書かないといけなくなった記事です。 Stable DiffusionやMidjourney、Nijijourney、NovelAIの使い方を詳しく解説した文書は数あれど、ふだんパソコンを使わない一般の人向けまで踏み込んで網羅している解説記事って案外ないかもな？と思ったのもきっかけではある！ 書く前からわかってたんだけどボリュームがヤバいので稚拙な表現や抜け漏れ多数だ。公開後もちょくちょく手を加える可能性大だから、もし更新が気になるようであれば筆者のX, Blueskyアカウントをフォローするなり、気が向いた時にこのnoteに戻ってきてくれよな！！ しばらく前提条件を書いておくので、とっとと中身を読みたい人は飛ばしちゃってください。
『スクラムの拡張による組織づくり』を読んで、そもそも”組織をつくる”ってなんだろうなって考えた - Magnolia Tech
スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する WEB+DB PRESS plus 作者:粕谷 大輔技術評論社Amazon だいくしーさんこと、粕谷大輔さんの『スクラムの拡張による組織づくり』を読みました。 複数のスクラムチームを協業させていく手法として「Scrum@Scale」を軸に、スクラムという概念自体のおさらいから始まり、コミュニケーションを軸とした組織の作り方、運用の仕方を解説していく構成になっています。 第3章で出てくる「毎日45分で問題が解決する」というのはなかなかキャッチーな表現で、Daily Scrum -> Scaled Daily Scrum -> Executive Action Teamのそれぞれに15分という目安を作ることで、議論ではなく問題の確認と決定の場としてショートに実行するものである、という定義が明確で分かりやす
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
SaaS型Webサービス｢カオナビ｣のチーム開発でPackage by Featureを取り入れた話/Implementing Package by Feature in kaonavi
「DevOps」とは？〜超基本から実践のポイントを解説〜|インシデント管理プラットフォーム│PagerDuty
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である - mtx2s’s blog
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく
組織の話が好物なので色々読んできたのですが、結局ティール組織はよくわからないままでした。最初に本を読んだのが5年も前なんですね。 ティール組織は面白くなかったというか、個人的にはそこまで響かなかった。歴史書読んでるみたいな感覚で……。リーンスタートアップは部署レベルで実践できそうだけど、こっちはそうは思えなかった。— 絶賛異世界転生中 (@Kengo_TODA) July 6, 2018 で、自分なりに考えた結果、大きく2点においてよくわからないのだと思ったのでメモしておきます。 以下、「ティール組織」と書いた場合は書籍「ティール組織」を指します。なお昔読んだ本を読み返しながら書いているので読み飛ばしによる誤解などはあるかもしれませんし、ここ5年で新しい発見があったとしても私はそれをキャッチアップできていないことにご留意ください。 組織に人間の弱みを補う機能を求めたいのに、スキル常時発動を
今回のAgendは、”組織開発するマン” こがねんさんに『1on1』についてお聞きしました。 こがねんさんこと小金 蔵人さんは、ZOZOで組織開発の部門長として活躍する傍ら、個人でもさまざまな企業の組織づくりに貢献しています。 もともとはヤフー（現：LINEヤフー株式会社）で1on1文化と出会い、これまで1on1の活用を深く考えてきたこがねんさんは「いい1on1をやる必要はない」と言い、どのように1on1を捉えるとチームコミュニケーションが良くなるのかを教えてくれました。 上司・部下側どちらにとっても発見のある「1on1の本質」が語られていると思います。ぜひ最後まで読んでいただければ幸いです。 株式会社ZOZO 人自本部 組織・人材開発部 ディレクター。 1998年に味の素株式会社に入社。2006年にヤフー株式会社（現・LINEヤフー株式会社）に転職。2016年に人事部門に異動後、一貫して
開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。 そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。 吉羽氏のセッションの内容をダイジェストで紹介しましょう。 本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は前編です。 これから「ベロシティ Deep Dive」ということで「ベロシティ」についてお話をしていきたいと思います。 ベロシティを使っているっていう方、会場にどれぐらいいますか？ （手が挙がる） 結構多いで
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『晩餐歌』が爆発的ヒット tuki. 15歳の等身大インタビュー完全版 音楽活動は「ゆる～く趣味として」 | めざましmedia
アジャイル勘違い集 (2024) | Agile Studio
アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
組織をスケールさせるための Four Keys とチームトポロジー
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
すぐ使える Cloudflare Workers！
開発チーム間の情報を遠回りさせてる - Mitsuyuki.Shiiba
【2024年】ITエンジニア本大賞まとめ - Qiita
開発プロセスをインクリメンタルに改善する - 一休.com Developers Blog
チーム間コミュニケーションにおける「ただ話す」のすすめ - SmartHR Tech Blog
QAエンジニアがSMに憧れてしくじった話
「DNS」「DHCP」「IPAM」をまとめた「DDI」とは何か？ なぜ必要なのか
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント
個人開発が続かない理由は「時間」「戦略」「気力」「孤独」 4つの“つらみ”を解消するアジャイル開発・スクラム開発のエッセンス
AIイラスト始め方の網羅的案内 2024年版 / だいたい未経験者向け｜かいりん
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化
ゼロから始めるシステム障害対応フロー - Qiita
ティール組織わからん、を掘り下げる - Kengo's blog
1on1マスターガイド ―――組織開発するマン・こがねんさんに聞く「ほんとにすごい1on1」
ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）