再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス
Scrum Fest Mikawa 2021の登壇資料です。 以下は資料内で引用している参考リンクです DPA https://qiita.com/viva_tweet_x/items/97e819c626979b78947a KPT http://objectclub.jp/downlo…
Open8 勉強会で発表したレビューの仕方と心理的安全性の話しです。
Author: @urahiroshi, Engineering manager of Web Platform team 2022年8月4日、メルカリで “web-2” と呼ばれるサーバがシャットダウンされました。これはメルカリWeb版の開発に携わっているチームにとって、一つの区切りとなる出来事でした。 web-2はPHPで記述されたwebサーバで、2015年から https://www.mercari.com/jp/ 配下のコンテンツを配信していましたが、現在では複数のWebマイクロサービスがその機能を担っており、 https://www.mercari.com/jp/ 配下のページは後継となるWebマイクロサービスが配信するページへリダイレクトされています。 メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかか
あるときコードレビューするときにどういうところ見てるんですか？ と訊かれてたしかに自分でもあまり言語化したことはなかったな、と気づいたので簡単に書いておく。 変更意図が要求に沿っているか そもそも実現しようとしていることが、ユーザやプロダクトオーナーの要求に沿っているか。モデリングや実装のコンテキストを自分でも把握しておく。 関連する別の変更やイシューなど、自分が知っていて相手が知らない有意義な情報があったらコメントする。 モデリングが妥当か モデルによって意図が表現できているか。仕事が適切な粒度で明確に切り分けられているか。意図のない共通化がなされていないか。 わかりやすい名前がつけられているか。ここが混乱していると何かがよくないサイン。既存のコードがすでに……ということもある。そういう場合は改善できそうな道筋について議論できるとベター。 仕事にあったインタフェースになっているか。テスト
はじめまして。株式会社イノベーター・ジャパンでフロントエンドエンジニアをしている、うじた（@besburg）です。弊社ではスクラムによる開発を取り入れており、スプリントの最後には毎回スプリントレトロスペクティブという振り返りを行っています。そこで試した振り返りの手法をこの記事ではまとめてみました。 私たちのプロジェクトではタスクの優先度に入れ替わりが多く、今やっていることを可視化するため、2021年8月からスクラムを開始しました。参加メンバーは各プロジェクトのエンジニア全員で、スプリント期間に合わせて1週間ごとに振り返りを行っています。スクラムによる開発が初めてだったこともあり、当初は自分たちに合った手法を見つけることを目標に振り返りを進めました。 週ごとにメンバーが交代でファシリテーターを担当し、試したい振り返り手法を持ち寄ってレトロスペクティブを行いました。そのため基本的には振り返り手
2022.11.05 Scrum Fest Sapporo 2022
こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法（原題: The Airbnb Story）の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう？ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。
マネージャーや横断チームのリードを担っていると、自然と他チームとの関わりが増える。 他チームと関わる中では、必要な情報を適切に把握しておくことが大事。それができていないと、よい意思決定ができなかったり常に周囲に振り回されてしまったりして成果を出しづらい。たとえば、「品質保証に責務を持つ横断チームなのにいつのまにか知らない機能のリリースが進んでいた」みたいなやつである。 こういう「適切なタイミングで情報をキャッチできていない」という状況はわりと発生しやすい。そういう時に情報をキャッチできるように対処するプロセスを雑に書き出してみる。 1. 役割を明確にする 何に責務を持っていて何をする人/チームなのかを明確にすること 役割を知ってもらう前にまず自分自身やチームの中で認識を揃えることが大事 意外と役割自体がふわっとしていることも多く、その状態だと当然必要な情報も集まってこない 2. 役割の認識
2023.04.08 ふりかえりカンファレンス2023 https://retrospective.connpass.com/event/266892/
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
こんにちは。BASE BANK 株式会社 Dev Division にて、 Engineering Manager をしている東口（@hgsgtk）です。 弊チームではプロダクト開発のリズムの中で振り返りを継続的に行っていますが、YOT という振り返りワークを作成、使用しています。BASE 社内の他チームでも「YOT っていう振り返り方法があるらしい！」と興味を持ってもらい活用されていたり、社外でもスクラムやアジャイル関連のカンファレンスでの登壇でちらっと紹介した際に「それ良さそう！」と一定の反響がありました。しかし、その一次情報はインターネット上のどこにもない状態でしたので、作成の背景も含めて参考にできる YOT の一次情報をここに記します。 TL;DR 振り返りの場のファシリテーターには、発言量が少なくてうまく場が盛り上がらない、というあるあるな悩みがありますよね 起こったことや思った
KPT縛りではなく、他の代替手法、他の手法との組み合わせも含めた知見が集まっていました。 - 1 振り返りの前に - チームで共有したふりかえりの文脈をつくる - 前回のProblem/Tryを今回のKeepにつなげる 続きを読む
Data Physicalisation - Lecture 9 - Next Generation User Interfaces (4018166FNR)
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
どうも、ばやしです。 先日@ryuzeeさんがこんな記事書いてましたね。 www.ryuzee.com 記事の内容に関して同意しかないので、自分も最初はKPTをやるけどそのうちやらなくなる理由を書いていきます。 なおレトロスペクティブの手法はファシリテーターの振る舞いで効果効能が変わると思うので、ここから書く話はあくまで自分がファシリをする場合の話です。本記事内で登場する「KPTは」という表現は「(私がファシリする)KPTは」の短縮表現なのでご承知おきのほどお願いします。 KPTから始める理由 わかりやすいから シンプルでいいですよね。ルールも簡単でレトロスペクティブのファシリをしたことない方でも取っ付きやすいです。また業務改善感が強いのがウケが良い理由のひとつだと感じています。業務中のMTGなんだから、業務が改善されるようなMTGをしようよという心理的な圧は多少なりともありますよね。 チ
<> 2024.1.11 みなさんも編集可能・かつさらに使いやすくなった「コミュニティ版」をリリースしました。 是非そちらもご参照ください！ https://qiita.com/viva_tweet_x/items/f4db2c923d474f67fe0f 古今東西のふりかえり手…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? New!!（2024.1.11） 本記事の内容をよりブラッシュアップし、さらに使いやすくなった「ふりかえりカタログ（コミュニティ版）」をリリースしています。 今後はそちらをご利用ください。 ふりかえりカタログ（コミュニティ版） はじめに あなたのふりかえりを拡張するふりかえりカタログを公開いたします！ ふりかえりカタログは、ふりかえりの手法（現在）71個とその特徴を網羅したカタログです。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => ふりかえりカタログ（Booth版） スライドはSpeakerDec
■発表者 https://twitter.com/_N_A_ https://note.com/mryy プロダクトに関する問題空間を集めた電子書籍はこちら プロダクトマネジメント大全 上巻 https://booth.pm/ja/items/2657772 ---- 「問題ば…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに あなたのふりかえりを更に拡張するふりかえりカタログ（コミュニティ版）を公開いたします！ ふりかえりカタログ（コミュニティ版）は、ふりかえりの手法（現在）84個とその特徴を網羅したカタログです。下記画像はイメージです。 Miroにて作成したものをどなたでも利用可能です！ 利用はこちら => ふりかえりカタログ（コミュニティ版） 2021年1月にpdf版/speakerdeck版でリリースして以降、なんと約8万viewと、長く多くの現場にご利用いただいています。そちらを、より使いやすく、みんなで編集できる形にしたものが今回のコミュ
こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ（@yama_sitter）です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析（プレモーテム）の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り
https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15981 私たちは観察、理解、知識を用いて仕事をこなしています。 これらは「心の働き」といえるものです。 仕事の成果の質を左右する重要な活動で、 子供の…
こんにちは。ソフトウェアエンジニアの椎葉（@bufferings）です。最近実施したオリジナルのふりかえりがよかったので紹介します。 いつもはエンジニアリングマネージャの小田中さん（@dora_e_m）が、そのときのチームの状況に合わせたふりかえりの手法を用意してくれていて、毎週違うふりかえりをみんなで楽しんでいるのですが、今回は小田中さんが不在だったので私がファシリテーションをしてみることにしました。 どんなふりかえりをしようかなと ふりかえりカタログ を眺めていたところ Six Thinking Hats が目に止まり「これをアレンジして『帽子の交換』をすると、今のチームにちょうどいいかもしれないな」と感じて、今回のふりかえり手法を思いつきました。 カケハシはリモートファーストの会社で、私の所属するチームもフルリモートで開発に取り組んでいます。そのため、今回のふりかえりもオンラインホワ
JX通信社シニアエンジニアの@shinyorkeです. 最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1 JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して, BI（Business Intelligence）文脈でのデータ分析・可視化. ダッシュボード作ったり. 機械学習的なアプローチを使ったR&Dと機能開発（分類タスクなど） といった業務・タスクを社員・インターン問わず行っています. データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで！」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね. チームの皆さんも, もちろん私もモチベーション高くやってるわけですが！？ あれ, notebookどこ行ったんや...🤔 よくありますよねー（震え） 自分もチームメイトも, 前のめりになっ
新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか？また、オンラインでのふりかえりはどのように行っていますか？この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、本記事で説明します。 ふりかえり事前会アジェンダ 参画時期の共有（プラクティス1） 起こったことの共有（プラクティス1） ふりかえり本会アジェンダ 本日のチャレンジ宣言（アイスブレイク） 良かったこと、気になったことを共有（プラクティス1） インタビュー×3（プラクティス2） 課題の狙いを定める（プラクティス3
リンクアンドモチベーションでUXデザイナーをしている辻井です。所属している開発チームのとある会議が、想像以上にいろんな効果を生んでいた、というお話です。 どんな会議だったのかそれは週次のKPT会議でした。（Keep / Problem / Tryの観点で、成果・課題を棚卸しするミーティング） 会議は週に1回、1時間 全職種から全員が参加 Miroで、「今週やったこと」「来週やること」を書き出す 他メンバーの振り返りを見て、「感謝コメント」を記入する チームや開発に関するGood Newsを自由に記述する 感じている懸念があれば、それも自由に記述する というルールで実施していました。 この会議体、半年近く運用していて、大きな問題があったわけではありませんでした。ただ、期初のタイミングで会議体を見直し、「週次で1時間はややToo muchかもしれない。感謝・リスペクトを伝える会議体は月末に納会
こんにちは。バクラク申請・経費精算エンジニアの@upamuneです。最近「グラップラー刃牙」を全巻読んだので、懸垂マシンを買いました。 この記事はLayerXテックアドカレ2023の10日目の記事です。前回はデータチームの@saaaaaakyが「1人目データアナリストとしてデータチームに異動しました #LayerXテックアドカレ 」を書いてくれましたが、明日は @shimacos が面白い話を書いてくれる予定です。 私はなぜか3日分もテックアドカレに入れてしまったのですが、1回目の今回は軽い自動化ネタを紹介しようと思います。 弊チームではスクラム開発を行っています。スプリントごとに振り返りとしてKPT(Keep, Problem, Tryを出し合うふりかえり手法の1つ)を利用して行うのですが、リモートワーク下だったこともあり、オンラインホワイトボードとして利用できるMiroをKPTに利用し
はじめに こんにちは。コミューンのスクラムチームで開発をしているandoと申します！ コミューンの開発チームはスクラム開発を採用しており、2週間スプリントを行っています。 スプリントの終了時には振り返りを通じて改善アクションを出し、日々の業務の中でももっと良くできそうなことがあれば改善するといった形で改善を繰り返しています。 今回はその改善の中から、チームが質とスピードを両立させるために行った改善策を紹介します。 持っていた課題感 私の所属しているチームではそれぞれに対して以下のような課題感を持っていました。 スピード ストーリーをもっと早くリリースできそう バーンダウンチャートを見ると、しばらく横ばいで急に下がるような動きになっている 考えられる障壁はあるが、チームで収まらない課題も多い チーム内で解決できる課題もあるかもしれないが、見つかっていない 質 テストケースを作りリリース時に動
この記事はBASE Advent Calendar 2022の3日目の記事です。 どうもこんにちは、ShopFrontチームの青木です。 主にショップデザイン関連機能の開発を担当しています。 今回は、チームのEMをしていた頃に、メンバーのGitHubやKibelaの活動など一箇所でまとめて見れるWebアプリを作成した話になります。 作成したWebアプリについて 自分のページのスクリーンショット 構成 ローカル環境で利用することを想定したもの 環境変数に各種PAT等設定をし、Asana API, GitHub GraphQL API, Slack APIを利用しています フレームワークにはNext.js, Bootstrap5を選定しました 主な機能 メンバーごとに、期間を指定して、以下のようなことができます。 Asanaのアサイン中のTask、GitHubの活動、Kibelaの活動、Uni
"ふりかえり会" をやろうよ！という話を、社内勉強会で話した。
This article was originally posted on the Rails at Scale blog. In September, 2020, our team at Shopify released a Ruby gem named Packwerk, a tool to enforce boundaries and modularize Rails applications. Since its release, Packwerk has taken on a life of its own, inspiring blog posts, conference talks, and even an entire gem ecosystem. Its popularity is an indication that Packwerk clearly filled a
スクラムなどアジャイル開発において重要な「ふりかえり」。チームを成長させるために不可欠にもかかわらず、うまい方法がわからない、形骸化している、といった課題を感じている方は少なくないはず。今回は『アジャイルなチームをつくる ふりかえりガイドブック』（翔泳社）より、ふりかえりの基本を解説した「Chapter01 ふりかえりって何？」を紹介します。 本記事は『アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット』の「Chapter01 ふりかえりって何？」から抜粋したものです。掲載にあたり一部を編集しています。 ふりかえりとは？ ふりかえりは、チーム全員で立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です（図1.1）。毎週や隔週など定期的に、毎回同じ時間にチーム全員で集まって行います。チームにとっ
このブログでは何度か「ふりかえり」の重要性とやり方について紹介してきた。 ふりかえりメソッド「KPT」の基本とはじめ方 ふりかえりは、チーム活動の改善や個人の成長を促すことに大変に役に立つ手法だが、それだけでなく人間としての成熟にも寄与するものではないかと長年やってきて感じるようになった。 本稿では、アジャイル開発で使われるレトロスペクティブと、人材育成で使われるリフレクションの二つのふりかえりを比較しつつ、ふりかえりの本質的な価値について考察してみたい。 改善のためのレトロスペクティブと、学びのためのリフレクション 最近、人材育成の場面でも「ふりかえり」が注目されているらしい。そこでは、ふりかえりのことを「リフレクション」とも呼ぶ。リフレクションでは、得られた経験をもとに学びに転換することを目的としている。 一方、私たちが以前からやっているKPTを使った「ふりかえり」は、アジャイル開発で
【緩募】KPT (Keep/Problem/Try) をやると、Kがあまり出ずに、Pばかりになる。しかも、各メンバーからの「自分はあれもこれもできなかった」という自責もので溢れてしまう。という組織は少なくないと思うのですが、Kを増やすための何か工夫をしている人がいたら、教えて下さい🙏🏻 — 及川卓也 / Takuya Oikawa (@takoratta) September 24, 2021 非常によく聞く話。この状況、冷静に考えると・・・ 「ふりかえりがしやすい方法」をやってみたが、ふりかえりがうまくできない。この「ふりかえりがしやすい方法」が「よりやりやすい方法」をみんなが考えているこれって・・・ 痩せるためにランニングを始めたが、効果が薄い。よりランニングがしやすいランニングウェアを考えるみたいな感じが否めない。 ランニングで痩せないなら、ランニングじゃない方法が良いのでは？
This blog post is all about three particular kinds of issues Airbnb focused on when declaring their way to fix problems in their company culture; why its important to name such issues explicitly; what happens if you ignore them & why it's so important not to do so.Disclaimer: the concept presented in this article is not mine, hereby I take no credit neither for the naming nor the idea itself. The
スクラムの中でレトロスペクティブという1週間の振り返りを行っているかと思います。ただ1週間の振り返りだけではマンネリ化していく可能性があります。「ぼくたちはどこに向かっているんだろうか。」 弊社の開発チームが向き直りと振り返りをうまく活用して、成長していった物語をお話したいと思います。 振り…
ふりかえりカンファレンス2023
プロジェクトマネジメント協会の元会長であるアントニオ・ニエト＝ロドリゲスが「現代の経済の原動力はオペレーションからプロジェクトへと置き換わった」と指摘1するように、現代は「プロジェクトの時代」と言えます。プロジェクトは「必ず、過去に行われたことのない何かが含まれる」ものですが、現代社会はその傾向がより強まっています。そもそも何が問題かということも分からないし、仮に問題が分かったとしても、どのように解決したらよいかという手段の選択も簡単ではありません。 このような状況でも、プロジェクトを進めていくためには、どこかで進むべき方向や何をやるのか、ということを決定しなければなりません。分からないながらも、判断しなければ、一歩も動き出すことはできません。しかしながら、なんとか判断したとしても、その決定は絶対的なものではありません。良くも悪くも「仮決定」のようなものです。そのため、「仮決定」が適切なも
BlogBlog Home Blog 振り返りのフレームワーク「KPT法」とは｜そのメリットや進め方、実施のポイントについて 日々新しい何かが生まれ、あらゆるものが常にアップデートされ続ける現代において、個人や組織も継続したアップデートが不可欠になっています。つまり、新たな挑戦や学習、それらを通じたナレッジの積み重ねにより、絶えず改善を重ねる取り組みの重要性が高まっていると言えるでしょう。 特にIT業界において、その傾向はより顕著です。日進月歩で新たな概念やテクノロジーが生まれ、またそれらを活用したサービスが生まれ続けるなかで、仕事においても日々新しいことにトライしながら、改善をしていくということが求められています。 しかしながら、多くの業務を抱えて毎日を忙しく過ごすなかで、仕事がいわゆる「やりっぱなし」になってしまい、実施したことに対してきちんと振り返りを行い、改善することにまでなかなか
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く