<p>いつもはKPTベースで振り返りをやっていますが、KEEPがあまり出てこなかったり、PROBLEMに付箋が集中したりと、ストイックな会になりがちです。それ自体は悪いことではないのですが、もっと前向きで楽しい会にできないものだろうか、みんなの成果を称えられないだろうか、と考えていたところ、<a href="https://mobile.twitter.com/yykaoruko/status/1458567788075749377" target="_blank" rel="noopener noreferrer">@nozawabit</a> さんのツイートが流れてきました。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">KPTではないのですが、この記事の内容をカスタマイズしてレトロしたところ、Kがよく出て、自責以外のPも出るようになりました！Kが「ドやりたいこと」「感謝したいこと」「続けたいこと」にあたり、PとTが「聞いてほしいこと」「変えたいこと」にあたると思っています。<a href="https://t.co/9e3GMoWTfY">https://t.co/9e3GMoWTfY</a></p>&mdash; nozawabit (@nozawabit) <a href="https://twitter.com/nozawabit/status/1441273533355548688?ref_src=twsrc%5Etfw">September 24, 2021</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><p><br></p><p>こちらで紹介されているフォーマットを試してみたところ、かなり充実した振り返りになったので、気づきを書いていきたいと思います。</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/c8e23e8b647040749e2ffcae2ee21af4/retoro-2021-12-30-11.47.11.png" alt="" width="1776" height="1148"></p><p><br></p><h2 id="hf29c819954">ポジティブな付箋が増えた</h2><p>KEEPがドヤりたいこと・感謝したいこと・続けたいことというラベルに変わっただけで、かなりポジティブな付箋が増えました。また、個人と他人のがんばりに目をむけることで、個人の特性やチームの良いところが見えたりもしました。</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/db4c6077b284405cac00658d4d2f3c77/retoro-2021-12-30.png" alt="" width="1988" height="1278"></p><p>テストのカバレッジに貢献して足場をガンガン整えていくメンバーもいれば、複雑な案件を着実に進めてきたメンバー、チームのファシリテーターをやってきたメンバーもいます。みんな、それぞれの形でコミットしているんだなと、全員で改めて実感できたのがよかったです。</p><h2 id="h5da4fb9b7d">コミュニケーションがスムーズになった</h2><p>聞いてほしいことと変えたいことを分けることで、解決すべきことと愚痴の線引ができて、コミュニケーションがスムーズになりました。付箋を書くときにも、まず「これは解決するべき問題なのか？」と考えることができます。問題点は無限に出てくるし、すべて議論していたらいくら時間があっても足りません。</p><p>また、「聞いてほしいこと」があることで、問題視するほどではないことを、発散できるのも良いです。</p><h2 id="hedaa0e43be">気持ちを話しやすくなった</h2><p>気持ちに寄り添ったラベルにすることで、気持ちの問題を話しやすくなったと思います。特に印象的だったのは「チームに遠慮することをやめたい」「土下座絵文字の濫用をやめたい」というトピックです。これらは従来のKPTでは出づらい内容だったと思っています。</p><h2 id="ha214098e44">まとめ</h2><p>感情的になるのは一般的に良くないと言われるけど、感情があるのはあたりまえのことだと思います。自分の思いや考えを素直に表現し、がんばりを称えられるチームでありたいです。気持ちに寄り添った振り返りをすることで、相互理解が深まり、心理的安全性が高まったのではないかと思います。</p><p>また、フォーマットによって振り返りのアウトプットがかなり変わることがわかったので、フォーマットの特性を理解して、状況に応じて選択できると良いと思いました。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">ラベリングって結構大事なんだな〜<br>人の動きがほんと変わる気がする。<br>抽象化しすぎるより、コミュニケーションとか感情に寄り添ったラベルのほうが、意図を実践しやすいんだろうな〜とか思った</p>&mdash; カオルコ (@yykaoruko) <a href="https://twitter.com/yykaoruko/status/1458567788075749377?ref_src=twsrc%5Etfw">November 10, 2021</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><p><br></p><p>振り返りは奥が深い。</p>

