git pullでerror: The following untracked …やYour local changes…が出たときの原因と対処

Gitに慣れていないときはgit pullを実行したさいにエラーが出て困ることがあります。1度対処方法が分かれば大したことないのありませんので本記事ではgit pullで起こるエラーと原因、解決方法をまとめておきます。

追跡されていないファイルでエラー

error: The following untracked working tree files would be overwritten by merge:
<ファイル名>
Please move or remove them before you merge.

git pullしたとき、remoteと同じファイル名で追跡されていないファイルがローカル環境にあってエラーになっています。対処法は一時退避するか、削除するかです。

一時退避する

git stash -aでスタッシュ領域に退避できます。その状態であればgit pullが成功します。退避したファイルはgit merge stash@{0}でマージすることもできます。

削除する

該当のファイルが不要な場合、git clean -fdで削除できます。

変更中のファイルでエラー

error: Your local changes to the following files would be overwritten by merge:
<ファイル名>
Please commit your changes or stash them before you merge.

git pullしたときにローカル環境のファイルが変更中のためエラーになっています。対処法は一時退避するか、変更を取り消すかです。

一時退避する

上記と同じくgit stashでスタッシュ領域に退避できます。この場合「-a」オプションはなくてもgit pullが成功します。*1

変更を取り消す

git restore <ファイル名>で変更を取り消します。その状態であればgit pullが成功します。

まとめ

git pullを実行したさいに一度は発生するエラーについてまとめました。Gitコマンドを使った対処法の紹介でしたが、エラーになったファイル名を変更して一時退避してもいいと思います。やりやすい方法で対応していきましょう。

git stash、git clean、git restore、それぞれのコマンドについては別でも記事を書いています。
iucstscui.hatenablog.com
iucstscui.hatenablog.com
iucstscui.hatenablog.com

*1:-aを付けてても大丈夫です

変更を一時退避するGitコマンド：stash

開発中、最新の環境にしたくてPullしたとき、競合することはありませんか。または急ぎで別の開発を頼まれて今の変更をコミットせずにおいておきたいことはありませんか。

そんな時に使えるコマンドがgit stashです。git stashは現在の変更点を一時領域に退避(スタッシュ)できます。
git-scm.com

今回の検証に使ったgit version は 2.26.2 です。

変更を退避する

git stashコマンドはHEADとの差分がスタッシュされます。スタッシュされるファイルはオプションによって変わります。以下のフォルダ構成でオプションによる違いを確認していきます。

root/
　├ commit.txt
　├ change.txt
　├ new.txt
　└ ignore.txt

commit.txtは追跡されているファイルです。
change.txtは追跡されているファイル＋変更ありのファイルです。
new.txtは追跡されていないファイルです(開発中で新しく作ったファイルの想定)。
ignore.txtは.gitignoreで無視ファイルに設定しています。

git stash

スタッシュされるファイルはHEADと差分がある追跡されているファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt

git stash -a

スタッシュされるファイルはHEADと差分があるすべてのファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt
• new.txt
• ignore.txt

git stash -u

スタッシュされるファイルはHEADと差分がある無視ファイル以外のファイルです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt
• new.txt

git stash -k

スタッシュされるファイルはHEADと差分があるファイルです。ただし、ステージングエリアに登録しているファイルの変更は残ったままです。上記のフォルダ構成の場合、以下のファイルがスタッシュされます。

• change.txt

スタッシュの一覧を確認する

git stash listコマンドでスタッシュの一覧が表示されます。

stash@{0}: On master: option-all
stash@{1}: On master: option-non

git stashコマンドで-m <コメント>オプションをつけてコメント付きでスタッシュすると一覧表示したさいにわかりやすくなります。

スタッシュの変更内容を表示する

git stash showコマンドでスタッシュしたさいの変更内容が表示されます。

change.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

スタッシュの変更内容を反映する

git stash popコマンドでスタッシュの内容をワーキングツリーに反映します。また、反映後はスタッシュから削除します。
git stash applyコマンドでスタッシュの内容をワーキングツリーに反映しますが、反映後にスタッシュから削除しません。

スタッシュを削除する

git stash clearコマンドですべてのスタッシュを削除します。
git stash drop コマンドで1つのスタッシュを削除します。

TortoiseGitで使う

