00:01
この前、スクラムフェス大阪2025にプロポーザルを出していたんですけど、それが見事採用されました。
ということで、7月の18、19ですかね、に開催されるんですけど、
まあ、大阪に行こうかなと思っております。ラッキーですね。
まあ、ちょっといろいろな事情があって、本当はですね、今この時期、万博やってるじゃないですかと。
だから、ついでに万博行くみたいなことを目論んでたんですけど、
7月19日、スクラムフェス大阪の2日目に帰らざるを得ないので、
まあ、翌日こう残ってちょっと万博行くかみたいなことが気づいて、
スクラムフェス大阪の2日目に帰らざるを得ないので、
スクラムフェス大阪の2日目に帰らざるを得ないので、
まあ、翌日こう残ってちょっと万博行くかみたいなことが気づいて、残念ですね。
まあ、そんな感じで、スクラムフェス大阪の登壇に向けて、いろいろ準備をしていこうかなと思っています。
結構、そうですね、やっぱり、私はプロというか、
結構登壇慣れしてる人って資料をギリギリまでやるみたいな人いるじゃないですか。
ああいうのができないので、結構事前に準備しようかなと思っています。
ということで今回は、一見事実のように見える評価という攻撃を受けたときですね。
攻撃という結構、なんでしょうね、あれなワードが入ってるんですけど、
事実のように見える評価、観察ってありますよね。
観察をして評価をすると。
観察と評価は分けましょうみたいな話をよく聞くんですよ。
というか、聞いてきたんですよ。
特にこの界隈ではそういうのよく言いますよね。
文化人類学をやってた人がどうのとか、観察と評価は違うよみたいなことを聞いてきて、
そうだよなと思うところですよね。
この前ですね、
登壇を聞いてきたんですよね。
一つがテストの話で、一つがNVCの話みたいな。
NVCの話って、あんまり詳しくわかんないんですけど、
Nonviolent Communicationとかそういうやつでしたっけ?
ちょっと略語もわかってはいないんですけど、
コミュニケーションのお作法としてそういうのに目を向けると、
いろいろと相手を思いやりつつ何か発するみたいなことができるんだなっていうのは理解をしていて、
03:09
その中で、
確かNVCの文脈の中で、
評価を混ぜ込まない方がいいみたいな。
事実と評価を混ぜ込まない方がいいみたいなことを確か言っていたんですよね。
非常に本当そうだなと思っていて、
その時はそうだなと。
だけど最近ですね、本当に事実と評価が混ぜこぜになって、
何か言われたみたいな経験があったので、
これはもうやっぱりNVCのあれ、聞いててよかったなって思うところですよね。
最近あったことで言うと、
うちのチームが本当にやりたくないことをやったんですよ。
うちの組織Ruby on Railsを使っていて、
Ruby on Railsのモデルっていうのがありますよね。
モデルにバリデーションって追加する時って結構注意しないといけないじゃないですか。
既存のデータでその新しく追加するバリデーションが適用され、
既存のデータでその新しいバリデーションが引っかかるかっていうのは結構注意しないといけないんですよね。
いろいろな事情があると。
本当にいろいろな政治的事情があって、
既存のデータはそもそも修正しづらいので、
このままやろうという決断をしたわけですよ。
それはもうプロダクトマネージャー含め了承済みの決断なんですよね。
それをやっておそらくエラーが出るから、
エラーが出たらアドホックに対処しようということでやってて、
案の定エラーが出て、
エラーが出た箇所があるチームの場所で出たんですよね。
そこでいろいろと連絡を受けるわけですよと。
連絡を受ける前にまず私の方で、
これはこういうエラーかなっていうことで、
一応そういうふうな修正をするということは、
社内全体に周知していた状況だったんですよね。
だから放っておいても、
こういうことだからということで各チーム対処してくれるかなと思ったんですけど、
そうではなくて、
このエラーが起きたときに、
あなたのチームではどういうことをする想定だったんでしょうか?
みたいに聞いてきて、
そうですね。
いろいろなことを言うわけですよ。
06:03
それがですね、
ちょっと細かいことを言わないでおきますけど、
あたかも事実、
あたかも至極真っ当な事実を言っているようなんですけど、
はしばしにうちのチームへの批判が読み取れるわけなんですよね。
これがまさに事実と評価が混ざった状態なんだなということで、
私はもうこれ攻撃と捉えてます。
ただそれをスラック上でそういうことをやってたんで、
そこの中でやり取りで応酬が始まると非常にやばいなと思ったんで、
ハードルで話しましょうということで話したと。
そこの中でもいろいろ言ってたんですけど、
バリデーションを導入する経緯みたいなことを説明して、
うちとしては一応こういうことでやってると言って、
納得はしてくれなかったんですけど、
そういう説明をしたということがありました。
そうですね。
もう本当これ非常にタフなコミュニケーションだったなって思うところなんですよね。
あたかも事実ですげえチーム批判みたいな感じなんですよね。
良くないよなって思います。
本当事実と評価を分けましょうはマジでその通りで、
事実を淡々と並べるだけじゃないんですよね。
事実と評価を分けるって意外と難しいよなって思うところがあって、
さっきのNVCの登壇で質問があって、
遅刻ですよねってそれは事実に見えるんだけど、
でも遅刻というワード自体にも評価が含まれてますよねと。
そんなことを言っていて、本当そうだなって思うんですよね。
事実、その人にとっての事実ってその人にとっての事実であって、
これから見れば評価なんですよね。
私もさっき攻撃って捉えたのはそういうことなんですよね。
これどうしようかなって本当に思うわけですよ。
攻撃を受けた時の話をしようってことが今回のテーマなんですけど、
そもそも攻撃をする側になっちゃう可能性があるんで、
そういう時には本当に相手の文脈、
せざるを得なくてそうなったっていう話は絶対あると思うんで、
あんまり批判しないようにコミュニケーション取りたいなとは思いますよね。
こういうことが起きてるんですけど、
ちょっと話しませんかとか、一緒に協力しませんかみたいな、
そういう感じでやっていきたいですよね。
一方で攻撃を受けた時どうするかっていうと、
さっきハドルでやるってやったんですけど、
09:02
個人的には結構、別にスラックのハドルですよね。
スラックのハドルで喋ったところで納得はしてもらえなかったんですけど、
もしあれを非同期のテキストのやり取りの応酬をしていたら、
なんかめちゃくちゃ大変なことになったなっていう予感しかないんですよ。
パラレルワールドじゃないので、
正直それをやってた世界でどうなったかとの比較はできないんですけど、
少なくとも口頭でやり取りしてよかったなって思います。
なんで、説明させてくださいみたいな感じで、
一回そういうやり取りをするのは非常に良さそうだなって思いました。
テキスト、非同期のテキストはマジでやめた方がいいなと。
あとですね、口頭でのやり取りをしている最中に出てきたのは、
我々チームとしてはベストを尽くして、
結局少し考慮が足りなかった部分があるとは思うんですけど、
じゃあそれを向こうとしては、
エラーが起きたら放置するという方針だったんですか?みたいな聞き方をするわけですよ。
我々はアナウンスするから各チームがやるだろうということで、
楽観的に見ていたところがあると。
エラーが起きたら何かしら対処するかもしれないけど、
ひとまずはエラーが起きてから考えるって考えだったんですよね。
さっきのエラーが起きたら放置するんですか?は、
言い方の問題だとは思うんですけど、
さっきの我々のスタンスと、エラーができたら放置するんですか?は、
そんなに差分ないから、
そういう聞き方をされたら、はいそうですとしか言えなかったなと思うわけなんですよね。
そこから、それは開発者としてどうなの?みたいにすごい言われるんですけど、
いや待てよ、そんなことはないだろうと思うわけですよね。
そこで久しぶりにテクニックを使いましたね。
推論のはしご。
推論のはしご自体は多分いろんな文献で出てきていると思うんですけど、
私がこれに触れたのはあれですね。
組織を変える5つの対話。
そうですね、あってますね。組織を変える5つの対話。
これで一番最初の方に出てきたあれですね。
現代がアジャイルカンバセーションズで、
どちらかというと多分開発者向けなのかなって思う感じの記述なので、
テスト駆動開発ならず、なんだっけな。
12:02
会話をテスト駆動でやっていくみたいなところで
推論のはしごみたいなのが出てきたんですけど、
そうなんですよね。
もちろん我々が何かしら施した変更によってエラーが出たら、
それは対処しますよというところで、
まずそういうことを言わなくて、
じゃあどういう態度だったらいいんですかっていうところで、
そこは責任を持ってやるみたいなことを言うわけですよね。
それはそうだろうなということで、
我々もそういう態度だったと。
それを証明するものとしては、
エラーが出たときに一回そのエラー内容に触れて、
こういうことが起きているんだな、
ただこれは勝手にそれを対処する何かをするっていうのは、
やるとかえって別の問題が吹き起こすかもしれないし、
もうアナウンス済みだし、
各チームで任せるってことはアナウンス済みだったから、
そこは任せようっていうスタンスを取った。
ここの一連までの流れで、
もうすでに向こうが期待している、
自分たちが変更したものによってエラーが起きたら何かアクションをするってことはやってるわけなんですよね。
ここやってますよねっていうところを目線を揃えさせたわけですよ。
無理やりかどうかわかんないんですけどね。
そこが推論のはしごからと。
つまり、相手もこっちも、
開発者としてあるべき態度っていうところのスタートラインはおそらく一緒ですよねっていうところに
持っていくことができましたと。
私は持っていくことができたと思ってるんですけどね。
ということで、推論のはしごは、
久しぶりに使ったテクニックなんですけど非常に有効だったなと。
相手と自分は本当に同じなんですよっていうところの同じポイントがあると。
どこからか何かしらの分岐点はあるんだけど、
分岐点の手前ぐらいまで一緒なんですよというところに持ってきたっていうのがありましたね。
一見事実のように見える評価という攻撃を受けたときということでやってますけど、
今回は口頭で喋るということと推論のはしごをやったよということを言いました。
本当でもタフなコミュニケーションはマジでタフだし、
今も尾を引きずってるんであんまり良くないですよね。
結局その納得感は向こうは持ってなかったとは思うんで、
どうしようかなっていうところでそこを納得感まで持っていくことができたら、
多分完璧なコミュニケーションだったんだろうなとは思います。
そこは勉強中ですね。
ということで今回は一見事実のように見える評価という攻撃を受けたときでした。
それではまた。
