<p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/2e033516dda44161b0cfb36db7dab7b8/IMG_1544.jpg?w=620&amp;h=465" alt="オールボーの住宅街は静かで煉瓦造りの一軒家が並んでいる" width="620" height="465"></p><p>2022/7/28 に日本を経ち、マルタ・ドイツを経由して、2022/8/7 にデンマークへ到着しました。</p><p>こちらの夏は1日が長く、日没は 21時過ぎごろ。気温も最高20度・最低14度程度とかなり過ごしやすい気候です。（熱波の影響で気温が上がる日もありますが、30度以上になることは今のところなさそう）</p><p>一人で海外に来ること自体はじめてでしたが、渡航時期を夏にして本当によかったと思っています。日が長いだけでものすごく安心感があるんですよね。私がビビりなだけかもしれないけれど！笑</p><p>日本ではない場所に滞在するということにやっと慣れてきたところです。ぽつぽつと心境や気づきなどを残していきたいと思っています。</p><h2 id="h3daef05f2e">デンマーク、オールボー</h2><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/ba36e6a3213446a7bc55267a6fb61eaf/IMG_1456.jpg?w=620&amp;h=465" alt="オールボー駅での一枚" width="620" height="465"></p><p>私は今、北の街オールボーに滞在しています。入学予定の学校がオールボーの少し北にあるため、入寮までの少しの間、この街で過ごしています。滞在先は Airbnb で探しました。</p><iframe class="embedly-embed" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.google.com%2Fmaps%2Fembed%2Fv1%2Fplace%3Fcenter%3D57.0267582%252C9.7673491%26key%3DAIzaSyD9HrlRuI1Ani0-MTZ7pvzxwxi4pgW0BCY%26zoom%3D11%26q%3D%25E3%2582%25AA%25E3%2583%25BC%25E3%2583%25AB%25E3%2583%259C%25E3%2583%25BC&display_name=Google+Maps&url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fplace%2F%25E3%2582%25AA%25E3%2583%25BC%25E3%2583%25AB%25E3%2583%259C%25E3%2583%25BC%2F%4057.0267582%2C9.7673491%2C11z%2Fdata%3D%213m1%214b1%214m5%213m4%211s0x464933b25fdf3d0d%3A0x4eb1b46a2eec26c3%218m2%213d57.0488195%214d9.921747%3Fshorturl%3D1&image=http%3A%2F%2Fmaps-api-ssl.google.com%2Fmaps%2Fapi%2Fstaticmap%3Fcenter%3D57.0267582%2C9.7673491%26zoom%3D15%26size%3D250x250%26sensor%3Dfalse&key=94335756f04b424b8ce3ce71cbe3de0a&type=text%2Fhtml&schema=google" width="600" height="450" scrolling="no" title="Google Maps embed" frameborder="0" allow="autoplay; fullscreen" allowfullscreen="true"></iframe><p>オールボーはデンマーク第四の都市で、人口は20万人ほどです。福岡県で 510万人、我がふるさと大分県で 113万人なので、比較するとかなりこじんまりした街ですね。そもそもデンマークの国土面積が九州と同じくらいだったりします。（びっくり）</p><p>なんとなく日本って島国で小さいイメージがあったんですが、世界的に見るとそんなに小さくもないんだなと気づいたりしました。</p><h2 id="h4c2550dcce">オールボーでの暮らし、第一印象</h2><h3 id="hb294587857">街並みがとにかく素敵</h3><p>建物のトーンが煉瓦造りで統一されていて、高いビルもないので、とても雰囲気が良いです。あちらこちらでドリンク片手にゆったり過ごしている人を見かけます。夏の気候の良さも相まってめっちゃチルい。</p><blockquote class="twitter-tweet"><p lang="ja" dir="ltr">なんかもうめちゃデンマークの街の雰囲気すき。永住権ほしい（厳しい）<br>至るところに緑とベンチがあって、the country of チルとゆう感じだ <a href="https://t.co/YYl3VIY3m3">pic.twitter.com/YYl3VIY3m3</a></p>&mdash; カオルコ in Denmark (@yykaoruko) <a href="https://twitter.com/yykaoruko/status/1557064966410223618?ref_src=twsrc%5Etfw">August 9, 2022</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script><p>街中に緑も多く、あちらこちらで素敵な花壇を見つけることができます。かなり大事に手入れされている街だなあという印象を受けました。（誰がメンテナンスしてるんだろう）</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/9c40ac3bccfc477cb9d94fe6b464dccb/IMG_1475.jpg?w=620&amp;h=465" alt="素敵な花壇をあちらこちらで見つけることができる" width="620" height="465"><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/d7aa59f674e14c88af6f632de6817e5e/IMG_1497.jpg?w=620&amp;h=465" alt="Aalborg Old Town" width="620" height="465"></p><p>オールボーの中心街は "City" と呼ばれているそうで、地方の繁華街を "街" と表現する感覚がここにもあるんだなとちょっと嬉しくなったりしました。大分も中心地は "街" なんです。笑</p><h3 id="h26d6c44478">インテリアがとにかく素敵</h3><p>マルタとドイツの Airb は正直ちょっと落ち着かなかったのだけれど、オールボーで滞在した Airb はかなり居心地の良いお部屋でした。水回りもきれいに掃除されていたし、ホスト曰く、お部屋にはかなりこだわっているみたいです。</p><p>ちょっと意外だったのは、靴を脱ぐ文化だということ。日本のような玄関はないのだけど、入り口に靴箱があって、みんなそこで脱いでいきます。</p><p>冬場は日照時間が極端に短いので、より穏やかに暮らせるように工夫しているのかもしれません。</p><p>照明もオレンジっぽい灯りでよかったです。（照明へのこだわりは自分も強く、白色灯が苦手なので助かりました。）</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/55a0b9ad9959431db1fe0828fd9e29cb/IMG_1470.jpg?w=620&amp;h=465" alt="個人部屋にも緑がある" width="620" height="465"></p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/1329b4d4d4ab458ab9bd741355da7bf2/IMG_1471.jpg?w=620&amp;h=465" alt="壁のあちこちにアートが飾られている" width="620" height="465"></p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/d93b34533ef04400ab58ea2f3b65fccb/IMG_1461.jpg?w=620&amp;h=465" alt="しっくいの壁で全体的に白を基調としている" width="620" height="465"></p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/3d54ef39941942788644a902300ad494/IMG_1462.jpg?w=620&amp;h=465" alt="トイレまでおしゃれ" width="620" height="465"></p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/42594e73813f48f7b68a734399c98df3/IMG_1482.jpg?w=620&amp;h=465" alt="大きなテレビで映画を見て過ごすリビング" width="620" height="465"></p><h3 id="h58050b1130">デンマーク人はとってもフレンドリー</h3><p>ちょっと驚いたんですが、道ですれ違った知らない人と目があった時にも、にっこりとしてくれます。本当に、めっちゃ、にっこりしてくれます。そして困ってそうだと思ったら声をかけてくれます。スーパーの店員さんとか、忙しい時は塩対応だったりもするのだけど（笑）基本優しいです。コペンハーゲンに行くとまたちょっと違ったりするのかな？</p><p>フラットメイトも、I can show you around! と行って観光に連れて行ってくれたり、一緒にご飯を食べてくれたり、あったかいですね。みんなでお寿司を作って、Netflix を見ながら食べたりもしました。イカゲームはヨーロッパでも流行っているようです。笑</p><p><img src="https://images.microcms-assets.io/assets/89d5e740f7584d8ca86453f5e674958a/10c4629e2d4044e49763a2b063bb3b98/IMG_1532.jpg?w=620&amp;h=465" alt="" width="620" height="465"></p><p>ただその反面で、距離感が近すぎる印象も受けちゃいました。日本人的な感覚なんですかね・・・？自分が集団行動に向いていないのは知っていたんですが、想像以上に一人の時間を必要とするタイプなんだという気づきがあったりもしました。</p><h2 id="hdda8b57515">すでにちょっと日本が恋しい</h2><p>お風呂、ウォシュレット付きトイレはもちろんのこと、コンビニがかなり恋しかったりします。マウントレーニアが飲みたいとか、コンビニのおにぎりやおでんが食べたいとか、無駄にスイーツ眺めたいとか、意外なところでホームシックが発生しています。笑</p><p>日本のコンビニってカフェメニューがかなり充実していますよね。プライベートブランドのコーヒーとかスムージーとかスイーツとか。ああゆうパックの飲み物、デンマークではあまり見かけないです。（知らないだけかも？）</p><p>日本のコンビニスイーツ、結構好きだったんだなあというのも、こっちに来て気づいたことの一つでした。</p><h2 id="h6546594dfe">明日から学校生活が始まる</h2><p>人と仲良くなるのに時間を要するタイプなので馴染めるか不安ですし、授業（英語）がとにかく心配ですが、楽しんでいきたいと思います！</p>

デンマークに来て一週間が経ちました

<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 の違いについて