TortoiseGitでもgit stashが使えます。基本はCUIと同じで、操作がGUIになるだけです。

変更を退避する

右クリックメニューからStash changesをクリックします。

ポップアップにメッセージや、オプションを選択してOKをクリックでスタッシュします。

スタッシュの変更内容を反映する

右クリックメニューからStash Popをクリックでスタッシュの内容をワーキングツリーに反映します。

まとめ

変更を一時退避するgit stashコマンドを調べました。過去にスタッシュしたのになぜかファイルが退避されてないということがあったのですが、オプションの指定ができてなかったんだと気づきました。知っているつもりのコマンドも改めて調べることは大切ですね。

変更された行のコミットを確認するGitコマンド：blame / おすすめのツールはVSCode＋GitLens

前回の記事はgit bisectを紹介しました。
iucstscui.hatenablog.com

今回は同じくバグ調査に役立つgit blameです。
git blameは変更された行の情報(コミットのハッシュ値や更新者)を確認するコマンドです。誰が変更したか分かれば変更の意図などを確認できますよね。
git-scm.com

以下のそれぞれの環境で使う方法についてまとめていきます。

• CLI
• VisualStudioCode＋GitLens
• TortoiseGit
• GitHub

サンプルコード

git bisectの記事で使ったコードを使って検証しました。
github.com

CLIで使う

基本的な使い方

git blame <ファイル名> を実行するとそのファイルの変更一覧が確認できます。

<省略>
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 21)             else if (num % 3 == 0)
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 22)             {
YYYYYYY (iucstscui 2020-05-05 22:05:26 +0900 23)                 return "Fizzzzzzzzzzzzzzz";
^XXXXXXX (iucstscui 2020-05-05 21:59:30 +0900 24)             }
<省略>

左からコミットのハッシュ値、更新者、日付が表示されます。

特定の行を調べる

-Lオプションを使うことで表示数行数を絞り込めます。

行番号指定で絞り込み

以下は10行目から20行目を表示します。
git blame -L 10,20 -- <ファイル名>

以下は10行目から10行を表示します。
git blame -L 10,+10 -- <ファイル名>

正規表現で絞り込み

以下はキーワードの文字がヒットした行付近を表示します。
git blame -L /キーワード/ -- <ファイル名>

過去の情報を見る

以下は指定したリビジョンより過去の情報が表示されます。
git blame <コミットのハッシュ値> -- <ファイル名>

VisualStudioCode＋GitLensで使う

VisualStudioCodeのGitLensという拡張機能をインストールするとgit blameと同等の機能がより使いやすくなります。
marketplace.visualstudio.com

選択行にgit blameと同等の情報が表示されます。

選択行の空白の部分にマウスオーバーすると変更差分が表示されます。

上記ポップアップのChangesをクリックすると差分が表示されます。

GitHubで使う

GitHubでもgit blameが使えます。

GitHubでファイルを表示後、右上のBlameボタンをクリックします。

変更箇所にコミットメッセージが表示されます。

上記のコミットメッセージをクリックすると差分が表示されます。

TortoiseGitで使う

TortoiseGitでもgit blameが使えます。

ファイルを右クリックし、Blameを選択します。

ポップアップが表示され、変更箇所にコミットのハッシュ値が表示されます。

まとめ

変更された行の情報が確認できるgit blameを紹介しました。なぜ変更されたのか経緯を調べるために便利なコマンドです。GitLensが使えるVSCodeが一番扱いやすそうでした。

バグの混入コミットを発見するGitコマンド：bisect

開発をしているといつの間にかバグが混入することがありますよね。混入タイミングが分からない場合はとりあえず正しく動く時期のコミットを見つけて、バグが発生するまで地道に調べていくと思います。

そんなときに使えるコマンドが git bisect です。
git bisect はコミットログからバグが発生したコミットを見つける手助けをしてくれます。
git-scm.com

今回の検証に使ったgit version は 2.26.2 です。

サンプルコード

検証用にバグが混入しているリポジトリを用意しました。最新のコミットはテストコードが通りません。
github.com

基本的な使い方

バグが混入しているコミットと正しく動いていたコミット間から混入したコミットを見つけます。正しく動いていたコミットは確実に動いていた時期のコミットを指定します(1週間前は確実に動いていたのになーって感じならその時期のコミットを指定します)。この2つのコミット間を二分探索で絞り込みながら見つけていきます。

