『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
『Lean と DevOps の科学』って教養ないと理解できないじゃん！っていう話 - Qiita
今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか？ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。 本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。 目次 初めに GW中に読も
「撤退はしないくせに投資もしない」はインパール作戦みたいなもの 吉羽龍太郎氏（以下、吉羽）：さてさて、あと5分ぐらいなので、最後の「プロダクトや機能を終了する」という話をして、終わりにしたいと思います。これ、僕らは散々言いますよね。もう口酸っぱく言いまくるという感じかな。 「プロダクトをやめられない」とよく聞きます。だから人が分散しちゃって勝負にならなくなっちゃうというのが、すごくありますよね。薄い人数のチームがいっぱいあって、どれも塩漬け、プラス、運用対応をちょっとだけしてみたいな。 それで、「メンバーのモチベーションが上がらないんですけど、どうしたらいいですか？」、いや、そりゃ、そんな塩漬けを運用させていてメンバーのモチベーションが上がるんだったらやり方を教えてくださいよという感じだと思います。これはもう（プロダクトを）捨てろという話だと思うんですが、それ以上の話はなにかあります？ 及
はじめに こんにちは、土屋と申します。バニッシュスタンダードで社内システム保守とスクラムマスターを担当しています。最近の趣味は早朝にゼルダの伝説ティアーズオブキングダムをプレイすることです。なかなかハイラルが平和になりません。トーレルーフ!! ところでみなさんスクラム開発しっくりきてますか?完璧ですか?心酔してますか? 僕は開発メンバーとして何度かスクラム開発を経験してきましたがどうもしっくりきませんでした。ウォーターフォールやデスマーチしていたあの頃に戻る気はないけど、とはいえ良さが理解できない。こんな印象が拭えないままスクラムマスターになってしまいました。 でも。こんな僕でもスクラム開発とちょっとだけ仲良くなれた気がしてきました。スクラム開発と仲良くできない、しっくりこない、そんな方に向けて1つの情報になれば幸いです。 スクラムマスターになった経緯 昨年末、スクラムマスターだった dk
初学者のためのアジャイルスターターキット/Agile starter kit for beginners
アジャイル開発に初めて触れる人が基本的なポイントをおさえるための資料です。 アジャイルチームに初めてジョインする方、アジャイルを導入している企業に入社した新入社員、などが読むことを想定しています。 2024.05.16 イニシャルコミット 2024.05.19 アイゼンハワーマトリクスの緊急度が反転していたバグを修正
海外版のピザ屋のデモ 森正弥氏：海外版のピザ屋のデモを流せればと思います。英語がちょっと流れますが、こんな感じです。 ピザ屋に店員のAIアバターがいて、お客さんが来て……お客さんがだいぶぶっきらぼうですけど（笑）、答えていくのをハンドリングして、最後はペイメントまでやるという感じでした。シナリオは一定はありますが、これは裏がLLMで、ここではNVIDIAのNeMoを使って会話をやっているので、シナリオじゃないアクションにももちろん普通に対応できます。 例えばいきなり「アジャイルって知っている？」と聞いたらきちんと答えてくれます。NeMoは英語とスペイン語がすごく得意なので、このデモは英語のデモになっていますが、日本語でも動きます。 あと、単にこれは単なるマイクロサービスのマッシュアップなので、23個ぐらいのマイクロサービスが立ち上がっていて、そんなに立ち上げるのかと思いながらやっています。
アジャイル開発やスクラムにもマネジメントは必要だ
Photo by Pixabay on Pexels.com 最近、よくお客さま向けに「アジャイル開発やスクラムにも、マネジメントやプロジェクトマネジメントは必要だ」と話すことが多い。事の背景はこんな感じ。 背景 よくあるのが「アジャイルチームは自律して動くからマネージャはいらない」という意見だ。この意見はおおむね正しいと思う。「おおむね」の理由は、マネージャという役割は自律型組織にとって必要なくなってくるだろうけど、マネジメントという仕事はなくならないからだ。 会社全体が自律型であれば、もしかしたらマネジメントすらいらなくなるのかもしれない。ただ、ほとんどの組織がそうではないのが現状だろう。よって、四半期ごとに目標設定と評価が発生するし、人材を採用したり育成する計画は必要だし、予算管理や体制変更も検討しなければならない。 こんな状況から「マネージャとマネジメント」を引っこ抜いてもうまくい
はじめに どうも、元QAのエンジニア @Syahu_Writer です。 今回は、元QAが開発チームにjoinしてから行った品質向上のための施策について紹介していきます。 大なり小なりいろいろとやってますが、代表して以下3つを話します。 ・開発プロセスの改善 ・シナリオテストケーステンプレートの改善 ・不具合の再発防止 開発プロセスの改善 以下は当初の開発フローを図に書き起こしたものです。 この図から読み取れる問題点はざっくりと、 ・すべて直列のフローだが、並列処理にしていいものも混じっている ・テスト完了レビューといった、不要で実際に行われていないものがある ・レビューのタイミングが悪く、大きく手戻りが発生する箇所がある という状態でした。 それを以下の通り修正しました。 ・並列にして問題ないものは並列にする ・不要なプロセスは削除する ・手戻りが最小限となるようにレビューを設置する ま
こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu
はじめに どうも、認定スクラムマスターの瀬尾です。 弊社ではエンジニアの支援制度として認定スクラムマスター取得の補助があります。これを利用して Certified ScrumMaster （CSM） を取得したので、その研修で学んだスクラムの基礎をまとめ、更にふ〜んとなったことや疑問に思ったことについて書いていけたらと思います！ 私が受講したのは、Joe Justice 先生の認定スクラムマスター講座です。2日間の研修があったのち、Webテストを受けて合格しました。ちなみに合格すると合格証と下のバッジがもらえます。Linkedin にも資格を登録してもらえました。 受講の背景を簡単にまとめてみる 受講前の知識量は「開発部に参画してから1年くらいスクラムの開発メンバーとして働いた」程度のものだった 3ヶ月くらい、見様見真似でスクラムマスターのような動きをしてはいた スクラムがアジャイルの具体
目次[非表示] 1.アジャイル開発に要件定義は不要なのか？ 2.ウォーターフォール開発とアジャイル開発の決定的な違い 2.1.①ウォーターフォール開発の特徴 2.2.②アジャイル開発の特徴 3.アジャイル開発の要件定義でよくある勘違い 3.1.①要件を初期段階で固定すべきだという誤解 3.2.②ドキュメントや仕様書が不要だという誤解 3.3.③すべての要件を等しく扱うべきだという誤解 3.4.④スプリント初日にすべての要件を明確にすべきだという誤解 4.アジャイル開発で要件を明確にするユーザーストーリーとは 4.1.①ユーザーストーリーの基本フォーマット 4.2.②ユーザーストーリーの特徴 4.3.③ユーザーストーリーの使い方 4.4.④受け入れ基準（アクセプタンスクライテリア） 5.アジャイル開発の基本的な流れ 5.1.①プロジェクトの計画立案 5.2.②スプリント計画ミーティング（スプ
自分が変わること。アジャイルやスクラムで自分が変わったこと。Scrum Fest Sapporo 2021
スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの
目次[非表示] 1.スクラッチ開発とは 2.スクラッチ開発とパッケージ開発の相違点 2.1.①スクラッチ開発の特徴 2.2.②パッケージ開発の特徴 3.スクラッチ開発の3つのメリット 3.1.①独自性の高いシステムを開発できる 3.2.②要件定義を最適化できる 3.3.③システム改修をしながら長期的に運用できる 4.スクラッチ開発の3つのデメリット 4.1.①他の開発手法より開発期間が長くなりやすい 4.2.②初期費用が高額になりやすい 4.3.③開発に一定の技術とノウハウが求められる 5.スクラッチ開発の基本的な流れ 6.スクラッチ開発を進める2種類の手法 6.1.①ウォーターフォール開発 6.2.②アジャイル開発 7.スクラッチ開発をアジャイル開発で進める手順 7.1.①プロダクトバックログの作成 7.2.②スプリントプランニングによる認識のすり合わせ 7.3.③スプリントレトロスペク
「NO」と言うのはメチャ重要 及川卓也氏（以下、及川）：逆に言うと、リソースが限られているからこそ研ぎ澄ます時に、どこを削るべきかというのができる。 吉羽龍太郎氏（以下、吉羽）：そう、それが振りで、「NOと言う覚悟」の話をしようかなと思っていたんですけど。 及川：あと、あれですよ。「未完成なプロダクトを人に使ってもらう覚悟」というところにつながってくるんですよね。 吉羽：そうそう、そうそう。そのあたりの話をしていけたらいいかなと思うんですけど。 「NO」と言うのはメチャ重要だなって。僕らはすごく気軽に「NOと言ってください」と言うんですけど、いざ言うとなったら、むちゃくちゃ難しいワードだと思います。 及川：そのとおりですね。でも、「NO」と言っていますよね。 吉羽：そう。自分の経験上まあまあ言っていると思うんですけど、けっこう慣れが必要な気もしますよね。 及川：そうですよね。私は吉羽さんと
その人の人生を狂わせるくらいの巻き込む能力が必要 吉羽龍太郎氏（以下、吉羽）：2つ目の「ヒトを巻き込む」という話も出ました。このペースでしゃべったら絶対終わらないので、そろそろ次のテーマにいきたいと思います。 次が今、及川さんから振りがあった、「ヒトを巻き込む覚悟」ですね。ちょっとこっちについて話していきたいと思うんですけど。 これもいろいろな話がありますよね。人といっても、自分のチームのメンバーも人じゃないですか。それから、ステークホルダーも当然巻き込む対象になってくると思うんですけど。 ユーザーに関しては、下で触れようと思うので1回置いておいて、チームとステークホルダーという観点でいうと、どんな覚悟が必要ですかね？ 及川卓也氏（以下、及川）：人の人生を狂わせちゃうかもしれないわけで。 吉羽：（笑）。 及川：スタートアップは、「俺の会社でこのプロダクトを作って世界を変えようぜ」と言って、
顧客、ユーザーの片側だけにアプローチをしているケースが多い 吉羽龍太郎氏（以下、吉羽）：あと15分ぐらいみたいなんですけど、あと2つですかね……あっ、3つだ。「ユーザーを巻き込む覚悟」「未完成なプロダクトを人に使ってもらう覚悟」「プロダクトや機能を終了する」という話にいきたいと思います。 触れているところもだいぶ多いと思うので、ちょっと順番にいきたいと思います。ここまでは人を巻き込むといっても、ステークホルダーやチームメンバーという話でした。今度はユーザーというところにいきたいと思います。 顧客とユーザーは意外と混同されがちですよね。顧客とユーザーは、toBかtoCかによってけっこう変わってきますけど、これはどういうふうに考えるといいんですかね？ お金を払ってくれる人はもちろん大事だし、使ってくれる人も大事。ここでは、ユーザーを巻き込むと言っているんですけど、お金を払ってくれる人はそれなり
Waterfall Deconstructed It’s hard to find anyone that actually defends a Waterfall process anymore. Agile methods might have their flaws, but at least they are usually much lesser flaws than Waterfall. Yet I actually meet many teams that claim to be practitioners of Agile and Lean, yet when they show me how they work, I all too often have to reluctantly point out to them that they might have the
チームに新しく飛び込んだスクラムマスターが最初にやること - Money Forward Developers Blog
こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 新しいチームにジョインするのって、ドキドキしますよね。新しい環境、新しい人々、そして新しい課題。それぞれのチームが直面している問題は異なりますが、スクラムマスターとして私たちが共有する目標は一つです。それは、チームの有効性を最大化し、素晴らしいプロダクトを生み出すこと。 私は今年の1月にマネーフォワードにジョインし、今のチームでスクラムマスターとして働くことになりました。事前に聞いていたチームの情報は以下の通りです。 プロダクトマネージャー、UI/UXデザイナー、複数のバックエンド/フロントエンド/QAエンジニアから成る 従来のプロジェクトの進め方に課題感があり、4ヶ月前からスクラムを実践中 ここで一つの質問です。もし、あなたがスクラムマスターとして新しいチームにジョインしたとしたら、最初に何をしますか？この
まだ完結していないシリーズの途中ではあるのですが、ちょっと早めに自分の備忘録としてまとめておきたかったので先にこちらを書いてしまいました。 相変わらずの文章量なのですが(ちゃんと読むのに15分は確実にかかります)、お時間ある方は読んでいただけると嬉しいです。そして、内容についてはまだ実験段階な部分が多いので、フィードバックを貰えると非常に助かります🙏 1.命名規則とコンポーネントの単位について命名規則とコンポーネントの単位はプロジェクトで使用される技術によって少し状況が変わってくるように思います。 そもそもコンポーネントという概念が開発にほぼ必要ない普通のWebサイトなどであれば、多少実装しにくいと思われるかもしれませんが、あまりデザイナー側が気にする事ではないかなとも思います。 ただ、今回はReact.jsやVue.jsなどのフレームワークを使ったWebアプリケーション/サービス、また
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『みんなで小さく区切ってやる』ガイド｜kawanotron
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
「『撤退はしないくせに投資もしない』はインパール作戦みたいなもの」 “撤退”か“追加投資”しかない中で、プロダクトマネージャーが持つべき心構え
スクラム開発が全然しっくりこないまま スクラムマスターになってしまった僕が取り組んだこと
大手企業がこぞって進める生成AIの全社導入 日本企業におけるChatGPTとLLMの活用事例
元QAが開発チームにjoinして品質向上を試みたこと3選 - Qiita
ぼくらのスクラム奮闘記 - SmartHR Tech Blog
認定スクラムマスターになったので学んだことをまとめる！
アジャイル開発は要件定義が不要？よくある勘違いと正しい進め方を詳しく紹介
(公開版)スクラムマスターはどのように成長するのか
不確実なスパイクを確実にDONEする試み in スクラム
スクラッチ開発をアジャイル開発で進める手順！パッケージ開発との相違点も紹介
「理不尽な要求にはサラリーマン人生を懸けてでも『NO』と言う」 プロダクトマネージャーにとって重要な“NOと言う覚悟”
「チームの理想の状態は“巻き込み巻き込まれ”になっていること」 及川卓也氏が語る、プロダクトマネージャーの「ヒトを巻き込む覚悟」
「自分がセールスとなってプロダクトを売り込めますか？」 プロダクトマネージャーが営業のマインドセットを持つべき理由
Waterfall Deconstructed | Silicon Valley Product Group
Figmaにおけるコンポーネントとバージョンの管理について考える｜Nao Komura