【TsKaigi】「TypeScript 関数型バックエンド開発のリアル」を聞きました

TypeScript 関数型バックエンド開発のリアル

tskaigi.org

伊藤 直也 様(@naoya_ito

株式会社 一休 / CTO

発表スライド

内容メモ

背景

バックエンドを関数型プログラミング寄りの実装で、飲食店システムのSaaSのバックエンドを開発をしているが、詳細についてイメージがわかないという話をよく聞くのでそれに答えるような話。

Domain Modeling Made Functional

概要は、クラスにしてオブジェクト指向で書いていくというのを、ドメインモデルに相当する型をたくさん書いていくというイメージ。

ドメインモデルのステータスが書きかわったというふうに書くのではなく、型が変化したという風に書くのがいいよ という主張

ただ、本だと、usecaseにdomain objectを書いているので、そのようは方法は採用していない。部分的に採用している。

  • オブジェクトの変更は「l案数適用による状態遷移」としてイミュータブルにする
  • 具体的なユースケースは"workflow"として実装
  • ドメインオブジェクトは型で構造を定義する

入力したドメインオブジェクトがワークフローにしたがって新しい状態にどんどん遷移していく。

しかし、業務のフローだと、エラーが途中で挟まるので、Result型を導入することによって管理している。

TsにはResult型がないので、NeverThrowというライブラリを用いている。

ドメインモデルの型は普通に型定義

予約の型としては、ネットからの予約と、別の形での予約のユニオンで表している。

型のコンストラクタを用意して、生成時ロジックなどを記述する

archiveCustomer = (customer: Customer): Customer => ({
  ...customer,
})
customer.archive()

という書き方から

const archived = archiveCustomer(customer)

になる。オブジェクト指向っぽい書き方では、内部状態に命令を与えることで状態を変化させる。

関数的に書くと、イミュータブルが原則なので、状態遷移後のオブジェクトを得るようにするので、状態の変化が明示的。

状態遷移が追いやすい。

上で定義した型と関数での状態遷移を、workflowとしてユースケースを実装する。

Resultを返す関数を合成して一本道の処理フローを作る。

Railway Oriented Programming

上の話の上で、他のアプリケーションの部分とどう繋げるの?

DBに保存する部分もこのように書くの?

→ そんなことない。DBの保存などの部分は普通に行なっている。

基本的に関数型スタイルでやっているのは主にドメイン層。それ以外は従来通りの作りにしている。

入力のIOとドメインロジックと出力のIOのサンドイッチ

→ これはオニオンアーキテクチャ

基本的に操作する関数と、型を同じファイルに定義する。

これは、今までDDDでやってきたこととあまり変わらない。

ではなぜこのようなことをしているのか → 型の恩恵を最大限に活用したい

型を固く定義することで、静的解析の部分でキャッチすることができるようになる。

ここまで聞くと、関数型めっちゃいいじゃんってなるけど、やはり管理が難しいのがResult型パズル。

TsはResult型をネイティブに持っていないのでこの部分が面倒な作業になる。しかし堅牢にはなる。

Haskellとかだと、モナドを用いるとそのようなことを避けることができたりする。

実際やってみてどうか

  • 2年ぐらい開発をしているが、堅牢になったと思う。不具合による障害が少ない。
  • エラーの処理漏れの不具合が少ない。ぬるぽがほぼない。普通に要件定義が間違っていたということになる。
  • unit Testが減る。型自体が保証してくれているところはテストを書かなくて良くなることがある。
  • オンボーディングがちょっと大変

感想

最近よく聞くようになったバックエンドの関数型パラダイムの導入。今まであまりイメージがかっちりとしなかったのだけれども、ちゃんとイメージが湧いた。

型によって堅牢なプログラムが書けるのがとても魅力的に感じた

【TsKaigi】「フロントエンドもバックエンドもインフラも… 全てをTypeScriptで統一したらこうなった」を聞きました

フロントエンドもバックエンドもインフラも… 全てをTypeScriptで統一したらこうなった

tskaigi.org

君田様(トグルホールディングス)

@kimi_koma1111

不動産、建築、記入の三つの業界を統合し、産業インフラを構築することを目指している

発表スライド

発表メモ

TSを利用する前の自分の経験

元々フロントエンドエンジニアだった。主にjsを用いてフロント開発。

最初はtoB向けのwebサービス

次にtoC向けのwebサービス。お金が毎分発生している中での危機感を感じながら開発していた。

jsあるある。の話。

プロダクトのデータをAPIから取得するコード。しかし、取ってきたデータの型がわからない。仮にオブジェクトだったとしても、どのようなプロパティを持っているのかどうかわからないですよね。

(思ったことメモ:あるあるだ。。。)

jsだと、関数の引数にどのような値を入れればいいかもわからない。

わからないことがたくさんあるので、jsで開発していると綱渡りをしている気分だった。

TSを使い始めてどうなったか

tsを用いることによって、どのような型かというのがわかるので、安心して取ってきた値がどうなるのかがわかるようになる。

tsを用いていると、「綱渡り」から「石橋を叩いて渡っている気分」の開発になる!

動かさなくても、型の不一致については知ることができる。

実際にどのような環境で開発をしているか

トグルホールディングス様ではTSで統一されている

フロント:React

バックエンド;Hono

インフラ:pulumi

(思ったことメモ:pulumi知らなかった)

開発はレイヤードアーキテクチャ

各層ごとに責務を分割

環境:GitHub CodeSpace

型について

Zodを採用している

Zodはデータのスキーマで、バリデーションをしてくれる。

そして、Zodで定義したスキーマから、ts上の型を抽出することができるので、スキーマ定義を変更すると、型も変化する。

そして、それらの型をfrontendとbackendで共有している。

(思ったことメモ:APIなどの界面についてのバリデーションなどを変更したときに両方変更するみたいなことをしなくていいの便利だな)

API定義ができるライブラリとして、Zodを応用したZodiosというものを用いている。Zodのスキーマ定義を用いてAPI定義ができる。(便利だ!)

統一したらどうなったか

フロントもバックエンドもメンバーが両方開発することができるようになった。

バックエンドの開発の経験をフロントに活かせたりなどの効果もある。

個人の話

よりプロダクトの価値に貢献できるエンジニアになりたかったため、フルスタックに開発ができるようになりたいという思いで、現職に転職した。現在はTSのおかげでフルスタックに開発ができるようになり、エンジニアとしてもスキルアップできていると感じる。

終わりに

TSで統一した環境は開発者体験が良い!

全体を通しての感想

うちでもtypescript統一で開発をしているけど、コードの共有はできていなかった。現状はモノレポではないので難しいかもしれないが、今回のお話を聞いて、コードの共有をすることの良さを知ることができた。

また、Zodやpulumiなどのツールを初めて聞けたので勉強しようと思う。

【雑記】チームのふりかえりのファシリがうまくできた気がしたのでふりかえり

背景

  • 私はスクラムチームでスプリントの最後のふりかえりの時間のファシリテーターをしている
  • 最近のふりかえりの時間に課題を感じていた
  • 今回、ふりかえりの時間の改善のために、課題に感じているところはどこか、課題を改善するためにはどのようにするのが良いのかを考えてから臨んだ

事前準備

ふりかえりカンファレンスでさまざまな発表を聞かせていただき、今回の振り返りでは「現状のチームの状況に合わせてどのようなふりかえりにするかを考える」というのを実践してみることにした。

現状のチームの振り返りでは、

「スプリント内で出てきた事柄を出す」→「事実についての感想出し+議論」→「あればActionを出す」

というような流れで行なっている。

例えば(実際に出てきたものではありません)、

  • 事柄:「スプリント内の打ち合わせが多い」
  • 感想
    • 話したいことを話せているので問題がないと思っている
    • 進めたいタスクが思うように進まないので大変
    • まだ話したいことが話せていない
  • Action:打ち合わせをできるだけ一日に集約する

といったような感じ

この方法で振り返りを行うことによって、実際に起きた事実についてメンバーで話し合うことができるため、事実を元に簡潔にどのような対応を行うかを考えることができていた。

しかし、現在この方法で三ヶ月ほどふりかえりを行ってきて、私は以下の課題を感じていた

  • 問題の解決策を話し続けるので雰囲気が暗くなる
  • 課題の対処に熱心になってしまって問題の根本的な原因などについて触れられにくい
  • 具体的な問題になっていないような「仕事がしずらいモヤモヤ」みたいなものが共有されない

これらのふりかえりに対する課題に対処するため、あらかじめ解決のための施策を考えてファシリテーションに臨むことにした。

ふりかえり本番

今回の振り返りでは、実際に以下の流れで行うようにした。

「事実出し」→「その事実について理想的にはどのようになっていたかったかを考える」→「あればActionを出す」

今までのフローとは異なり、出てきた事実に対して「理想的にはどのような形になっていたらよかったか」を最初に合意をとることを行った。いわゆる「ありたい姿フレームワーク」の部分適用のようなイメージだ。

例えば以下のような感じ(実際に出てきたものではありません)、

  • 事柄:「スプリント内の打ち合わせが多い」
  • 理想的な状況
    • 打ち合わせに優先順位をつけることができていて、取り組むべきものから取り組めるようになっているようにしたい
    • 打ち合わせしないといけないものはどんどん出てくるので、タスクを止めてでも取り組みたい
  • Action:打ち合わせしなければならないものに優先順位をつけてMustで取り組むものを決める

上記のように、理想的な状況がコンフリクトした場合には、どうしてそれが理想的な状況かを深掘りするように促し、チームとしての唯一の理想的な状態に合意をとるようにする。

そのような形をとった狙いは以下の四つである。

  • ギャップを埋めたいと思う力である「クリエイティブテンション*」によって楽しく問題に立ち向かいたい
  • 理想的な状態を共有するという行為を通して、メンバーの中にある「もやもや」や「言葉にできない働きにくさ」みたいなものをお互いに共有したい
  • 理想的な状態について皆で想像することによって、問題の本質的な部分に気づくことができそう
  • 理想を先に共有し、目指す場所を一つにすることで議論が発散するのを防ぎたい

(*)創造的緊張(クリエイティブ・テンション)|玉川大学の通信教育|玉川大学 通信教育課程

上記のねらいを達成するために、ファシリテーションする上で以下の三つのことに注意して進めた

  • 理想像に合意を取りたいということ、またその目的をメンバーにつたえる
  • 今回出そうな話題が「人vs人」の構造になりやすいことが予想されたので、それを抑制する
  • 「理想の姿フレームワーク」を用いるみたいな用語は持ち込まない(用語を出すと忌避感を感じる方もいるかもしれないので)

終えての感想

これは僕のファシリテーションの腕不足だったと思っているが、予想よりも議論のスコープが広がってしまう。一つの事象について、さまざまな観点での「理想的な姿」が出てくるので、事象を小さくしたり、さまざまな観点での理想な姿を適切に捌くなどをして、メンバーが最も取り組むべき話題に集中できるように促すのが必要だと感じた。

また、メンバーが個々の理想を共有するとき、しばしば「これがチームの理想だ!」という空気が生まれがちになる。しかし、真にチーム全体の理想像に合意するためには、その理想が本当に全員の合意を得ているかを定期的に確認する必要があった。そのため、少しでも疑問に思う場面があれば、「この理想像は〇〇さんの考えと異なるように感じますが、〇〇さんにも理想的な状態ですか?」と意識して尋ねることを心がけた。その結果、メンバー全員で一致したチームとしての理想像を持つことに近づけられたと感じた。

今回扱った事象についての理想を合わせるのに1時間半もかかってしまったが、これによって今までふりかえりで話題に上げづらかった「思い」の部分をぶつけ合うことができたと感じている。直接的なActionこそ出なかったが、理想的な状況のイメージをチーム全員で合意をとることができたことにチーム全体で価値を感じることができた。

そして、「今回のふりかえりはとても良い時間だった!」とメンバーからも言っていただくことができ、心なしかチームの雰囲気が明るくなったのを感じた。

おわりに

色々とやってみて、やはり自分のファシリテーション力にはまだまだ課題があるとは感じた、(どうしても人vs人になりかけてしまうケースがあったりしたりなど)、一方であらかじめ準備をしてふりかえりのファシリテーションに臨むことはとても大切だと実感した。

これからもふりかえりの前には現状のチームの状態に合わせたふりかえりの準備をし、目的を持ってファシリテーションをしようと思った。

おしまい

「春和の候!若手エンジニアふんわりLT Night!」に参加しました!

春和の候!若手エンジニアふんわりLT Night!に参加してきましたので、その記録です。

wakate-funwari-study.connpass.com

概要

connpassより引用

このイベントは、新卒1〜3年目ぐらいまでの若手エンジニア同士の交流を主目的としています。

前半はテーマフリーのLT(ライトニングトーク)会、後半は参加者同士が交流ができる懇親会を開催します!

LT会と懇親会を通して、エンジニア同士の横の繋がりを作りましょう!

一人で参加する予定で、うまく溶け込めるか不安だったのですが、和気藹々とした雰囲気ですぐに打ち解けることができ、いろんなお話をすることができました!

また、登壇されていた方の中には、新卒一年目や学生の方もいらっしゃって、その情熱に素直に脱帽しました。

会場はAKKODiSさん。とても綺麗でした!

各LTのメモ

備忘録として各LTでメモったことを書きます

個人開発でAWSを使いたい

javadogさん (@Javadog_)https://twitter.com/Javadog_

speakerdeck.com

  • 趣味
    • DDD
    • CleanArchitecture

やりたいことはAWSを使ってアプリケーションを動かすこと。しかしAWSが高い。

どのくらい高いかというと、 ECS on fargate + RDSで月20000円

個人開発のアプリを作って提供する時に、ユーザー数と収益が増加していくとして、どのようにアーキテクチャをスケーリングしていくかという提案

  1. 激安サーバー&Firebae無料枠 -> 1600円/month~
  2. 激安サーバー&有料DBaaS -> 4000円/month~
  3. ECS on fargate + RDS -> 20000円/month~

1, 2 の激安サーバー1台でやるには、SPAとBackendのコンテナを両方とも443のポートで動かす必要があるので、リバプロを挟むなどの工夫が必要

DBの切り替えという、だいぶ心理的コストの高い構成なので、これをするにはクリーンアーキテクチャを意識してDBを交換可能にすることが大切だよねという話をされていた。

感想

  • 無料枠がとても大きかったplanetScaleも最近有料になったので無料DBaaSの選択肢がないの大変ですよね。。
  • KVSからRDBへの移行、全然やったことないので、実際にやってみたときのpros/consを知りたい!
  • 個人開発でAWS使いたいのめっちゃわかる。個人開発で使うべき安い構成について知ることができて嬉しかった

「友達にコード送ったら1行にされた」

ひなさん @mi111025

speakerdeck.com

自分の作ったポートフォリオサイトについて友人と話していたら、とても長く書いていたコードを1行にしてもらっちゃった話だった。

HSL色空間知らなかった。

感想

  • HSL色空間全然知らなかった
  • 知識によって冗長だったコードを短くできるという体験すごい。
  • 友人とコードレビューし合える関係がとても素敵だと感じた。

Let's Learn Code Review

RioFujimonさん @RioFujimon

speakerdeck.com

コードの書き方を学ぶことはあるけど、コードレビューについて学ぶ機会はあまりないよねという話

Googleがコードレビューの指南書を持っている。コードレビューをどのような観点でするといいかなどについてなど、説明がいろいろある。

感想

  • Googleからコードレビューのドキュメントが出ているなんて知らなかった
  • コードレビューのドキュメントがあるというのをチームに共有しようと思った
  • できる部分から少しずつ実践していこう!という最後のメッセージがとても素敵

「Result型の次のエラーハンドリング」

そうさん。さん @moso_midnight

speakerdeck.com

jsでtry-catchがしんどくなってくるので、Result型を導入することでエラーハンドリングもType safeにできるという話

感想

  • 関数型言語について全く明るくなかったので、ちゃんと勉強したいと思った。
  • かねてから関数型言語のエッセンスを取り入れることで、全てをType Safeにできるとは聞いたことあったけど、その実例を見ることができてとても良かった。
  • React, TSちょっとできるって言えるように僕も頑張りたい

「記事の一歩目は業務内容から」

yamatai12 さん (taiyama1212)https://twitter.com/taiyama1212

技術記事を1年で100本ほど書いている超人の方。

技術記事書きたいけど何書けばいいかわからない。という方へのアドバイスというような内容だった。

感想

  • 月10本ペースで技術記事書くのとんでもない。
  • 「どういう時が記事を書くきっかけになるよ」というのをまとめてくださっていてとても参考になると思いました。
  • 技術記事としてのアウトプットまだあまりできていないと感じていたので燃えました🔥

Laravelのサービスコンテナを知ろう

Takumi@男子新体操をしてるエンジニア さん (@Ota_Rg_Blog)https://twitter.com/Ota_Rg_Blog

speakerdeck.com

DIの目的から始まり、サービスコンテナ(≒DIコンテナ)はいいぞ!という話につながるお話。

感想

  • テスタビリティが上がるよねという話に共感した
  • 個人的にDI好きなのでとても面白かった

Bloom FilterをJSで実装してみた

kii310 さん (@kii310_nyan)https://twitter.com/kii310_nyan

speakerdeck.com

Bloom Filterという空間効率の良い確率的データ構造をjs(ts)で実装した話。

Bloom Filterについて初めて知ったのですが、簡単に説明してくださった。

イメージとしては、配列に入っているかどうかの判定とかを確率的に行えるというもの?

感想

  • ユースケースとして、キャッシュヒットなど、処理に時間をかけたくないが、最悪偽陰性でも問題ない場合に有効なのなな
  • 初めてBloom Filterという言葉を聞いたのでとても興味深かった

正しいプロファイリング

saitos さん

「推測するな、計測せよ」

というのは物事を推測で語るなという意味ではなく、計測した値に基づいて議論せよという話

なぜプロファイリングするのかという話から、ビジネスに対してどのように利益になるのかなど、網羅的に説明されていた。

感想

  • とても勉強になる内容だった
  • 最近特に、仕事でもパフォーマンスに取り組んでいたので、タイムリーな情報でとても嬉しかった。

ライブづくりの話

こばさん さん (@ynstg)https://twitter.com/ynstg

Mikuのライブをするために、どのように許可を取って人を集めて、会場をセッティングするのかという話。

個人で煙を炊く機械をヤフオクで落札しているのがすごかった。

感想

  • 発表の時にスライド上にコメントを流せるツールを使っていた。僕も何かのLTの時には使ってみたいと思った!
  • 何かイベントを企画して遂行しきるその実行力が凄まじい。見習いたいと思った。

【雑記】社内の読書会の運営って難しいと思った話

今、僕は途中から引き継いだ社内の読書会を運営している。

読書会を始めるにの当たって以下のルールがあった

  • 週に一回業務時間内で1時間行う
  • 強制参加ではない
  • 初回に集まったメンバーで本を決める
  • あらかじめ読んできて、読んできた内容を元に集まったメンバーで議論をする
  • 対象はエンジニアチーム全体

このルールを元に今まで4冊の本を読書会で扱ってきている

最初に読み始めたのはチームについての本。次にアジャイルについての本。ここは結構盛り上がった

三冊目に選んだ本は、クラウドサービス関連の本。目的としては社内のスクラムチームのメンバーのみならず、幅広い人に来て欲しかったからだった。当初の狙いを完全に満たすものになったわけではなかったが、まずまずの参加者が来てくれて、盛り上がった。

三冊目を読んでいるあたりから主体的に運営を任せてもらっていた。

四冊目は、ソフトウエアのアーキテクチャなどについての本。今では3~4人の参加者まで減ってしまっていた。


ここで、私は、だんだんと参加者がいなくなってしまうことに焦っていた。

それは1冊目、2冊目に読んだ本の内容をチームで共通言語として得たことにより、それを土台として議論を行うことができるようになった体験を持っていたからだった。

参加者が多ければ多いほど、同じ書籍を読んだ人同士で共通言語を作ることができる。このことによって、チームのレベルがボトムアップしたような体験が、私の中に良い体験として残っていた。

そんな私の理想像とは裏腹に、読書会の参加メンバーは減っていった。


しかし、人数が少ないと読書会の価値はないのか。

よく考えれば、断じてそんなことはない。

毎週興味持って参加してくれるメンバーがいて、本の内容について議論できる状態が作れているのはそれだけで価値があるはず。

そもそも自分が読みたかった本を強制的に読み進められるだけで価値があるじゃないか。

私は暗黙的に目的を「共通言語の醸成」と位置付けていてしまっていて、そうならなかったからだめ!と考えてしまっている節があったことに気づいた。


そもそも、多くの人に来てもらえる施策をしていただろうか。参加のハードルを下げるだけでは、「参加したい」、「参加しなきゃ」と思えるような読書会にすることはできないだろう。

目指すかどうかは別として、もし、本当に多くの人に参加してもらう必要があるなら、今の進め方はあまり得策ではないと感じた。本の選定プロセスや、募集の仕方など、多くの人に来てもらう方法をちゃんと考える必要があると感じた。

まとめ

私はゆるく読書会を運営していたが、人が減ってきたことに焦りを覚えていた。

しかし、そのことに対して何も策を講じていなければ人が去っていくのは自然なことであるし、それは良くないことであるという前提も正しくはないと感じた。

多くの人で読書会をすることに価値はあるが、多くの人に集まってもらうには、そのための施策は別途行う必要があると感じた。

ただ、ひとまず今の読書会に集まってくれている人たちと、楽しく読書会ができればそれでいいと思った。

おしまい

1on1で理想的なチームってなんだろうという話をした

1on1にて、

自分の理想とするチーム像と、EMが理想とするチーム像にギャップがあった。

私の思い浮かべる理想的なチームとは

  • 部活のような、文化祭前日のクラスのような、熱を帯びて一つの目的に対して立ち向かっていて
  • チーム内のコミュニケーションが活発で
  • お互いを信頼しあっている

そんなものを想像していた。

私はこの状態を目指すべきだと思っていたし、現状のチームと理想のギャップを感じてた。

しかし、EMさんと僕とでチームの理想像に関する考えは異なっていた。

EMさんの考えとしては「団結!!って感じのチームではなくとも、異なる価値観を持つメンバーが、最大限能力を発揮できるようにする。その中で理想のチーム像を作っていくのでは?」という考えだった。

私がトップダウン的に理想を体現しようとしているのに対して、EMはボトムアップ的に個の力を最大化しようとしている。

チームというのはチームの数だけ性質がある。それぞれのチームの理想的な姿は異なるもの。

どのチームも目指すべき絶対的な理想があるのではなく、チームの数だけ目指す場所があるのかもしれない。

自分はEMさんのような考えを今までしてこなかったので、目から鱗だった。

何が正しいかわからないけれど、もっと考えていこう。

おしまい

ふりかえりカンファレンス「LT」を聞きました

スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた

confengine.com

内容メモ

品質と効果を高める方法の計画→これは反省会にしないための目的

過程を検査する→仮説を持った真因の探求→努力・根性で終わらせない。 Good Problem Result→結果の代償や良し悪しには問わない

これを対話する→報告会ではない。

いろいろ話し合った中で、最も役立つ変更を特定する。

スピードも重要。できるだけ早く対応する。

感想

スクラムガイド、もう一度ちゃんと読んでみようと思いました。報告会ではない、だったり、最も役立つ変更を特定するだったり、ハッとしました。

2プロダクトをコネクト! 同時開発のしんどさと楽しさと心強さと

confengine.com

内容メモ

2プロダクトをコネクト!同時開発のしんどさ

2プロダクトを同時に見るチームをやってきた。

ここで起こったこと。

  • ドメイン言語知識がバラバラで、フロントとバックに分かれちゃった
  • プロダクト切り替える認知負荷が厳しい

→まずプランニングを変革:必ず終わるようにする スクラムの「確約」から

1スプリントで1プロダクトにすることにした。

プロダクト間の優先順位は PdMに喧嘩してもらって決める

感想

僕も今、2プロダクトを見ているのに近い状況だけれども、1スプリント1プロダクトにするなどのテクニックは応用できそうだと感じました。確かに、2プロダクト見ざるを得ない状態になっていた時はインクリメントが終わっていました。

しくじり先生 〜ふりかえり手法はチームのイマとコネクトして〜

confengine.com

内容メモ

振り返り手法の選択はチームの今とコネクトするのが吉!

チームの状況、スプリントの状況、振り返りの雰囲気を踏まえた上で、どのような振り返り手法を試すのかを考える必要がある

感想

他のセッションでも話されていたけれども、やはり戦略的にチームの状況を考えて振り返りの手法を考えることが大切だなと感じました。

多職種で実施したふりかえりで基本的なことに気付かされた

confengine.com

内容メモ

  • 6人で全員違う職種
  • 手法はKPTA

-> 2回目らへんに異変が発生。振り返る対象、着眼点

しかし最後には、観点などが揃ってきた。

5回目には振り返りの理解度が上がったと回答。

感想

ふりかえる目的の共通認識化が大切。参加者同士の目的がコネクトしたことが、最後のふりかえりの改善した感の原因だった