1.調査開始

git bisect start コマンドを使って調査を開始します。開始時にバグが混入しているコミットと正しく動いていたコミットを指定します。

以下のコマンドではgit bisect badで最新のコミットにバグが混入していることを指定し、git bisect good HEAD~8 で8個前のコミットでは確実に動いていたことを指定しています。

git bisect start
git bisect bad
git bisect good HEAD~8

また、以下のように書いても同じ意味です。

git bisect start HEAD HEAD~8

2.調査

「1.調査を開始する」を実行した後のworking treeは二分探索で絞り込まれたコミットの環境になっています。この環境で動作確認をして正しく動作すればgit bisect good、正しく動作しなければgit bisect badを入力します。入力後のworking treeは二分探索で絞り込まれた新たなコミットの環境になっています。

これを繰り返すと<コミットID> is the first bad commitのメッセージが出て初めてバグが混入したコミットを見つけられます。

3.調査完了

git bisect reset でgit bisect start前のコミットに戻れます。

テストコードがあれば自動探索できる

バグかどうかを発見できるテストコードなどがあれば、git bisect run コマンドで自動探索できます。
*1

たとえば以下のようにgit bisect run コマンドの引数でdotnetのテストを実行すると自動で判断しながら特定のコミットを発見してれます。

git bisect start HEAD HEAD~8
git bisect run "C:\Program Files\dotnet\dotnet.exe" test

TortoiseGitでbisect

TortoiseGitでもgit bisectが使えます。基本はCUIと同じで、操作がGUIになるだけです。

1.調査開始

右クリックのメニューからBisect startを選択します。

バグが混入しているコミットと正しく動いていたコミットを選択します
goodは「...」から正しく動いていた頃のログを選択します。

2.調査

working treeは二分探索で絞り込まれたコミットの環境になっているので動作確認をしてBisect good、Bisect badを選択していきます。

これを繰り返すと<コミットID> is the first bad commitのメッセージが出て初めてバグが混入したコミットを見つけられます。

3.調査完了

Bisect resetでBisect start前のコミットに戻れます。

まとめ

二分探索でバグが混入したコミットを見つけてくれるgit bisectコマンドを調べました。どのタイミングで混入したか分からないバグを探すときには便利なコマンドです。

*1:そもそも、テストコードがあればbisectコマンドが必要になる前にバグ混入に気づけると思いますが

理想を語れる組織をつくろう / Cybozu UX Cafe 理想のデザイン組織について語ろう に参加した

2020/04/24 に開催された【オンライン開催】Cybozu UX Cafe 理想のデザイン組織について語ろうに参加しました。僕はソフトウェアエンジニアでデザイナーではありませんが、良いモノづくりをするにはUXの理解がたいせつだと考えてデザインについても学んでいます。
今回の勉強会は4名の方がそれぞれのデザイン組織について発表されました。

cybozu.connpass.com

どの組織もメンバーの個性を伸ばしてプロダクトを良くしようと感じました。これを良くすれば売れる。これを作れば売れる。そういう時代ではなくなり、ユーザーニーズを早く見つけ、早く市場に出すことが重要になっています。なにが売れるか分からない不確実性に対応している4者4様の組織づくりを学びました。

みなさんのそれぞれの発表で学んだことをまとめて、さいごに気づいた共通点をまとめます。

「サイボウズデザイン組織改善事例」 柴田 哲史さん（サイボウズ株式会社）@satosh923

サイボウズデザイン組織改善事例 from Satoshi Shibata

• プランニングからデザイナーが入ることで製品は良くなる
  • 「製品が出来てからフィードバック」から、「企画→リサーチ→設計→デザイン」で早めのフィードバック
• 理想のデザインプロセスの探求を毎週実施
• フィールドリサーチでリアルな課題を見つける
• スクラム時代のマルチプレイヤーへ
  • リサーチもできるデザイナー
  • デザイン＆リサーチに名称を変更
• 個性を伸ばせるようにサブチームに分割

デザインチームが個性を伸ばせるように1チームをサブチームに分割するまでの道のりの話でした。「理想のデザインプロセスの探求を毎週実施」された話が参考になりました。対話を繰り返すことでお互いの個性を知ることもできそうですし、組織を自分たちで変えていくという意識に繋がると思います。

