振り返りの重要性と成功・失敗の捉え方
じゃあ、naminami.fm始めていきます。お願いします。 お願いします。
swat
今日は、社内のメンバーと話していて、ふりかえりってどうするのがいいんだろうねとか、
成功した時ほど、ちゃんと振り返った方がいいよね、みたいな話があって。
個人をエースとして、ふりかえりってどうしてたかな、どう考えてるかなっていうのを話せればなぁと思ってます。
はい、よろしくお願いします。 よろしくお願いします。
で、自分からなんですけど、メンバーと話してて、成功した時ほど、失敗はよく振り返りますけど、成功した時ほど振り返った方がいいよね、みたいな話を
していて、まあそれは確かになぁと思いつつ、成功か失敗かで分ける必要があるのかなっていうのを考えていて。
で、自分が持っているのは、プロセスを振り返るっていうのが大事なのかなと思ってまして、
成功か失敗かっていうのが、ものにもよりますけど、外部要因で決まるものが結構ある。
プロジェクトが成功したか失敗したかみたいのは、なんか割り込みがあったとか、メンバー抜けたとか、まあそういうのもあったりして、
単純に成功か失敗かだけでは、成長できているのかっていうのは測れないところもあるのかなって言って、
成功の可能性が高いプロセスを作れていたか、再現性を高められるような動きができていたかっていうのを振り返れるかどうかっていうのが大事なのかなと思ってます。
なんか例としては、サッカーでゴールできたかできてないかだけで判断してたら、ゴールできない試合も全然ありますし、なんか変にゴールしちゃうときもあって、
うっちー
天地ゴール?
swat
天地ゴール。ゴールだと。
で、ゴールできたかだけで判断すると、なんか力ついてるのかよくわかんないなみたいな、何直せばいいかわかんないなみたいなものになっちゃうですけど、
たぶんそうじゃなくて、ゴールに持っていくまでの展開を良い展開作れたか、みたいなところを振り返る、振り返ってるんだろうと思っている感じですね。
まあちょっと自分がサッカー経験ないので。
うっちー
サッカーの記念にサッカーの礼をあげる。
swat
そうですね。そういうことかなって想像ですけど。
で、なんかブルーロックの漫画の中でも再現性のない成功体験に価値はないっていう話をしていて、
ゴールに持っていくまでの再現性を高める良い展開を作れる、そのためのできる改善点を振り返るみたいなことができるし、
swat
そこのプロセスを振り返るってところが振り返ってみる肝なのかなと、こういうのを思っています。
アジャイル開発における振り返りの種類
うっちー
なんかスプリントレビューとスプリントレトロスペクティブで両方とも振り返りなんですけど、
レビューの方は結果の方を振り返る、その出来上がった成果物に対してどうだったのかっていうところを振り返って、
それに対してのアクションは次の機能を考えるとかになって、
それってなんかプロダクトをどんどん良くするみたいな方向ですけど、
うっちー
スプリントレトロスペクティブの方は開発プロセスが対象、振り返りの対象なんで、自分たちがどういう動きをしてたかみたいなところ、
今渡邉さん言ってた、その再現性というか、成功体験とゴールまで持っていくまでの途中プロセスのところは、
まさに、アジャイルだとスプリントレビューとスプリントレトロスペクティブで分かれてるなっていうのを考えてましたね。
swat
なるほど。振り返りってざっくり見ると対象物の違いで分けられる。
なんかスプリントレトロスペクティブのレトロスペクティブってなんか言いにくい名前のままにしてるのは、
一般的というか振り返りって言葉とちょっと分けるみたいな意味合いもあるっていうのを。
うっちー
振り返りというのが、ルックバックっていう言葉とレトロスペクティブとあって、
ルックバックは単純に振り返るっていうか、背中を、ルックバックって映画、映画じゃねえわ、アニメ、漫画がありますもんね。
swat
映画もあります。
うっちー
あれはなんか背中を振り返るみたいな、過去を見るみたいな方向ですけど、単純に後ろ見るだけなんですけど、
レトロスペクティブの方はレトロっていうのが前の方でスペクティブって視点っていう言葉なんで、
後ろを過去を振り返る視点みたいな意味があって、
それこそアジャイルとかでいう振り返りの方は単純に後ろを過去を見るだけじゃなくて、
ちゃんと視点として見て、それを経験に生かす、次のスプリントに生かすっていう方向だとレトロスペクティブの方が多分合ってる意味なのかなと思いました。
swat
スクラムの三本柱かなんかは、透明性と、検査と、ちょっと見積み忘れちゃいましたけど、検査みたいなところが、
スクラムに関しては重要な要素であって、2週間とかに切ってるのも、2週間のうちに収まらなかった、
swat
なんか目標としてた機能が実装しえなかった、じゃあ何が改善できるんだろうみたいな、
この振り返りって言っちゃいますけど、振り返りしやすくするためにタイムボックスを切ってるみたいなのもあるので、
単純に成功か失敗かってことではなくて、プロセスをより良く改善し続けるための仕組みがスクラムの中にはあるんだろうなっていうのは確かに思います。
ソフトウェア開発における振り返りとフィードバックループ
swat
開発プロセスはまあ、それはそれとしてあって、あとソフトウェア設計とかコーディングとかっていうところを振り返るにはどうしたらいいかみたいのも考えていて、
一人で振り返ろうと思うと、理想形を知っていれば振り返れるっていうか、理想形知っていれば自分とのギャップ、今の自分のコーディングか設計とのギャップを見て、
あの子ができなかったのかなーっていうのがあって一人で振り返れるんですけど、ソフトウェア開発だと理想の形っていうのが状況によって変わるので、この時の理想って何だったのかなーみたいのは毎回変わるし、
まあこれっていうものもなくて、どうやって振り返るかって思うと、後で返しをもらうっていう表現をしてるのをアカデミーだったんですけど、
swat
コードとか設計書いて、数ヶ月後とかでそのコードをまた触ることがあった時に、すごい変更しづらいとか、バグが潜んでたとかすごい読みづらいとかっていう、
そこで初めて気づくみたいのがウェア開発だとあるなーと思っていて、着地が見えなくなっちゃったんですけど、その振り返しをいかにもらうかというか、
フィードバックループというのか、実装してみてあれこれダメだねっていうのをいかに早く気づくかっていうところをうまく回せると、ウェア開発の中での振り返りというか、改善みたいのは済むのかなーって思う
うっちー
基本はフィードバックサイクルが回るっていうのが振り返りの目的だし、成長にはそのフィードバックサイクルが必要になってくる。
フィードバックサイクルをアクションした人に戻さなきゃいけないし、サイクル自体を早くしなきゃいけない、早くしなきゃいけないというよりも早くしたほうがいっぱい成長できるっていうのがありますもんね。
今のアーキテクチャの話だと、なんかDevOps出る前とかだと新機能開発する人と保守担当が別れてて、新機能開発した人のミスみたいな設計のミスみたいなのをフィードバック返ってくるのが別チーム、保守担当チームに執笛返しが来る状態になってたから、
自分にフィードバックが返ってこないんですよね。それだとそもそもフィードバックサイクルが出来上がってないので成長していかないとか、無限に新機能を作ってる開発チームの不具合というか成長がされないから良くなっていかない。
自分たちにフィードバックサイクルが返ってくるから、アーキテクチャーのところも同じようにアーキテクチャー設計しておしまいじゃなくて、そこを保守して自分にあの時の失敗があったから不具合が出ちゃった、技術的不採がなくなってしまった。
止まっちゃったみたいなことになるから、次のアーキテクチャーを作る時の過程になるですもんね。
そうですね。開発と運用は両方やると総合成長できるというか、開発した結果を自分で運用してみて、運用してみるとバグとかログの分かりづらさとか、変なところでラグあるとかが分かって、それが開発に生かされて、
swat
それがまた運用を良くしてみたいな、開発と運用のループっていうのがしっかりあります。
うっちー
今、サイクルを同じ人に回ってくるようにするっていうのが話ですけども、一個は早くするっていうのがあって、
響け！ユーフォニアムから学ぶ試行錯誤と成長
うっちー
さっきレトロスペクティブとスプリントレビューとレトロスペクティブの話しましたけど、スプリントレビューっていうとあれですけど、プロジェクト完了したタイミングでそのプロジェクトがどうだったのかという振り返りをすると思うんですけど、
そのタイミングって完成物としてもあるんで、プロジェクト終わってるから、完成物がどうだったのかっていう評価だったりとか、振り返りにフォーカスしがちだと思うんですよ。
でも、レトロスペクティブというか、そのプロセスの途中、プロジェクトの途中で振り返りをしていくと、結果がない分、今まだどうなるかわかんないけどなんか違和感があるみたいなところにフォーカスできるんで、
仮説しかないんですよね。本当にそれが問題なのかもわかんないし、こうしてみようっていうのも本当にうまくいくかわかんないから、仮説を立ててそれを実行してみて、またそれでうまくいったらダメだったからまた変えるっていう方向になる。
だから、プロジェクト完成待って、最初の話で言うと成功したのか失敗したのかっていうのを待ってから評価して、次のアクション決めてると多分すごい長くなっちゃう、フィードバックサイクルが長くなるんで、
うっちー
短くしようと思うと成功失敗になる前に、プロセスの途中で振り返りをしていくっていうのが多分スピード感あるんだなと思ってましたね。で、最近アニメを、学園モノのアニメをよく見るんですけど、
響け!ユーフォニアムを最近見るようになったんですよ。10年ぐらいやってるんですかね。
swat
そんな経ちます?見てはないですけど、タイトルは知ってます。
うっちー
今、9月になんか最後の映画がやるみたいなのをやってました。
そもそもなんか僕、うちの息子が中学の時に吹奏楽やってて、それでちょっとこのアニメに興味あって、最近アマプラで見れるようになったんですよ。
だから見てたんですけど、これ見てると高校生の時って3年しかないじゃないですか。
で、高校生というか吹奏楽部だとなんかコンクール?コンテスト?なんか全国大会を目指してるんですけど、それって1年に1回しかないから、
それをその結果、なんか銀賞取った銀賞取ったとかを振り返って、じゃあ次どうしようってやってたら3年間終わっちゃうんで、
3回しかやれないから、3回というか2回しか振り返りかせないんで、もう3年経ったらもうおしまいだからね。
だからそういう結果を見て成長していく、振り返るってことはしないと思うんですよ。
で、高校3年間で成長していこうとしたら、なんか他のフィードバックの絵方としては先輩に教えてもらうとか先生に教えてもらうとかやると思うんですけど、
それも結局1日待たないと部活の時間しか見れないとか、先生も1人しかいないんで、
吹奏楽部ってめちゃめちゃ人数いるから、その先生に見てもらうまで待たないと成長できないってなってるとすごい時間かかっちゃうんで、
やっぱり自分で個人練習して、そこで成長していくっていうのが必要なんですけど、その時ってフィードバックが得られないじゃないですか、
先輩に教えてもらうとか先生に教えてもらうって個人練習だとできないんで、その時に主人公がどういう息遣いで、
どういう息の強さで吹けばいいのかっていうのをめちゃめちゃ試行錯誤してる、あ、吹けなかった、吹けなかったか、吹けなかった時に、
なんかその息遣いをどうしたらうまく弾けるんだみたいなのをすごい試行錯誤してるシーンがあって、
なんかそれがレトロスペクティブの部分にすごい開発プロセスの改善に近しいなと思って、
どう吹いたら正解なのかっていうのはわかんないけど、多分なんか失敗ばっかり見えてるんですよね、
なんかうまく弾けないっていうダメな状態が見えてて、でも多分1000回とかやってると1回だけうまくいく、
一瞬うまくいく時があって、あれなんでさっきのうまくいったんだみたいなのがわかって、
でも次やったらそれと同じものを再現できないから、何回も繰り返していくと1000回に1回だったのが100回に1回成功するようになって、
10回に1回成功するようになって、だんだん毎回成功できるようになるっていうのがあるから、
そういう仮説を立ててどうしたらうまくいくのかっていうのをすごい試みていくっていうのは、
多分これって意識的に振り返りしてるっていう、個人練習の時はイメージしてないですけどやってることって一緒だと思うんですよね、
うっちー
なんか1回吹いてこれじゃダメだなって思うから、次はもうちょっと弱くするのか強くするのかっていうのを変えてみるっていうことで、
試してみてその結果を見て、また次どう動くのかっていうところを無限に繰り返すっていうのが振り返りだから、
一番それを究極に短くすると個人練習の副練習、ユーフォニアムを弾いてた主人公が練習してたのになるなっていうのを思ってましたね。
そういうことがそういう方向にやれると、結局すごいサイクルで学びを積み重ねて成長していくんだなと思います。
長期的な視点での振り返りと組織的成長
swat
そこのポイントはいい音をわかってるっていうのが大事だよね。
うっちー
これがいい音だ。
その主人公は先生に指摘されてて、なんか弾けないんですがっていう指摘をされてて、自分も弾けないっていうのがわかってて、
隣にユーフォニアム弾いてる先輩がいて、その人めちゃめちゃ上手いんで、笠橋さんみたいに演奏できるようにっていう先輩が背中を見せられてる状態ではあります。
だから型っていうのはね、先輩が見せるものにあったりもしません。
swat
見える環境、見えてると一人でも変えて成長していくってことを。
響きユーフォニアムに聞いてて、自分別の視点でちょっと思ったのがあって、
最後これかもしれないですけど、学生だとその3年の間でやりますけど、
先生は何年も見るわけじゃないですか、入れ替わっていく生徒。
そうっすね。
swat
その中で吹奏楽部が金賞を取るためにはどういう指導をしたらいいのかとか、
っていうのを先生は年単位のフィードバックループでやっていくというか、
1年やってみて、金賞取れなかった、あ、じゃあダメだ、おっとっと違うのやろうとか、金賞取れた、今回はこれが良かったみたいなのをやっていくっていうのが、
swat
エンジニアのアーキテクチャ設計みたいなところもちょっと似ているのかなと思っていて、
単機能とかだったら効果出るのは結構すぐ、数ヶ月後とかかもしれないですけど、
もっと大きくインフラ構造とかクラス設計とか、チームが開発しやすいようなチーム体制作るとか、
そういうのの効果が出てくるのって半年とか1年後とか、実際にプロダクトがスケールしてきたときにそれにちゃんと耐えれるかとか、
スピード維持できるか、スタイルが増えてないかとか、そういうので見えてくるなと思っていて、
swat
自分が今メイブ10年以上でコミックフェスタのサービスを何年前、1年かぐらい前にリニューアルをして、
その時に初めてぐらいしっかりアーキテクチャ設計してやりましたけど、
swat
今になって、当時もうちょっとこうしてたら今違ったのかもなーみたいな点がボロボロ見えてくるというか、
っていうのがあって、それは自分が7,8年今その会社にいるんでもらえた支払い師というかフィードバックがあって、
そこは個人的に長くその会社にいたから得られた経験かなっていうのがあって、そこはいいなと思ってますね。
うっちー
ですよね。確かに高校生って3年間しかないから、で多分3年生って最後だから、もうラストがないから、
それ以上改善するっていうよりもそこで出し切るっていう方向になるけど、先生は無限に、無限ではないけど、
国境的に改善し続けるんで、そっちの方が自社開発のプロセスに近しいすんで、
結論はみんな長くウェーブに勤めましょうっていう話ですね。
swat
長く行っていただいて、多分なんか1,2年とかで僕が移っていくのもちろんそれはそれなんです。
自分がやった実装した機能みたいなのが、とかシステムが年数経ってどうなったかなみたいなのが、
swat
見れる機会があれば見れるとすごく経験値になるというか、
当時の設計とか、作った機能みたいなのが良かったのかみたいなのが対応できていいんだろうなと思う。
ですね。なんか新規を渡り歩いてるだけだと多分そういう経験できないから、
1個のプロジェクトに長くやるっていうのはもう1個成長にはいいかもしれない。
swat
今日はこんなところですかね。
終わります。お疲れ様でした。
うっちー
お疲れ様です。