気持ちに寄り添った振り返りを実践してみた

<p>この記事は <a href="https://qiita.com/advent-calendar/2021/yamap-engginers" target="_blank" rel="noopener noreferrer">YAMAP エンジニア Advent Calender 2021</a> 3日目の記事です。</p><p>YAMAP開発チームのカオルコです。</p><p>今年の8月からプロジェクトリーダー兼フロントエンド開発者として奮闘していました。今回はそこで得た学びを振り返ってみたいと思っています。&nbsp;&nbsp;かなり抽象的なポエムになりそうです。&nbsp;&nbsp;</p><h2 id="h9a28ba33b0">どんなプロジェクトなの？</h2><p>私が参加しているプロジェクトでは、ビジネスサイドの理想や目標を達成するために、どのようなHOWをやっていくか、主に開発チームで検討するスタイルをとっています。</p><p>渡された仕様書通りに実装するのではなく、エンジニア自らがものづくりに参加できるのはかなりわくわくする環境です。</p><p>参加しているのは探索的かつ実験的なプロジェクトであり、目標数値が明確でないことが多いです。また、部署の縦割りもゆるやかで「できることはできる人がやる」というtheベンチャー風土があるため、いろんな面で不確実性が高く、自分には少し背伸びしたプロジェクトだと思います。</p><p>チームメンバーにフィードバックをもらったり、1on1で壁打ちしてもらったりして学んだ、6つのことを書いていきたいと思います。</p><h2 id="h3169d2b998">1. ミーティングは準備が8割</h2><p>「たくさんミーティングをしているのに、なぜか前に進んでいない気がします」</p><p>これが一番初めにもらったフィードバックでした。ミーティングで大事なのは、アジェンダとゴールを明確にしておくことだと思います。ただ、それだけでは不十分なのだと気づきました。ゴールに辿り着くために必要なものは何か、ステップ数はどれくらいになるか、ゴールまでのプロセスを想像することも重要なのだと思います。</p><p>YAMAPの開発プロセスはかなりデータドリブンで、データなしにディスカッションすることはほとんどありません。意思決定するために十分なデータを用意して、事前に自分なりの考えをまとめておくことを学びました。叩きがあるとゼロベースより議論がしやすいです。</p><p>また、あらかじめデータや考えを共有しておくことも大事です。時間を有効活用できますし、足りない情報を指摘してもらえたりします。</p><h2 id="he54dd261fc">2. スケジュール調整の落としどころを考える</h2><p>予定通りに開発が進んでいたとしても、思いもよらぬところでハプニングは起きるものです。ユーザーさんへの周知や他部署との調整、社内からの熱烈なフィードバックなど、プロダクト開発は、実装してリリースするだけではありません。</p><p>関係者を明確にしたり、リスク管理をしておくことはもちろん重要なのですが、何かあった時に最善の落とし所を見つける冷静さを持っておくことが大事なのだと思います。</p><p>ちょっとぐらいなら無理をきかせて、計画通りにやりたくなっちゃう気持ちもありますが、リスクが見えたら、冷静にスケジュール調整を検討するのが良いと思います。本当に、つい走り切りたくなっちゃうのだけど。（若干体育会系マインド）</p><p>スケジュール通りに進むことが大切なのではなく、ハプニングは起きる前提で、丁度良い落としどころを見つけるために調整していくことが大事なんだと学びました。</p><h2 id="h09f49fa04c">3. 「ご近所さん」を探せ</h2><p>ソフトウェアの開発手法であるアジャイルの中に、インセプションデッキというドキュメント作成のフレームワークがあります。</p><p>これはプロジェクトの全体像（目的や背景など）を端的に伝えるためのものです。問いに答えていく形でドキュメントを作成していくのですが、その中に「ご近所さんを探せ」があります。簡単にいうと、自分たちを中心に、プロジェクトに関わる人を図式化するものです。わたしはこれを軽く扱ってしまっていて、他のチームに少し迷惑をかけてしまいました。</p><p>自分たちにも都合があるように、他のチームにも都合はあるものです。はじめに関係者を洗い出して明確に言語化しておくと、早い段階で展望を伝えておくことができるし、リスク回避にもなります。助け合いもできます。ご近所付き合いは大切です。</p><h2 id="h02f9b1c543">4. 目的と同じくらい目的じゃないことが大事</h2><p>目的を明確にしておくことは何事においても大事なことです。そして、目的に対して「どこまでやるか」も重要な論点の一つです。</p><p>もし「目的じゃないこと」を決めていなければ、議論はどこまでも発散していくと思います。アイデアは縦にも横にも広がり、その一つ一つに意見が飛び交い、コミュニケーションにかかる時間は増え、意思決定の難易度はぐっと上がります。&nbsp;&nbsp;</p><p>最初に目的じゃないことを定義しておくことで、議論のスコープが明確になり、より目的に集中できることを学びました。</p><p>目的と目的じゃないことの言語化はプロジェクトメンバー全員で行いましたが、良い取り組みだったと思っています。一言一句レベルで定義を話し合うことで、小さな違和感の擦り合わせがかなり上手くいったと思います。</p><h2 id="he3ec817712">5. すぐに解決しようとしないこと</h2><p>わたしはかなりせっかちです。何かしらの問題報告を受けると、「では、こうしましょう」とすぐに解決してしまいたくなります。</p><p>社内・社外問わず、仕様に対してたくさんのフィードバックをいただきますが、それはどんな問題なのか、その問題は誰のものなのか、よく考えもせず場当たり的に解決してしまうのは、よくないです。というのも、解決策には新たな問題をはらんでいることが大いにあるからです。また、問題だと思っていることは、実は問題じゃなかったりもします。</p><p>解決するのではなく、問題定義をすることが重要なのだと学びました。そして、問題定義に正解はありません。やってみて、違ったなってなることもあります。なぜ違ったのか、本当の問題は何だったのか、どこまでも向き合い続けることが大事なのだと思います。</p><h2 id="h5abf467491">6. 自分の役割のひとつ外側からプロジェクトを見る</h2><p>これは先輩にもらったアドバイスなのですが、プロジェクトやチームの見え方がかなり変わるものでした。&nbsp;&nbsp;アドバイス以前にも無意識にやっている部分もあったと思いますが、漠然と客観視していたものが、ひとつ外側の視点を決めることで、より精度の高い客観視になった気がします。</p><p>プロジェクトリーダーの外側にはPdMやプロジェクトの戦略メンバーがいます。自分がPdM・戦略メンバーだったらプロジェクトをどう見るか、実際に自分の頭で考えてみることがすごく重要なのではないかなと気づきました。自分の動きも変わるだろうし、外側とのコミュニケーションがスムーズになります。&nbsp;&nbsp;</p><p>プロジェクトリーダーは調整役をすることが多いので、この視点は常にもっていたいと思いました。</p><h2 id="ha214098e44">まとめ</h2><p>こうやって言葉にしてみると、ごく当たり前のことを書いている気がします。当たり前のことを当たり前にやるのって、難しいですよね。（当事者として、プロジェクト進行のさなかにいると特に）わたしだけでしょうか。</p><p>学んだことを完璧に実践できてはいないけど、自分のものにするには、トライアンドエラーを繰り返していくしかないと思っています。毎日かなり頭を使って本当に大変です。&nbsp;&nbsp;大変だけど、プロダクトと一緒に成長していけるのは嬉しいことです。</p><p>最後に、いつもオープンな議論・フィードバックをしてくれて、あたたかく見守ってくれるチームメンバーに心から感謝しています。ありがとうございます。</p><h2 id="h5b64d170ec">余談）思ったよりコーディングする時間が取れない問題</h2><p>プロジェクトリーダーと開発者を兼務していると、コードを一行も書いてないのに気づいたら夕方、みたいなことがざらにあって、妙に焦りを感じます。空いた時間はまずコードレビューを優先するので、コアタイム終わってからが本番なのだけど、その頃にはHP0になってたりします。</p><p>世のプレイングマネージャー的な人たち、どうなってるん・・・？</p>