プランニングにデザイナーも入る話も良かったですが、プランニングに入る分、デザインを書く時間は減ると思うので対策が気になりました。

また、UXの勉強会でスクラムという単語が聞けたのは驚きです。スクラムが浸透しているんですね。

「SmartHRのプロダクトデザイン グループで考える理想のデザイン組織」佐々木 勇貴さん （株式会社SmartHR）@tyoys00

www.figma.com

• 理想の組織：それぞれが異なったスキルを持って連携できる組織
• デザインが取り組むべき課題は広範囲なのでひとりがすべて実践するのは無理
• SmartHRの価値観：100の問題を100人で1問ずつ解く組織
• 社内にも社外にも共通言語や価値観を発信することでシナジーが生まれる

「それぞれが異なったスキルを持って連携できる組織」

これにすべてが詰まっていますね。僕もチームを形成するときに意識していることです。誰の個性も消さず、むしろ全員の個性が高まるようなチームになりたいと思っています。「100の問題を100人で1問ずつ解く組織」も優先度の高い課題を全員で解決しようとするスクラムの価値観に近いと感じました。それを組織としてされているのは自分の理想に近くて良いなと思いました。

SmartHRさんは「アジャイル推進室」も進められているので注目しています。

tech.smarthr.jp

「なぜ組織でモノを創るのか」金子 剛さん（600株式会社）@tsuyoshi_osiire

なぜ組織でモノを創るのか? from Tsuyoshi Kaneko

• 組織で「共」に「創」る【共創】
• 歴史から紐解くモノづくり
  • 古代よりヒトは分業することで進化した
  • 現代はすぐにコモディティ化する
  • 常に新しい「意味的価値」を生み出していく
• エキスパート×コラボレーションで生み出す

分業により進化してきた歴史から現代に求められる意味的価値について話はとても興味深かったです。今は多様性が求められていてエキスパートが共創できる組織は納得です。

「意味的価値の構築は不確実性が高い」と紹介がありました。不確実性へのアプローチはアジャイルが一つの方法ですね。コレボレーションを生み出すチーム作りとアジリティを高める活動。スクラムマスターの腕の見せ所な気がします。

「freee におけるデザイン組織」神戸 慎一さん（freee株式会社）@kambielden

• 速度重視から組織をスケールするフェーズへ
  • UXの役割は多い
  • 3チーム体制に変更
• プロダクトで実現したいこと
  • プロダクトを通してマジ価値な体験をユーザーに届けきる
  • マジ価値：ユーザーにとって本質的な価値があると自信をもっていえること
• 取り組み
  • スキルマップ定義
  • 計画的な採用
  • UX起因のプロダクト提案を増やす

組織をスケールアップするために取り組まれた話でした。「プロダクトを通してマジ価値な体験をユーザーに届けきる」の「届けきる」に強い意志を感じました。

取り組まれた結果、リサーチやユーザーテストが組織に根付いたと話されていて課題もありつつ根気よく取り組まれたことは尊敬です。

デザイナーのスキルマップも一部紹介頂きました。

• コアスキル
  • リサーチ
  • 情報設計
  • UI設計
• ソフトスキル
  • 進め方
  • 影響度
  • リーダーシップ

さいごに

みなさんのお話には以下の共通点を感じました。

• 個性をのばす多様性なチーム
• デザイナーだけでなくプランナーなどと共につくる
• リサーチを当たり前の文化にする
• 価値観を合わせる

金子さんの話にあった「意味的価値」をつくるために進化させ続けた結果の共通点だと思います。

プランニングの段階から個性と個性をかけあわせてアイデアを出し、それがユーザーニーズに合っているかリサーチしながら作りつづける。ただ、個性だけではブレたプロダクトになるので価値観を合わせる。とても大切なことだと思いました。

また、もう一つ大切なことは理想の組織やプロセスについて対話しつづけることだと思います。変化に敏感になり、変化に適応できるように僕もチームで理想について定期的に話したいと思います。

理想の探求をチームや組織で継続的に行って誰も見たことのないプロダクトを生み出したいと思います。

運営のみなさま、発表のみなさま、素敵なイベントをありがとうございました！

参考

「なぜ組織でモノを創るのか」の発表者の金子さんは自身の内容をまとめられています。
note.com

