記事のサマリー（TL;DR）
- SmartHRのスクラムチームがKPT振り返りに「感謝付箋」セクションを追加し、専門性を尊重する文化を仕組みで担保
- 感謝の効果は「ありがとう」スタンプではなく「何が助かったか」を具体的に言語化することで最大化
- 生成AIで試行錯誤が速くなるほど、専門家レビューの頻度は増し、感謝を伝える信頼関係の重要性は下がらない
SmartHR × クロスファンクショナルチームの文脈で読み取れること
SmartHRは、エンジニア・デザイナー・QA・プロダクトマネージャー・UXライターが同一フィーチャーチームとして動く体制を取っています。この構造は、kintoneやSalesforceなど業務SaaSをRailsで補完したり、複数のSaaS担当者が同じプロダクトに向き合う体制と共通点があります。職能を横断するチームほど「お礼の一言」が属人知の共有を促し、次の協力を引き出す起点になります。
生成AIの普及により、専門外の領域に個人が踏み込む速度は上がっています。その分、コード・設計・文章のレビューを専門家に依頼する頻度も増えます。SmartHRの実践は、「レビュー依頼後に何が助かったかを一言添える」という小さな行動習慣が、AI活用が進む開発現場での信頼コストを下げるという示唆を含んでいます。
詳細
ゲームが示した「感謝の循環」
SmartHRの人事評価機能を担当するプロダクトエンジニア・70snow氏は、住民のお願いに応えると感謝の言葉が返ってくるゲームにはまった体験から着想を得ました。チームメンバーの「ただ木を切って運んだだけで褒められる。普通に過ごしているだけで存在価値を認められる社会」という一言がきっかけです。
「お願いを達成する → 感謝される → やる気が出る → またお願いを達成する」という好循環は、プロダクト開発チームにも転用できると70snow氏は考えました。
専門性を補い合うチームに感謝が効く理由
SmartHRのフィーチャーチームは、エンジニア・デザイナー・QAエンジニア・プロダクトマネージャー・UXライターで構成されます。自分では「あたりまえ」と感じていることも、他の職能の人から感謝を伝えられることで強みとして認識でき、前向きに仕事へ向き合いやすくなります。
また、SmartHRでは個人が複数の職能に踏み込む「クロスファンクショナル実践」も推奨しています。専門外の領域を学ぶ際に、教えてくれたメンバーへ感謝を具体的に伝えることで、こうした動きが加速すると70snow氏は述べています。
KPT振り返りに「感謝付箋セクション」を組み込む
チームが採用した具体的な仕組みは以下の通りです。
- スクラム開発の振り返りで KPT（Keep・Problem・Try）の三項目に加え、そのスプリントでやってもらったことへの感謝を書く付箋セクションを設置
- 「ライブラリの脆弱性対応などの差し込み対応をいつもありがとうございます」のような、具体的な行動に言及した付箋を贈り合う
- 個人の心がけだけに頼らず、仕組みとして感謝を伝える機会をプロセスに組み込む
チームで試せる小さなアクション
- レビューや相談のあとに、何が助かったのかを一言添える
- 振り返りのなかに、感謝を伝える時間や付箋の枠をつくる
- 褒められたこと・感謝されたことを、自分やチームの強みとして見直す
70snow氏自身は「ありがとうございます」のスタンプで済ませることが多かったと振り返り、今後は何が助かったのかを言語化して伝える機会を増やすと述べています。
well-working との接続
SmartHRが掲げる well-working（誰もがその人らしく働ける社会をつくる） という考え方と、感謝を伝え合う文化は直接イコールではありません。ただし70snow氏は、職場の信頼や働きがいの土台として、「その人らしく働く」に地続きのものとして実感していると述べています。
生成AIが進んでも感謝の言語化は残る
生成AIの普及でコード・文章・設計案を短時間で試せるようになり、個人がカバーできる範囲は広がっています。一方で、試せることが増えるほど専門家によるレビューを依頼する場面も増えます。最終的な意思決定と責任は人間が担うため、各分野の専門性が判断の根拠となります。
70snow氏は「レビューや相談をただ依頼するだけでなく、何に助けられたのかを言葉にして伝えることが大切」と結論づけています。生成AIで試行錯誤の速度が上がっても、専門性を尊重し感謝を伝え合える信頼関係の価値は変わらないという見解です。