プロジェクトリーダーをやってみて学んだ6つの事

<p>この記事は <a href="https://qiita.com/advent-calendar/2020/yamap-engginers" target="_blank" rel="noopener noreferrer">YAMAP エンジニア Advent Calender 2020</a> 1日目の記事です。</p><h2 id="h1c63828b47">パフォーマンス計測に至った理由</h2><p>YAMAP では地図を表示する画面が多いです。地図にはランドマークのピンアイコンだったり、登山道だったり、たくさんの要素を表示する必要があり、ページが重いことが体感的にわかることがありました。しかし、実際に重いのかどうかよくわからないし、改善するためにも指標が必要です。&nbsp;&nbsp;そこでなにか指標を決めて、計測をしようと思いました。</p><h2 id="h3531572b42">パフォーマンスの指標</h2><p>パフォーマンスの指標について調べていると、Web サイトのユーザー体験の観測には2つの視点があることがわかりました。</p><h3 id="h683a953410">合成モニタリング</h3><p>合成モニタリングは、同じ環境で定期的に繰り返し計測します。ある特定の環境をシュミレートし、その環境で計測を続けるので、計測結果のゆらぎが少ないです。この後書くリアルユーザーモニタリングと違って、ユーザー環境の違いを考慮しません。&nbsp;&nbsp;</p><h3 id="h1ddb5fe2dc">リアルユーザーモニタリング</h3><p>リアルユーザーモニタリングは、実際のユーザー体験を計測します。&nbsp;計測環境はユーザーによるため、計測結果のゆらぎは大きいです。&nbsp;&nbsp;</p><h3 id="h8fd82cf941">指標は合成モニタリング</h3><p>継続的に改善していくことを考えていたので、環境によるゆらぎの少ない合成モニタリングを行うことにしました。ページエクスペリエンスを測定してくれる Lighthouse を使って定点観測し、その結果を指標にすることにしました。&nbsp;&nbsp;</p><blockquote>本当はどっちもやるのがいいのだと思います。リアルユーザーモニタリングは実際の数値が見れるので、合成モニタリングと結果を比較することで、合成モニタリングの環境設定を見直すことができたり、ユーザーへのインパクトを知ることができそうです。&nbsp;&nbsp;</blockquote><h2 id="hb3b3856153">lighthouse-observer の構成</h2><h3 id="h9707d3a59a">概要</h3><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/00864ab74fb047adae144a1c3a38ca69/ligthouse-observer-architecture.png" alt="" width="1498" height="874"></p><p><a href="https://github.com/yamap-inc/lighthouse-observer" target="_blank" rel="noopener noreferrer">lighthouse-observer</a> は関数です。この関数を Cloud Functions として定期実行し、その結果を Spreadsheet に記録します。データポータルから Spreadsheet に接続し、計測結果をグラフ化し、経過を見やすくしています。</p><h3 id="h89e7b98e09">詳細</h3><h4 id="hcab1ce1c6f">Cloud Functions を定期実行する</h4><p>Cloud Scheduler と Cloud Pub/Sub を利用することで Cloud Functions を定期実行することができます。&nbsp;&nbsp;</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/698b0b1bce7849e5b9be28d67958d0f6/ligthouse-observer-gcp.png" alt="" width="1120" height="380"></p><p>Cloud Scheduler のペイロードとして、次のような json を設定します。スケジューラー起動時、このペイロードは Cloud Pub/Sub を通して、Cloud Functions へ通知されます。&nbsp;&nbsp;</p><pre><code>{
&nbsp; "spreadsheetId": "${your_spreadsheet_id}",
 &nbsp;"timezone": "Asia/Tokyo",