製造業アジャイル勉強会『春のOST祭り』（オンライン）に参加して、オンライン勉強会の良さを体感した

製造業アジャイル勉強会『春のOST祭り』（オンライン）に参加しました。

beyond-hardware-agile.connpass.com

初めてのオンライン勉強会の参加でした。テーマも楽しみでしたが、オンラインのOST(Open Space Technology)はどうやって進行していくかも楽しみの一つでした。
オンラインの進行はとても考えられていて、運営の方法も含めてたくさん学べました。

運営のみなさま、参加者のみなさま、ありがとうございました。

オンラインのOST進行方法

オンラインのOST進行方法がほんと素晴らしくて忘れないようにまとめておきます。

使用ツール

• 音声、チャット：Discord
• 壁、ホワイトボードのかわり：Google Jamboard

Discordの使い方

Discordはゲーム用チャットツールで「サーバー」という場所に「チャンネル」という部屋をたくさんが作れるサービスです。
discordapp.com

今回の勉強会はチャンネルの使い方が工夫されていてオフラインでOSTしているのと変わらない感じで参加することが出来ました。

• 「#ホール」という全員が集まるチャンネルを用意
• 「#保健室」「#理科室」のようなユニークの名前のチャンネルで各セッション
• 部屋の移動がワンクリックで手軽

Google Jamboardの使い方

Jamboardはオンラインで使えるホワイトボードです(同時編集できます)。
gsuite.google.co.jp

OSTは参加者で議題を決めていき、下の画像のように話したい内容を壁に貼って自分たちでスケジュールを作っていきます。

※本勉強会と関係なく過去のOSTで撮影した写真

オンラインホワイトボードはこのスケジュール作成の代わりに使われていました。

• オンラインホワイトボード上に仮想の待機列があり、話したいことがある人は付箋を書いて待機列に並ぶ
• 自分の順番が来たら話したい内容を宣言して、空いているスケジュールの枠に付箋を配置

オンラインでこの進行が出来るんだ！と驚きでした。

進行

