Regional Scrum Gathering Tokyo 2020のスライドまとめ #RSGT2020 - スクラムマスダーの日記
2020/01/08から、Regional Scrum Gathering Tokyo 2020（以下、RSGT2020）が始まりました！ 2020.scrumgatheringtokyo.org 本ブログでは、RSGT2020のセッションの発表資料をまとめています。 個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄などで教えていただけるとさいわいです。 現時点では、1日目のスライドのみです。 2日目まで追加しました！ 3日目まで更新しました。 1日目（2020/01/08） keynote The Ten Bulls of the Scrum Patterns Hall WEST アジャイルコーチ活用術 slide.meguro.ryuzee.com みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？ プロダクト生
Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント！ 応募期間は2019/11/29～2019/12/31まで。詳細はこちらをご覧ください。 今すぐツイートするならこちら→ フォローもお忘れなく！ 【IIJ 2019 TECHアドベントカレンダー 12/15（日）の記事です】 システムクラウド本部の濵﨑です。認定スクラムマスター(CSM)を取りました。 我々は今新サービス開発を行っています。 サービスの開発にあたっては検証タスクを洗い出したり、ユーザーストーリーマッピングを実施したり、とにかく描いて話してということが多くなります。毎回会議室を取って話す時間を作っていましたが、まとまった時間が確保しづらいですし、予定を取るのがあまりにも面倒なので貸し会議室を借りて合宿のような形式でワークショップを行ったりしました。 この貸し会議室作戦は大変よかったの
はじめに HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。 私たちのチームには、プロダクト開発を進める上で次のような課題がありました。 プロダクトオーナー（以下、PO）の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー（以下、EM）の業務負担を削減するものです。 本記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。 この記事では、プロダクト開発において
このエントリはEngineering Manager Advent Calendar 202213日目の記事です。 まえがき このエントリは、以下のPodcastで話した内容を掘り下げて整理したものです。Podcastの方では本エントリで触れていないチームの具体的な様子等についても話しているので、ぜひ合わせてお楽しみください！ はじめに 以前、エンジニアリングマネージャーを目指す若者の戦略というエントリを書きました。その時点でのエンジニアリングマネージャー（以下EM）というロールへの理解や、実際にEMを目指していくための戦略を整理したものです。 素晴らしいことに、このエントリの投稿からおよそ1年3ヶ月たった今も戦略は機能しており、ロールへの理解を深めつつキャリアを前進させることが出来ています。本エントリでは、EMというロールへの理解の変化や、EMを志向する過程で目指している「最強の現場リー
アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。後半は、「作り方における準備のRebuild」「コミュニケーションの Rebuild」「ノウハウのRebuild」について。前回はこちら。 「イテレーション0」をやらないアジャイルは出だしでつまずく 渡会健氏（以下、渡会）：あと、もう1つ次のヒントで、イテレーション0をやらないアジャイルは出だしでつまずくんじゃないかなというところで、よく、アジャイルをやるための準備としてイテレーション0、もしくはスプリント0というものをやりましょうという話をします。 その時によくアジャイルの本で書いて
こんにちは、坪田です。 dely Advent Calendar 3日目の記事です。 昨日は、エンジニアのmochizukiが NetflixのFast JSON APIを使ってみた を書きました！ 僕は、クラシルを運営するdelyでクラシルユーザー体験と、開発部門のマネジメントに責任を持っており、そのプロダクトマネジメントのスタイルを書いてみます。 よく、CXOって何をするのか聞かれますが、僕の場合は社長である堀江さんのビジョンを汲み取り、1秒でも早く、ユーザーに評価される最適な体験を作ってリリースする事を仕事にしてます。プレイヤー領域としては、UIデザインを武器にしているので、ユーザー体験を可視化しながら関係者を巻き込んで開発するスタイルが強みです。 今回は、突破するプロダクトマネジメントという内容で、クラシルで実践しているプロダクトマネジメントの手法について書きました。 タイトルを突
ニューヨーカーより。 ネットワーク上の時刻を同期させるのは、目立たないソフトウェアシステムがある。誰がそれを維持するのだろうか? BY ネイト・ホッパー 1977年、ワシントンDCに本社を置く衛星通信企業COMSATに、風変わりなエンジニアでコンピュータ科学者のデイビッド・ミルズが入社してきた。恋人の叔父のために補聴器を作ったり、フォード社に紙テープのコンピュータを車に搭載するためのコンサルティングをしたこともある。ミルズはCOMSATで、後にインターネットの前身となるARPANETというコンピュータ・ネットワークに携わるようになった。すでに、一握りの研究者らが、離れた場所にあるコンピュータ同士を繋いで情報交換をしていた。しかし、このネットワークは、各コンピュータが同じ時刻を共有していないという欠点があり、データの信頼性が損なわれていた。 ミルズは数十年にもわたり、数学、工学、コンピュータ
さよならスプレッドシート Azure DevOps の Azure Boards でスクラム開発一元化！（後編） - ecbeing labs（イーシービーイング・ラボ）
目次 本記事は前編と後編に分けてお届けいたします。 前編と後編を合わせた記事の目次は以下の通りです。 前編 はじめに Azure DevOps について スクラム開発をAzure Boardsで管理する プロジェクト作成時にプロセスを設定 ポートフォリオバックログどうなる？ プロダクトバックログどうなる？ リファインメントどうなる？ 後編 スプリントプランニングどうなる？ デイリースクラムどうなる？ スプリントレビューどうなる？ レトロスペクティブどうなる？ まとめ このページは後編となっていますので、まだ前編をお読みでない方は上記リンクから前編にご移動をお願いします。 スプリントプランニングどうなる？ スプリントプランニングで行われる作業で大事なことは以下の３点です。 チームのキャパシティを明らかにする スプリントバックログを作成する スプリントで取り組むプロダクトバックログアイテムを選
ブログプロジェクト管理【2024年版】プロジェクト管理システム・ツール おすすめ10選！脱エクセルでスムーズな工程�・進捗管理 こんにちは。マニュアル作成・ナレッジ共有ツール「NotePM」ブログ編集局です。 企業がひとつの目標に向かって効率的かつ、生産的に取り組むには「プロジェクト管理」が不可欠です。従来のプロジェクト管理では、エクセル（Excel）で課題管理や進捗管理をされている方も多いと思いますが、プロジェクト管理ツールを導入する事によってさまざまなメリットがあります。 この記事では、プロジェクト管理ツールのメリット、おすすめツールなどをご紹介します。また、プロジェクト管理で活躍する「ITツール」を以下でまとめていますのでご一読ください。 【2024年版】社内wikiツール おすすめ15選（有料・無料） 【2024年版】ナレッジ共有ツール タイプ別おすすめ 10選 プロジェクト管理ツ
施策を "Own it" するエンジニア 〜オーナーエンジニア制度の紹介〜 - クックパッド開発者ブログ
レシピサービス開発部の新井（@SpicyCoffee66）です。いろんなゲームが好きなのでどれも中途半端にしか上手くならないことに 10 年以上悩んでいます。 この記事では、クックパッドのレシピサービス開発に導入している "オーナーエンジニア" と呼ばれる制度について紹介します。 クックパッドでサービス開発をしているエンジニアがどういう働き方をしているのか知りたい ディレクターやデザイナーと上手く協業する方法が知りたい サービス開発エンジニアはやることが多すぎてどうやって仕事をすればいいか悩んでいる といったような方の参考になると思いますので、興味があれば是非ご一読ください。 制度導入の背景 オーナーエンジニアという役割について述べる前に、まずはレシピサービスの開発を取り巻く環境について軽く解説します。 現在クックパッドのレシピサービスは、エンジニアが 10 名と少し、デザイナーが 5 名
モバイルアプリ開発チーム、カンバンはじめました。 - kubell Creator's Note
こんにちは！モバイルアプリケーション開発部の折田 (@orimomo)です🍑 私たちの部署では2023年1月にチームの再編成をおこないました。 もともと2チーム制だったところを3チーム制へと変更し、そのうち2チームでスクラムではなくカンバンを採用するという選択をしています（残り1チームはスクラムを継続）。 今回は、カンバンを採用した理由や、この4ヶ月間おこなってきた試行錯誤について書いてみようと思います。カンバンが気になっている方、スクラムからカンバンへの移行を検討している方にとって、少しでも参考になれば幸いです。 なお、以前に部署のスクラムについて紹介する記事を書いておりますので、よければそちらもご覧ください。 creators-note.chatwork.com 2023年〜のチーム構成 カンバンを採用した経緯 カンバンを始めるにあたって 実際カンバンをやってみて どうだったか？ メ
この記事は ANDPAD Advent Calendar 2022 の 7日目の記事です。 qiita.com こんにちは、ydahです。 先日のRubyWorld Conference 2022で燗酒の美味しさに感動していたのですが、ふと気がついたら島根の日本酒がたくさん我が家にいました。 気が付くと何故か我が家にいらっしゃった方々(不思議だ...) そして、また気がつくと枡や徳利、平盃も我が家にいらした(不思議ですね...)のでこれから寒くなるので、燗酒を飲んで温まっていこうと思います。 はじめに 本記事では私が所属しているANDPAD検査チームで取り組んだ以下のことについて紹介いたします。 Request specの改善についてやったこと チームとして改善タスクやリファクタリングを推進するための仕組み作り Request specの改善について 長年、様々な人によって書かれてきていた
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ スクラムマスターの中原（PayPayカード株式会社）、岩井（ヤフー株式会社）、そしてアジャイルコーチの荒瀬（ヤフー株式会社）です。 私たちは、PayPayカードの会員サービス開発を大規模スクラムで進めています。PayPayカードとは、クレジットカード加盟店で通常のクレジットカード決済ができることに加え、PayPayアプリと併用することによってPayPay加盟店であと払い決済が利用できるサービスです。「圧倒的No.1のサービスをすべてのお客さまに！」というビジョンを掲げており、ユーザーファーストにサービスを提供することを心掛けています。 より早く質の高いプロダクトをお客様に提供するために、ヤフーとPayPayカードの2
こんにちは。 AI在庫管理というプロダクトでフロントエンドの開発を担当している大村です。 AI在庫管理開発チームでは、顧客に素早く価値を提供するためにフロー効率を重視した開発を行っています。 本記事では、なぜフロー効率を高めようとしているのかと、どのような取り組みによってフロー効率を高めているかについて紹介します。 リソース効率とフロー効率 生産性の効率の考え方として「リソース効率」と「フロー効率」があります。 複数人の開発者がチームでソフトウェアを開発するシーンを想定し、リソース効率とフロー効率それぞれを重視した場合の仕事の流れを単純なモデルとして表現してみました。(ここでは仕事の1つ1つをタスクと呼ぶことにします) これだけ見ると、リソース効率重視の方がムダなくタスクを消化しているように思います。 しかし、ソフトウェア開発の現場では以下のような状況が頻繁に発生します。 他の開発者のレビ
認定スクラムマスター研修で獲得した知識をチームに還元できている話 - Hatena Developer Blog
こんにちは。Webアプリケーションエンジニアの“すてにゃん”こと id:stefafafan です。私は2021年7月に認定スクラムマスターの資格を取得し、現在はその知識をチームの仕事に活かしています。 はてなにおけるスクラムの取り組みとしては、この開発ブログで id:shimobayashi が紹介した「すくすく開発会」や「プロジェクトテンプレート講義」があります。 ▶ はてなの開発プロセスを改善する、すくすく開発会とプロジェクトテンプレート講義のご紹介 - Hatena Developer Blog 今回は、その延長として社外で認定スクラムマスター研修を受講し、スクラムのまとまった知識を学んで社内に展開したことや、今後やりたいことなどをお話します。 プロジェクト運営の前提知識がない問題に直面 認定スクラムマスター研修を受講することにした 研修を受けて分かったことや自分が変われたこと ス
Re:Backlogs というプロジェクト管理(タスク管理)ツールを OSS としてリリースしました - Qiita
読み方: Re:Backlogs (リ・バックログ) 2019/12/23: 使い方の記事を書きました。 Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します 画面紹介 デモサイト: https://rebacklogs.saino.me/ Twitter, Google, GitHub ログインに対応しているので、お気軽にお試しください マスターバックログ プロジェクトのトップページにあたる「マスターバックログ」という画面です。 この画面でプロダクトバックログの中に Story を追加したり、Sprint を追加した後にプロダクトバックログから Story を Drag & Drop で追加したりします。 カンバン (Kanban) マスターバックログにある Sprint のところから Kanban ページに飛ぶことができます。 この画面で Story
この記事は GMOアドマーケティング Advent Calendar 2020 24日目の記事です。 こんにちは。GMOアドマーケティングのT.Mです。 はじめに 2020年11月下旬くらいだったでしょうか、スクラムガイド2020が発表されました。 スクラムガイド2020を読んでみて、いま自分たちが行っているスクラムとどう違うのか考えてみました。 昨年のアドベントカレンダーではスクラムを始めた事を書きましたが、 ちょうど1年経ったようです。 ※スクラムを始めてからは1年半経ちました。 スクラムガイドについて スクラムガイドは、20ページ弱の短い文章でスクラムの定義、理論が記載されています。 理論的な内容なので具体的な実践方法は各種書籍の方が詳しいです。 2017年版から久しぶりの改訂版が出ました。 2020年版はこちら。 スクラムガイド2017と2020の違い 3年ぶりに改定されました。
入社しました 本日 2023 年 9 月 1 日から アンドパッド に技術広報として入社しました！ というわけで、こんな機会はそうそうないため（ 22 年ぶり！）、入社エントリーを書きました。 勤続 22 年 自己紹介を兼ねて、これまでのキャリアを簡単に。 2001 年に翔泳社の IT エンジニア向け研修事業の立ち上げで入社し、途中、子会社の SE プラスへの転籍を経て、 22 年間、研修事業に携わってきました。 その間、営業、コース開発、サービス開発、チームマネジメント、開発イベント企画・運営、プロダクトマネジメント、メディア編集・ライティング、あと少々のプログラミングなど、本当に様々なポジションを経験しました。 この場を借りてお世話になった方々にお礼を申し上げます。 お世話になりました！ ありがとうございました！！ その中でも転機になったのが、このブログでも過去に触れた、 SE ゼミで
モバイルアプリ開発チームのスクラムってどんな感じ？ - Chatwork Creator's Note
こんにちは！モバイルアプリケーション開発部でスクラムマスターをしている折田 (@orimomo)です。 私たちの部署ではiOSエンジニア・Androidエンジニアが混在する2つのチームを作り、それぞれでスクラムによる開発をおこなっています。 私自身もともとはiOSエンジニアなのですが、現在は専任のスクラムマスターとして両チームに関わらせてもらっています。 最近では各々の継続的な改善が実を結び、スクラムチームとして少しずつ、しかし確実に成長ができているなと感じられるようになりました。 「スクラムが楽しくなってきた！」「いいチームになってきた気がする！」という話をメンバーから聞くことも増え（嬉しい🙌）、ここまで色々あったなぁ…長かったなぁ…と感慨深く思っています。 今回は、そんな私たちが具体的にどのようにスクラムを回しているのか、また以前と比べてどのように変化してきたのかについてご紹介ができ
こちら、pyspa Advent Calendar 2019の23日目の記事です。前日の記事は id:kutakutatriangle さんの34のおっさん(当時)が痔ろう手術するハメになって健康大切だと実感した思い出話(前編)でした。 お前誰？ Luminosoという会社でソリューションチームの一員として働いています。業務としては、製品のプロトタイプ開発のような作業が大半です。お客様の要望に応えるために、既存の自社製品だけでは満たせない拡張部分を作っていくのが主な業務になります。 そうした仕事を通して、プロダクトを作るということについて自分なりに考えたことを書いていきます。 できるだけ開発しない 既存の製品・機能でできることがあるのであれば、まずそちらを使うべきでしょう。開発は、既存のプロダクトではユーザのニーズに「応えられない」ことがわかった場合に初めて行うものであり、「応えられるかわ
2023.12.08 スキル 牛尾剛マイクロソフトアジャイルグローバルチーム 考える前に手を動かせ、質問する前に自分で考えろ…日本の社会人にとっての“あるある”は「世界最先端で働くエンジニアにとって真逆の考えだった」と、書籍『世界一流エンジニアの思考法』で紹介したのが、米国マイクロソフトのエンジニア・牛尾剛さんだ。 10月末に発売された著書は、各書店やAmazonの売れ筋ランキングで上位に入り、読者からは驚きや感嘆が交じったXが連日ポストされている。 「即レス」は非効率 「試行錯誤」は非効率 「後で文書化」は非効率 「ググれ、カス」は非効率 「早く失敗しない」は非効率 「納期を守りすぎる」は非効率 「会議の前に準備する」は非効率 「口頭だけでなく文書化」は非効率 何もかも覆された…でも超納得の一冊 pic.twitter.com/EmAQ3bSTfI — もとやま📚著書『投資としての読書
スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの
スクラムの各種イベントに対して懐疑的だったが、チームでの改善を繰り返すうちに意義を感じるようになった話 - Commune Engineer Blog
自己紹介 はじめまして、2020年の1月から業務委託、2020年の11月から正社員でコミューンのエンジニアとして働いているよしもと(@yoyo_yo123)です。 2022年の頭にスクラムチームが誕生し約８ヶ月間スクラム開発をしてきました。 正直スクラムを始めた当初はスクラムイベントの意義を感じられず多くのイベントに懐疑的でした。 しかしチームでの改善活動や取り組みを繰り返す中で、「スクラムイベントは意義があるものだ」と感じるようになりました。 今日は私が元々どう感じていて、今はどう感じているか、それは何故か、についてお伝えできればと思います。 スクラムイベントのどこに意義を感じてなかったのか？ 短いミーティングの中だけで実施されるリファインメント 要件の理解や実現方法の検討もできずで、「ただPOから話を聞くだけ」のあまり意味のない時間になっていた 時間内にストーリーの詳細化が進まず、結果
経験の浅い社員の意見も真摯に受け止めてくれるので、自信がつきやすい | はてなで働く lunastera にアンケート [#22] - Hatena Developer Blog
はてなで働くエンジニアにアンケートシリーズ第22回は、ブックマークチームのWebアプリケーションエンジニア、id:lunasteraに話を聞きました。 はてなブックマークのアーキテクチャの出来に感動して入社へ UXを重視し、フロントエンド周りやユーザー体験の改善に関するタスクを好む 自分の活動によって周囲の人の行動に影響を及ぼすことができた 「マネジメント星人？」と思うくらいうまいメンターから吸収したい 自分の意見が改善につながったから、自分の中だけに考えを留めるのはもったいない はてなブックマークのアーキテクチャの出来に感動して入社へ ── Q1. はてなidとその由来を教えてください id:lunastera です。元々は era（読み方は「イーラ」「えーら」「えら」）という名前で活動していたのですが、3文字なので、大抵のサービスではIDやアカウントとしては取得できないという問題があり
![経験の浅い社員の意見も真摯に受け止めてくれるので、自信がつきやすい | はてなで働く lunastera にアンケート [#22] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/e4c10a1889812b2e56fdbca1111ca0fc95247d7e/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20221129%2F20221129193252.jpg)
良い戦略は実行計画を含む｜himara2
こんにちは！プロダクトマネージャーのひまらつ（@himara2）です。 「戦略」とはどこか掴みどころのない言葉です。会社の事業戦略を考えたりそれをプロダクト戦略に落とし込んだりを定期的に行っていますが、戦略とは何を考えることなのか、いまいち解像度があげきれずにいました。 最近、プロダクトの行く先を考えるなかでその意味するところが少しわかった気がしました。戦略とは何か？戦略を立てるときに何に気をつければよいのか？このnoteで自分の理解を整理してみます。 戦略とはなにか？戦略とは「目的地に向かうルートを決めるもの」、というのが自分の理解です。 目的地というのは、大きく捉えればビジョンです。「こういう世界をつくりたい」というビジョンを叶えることが事業の最終的な目的地といえます。 もう少しミクロだと、事業として重要な地点にいくことが目的地です。PMFするとか、広く市場に受け入れられるとか、グロー
梗概 現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。 「文書を書かない」という誤解 本連載の第1回～第3回において、ウォーターフォール方式に変わる、新たな開発手法が発見され、それが1990年代後半～2000年代の「Linux」やスマートフォンの開発において極めて重要な役割を果たし、それが今日のアジャイル開発手法の原則として受け継がれてきていることを解説しました。今回から、アジャイル開
こんにちは、プレックスの種井です。 今回は、PlexJob開発チームにおいて、技術的負債に対して、どのように向き合っているかを紹介したいと思います。 「PlexJob」は物流特化型のダイレクト・リクルーティングサービスです。 求職者様が求人を検索するサイト 企業の採用担当者様が採用活動を行うための管理システム を提供しています。 背景 技術的負債との向き合い方 スプリントのタスクの10~20%を負債の返済に当てる 負債の蓄積と共有を行う 振り返りと棚卸しを定期的に実施する 負債の返済に対しての敷居を下げる 負債に対して、個々人の目線を合わせる 現在抱えている開発上の課題 おわりに 参考 背景 PlexJobはリリースから1年を迎えています。 嬉しいことに1年間ですでに13万ユーザーを突破するなど、急成長のサービスではありますが、まだまだプロダクトとしては、業界特有の課題に対して、仮設検証を
※この記事は「COUNTERWORKS Advent Calendar」の14日目の記事です。 はじめまして、株式会社 COUNTERWORKS にてEnterprise向けプロダクトのエンジニアリーダーのshimです。 私のチームは、障害対応や既に決まっていたミーティングなどの次に、コードレビューの優先順位を高くしております。 私がチームのリーダー的存在となって1年半ほど運用してきた振り返ろうと思います。 古くは Google様のドキュメント 、本年も他の会社でも同様の取り組みで良かったと聞くことが増えました。 個人的にかなり良い取り組みとなったので、この文化が広まる一助となるよう筆を執りました。 経緯 開発メンバーも増えたものの、いろいろなバックログがしかかり中で終わって、メンバー数の割になかなか価値提供までいかないスプリントが多かった時期がありました。 それについて複数要因はあったの
SRE と Developer のコラボレーションを支える仕組み - スタディサプリ Product Team Blog
こんにちは。SRE の @int128 です。 Quipper の SRE チームでは、Platform の安定運用や改善だけでなく、Platform を利用する Developer のサポートも重要な仕事と位置付けています。 SRE チームで工夫していることを紹介します。 Issue に記録を残す SRE チームでは課題や疑問などを気軽に相談してほしいと考えています。 そのため、Slack で気軽に SRE にメンションしてもらえる文化を作るように心がけています。 Slack で相談している例 一方で、同時に多くのメンションを受け取った場合、経緯の把握に時間がかかる、対応状況が分からなくなるといった課題があります。 例えば、Slack のやり取りを通して、ちょっと設定変更すればできるかも、検証してみようという話になることがよくあります。 Slack のスレッドだけでは、具体的な検証作業に
デュアルトラックアジャイルって結局何なの？｜かわきん（ちゃんかわ）/atama plus スクラムマスター
こんにちは、河口です。 atama plusというAI×教育のスタートアップでスクラムマスターをしています。会社と私の紹介については、以下のスライドとnoteを参照ください。 みなさん、「デュアルトラックアジャイル」という言葉をご存知ですか？ デュアルトラックアジャイルとは、「事前に最小コストで最大のリスクをつぶしながら、価値あるプロダクトを作っていく」ための開発プラクティスです。 atama plusでは創業当初からデュアルトラックアジャイルを実践しようと取り組み、たくさんの失敗と成功を重ねてきました。ディスカバリーバックログとデリバリーバックログを分けてプロセス化してしまったことによるミニウォーターフォール化など・・・。 今年のはじめに弊社のデザイナーも、atama plusのデュアルトラックアジャイルの取り組みを紹介していました。今回は、プロダクトオーナー、スクラムマスターの視点から
【Conference Projector】OpenAI API を使って CVPR 2023 全体を眺めるWebサイトを作成した - IrohaLog
概要 CVPR 2023 会議全体を可視化したグラフを眺めながら論文検索できるWebサイトを作成したので紹介します。 会議に採択された論文全体を可視化したグラフから、 カテゴリやアプリケーションが近い論文を探せます。 テキスト検索ではない方法で、広い視野で論文を探せます。 会議全体で盛り上がっている分野や、逆にニッチな分野を把握することもにも役立ちます。 研究テーマを模索している方や、広い視野で業界動向を知りたい方におすすめです。 yuukicammy--conference-projector-wrapper.modal.run 概要 はじめに Conference Projector で何ができるか システム概要 実装詳細 (1) スクレイピング (2) カテゴリ、アプリケーションなどのテキスト生成 (3) Embedding (4) PDFからの画像抽出 (5) 次元圧縮 (6) K
こんにちは、電子カルテチームの鳥山(@to_lz1)です。私のチームではクラウド電子カルテ「エムスリーデジカル」を開発運用しています。今回はそんなエムスリーデジカルの "オンラインデモ版"、つまり体験版アプリケーションを3年半ぶりにアップデートさせたお話です。具体的には インフラをAWSに移行 最新のコードベースでデプロイ 製品版のリリースと同タイミングでCI/CDできるように変更 という大きく3点を一気に実施しました。 3年半ぶりというとなんだかすごいことのようですが、そもそもなぜ製品版と異なる環境にあったのか、アップデートできないままだったのはなぜなのかといった疑問は皆さま抱かれるかなと思います。 この記事では、オンラインデモ版サイトの移行に関連するエムスリーデジカルのインフラの変遷、そして移行に際して工夫したこと・考えたことをご紹介しようと思います。 前提 オンラインデモ版更新の意義
スキル管理チームの「入社半年〜ズ」が感じる、仕事と成長をドライブするSmartHRの文化 - SmartHR Tech Blog
2023年8月22日にリリースしたSmartHRの最新プロダクト「スキル管理」。 実は、リリース時チームメンバーの3分の1、数にて4名がSmartHR入社半年以内のメンバーであり、しかもそのうち3名は配属時期が6〜7月とリリースの直前！ 今回は、そんなスキル管理の「入社半年〜ズ」に集まってもらい、リリース後の心境や、SmartHRについて感じていることについて語ってもらいました。 また、先日実施されたイベント「0→1をスクラムでやってみた -スキル管理機能の作り方- - connpass」では、新規プロダクトリリースに至る苦労や知見が、リリース時スクラムチームメンバーから選ばれた6名によって披露されたので、ぜひ資料をチェックしてみてください。 higashi173 大学卒業後、第三者検証の会社にQAエンジニアとして入社。1年ほど在籍したのち、ポテンシャル採用のQAエンジニアとして2023年
SSO（スクラム知らないおじさん）がスクラムチームにやって来た - ぐるなびをちょっと良くするエンジニアブログ
はじめまして、ぐるなび仕入モールでバックエンド開発を担当している中村です。2020年度に中途入社し、それまでは主にウォーターフォールモデルでの開発に携わっておりました。 今回はそんな スクラム知らないおじさん（以降、SSO）から見たぐるなび仕入モールチームのスクラム開発をご紹介できたらと思います。 この記事で書いていること この記事で書いていないこと 何を作っているか 現在のチーム構成 プロダクトオーナー スクラムマスター 開発メンバー 開発のサイクル プランニングからリリースに至るまで スクラムイベントのスケジュール ウォーターフォールとのフロー対比 何やらカタカナが多い 工数算出をどう行なっているか プランニングポーカー 数値の一律設定型 Tシャツサイジング（今ココ） 最後に この記事で書いていること スクラムを用いてチームで開発にどう取り組んでいるかをご紹介しています。主に、 スクラ
チームでやっている ZenHub x Scrapbox を使ったフルリモートなアジャイル開発の紹介 - Money Forward Developers Blog
こんにちは！ マネーフォワード クラウド横断本部のWebエンジニアの はるやま (@linnefromice) です。 現在クラウド横断本部で行っている既存サービスのリプレイスプロジェクトにおける開発チームでの開発プロセスの紹介をさせていただきたいと思います！ 背景 プロジェクト発足当時は2人だったのですが、現在5人にまでメンバーが増え、そのうちの1人は海外居住者なので現在入国できておらずフルリモートで参画しています。海外居住者でないメンバーに関しては最低週1出社としていて、チームとしてはほとんどがリモートでの勤務がベースになっています。 (当たり前なことではあるのですが、)途中参画したメンバーはそれまでの経緯や意思決定をキャッチアップも必要ですし、初期メンバーはそれに対するフォローだったり、メンバー同士の相談などもなるべく低コストでスムーズにしたいです。 上記のような背景があり、仮にフル
スクラムで品質を上げ続けるために完成の定義（Definition of Done）を作りました - Timee Product Team Blog
読んで欲しいと思っている人 POやステークホルダーと品質について共通言語や目標が欲しい開発者 開発者と品質について共通言語や目標が欲しいPO スクラムで品質について困っている人 読むとわかること 完成の定義（Definition of Done）とはどんなものか スクラムと非機能的な品質の関係性 タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか 完成の定義（Definition of Done）とは インクリメントが常に守るべき状態のことです。スクラムガイド1では以下のように説明されています。 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 つまり完成の定義を満たしていない成果物は、いかに優れた機能であっ
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 9 週目の記事です！ 1年間連続達成まで 残り 44 週 となりました！ はじめに こんにちは、株式会社ログラスでエンジニアの浅井（@mixplace）です。開発チームのいちメンバーとして、チームの開発生産性改善を行う傍ら、デザインシステムの構築に携わっています。 ログラスもプロダクトローンチをして 3 年が経ちました。日々新しい機能の追加や改修が入っていく中で、開発チームも増え、チーム内でアウトカムを出していくことが増えてまいりました。 機能が増え画面数も増えてくると、比例するように「UX負債」や「共通UIコンポーネントの技術的負債」も目に付くことが増えてくるようになります。 このような課題について、プロダクト全体の品質や一貫性担保する観点で「デザインシステム」を構築して運用していくことが
大規模B2B SaaS 「HRMOS」におけるDesign Systemの開発・運用プラクティス
前回の記事ではHRMOSのDesign Systemの導入背景の紹介をしました。 本日はそのDesign Systemがどのように開発・運用されているのかを紹介したいと思います。 開発体制 Design Systemの開発はデザイナー、エンジニアが1つのチームとして開発を行っています。 開発のポイントとしては以下のとおりです。 デザインタスク、実装タスクなどすべてのDesign Systemのタスクは1つのバックログで管理 隔週に1度、やることの計画、やったことの確認をチーム全員で行う チームメンバーは全員兼務なので、極力MTGを増やさないよう、非同期でのコミュニケーションをメインにしている この体制になった背景として、当初はDesign System開発がデザイナーとエンジニアで分断されていたことにあります。 デザインとエンジニアリングでそれぞれ別のバックログをもち、それぞれ別のサイクル
RubyKaigiに参加してプロダクト価値を高めるためにOSS をやっていきたいと再認識した話 - Speee DEVELOPER BLOG
こんにちは、新卒で入社してから早くも 1 年がたってしまったことに驚きを隠せない、DX 事業本部エンジニアで 22 新卒の高島です。 本ブログでは、プロダクトを伸ばすために OSS をもっとやっていきたいと気づけた話として、直近参加した RubyKaigi 2023 で得られた学びをまとめたいと思います。 目次はこちら OSS 活動について 私が RubyKaigi にオフライン参加した第 2 の目的 「プロダクト開発」 と 「OSS 活動」 はトレードオフ関係ではない OSS と プロダクトは 表裏一体な関係である OSS に関わる機会は自分でもっと作っていける まとめ 謝辞 RubyKaigi の思い出 最後に OSS 活動について 私は昨年の 12 月からクリアコードの結城さんのサポートを受けながら、週 1 回業務時間を使って OSS 活動を行っています。 特に、業務の中で使っている
Amazon Web Services ブログ correction of error (COE) を開発すべき理由 アプリケーションの信頼性は非常に重要です。サービスの中断はマイナスのお客様体験となり、お客様の信頼とビジネス価値を低下させます。Amazon で学んだベストプラクティスの 1 つは、インシデント発生後の分析のための標準的なメカニズムを持つことです。これにより、インシデント発生後にシステムを分析し、今後の再発を防止することができます。また、インシデントの発生は、システムおよびプロセスがどのように機能するかについて理解を深めるのにも役立ちます。その知識は、特定のインシデントの再発防止だけでなく、他のインシデントシナリオに役立つアクションにつながることがよくあります。このメカニズムは、Correction of Error (COE) プロセスと呼ばれています。事後分析は COE
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
部長席を破壊しました | IIJ Engineers Blog
メンバー全員が開発リードになれる、「エピック主管」という仕組み
EMキャリアを切り拓く「最強の現場リーダー」という働き方 - yigarashiのブログ
理論や理想だけではない、現場で役立つアジャイルのヒント 50以上の案件から見つけた実践のTips
突破するプロダクトマネジメント - クラシル開発チームで実践した事まとめ｜坪田 朋
インターネットの時刻を守り続ける問題
【2024年版】プロジェクト管理システム・ツール おすすめ10選！脱エクセルでスムーズな工程�・進捗管理
RSpec の Request spec をチームで改善していった話 - ANDPAD Tech Blog
ヤフーとPayPayカードが大規模スクラム合同実践 〜 若手スクラムマスターがやってみた
フロー効率を重視した開発のすすめ - KAKEHASHI Tech Blog
スクラムガイド2020を読んで自分たちのスクラムをふりかえりました。
アンドパッドに技術広報として入社しました - ♥OSS
プロダクトを作るということについて考える - 科学と非科学の迷宮
米マイクロソフトで見つけた「究極の生産性」日本のIT業界でも実行できる理由とは？ - エンジニアtype | 転職type
不確実なスパイクを確実にDONEする試み in スクラム
第4回：アジャイルに対する誤解（1）--設計せずにいきなり作る？文書を書かない？
技術的負債との向き合い方 - PLEX Product Team Blog
コードレビューの優先順位を高めたらチームの生産量が上がった話
3年半デプロイのなかったクラウド電子カルテ体験版をついに本番追従させた話 - エムスリーテックブログ
エンジニアがデザインシステムの構築に向けて、UX改善と両立して取り組んだ話
correction of error (COE) を開発すべき理由 | Amazon Web Services