&nbsp; "targets": [
&nbsp; &nbsp;{
&nbsp; &nbsp;&nbsp;"url": "https://yamap.com",
&nbsp; &nbsp;&nbsp;"sheetName": "top"
&nbsp; &nbsp;},
&nbsp; &nbsp;{
&nbsp; &nbsp;&nbsp;"url": "https://yamap.com/maps",
&nbsp; &nbsp;&nbsp;"sheetName": "maps"
&nbsp; &nbsp;}
&nbsp; ]
}</code></pre><p>スケジューラーのペイロードを変更したり、追加することで、柔軟な対応ができるようにしました。Cloud Functions には実行時間の上限（540s）やメモリの上限（2GB）があるので、塩梅を考えて計測対象を分割してスケジュール登録したりしています。&nbsp;&nbsp;</p><h3 id="hc9f65907c0">計測結果をデータポータルで可視化</h3><p><a href="https://marketingplatform.google.com/intl/ja/about/data-studio/" target="_blank" rel="noopener noreferrer">データポータル</a>は Google が提供するサービスのひとつで、データを表やグラフなどで可視化することができるすぐれものです。データのリソースとして、Google アナリティクスや MySQL データベース、スプレッドシートなどを選ぶことができます。日付による絞り込みも GUI からパーツを配置するだけで簡単にできるので、すごく助かりました。&nbsp;&nbsp;</p><p>実際の表示はこんな風になっています。11/26 に大きくパフォーマンスのスコアが落ちていますね（max=1）😣&nbsp;&nbsp;</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/add8f89e20ec4239bfd64ab8746fe28e/lighthouse-observer-web_(daily).png" alt="" width="1875" height="1406"></p><h2 id="h4f0d38f22d">パフォーマンスを可視化してみて</h2><p>問題がありそうに見えるものは定量化するとよいと、改めて思いました。実際、計測前の体感どおり、地図が表示されているページが遅いことがわかったり、クライアント側の実装で改善の余地があることがわかったりしました。&nbsp;&nbsp;</p><p>YAMAP のフロントエンドチームは週に一回、チームミーティングを行っていて、その中でパフォーマンスのサマリーを共有して、ああだこうだ言う時間を設けてもらっています。まだこの指標を活用しきれているとは言えませんが、仲間を増やしてやっていこうと思っています。&nbsp;&nbsp;</p><h2 id="h216559ffb2">（雑談）パフォーマンスに関する名言</h2><h3 id="he98c462ec9">「推測するな計測せよ」</h3><p>有名な言葉ですよね。ボトルネックはどこにあるかわからないので、わからないままやみくもに改善するのはよくないです。改めて調べてみると、ソフトウェア工学者である<a href="https://ja.wikipedia.org/wiki/ロブ・パイク" target="_blank" rel="noopener noreferrer">ロバート・C・パイク</a>さんの<a href="https://ja.wikipedia.org/wiki/UNIX哲学" target="_blank" rel="noopener noreferrer">Cプログラミングに関する覚書</a>の中で述べられている言葉だとわかりました。&nbsp;&nbsp;</p><h3 id="hd60678c2a6">「xxx秒遅くなるとxxx」シリーズ</h3><blockquote>サイト表示が0.1秒遅くなると、売り上げが1%減少し、1秒高速化すると10%の売上が向上する。 ー <a style="background-color:#ffffff" href="http://robotics.stanford.edu/~ronnyk/2007IEEEComputerOnlineExperiments.pdf" target="_blank" rel="noopener noreferrer">Web experiments generate insights and promote innovation.</a><br>表示速度が1秒から3秒になると直帰率は32%上昇 ー <a style="background-color:#ffffff" href="https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/" target="_blank" rel="noopener noreferrer">Find out how you stack up to new industry benchmarks for mobile page speed</a></blockquote><p>サイトスピードがビジネスに与える影響も大きいことがわかります。偉い人を説得するときに使えそう😌&nbsp;&nbsp;</p><h2 id="h3de35099b3">参考</h2><ul><li><a href="https://gihyo.jp/book/2017/978-4-7741-9400-4" target="_blank" rel="noopener noreferrer">超速！ Webページ速度改善ガイド</a></li><li><a href="https://developer.mozilla.org/ja/docs/Glossary/Synthetic_monitoring" target="_blank" rel="noopener noreferrer">Synthetic monitoring (合成モニタリング)</a></li><li><a href="https://developer.mozilla.org/en-US/docs/Web/Performance/Rum-vs-Synthetic" target="_blank" rel="noopener noreferrer">Performance Monitoring: RUM vs synthetic monitoring</a></li></ul><p><br></p><p>&nbsp;&nbsp;</p>