これらのツールを使った全体の進行は以下の流れでした。
1.「#ホール」でオープニング(LT大会とOSTの説明)
2.「#ホール」と「Google Jamboard」でテーマ出しとスケジュールの作成
　(OSTではマーケットプレイスと呼びます)
　スケジュール作成時にどのチャンネル(#保健室とか)で話をするかも決定されます
3. スケジュール決まったら各チャンネルで各々テーマに沿った対話

運営のTAKAKING22さんがもっと詳しく紹介されていました。
takaking22.com

OSTの内容について

僕が参加したセッションについて考えをまとめておきます。

リモート朝会(どんな風にやっているか)

コロナ禍でリモート作業になり、どのような方法があるのか悩まれていました。

僕もスクラムをベースとした開発をしているので毎日デイリースクラムを実施しています。デイリースクラムでは「昨日やったこと」「今日やること」「困ったこと」を話されることが多いと思います。最近は「昨日やったこと」「今日やること」を話すのを止めて「困ったこと」だけを質問するように変えました。「昨日やったこと」「今日やること」は分報を取り入れた影響で話さなくても見えるようになったので、一番大切な「困ったこと」だけを質問するようにしました。

残った時間でフリートークしています。テレワークが続くと何気ない会話も意識しないとできなくなるので、コミュニケーション不足をカバーしてます。

分報は別で記事を書いています。
iucstscui.hatenablog.com

大規模でテストどうしている

製造業の開発をしているとハードウェアも絡みますしテストも大規模になります。スプリントで開発は回しているけど、結局最後にテストフェーズがありどうすれば良いのか悩まれていました。

僕も難しいなぁということで答えを持っているわけではありません。一緒に悩んでいきたい課題です。リリーススプリントという考え方が参考になると思いました。
www.ryuzee.com

スプリントごとにリリース可能な状態にする考えを前提として、後に回すテストも認めるように考えるとスプリントごとに何をするべきか考えられて良いのかなぁと思います。

チーム開発でチームの達成感でなく、個々の達成感を実感してもらう方法

チームで作る取り組みを増やすと個々の達成感が減っていて、達成感を実感してもらうにはどうすれば良いのか悩まれていました。

いいなって思った手法は「ふりかえりのチェックインに0-100で達成感を表明してもらう」です。0-100の値を出すときに考えるきっかけになるし、ふりかえりでも「達成感」をテーマにした話も出しやすそうですね。

僕なら「Fun!Done!Learn!」をやってみるかなって思います。「Done!」の項目があることで達成したことを振り返るきっかけになると思いますし、そのDoneがLearnやFunに繋がっていたことも実感してもらえそうだなって思いました。

「Fun!Done!Learn!」は過去にまとめたことがあります。
iucstscui.hatenablog.com

さいごに

オンライン勉強会はオフラインと変わらず、むしろオフラインよりも良い面も沢山ありました。

• 遠方の勉強会に参加できる
• 見るだけ、話すだけ、特定の時間だけ参加、など参加方法に多様性が出る
• OST時の部屋の移動が気兼ねなくできる

今はコロナ禍でオンライン勉強会が増えていますが、この状況が落ち着いたあとでもオンライン勉強会は続いていくと良いなと思います。
それらを感じられたのは運営のみなさんの工夫と開催のおかげです。ありがとうございます。

また、参加したいと思える勉強会でした。

離れていてもチームの一体感を高める方法「分報」

今までは当然のようにチームと同じロケーションで働いていましたが、テレワークが推奨されてそれぞれ家で働くことが多くなりました。
同一ロケーションじゃなくなると以下のようなことで困りそうだなぁと思いました。

• 相談が気軽にできなくなる
• 何をしているか分からない
• 元気かどうか分からない
• コミュニケーションが減る

そこで取り入れたのが分報です。その結果、同一ローケーションで働いている以上に良くなった部分もあります。

分報とは

週報や日報はよく聞くことがあると思います。一週間や一日の終わりに上司などに作業結果を報告するアレです。
分報は分単位で報告します。1分単位で報告するわけではなく、好きなタイミングで好きなことを報告します。
例えば、「○○はじめます」「○○、予定通り終わったー」「あれ、うまくいかないなぁ」「疲れてきた」「予定より時間がかかってる」のようにツイッターで呟くように書いていきます。

分報は専用のチャンネル作る場合もありますが、今は一つのチャンネルにチームメンバー一人ひとりがスレッドを作って呟いています。同じチャンネルで分報することで一体感が出ている気がします。

では、この分報で何か良くなるのか書いていきます。

近くで働いている感が出る

同一ロケーションで働いていると物理的な距離が近いので何もせずとも一緒に働いている感が出やすいです。テレワークはモクモク作業していると「いるかどうかも分からない」なんてこともあるでしょう。

でも、チームで分報をしていると今何をしているのか、何に困っているのか、分かるようになります。むしろ一緒に働いているときよりも何をしているのか分かるようになります。(一緒に働いていても、今何をしているのか逐一把握してないですもんね)

その結果、いつもより距離が近く感じます。

困っていることにアドバイスがもらえる

「○○がわからない」と呟くとそれを見つけてくれたメンバーからアドバイスがもらえます。普段ならもう少し悩んでから相談していたことも早めに助けてもらえます。

ちょっとしたことも褒めあえる

「〇〇できたー」みたいな呟きにみんながイイね！してくれます。小さなことでも共感や褒めて貰えると嬉しいですよね！

相手のタイミングに合わせて相談

ちょっと今いいですか？の代わりに相手の分報に質問を書いておきます。このとき、急ぎはメンションつけて、後でいいときはメンションなしで質問します。

メンションなしの場合、回答者は自分のタイミングで回答できるので集中を保てるメリットがあります。

また、DMのやり取りと違ってみんなに見えるので透明性が高い会話になります。

ふりかえりに使える

一日の終わりに分報を眺めるとやったことが分かります。今日は何をしたか悩まなくていいのです。YWT*1のやったことがすでに終わっている状態です。

まとめ

• テレワーク、リモートワークでチームの距離が遠くなった場合に分報は有効
• 困っていることが見えてチーム内の助け合いが起こりやすい
• ルールを決めてかっちりするよりは、自由にしたほうが色んな声が聞ける
• チームだけでなく個人のふりかえりにもGood

ポモドーロテクニックと合わせてすると良いかなとも思います。少なくとも1ポモの始まりと終わりに呟くとリズムがあって良さそうです。

*1:ふりかえりのフレームワークです。やったこと、わかったこと、次することを考えて改善していきます。