Web サイトのパフォーマンスを定点観測する仕組みを作った話

<h2 id="h985650bf48">package.json って何？</h2><p>package.json はそのプロジェクトが使用する、npm パッケージの依存関係などを管理することができる json ファイルのことです。パッケージのバージョン指定には書き方がいくつかあります。&nbsp;&nbsp;</p><pre><code>{
  "hoge": "^10.0.0",
  "huga": "10.0.0",
}</code></pre><p>たとえば <code>^10.0.0</code>  は <code>10.0.0</code> 以上のバージョンのパッケージを指しますが、<code>major.minor.patch</code> のうち、major は更新されません。<code>10.0.0</code>  は <code>10.0.0</code> そのものです。&nbsp;&nbsp; </p><p>package.json でパッケージバージョンを固定していても、そのパッケージ自体の package.json でパッケージバージョンが固定されているとは限らないようなので、要注意です。&nbsp;&nbsp;</p><h2 id="hfb91a51dcc">package-lock.json って何？</h2><p>npm@5.0.0 以降で、npm install 時に自動生成される json ファイルです。&nbsp;&nbsp;packeage-lock.json は package.json に記載されたパッケージの、具体的で厳密なリストです。バージョン番号や、そのパッケージの依存リストなどが、正確に記録されています。</p><h2 id="hcd2de89dcd">npm install と npm ci のちがい</h2><p><code>npm install</code>  は package.json を元に、依存関係を解決し、パッケージのインストールを行います。その際に、package-lock.json を上書きします。もともとは上書きしない仕様でしたが、パッケージを追加でインストールする際に差が生じて困るので、<a href="https://github.com/npm/npm/issues/16866" target="_blank" rel="noopener noreferrer">上書きする仕様になったよう</a>です。</p><p><code>npm ci</code>  は package-lock.json を元に、パッケージのインストールを行います。依存関係の解決はしませんが、package.json と package-lock.json の間で矛盾が生じていた場合、エラーになります。&nbsp;&nbsp;インストール前に /node_modules を削除するのでクリーンインストールとしても使えそうです。</p><h2 id="h94ea9418c1">結局どっちを使うのがいいんだろう</h2><p>プロジェクトの clone 直後には <code>npm ci</code>  を使うのがいいかもしれないと思いました。package-lock.json に記載されたバージョンのパッケージをインストールしてくれるので、開発メンバーと環境を同じにすることができるからです。これからは <code>npm ci</code>  を使うようにしていきたいと思います。&nbsp;&nbsp;</p><p><br></p>

Rukolog

気持ちに寄り添った振り返りを実践してみた

プロジェクトリーダーをやってみて学んだ6つの事

Web サイトのパフォーマンスを定点観測する仕組みを作った話

npm install と npm ci の違いについて