feedforce

この記事は、Feedforce Group Advent Calendar 2022 の16日目の記事です。昨日は、アナグラム田中さんによる「クラス制のキャラ育成ができるRPGってキャリア形成のそれと似ているな...って思っただけの話」でした！note.com私はつい最近、フロントエンドエンジニアからスクラムマスターに社内で「転職（ドラクエ的表現）」したところでして、学生時代のアルバイトで貯めていた経験なんかが意外なところで活きたなぁと感じていたところがあったため、とてもしっくりくる内容でした！また、運用型広告というジョブのアビリティの豊富さ・プレイスタイルの幅広さが視覚的に表現されており、運用型広告というジョブの魅力がガッツリ伝わってきました。何の話なんだろう？と思った未読の方、是非本文を楽しんでください！まえがき本記事では、この 1 年間家族でやってきたふりかえりについて書きます。2022 年、家族で毎週ふりかえりをしたふりかえりをすると、たくさんいいことがあったたくさんの課題があり、工夫して乗り越えたこの記事は「家族のふりかえり」にフォーカスしたものですが、家族以外の親密な人とのふりかえりや、自分ひとりのふりかえりをしたい方にも届けたいと思って書きました。はじめに自己紹介こんにちは、はじめまして。 @zomysan と申します。弊社は東京にオフィスのある会社ですが、私は関西からフルリモートで勤務しています。家族について二人暮らしです。同い年で、ゲーム、絵を描く、お菓子を食べるなど共通の趣味が多く仲良しです。自分: @zomysan犬好き個人開発プロダクトを開発中家族猫好きWeb エンジニアを目指し勉強中ふりかえりのきっかけ2022 年 1 月、それぞれの 1 年の目標を立てました。ふりかえりの内容実施しているふりかえりについて紹介します。いつどれくらいやるか毎週土曜日午前、2 時間の開催としています。ふりかえりの目的わが家では、ふりかえりの目的を下記のとおり定めています。ありたい姿に向かって、自分がどれくらい進んだのか？ありたい姿に向かって、正しい方向に進めているのか？「ありたい姿」というと何やら大袈裟な感じがしますが、大層なものでなくても構わないです。ふりかえりをすることで、自分の生活と「ありたい姿」のギャップを確認し、そこを目指すための軌道修正ができます。わが家では週に 1 度ふりかえりをしているので、「ありたい姿」を目指すための軌道修正が毎週できているということになります。YKPT + ファイブフィンガーいわゆる「YKPT」という方法を少しアレンジし、ふりかえりをおこなっています。YKPT の詳細は省きますが、客観的事実のみから成る「やったこと(Y)」、「やったこと」に基づく「よかったこと（Keep）」、「改善したいこと（Problem）」を書き出し、それに基づいて「次やること（Try）」を決めるという手法です。また、ファイブフィンガーという手法で、ふりかえりのふりかえりをおこなっています。これらと併せて、家計簿等を見返す「お金のふりかえり」、アプリの利用時間やゲームのプレイ時間等を見返す「時間のふりかえり」もやっているのですが、今回はこれらについての詳細は省きます。実際の様子実際のふりかえりの様子をスクリーンショットですこし紹介します。これは「やったこと」「よかったこと」「改善したいこと」の一部が見えています。ふりかえりをしてよかったことさて、ここまではふりかえりの概要を紹介してきました。ここからいよいよ、約50回のふりかえりから得た経験について紹介していきます！問題を共有できる一緒に暮らしていると、ちょっとした困りごとや、変えてもらうようお願いしたいことが出てくるものですよね。「いまは改善したいことを挙げる時間ですよ」と区切られていることで、ちょっと言い出しにくいことも表現しやすいです。「発生した課題と解決方法」で詳しくお話ししますが、言い出しにくいことを言い出すための工夫もしています。1 年のふりかえりを通して、どういう課題であっても、「相手を責めたり押し付けたりするのではなく、解決方法について一緒に真剣に考える」ことで解決することを信じ、安心して話せるようになりました。このことで、さらに「改善したいこと」が出てきやすくなり、カイゼンにつながっています。課題が解決するふりかえりをせずに過ごしていると、困っていることがあってもなんとなくそのまま過ごしてしまいます。ふりかえりで「改善したいこと」「困っていること」をあらためて書き出すことで、すぐに対応できます。そのほかには、「本を読む時間が 0 分だった」という客観的事実から、「寝る前に本を読む時間をとる」という改善すべきことが見つかりました。悩まなくていい悩みを捨てられる「課題が解決する」では、本を読む時間を確保できるようになったことについてお話ししました。日常を過ごしていると、ついあれもこれもと考えてしまいがちです。ふりかえりの場で自分の優先順位を確認することで、自分が本当に集中したいこととそうでないことを振り分け、優先度の低いことに心を煩わされないようにしたいですね。それはそうとして、なんとかして読書の時間は確保したいものです。明日の家族会議で話してもいいかもしれません。出来事が蓄積される「やったこと」でその週にあったことを客観的事実として挙げます。これは、「よかったこと」「改善したいこと」につなげるための思い出しなのですが、挙げた「やったこと」自体にも価値があると感じます。書いたカードは、すべてとっておき、ふりかえりをした順番に蓄積していきます。そうすると、楽しかったお出かけや、美味しかった自炊、外食、達成したことや困ったことなど、さまざまな「今年 1 年あったこと」のまとめになります。もうすぐ年末休みなので、我が家でも家族で 1 年分の「あったこと」をまとめて見返す予定です。とても楽しみです！発生した課題と解決方法ここまでふりかえりの良かったところについて書きましたが、楽にこれらを得たわけではありませんでした。ふりかえりをやっていくと、大小さまざまな課題が発生します。決めた「次やること」を忘れてしまうせっかく「次やること」を決めてリストにしたのに、すっかり忘れたまま 1 週間を過ごす。→ 解決方法: 朝会を実施「次やること」で決めたことを守れているか、やると決めたタスクはこなせているかを確認するため、朝にも短い家族会議をすることに決めました。わが家ではそのまま朝会と呼んでいます。朝会で「次やること」を確認することで、日常のなにかを変えるような取り組み（「水をしっかり飲むためにお湯を 10 時に沸かす」など）についてあらためて認識できます。また、タスク的な取り組み（「敷き毛布を買う」「保温ケトルを買う」など）についても、その日の TODO に落とし込むなどして 1 週間のうちに確実に消化しきることができるようになりました。余談ではありますが、朝会ではふりかえりの「次やること」の確認に加え、以下のような取り組みもやっています。直近の家族の目標を確認当日・直近のスケジュール確認それぞれの「今日の TODO」を付箋に書くこれも朝会をやっていく過程で試行錯誤があり、ふりかえりを通して今の形になりました。「改善したいこと」の話し合いが精神的につらくなる「改善したいこと」の深掘りではお互いにマイナスのフィードバックをするような場面も多く、「えっ」「いやいや」と言いたい気持ちになる場面もあります。→ 解決方法: おやつ休憩を挟む現在、わが家の「改善したいこと」を話す流れは以下のようになりました。おやつは血糖値を上げて脳の栄養になってくれそうな甘いものを選びます。紅茶やコーヒーなど、用意していたおやつに合いそうな飲み物もふたりで一緒に用意します。まず文章で見て、自分なりに受け止める時間があり、楽しいおやつの時間も挟むので、反射的に言い返すことから喧嘩になる可能性が大幅に下がります。そのころには、最初に感じた「えっ」という衝撃はずいぶん和らいでいます。余談ですが、元気なうちに「改善したいこと」の話を済ませてしまうという解決方法もあるかもしれません。わが家では「その週のふりかえりで食べるお菓子を選ぶ」という楽しいイベントが一つ加わり、ふりかえりの時間が楽しみになるという嬉しい副作用もあったので、今のやり方を続けています。ふりかえりへの取り組み方に差が出てしまう一緒にやると決めたふりかえりですが、お互いがずっと高いモチベーションで取り組めていたわけではありません。「ちゃんとやってよ」と言い合うのは簡単ですが、集中できないのは集中できないなりの理由があるということです。ただ、これではせっかくのふりかえりの質が保てませんし、最悪ふりかえりのせいで言い争いが起きてしまいます。→ 解決方法: ふりかえりについてふりかえり、あらためてふりかえりの意義を共有するどうすべきなのか、一旦休んだほうがいいのかな、と思っていたところ、2022 年に開催されたスクラムフェス大阪で、とてもタイムリーなセッションに出会いました。ふりかえりをふりかえるための「ふりかえりチェックシート」を使ってふりかえろう！このセッションで紹介されたのは、ふりかえりがうまくいっているのかをさまざまな観点からチェックし、話し合うためのチェックシートです。ぜひ一度こちらからシートの現物をごらんいただきたいです。わが家でも、このチェックシートにふたりで取り組みました。しかし、シートの効果はそれだけではありませんでした。このシートのチェック項目は、場づくり、アイデア出し、思い出しといった「ふりかえりの要素」ごとに整理されています。まとめふりかえりをしてよかったことをまとめます。問題を家族で共有できる課題が解決する悩まなくていい悩みを捨てられる出来事が蓄積されるまた、ふりかえりをよいものにするために取り組んだことは以下のとおりです。ふりかえったことは、毎日確認する機会をつくるふりかえり自体のふりかえりもするごきげんでいるために、おやつ休憩を挟むありたい姿を認識するふりかえりの意義を共有する長い記事を読んでいただき、感謝しかありません。2023 年、プライベートについてもふりかえりをはじめてみませんか？Twitter でもふりかえりのことなど発信していきたいと思っていますので、興味があれば是非そちらもチェックしていただければと思います！https://twitter.com/zomysan

【約 50 回】2022 年、家族で毎週ふりかえりをした話

<p>こんにちは。<a href="https://twitter.com/masutaka/status/1550357627779284992">自称 Looker エバンジェリスト</a>の <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>この記事は Looker Advent Calendar 2022 の 5 日目の記事です。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2022%2Flooker" title="Calendar for Looker | Advent Calendar 2022 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2022/looker">qiita.com</a></cite></p>

<p>昨日と一昨日は記事がなくて、その前は BASE 永野さん (<a href="https://twitter.com/glassmonekey">@glassmonekey</a>) の「<a href="https://devblog.thebase.in/entry/2022/12/02/110000">アジリティを保ってデータ基盤を作る取り組み</a>」でした。使用した技術そのものよりも、どのように合意形成してこのような体制に出来たのかが気になりました。👀</p>

<p>今回は奇しくも去年の Advent Calendar その後の話になります。全然狙っていませんでした。たまたまです。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F12%2F13%2F110000" title="LookML 開発で使っているディレクトリ構造を紹介する - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2021/12/13/110000">developer.feedforce.jp</a></cite></p>

<ul class="table-of-contents">
    <li><a href="#LookML-のレイヤー化とは">LookML のレイヤー化とは</a></li>
    <li><a href="#導入戦略">導入戦略</a></li>
    <li><a href="#実際の導入方法">実際の導入方法</a><ul>
            <li><a href="#_baselayerlkml">/_base.layer.lkml</a></li>
            <li><a href="#_basiclayerlkml">/_basic.layer.lkml</a></li>
            <li><a href="#layerslayerlkml">/layers/*.layer.lkml</a></li>
            <li><a href="#modellkml">/*.model.lkml</a></li>
            <li><a href="#コラム-複数レイヤーで共通するロジックの置き場所">[コラム] 複数レイヤーで共通するロジックの置き場所</a></li>
        </ul>
    </li>
    <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="LookML-のレイヤー化とは">LookML のレイヤー化とは</h2>

<p>LookML には <a href="https://cloud.google.com/looker/docs/lookml-refinements">Refinements</a> という <a href="https://cloud.google.com/looker/docs/reusing-code-with-extends">Extends</a> に似た機能があり、explore や view の定義を分散させたり、元のコードを変更せずに機能を追加することが出来ます。</p>

<p>この Refinements を応用することで LookML に「レイヤー化」という概念を導入することが出来ます。まずはこちらの記事をどうぞ。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2F%25E3%2582%25B3%25E3%2583%25A9%25E3%2583%25A0-103%2Frefinements%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%25A3%25E3%2581%25A6lookml%25E3%2581%25AE%25E3%2582%25B3%25E3%2583%25BC%25E3%2583%2589%25E3%2582%2592%25E6%2595%25B4%25E7%2590%2586%25E3%2581%2599%25E3%2582%258B-18809" title="Refinementsを使ってLookMLのコードを整理する | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://community.looker.com/%E3%82%B3%E3%83%A9%E3%83%A0-103/refinements%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6lookml%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%95%B4%E7%90%86%E3%81%99%E3%82%8B-18809">community.looker.com</a></cite></p>

<p>このような責務だと理解しました。</p>

<ul>
<li>/_base.layer.lkml

<ul>
<li>スキーマと Explore の定義に徹する。Join はしない</li>
</ul>
</li>
<li>/_basic.layer.lkml

<ul>
<li>データ構造に着目した Join と、primary_key の定義に徹する。ビジネスロジックは定義しない</li>
</ul>
</li>
<li>/layers/*.layer.lkml

<ul>
<li>ビジネスロジックの論理レイヤーをここに定義する</li>
</ul>
</li>
</ul>


<p>💭 <code>_base</code> と <code>_basic</code> はもっと良い命名はあるかもしれません。</p>

<h2 id="導入戦略">導入戦略</h2>

<p>既存のプロジェクトを全部書き換えるのはリスクが大きいので、新規で Join する view からレイヤー化を試すことにしました。</p>

<p>ただ、責務はこのように再定義しました。特に <code>/_basic.layer.lkml</code> を変えました。</p>

<ul>
<li>/_base.layer.lkml

<ul>
<li>スキーマ定義に徹する</li>
</ul>
</li>
<li>/_basic.layer.lkml

<ul>
<li>primary_key のテストを書ける定義を書く。Join はしない。ビジネスロジックは知らない</li>
</ul>
</li>
<li>/layers/*.layer.lkml

<ul>
<li>Join 含めて、ビジネスロジックの論理レイヤーをここに定義する</li>
</ul>
</li>
</ul>


<p>というのも、今回は「データ構造に着目した Join」と同じ Join を論理レイヤーにも定義する必要があり、実装が分散するからです。後述します。</p>

<h2 id="実際の導入方法">実際の導入方法</h2>

<h3 id="_baselayerlkml">/_base.layer.lkml</h3>

<p>このようなスキーマ定義を、1 つのファイルに書いていきます。</p>

<pre class="code" data-lang="" data-unlink>view: ad_budget {
  sql_table_name: @{table_ad_budget} ;;

  dimension: month        { type: string }
  dimension: client_name  { type: string }
  dimension: site_name    { type: string }
  dimension: media        { type: string }
  dimension: budget_gross { type: number }
}</pre>


<p>💡 <code>sql: ${TABLE}.date ;;</code> 等がなくて違和感があるかも知れませんが、以下のとおり問題ありません。</p>

<p>🔗 <a href="https://cloud.google.com/looker/docs/reference/param-field-sql#sql_for_dimensions">sql (for fields) > Definition > sql for Dimensions</a></p>

<blockquote><p>If <code>sql</code> is left unspecified, then Looker assumes that there is a column in the underlying table with the same name as the field. For example, selecting a field called <code>city</code> without a <code>sql</code> parameter would be equivalent to specifying <code>sql: ${TABLE}.city</code>.</p>

<p><code>sql</code> が指定されていない場合、Looker はそのフィールドと同じ名前のカラムが基礎となるテーブルに存在すると仮定します。例えば、<code>sql</code> パラメータを指定せずに <code>city</code> というフィールドを選択すると、<code>sql: ${TABLE}.city</code> と指定したのと同じことになります。</p></blockquote>

<h3 id="_basiclayerlkml">/_basic.layer.lkml</h3>

<p>このような定義を書きます。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;/_base.layer&#34;

# Define for tests
explore: ad_budget {
  required_access_grants: [can_view_explores_for_tests]
  hidden: yes
}

view: +ad_budget {
  dimension: pk {
    primary_key: yes
    type: string
    sql: CONCAT(${month}, ${client_name}, ${site_name}, ${media}) ;;
    hidden: yes
  }

  measure: count {
    type: count
    description: &#34;Row Count&#34;
    filters: {
      field: &#34;pk&#34;
      value: &#34;-NULL&#34;
    }
  }
}</pre>


<p>💡 ad_budget view は直接使われず、他の Explore から Join して使うので、ad_budget explore はテストだけで使うように隠しています。</p>

<p>関連記事です。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F08%2F30%2F150000" title="Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2021/08/30/150000">developer.feedforce.jp</a></cite></p>

<h3 id="layerslayerlkml">/layers/*.layer.lkml</h3>

<p>ad_budget view を 2 つの Explore から Join します。<code>join</code> 内容はほとんど同じで、<code>sql_on</code> の view 名が違うだけです。</p>

<p>似た実装を 1 つにまとめられるメリットがあります。corp_name1 という名前から推測できるとおり、corp_nameN explore は複数存在しており、その数数十にもなります。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;/_basic.layer&#34;
include: &#34;/explores/all_media.explore&#34;

explore: +all_media {
  join: ad_budget {
    view_label: &#34;広告予算&#34;
    relationship: many_to_many
    sql_on: ${all_media.date_month} = ${ad_budget.month}
            AND ${all_media.corporate_name} = ${ad_budget.client_name}
            AND ${all_media.proposition_name} = ${ad_budget.site_name} ;;
  }
}

explore: +corp_name1 {
  join: ad_budget {
    view_label: &#34;広告予算&#34;
    relationship: many_to_many
    sql_on: ${corp_name1.date_month} = ${ad_budget.month}
            AND ${corp_name1.corporate_name} = ${ad_budget.client_name}
            AND ${corp_name1.proposition_name} = ${ad_budget.site_name} ;;
  }
}

view: +ad_budget {
  dimension: budget_gross { hidden: yes }

  measure: total_budget_gross {
    type: sum
    sql: ${budget_gross} ;;
    label: &#34;広告予算 (Gross)&#34;
    value_format_name: jpy_0
  }
}</pre>


<h3 id="modellkml">/*.model.lkml</h3>

<p><code>/model_name.model.lkml</code> のようなファイルに、レイヤーファイルの include を追加しました。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;/layers/**/*.layer&#34;</pre>


<h3 id="コラム-複数レイヤーで共通するロジックの置き場所">[コラム] 複数レイヤーで共通するロジックの置き場所</h3>

<p>少し脱線。複数レイヤーで共通するロジックをどう書けばよいか？の話はあると思います。</p>

<p>今まで通り <code>extends</code> パラメーターを使えば良いです。Refinements と Extends は共存できます。詳しくは <a href="https://help.looker.com/hc/en-us/articles/5043112335891-Lookml-refinements-compared-to-extends">Lookml refinements compared to extends</a> をどうぞ。</p>

<p>まだ試行錯誤中ですが、私は <code>/modules/*.module.lkml</code> に共通ロジックをまとめています。</p>

<h2 id="まとめ">まとめ</h2>

<p>LookML のレイヤー化を紹介しました。今回の例以外にもガッツリと使っています。</p>

<p>記事を書いていて、具体的な例を出してもピンと来ないだろうし、抽象的な例にするとボンヤリするしで、いろんな意味で難易度が高かったです。どなたか 1 人にでも参考になれば十分です。</p>

<p>レイヤー化は LookML の到達点ではなく、1 つの選択肢に過ぎません。素朴なデータ構造であれば、<code>/views</code> や <code>/explores</code> で実装したほうが良いと思います。</p>

<p>というのも、レイヤー化を導入すると、スキーマ定義と Dimension&amp;Measure 定義の距離が離れるので、その view で何が使えるのか、コードから理解するのが難しくなるからです。</p>

<p>今回紹介した例も、記事を書いていてもっと良い方法があるような気がしました。Explore をうまいこと Extends して Join を 1 つにまとめれば、レイヤー化を使わなくてよいのでは？とか。でも以前検討した時はうまくいかなかったんですよね...。</p>

<p>正解はないと思うので、他の試行錯誤も是非教えて下さい。</p>

<p>🔗 <a href="https://community.looker.com/lookml-5/what-is-the-looker-recommended-folder-structure-for-lookml-development-28826">What is the looker recommended folder structure for LookML development ? | Looker Community</a></p>

<blockquote><p>I used different approaches in the last few years and found it that I always have to have some kind of a hybrid system.
(snip)
But to be honest, I am still experimenting with what’s the best physical split versus logical</p>

<p>私は過去数年間、さまざまなアプローチを使用し、私は常にいくつかの種類のハイブリッドシステムを持たなければならないことを発見した。
（省略）
しかし、正直なところ、物理的な分割と論理的な分割のどちらが良いのか、まだ試行錯誤の段階です。</p></blockquote>

<p>以前、Looker Community のこちらのコメントを紹介したことがあります。<a href="https://community.looker.com/members/dawid-5902">Dawid</a> さんはよくお見かけする方で、かなりの熟練者のはずです。そんな彼も、未だに試行錯誤しているようです。</p>

<p>始めは <code>/views</code> や <code>/explores</code> のような素朴な実装から始めて、必要に応じてレイヤー化を取り入れれば良いと思います。いつか公式から、データの複雑度に応じたベストプラクティスが出てくることを期待します。🙃</p>

<p><a href="https://qiita.com/advent-calendar/2022/looker">Looker Advent Calendar 2022</a> の明日、明後日は書く人はまだいなくて、その次は @saenakano さんの「System Activity入門」です。お楽しみに。</p>


こんにちは。自称 Looker エバンジェリストの id:masutaka26 です。この記事は Looker Advent Calendar 2022 の 5 日目の記事です。qiita.com昨日と一昨日は記事がなくて、その前は BASE 永野さん (@glassmonekey) の「アジリティを保ってデータ基盤を作る取り組み」でした。使用した技術そのものよりも、どのように合意形成してこのような体制に出来たのかが気になりました。👀今回は奇しくも去年の Advent Calendar その後の話になります。全然狙っていませんでした。たまたまです。developer.feedforce.jpLookML のレイヤー化とは導入戦略実際の導入方法/_base.layer.lkml/_basic.layer.lkml/layers/*.layer.lkml/*.model.lkml[コラム] 複数レイヤーで共通するロジックの置き場所まとめLookML のレイヤー化とはLookML には Refinements という Extends に似た機能があり、explore や view の定義を分散させたり、元のコードを変更せずに機能を追加することが出来ます。この Refinements を応用することで LookML に「レイヤー化」という概念を導入することが出来ます。まずはこちらの記事をどうぞ。community.looker.comこのような責務だと理解しました。/_base.layer.lkmlスキーマと Explore の定義に徹する。Join はしない/_basic.layer.lkmlデータ構造に着目した Join と、primary_key の定義に徹する。ビジネスロジックは定義しない/layers/*.layer.lkmlビジネスロジックの論理レイヤーをここに定義する💭 _base と _basic はもっと良い命名はあるかもしれません。導入戦略既存のプロジェクトを全部書き換えるのはリスクが大きいので、新規で Join する view からレイヤー化を試すことにしました。ただ、責務はこのように再定義しました。特に /_basic.layer.lkml を変えました。/_base.layer.lkmlスキーマ定義に徹する/_basic.layer.lkmlprimary_key のテストを書ける定義を書く。Join はしない。ビジネスロジックは知らない/layers/*.layer.lkmlJoin 含めて、ビジネスロジックの論理レイヤーをここに定義するというのも、今回は「データ構造に着目した Join」と同じ Join を論理レイヤーにも定義する必要があり、実装が分散するからです。後述します。実際の導入方法/_base.layer.lkmlこのようなスキーマ定義を、1 つのファイルに書いていきます。view: ad_budget {  sql_table_name: @{table_ad_budget} ;;  dimension: month        { type: string }  dimension: client_name  { type: string }  dimension: site_name    { type: string }  dimension: media        { type: string }  dimension: budget_gross { type: number }}💡 sql: ${TABLE}.date ;; 等がなくて違和感があるかも知れませんが、以下のとおり問題ありません。🔗 sql (for fields) > Definition > sql for DimensionsIf sql is left unspecified, then Looker assumes that there is a column in the underlying table with the same name as the field. For example, selecting a field called city without a sql parameter would be equivalent to specifying sql: ${TABLE}.city.sql が指定されていない場合、Looker はそのフィールドと同じ名前のカラムが基礎となるテーブルに存在すると仮定します。例えば、sql パラメータを指定せずに city というフィールドを選択すると、sql: ${TABLE}.city と指定したのと同じことになります。/_basic.layer.lkmlこのような定義を書きます。include: "/_base.layer"# Define for testsexplore: ad_budget {  required_access_grants: [can_view_explores_for_tests]  hidden: yes}view: +ad_budget {  dimension: pk {    primary_key: yes    type: string    sql: CONCAT(${month}, ${client_name}, ${site_name}, ${media}) ;;    hidden: yes  }  measure: count {    type: count    description: "Row Count"    filters: {      field: "pk"      value: "-NULL"    }  }}💡 ad_budget view は直接使われず、他の Explore から Join して使うので、ad_budget explore はテストだけで使うように隠しています。関連記事です。developer.feedforce.jp/layers/*.layer.lkmlad_budget view を 2 つの Explore から Join します。join 内容はほとんど同じで、sql_on の view 名が違うだけです。似た実装を 1 つにまとめられるメリットがあります。corp_name1 という名前から推測できるとおり、corp_nameN explore は複数存在しており、その数数十にもなります。include: "/_basic.layer"include: "/explores/all_media.explore"explore: +all_media {  join: ad_budget {    view_label: "広告予算"    relationship: many_to_many    sql_on: ${all_media.date_month} = ${ad_budget.month}            AND ${all_media.corporate_name} = ${ad_budget.client_name}            AND ${all_media.proposition_name} = ${ad_budget.site_name} ;;  }}explore: +corp_name1 {  join: ad_budget {    view_label: "広告予算"    relationship: many_to_many    sql_on: ${corp_name1.date_month} = ${ad_budget.month}            AND ${corp_name1.corporate_name} = ${ad_budget.client_name}            AND ${corp_name1.proposition_name} = ${ad_budget.site_name} ;;  }}view: +ad_budget {  dimension: budget_gross { hidden: yes }  measure: total_budget_gross {    type: sum    sql: ${budget_gross} ;;    label: "広告予算 (Gross)"    value_format_name: jpy_0  }}/*.model.lkml/model_name.model.lkml のようなファイルに、レイヤーファイルの include を追加しました。include: "/layers/**/*.layer"[コラム] 複数レイヤーで共通するロジックの置き場所少し脱線。複数レイヤーで共通するロジックをどう書けばよいか？の話はあると思います。今まで通り extends パラメーターを使えば良いです。Refinements と Extends は共存できます。詳しくは Lookml refinements compared to extends をどうぞ。まだ試行錯誤中ですが、私は /modules/*.module.lkml に共通ロジックをまとめています。まとめLookML のレイヤー化を紹介しました。今回の例以外にもガッツリと使っています。記事を書いていて、具体的な例を出してもピンと来ないだろうし、抽象的な例にするとボンヤリするしで、いろんな意味で難易度が高かったです。どなたか 1 人にでも参考になれば十分です。レイヤー化は LookML の到達点ではなく、1 つの選択肢に過ぎません。素朴なデータ構造であれば、/views や /explores で実装したほうが良いと思います。というのも、レイヤー化を導入すると、スキーマ定義と Dimension&Measure 定義の距離が離れるので、その view で何が使えるのか、コードから理解するのが難しくなるからです。今回紹介した例も、記事を書いていてもっと良い方法があるような気がしました。Explore をうまいこと Extends して Join を 1 つにまとめれば、レイヤー化を使わなくてよいのでは？とか。でも以前検討した時はうまくいかなかったんですよね...。正解はないと思うので、他の試行錯誤も是非教えて下さい。🔗 What is the looker recommended folder structure for LookML development ? | Looker CommunityI used different approaches in the last few years and found it that I always have to have some kind of a hybrid system.(snip)But to be honest, I am still experimenting with what’s the best physical split versus logical私は過去数年間、さまざまなアプローチを使用し、私は常にいくつかの種類のハイブリッドシステムを持たなければならないことを発見した。（省略）しかし、正直なところ、物理的な分割と論理的な分割のどちらが良いのか、まだ試行錯誤の段階です。以前、Looker Community のこちらのコメントを紹介したことがあります。Dawid さんはよくお見かけする方で、かなりの熟練者のはずです。そんな彼も、未だに試行錯誤しているようです。始めは /views や /explores のような素朴な実装から始めて、必要に応じてレイヤー化を取り入れれば良いと思います。いつか公式から、データの複雑度に応じたベストプラクティスが出てくることを期待します。🙃Looker Advent Calendar 2022 の明日、明後日は書く人はまだいなくて、その次は @saenakano さんの「System Activity入門」です。お楽しみに。

Looker のレイヤー化を本番環境に導入してみた

<p>こんにちは。<a href="https://twitter.com/masutaka/status/1550357627779284992">自称 Looker エバンジェリスト</a>の <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>フィードフォースで Looker を使っているサービスで最近 BigQuery の料金が上がってきました。</p>

<p>本当に使われているのならとても良いことですが、Looker のキャッシュが有効に使われずに BigQuery 料金が増えていたら嫌だなと思い、キャッシュの仕組みを思い出しつつ実装を整理してみました。</p>

<ul class="table-of-contents">
    <li><a href="#Looker-のキャッシュおさらい">Looker のキャッシュおさらい</a></li>
    <li><a href="#今回のサービスでのキャッシュ設定">今回のサービスでのキャッシュ設定</a></li>
    <li><a href="#変更後のキャッシュ設定">変更後のキャッシュ設定</a></li>
    <li><a href="#さらなる足掻きからの失敗">さらなる足掻きからの失敗</a></li>
    <li><a href="#もっと足掻いてからの困惑">もっと足掻いてからの困惑</a></li>
    <li><a href="#まとめ">まとめ</a></li>
    <li><a href="#さらなるキャッシュへの理解">さらなるキャッシュへの理解</a></li>
</ul>

<h2 id="Looker-のキャッシュおさらい">Looker のキャッシュおさらい</h2>

<p>Looker にはキャッシュの仕組みがあり、LookML 開発者が適切に設定することで、データベースのクエリ実行を減らすことができます。</p>

<p>全く同じ SQL の実行結果がキャッシュされていれば、データベースにクエリ実行せずにキャッシュを返します。</p>

<p>Looker ユーザーとしてはダッシュボードの表示速度向上のメリットがあり、LookML 開発者としては（BigQuery 等であれば）料金削減に繋がります。</p>

<p>キャッシュの有効期限はデフォルトで 1 時間です。これは <a href="https://cloud.google.com/looker/docs/reference/param-model-persist-for">persist_for (for models)</a> のデフォルト値です。</p>

<h2 id="今回のサービスでのキャッシュ設定">今回のサービスでのキャッシュ設定</h2>

<p>良くも悪くも設定は最小限で、PDT（永続的派生テーブル）の実装箇所だけでした。</p>

<p>例えば Google や Criteo などの広告媒体数値が入ったテーブルを参照する、all_media explore があります。このようなキャッシュ設定でした。</p>

<pre class="code" data-lang="" data-unlink>datagroup: cache_all_media {
  # 最新の日付か総レコード数に変化があったら検知する。
  sql_trigger: SELECT CONCAT(MAX(date), &#39;_&#39;, COUNT(*)) FROM @{table_all_media} ;;
  max_cache_age: &#34;1 hour&#34;
}

explore: all_media {
  persist_with: cache_all_media # (1)

  # ...
}

view: all_media {
  derived_table: {
    # めちゃめちゃ長い SQL
    sql: SELECT
           ...
         FROM @{table_all_media}
         GROUP BY ... ;;
    datagroup_trigger: cache_all_media # (2)
    partition_keys: [&#34;date&#34;]
  }

  # ...
}</pre>


<p>(1) で <code>cache_all_media</code> datagroup と <code>all_media</code> explore が <a href="https://cloud.google.com/looker/docs/reference/param-explore-persist-with">persist_with (for Explores)</a> で紐付くことで、以下の振る舞いが生まれます。</p>

<ul>
<li><code>sql_trigger</code> によりテーブルの変更が検知されると、キャッシュが破棄される</li>
<li><code>max_cache_age</code> を超えたキャッシュは破棄される</li>
</ul>


<p>つまりキャッシュの生存期間は最長でも 1 時間です。その前に PDT が再作成されればもっと短くなります。</p>

<p>どちらかと言えば、データベースを優先する設定です。このテーブルは 1 日に 3 回しか更新されないため、最適化の余地がありそうです。</p>

<p>(2) で <code>cache_all_media</code> datagroup と <code>all_media</code> view も <a href="https://cloud.google.com/looker/docs/reference/param-view-datagroup-trigger">datagroup_trigger</a> で紐付いていますが、これは derived_table を永続化するための設定です。<code>sql_trigger</code> によりテーブルの変更が検知されると、PDT が再作成されるとともに、キャッシュが破棄されます。</p>

<p>※ 余談: <code>persist_with</code> を設定していたことをすっかり忘れていたこともあり、調査前は (1) の理解が出来ていませんでした。😇</p>

<h2 id="変更後のキャッシュ設定">変更後のキャッシュ設定</h2>

<p>紆余曲折あり、<code>max_cache_age</code> を少し増やしただけにしました。</p>

<pre class="code" data-lang="" data-unlink>datagroup: cache_all_media {
  # 最新の日付か総レコード数に変化があったら検知する。
  sql_trigger: SELECT CONCAT(MAX(date), &#39;_&#39;, COUNT(*)) FROM @{table_all_media} ;;
  max_cache_age: &#34;2 hours&#34;
}</pre>


<p>本当は "24 hours" にして「PDT 再作成のタイミングでのみキャッシュを破棄」したかったのですが、他の Explore でも参照される関係で、<code>max_cache_age</code> を思い切って増やせませんでした。</p>

<h2 id="さらなる足掻きからの失敗">さらなる足掻きからの失敗</h2>

<p><code>max_cache_age</code> を 1 時間から 2 時間に増やした程度では、BigQuery 料金を抑えられたように見えませんでした。</p>

<p>仕方がないので、all_media explore 以外の Explore で <code>cache_all_media</code> datagroup を使うのを止めて、専用 persist_with + datagroup を設定しました。</p>

<p>このような LookML を 40 個書きました。😱</p>

<pre class="code" data-lang="" data-unlink>datagroup: cache_corp_xxx {
  sql_trigger:  SELECT
                  STRING_AGG(CONCAT(table, &#39;_&#39;, date, &#39;_&#39;, count) ORDER BY table)
                FROM (
                  SELECT &#39;all_media&#39; AS table, MAX(date) AS date, COUNT(*) AS count FROM @{table_all_media} UNION ALL
                  SELECT &#39;UA_1&#39;, MAX(date), COUNT(*) FROM @{table_ga_xxx} UNION ALL
                  SELECT &#39;UA_2&#39;, MAX(date), COUNT(*) FROM @{table_ga_xxx2}
                ) ;;
  max_cache_age: &#34;24 hours&#34; # テーブル更新のタイミングでのみ、キャッシュを破棄する。
}

explore: corp_xxx {
  persist_with: cache_corp_xxx

  # ...
}</pre>


<p>結果的には大失敗。40 個の datagroup が 5 分に 1 回トリガーされる関係で、Looker を使わない土日でも BigQuery 料金が変わらなくなってしまいました。</p>

<p>※ 補足: 「可能な限り Explore を少なくする」が Looker のベストプラクティスなので、40 個もの Explore は本来はアンチパターンです。ですが、今回のサービスはお客様にダッシュボードを提供する上に、やむを得ず個別実装が発生することもあります。そのような経緯で結果的にこの数になっています。</p>

<h2 id="もっと足掻いてからの困惑">もっと足掻いてからの困惑</h2>

<p>それならばと、利用頻度が高い Explore だけに、専用 persist_with + datagroup を設定すれば良いのでは？と思いました。<a href="https://cloud.google.com/looker/docs/usage-reports-with-system-activity-explores">System Activity の History Explore</a> から、このようなフィールドを選択すれば利用頻度の高い Explore が分かります。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20221110/20221110171713.png" width="1200" height="692" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>設定してから一週間。BigQuery 料金はあまり変わりませんでした。😇</p>

<p><a href="https://cloud.google.com/looker/docs/system-activity-dashboards#dashboard_performance_dashboard">Database Performance ダッシュボード</a>の Results from Cache<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>は 18% から 20% に向上しました。もっと高いほうが良いのか、どうなのか...。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20221110/20221110165849.png" width="390" height="388" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>System Activity の History Explore からダッシュボードを作ってもみましたが、設定変更とキャッシュヒット率の相関性は見いだせませんでした。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20221110/20221110171721.png" width="1200" height="763" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>とはいえ、BigQuery 料金はそこまで増えなかったので、とりあえず続けています。</p>

<h2 id="まとめ">まとめ</h2>

<p>BigQuery 料金が増えたことをきっかけにして、Looker のキャッシュ設定を見直しました。</p>

<p>実装は整理できましたが、BigQuery 料金の変化はなく、キャッシュ難しい...という気持ちです。</p>

<h2 id="さらなるキャッシュへの理解">さらなるキャッシュへの理解</h2>

<p>中の人が翻訳して下さった記事がとても良いです。</p>

<p><a href="https://community.looker.com/%E3%82%B3%E3%83%A9%E3%83%A0-103/%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AE%E3%83%AD%E3%82%B0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B-28549">クエリのログからキャッシュを理解する | Looker Community</a></p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>キャッシュから返されたクエリの割合<a href="#fnref:1" rev="footnote">&#8617;</a></p></li>
</ol>
</div>



こんにちは。自称 Looker エバンジェリストの id:masutaka26 です。フィードフォースで Looker を使っているサービスで最近 BigQuery の料金が上がってきました。本当に使われているのならとても良いことですが、Looker のキャッシュが有効に使われずに BigQuery 料金が増えていたら嫌だなと思い、キャッシュの仕組みを思い出しつつ実装を整理してみました。Looker のキャッシュおさらい今回のサービスでのキャッシュ設定変更後のキャッシュ設定さらなる足掻きからの失敗もっと足掻いてからの困惑まとめさらなるキャッシュへの理解Looker のキャッシュおさらいLooker にはキャッシュの仕組みがあり、LookML 開発者が適切に設定することで、データベースのクエリ実行を減らすことができます。全く同じ SQL の実行結果がキャッシュされていれば、データベースにクエリ実行せずにキャッシュを返します。Looker ユーザーとしてはダッシュボードの表示速度向上のメリットがあり、LookML 開発者としては（BigQuery 等であれば）料金削減に繋がります。キャッシュの有効期限はデフォルトで 1 時間です。これは persist_for (for models) のデフォルト値です。今回のサービスでのキャッシュ設定良くも悪くも設定は最小限で、PDT（永続的派生テーブル）の実装箇所だけでした。例えば Google や Criteo などの広告媒体数値が入ったテーブルを参照する、all_media explore があります。このようなキャッシュ設定でした。datagroup: cache_all_media {  # 最新の日付か総レコード数に変化があったら検知する。  sql_trigger: SELECT CONCAT(MAX(date), '_', COUNT(*)) FROM @{table_all_media} ;;  max_cache_age: "1 hour"}explore: all_media {  persist_with: cache_all_media # (1)  # ...}view: all_media {  derived_table: {    # めちゃめちゃ長い SQL    sql: SELECT           ...         FROM @{table_all_media}         GROUP BY ... ;;    datagroup_trigger: cache_all_media # (2)    partition_keys: ["date"]  }  # ...}(1) で cache_all_media datagroup と all_media explore が persist_with (for Explores) で紐付くことで、以下の振る舞いが生まれます。sql_trigger によりテーブルの変更が検知されると、キャッシュが破棄されるmax_cache_age を超えたキャッシュは破棄されるつまりキャッシュの生存期間は最長でも 1 時間です。その前に PDT が再作成されればもっと短くなります。どちらかと言えば、データベースを優先する設定です。このテーブルは 1 日に 3 回しか更新されないため、最適化の余地がありそうです。(2) で cache_all_media datagroup と all_media view も datagroup_trigger で紐付いていますが、これは derived_table を永続化するための設定です。sql_trigger によりテーブルの変更が検知されると、PDT が再作成されるとともに、キャッシュが破棄されます。※ 余談: persist_with を設定していたことをすっかり忘れていたこともあり、調査前は (1) の理解が出来ていませんでした。😇変更後のキャッシュ設定紆余曲折あり、max_cache_age を少し増やしただけにしました。datagroup: cache_all_media {  # 最新の日付か総レコード数に変化があったら検知する。  sql_trigger: SELECT CONCAT(MAX(date), '_', COUNT(*)) FROM @{table_all_media} ;;  max_cache_age: "2 hours"}本当は "24 hours" にして「PDT 再作成のタイミングでのみキャッシュを破棄」したかったのですが、他の Explore でも参照される関係で、max_cache_age を思い切って増やせませんでした。さらなる足掻きからの失敗max_cache_age を 1 時間から 2 時間に増やした程度では、BigQuery 料金を抑えられたように見えませんでした。仕方がないので、all_media explore 以外の Explore で cache_all_media datagroup を使うのを止めて、専用 persist_with + datagroup を設定しました。このような LookML を 40 個書きました。😱datagroup: cache_corp_xxx {  sql_trigger:  SELECT                  STRING_AGG(CONCAT(table, '_', date, '_', count) ORDER BY table)                FROM (                  SELECT 'all_media' AS table, MAX(date) AS date, COUNT(*) AS count FROM @{table_all_media} UNION ALL                  SELECT 'UA_1', MAX(date), COUNT(*) FROM @{table_ga_xxx} UNION ALL                  SELECT 'UA_2', MAX(date), COUNT(*) FROM @{table_ga_xxx2}                ) ;;  max_cache_age: "24 hours" # テーブル更新のタイミングでのみ、キャッシュを破棄する。}explore: corp_xxx {  persist_with: cache_corp_xxx  # ...}結果的には大失敗。40 個の datagroup が 5 分に 1 回トリガーされる関係で、Looker を使わない土日でも BigQuery 料金が変わらなくなってしまいました。※ 補足: 「可能な限り Explore を少なくする」が Looker のベストプラクティスなので、40 個もの Explore は本来はアンチパターンです。ですが、今回のサービスはお客様にダッシュボードを提供する上に、やむを得ず個別実装が発生することもあります。そのような経緯で結果的にこの数になっています。もっと足掻いてからの困惑それならばと、利用頻度が高い Explore だけに、専用 persist_with + datagroup を設定すれば良いのでは？と思いました。System Activity の History Explore から、このようなフィールドを選択すれば利用頻度の高い Explore が分かります。設定してから一週間。BigQuery 料金はあまり変わりませんでした。😇Database Performance ダッシュボードの Results from Cache1は 18% から 20% に向上しました。もっと高いほうが良いのか、どうなのか...。System Activity の History Explore からダッシュボードを作ってもみましたが、設定変更とキャッシュヒット率の相関性は見いだせませんでした。とはいえ、BigQuery 料金はそこまで増えなかったので、とりあえず続けています。まとめBigQuery 料金が増えたことをきっかけにして、Looker のキャッシュ設定を見直しました。実装は整理できましたが、BigQuery 料金の変化はなく、キャッシュ難しい...という気持ちです。さらなるキャッシュへの理解中の人が翻訳して下さった記事がとても良いです。クエリのログからキャッシュを理解する | Looker Communityキャッシュから返されたクエリの割合↩

Looker のキャッシュの仕組みを思い出して実装を整理した

<p>こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『引っ越ししたら家賃が3分の1になったかも』というタイトルで、実際は Amazon CloudFront + Heroku で動いていた<a href="https://masutaka.net/">自分のブログ</a>を GCP の <a href="https://cloud.google.com/run">Cloud Run</a> に移行した話をしました。</p>

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTucSlV9z4czouHd-hIOiDBwaeh1a7CMbEm2mmx5kGDTijuRKJF4ID3blnnKz1nhG6rvMfMBLyTSFMM/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


<p>モチベーションはスライドにつらつら書きつつも、実際はこの FFTT の発表当番だったからではあります。結果的に満足行く結果にはなったので、これからコード管理などもう少し作り込んでいきます。<s>今後ネタに困ったらまた引っ越せばよいし。</s></p>

<p>Cloud Run もそうですが、<a href="https://domains.google/intl/ja_jp/">Google Domains</a> や <a href="https://cloud.google.com/monitoring">Cloud Monitoring</a> の外形監視（稼働時間チェック）など、便利でライトに使える GCP を知ることが出来たことも収穫でした。</p>

<p>それでは良い週末を！(^^)/</p>

<p><strong>2022-11-04 追記：</strong>
個人ブログにオチを書きました。
<a href="https://masutaka.net/2022-11-04-1/">Heroku から Cloud Run に移行して、料金は本当に3分の1になったのか | マスタカの ChangeLog メモ</a></p>


こんにちは id:masutaka26 です。本日、週次の社内勉強会 FFTT で『引っ越ししたら家賃が3分の1になったかも』というタイトルで、実際は Amazon CloudFront + Heroku で動いていた自分のブログを GCP の Cloud Run に移行した話をしました。モチベーションはスライドにつらつら書きつつも、実際はこの FFTT の発表当番だったからではあります。結果的に満足行く結果にはなったので、これからコード管理などもう少し作り込んでいきます。今後ネタに困ったらまた引っ越せばよいし。Cloud Run もそうですが、Google Domains や Cloud Monitoring の外形監視（稼働時間チェック）など、便利でライトに使える GCP を知ることが出来たことも収穫でした。それでは良い週末を！(^^)/2022-11-04 追記：個人ブログにオチを書きました。Heroku から Cloud Run に移行して、料金は本当に3分の1になったのか | マスタカの ChangeLog メモ

自分のブログを CloudFront + Heroku から Cloud Run に移行した話をした

こんにちは。自称 Looker エバンジェリストの id:masutaka26 です。今日は Spectacles というツールを導入して、Looker インスタンスの健全性を高められた話を紹介します。Spectacles とは4 種類のテスト基本的な振る舞いどのテストを採用し、どのような課題を解決したのかSQL validationAssert validationContent validationLookML validationどのような GitHub Actions にしたのかCI workflowSchedule workflow落ち穂拾い作業ブランチのゴミが残ることがあるマシンユーザーを作るか作らないかまとめSpectacles とはSpectacles は Looker のサードパーティ CI ツールです。継続的に各種テストを実行し、Looker インスタンスを健全に保つことが出来ます。クラウド版と OSS 版があり、それぞれ過去にクラスメソッドや、Zenn の記事で紹介されたことがあります。SpectaclesでLooker（LookML）のテストをやってみた | DevelopersIOLookerのCIツールであるSpectaclesを導入した話今回は OSS 版を使いました。github.com4 種類のテスト2022 年 9 月時点で 4 種類のテストが実装されています。SQL validation全ての Dimension の sql パラメーターについて、実際にクエリを実行し、その有効性を検証するdata warehouse のリソースを過剰に使わないよう工夫されている。例えば BigQuery の料金は発生しない1Assert validationLookML IDE 上でも実行できる LookML data tests を実行するContent validation開発メニューの Content Validator 相当の検証を行い、エラーのある Dashboard や Look を特定するLookML validationLookML IDE 上でも実行できる LookML validation を実行する基本的な振る舞いSpectacles は Looker API を使用し、指定した Looker インスタンス上で、LookML data tests や validation などを実行します。Spectacles -(Looker API)-> Your Looker Instanceいわゆるユニットテストでは、テスト環境でソースコードを checkout し、そこでテストを実行しますが、Spectacles はその点は全く違います。つまり GitHub Actions 等の CI で動かす場合、LookML コードの checkout は不要ということです。どのテストを採用し、どのような課題を解決したのかSQL validationいきなりですが、こちらは今回採用出来ませんでした。我々の環境で全ての Explore をテスト対象にすると、かなりの数のテストが失敗します。hidden: yes な Dimension がおそらく全てです。想定内です。$ spectacles sql --project my_project_name --profile -vそれならばと、--ignore-hidden オプションを付けると、今度はこんなエラーが発生します。どうやら 1 つも Dimension が表示されない Explore があるようです。こちらも想定内です。Explore object is missing dimensions, meaning this query won't have fields and will error. Often this happens because you didn't include dimensions when you built the project.--explore オプションでエラーが発生しない Explore を指定すればよいのですが、Explore が 150 個以上ある関係で、切り分けができていません。sql パラメーターは壊れていても、実際に Explore で当該 Dimension が使われないとエラーにならないのと、そのエラーが報告されるとも限らないので、いずれは再挑戦したいです。Assert validation我々の Looker インスタンスでは、BigQuery の外部テーブルに Google スプレッドシートを指定したテーブルを数多く参照しています。つまり人間が編集するデータです。このようなデータはオペミスにより壊れることがあり、primary_key も芋づる式に壊れることがあります。primary_key はほぼ全てテストを書いています2が、約 250 個と数が多いです。一方で LookML IDE 上での data tests は同時実行数が 1 に制限されているようで、テストに 10 分以上かかります。commit 前のテストを必須にできない状態でした。そのため、時々テストを手動実行しないと、壊れたことに気づけない課題がありました。以上の課題を解決するために、定期的に LookML data tests を実行し、手動実行せずに気付けるようになりました。Content validation今までは私の注意力で Dashboard 約 140 個と Look 約 30 個のエラー数ゼロを継続できていましたが、まさに属人的でした。これも定期的に実行し、Content Validator を手動実行することなく気付けるようになりました。LookML validation時々 LookML IDE を介さず、ローカル環境で git commit してデプロイすることがあります。そのケースで大きな変更をすることはないものの、validation が通らない LookML がデプロイされる確率はゼロではありません。こちらは git push のタイミングで実行することで、健全性を高めることが出来ました。どのような GitHub Actions にしたのかgit push のタイミングで実行する CI workflow と、定期的に実行する Schedule workflow を作りました。CI workflowgit push のたびに、当該 commit のブランチに対して、LookML validation のテストをしています3。name: CIon:  push:    branches-ignore: # ①      - 'dev-**'            # LookML IDE の個人用開発ブランチ      - 'tmp_spectacles_**' # spectacles の --commit-ref オプションが作るブランチjobs:  validate_lookml:    name: Validate LookML files    runs-on: ubuntu-latest    timeout-minutes: 5 # デフォルトは 360 分。料金のスパイクを防ぐ    concurrency: # ② spectacles が複数同時に実行しないようにする      spectacles_should_be_run_in_series    steps:    - uses: actions/setup-python@v4      with:        python-version: '3.x'    - name: Install Spectacles      run: pip install spectacles    - name: Run LookML Validator      env:        LOOKER_BASE_URL: "https://my_instance_name.looker.com"        LOOKER_CLIENT_ID: ${{ secrets.SPECTACLES_LOOKER_CLIENT_ID }} # ③        LOOKER_CLIENT_SECRET: ${{ secrets.SPECTACLES_LOOKER_CLIENT_SECRET }} # ③      run: spectacles lookml --project my_project_name --commit-ref "$GITHUB_SHA" -v①で特定のブランチを除外しています。特に今回のケースでは、tmp_spectacles_** を設定しないと validate_lookml ジョブが無限に起動し続けるため、絶対に必要です。②も結構重要で、CI workflow と次に示す Schedule workflow から起動される spectacles プロセスの同時実行数を 1 に制限しています。Spectacles は③と紐づく Looker ユーザーが実際に開発モードで tmp_spectacles_** というブランチを作り、切り替えます。Looker では 1 人のユーザーが同時に利用できるブランチは 1 つだけです。Spectacles の複数起動は問題が発生するため、今回の制限を設定しました。公式ドキュメントでも言及されています。Schedule workflow早朝と夕方に master（デフォルト）ブランチ上で、Content validation と LookML data tests を実行しています。name: Scheduleon:  schedule:    - cron: "00 21 * * 0-4" # 平日の  6:00 JST    - cron: "30  7 * * 1-5" # 平日の 16:30 JSTjobs:  schedule:    name: Scheduled job    runs-on: ubuntu-latest    timeout-minutes: 30 # デフォルトは 360 分。料金のスパイクを防ぐ    concurrency: # ① spectacles が複数同時に実行しないようにする      spectacles_should_be_run_in_series    env:      LOOKER_BASE_URL: "https://my_instance_name.looker.com"      LOOKER_CLIENT_ID: ${{ secrets.SPECTACLES_LOOKER_CLIENT_ID }}      LOOKER_CLIENT_SECRET: ${{ secrets.SPECTACLES_LOOKER_CLIENT_SECRET }}    steps:    - uses: actions/setup-python@v4      with:        python-version: '3.x'    - name: Install Spectacles      run: pip install spectacles    - name: Run Content Validator      run: spectacles content --project my_project_name -v    - name: Run LookML data tests      run: spectacles assert --project my_project_name -vブランチの時や、master ブランチへのマージ直後ではまだ Dashboard や Look がエラーになることがあるため、Content validation はこのタイミングにしています。LookML data tests も 10 分以上かかることと、git push の粒度でやらないと不安というわけではないため、このタイミングにしています。BigQuery の料金もかかりますからね。落ち穂拾い作業ブランチのゴミが残ることがあるSpectacles が途中で異常終了すると、LookML IDE と GitHub に tmp_spectacles_b016c8a4dd といった、Spectacles が作る作業ブランチが残ることがあります。気づいたら削除してあげましょう。正常終了の場合は残りません。マシンユーザーを作るか作らないかLooker はユーザー課金モデルであるため、Spectacles のためにユーザーを作ることに躊躇するかもしれません。私もそうでした。おまけに Developer 相当の権限が必要なため、そこそこの料金です。Create a Looker API Key | Spectacles DocsWe strongly recommend creating a dedicated Spectacles user in Looker to ensure a human user doesn't accidentally change the Git branch or turn off development mode in the middle of a validation.ですが、公式ドキュメントで強く奨励されているとおり、Spectacles 専用のユーザーを作って下さい。人間のユーザーは権限が大きすぎますし、前述のとおり Spectacles は実際に開発モードでブランチを作って切り替えるため、人間の作業とコンフリクトします。まとめSpectacles というツールを導入して、Looker インスタンスの健全性を高められた話をしました。導入したのは先月ですが、導入の翌日にタイミング良く Schedule workflow のテストが落ち、primary_key が壊れたことに気づけたことにはニッコリしました。私のようなボッチ LookML 開発者は、いかに作業を機械に任せるかが重要だと思います。心の平穏も大事です。また、あとから CI を導入するのは結構大変なので、始めから開発計画に組み込むことをオススメします。それでは良い Looker ライフを！(^^)/Limiting Resource Consumption | Spectacles Docs↩Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた - Feedforce Developer Blog↩実際には他のジョブや、失敗時の Slack 通知ジョブもありますが、分かりやすくするために省略しています。↩

OSS 版 Spectacles を使って、LookML の data tests や validation などを GitHub Actions で継続的に実行させてみた

<p>こんばんは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>本日、<a href="https://looker-japan-user-group.connpass.com/event/253923/">Looker User Meetup Online #8</a> で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をしてきました。Looker User Meetup は 5 回目の参加、発表は初めてです。</p>

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTlQkD3R2OS415gr51ieTs1pyy3cK0ck8By1PYJ8SZtrFDjWyLP1eD_s7Q4UDH_yvmTDNdHFpZQf0IU/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


<p>いくつかネタはあったのですが、今回のテーマは「Lookerまでのデータデリバリー、みんなどうしてる？」ということもあり、この 2 年で確立した方法を紹介することとなりました。</p>

<p>bq CLI ではなく、terraform で管理している方もいらっしゃいました。terraform の更新に追随するのはそれなりに大変だと思いますが、これならスキーマ定義と、実際のスキーマの差異検知は出来そうですね。</p>

<p>「dbt seed」を使っている方もいらっしゃるようでした。今回 2 つの発表があった dbt ですが、全く触ったことがありません。😇</p>

<p>あと、P24 で「BigQueryは一番左のシートしか参照できない」と書きましたが、誤りでした。範囲にでシート名も指定すれば出来ることを確認しました。P10 で華麗に「シート範囲」を無視してますね。💦</p>

<p><a href="https://gist.github.com/masutaka/142ca20b802401d12012fe952f2ea1f3">P18 の Gist</a> との差分は以下になります。</p>

<pre class="code lang-diff" data-lang="diff" data-unlink><span class="synType">diff --git a/define.json b/define.json</span>
<span class="synPreProc">index 9429e16..11d391c 100644</span>
<span class="synType">--- a/define.json</span>
<span class="synType">+++ b/define.json</span>
<span class="synStatement">@@ -1,7 +1,8 @@</span>
 {
   &quot;autodetect&quot;: false,
   &quot;googleSheetsOptions&quot;: {
<span class="synSpecial">-    &quot;skipLeadingRows&quot;: 1</span>
<span class="synIdentifier">+    &quot;skipLeadingRows&quot;: 1,</span>
<span class="synIdentifier">+    &quot;range&quot;: &quot;マスターデータ!A:E&quot;</span>
   },
   &quot;ignoreUnknownValues&quot;: false,
   &quot;maxBadRecords&quot;: 0,
</pre>


<p>一人開発の弊害ではありますが、こうやってアウトプットすることでこそ得られるフィードバックとも言えます。ある意味期待通りです。😄</p>

<p>次回以降も需要があれば発表したいと思います。</p>


こんばんは id:masutaka26 です。本日、Looker User Meetup Online #8 で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をしてきました。Looker User Meetup は 5 回目の参加、発表は初めてです。いくつかネタはあったのですが、今回のテーマは「Lookerまでのデータデリバリー、みんなどうしてる？」ということもあり、この 2 年で確立した方法を紹介することとなりました。bq CLI ではなく、terraform で管理している方もいらっしゃいました。terraform の更新に追随するのはそれなりに大変だと思いますが、これならスキーマ定義と、実際のスキーマの差異検知は出来そうですね。「dbt seed」を使っている方もいらっしゃるようでした。今回 2 つの発表があった dbt ですが、全く触ったことがありません。😇あと、P24 で「BigQueryは一番左のシートしか参照できない」と書きましたが、誤りでした。範囲にでシート名も指定すれば出来ることを確認しました。P10 で華麗に「シート範囲」を無視してますね。💦P18 の Gist との差分は以下になります。diff --git a/define.json b/define.jsonindex 9429e16..11d391c 100644--- a/define.json+++ b/define.json@@ -1,7 +1,8 @@ {   "autodetect": false,   "googleSheetsOptions": {-    "skipLeadingRows": 1+    "skipLeadingRows": 1,+    "range": "マスターデータ!A:E"   },   "ignoreUnknownValues": false,   "maxBadRecords": 0,一人開発の弊害ではありますが、こうやってアウトプットすることでこそ得られるフィードバックとも言えます。ある意味期待通りです。😄次回以降も需要があれば発表したいと思います。

Looker User Meetup Online #8 で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をした

<p>こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。<a href="https://developer.feedforce.jp/entry/2022/06/17/110000">先週</a>に引き続いてのブログ更新です。</p>

<p>Ruby や JavaScript などのプログラミング言語では、依存関係を管理することでコードの再利用性を高めるとともに、バグの少ないコードを書くことが出来ます。ただ、<a href="https://docs.looker.com/ja/data-modeling/learning-lookml/what-is-lookml">LookML</a> はプログラミング言語ではないため、同じ方法が使えません。</p>

<p>今回は LAMS という LookML Linter を導入することで、LookML の再利用性を高める糸口を見つけました。LAMS を紹介しつつ、その知見を共有します。</p>

<ul class="table-of-contents">
    <li><a href="#LAMS-とは">LAMS とは</a></li>
    <li><a href="#導入方法">導入方法</a></li>
    <li><a href="#ルールの免除">ルールの免除</a></li>
    <li><a href="#LookML-の再利用性を高められた-F1-ルール">LookML の再利用性を高められた F1 ルール</a></li>
    <li><a href="#注意事項">注意事項</a></li>
    <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="LAMS-とは">LAMS とは</h2>

<p>LAMS (Look At Me Sideways) は LookML のスタイルガイドと Linter がセットになったツールです。準公式のツールなのかな？</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Flooker-open-source%2Flook-at-me-sideways" title="GitHub - looker-open-source/look-at-me-sideways: A style guide and linter for Looker&#39;s LookML data modeling language" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/looker-open-source/look-at-me-sideways">github.com</a></cite></p>

<p>LookML IDE に付属する LookML validator が文法的な誤りを検出するのに対して、LAMS はメンテナンス性の高い、もう一歩進んだ LookML を提案します。</p>

<p>2022-06-21 現在、4 グループ、32 個のルールが定義されています。</p>

<p>🔗 <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html">LAMS Style Guide</a></p>

<ul>
<li>Key Dimensions (K1 ~ K6)</li>
<li>Other Fields (F1 ~ F6)</li>
<li>Derived Tables (T1 ~ T15)</li>
<li>Explores (E1 ~ E5)</li>
</ul>


<h2 id="導入方法">導入方法</h2>

<p>Linter を後から導入するのは辛いので、可能ならリポジトリを作るタイミングで導入するのが良いと思います。</p>

<p><a href="https://github.com/looker-open-source/look-at-me-sideways#deployment-examples">README の Deployment Examples</a> には、ローカルマシンで実行する方法や、GitHub Actions や CircleCI などで CI する方法がまとまっています。</p>

<p>今回は GitHub Actions を採用しました。git push するたびに LAMS が実行され、結果を Pull request 上で確認出来ます。参考までにコードを貼っておきます。</p>

<p><strong>.github/workflows/ci.yml</strong></p>

<pre class="code lang-yaml" data-lang="yaml" data-unlink><span class="synIdentifier">name</span><span class="synSpecial">:</span> CI

<span class="synIdentifier">on</span><span class="synSpecial">:</span> push

<span class="synIdentifier">jobs</span><span class="synSpecial">:</span>
  <span class="synIdentifier">lams</span><span class="synSpecial">:</span>
    <span class="synIdentifier">name</span><span class="synSpecial">:</span> LAMS LookML Linter
    <span class="synIdentifier">runs-on</span><span class="synSpecial">:</span> ubuntu-latest
    <span class="synIdentifier">steps</span><span class="synSpecial">:</span>
    <span class="synStatement">- </span><span class="synIdentifier">uses</span><span class="synSpecial">:</span> actions/checkout@v3
    <span class="synStatement">- </span><span class="synIdentifier">uses</span><span class="synSpecial">:</span> actions/setup-node@v3
      <span class="synIdentifier">with</span><span class="synSpecial">:</span>
        <span class="synIdentifier">node-version</span><span class="synSpecial">:</span> <span class="synConstant">'16'</span><span class="synComment"> # Use LTS https://nodejs.org/en/</span>
    <span class="synStatement">- </span><span class="synIdentifier">name</span><span class="synSpecial">:</span> Install LAMS
      <span class="synIdentifier">run</span><span class="synSpecial">:</span> npm install -g @looker/look-at-me-sideways@2
    <span class="synStatement">- </span><span class="synIdentifier">name</span><span class="synSpecial">:</span> Run LAMS
      <span class="synIdentifier">env</span><span class="synSpecial">:</span>
        <span class="synIdentifier">LOOKER_LICENSE_KEY</span><span class="synSpecial">:</span> ${{ secrets.LOOKER_LICENSE_KEY }}
      <span class="synIdentifier">run</span><span class="synSpecial">:</span> make lams
</pre>


<p><strong>Makefile</strong> <sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup></p>

<pre class="code makefile" data-lang="makefile" data-unlink>LAMS := lams
LOOKER_LICENSE_KEY := ${LOOKER_LICENSE_KEY}
REPORT_USER := feedmatic_report@example.com
SOURCE := **/{*.model,*.explore,*.view,*.layer,manifest}.lkml

.PHONY: lams
lams:
    @$(LAMS) --reporting=yes --report-license-key=$(LOOKER_LICENSE_KEY) --report-user=$(REPORT_USER) --source=&#39;$(SOURCE)&#39;</pre>


<h2 id="ルールの免除">ルールの免除</h2>

<p>manifest.lkml にこのように書くと、プロジェクト全体で任意のルールを免除することが出来ます。</p>

<pre class="code" data-lang="" data-unlink># LAMS
# rule_exemptions: {
#  F2: &#34;Any explanatory message you would like&#34;
#  F3: &#34;Another explanatory message for a different rule&#34;
# }</pre>


<p>dimension, measure, derived_table 単位でも免除することが出来ます。基本はこちらで免除し、無理そうなら manifest.lkml で免除すると良いでしょう。</p>

<p>初めから全てのルールをパスすることは少ないと思うので、必要に応じて免除すると良いでしょう。また、LAMS はあくまでスタイルガイドなので、必ずしも全てのルールに対応する必要はありません。</p>

<h2 id="LookML-の再利用性を高められた-F1-ルール">LookML の再利用性を高められた F1 ルール</h2>

<p>32 個のルールのうち、今回は個人的に一番意義というか、感心した <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#f1">F1</a> ルールを紹介します。</p>

<p>例えば orders.view から users.view の <code>count</code> measure を参照する、以下のような LookML があったとします。</p>

<p>LookML 書き始めの頃はこのように書きがちかと思いますが、F1 ルールでは NG です。orders.view が users.view に依存してしまうことで、orders.view の再利用がし辛くなるからです。そもそもこのケースでは LookML validation もエラーになるはずです。<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup></p>

<pre class="code" data-lang="" data-unlink>view: users {...}

view: orders {
  ...
  measure: orders_per_user {
    sql: ${count} / NULLIF(${users.count},0)
  }
}

explore: orders {} # Errors :(

explore: users {
  join: orders {...}
}</pre>


<p>解決方法がこちらです。まず、依存フィールドだけを抽出した users_orders.view を作ります。この view では sql_table_name や derived_table を設定しません。</p>

<pre class="code" data-lang="" data-unlink>view: users {...}
view: orders {...}

view: users_orders {
  # No need for a sql_table_name or derived_table
  measure: orders_per_user {
    sql: ${orders.count} / NULLIF(${users.count},0)
  }
}</pre>


<p>こうすることで少なくとも orders.explore は users.view に依存しないクリーンな LookML になりました。</p>

<pre class="code" data-lang="" data-unlink>explore: orders {} # Doesn&#39;t break like before!</pre>


<p>次に users.explore で魔法を使います。users.view と users_orders.view の Join で通常指定するはずの <code>sql_on ... ;;</code> の代わりに、空の SQL <code>sql: ;;</code> を指定します。</p>

<pre class="code" data-lang="" data-unlink>explore: users {
  join: orders {...}
  join: users_orders {
    sql: ;;
    # Use `sql` instead of `sql_on` and put some whitespace in it
    relationship: one_to_one
    view_label: &#34;Orders&#34; # For cleaner explore UI
  }
}</pre>


<p>え？と思うかもしれませんが、これは妥当な LookML です。</p>

<p>Users explore が生成する SQL を確認すると分かりますが、<code>orders_per_user</code> measure を選択しても Join 句は増えません。しかしこの measure が参照するテーブルは既存の users と orders だけなので、構文エラーになりません。</p>

<p>初見での理解は難しくなりますが、orders.view の再利用性が高まるのは大きなメリットです。</p>

<h2 id="注意事項">注意事項</h2>

<p><a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#k1">K1</a> と <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#k2">K2</a> のように、一部のルールには依存関係があり、一方を免除するためには両方免除する必要があります。</p>

<p>あと、まだ <a href="https://docs.looker.com/reference/view-params/extension-for-view">Extension</a> と <a href="https://docs.looker.com/ja/data-modeling/learning-lookml/refinements">Refinements</a> に対応していません。Issue <a href="https://github.com/looker-open-source/look-at-me-sideways/issues/46">#46</a> によると、<a href="https://github.com/fabio-looker/node-lookml-parser">パーサー</a>側は対応したそうで、あとは LAMS 本体を対応するだけだそうです。割と致命的な課題...。</p>

<h2 id="まとめ">まとめ</h2>

<p>LookML の Linter である LAMS を紹介しました。うまく使うことで、再利用性やメンテナンス性の高い LookML を書くことが出来るかもしれません。</p>

<p>それでは良い Looker ライフを！(^^)/</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>Makefile を作ったのは、ローカルで実行しやすくするためです。<a href="#fnref:1" rev="footnote">&#8617;</a></p></li>
<li id="fn:2">
<p><a href="https://help.looker.com/hc/en-us/articles/360023586293-Error-Unknown-or-Inaccessible-Field">F1 ルールに従わずにエラーを回避する方法はあります。</a><a href="#fnref:2" rev="footnote">&#8617;</a></p></li>
</ol>
</div>



こんにちは、id:masutaka26 です。先週に引き続いてのブログ更新です。Ruby や JavaScript などのプログラミング言語では、依存関係を管理することでコードの再利用性を高めるとともに、バグの少ないコードを書くことが出来ます。ただ、LookML はプログラミング言語ではないため、同じ方法が使えません。今回は LAMS という LookML Linter を導入することで、LookML の再利用性を高める糸口を見つけました。LAMS を紹介しつつ、その知見を共有します。LAMS とは導入方法ルールの免除LookML の再利用性を高められた F1 ルール注意事項まとめLAMS とはLAMS (Look At Me Sideways) は LookML のスタイルガイドと Linter がセットになったツールです。準公式のツールなのかな？github.comLookML IDE に付属する LookML validator が文法的な誤りを検出するのに対して、LAMS はメンテナンス性の高い、もう一歩進んだ LookML を提案します。2022-06-21 現在、4 グループ、32 個のルールが定義されています。🔗 LAMS Style GuideKey Dimensions (K1 ~ K6)Other Fields (F1 ~ F6)Derived Tables (T1 ~ T15)Explores (E1 ~ E5)導入方法Linter を後から導入するのは辛いので、可能ならリポジトリを作るタイミングで導入するのが良いと思います。README の Deployment Examples には、ローカルマシンで実行する方法や、GitHub Actions や CircleCI などで CI する方法がまとまっています。今回は GitHub Actions を採用しました。git push するたびに LAMS が実行され、結果を Pull request 上で確認出来ます。参考までにコードを貼っておきます。.github/workflows/ci.ymlname: CIon: pushjobs:  lams:    name: LAMS LookML Linter    runs-on: ubuntu-latest    steps:    - uses: actions/checkout@v3    - uses: actions/setup-node@v3      with:        node-version: '16' # Use LTS https://nodejs.org/en/    - name: Install LAMS      run: npm install -g @looker/look-at-me-sideways@2    - name: Run LAMS      env:        LOOKER_LICENSE_KEY: ${{ secrets.LOOKER_LICENSE_KEY }}      run: make lamsMakefile 1LAMS := lamsLOOKER_LICENSE_KEY := ${LOOKER_LICENSE_KEY}REPORT_USER := feedmatic_report@example.comSOURCE := **/{*.model,*.explore,*.view,*.layer,manifest}.lkml.PHONY: lamslams:    @$(LAMS) --reporting=yes --report-license-key=$(LOOKER_LICENSE_KEY) --report-user=$(REPORT_USER) --source='$(SOURCE)'ルールの免除manifest.lkml にこのように書くと、プロジェクト全体で任意のルールを免除することが出来ます。# LAMS# rule_exemptions: {#  F2: "Any explanatory message you would like"#  F3: "Another explanatory message for a different rule"# }dimension, measure, derived_table 単位でも免除することが出来ます。基本はこちらで免除し、無理そうなら manifest.lkml で免除すると良いでしょう。初めから全てのルールをパスすることは少ないと思うので、必要に応じて免除すると良いでしょう。また、LAMS はあくまでスタイルガイドなので、必ずしも全てのルールに対応する必要はありません。LookML の再利用性を高められた F1 ルール32 個のルールのうち、今回は個人的に一番意義というか、感心した F1 ルールを紹介します。例えば orders.view から users.view の count measure を参照する、以下のような LookML があったとします。LookML 書き始めの頃はこのように書きがちかと思いますが、F1 ルールでは NG です。orders.view が users.view に依存してしまうことで、orders.view の再利用がし辛くなるからです。そもそもこのケースでは LookML validation もエラーになるはずです。2view: users {...}view: orders {  ...  measure: orders_per_user {    sql: ${count} / NULLIF(${users.count},0)  }}explore: orders {} # Errors :(explore: users {  join: orders {...}}解決方法がこちらです。まず、依存フィールドだけを抽出した users_orders.view を作ります。この view では sql_table_name や derived_table を設定しません。view: users {...}view: orders {...}view: users_orders {  # No need for a sql_table_name or derived_table  measure: orders_per_user {    sql: ${orders.count} / NULLIF(${users.count},0)  }}こうすることで少なくとも orders.explore は users.view に依存しないクリーンな LookML になりました。explore: orders {} # Doesn't break like before!次に users.explore で魔法を使います。users.view と users_orders.view の Join で通常指定するはずの sql_on ... ;; の代わりに、空の SQL sql: ;; を指定します。explore: users {  join: orders {...}  join: users_orders {    sql: ;;    # Use `sql` instead of `sql_on` and put some whitespace in it    relationship: one_to_one    view_label: "Orders" # For cleaner explore UI  }}え？と思うかもしれませんが、これは妥当な LookML です。Users explore が生成する SQL を確認すると分かりますが、orders_per_user measure を選択しても Join 句は増えません。しかしこの measure が参照するテーブルは既存の users と orders だけなので、構文エラーになりません。初見での理解は難しくなりますが、orders.view の再利用性が高まるのは大きなメリットです。注意事項K1 と K2 のように、一部のルールには依存関係があり、一方を免除するためには両方免除する必要があります。あと、まだ Extension と Refinements に対応していません。Issue #46 によると、パーサー側は対応したそうで、あとは LAMS 本体を対応するだけだそうです。割と致命的な課題...。まとめLookML の Linter である LAMS を紹介しました。うまく使うことで、再利用性やメンテナンス性の高い LookML を書くことが出来るかもしれません。それでは良い Looker ライフを！(^^)/Makefile を作ったのは、ローカルで実行しやすくするためです。↩F1 ルールに従わずにエラーを回避する方法はあります。↩

LAMS を導入して、LookML の再利用性を高められた

<p>こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>今回は少し前に社内に共有した記事を、このブログでも共有します。Looker は Ruby や Python 等のプログラミング言語よりはユーザーが少ないはずで、質問相手がいないと本当に困ります。この記事がその一助になれば幸いです。</p>

<ul class="table-of-contents">
    <li><a href="#ググる">ググる</a></li>
    <li><a href="#チャット">チャット</a></li>
    <li><a href="#問い合わせフォーム">問い合わせフォーム</a></li>
    <li><a href="#Looker-Community-en">Looker Community (en)</a></li>
    <li><a href="#Looker-Community-ja">Looker Community (ja)</a></li>
    <li><a href="#Slack-Looker-User-Group---Japan">Slack Looker User Group - Japan</a></li>
    <li><a href="#番外編-製品についてのアイディアがありますか">番外編: 製品についてのアイディアがありますか？</a></li>
    <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="ググる">ググる</h2>

<p>さすがにこれは基本ですね。💦</p>

<p><a href="https://docs.looker.com/ja">公式ドキュメント</a> に誘導されることもしばしばです。これが結構よく出来ています。<code>looker table calculation</code> などと英語でググると、解決にたどり着きやすいかもしれません。</p>

<p>マニアックなテクニックとして、ググった URL の後ろに <code>&amp;gl=us&amp;hl=en&amp;gws_rd=cr</code> を付け、検索対象を英語にして、日本語のノイズを減らす方法もあります。</p>

<p><a href="https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8">https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8</a></p>

<p>↓</p>

<p><a href="https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr">https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr</a></p>

<p>私はこんなブックマークレットを使っています。ちなみに名前は <code>en</code> です。</p>

<pre class="code" data-lang="" data-unlink>javascript:location.href=location.href+&#39;&amp;gl=us&amp;hl=en&amp;gws_rd=cr&#39;</pre>


<h2 id="チャット">チャット</h2>

<p>Admin 権限を持ったユーザーだけが使用できます。</p>

<p>日本語可ですが、日々混んでいるので急ぎでなければ次の「問い合わせフォーム」が良いと思います。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616165108.png" width="313" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2 id="問い合わせフォーム">問い合わせフォーム</h2>

<p><a href="https://help.looker.com/hc/en-us/requests">https://help.looker.com/hc/en-us/requests</a> から <code>Create a New Request</code> をクリックします。Looker ユーザーなら誰でも利用可能なのかな？日本語可です。</p>

<p>このフォームは割と最近知ったのですが、問い合わせてみたら翌日返信が来て、速やかに解決できました。急がない時はチャットより良いと思います。サポートの方も時間に追われなくて良さそうです。</p>

<p>今までのチャット履歴もここで確認出来ます。これは知らなかった。</p>

<h2 id="Looker-Community-en">Looker Community (en)</h2>

<p>誰でも利用可能です。日本語不可。頻繁に投稿があります。</p>

<p><a href="https://community.looker.com/">https://community.looker.com/</a></p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616173918.png" width="1200" height="489" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2 id="Looker-Community-ja">Looker Community (ja)</h2>

<p>誰でも利用可能な日本語コミュニティです。稀に投稿があります。</p>

<p><a href="https://community.looker.com/%E3%83%98%E3%83%AB%E3%83%97%E3%81%A8%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88-101">コミュニティフォーラム (Japanese) > ヘルプとサポート</a></p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174114.png" width="1200" height="458" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>⚠️ <a href="https://community.looker.com/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-japanese-161">コミュニティフォーラム (Japanese) のトップ</a> で <code>Ask question / Create topic</code> ボタンをクリックすると en のほうにトピックが作られてしまいます。注意です。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174411.png" width="1116" height="774" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>このフォームが正解です。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174446.png" width="1200" height="690" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2 id="Slack-Looker-User-Group---Japan">Slack Looker User Group - Japan</h2>

<p>日本語の Slack コミュニティもあります。<a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E4%BC%9Aslack%E3%81%AE%E3%81%94%E6%A1%88%E5%86%85-28903">今年の初め (2022-01-14) に作られました</a>。</p>

<p><a href="https://join.slack.com/t/lookerusergroup-japan/shared_invite/zt-1auagto9i-cT2lV~cejC7MgxMrzvveow">この招待リンク</a>から参加出来ます。</p>

<h2 id="番外編-製品についてのアイディアがありますか">番外編: 製品についてのアイディアがありますか？</h2>

<p>新しい機能のアイディアを POST 出来る場所です。Admin 権限を持ったユーザーだけが使用できます。日本語不可です。</p>

<p>不具合も報告されることがあり、たまに 前述の「問い合わせフォーム」に誘導されています。それで知りました。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616175411.png" width="391" height="500" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2 id="まとめ">まとめ</h2>

<p>私が知る限りの「Looker で困った時の解決手段」をまとめました。</p>

<p>以前紹介した情報収集も日々継続すれば、Looker のスキルはかなり高まる実感があります。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F08%2F16%2F150000" title="私が１年かけて辿り着いた Looker の情報収集方法を紹介する - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>それでは良い Looker ライフを！(^^)/</p>


こんにちは、id:masutaka26 です。今回は少し前に社内に共有した記事を、このブログでも共有します。Looker は Ruby や Python 等のプログラミング言語よりはユーザーが少ないはずで、質問相手がいないと本当に困ります。この記事がその一助になれば幸いです。ググるチャット問い合わせフォームLooker Community (en)Looker Community (ja)Slack Looker User Group - Japan番外編: 製品についてのアイディアがありますか？まとめググるさすがにこれは基本ですね。💦公式ドキュメント に誘導されることもしばしばです。これが結構よく出来ています。looker table calculation などと英語でググると、解決にたどり着きやすいかもしれません。マニアックなテクニックとして、ググった URL の後ろに &gl=us&hl=en&gws_rd=cr を付け、検索対象を英語にして、日本語のノイズを減らす方法もあります。https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8↓https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr私はこんなブックマークレットを使っています。ちなみに名前は en です。javascript:location.href=location.href+'&gl=us&hl=en&gws_rd=cr'チャットAdmin 権限を持ったユーザーだけが使用できます。日本語可ですが、日々混んでいるので急ぎでなければ次の「問い合わせフォーム」が良いと思います。問い合わせフォームhttps://help.looker.com/hc/en-us/requests から Create a New Request をクリックします。Looker ユーザーなら誰でも利用可能なのかな？日本語可です。このフォームは割と最近知ったのですが、問い合わせてみたら翌日返信が来て、速やかに解決できました。急がない時はチャットより良いと思います。サポートの方も時間に追われなくて良さそうです。今までのチャット履歴もここで確認出来ます。これは知らなかった。Looker Community (en)誰でも利用可能です。日本語不可。頻繁に投稿があります。https://community.looker.com/Looker Community (ja)誰でも利用可能な日本語コミュニティです。稀に投稿があります。コミュニティフォーラム (Japanese) > ヘルプとサポート⚠️ コミュニティフォーラム (Japanese) のトップ で Ask question / Create topic ボタンをクリックすると en のほうにトピックが作られてしまいます。注意です。このフォームが正解です。Slack Looker User Group - Japan日本語の Slack コミュニティもあります。今年の初め (2022-01-14) に作られました。この招待リンクから参加出来ます。番外編: 製品についてのアイディアがありますか？新しい機能のアイディアを POST 出来る場所です。Admin 権限を持ったユーザーだけが使用できます。日本語不可です。不具合も報告されることがあり、たまに 前述の「問い合わせフォーム」に誘導されています。それで知りました。まとめ私が知る限りの「Looker で困った時の解決手段」をまとめました。以前紹介した情報収集も日々継続すれば、Looker のスキルはかなり高まる実感があります。それでは良い Looker ライフを！(^^)/

Looker で困った時の解決手段まとめ

<p>こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p><a href="https://www.looker.com/">Looker</a> を使い始めて 3 年目に突入しました。変わらず <a href="https://feedmatic.net/">Feedmatic</a> という広告運用コンサルティングのデータ整備をする毎日です。</p>

<p>今回はここ 1 年の懸案だった LookML Validation の堪え難い遅さを改善出来たので、共有します。</p>

<ul class="table-of-contents">
    <li><a href="#2-年間でコード量が肥大化した">2 年間でコード量が肥大化した</a></li>
    <li><a href="#LookML-Validation-が堪え難いほど遅くなった">LookML Validation が堪え難いほど遅くなった</a></li>
    <li><a href="#My-LookML-Validator-is-slow">My LookML Validator is slow!</a><ul>
            <li><a href="#TLDR">TL;DR</a></li>
            <li><a href="#Quick-wins">Quick wins</a></li>
            <li><a href="#Long-answer">Long answer</a></li>
            <li><a href="#Bonus-note">Bonus note</a></li>
        </ul>
    </li>
    <li><a href="#include-を最適化したら半分弱の時間になった">include を最適化したら半分弱の時間になった</a></li>
    <li><a href="#まとめ">まとめ</a></li>
    <li><a href="#余談">余談</a></li>
    <li><a href="#追記-LAMS-を使って-wildcard-include-を禁止する">追記: LAMS を使って wildcard include を禁止する</a></li>
</ul>

<h2 id="2-年間でコード量が肥大化した">2 年間でコード量が肥大化した</h2>

<p>2 年前と比べて Feedmatic プロジェクトの <code>.lkml</code> ファイルがものすごく増え、440 個、23,217 行<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>にもなりました。Explore は 62 個、<a href="/entry/2021/08/30/150000">テスト用</a>も含めると 150 個もあります。相変わらず<a href="/entry/2022/02/04/180000">ボッチ LookML 開発者</a>ではあるのですが。💦</p>

<p>さて、<a href="/entry/2020/10/23/190000">Looker の JumpStart</a> で教えて頂いた「モデル編成のベストプラクティス」のうちの 1 つにこちらがありました。</p>

<blockquote><p>ユーザーが必要とする答えに簡単にアクセスできる、可能な限り少ない数の explore を使用する。</p></blockquote>

<p>しかし、広告運用の文脈だと、クライアントごとに独自実装が必要なケースが多く、このコード量になってしまいました。💦</p>

<h2 id="LookML-Validation-が堪え難いほど遅くなった">LookML Validation が堪え難いほど遅くなった</h2>

<p>そんな LookML 開発に使用する Looker IDE には LookML Validator が付属しており、git commit 前に強制する設定をしています。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.looker.com%2Fja%2Fdata-modeling%2Fgetting-started%2Flookml-validation%23validating_your_lookml" title="Editing and validating LookML" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.looker.com/ja/data-modeling/getting-started/lookml-validation#validating_your_lookml">docs.looker.com</a></cite></p>

<p>以前は一瞬で完了していましたが、最近は 20 秒以上かかります。ちょっとコメントを書き換えただけでこれだけ待たされるのは、なかなかの苦行です。</p>

<p>試作した別プロジェクト（41 ファイル、1999 行）はそんなにかからないため、単純にコード量に比例していると思いました。</p>

<p>念のため Looker のサポートに質問したところ、やはりコード量（プロジェクトのサイズ）が影響しているそう。そして Looker インスタンスの CPU やメモリ使用量に問題はないとのこと。</p>

<p>さらに、こちらの記事を紹介して頂きました。🙏</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Ftechnical-tips-tricks-1021%2Fmy-lookml-validator-is-slow-23592" title="My LookML Validator is slow! | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://community.looker.com/technical-tips-tricks-1021/my-lookml-validator-is-slow-23592">community.looker.com</a></cite></p>

<h2 id="My-LookML-Validator-is-slow">My LookML Validator is slow!</h2>

<p>長い記事ではないので、ざっと翻訳します。</p>

<h3 id="TLDR">TL;DR</h3>

<p>プロジェクトが大きければ大きいほど、検証には時間がかかります。</p>

<h3 id="Quick-wins">Quick wins</h3>

<ol>
<li>戦略的に "includes" する

<ol>
<li>常に他のすべてのビューをインクルードすることは開発上簡単かもしれないが、命名規則を使って必要なファイルだけを戦略的にインクルードすることで、パフォーマンスを向上させることができる</li>
</ol>
</li>
<li>使用しない explore（および join、field など）をコメントアウトまたは削除する</li>
<li>プロジェクトを複数のプロジェクトに分割することを検討する</li>
</ol>


<p>LookML のベストプラクティスについては、<a href="https://community.looker.com/lookml-5/lookml-best-practices-1636">こちらの記事</a>をご覧ください。</p>

<h3 id="Long-answer">Long answer</h3>

<p>LookML のプロジェクトサイズ（総行数）と不要な <code>include</code> の両方が LookML Validator の性能に影響を及ぼします。</p>

<p>Validation は 2 段階のプロセスで行われます。</p>

<p>1) 1 回目の検証では、プロジェクト内のすべてのファイルを読み込み、どこにも参照されていないファイルも含めて、メモリに読み込み、ソースコードを 1 モデルずつ完全に翻訳して、「コンパイル」エラーを探します。</p>

<p>2) 2 回目の検証は、各モデルで開始し、そのモデルから参照されるファイルのみを解析します。そして、そのモデルに基づいてクエリーを構築し、クエリーエラーや「実行時」エラーを探します。また、これらのパスは、すべての検証で行われることも重要です。</p>

<p>結論として、1 回目の検証は LookML プロジェクトのサイズに、2 回目の検証は不要な <code>include</code> 文に影響されます。したがって、LookML プロジェクトのサイズを適切に保つと同時に、より選択的かつ戦略的な <code>include</code> を推奨するのが良いでしょう。</p>

<h3 id="Bonus-note">Bonus note</h3>

<p>Explore ごとのフィールド数は、検証時間という点で非常に重要です。これはしばしばモデルのパースよりも時間がかかります。</p>

<h2 id="include-を最適化したら半分弱の時間になった">include を最適化したら半分弱の時間になった</h2>

<p>今回は「戦略的に "includes" する」をやってみました。</p>

<p>具体的には 56 個の <code>.explore.lkml</code> ファイルを以下のように変更しました。ワイルドカード付きの <code>include</code> を出来るだけ減らしました。</p>

<pre class="code" data-lang="" data-unlink># 変更前
include: &#34;/views/**/*.view&#34;

↓

# 変更後
include: &#34;/views/view1.view&#34;
include: &#34;/views/view2.view&#34;
include: &#34;/views/view3.view&#34;
include: &#34;/views/view4.view&#34;
include: &#34;/views/view5.view&#34;</pre>


<p>結果がこちら。たったこれだけで、20 秒かかっていた LookML validation が 12 秒弱にまで縮まりました。期待以上です！👏😂🎉</p>

<table>
<thead>
<tr>
<th style="text-align:right;"> </th>
<th style="text-align:right;"> 変更前（秒） </th>
<th style="text-align:right;"> 変更後（秒） </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:right;"> 1 </td>
<td style="text-align:right;"> 20.46 </td>
<td style="text-align:right;"> 12.39 </td>
</tr>
<tr>
<td style="text-align:right;"> 2 </td>
<td style="text-align:right;"> 20.44 </td>
<td style="text-align:right;"> 11.89 </td>
</tr>
<tr>
<td style="text-align:right;"> 3 </td>
<td style="text-align:right;"> 20.05 </td>
<td style="text-align:right;"> 11.69 </td>
</tr>
<tr>
<td style="text-align:right;"> 3 </td>
<td style="text-align:right;"> 20.61 </td>
<td style="text-align:right;"> 11.65 </td>
</tr>
<tr>
<td style="text-align:right;"> 5 </td>
<td style="text-align:right;"> 20.48 </td>
<td style="text-align:right;"> 11.95 </td>
</tr>
<tr>
<td style="text-align:right;"> 平均 </td>
<td style="text-align:right;"> 20.41 </td>
<td style="text-align:right;"> 11.91 </td>
</tr>
</tbody>
</table>


<p>ついでに、事情があって隠している Explore 10 個<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup>の削除を確認してみたら、さらに速くなり、9 秒程度まで縮まりました。なるほど。</p>

<h2 id="まとめ">まとめ</h2>

<p>ここ 1 年の懸案だった LookML Validation のパフォーマンスを改善しました。</p>

<p>include を最適化するだけで、ここまで速くなるとは驚きでした。おまけに LookML Validation のプロセスも理解することもできました。</p>

<p>💭 コンパイラ側で良しなにするのは難しいのかな、<a href="https://github.com/looker-open-source/look-at-me-sideways">LAMS</a> で警告してくれれば良いのかな。</p>

<p>引き続き、LookML 開発を妨げる課題があれば、解決していきます。💪</p>

<h2 id="余談">余談</h2>

<p><code>Validate LookML</code> をクリックすると、すぐ <code>Validate LookML</code> に戻ることがあるのですが、なんででしょう...？ファイル保存直後だとほぼ発生します。</p>

<p><img src="https://user-images.githubusercontent.com/170014/170627597-55819ca6-7394-4900-9e33-9ed0c1ce2492.gif" alt="looker" /></p>

<p>Validation が終わる時間くらいまで待つと 2 回クリックしなくて良いみたいです。🙄</p>

<p><img src="https://user-images.githubusercontent.com/170014/170627672-f1bf212b-ab73-48f3-9feb-4e8f751984b6.gif" alt="looker2" /></p>

<h2 id="追記-LAMS-を使って-wildcard-include-を禁止する">追記: LAMS を使って wildcard include を禁止する</h2>

<p>LookML の Linter として LAMS というものがあります。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2022%2F06%2F21%2F130000" title="LAMS を導入して、LookML の再利用性を高められた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2022/06/21/130000">developer.feedforce.jp</a></cite></p>

<p>このカスタムルールを定義することで、今回のようなワイルドカード付きの <code>include</code> を禁止することが出来ます。</p>

<p>manifest.lkml にこのように書くだけです。</p>

<pre class="code" data-lang="" data-unlink># LAMS
# rule: NO_WINC {
#  description: &#34;Prohibit wildcard include to avoid increasing LookML verification time&#34;
#  match: &#34;$.files.*.include.*&#34;
#  expr_rule: ($let file_path ($get ::project files ::path:2 $file_path))
#             ($if ($match &#34;\\*&#34; ::match)
#                 ($concat &#34;Found wildcard include &#39;&#34; ::match &#34;&#39; in &#34; ::file_path &#34;&#34;)
#               true) ;;
# }</pre>


<p><a href="https://looker-open-source.github.io/look-at-me-sideways/customizing-lams">Customizing LAMS</a> にさらりと書いてありますが、指摘されたファイル名を出す方法が分からなかったので、Issue <a href="https://github.com/looker-open-source/look-at-me-sideways/issues/95">#95</a> で質問したら分かりました。これは分からない。💦</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<p>コメントと空行を除く<a href="#fnref:1" rev="footnote">&#8617;</a></p></li>
<li id="fn:2">
<p><code>.explore.lkml</code> 10 個、<code>.view.lkml</code> 10 個、<code>.layer.lkml</code> 31 個<a href="#fnref:2" rev="footnote">&#8617;</a></p></li>
</ol>
</div>



こんにちは、id:masutaka26 です。Looker を使い始めて 3 年目に突入しました。変わらず Feedmatic という広告運用コンサルティングのデータ整備をする毎日です。今回はここ 1 年の懸案だった LookML Validation の堪え難い遅さを改善出来たので、共有します。2 年間でコード量が肥大化したLookML Validation が堪え難いほど遅くなったMy LookML Validator is slow!TL;DRQuick winsLong answerBonus noteinclude を最適化したら半分弱の時間になったまとめ余談追記: LAMS を使って wildcard include を禁止する2 年間でコード量が肥大化した2 年前と比べて Feedmatic プロジェクトの .lkml ファイルがものすごく増え、440 個、23,217 行1にもなりました。Explore は 62 個、テスト用も含めると 150 個もあります。相変わらずボッチ LookML 開発者ではあるのですが。💦さて、Looker の JumpStart で教えて頂いた「モデル編成のベストプラクティス」のうちの 1 つにこちらがありました。ユーザーが必要とする答えに簡単にアクセスできる、可能な限り少ない数の explore を使用する。しかし、広告運用の文脈だと、クライアントごとに独自実装が必要なケースが多く、このコード量になってしまいました。💦LookML Validation が堪え難いほど遅くなったそんな LookML 開発に使用する Looker IDE には LookML Validator が付属しており、git commit 前に強制する設定をしています。docs.looker.com以前は一瞬で完了していましたが、最近は 20 秒以上かかります。ちょっとコメントを書き換えただけでこれだけ待たされるのは、なかなかの苦行です。試作した別プロジェクト（41 ファイル、1999 行）はそんなにかからないため、単純にコード量に比例していると思いました。念のため Looker のサポートに質問したところ、やはりコード量（プロジェクトのサイズ）が影響しているそう。そして Looker インスタンスの CPU やメモリ使用量に問題はないとのこと。さらに、こちらの記事を紹介して頂きました。🙏community.looker.comMy LookML Validator is slow!長い記事ではないので、ざっと翻訳します。TL;DRプロジェクトが大きければ大きいほど、検証には時間がかかります。Quick wins戦略的に "includes" する常に他のすべてのビューをインクルードすることは開発上簡単かもしれないが、命名規則を使って必要なファイルだけを戦略的にインクルードすることで、パフォーマンスを向上させることができる使用しない explore（および join、field など）をコメントアウトまたは削除するプロジェクトを複数のプロジェクトに分割することを検討するLookML のベストプラクティスについては、こちらの記事をご覧ください。Long answerLookML のプロジェクトサイズ（総行数）と不要な include の両方が LookML Validator の性能に影響を及ぼします。Validation は 2 段階のプロセスで行われます。1) 1 回目の検証では、プロジェクト内のすべてのファイルを読み込み、どこにも参照されていないファイルも含めて、メモリに読み込み、ソースコードを 1 モデルずつ完全に翻訳して、「コンパイル」エラーを探します。2) 2 回目の検証は、各モデルで開始し、そのモデルから参照されるファイルのみを解析します。そして、そのモデルに基づいてクエリーを構築し、クエリーエラーや「実行時」エラーを探します。また、これらのパスは、すべての検証で行われることも重要です。結論として、1 回目の検証は LookML プロジェクトのサイズに、2 回目の検証は不要な include 文に影響されます。したがって、LookML プロジェクトのサイズを適切に保つと同時に、より選択的かつ戦略的な include を推奨するのが良いでしょう。Bonus noteExplore ごとのフィールド数は、検証時間という点で非常に重要です。これはしばしばモデルのパースよりも時間がかかります。include を最適化したら半分弱の時間になった今回は「戦略的に "includes" する」をやってみました。具体的には 56 個の .explore.lkml ファイルを以下のように変更しました。ワイルドカード付きの include を出来るだけ減らしました。# 変更前include: "/views/**/*.view"↓# 変更後include: "/views/view1.view"include: "/views/view2.view"include: "/views/view3.view"include: "/views/view4.view"include: "/views/view5.view"結果がこちら。たったこれだけで、20 秒かかっていた LookML validation が 12 秒弱にまで縮まりました。期待以上です！👏😂🎉  変更前（秒）  変更後（秒）  1  20.46  12.39  2  20.44  11.89  3  20.05  11.69  3  20.61  11.65  5  20.48  11.95  平均  20.41  11.91 ついでに、事情があって隠している Explore 10 個2の削除を確認してみたら、さらに速くなり、9 秒程度まで縮まりました。なるほど。まとめここ 1 年の懸案だった LookML Validation のパフォーマンスを改善しました。include を最適化するだけで、ここまで速くなるとは驚きでした。おまけに LookML Validation のプロセスも理解することもできました。💭 コンパイラ側で良しなにするのは難しいのかな、LAMS で警告してくれれば良いのかな。引き続き、LookML 開発を妨げる課題があれば、解決していきます。💪余談Validate LookML をクリックすると、すぐ Validate LookML に戻ることがあるのですが、なんででしょう...？ファイル保存直後だとほぼ発生します。Validation が終わる時間くらいまで待つと 2 回クリックしなくて良いみたいです。🙄追記: LAMS を使って wildcard include を禁止するLookML の Linter として LAMS というものがあります。developer.feedforce.jpこのカスタムルールを定義することで、今回のようなワイルドカード付きの include を禁止することが出来ます。manifest.lkml にこのように書くだけです。# LAMS# rule: NO_WINC {#  description: "Prohibit wildcard include to avoid increasing LookML verification time"#  match: "$.files.*.include.*"#  expr_rule: ($let file_path ($get ::project files ::path:2 $file_path))#             ($if ($match "\\*" ::match)#                 ($concat "Found wildcard include '" ::match "' in " ::file_path "")#               true) ;;# }Customizing LAMS にさらりと書いてありますが、指摘されたファイル名を出す方法が分からなかったので、Issue #95 で質問したら分かりました。これは分からない。💦コメントと空行を除く↩.explore.lkml 10 個、.view.lkml 10 個、.layer.lkml 31 個↩

LookML Validation を 20 秒から 11 秒に高速化出来た

<p>こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『ボッチLookML開発者兼データ整備人を連れてきたよ！』というひどいタイトルの発表をしました。</p>

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTv911SmUBM9fAk-IKQM9139Q29fU7INnUHwbFeOBxolqyybPdlcFHW2dAHBTgr3P9J_kL0Xdhbe38L/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


<p>2020 年 4 月から Looker に関わって得たことをまとめた内容であるとともに、1 年半近く前からのアップデートになります。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2020/10/23/190000">developer.feedforce.jp</a></cite></p>

<p>世に出ている Looker の情報はキラキラしているものが多く、ツラい話をそれほど目にしません。<s>絶対にあるはずなのに！😭</s></p>

<p>それならば！とツラい話や解決が困難な話を散りばめさせてもらいました。課題が共有されて初めて知見が役に立つと思いますからね。<em>解決した課題もあるよ（小声）。</em></p>

<p>それでは良い週末を！(^^)/</p>


こんにちは id:masutaka26 です。本日、週次の社内勉強会 FFTT で『ボッチLookML開発者兼データ整備人を連れてきたよ！』というひどいタイトルの発表をしました。2020 年 4 月から Looker に関わって得たことをまとめた内容であるとともに、1 年半近く前からのアップデートになります。developer.feedforce.jp世に出ている Looker の情報はキラキラしているものが多く、ツラい話をそれほど目にしません。絶対にあるはずなのに！😭それならば！とツラい話や解決が困難な話を散りばめさせてもらいました。課題が共有されて初めて知見が役に立つと思いますからね。解決した課題もあるよ（小声）。それでは良い週末を！(^^)/

『ボッチLookML開発者兼データ整備人を連れてきたよ！』という発表をした

<p>こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>この記事は Looker Advent Calendar 2021 の 13 日目の記事です。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2021%2Flooker" title="Calendar for Looker | Advent Calendar 2021 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2021/looker">qiita.com</a></cite></p>

<p>昨日は Yappli 阿部さんの「<a href="https://tech.yappli.io/entry/2021/12/12/Sexy_Tech_for_You_9">Lookerの目標値やストップワードを、Googleスプレッドシート連携でお手軽管理【Sexy Tech for You #9】</a>」でした。Looker を使うとこのような LookML を書くだけで、ビジネスユーザーが SQL を書くことなく、本業に集中できるのはとても良いですよね。</p>

<p>個人的には、SQL ベースの派生テーブルの中で join するよりも、explore で join したほうが Looker らしく、メンテナンス性が良い気がしました。<a href="https://help.looker.com/hc/en-us/articles/360023722974">symmetric 集計</a>が働くため、ファンアウトも避けられます。wikipedia テーブルに関しては、永続的な派生テーブル（PDT）を使って BigQuery のスキャンサイズを抑えるのも良さそうです。</p>

<p>、、、( ﾟдﾟ)ハッ！ついマジレスをしてしまいました。💦</p>

<p>今回は dimension が null の measure を（0 ではなく）ø にする少しマニアックな記事を書く予定でしたが、先日の <a href="https://looker-japan-user-group.connpass.com/event/233775/">Looker User Meetup Online #7</a> で、LookML のディレクトリ構造を知りたいというチャットをお見かけしたので、今回はその話を書くことにしました。</p>

<ul class="table-of-contents">
    <li><a href="#今回のプロジェクトの規模感">今回のプロジェクトの規模感</a></li>
    <li><a href="#デフォルトのディレクトリ構造">デフォルトのディレクトリ構造？</a></li>
    <li><a href="#特別なファイル形式を知る">特別なファイル形式を知る</a></li>
    <li><a href="#最近使っているディレクトリ構造">最近使っているディレクトリ構造</a><ul>
            <li><a href="#bigquery">bigquery/</a></li>
            <li><a href="#model1modellkml">model1.model.lkml</a></li>
            <li><a href="#explores">explores/</a></li>
            <li><a href="#views">views/</a></li>
            <li><a href="#tests">tests/</a></li>
            <li><a href="#manifestlkml">manifest.lkml</a></li>
        </ul>
    </li>
    <li><a href="#まとめ">まとめ</a></li>
    <li><a href="#2021-12-29-追記">2021-12-29 追記</a></li>
</ul>

<h2 id="今回のプロジェクトの規模感">今回のプロジェクトの規模感</h2>

<p>プロジェクトの規模感によってディレクトリ構造は変わると思うので、先に書いておきます。</p>

<ul>
<li>Looker インスタンスに 1 つだけ LookML プロジェクトが存在する</li>
<li>BigQuery Dataset 76 個</li>
<li><code>.lkml</code> ファイル 277 個

<ul>
<li><code>.model.lkml</code> ファイル 1 個</li>
<li><code>.explore.lkml</code> ファイル 56 個</li>
<li><code>.view.lkml</code> ファイル 139 個</li>
<li><code>.test.lkml</code> ファイル 78 個</li>
</ul>
</li>
<li>LookML 開発者 1 名</li>
</ul>


<h2 id="デフォルトのディレクトリ構造">デフォルトのディレクトリ構造？</h2>

<p>この記事を書くまで誤解をしていたのですが、デフォルトのディレクトリ構造というものはなかったのですね。この記事を書くために改めて Blank Project を作ったら、ファイルもディレクトリも何もないプロジェクトが作られました。</p>

<p>モデルファイルを作るとこのようなコードが展開されるので、<code>.view.lkml</code> に関しては <code>/views/</code> 以下に作る方が多いと思います。私もそうでした。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;/views/*.view.lkml&#34;                # include all views in the views/ folder in this project
# include: &#34;/**/*.view.lkml&#34;                 # include all views in this project
# include: &#34;my_dashboard.dashboard.lookml&#34;   # include a lookml dashboard called my_dashboard</pre>


<p>例えばこのようになります。</p>

<pre class="code" data-lang="" data-unlink>feedmatic.model.lkml
views
├── all_media.view.lkml
└── ga.view.lkml</pre>


<p>開発初期は <code>feedmatic.model.lkml</code> に view 以外の、explore や datagroup などをズラズラと書いていました。</p>

<h2 id="特別なファイル形式を知る">特別なファイル形式を知る</h2>

<p>ご存知の通り、LookML のファイル形式は <code>.lkml</code> です。</p>

<p>LookML 開発が続くと <code>.model.lkml</code> や <code>.view.lkml</code> などが増えていきますが、この中で唯一意味を持つのが <code>.model.lkml</code> です<sup id="fnref:1"><a href="#fn:1" rel="footnote">1</a></sup>。その他のファイル形式は整理のために自由に作ることが出来ます。</p>

<p>例えば <code>feedmatic.model.lkml</code> を作ると、<code>feedmatic</code> というモデルが定義されます。<code>https://{{your looker domain}}/projects</code> で確認できます。<code>all_media.view.lkml</code> を作っても、何かが作られるわけではありません。</p>

<p>以上の知識を持った上で、公式ドキュメントを読むと理解が深まるかもしれません。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.looker.com%2Fja%2Fdata-modeling%2Flearning-lookml%2Flookml-terms-and-concepts" title="Looker documentation  |  Google Cloud" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<h2 id="最近使っているディレクトリ構造">最近使っているディレクトリ構造</h2>

<p>こんな感じです。それぞれ解説していきます。</p>

<pre class="code" data-lang="" data-unlink>bigquery
├── spreadsheet1
│   ├── define.json
│   └── schema.json
└── spreadsheet2
    ├── define.json
    └── schema.json
model1.model.lkml
explores
├── corp
│   ├── base.explore.lkml
│   ├── name1.explore.lkml
│   └── name2.explore.lkml
├── explore1.explore.lkml
└── explore2.explore.lkml
views
├── corp
│   ├── base.view.lkml
│   ├── name1.view.lkml
│   └── name2.view.lkml
├── view1.view.lkml
└── view2.view.lkml
tests
└── model1
    ├── corp
    │   ├── name1.test.lkml
    │   └── name2.test.lkml
    ├── explore1.test.lkml
    └── explore2.test.lkml
manifest.lkml</pre>


<h3 id="bigquery">bigquery/</h3>

<p>いきなり LookML 関係ありません。💦</p>

<p>BigQuery はデータソースに Google スプレッドシートを指定でき、そのスキーマ定義はコード化することが出来ます。</p>

<p>コード化することで変更履歴を Git で管理できますし、BigQuery CLI を使って簡単に Dataset や Table を作ったり、削除したりが出来ます。</p>

<pre class="code" data-lang="" data-unlink>$ bq mk spreadsheet1
$ bq mk --external_table_definition=./define.json spreadsheet1.gsheet
$ bq rm -r spreadsheet1</pre>


<p>破壊的な変更をする時は、バージョン名を付けた Dataset を新規作成し、LookML から参照先を変えます。こうすることで、本番環境に影響を与えずに開発することが出来ます。</p>

<pre class="code" data-lang="" data-unlink>$ bq mk spreadsheet1_v2
$ bq mk --external_table_definition=./define.json spreadsheet1_v2.gsheet</pre>


<p>スキーマ定義は公式ドキュメントをご覧下さい。需要があればそんな記事を書きます。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcloud.google.com%2Fconfig-connector%2Fdocs%2Freference%2Fresource-docs%2Fbigquery%2Fbigquerytable%3Fhl%3Dja" title="BigQueryTable  |  Config Connector Documentation  |  Google Cloud" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<p>他の Dataset は ETL ツール<sup id="fnref:2"><a href="#fn:2" rel="footnote">2</a></sup>が作るためコード化はしていません。</p>

<h3 id="model1modellkml">model1.model.lkml</h3>

<p>中心となるこのファイルは軽いです。本当にこの程度しか書いていません。</p>

<pre class="code" data-lang="" data-unlink>connection: &#34;docs_bigquery_db&#34;

include: &#34;/explores/**/*.explore&#34;
include: &#34;/tests/model1/**/*.test&#34;

named_value_format: jpy_0 {
  value_format: &#34;\¥#,##0&#34;
}

named_value_format: jpy_1 {
  value_format: &#34;\¥#,##0.0&#34;
}

# for test
access_grant: can_view_explores_for_tests {
  user_attribute: view_explores_for_tests
  allowed_values: [&#34;yes&#34;]
}</pre>


<p>必要な定義は <code>connection</code> と <code>include</code> だけです。</p>

<p>include 対象を全ての <code>.explore.lkml</code> と、このモデルに関連するテスト（<code>tests/feedmatic/</code> 以下全ての <code>.test.lkml</code>）だけにしていることがポイントです。つまり <code>.model.lkml</code> は <code>.explore.lkml</code> と自分の <code>.test.lkml</code> しか知りません。</p>

<p>あとは蛇足で、<code>named_value_format</code> と、<a href="/entry/2021/08/30/150000">前回紹介したテスト</a>に必要な <code>access_grant</code> だけです。</p>

<h3 id="explores">explores/</h3>

<p>1 つの explore を 1 つのファイルに定義しています。</p>

<p><code>explores/explore1.explore.lkml</code> はこのように書いています。<code>.explore.lkml</code> は <code>.view.lkml</code> しか知りません。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;/views/**/*.view&#34;

explore: explore1 {
  # ...
}</pre>


<p>紆余曲折あり、<code>explores/corp/name1.explore.lkml</code> のような取引先ごとの explore もあります。</p>

<p>基本となる <code>explores/corp/base.explore.lkml</code> はこのような定義です。ファイル名と explore 名を変えていることがポイントです。Ruby の慣習を参考にしました。</p>

<pre class="code" data-lang="" data-unlink>explore: corp_base {
  extension: required
  # ...
}</pre>


<p><code>corp_base</code> explore を継承する、各取引先の explore はこのような定義です。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;./base.explore&#34;
include: &#34;/views/**/*.view&#34;

explore: corp_name1 {
  extends: [corp_base]
  # ...
}</pre>


<h3 id="views">views/</h3>

<p>view も explore と同様に、1 view 1 ファイルに定義しています。</p>

<p><code>views/view1.view.lkml</code> です。<code>.view.lkml</code> は <code>.model.lkml</code>, <code>.explore.lkml</code>, <code>.test.lkml</code> の誰も知りません。</p>

<pre class="code" data-lang="" data-unlink>view: view1 {
  # ...
}</pre>


<p>取引先ごとの view も同じです。<code>views/corp/base.view.lkml</code> はこんな感じで、</p>

<pre class="code" data-lang="" data-unlink>view: corp_base {
  extension: required
  # ...
}</pre>


<p>継承先の <code>views/corp/name1.view.lkml</code> はこんな感じです。</p>

<pre class="code" data-lang="" data-unlink>include: &#34;./base.view&#34;

view: corp_name1 {
  extends: [corp_base]
  # ...
}</pre>


<h3 id="tests">tests/</h3>

<p>テストはかなり書いており、2021-12-13 現在、184 もあります。</p>

<p>ほぼ explore 単位でファイル分割しています。分割することで、ファイル単位のテストが可能になっています。</p>

<p>こちらのベストプラクティスに従っています。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Flookml-data-tests-recommendations-and-best-practices-20815" title="LookML Data Tests: Recommendations and Best Practices | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<p>テスト対象はこんな感じです。</p>

<ul>
<li>(1) LookML で特別な実装をしていて、壊れても気づくのが難しそうな実装</li>
<li>(2) <code>primary_key</code> が重複していないか？ null になっていないか？を全ての view に対して</li>
</ul>


<p>(2) は前回詳しく書きました。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F08%2F30%2F150000" title="Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<p>実行に時間がかかることが悩みで以前こんな Topic を作りましたが、反応ゼロでした。みなさん課題ではないのかしら？💦</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Fis-it-possible-to-run-tests-in-parallel-28222" title="Is it possible to run tests in parallel? | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<p><code>primary_key</code> は壊れた時に気づくのが難しく、LookML 開発者が私だけということもあるため、機械的に全ての <code>primary_key</code> をテスト出来るようにしています。ただ、全テストは結構時間がかかるので、日に 1 回くらいの頻度で手動実行しています。CI したい...。</p>

<h3 id="manifestlkml">manifest.lkml</h3>

<p>ディレクトリ構造とは関係ありませんが、manifest.lkml についても触れておきましょう。</p>

<p><code>bigquery/</code> の項で書いたとおり、テーブル定義に破壊的な変更を加える時は <code>dataset_v2</code> のように Dataset 名にゆるふわバージョンを付けています。つまり割とカジュアルに Dataset 名が変わります。</p>

<p>そのため、このように manifest.lkml で全ての Dataset 名を定義しています<sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup>。Dataset 名は複数箇所で使われ得るためです。</p>

<pre class="code" data-lang="" data-unlink>constant: table_name1  { value: &#34;`table1_v2.gsheet`&#34; }
constant: table_name2  { value: &#34;`table2.view`&#34; }</pre>


<p>利用例です。</p>

<pre class="code" data-lang="" data-unlink>sql_table_name: @{table_name1} ;;</pre>


<h2 id="まとめ">まとめ</h2>

<p>現在 LookML 開発で使っているディレクトリ構造を紹介しました。中規模くらいまでの LookML プロジェクトには使える実感があります。</p>

<p>ただ、最近はファイル数が多くなってきて、<code>.view.lkml</code> を追加した時に変更する <code>.explore.lkml</code> と <code>.test.lkml</code> の距離が遠く、実装しづらい課題があります。</p>

<p>Refinements を使えば解決できるのだろうか、もっと再利用性のあるコードにしたいなど、悩みは尽きないです。</p>

<p>こちらの記事は読んで手も動かしたのですが、巨大なファイルを分割する、Blocks のようなライブラリをカスタマイズする（？）、以外の使い方を見いだせていません。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2F%25E3%2582%25B3%25E3%2583%25A9%25E3%2583%25A0-103%2Frefinements%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%25A3%25E3%2581%25A6lookml%25E3%2581%25AE%25E3%2582%25B3%25E3%2583%25BC%25E3%2583%2589%25E3%2582%2592%25E6%2595%25B4%25E7%2590%2586%25E3%2581%2599%25E3%2582%258B-18809" title="Refinementsを使ってLookMLのコードを整理する | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe></p>

<p>皆さんのディレクトリ構造も是非教えて下さい！</p>

<h2 id="2021-12-29-追記">2021-12-29 追記</h2>

<p><a href="https://community.looker.com/lookml-5/what-is-the-looker-recommended-folder-structure-for-lookml-development-28826">What is the looker recommended folder structure for LookML development ? | Looker Community</a></p>

<p>Looker Community にもお悩みの方がいらっしゃいました。返信している Dawid さんはよくお見かけする方で、かなりの熟練者だと思います。</p>

<p>そんな彼も、今回私が書いた記事のような物理的な構造が良いのか、論理的な構造が良いのか、未だに試行錯誤しているようです。</p>

<p>始めは物理的なディレクトリ構造から始めて、徐々に変化しながら論理的な構造に近づくのかもしれません。その頃にはステージに応じたベストプラクティスが出ていると良いですね。</p>
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
正確に書くと <code>manifest.lkml</code> や <code>.strings.json</code> などもありますが、一旦考えなくて良いと思います。<a href="#fnref:1" rev="footnote">&#8617;</a></li>
<li id="fn:2">
<a href="https://funnel.io/">Funnel.io</a> を使っています。<a href="#fnref:2" rev="footnote">&#8617;</a></li>
<li id="fn:3">
1 行で書いているのはソートしやすくするためです。<a href="#fnref:3" rev="footnote">&#8617;</a></li>
</ol>
</div>



こんにちは、id:masutaka26 です。この記事は Looker Advent Calendar 2021 の 13 日目の記事です。qiita.com昨日は Yappli 阿部さんの「Lookerの目標値やストップワードを、Googleスプレッドシート連携でお手軽管理【Sexy Tech for You #9】」でした。Looker を使うとこのような LookML を書くだけで、ビジネスユーザーが SQL を書くことなく、本業に集中できるのはとても良いですよね。個人的には、SQL ベースの派生テーブルの中で join するよりも、explore で join したほうが Looker らしく、メンテナンス性が良い気がしました。symmetric 集計が働くため、ファンアウトも避けられます。wikipedia テーブルに関しては、永続的な派生テーブル（PDT）を使って BigQuery のスキャンサイズを抑えるのも良さそうです。、、、( ﾟдﾟ)ハッ！ついマジレスをしてしまいました。💦今回は dimension が null の measure を（0 ではなく）ø にする少しマニアックな記事を書く予定でしたが、先日の Looker User Meetup Online #7 で、LookML のディレクトリ構造を知りたいというチャットをお見かけしたので、今回はその話を書くことにしました。今回のプロジェクトの規模感デフォルトのディレクトリ構造？特別なファイル形式を知る最近使っているディレクトリ構造bigquery/model1.model.lkmlexplores/views/tests/manifest.lkmlまとめ2021-12-29 追記今回のプロジェクトの規模感プロジェクトの規模感によってディレクトリ構造は変わると思うので、先に書いておきます。Looker インスタンスに 1 つだけ LookML プロジェクトが存在するBigQuery Dataset 76 個.lkml ファイル 277 個.model.lkml ファイル 1 個.explore.lkml ファイル 56 個.view.lkml ファイル 139 個.test.lkml ファイル 78 個LookML 開発者 1 名デフォルトのディレクトリ構造？この記事を書くまで誤解をしていたのですが、デフォルトのディレクトリ構造というものはなかったのですね。この記事を書くために改めて Blank Project を作ったら、ファイルもディレクトリも何もないプロジェクトが作られました。モデルファイルを作るとこのようなコードが展開されるので、.view.lkml に関しては /views/ 以下に作る方が多いと思います。私もそうでした。include: "/views/*.view.lkml"                # include all views in the views/ folder in this project# include: "/**/*.view.lkml"                 # include all views in this project# include: "my_dashboard.dashboard.lookml"   # include a lookml dashboard called my_dashboard例えばこのようになります。feedmatic.model.lkmlviews├── all_media.view.lkml└── ga.view.lkml開発初期は feedmatic.model.lkml に view 以外の、explore や datagroup などをズラズラと書いていました。特別なファイル形式を知るご存知の通り、LookML のファイル形式は .lkml です。LookML 開発が続くと .model.lkml や .view.lkml などが増えていきますが、この中で唯一意味を持つのが .model.lkml です1。その他のファイル形式は整理のために自由に作ることが出来ます。例えば feedmatic.model.lkml を作ると、feedmatic というモデルが定義されます。https://{{your looker domain}}/projects で確認できます。all_media.view.lkml を作っても、何かが作られるわけではありません。以上の知識を持った上で、公式ドキュメントを読むと理解が深まるかもしれません。最近使っているディレクトリ構造こんな感じです。それぞれ解説していきます。bigquery├── spreadsheet1│   ├── define.json│   └── schema.json└── spreadsheet2    ├── define.json    └── schema.jsonmodel1.model.lkmlexplores├── corp│   ├── base.explore.lkml│   ├── name1.explore.lkml│   └── name2.explore.lkml├── explore1.explore.lkml└── explore2.explore.lkmlviews├── corp│   ├── base.view.lkml│   ├── name1.view.lkml│   └── name2.view.lkml├── view1.view.lkml└── view2.view.lkmltests└── model1    ├── corp    │   ├── name1.test.lkml    │   └── name2.test.lkml    ├── explore1.test.lkml    └── explore2.test.lkmlmanifest.lkmlbigquery/いきなり LookML 関係ありません。💦BigQuery はデータソースに Google スプレッドシートを指定でき、そのスキーマ定義はコード化することが出来ます。コード化することで変更履歴を Git で管理できますし、BigQuery CLI を使って簡単に Dataset や Table を作ったり、削除したりが出来ます。$ bq mk spreadsheet1$ bq mk --external_table_definition=./define.json spreadsheet1.gsheet$ bq rm -r spreadsheet1破壊的な変更をする時は、バージョン名を付けた Dataset を新規作成し、LookML から参照先を変えます。こうすることで、本番環境に影響を与えずに開発することが出来ます。$ bq mk spreadsheet1_v2$ bq mk --external_table_definition=./define.json spreadsheet1_v2.gsheetスキーマ定義は公式ドキュメントをご覧下さい。需要があればそんな記事を書きます。他の Dataset は ETL ツール2が作るためコード化はしていません。model1.model.lkml中心となるこのファイルは軽いです。本当にこの程度しか書いていません。connection: "docs_bigquery_db"include: "/explores/**/*.explore"include: "/tests/model1/**/*.test"named_value_format: jpy_0 {  value_format: "\¥#,##0"}named_value_format: jpy_1 {  value_format: "\¥#,##0.0"}# for testaccess_grant: can_view_explores_for_tests {  user_attribute: view_explores_for_tests  allowed_values: ["yes"]}必要な定義は connection と include だけです。include 対象を全ての .explore.lkml と、このモデルに関連するテスト（tests/feedmatic/ 以下全ての .test.lkml）だけにしていることがポイントです。つまり .model.lkml は .explore.lkml と自分の .test.lkml しか知りません。あとは蛇足で、named_value_format と、前回紹介したテストに必要な access_grant だけです。explores/1 つの explore を 1 つのファイルに定義しています。explores/explore1.explore.lkml はこのように書いています。.explore.lkml は .view.lkml しか知りません。include: "/views/**/*.view"explore: explore1 {  # ...}紆余曲折あり、explores/corp/name1.explore.lkml のような取引先ごとの explore もあります。基本となる explores/corp/base.explore.lkml はこのような定義です。ファイル名と explore 名を変えていることがポイントです。Ruby の慣習を参考にしました。explore: corp_base {  extension: required  # ...}corp_base explore を継承する、各取引先の explore はこのような定義です。include: "./base.explore"include: "/views/**/*.view"explore: corp_name1 {  extends: [corp_base]  # ...}views/view も explore と同様に、1 view 1 ファイルに定義しています。views/view1.view.lkml です。.view.lkml は .model.lkml, .explore.lkml, .test.lkml の誰も知りません。view: view1 {  # ...}取引先ごとの view も同じです。views/corp/base.view.lkml はこんな感じで、view: corp_base {  extension: required  # ...}継承先の views/corp/name1.view.lkml はこんな感じです。include: "./base.view"view: corp_name1 {  extends: [corp_base]  # ...}tests/テストはかなり書いており、2021-12-13 現在、184 もあります。ほぼ explore 単位でファイル分割しています。分割することで、ファイル単位のテストが可能になっています。こちらのベストプラクティスに従っています。テスト対象はこんな感じです。(1) LookML で特別な実装をしていて、壊れても気づくのが難しそうな実装(2) primary_key が重複していないか？ null になっていないか？を全ての view に対して(2) は前回詳しく書きました。実行に時間がかかることが悩みで以前こんな Topic を作りましたが、反応ゼロでした。みなさん課題ではないのかしら？💦primary_key は壊れた時に気づくのが難しく、LookML 開発者が私だけということもあるため、機械的に全ての primary_key をテスト出来るようにしています。ただ、全テストは結構時間がかかるので、日に 1 回くらいの頻度で手動実行しています。CI したい...。manifest.lkmlディレクトリ構造とは関係ありませんが、manifest.lkml についても触れておきましょう。bigquery/ の項で書いたとおり、テーブル定義に破壊的な変更を加える時は dataset_v2 のように Dataset 名にゆるふわバージョンを付けています。つまり割とカジュアルに Dataset 名が変わります。そのため、このように manifest.lkml で全ての Dataset 名を定義しています3。Dataset 名は複数箇所で使われ得るためです。constant: table_name1  { value: "`table1_v2.gsheet`" }constant: table_name2  { value: "`table2.view`" }利用例です。sql_table_name: @{table_name1} ;;まとめ現在 LookML 開発で使っているディレクトリ構造を紹介しました。中規模くらいまでの LookML プロジェクトには使える実感があります。ただ、最近はファイル数が多くなってきて、.view.lkml を追加した時に変更する .explore.lkml と .test.lkml の距離が遠く、実装しづらい課題があります。Refinements を使えば解決できるのだろうか、もっと再利用性のあるコードにしたいなど、悩みは尽きないです。こちらの記事は読んで手も動かしたのですが、巨大なファイルを分割する、Blocks のようなライブラリをカスタマイズする（？）、以外の使い方を見いだせていません。皆さんのディレクトリ構造も是非教えて下さい！2021-12-29 追記What is the looker recommended folder structure for LookML development ? | Looker CommunityLooker Community にもお悩みの方がいらっしゃいました。返信している Dawid さんはよくお見かけする方で、かなりの熟練者だと思います。そんな彼も、今回私が書いた記事のような物理的な構造が良いのか、論理的な構造が良いのか、未だに試行錯誤しているようです。始めは物理的なディレクトリ構造から始めて、徐々に変化しながら論理的な構造に近づくのかもしれません。その頃にはステージに応じたベストプラクティスが出ていると良いですね。manifest.lkml や .strings.json などもありますが、一旦考えなくて良いと思います。↩Funnel.io を使っています。↩↩

LookML 開発で使っているディレクトリ構造を紹介する

<p>こんにちは、<a href="http://blog.hatena.ne.jp/daido1976/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/daido1976/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:daido1976</a> です。</p>

<p>先日 GitHub Packages を使ってプライベート gem を社内限定で公開したので、その方法をご紹介します。</p>

<ul class="table-of-contents">
    <li><a href="#GitHub-Packages-とは">GitHub Packages とは</a></li>
    <li><a href="#既存のプライベート-gem-と-GitHub-Packages-との違い">既存のプライベート gem と GitHub Packages との違い</a></li>
    <li><a href="#GitHub-Packages-を使ってプライベート-gem-を社内限定で公開する">GitHub Packages を使ってプライベート gem を社内限定で公開する</a><ul>
            <li><a href="#gem-をリリースPublishする方法">gem をリリース（Publish）する方法</a><ul>
                    <li><a href="#ローカルからリリースする">ローカルからリリースする</a></li>
                    <li><a href="#CI-からリリースする">CI からリリースする</a></li>
                </ul>
            </li>
            <li><a href="#各環境へのインストール方法">各環境へのインストール方法</a><ul>
                    <li><a href="#ローカルや本番環境でのインストール">ローカルや本番環境でのインストール</a></li>
                    <li><a href="#Dependabot-でのインストール">Dependabot でのインストール</a></li>
                </ul>
            </li>
        </ul>
    </li>
    <li><a href="#関連記事">関連記事</a></li>
</ul>

<h2 id="GitHub-Packages-とは">GitHub Packages とは</h2>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.co.jp%2Ffeatures%2Fpackages" title="Packages" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.co.jp/features/packages">github.co.jp</a></cite></p>

<p>GitHub Packages はライブラリ（パッケージ）のホスティングサービスです。</p>

<p>Ruby の場合 <code>https://rubygems.org</code> の代わりに <code>https://rubygems.pkg.github.com</code> に公開するイメージで、認証には GitHub の personal access token などを使います。</p>

<h2 id="既存のプライベート-gem-と-GitHub-Packages-との違い">既存のプライベート gem と GitHub Packages との違い</h2>

<p>既存のプライベート gem は主に git のタグやブランチを指定する方法が用いられますが、以下のようにいくつかの問題があります。</p>

<pre class="code lang-ruby" data-lang="ruby" data-unlink><span class="synComment"># main ブランチの先端を使うのは再現性がない（ブランチ指定した場合も同じ）</span>
gem <span class="synSpecial">'</span><span class="synConstant">my_rubygem</span><span class="synSpecial">'</span>, <span class="synConstant">github</span>: <span class="synSpecial">'</span><span class="synConstant">my_name/my_rubygem</span><span class="synSpecial">'</span>
<span class="synComment"># タグを指定しても書き換えられる可能性がある</span>
gem <span class="synSpecial">'</span><span class="synConstant">my_rubygem</span><span class="synSpecial">'</span>, <span class="synConstant">github</span>: <span class="synSpecial">'</span><span class="synConstant">my_name/my_rubygem</span><span class="synSpecial">'</span>, <span class="synConstant">tag</span>: <span class="synSpecial">'</span><span class="synConstant">v1.0.0</span><span class="synSpecial">'</span>
<span class="synComment"># コミットの参照を指定するのはシンプルに見づらい</span>
gem <span class="synSpecial">'</span><span class="synConstant">my_rubygem</span><span class="synSpecial">'</span>, <span class="synConstant">github</span>: <span class="synSpecial">'</span><span class="synConstant">my_name/my_rubygem</span><span class="synSpecial">'</span>, <span class="synConstant">ref</span>: <span class="synSpecial">'</span><span class="synConstant">4aded</span><span class="synSpecial">'</span>
</pre>


<p>GitHub Packages は <code>rubygems.org</code> と同じように、バージョン指定が明確かつ一度リリースしたバージョンは変更できないので安全です。</p>

<h2 id="GitHub-Packages-を使ってプライベート-gem-を社内限定で公開する">GitHub Packages を使ってプライベート gem を社内限定で公開する</h2>

<p>ここからは実際に GitHub Packages を使ってプライベート gem を社内限定で公開する方法（主にリリースとインストールの仕方）を説明していきます。</p>

<p>今回は Organization は <code>feedforce</code>、gem の名前は <code>socialplus-rails</code> という想定です。</p>

<p>日本語版のドキュメントは文章やサンプルコードが古いケースがあるので、以下の英語版ドキュメントを参照した方が良いです。</p>

<p><a href="https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry">Working with the RubyGems registry - GitHub Docs</a></p>

<p>認証に使う personal access token の権限については以下のドキュメントが詳しいです。</p>

<p><a href="https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages">About permissions for GitHub Packages - GitHub Docs</a></p>

<h3 id="gem-をリリースPublishする方法">gem をリリース（Publish）する方法</h3>

<p>まずは作成した gem をリリースする方法について説明します。</p>

<h4 id="ローカルからリリースする">ローカルからリリースする</h4>

<p>まとめると以下のような手順になります。</p>

<ol>
<li><code>〜/.gem/credentials</code> に GitHub の personal access token を追加

<ul>
<li>権限は <code>repo</code> と <code>write:packages</code> が必要</li>
</ul>
</li>
<li><code>$ gem build socialplus-rails.gemspec</code> で gem をビルド

<ul>
<li><code>SocialplusRails::VERSION</code> は <code>0.1.0</code> を想定</li>
</ul>
</li>
<li><code>$ gem push --key github --host https://rubygems.pkg.github.com/feedforce socialplus-rails-0.1.0.gem</code> で push する

<ul>
<li>この時に personal access token の権限が足りないとエラーになる</li>
</ul>
</li>
</ol>


<p>Push が成功すると <a href="https://github.com/orgs/feedforce/packages">https://github.com/orgs/feedforce/packages</a> のような Packages のページに反映されます 👏</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/d/daido1976/20211104/20211104160709.png" alt="f:id:daido1976:20211104160709p:plain" width="1200" height="492" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h4 id="CI-からリリースする">CI からリリースする</h4>

<p>gem のソースコードを更新した際に毎回上記のようにローカルからリリースしても良いのですが、できれば CI からリリースできるように仕組み化したいものです。</p>

<p>CircleCI の場合、以下のような <code>release</code> コマンドを定義して、リリース用のブランチがマージされた時に実行されるようにすれば OK です。</p>

<pre class="code lang-yaml" data-lang="yaml" data-unlink><span class="synComment"># .circleci/config.yml</span>

<span class="synIdentifier">version</span><span class="synSpecial">:</span> <span class="synConstant">2.1</span>
<span class="synComment"># ...</span>
<span class="synIdentifier">commands</span><span class="synSpecial">:</span>
  <span class="synIdentifier">release</span><span class="synSpecial">:</span>
    <span class="synIdentifier">description</span><span class="synSpecial">:</span> Release to GitHub Packages
    <span class="synIdentifier">steps</span><span class="synSpecial">:</span>
      <span class="synStatement">- </span><span class="synIdentifier">run</span><span class="synSpecial">:</span>
          <span class="synIdentifier">name</span><span class="synSpecial">:</span> Create GitHub Packages Credentials
          <span class="synIdentifier">command</span><span class="synSpecial">:</span> |
            mkdir ~/.gem || <span class="synConstant">true</span>
            echo -e <span class="synConstant">&quot;---</span><span class="synSpecial">\n</span><span class="synConstant">:github: Bearer ${GITHUB_ACCESS_TOKEN}&quot;</span> &gt; ~/.gem/credentials
            chmod <span class="synConstant">0600</span> ~/.gem/credentials
      <span class="synStatement">- </span><span class="synIdentifier">run</span><span class="synSpecial">:</span>
          <span class="synIdentifier">name</span><span class="synSpecial">:</span> Release Gem
          <span class="synIdentifier">command</span><span class="synSpecial">:</span> |
            gem build socialplus-rails.gemspec
            release_version=$(find . -name <span class="synConstant">&quot;socialplus-rails-*.gem&quot;</span> | sed -E <span class="synConstant">'s/\.\/socialplus-rails-(.*).gem/\1/'</span>)
            gem push --key github --host https://rubygems.pkg.github.com/feedforce <span class="synConstant">&quot;socialplus-rails-${release_version}.gem&quot;</span>
</pre>


<h3 id="各環境へのインストール方法">各環境へのインストール方法</h3>

<p>ここからはリリースした gem を各環境へインストールする方法を説明します。</p>

<p>Gemfile への記述は以下のようにします。<a href="#f-ff64d70e" name="fn-ff64d70e" title="See. https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry#installing-a-package">*1</a></p>

<pre class="code lang-ruby" data-lang="ruby" data-unlink><span class="synComment"># Gemfile</span>
source <span class="synSpecial">'</span><span class="synConstant">https://rubygems.pkg.github.com/feedforce</span><span class="synSpecial">'</span> <span class="synStatement">do</span>
  gem <span class="synSpecial">'</span><span class="synConstant">socialplus-rails</span><span class="synSpecial">'</span>, <span class="synSpecial">'</span><span class="synConstant">0.1.0</span><span class="synSpecial">'</span>
<span class="synStatement">end</span>
</pre>


<h4 id="ローカルや本番環境でのインストール">ローカルや本番環境でのインストール</h4>

<p>以下のように <code>bundle config</code> コマンドで認証情報をセットしてから <code>bundle install</code> を行います。<a href="#f-54facd0e" name="fn-54facd0e" title="環境変数を利用して認証情報をセットすることもできるようです">*2</a></p>

<pre class="code lang-sh" data-lang="sh" data-unlink><span class="synComment"># `USERNAME:TOKEN` は `{GitHubのユーザ名}:{Personal access token}` という形です（例: `daido1976:7axxx`）</span>
$ bundle config https://rubygems.pkg.github.com/feedforce USERNAME:TOKEN
$ bundle install
</pre>


<p>※ インストール時の認証に利用する personal access token には <code>read:packages</code> の権限のみあれば OK です</p>

<h4 id="Dependabot-でのインストール">Dependabot でのインストール</h4>

<p>GitHub Packages のプライベート gem をDependabot の更新対象にしたい場合は追加の設定が必要です。</p>

<p>以下のように設定ファイルで GitHub Packages の認証情報を渡す準備をします。<a href="#f-52f8882d" name="fn-52f8882d" title="See. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#rubygems-server">*3</a></p>

<pre class="code lang-yaml" data-lang="yaml" data-unlink><span class="synComment"># .github/dependabot.yml</span>

<span class="synIdentifier">version</span><span class="synSpecial">:</span> <span class="synConstant">2</span>
<span class="synIdentifier">registries</span><span class="synSpecial">:</span>
  <span class="synIdentifier">rubygems-pkg-github</span><span class="synSpecial">:</span>
    <span class="synIdentifier">type</span><span class="synSpecial">:</span> rubygems-server
    <span class="synIdentifier">url</span><span class="synSpecial">:</span> https://rubygems.pkg.github.com
   <span class="synComment"> # BUNDLE_GITHUB_TOKEN の値は `USERNAME:TOKEN` という形式です</span>
    <span class="synIdentifier">token</span><span class="synSpecial">:</span> <span class="synConstant">&quot;${{secrets.BUNDLE_GITHUB_TOKEN}}&quot;</span>
</pre>


<p>以下ドキュメントを参考に GitHub Packages の認証情報（今回の例なら <code>BUNDLE_GITHUB_TOKEN</code>）を Dependabot 用の Secret として登録すれば完了です。<a href="#f-e337a98d" name="fn-e337a98d" title="Secret はリポジトリ単位とオーガニゼーション単位のどちらでも設定できます">*4</a></p>

<p><a href="https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/managing-encrypted-secrets-for-dependabot">Managing encrypted secrets for Dependabot - GitHub Docs</a></p>

<h2 id="関連記事">関連記事</h2>

<ul>
<li><a href="https://tech.pepabo.com/2021/09/10/in-house-rubygems-registry-with-ghes-github-packages/">GitHub Enterprise Server&#x306E;GitHub Packages&#x3067;&#x793E;&#x5185;&#x7528;gem&#x3092;&#x30DB;&#x30B9;&#x30C8;&#x3059;&#x308B; - &#x30DA;&#x30D1;&#x30DC;&#x30C6;&#x30C3;&#x30AF;&#x30D6;&#x30ED;&#x30B0;</a></li>
<li><a href="https://tech.actindi.net/2020/06/12/180000">GitHub Actions&#x3092;&#x5229;&#x7528;&#x3057;&#x3066;gem&#x3092;GitHub Packages&#x306B;&#x516C;&#x958B;&#x3059;&#x308B; - &#x30A2;&#x30AF;&#x30C8;&#x30A4;&#x30F3;&#x30C7;&#x30A3;&#x958B;&#x767A;&#x8005;&#x30D6;&#x30ED;&#x30B0;</a></li>
<li><a href="https://chocoby.com/blog/2021/09/21/dependabot-github-packages-gem">Dependabot &#x3067; GitHub Packages &#x306B;&#x516C;&#x958B;&#x3057;&#x305F; Gem &#x306E;&#x30A2;&#x30C3;&#x30D7;&#x30C7;&#x30FC;&#x30C8;&#x3092;&#x30C1;&#x30A7;&#x30C3;&#x30AF;&#x3059;&#x308B; - &#x6687;&#x4EBA;&#x3058;&#x3083;&#x306A;&#x3044;</a></li>
</ul>

<div class="footnote">
<p class="footnote"><a href="#fn-ff64d70e" name="f-ff64d70e" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">See. <a href="https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry#installing-a-package">https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry#installing-a-package</a></span></p>
<p class="footnote"><a href="#fn-54facd0e" name="f-54facd0e" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://tech.pepabo.com/2021/09/10/in-house-rubygems-registry-with-ghes-github-packages/#%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%E3%81%8B%E3%82%89%E3%81%AEgem%E3%81%AE%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89">環境変数を利用して認証情報をセットすることもできるようです</a></span></p>
<p class="footnote"><a href="#fn-52f8882d" name="f-52f8882d" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text">See. <a href="https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#rubygems-server">https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#rubygems-server</a></span></p>
<p class="footnote"><a href="#fn-e337a98d" name="f-e337a98d" class="footnote-number">*4</a><span class="footnote-delimiter">:</span><span class="footnote-text">Secret はリポジトリ単位とオーガニゼーション単位のどちらでも設定できます</span></p>
</div>

こんにちは、id:daido1976 です。先日 GitHub Packages を使ってプライベート gem を社内限定で公開したので、その方法をご紹介します。GitHub Packages とは既存のプライベート gem と GitHub Packages との違いGitHub Packages を使ってプライベート gem を社内限定で公開するgem をリリース（Publish）する方法ローカルからリリースするCI からリリースする各環境へのインストール方法ローカルや本番環境でのインストールDependabot でのインストール関連記事GitHub Packages とはgithub.co.jpGitHub Packages はライブラリ（パッケージ）のホスティングサービスです。Ruby の場合 https://rubygems.org の代わりに https://rubygems.pkg.github.com に公開するイメージで、認証には GitHub の personal access token などを使います。既存のプライベート gem と GitHub Packages との違い既存のプライベート gem は主に git のタグやブランチを指定する方法が用いられますが、以下のようにいくつかの問題があります。# main ブランチの先端を使うのは再現性がない（ブランチ指定した場合も同じ）gem 'my_rubygem', github: 'my_name/my_rubygem'# タグを指定しても書き換えられる可能性があるgem 'my_rubygem', github: 'my_name/my_rubygem', tag: 'v1.0.0'# コミットの参照を指定するのはシンプルに見づらいgem 'my_rubygem', github: 'my_name/my_rubygem', ref: '4aded'GitHub Packages は rubygems.org と同じように、バージョン指定が明確かつ一度リリースしたバージョンは変更できないので安全です。GitHub Packages を使ってプライベート gem を社内限定で公開するここからは実際に GitHub Packages を使ってプライベート gem を社内限定で公開する方法（主にリリースとインストールの仕方）を説明していきます。今回は Organization は feedforce、gem の名前は socialplus-rails という想定です。日本語版のドキュメントは文章やサンプルコードが古いケースがあるので、以下の英語版ドキュメントを参照した方が良いです。Working with the RubyGems registry - GitHub Docs認証に使う personal access token の権限については以下のドキュメントが詳しいです。About permissions for GitHub Packages - GitHub Docsgem をリリース（Publish）する方法まずは作成した gem をリリースする方法について説明します。ローカルからリリースするまとめると以下のような手順になります。〜/.gem/credentials に GitHub の personal access token を追加権限は repo と write:packages が必要$ gem build socialplus-rails.gemspec で gem をビルドSocialplusRails::VERSION は 0.1.0 を想定$ gem push --key github --host https://rubygems.pkg.github.com/feedforce socialplus-rails-0.1.0.gem で push するこの時に personal access token の権限が足りないとエラーになるPush が成功すると https://github.com/orgs/feedforce/packages のような Packages のページに反映されます 👏CI からリリースするgem のソースコードを更新した際に毎回上記のようにローカルからリリースしても良いのですが、できれば CI からリリースできるように仕組み化したいものです。CircleCI の場合、以下のような release コマンドを定義して、リリース用のブランチがマージされた時に実行されるようにすれば OK です。# .circleci/config.ymlversion: 2.1# ...commands:  release:    description: Release to GitHub Packages    steps:      - run:          name: Create GitHub Packages Credentials          command: |            mkdir ~/.gem || true            echo -e "---\n:github: Bearer ${GITHUB_ACCESS_TOKEN}" > ~/.gem/credentials            chmod 0600 ~/.gem/credentials      - run:          name: Release Gem          command: |            gem build socialplus-rails.gemspec            release_version=$(find . -name "socialplus-rails-*.gem" | sed -E 's/\.\/socialplus-rails-(.*).gem/\1/')            gem push --key github --host https://rubygems.pkg.github.com/feedforce "socialplus-rails-${release_version}.gem"各環境へのインストール方法ここからはリリースした gem を各環境へインストールする方法を説明します。Gemfile への記述は以下のようにします。*1# Gemfilesource 'https://rubygems.pkg.github.com/feedforce' do  gem 'socialplus-rails', '0.1.0'endローカルや本番環境でのインストール以下のように bundle config コマンドで認証情報をセットしてから bundle install を行います。*2# `USERNAME:TOKEN` は `{GitHubのユーザ名}:{Personal access token}` という形です（例: `daido1976:7axxx`）$ bundle config https://rubygems.pkg.github.com/feedforce USERNAME:TOKEN$ bundle install※ インストール時の認証に利用する personal access token には read:packages の権限のみあれば OK ですDependabot でのインストールGitHub Packages のプライベート gem をDependabot の更新対象にしたい場合は追加の設定が必要です。以下のように設定ファイルで GitHub Packages の認証情報を渡す準備をします。*3# .github/dependabot.ymlversion: 2registries:  rubygems-pkg-github:    type: rubygems-server    url: https://rubygems.pkg.github.com    # BUNDLE_GITHUB_TOKEN の値は `USERNAME:TOKEN` という形式です    token: "${{secrets.BUNDLE_GITHUB_TOKEN}}"以下ドキュメントを参考に GitHub Packages の認証情報（今回の例なら BUNDLE_GITHUB_TOKEN）を Dependabot 用の Secret として登録すれば完了です。*4Managing encrypted secrets for Dependabot - GitHub Docs関連記事GitHub Enterprise ServerのGitHub Packagesで社内用gemをホストする - ペパボテックブログGitHub Actionsを利用してgemをGitHub Packagesに公開する - アクトインディ開発者ブログDependabot で GitHub Packages に公開した Gem のアップデートをチェックする - 暇人じゃない*1:See. https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-rubygems-registry#installing-a-package*2:環境変数を利用して認証情報をセットすることもできるようです*3:See. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#rubygems-server*4:Secret はリポジトリ単位とオーガニゼーション単位のどちらでも設定できます

GitHub Packages を使ってプライベート gem を社内限定で公開した

ソーシャルPLUS の開発チームでインフラエンジニア をやっています id:mayuki123 です。今月からフィードフォースから分社化をした株式会社ソーシャルPLUS の所属となりましたが、仕事内容は変わらずにサービスのインフラ改善を進めていく事になるかと思います。2019年11月に技術スタックを整理してみたという記事から2年弱経過していますが、ソーシャルPLUSのインフラ環境は、一部アプリケーションについてはコンテナ環境を Amazon EKS にホスティングして本番運用するようになりました。あと数ヶ月ほどで全ての環境がEC2からコンテナに置き換えられると良いなと思っています(願望)。developer.feedforce.jpそして、既に利用されている機能の一部を Amazon EKS に移行して、しばらく経過した時にアプリケーションでネットワークエラーが稀に発生していました。原因調査をした結果が CoreDNS の負荷によるものと発覚するまでのトラブルシュートの流れについて、記事として書き残しておきます。発生していた事象Datadog を活用した原因調査アプリケーションの負荷状況EKS 上のコンテナの調査EKS のCoreDNS の調査CoreDNS のデバッグログの有効化Kubernetes の名前解決についてCoreDNS の負荷軽減ドメインの末尾にドット (.) を追加する/etc/resolv.conf で ndots:1 の設定をするその他の CoreDNS の負荷軽減の方法最終的な結果おわりにおまけ発生していた事象ソーシャルPLUSでは、バックエンドのアプリケーションでエラーが発生した時に、Bugsnag を利用して Slack 通知するようにしています。ある時にMysql2::Error::ConnectionError が発生しました。単発のネットワークエラーの場合はアプリケーションがリトライする事でサービス影響がない事も多く、一時的な問題と思って静観する事があるかと思います。しかし、また数日後に同じ事象が発生しました。ハインリッヒの1：29：300の法則のように、ちょっとした異常を見落としていると重大なサービス障害となってしまう可能性があるので、原因調査を始めます。Datadog を活用した原因調査ソーシャルPLUSでは、モニタリングサービスの Datadog を利用しているのでメトリクスやログの調査を出来るようになっています。どこが原因かを探り始めました。アプリケーションの負荷状況まずはアプリケーションで利用するサーバの負荷状況を確認する所から始めました。Mysql2::Error::ConnectionError が発生した時刻は EKS の Node の CPU 使用率が 70% ほどで、アプリケーションで負荷のかかる処理の最中でした。また、データベースの負荷は少し前に負荷対策の改善をした事もあって、今回の事件の犯人ではなさそうです。他にもEC2 と DB 間でネットワークのボトルネックがないかなどの確認はしましたが、CPU 使用率が高い以外の問題は特に見つかりませんでした。完全犯罪でしょうか。EKS 上のコンテナの調査サーバ単体の問題ではないとすると、Amazon EKS で何か起きている事を疑うことにしました。EKSで動かしているコンテナのログは Datadog Logs に送っているので、エラーが発生していたアプリケーション以外のログ を確認していると、MySQL の ConnectionError が発生した時間帯に下記の Warning のメッセージが出ている事に気づきました。このログは Amazon Kinesis Data Firehose にログを送る Fluent Bit のコンテナで発生しており、エラーが発生してたアプリケーションとは異なるノードに存在してました。[yyyy/mm/dd hh:mm:ss] [ warn] [net] getaddrinfo(host='kinesis.ap-northeast-1.amazonaws.com'): Name or service not known同時刻に特定のアプリケーション以外のコンテナも影響を受けていることから、EKS の中で問題がありそうです。元々、EKSに関する技術ブログは目を通すようにしていた事もあり、Kubernetes の DNS の名前解決で問題が発生する場合があるというのは知っていたので、CoreDNSに焦点を当てて調べることにしました。アウトプットをしてくれる人たちには、いつも感謝をしています。Production Ready EKS CoreDNS Configuration | by Serkan Capkan | Cloutive Technology Solutions - Tech Blog | MediumEKSでDNSを安定させるために対応したこと - Chatwork Creator's Noteスマホゲームの API サーバにおける EKS の運用事例 | エンジニアブログ | GREE EngineeringEKS のCoreDNS の調査Datadog Agent で Kurbernetes の各種メトリクスを収集していて、EKS の CoreDNS の状況も Datadog の Metric Explorer で確認する事が出来るようになっています。Datadog で取得可能な CoreDNS のメトリクスcoredns.request_count を確認すると特定の時間帯で CoreDNS へのリクエストが多い状態で、このタイミングでの CoreDNS Pod の CPU 負荷は10％前後でしたが、それ以外に不審なメトリクスは存在しませんでした。まだ事象の原因との確信は持てないですが、負荷がそれなりにかかっていることは確かなのでリクエストが多くなる理由を調べます。CoreDNS のデバッグログの有効化まずは CoreDNS のデバッグログを確認したいとなるかと思いますが、EKS の CoreDNS はデフォルトだとデバッグログの出力がオフの状態のため、どのようなリクエストが到達しているのかは確認する事ができません。CoreDNS のログを有効化する方法は AWS のナレッジベースにある記事に方法が記載されています。Amazon EKS での DNS 障害のトラブルシューティングこの記事によると、Namespace(kube-system) に Configmap (coredns) があるので、Corefile 設定に log を追加するとデバッグログ が出力されるようになります。# kubectl -n kube-system edit configmap corednskind: ConfigMapapiVersion: v1data:  Corefile: |    .:53 {        log    # Enabling CoreDNS Logging        errors        health        kubernetes cluster.local in-addr.arpa ip6.arpa {          pods insecure          upstream          fallthrough in-addr.arpa ip6.arpa        }        ...上記の設定をすると CoreDNS のPod の標準出力にデバッグログ が出力されるようになります。私の触っていた EKS の環境の場合は、数分ほどで CoreDNS の Pod で reload が発生して元の設定（デバッグログ がオフ）に戻るようになってました。Kubernetes の名前解決について次にKubernetes 上のコンテナはどのように名前解決するのかを知っておく必要があります。Kurbernetes の Pod の DNS リゾルバー(/etc/resolv.conf) のデフォルト設定は下記のようになっています。% kubectl exec fluent-bit-46zvl -- cat /etc/resolv.confnameserver 172.20.0.10search logging.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5この状態で Fluent Bit のコンテナから Amazon Kinesis の API エンドポイントに疎通する場合は、CoreDNS に8回のリクエストが発生します。これは、IPv4 , IPv6 の2種類の名前解決を search の数だけ名前解決を試みた後で EKS 外に名前解決をする設定になっているからです。この設定になっているおかげで Kubernetes の Service を使った名前解決が出来るようになっています。また、options ndots:5 の設定は . の数が 5個以上の時は最初から外部に名前解決するようになります。そのため、Amazon Aurora や ElastiCache などのデータベースへの クラスターエンドポイントは . の数が五個以上あるので、CoreDNSへのリクエスト回数は少なくて済みます。ここを意識しなくてよいのはありがたいですね。ソーシャルPLUSというプロダクトの特性上、EKS 内のアプリケーションから外部サービスの API を実行する機会が多々あります。特定のタイミングで外部のサービスに大量のAPIリクエストを実行した際に、CoreDNS へのリクエストが増大してしまい不安定になってしまったのではと考えられます。CoreDNS の負荷軽減Kurbernetes 上のコンテナの名前解決を知ると、外部サービスのAPI を実行する際には CoreDNS へのリクエストが多くなる事が分かりました。ここで、CoreDNS へのリクエスト数を減らす方法は下記の二つがあります。これも AWS のナレッジベースに方法が記載されているので、詳細は下記の記事を読む方が良いと思います。Amazon EKS での DNS 障害のトラブルシューティングドメインの末尾にドット (.) を追加する接続先のドメインの最後に . をつけると、EKS の内部で名前解決を複数回しないようになり、CoreDNS へのリクエストの総数が減ります。一例をあげると、example.com ではなく、 example.com. とする事で最初から EKS の外部に名前解決をしてくれるようになります。ドメインが SDK の内部で定義されているような場合など、変更出来ない場合はこの方法は利用出来ないかと思います。/etc/resolv.conf で ndots:1 の設定をする/etc/resolv.conf に options ndots:5 とデフォルトで設定されている数値を 1 にする事で、ドメインに . が含まれている場合は常に EKS の外部に名前解決するようになります。Kubernetes の Manifest に spec.dnsConfig パラメータを設定する事で Pod 単位で変更が出来ます。ただし、この設定をすると EKS 内部で名前解決をしなくなってしまいますが、<name>.<namespace>.svc.cluster.local. のように最後に . をつけると名前解決出来ました。Kurbernetes の Service の数が多いとこの方法を周知させるのも大変だと思います。apiVersion: apps/v1kind: Deploymentmetadata:  name: hogespec:  template:    spec:      dnsConfig:        options:          - name: ndots            value: "1"その他の CoreDNS の負荷軽減の方法上記の二つの方法は CoreDNS へのリクエスト数を減らすことで、負荷を軽減するようなアプローチでした。CoreDNS の Pod 数はデフォルトで 2個となりますが、CoreDNS のPod をオートスケールする手段もあります。Autoscale the DNS Service in a Clusterまた、Daemonset で DNS キャッシュをノード単位で配置するという方法もあります。KubernetesクラスターでNodeLocal DNSキャッシュを使用するこの辺りは他の方が書いた技術ブログも多くあるかと思うので、この記事では特に説明はしないです。最終的な結果ソーシャルPLUSでは最終的に根本原因の CoreDNS へのリクエスト数を減らすために /etc/resolv.conf で ndots:1 の設定をするようにしました。この設定をアプリケーションの Pod に適応した所、CoreDNS へのリクエスト数は 25% ほどと目に見えて減少させる事が出来ました。キャプチャは載せてないですが、CoreDNS の Pod の CPU使用率も 以前の半分ほどになったので、負荷軽減の目的は達成しました。ここまで、確信を持てないまま CoreDNS の負荷軽減に取り組みましたが、元々のネットワークエラーであった Mysql2::Error::ConnectionError のエラーは再発しなくなりました。また、EKS 上の他のコンテナも Name or service not known のような名前解決が出来ないといったエラーも発生しなくなりました。CoreDNS の負荷を減らす事で悩まされていた問題の解消が出来たと思います。今回のように比較的早い段階で気づく事が出来たので、お客さんへのサービス影響のある問題に発展せずに済みました。今後、利用者数が増えてより負荷のかかる状況になってきた時には再発する可能性はありますが、早い段階で気付けるように日々確認するダッシュボードにメトリクスを追加するようにしています。その時がきた場合は CoreDNS の Pod 数の調整や DNS キャッシュの導入が必要になりそうです。おわりに最終的には Pod の DNS 設定を調整するだけでネットワークエラーは解決しました。この記事では、結果だけではなくて解決に至るまでの経緯をメインにまとめてみました。実施していて良かったと思うことを下記にまとめます。これらの事が出来ていなければ、今回のようなネットワークエラーはたまに発生する事象として、根本原因の追及は出来なかったと思うので、サービスのオブザーバビリティを整備する事や日々の情報収集は大事ですね。アプリケーションのエラーを Slack に通知していたKurbernetes のメトリクスを Datadog で確認できる状態だったコンテナのログを一元的に Datadog Logs  で閲覧できるようにしていた他の人の技術ブログから Kubernetes の CoreDNS が不安定になることを知っていたこの記事に間違っている内容や、もっと良い改善方法がある事をご存知の方がいましたら、優しく教えてください。おまけ現在、ソーシャルPLUS では作りたい機能が山ほどある状況でまだまだ成長するサービスになると思うので、成長を続けるサービスに携わりたいエンジニアやデザイナーのご応募をお待ちしております！サイトにはまだないですが、インフラエンジニアも近いうちに募集をする事にはなると思います。open.talentio.comopen.talentio.comopen.talentio.comフィードフォース の他のサービスもエンジニアを募集してますので、興味があればご応募お待ちしております！engineers.recruit.feedforce.jp

Amazon EKS で高負荷時に CoreDNS が原因で稀にネットワークエラーが発生していた時のトラブルシュート

<p>こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。
先週はまるっと夏休みにしてました。今日からまた <a href="https://ja.looker.com/">Looker</a> と戯れる日々が始まります。</p>

<p>丸１年 Looker と戯れてきて最近ようやく、<strong>Join 先の view でも</strong> primary_key が壊れてないことを保証するテストの書き方が分かったので、今回紹介します。</p>

<ul class="table-of-contents">
    <li><a href="#Looker-における-primary_key-の役割">Looker における primary_key の役割</a></li>
    <li><a href="#primary_key-の実装例">primary_key の実装例</a></li>
    <li><a href="#LookML-開発におけるテスト">LookML 開発におけるテスト</a></li>
    <li><a href="#Join-先の-view-は-primary_key-をテスト出来ないことがある">Join 先の view は primary_key をテスト出来ないことがある</a></li>
    <li><a href="#Join-先の-view-の-primary_key-をいい感じにテストする">Join 先の view の primary_key をいい感じにテストする</a></li>
    <li><a href="#まとめと所感">まとめと所感</a></li>
    <li><a href="#おまけ">おまけ</a></li>
</ul>

<h2 id="Looker-における-primary_key-の役割">Looker における primary_key の役割</h2>

<p>Looker には <a href="https://help.looker.com/hc/en-us/articles/360023722974">Symmetric Aggregates</a> という、合計を重複させない素晴らしい仕組みがあります。以前このブログでも紹介しました。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>その Symmetric Aggregates では <a href="https://docs.looker.com/reference/field-params/primary_key">primary_key</a> が重要な役割を果たします。適切に設定されていないと、以下のような問題が発生します。</p>

<ul>
<li>primary_key が重複すると fanout エラーが発生することがある</li>
<li>primary_key が null だと Measure が 0 になることがある</li>
</ul>


<p>このような問題は大概、ふわっと質問が来て発覚します。今のタスクを保留にして調査することは精神的になかなか辛いものがあり、それなりに時間も費やすことになるため、可能な限り事前に避けたいところです。</p>

<h2 id="primary_key-の実装例">primary_key の実装例</h2>

<p>私が所属する <a href="https://feedmatic.net/">Feedmatic</a> では、ウェブ広告や Google Analytics のデータを扱っています。正規化されたきれいなデータは少なく、Rails の id のようなユニークなカラムは存在しないことが多いです。</p>

<p>そのため、このようにいくつかの Dimension を組み合わせて primary_key を定義します。</p>

<pre class="code" data-lang="" data-unlink>dimension: id {
  primary_key: yes
  type: string
  sql: CONCAT(${dimension1}, ${dimension2}, IFNULL(${dimension3}, &#39;&#39;)) ;;
  hidden: yes
}</pre>


<p>※ <a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%8F%E3%82%A6%E3%82%B9">DWH</a> は BigQuery を使っています。</p>

<p>これで済めばよいのですが、上の例だとある日突然 dimension2 が null になり始めたり、全ての string 型の Dimension を使っても重複し始めることがあります。データの性格は理解していたつもりでしたが、実際どちらもありました。😭</p>

<h2 id="LookML-開発におけるテスト">LookML 開発におけるテスト</h2>

<p>以上の課題を解決するために、<a href="https://docs.looker.com/reference/model-params/test">test</a> パラメータが使えます。</p>

<p>例えばこのような <code>parent</code> explore があったとします。Join がないのでシンプルです。</p>

<pre class="code" data-lang="" data-unlink>explore: parent {
  ...
}

view: parent {
  dimension: id {
    primary_key: yes
    ...
  }

  measure: count {
    type: count
  }
}</pre>


<p>私はこのようなテストを書いて、全ての <code>parent.id</code> が null でないことと、重複しないことを保証させています。</p>

<pre class="code" data-lang="" data-unlink>test: parent_id_is_not_null {
  explore_source: parent {
    column: id {}
    sorts: [parent.id: asc]
    limit: 1
  }
  assert: id_is_not_null {
    expression: NOT is_null(${parent.id}) ;;
  }
}

test: parent_id_is_unique {
  explore_source: parent {
    column: id {}
    column: count {}
    sorts: [parent.count: desc]
    limit: 1
  }
  assert: id_is_unique {
    expression: ${parent.count} = 1 ;;
  }
}</pre>


<p>👉 ソート時に null が先頭と末尾のどちらに来るかは、DWH の実装によります。</p>

<h2 id="Join-先の-view-は-primary_key-をテスト出来ないことがある">Join 先の view は primary_key をテスト出来ないことがある</h2>

<p>さて、<code>child</code> view を Join する必要が出てきました。</p>

<pre class="code" data-lang="" data-unlink>explore: parent {
  join: child {
    type: left_outer
    relationship: one_to_many
    sql_on: ... ;;
  }
}

view: parent {
  dimension: id {
    primary_key: yes
    ...
  }

  measure: count {
    type: count
  }
}

view: child {
  dimension: id {
    primary_key: yes
    ...
  }

  measure: count {
    type: count
    hidden: yes
  }
}</pre>


<p>同じように <code>child.id</code> のテストを書きましたが、うまくいきません。<code>is_not_null</code> はまだしも、<code>is_unique</code> がダメです。</p>

<pre class="code" data-lang="" data-unlink># これは OK
test: parent_child_id_is_not_null {
  explore_source: parent {
    column: id { field: child.id }
    sorts: [child.id: asc]
    limit: 1
  }
  assert: child_id_is_not_null {
    expression: NOT is_null(${child.id}) ;;
  }
}

# parent の count になり、テストが通らない。
test: parent_child_id_is_unique {
  explore_source: parent {
    column: id { field: child.id }
    column: count { field: child.count }
    sorts: [parent.count: desc]
    limit: 1
  }
  assert: child_id_is_unique {
    expression: ${child.count} = 1 ;;
  }
}</pre>


<p>よく考えれば当たり前の話で、Join した状態でテストを書いているからです。そもそも <code>child</code> view の primary_key のテストをしたいだけなのに、Join は邪魔です。</p>

<h2 id="Join-先の-view-の-primary_key-をいい感じにテストする">Join 先の view の primary_key をいい感じにテストする</h2>

<p><code>child</code> view と同じファイルに、こっそり <code>child</code> explore を定義します。<a href="https://docs.looker.com/ja/reference/explore-params/hidden-for-explore">hidden</a> にして存在を消しています。さらに <a href="https://docs.looker.com/reference/explore-params/required_access_grants-for-explore">required_access_grants</a> で、開発者以外の URL 直打ちによるアクセスも防いでいます。</p>

<pre class="code" data-lang="" data-unlink>view: child {
  dimension: id {
    primary_key: yes
    ...
  }

  measure: count {
    type: count
    hidden: yes
  }
}

# Define for test
explore: child {
  hidden: yes
  required_access_grants: [can_view_explores_for_tests]
}</pre>


<p><a href="https://docs.looker.com/reference/model-params/access_grant">access_grant</a> である <code>can_view_explores_for_tests</code> はこのような定義です。</p>

<pre class="code" data-lang="" data-unlink># For tests
access_grant: can_view_explores_for_tests {
  user_attribute: view_explores_for_tests
  allowed_values: [&#34;yes&#34;]
}</pre>


<p><a href="https://docs.looker.com/admin-options/settings/user-attributes">User attribute</a> である <code>view_explores_for_tests</code> は、今回のような「Join 先の view をテストすること」全般に使います。User Access は <code>None</code>、Default Value も <code>no</code> です。開発者用の Group を作り、その Group value を <code>yes</code> にしました。</p>

<p>ここまでやらずとも全員アクセス不可でも良いのですが、テストが落ちた時に「クエリの探索」からの調査ができなくなるので、開発者にはアクセス権を与えるポリシーにしています。</p>

<p>あとは <code>parent</code> explore と同じようにテストを書くだけです。</p>

<pre class="code" data-lang="" data-unlink>test: child_id_is_not_null {
  explore_source: child {
    column: id {}
    sorts: [child.id: asc]
    limit: 1
  }
  assert: id_is_not_null {
    expression: NOT is_null(${child.id}) ;;
  }
}

test: child_id_is_unique {
  explore_source: child {
    column: id {}
    column: count {}
    sorts: [child.count: desc]
    limit: 1
  }
  assert: id_is_unique {
    expression: ${child.count} = 1 ;;
  }
}</pre>


<p>テストは通っても、LookML validation error が発生するかもしれません。その時は <a href="https://docs.looker.com/ja/reference/explore-params/fields-for-explore">fields</a> パラメータを使って、露出する field を限定すると良いでしょう。</p>

<pre class="code" data-lang="" data-unlink># Define for test
explore: child {
  hidden: yes
  required_access_grants: [can_view_explores_for_tests]
  fields: [child.id, child.count] # Avoid LookML validation error
}</pre>


<p>このテクニックは <a href="https://help.looker.com/hc/en-us/articles/360023586293-Error-Unknown-or-Inaccessible-Field">Error: Unknown or Inaccessible Field – Looker Help Center</a> でも紹介されています。</p>

<h2 id="まとめと所感">まとめと所感</h2>

<p>LookML 開発者で、且つテストを書いていて、且つ Join 先の view の primary_key に課題を抱えている、大変ニッチな層向けに記事を書きました。どこかの誰かに参考になれば幸いです。</p>

<p>もっと良い方法や、今回のやり方はここがマズイとかあれば <a href="https://twitter.com/masutaka">@masutaka</a> にお知らせ頂けると大変うれしいです。🙏</p>

<p>Feedmatic では今回のような view は数十もあり、primary_key のテストはまだ書き始めたばかりです。</p>

<p>Looker ではテストは直列でしか実行されないようで、書けば書くほど全テストが遅くなるのはモヤモヤしています。さすがに要望しようと思ってますが。</p>

<p>それに関連して、最近ディレクトリやファイル構成を再検討しました。次回はその記事を書く予定です。</p>

<h2 id="おまけ">おまけ</h2>

<p>今回の記事を書く過程で、中の人が書いたベストプラクティスを見つけました。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Flookml-data-tests-recommendations-and-best-practices-20815" title="LookML Data Tests: Recommendations and Best Practices | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>今回の記事ほど細かいテクニックは書かれていませんが、全体を網羅した良記事なので要チェックです。</p>


こんにちは、id:masutaka26 です。先週はまるっと夏休みにしてました。今日からまた Looker と戯れる日々が始まります。丸１年 Looker と戯れてきて最近ようやく、Join 先の view でも primary_key が壊れてないことを保証するテストの書き方が分かったので、今回紹介します。Looker における primary_key の役割primary_key の実装例LookML 開発におけるテストJoin 先の view は primary_key をテスト出来ないことがあるJoin 先の view の primary_key をいい感じにテストするまとめと所感おまけLooker における primary_key の役割Looker には Symmetric Aggregates という、合計を重複させない素晴らしい仕組みがあります。以前このブログでも紹介しました。その Symmetric Aggregates では primary_key が重要な役割を果たします。適切に設定されていないと、以下のような問題が発生します。primary_key が重複すると fanout エラーが発生することがあるprimary_key が null だと Measure が 0 になることがあるこのような問題は大概、ふわっと質問が来て発覚します。今のタスクを保留にして調査することは精神的になかなか辛いものがあり、それなりに時間も費やすことになるため、可能な限り事前に避けたいところです。primary_key の実装例私が所属する Feedmatic では、ウェブ広告や Google Analytics のデータを扱っています。正規化されたきれいなデータは少なく、Rails の id のようなユニークなカラムは存在しないことが多いです。そのため、このようにいくつかの Dimension を組み合わせて primary_key を定義します。dimension: id {  primary_key: yes  type: string  sql: CONCAT(${dimension1}, ${dimension2}, IFNULL(${dimension3}, '')) ;;  hidden: yes}※ DWH は BigQuery を使っています。これで済めばよいのですが、上の例だとある日突然 dimension2 が null になり始めたり、全ての string 型の Dimension を使っても重複し始めることがあります。データの性格は理解していたつもりでしたが、実際どちらもありました。😭LookML 開発におけるテスト以上の課題を解決するために、test パラメータが使えます。例えばこのような parent explore があったとします。Join がないのでシンプルです。explore: parent {  ...}view: parent {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count  }}私はこのようなテストを書いて、全ての parent.id が null でないことと、重複しないことを保証させています。test: parent_id_is_not_null {  explore_source: parent {    column: id {}    sorts: [parent.id: asc]    limit: 1  }  assert: id_is_not_null {    expression: NOT is_null(${parent.id}) ;;  }}test: parent_id_is_unique {  explore_source: parent {    column: id {}    column: count {}    sorts: [parent.count: desc]    limit: 1  }  assert: id_is_unique {    expression: ${parent.count} = 1 ;;  }}👉 ソート時に null が先頭と末尾のどちらに来るかは、DWH の実装によります。Join 先の view は primary_key をテスト出来ないことがあるさて、child view を Join する必要が出てきました。explore: parent {  join: child {    type: left_outer    relationship: one_to_many    sql_on: ... ;;  }}view: parent {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count  }}view: child {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count    hidden: yes  }}同じように child.id のテストを書きましたが、うまくいきません。is_not_null はまだしも、is_unique がダメです。# これは OKtest: parent_child_id_is_not_null {  explore_source: parent {    column: id { field: child.id }    sorts: [child.id: asc]    limit: 1  }  assert: child_id_is_not_null {    expression: NOT is_null(${child.id}) ;;  }}# parent の count になり、テストが通らない。test: parent_child_id_is_unique {  explore_source: parent {    column: id { field: child.id }    column: count { field: child.count }    sorts: [parent.count: desc]    limit: 1  }  assert: child_id_is_unique {    expression: ${child.count} = 1 ;;  }}よく考えれば当たり前の話で、Join した状態でテストを書いているからです。そもそも child view の primary_key のテストをしたいだけなのに、Join は邪魔です。Join 先の view の primary_key をいい感じにテストするchild view と同じファイルに、こっそり child explore を定義します。hidden にして存在を消しています。さらに required_access_grants で、開発者以外の URL 直打ちによるアクセスも防いでいます。view: child {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count    hidden: yes  }}# Define for testexplore: child {  hidden: yes  required_access_grants: [can_view_explores_for_tests]}access_grant である can_view_explores_for_tests はこのような定義です。# For testsaccess_grant: can_view_explores_for_tests {  user_attribute: view_explores_for_tests  allowed_values: ["yes"]}User attribute である view_explores_for_tests は、今回のような「Join 先の view をテストすること」全般に使います。User Access は None、Default Value も no です。開発者用の Group を作り、その Group value を yes にしました。ここまでやらずとも全員アクセス不可でも良いのですが、テストが落ちた時に「クエリの探索」からの調査ができなくなるので、開発者にはアクセス権を与えるポリシーにしています。あとは parent explore と同じようにテストを書くだけです。test: child_id_is_not_null {  explore_source: child {    column: id {}    sorts: [child.id: asc]    limit: 1  }  assert: id_is_not_null {    expression: NOT is_null(${child.id}) ;;  }}test: child_id_is_unique {  explore_source: child {    column: id {}    column: count {}    sorts: [child.count: desc]    limit: 1  }  assert: id_is_unique {    expression: ${child.count} = 1 ;;  }}テストは通っても、LookML validation error が発生するかもしれません。その時は fields パラメータを使って、露出する field を限定すると良いでしょう。# Define for testexplore: child {  hidden: yes  required_access_grants: [can_view_explores_for_tests]  fields: [child.id, child.count] # Avoid LookML validation error}このテクニックは Error: Unknown or Inaccessible Field – Looker Help Center でも紹介されています。まとめと所感LookML 開発者で、且つテストを書いていて、且つ Join 先の view の primary_key に課題を抱えている、大変ニッチな層向けに記事を書きました。どこかの誰かに参考になれば幸いです。もっと良い方法や、今回のやり方はここがマズイとかあれば @masutaka にお知らせ頂けると大変うれしいです。🙏Feedmatic では今回のような view は数十もあり、primary_key のテストはまだ書き始めたばかりです。Looker ではテストは直列でしか実行されないようで、書けば書くほど全テストが遅くなるのはモヤモヤしています。さすがに要望しようと思ってますが。それに関連して、最近ディレクトリやファイル構成を再検討しました。次回はその記事を書く予定です。おまけ今回の記事を書く過程で、中の人が書いたベストプラクティスを見つけました。今回の記事ほど細かいテクニックは書かれていませんが、全体を網羅した良記事なので要チェックです。

Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた

<p>こんばんは、<del>徳川家ｙ</del> <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。</p>

<p>以前紹介したように、去年から <a href="https://ja.looker.com/">Looker</a> を使ったウェブ広告数値の可視化や BI <a href="#f-25b67c2a" name="fn-25b67c2a" title="Business Intelligence">*1</a> に取り組んでいます。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>LookML 開発者として LookML を書き始めて困ったのが、Looker の情報が少ないように見えたことです。</p>

<p>LookML を含む Looker のドキュメントは充実しているのですが、それらを組み合わせた応用的なフロー情報が少なく感じました。ビジネスユーザー向けの情報も同様です。</p>

<p>現在は網羅的、かつ集約した情報を取得できているので、その方法をご紹介します。</p>

<ul class="table-of-contents">
    <li><a href="#情報源をリストアップする">「情報源」をリストアップする</a></li>
    <li><a href="#少し脱線">少し脱線...</a></li>
    <li><a href="#情報源の取得方法への課題">「情報源」の取得方法への課題</a></li>
    <li><a href="#今はどうなったか">今はどうなったか？</a></li>
    <li><a href="#Looker-Communityのフィードが存在した件">「Looker Community」のフィードが存在した件</a></li>
    <li><a href="#Looker-の記事一覧--DevelopersIOのフィードを作った件">「Looker の記事一覧 | DevelopersIO」のフィードを作った件</a></li>
    <li><a href="#まとめ">まとめ</a></li>
    <li><a href="#追記">追記</a></li>
</ul>

<h2 id="情報源をリストアップする">「情報源」をリストアップする</h2>

<p>初めはこれらをたまに見に行ったり、Slack の <code>/feed subscribe</code> <a href="#f-e46aea89" name="fn-e46aea89" title="Slack に RSS フィードを追加する | Slack">*2</a> で購読したりしてました。</p>

<ul>
<li><a href="https://community.looker.com/">Looker Community</a>

<ul>
<li>公式フォーラム。英語で Question や Conversation が出来る</li>
</ul>
</li>
<li><p><a href="https://community.looker.com/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-japanese-161">Looker 日本語コミュニティフォーラム</a></p>

<ul>
<li>「Looker Community」の日本語版。<a href="https://docs.looker.com/relnotes/intro">Release Notes</a> の日本語訳には本当に感謝 🙏</li>
<li><p>「ニュースと告知」「ヘルプとサポート」「コラム」はそれぞれ Subscribe 出来る。メールで通知される</p>

<p>  <figure class="figure-image figure-image-fotolife" title="Looker 日本語コミュニティフォーラム"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815145002.png" alt="f:id:masutaka26:20210815145002p:plain" width="1200" height="382" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Looker 日本語コミュニティフォーラム</figcaption></figure></p></li>
</ul>
</li>
<li><p><a href="https://www.facebook.com/groups/721814241538725">Looker APAC Forum | Facebook</a></p>

<ul>
<li>リリース案内や事例紹介など</li>
</ul>
</li>
<li><a href="https://dev.classmethod.jp/tags/looker/">Looker の記事一覧 | DevelopersIO</a>

<ul>
<li>ご存知クラスメソッドさんのブログ。国内最多の記事量と投稿頻度</li>
</ul>
</li>
<li><a href="https://zenn.dev/topics/looker">Lookerの記事一覧 | Zenn</a>

<ul>
<li>Zenn にもそれなりの頻度で投稿される</li>
</ul>
</li>
<li><a href="https://qiita.com/tags/looker">Looker - Qiita</a>

<ul>
<li>Qiita はもう少し頻度は落ちるかな</li>
</ul>
</li>
<li><a href="https://twitter.com/search?q=%23looker%20lang%3Aja&amp;f=live&amp;vertical=default">#looker lang:ja - Twitter 検索</a>

<ul>
<li>以上の情報をふわっと取得できる。<code>looker lang:ja</code> や <code>#looker</code> だとノイズが多いのでこれに落ち着いた</li>
</ul>
</li>
</ul>


<h2 id="少し脱線">少し脱線...</h2>

<p>Looker Community には過去一度だけ質問しました。</p>

<p><a href="https://community.looker.com/lookml-5/how-do-i-dynamically-switch-view-name-in-sql-parameter-of-dimension-27831">How do I dynamically switch view name in sql parameter of dimension? | Looker Community</a></p>

<p>私は日本語サポートに頼ることが多い傾向です。最近はだいぶ減らせています。</p>

<p>扱う情報を外に出せないので、外に出せるところまで昇華するのは難しいですね。🌀</p>

<p>Looker の水野さんが日本語訳して下さっている、Looker のリリースノート <a href="#f-c898f381" name="fn-c898f381" title="例: Looker 21.12 リリースノート | Looker Community">*3</a> は、去年の 12 月から社内向けにこんな記事を書いて、Looker に徹底的に向き合うようにしています。</p>

<p><figure class="figure-image figure-image-fotolife" title="Looker 21.12 のリリースノートを眺めてみた"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815160438.png" alt="f:id:masutaka26:20210815160438p:plain" width="1200" height="849" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Looker 21.12 のリリースノートを眺めてみた</figcaption></figure></p>

<p>今まで書いた記事です。</p>

<p><figure class="figure-image figure-image-fotolife" title="Looker のリリースノートを眺めてみたシリーズ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815160356.png" alt="f:id:masutaka26:20210815160356p:plain" width="1200" height="887" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Looker のリリースノートを眺めてみたシリーズ</figcaption></figure></p>

<h2 id="情報源の取得方法への課題">「情報源」の取得方法への課題</h2>

<p>RSS/Atom（フィード）を配信していないサイトがほとんどで、見に行くのがかなり面倒でした。</p>

<p>そのものズバリなフィードは Zenn と Qiita だけです。クラスメソッドさんは Looker タグのフィードが存在せず、当時は Twitter で捕捉してました。</p>

<h2 id="今はどうなったか">今はどうなったか？</h2>

<p>ほぼすべてを社内の Slack channel <code>#news-looker</code> に集約させることが出来ました。</p>

<p>以下が実際に購読しているフィードです。</p>

<ul>
<li><a href="https://community.looker.com/feed/buzzcapture">https://community.looker.com/feed/buzzcapture</a>

<ul>
<li>「Looker Community」のフィード。後述する</li>
</ul>
</li>
<li><a href="https://feed43.com/developersio-looker.xml">https://feed43.com/developersio-looker.xml</a>

<ul>
<li>「Looker の記事一覧 | DevelopersIO」のフィード。後述する</li>
</ul>
</li>
<li><a href="https://zenn.dev/topics/looker/feed">https://zenn.dev/topics/looker/feed</a>

<ul>
<li>「Lookerの記事一覧 | Zenn」のフィード</li>
</ul>
</li>
<li><a href="https://qiita.com/tags/looker/feed">https://qiita.com/tags/looker/feed</a>

<ul>
<li>「Looker - Qiita」のフィード</li>
</ul>
</li>
</ul>


<p>Twitter は <a href="https://ifttt.com/">IFTTT</a> を使って、同 channel に POST しています。</p>

<ul>
<li><code>If</code> New tweet from search <code>#looker OR LookML lang:ja -rt</code></li>
<li><code>Then</code> Post to channel

<ul>
<li>Channel: <code>#news-looker</code></li>
<li>Message: <code>@{{UserName}} : {{Text}} (via Twitter {{LinkToTweet}})</code></li>
</ul>
</li>
</ul>


<p>「Looker APAC Forum | Facebook」は集約できませんでしたが、Twitter にも流れることがあるので、一旦考えないことにしました。</p>

<h2 id="Looker-Communityのフィードが存在した件">「Looker Community」のフィードが存在した件</h2>

<p><a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA-the-kitchen-table-%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F-24032?postid=45126#post45126">Looker の水野さんに聞いたら、調べて教えて下さいました。</a>🙏</p>

<ul>
<li>(1) 新しいトピックの投稿

<ul>
<li><a href="https://community.looker.com/feed/topics">https://community.looker.com/feed/topics</a></li>
</ul>
</li>
<li>(2) 全ての新しい投稿（最初の投稿（タイトル＋ボディ）+ 全てのリプライ）

<ul>
<li><a href="https://community.looker.com/feed/buzzcapture">https://community.looker.com/feed/buzzcapture</a></li>
</ul>
</li>
</ul>


<p>アナウンス記事です。
<a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%81%AErss%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89-25553?postid=46404#post46404">LookerコミュニティのRSSフィード | Looker Community</a></p>

<p>(1) と (2) は両方とも「Looker 日本語コミュニティフォーラム」の情報も流れてきます。</p>

<p>今は (2) を購読しており、トラフィックはそれなりにあります。もちろんほぼ全て英語です。辛かったら (1) にすると良いと思います。</p>

<p><a href="https://community.looker.com/">https://community.looker.com/</a> の HTML には RSS/Atom 情報がないので、これらのフィードに気づける人は少ないと思います。Looker さんには是非お願いしたいところです。</p>

<h2 id="Looker-の記事一覧--DevelopersIOのフィードを作った件">「Looker の記事一覧 | DevelopersIO」のフィードを作った件</h2>

<p>ないものは仕方がないので、<a href="https://feed43.com/">Feed43</a> というサービスで作りました。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmasutaka.net%2Fchalow%2F2021-03-14-1.html" title="フィード（RSS/Atom）を配信していないサイトのフィードを Feed43 で作成する" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>出来たのが <a href="https://feed43.com/developersio-looker.xml">https://feed43.com/developersio-looker.xml</a> です。どなたでも購読可能です。よろしければどうぞ。</p>

<p>HTML をパースしているだけなので、HTML 構造が変わったら壊れることはあると思います。気づけたら直します。</p>

<p>本当は <a href="https://dev.classmethod.jp/tags/looker/">https://dev.classmethod.jp/tags/looker/</a> のフィードがあれば良いのですけどね。今後に期待です。</p>

<p>[Update] そのものズバリ <a href="https://dev.classmethod.jp/feed/?tag=looker">https://dev.classmethod.jp/feed/?tag=looker</a> を <a href="https://twitter.com/sh19910711/status/1427429573117964306">Twitterで教えて</a>頂きました。ありがとうございます！</p>

<h2 id="まとめ">まとめ</h2>

<p>私が１年かけて辿り着いた、Looker の情報取得方法をご紹介しました。</p>

<p>これで Looker の情報は大量にインプット出来たので、今後はコミュニティにアウトプットしていきます。🔥
※ ネタは少しあるけど、時間がない。(^^;</p>

<p>皆さんにも参考になれば幸いです。他にもあれば <a href="https://twitter.com/masutaka">@masutaka</a> に教えて下さい！</p>

<h2 id="追記">追記</h2>

<blockquote><p>他にもあれば <a href="https://twitter.com/masutaka">@masutaka</a> に教えて下さい！</p></blockquote>

<p>記事にも登場して頂いた Looker の水野さん <a href="https://twitter.com/tomoya_cs">@tomoya_cs</a> をフォローするとさらに捗ると思います。</p>

<p><blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">Lookerの情報収集本当に至難と思いますが、まとめていただきありがとうございます😭<br>あとは私をフォローいただけると最新情報が入手しやすくなるかと（アウトプットがんばります🙇‍♂️） <a href="https://t.co/eDQz8A5VCC">https://t.co/eDQz8A5VCC</a></p>&mdash; tomoya | Looker CS (@tomoya_cs) <a href="https://twitter.com/tomoya_cs/status/1428194155943972872?ref_src=twsrc%5Etfw">2021年8月19日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p>
<div class="footnote">
<p class="footnote"><a href="#fn-25b67c2a" name="f-25b67c2a" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AA%E3%82%B8%E3%82%A7%E3%83%B3%E3%82%B9">Business Intelligence</a></span></p>
<p class="footnote"><a href="#fn-e46aea89" name="f-e46aea89" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://slack.com/intl/ja-jp/help/articles/218688467-Slack-%E3%81%AB-RSS-%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B">Slack に RSS フィードを追加する | Slack</a></span></p>
<p class="footnote"><a href="#fn-c898f381" name="f-c898f381" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text">例: <a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker-21-12-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%8E%E3%83%BC%E3%83%88-27799">Looker 21.12 リリースノート | Looker Community</a></span></p>
</div>

こんばんは、徳川家ｙ id:masutaka26 です。以前紹介したように、去年から Looker を使ったウェブ広告数値の可視化や BI *1 に取り組んでいます。LookML 開発者として LookML を書き始めて困ったのが、Looker の情報が少ないように見えたことです。LookML を含む Looker のドキュメントは充実しているのですが、それらを組み合わせた応用的なフロー情報が少なく感じました。ビジネスユーザー向けの情報も同様です。現在は網羅的、かつ集約した情報を取得できているので、その方法をご紹介します。「情報源」をリストアップする少し脱線...「情報源」の取得方法への課題今はどうなったか？「Looker Community」のフィードが存在した件「Looker の記事一覧 | DevelopersIO」のフィードを作った件まとめ追記「情報源」をリストアップする初めはこれらをたまに見に行ったり、Slack の /feed subscribe *2 で購読したりしてました。Looker Community公式フォーラム。英語で Question や Conversation が出来るLooker 日本語コミュニティフォーラム「Looker Community」の日本語版。Release Notes の日本語訳には本当に感謝 🙏「ニュースと告知」「ヘルプとサポート」「コラム」はそれぞれ Subscribe 出来る。メールで通知される  Looker 日本語コミュニティフォーラムLooker APAC Forum | Facebookリリース案内や事例紹介などLooker の記事一覧 | DevelopersIOご存知クラスメソッドさんのブログ。国内最多の記事量と投稿頻度Lookerの記事一覧 | ZennZenn にもそれなりの頻度で投稿されるLooker - QiitaQiita はもう少し頻度は落ちるかな#looker lang:ja - Twitter 検索以上の情報をふわっと取得できる。looker lang:ja や #looker だとノイズが多いのでこれに落ち着いた少し脱線...Looker Community には過去一度だけ質問しました。How do I dynamically switch view name in sql parameter of dimension? | Looker Community私は日本語サポートに頼ることが多い傾向です。最近はだいぶ減らせています。扱う情報を外に出せないので、外に出せるところまで昇華するのは難しいですね。🌀Looker の水野さんが日本語訳して下さっている、Looker のリリースノート *3 は、去年の 12 月から社内向けにこんな記事を書いて、Looker に徹底的に向き合うようにしています。Looker 21.12 のリリースノートを眺めてみた今まで書いた記事です。Looker のリリースノートを眺めてみたシリーズ「情報源」の取得方法への課題RSS/Atom（フィード）を配信していないサイトがほとんどで、見に行くのがかなり面倒でした。そのものズバリなフィードは Zenn と Qiita だけです。クラスメソッドさんは Looker タグのフィードが存在せず、当時は Twitter で捕捉してました。今はどうなったか？ほぼすべてを社内の Slack channel #news-looker に集約させることが出来ました。以下が実際に購読しているフィードです。https://community.looker.com/feed/buzzcapture「Looker Community」のフィード。後述するhttps://feed43.com/developersio-looker.xml「Looker の記事一覧 | DevelopersIO」のフィード。後述するhttps://zenn.dev/topics/looker/feed「Lookerの記事一覧 | Zenn」のフィードhttps://qiita.com/tags/looker/feed「Looker - Qiita」のフィードTwitter は IFTTT を使って、同 channel に POST しています。If New tweet from search #looker OR LookML lang:ja -rtThen Post to channelChannel: #news-lookerMessage: @{{UserName}} : {{Text}} (via Twitter {{LinkToTweet}})「Looker APAC Forum | Facebook」は集約できませんでしたが、Twitter にも流れることがあるので、一旦考えないことにしました。「Looker Community」のフィードが存在した件Looker の水野さんに聞いたら、調べて教えて下さいました。🙏(1) 新しいトピックの投稿https://community.looker.com/feed/topics(2) 全ての新しい投稿（最初の投稿（タイトル＋ボディ）+ 全てのリプライ）https://community.looker.com/feed/buzzcaptureアナウンス記事です。LookerコミュニティのRSSフィード | Looker Community(1) と (2) は両方とも「Looker 日本語コミュニティフォーラム」の情報も流れてきます。今は (2) を購読しており、トラフィックはそれなりにあります。もちろんほぼ全て英語です。辛かったら (1) にすると良いと思います。https://community.looker.com/ の HTML には RSS/Atom 情報がないので、これらのフィードに気づける人は少ないと思います。Looker さんには是非お願いしたいところです。「Looker の記事一覧 | DevelopersIO」のフィードを作った件ないものは仕方がないので、Feed43 というサービスで作りました。出来たのが https://feed43.com/developersio-looker.xml です。どなたでも購読可能です。よろしければどうぞ。HTML をパースしているだけなので、HTML 構造が変わったら壊れることはあると思います。気づけたら直します。本当は https://dev.classmethod.jp/tags/looker/ のフィードがあれば良いのですけどね。今後に期待です。[Update] そのものズバリ https://dev.classmethod.jp/feed/?tag=looker を Twitterで教えて頂きました。ありがとうございます！まとめ私が１年かけて辿り着いた、Looker の情報取得方法をご紹介しました。これで Looker の情報は大量にインプット出来たので、今後はコミュニティにアウトプットしていきます。🔥※ ネタは少しあるけど、時間がない。(^^;皆さんにも参考になれば幸いです。他にもあれば @masutaka に教えて下さい！追記他にもあれば @masutaka に教えて下さい！記事にも登場して頂いた Looker の水野さん @tomoya_cs をフォローするとさらに捗ると思います。Lookerの情報収集本当に至難と思いますが、まとめていただきありがとうございます😭あとは私をフォローいただけると最新情報が入手しやすくなるかと（アウトプットがんばります🙇‍♂️） https://t.co/eDQz8A5VCC— tomoya | Looker CS (@tomoya_cs) 2021年8月19日  *1:Business Intelligence*2:Slack に RSS フィードを追加する | Slack*3:例: Looker 21.12 リリースノート | Looker Community

私が１年かけて辿り着いた Looker の情報収集方法を紹介する

こんにちは、エンジニアの id:len_prog です。私が所属している EC Booster チームでは、「カイゼンカード」機能の開発に Firebase を採用しています。しかし、Firebase を採用したことで苦労したことが全く無かったわけではありません。そこで、今回の記事では、いくつかあったハマりごとの中でも特に厄介だったものについて対策を書いていきます。Firestore Emulator のプロジェクト共有時のデータ競合Firebase Local Emulator Suite を使って Firestore に接続するテストを書いていた際に、調査の結果、これは、接続先プロジェクトがすべてのテストで同じになってしまっているのが原因ということが分かりました。この状態で同じドキュメントを書き換えるテストが並列で走ってしまった場合、実行タイミングによってはドキュメントが予期せぬ状態になってしまいます。このままでは役に立つテストが書けないと思い試行錯誤した結果、テストごとに違うプロジェクトの Firestore に接続することでそれぞれのテストが独立した状態で実行でき、結果としてデータ競合が防げることが分かりました。以下、サンプルアプリケーションを用いてこの方法について書いていきます。サンプルアプリケーションの概要今回は、サンプルとして簡易的な RPG を開発することを想定します。characters コレクションで管理されています。{  name: string;  level: number;  job: string;}また、このゲームでは以下の行動のみが可能と仮定します(これだけじゃゲームとして成り立たないと思いますが、簡単のためということでお許しください)キャラクターは、レベルアップすることができるキャラクターは、転職することができる転職すると、キャラクターのレベルが1に戻るなお、アプリケーション上においてキャラクターのレベルアップは、characterLevelUpUseCase、キャラクターの転職は characterJobChangeUseCase という関数を呼ぶことで行えることとします。ここからは、実際にこれら2つの関数のテストコードが競合する様子を見ていきます。データ競合発生時の構成characterJobChangeUseCase と characterLevelUpUseCase が my-game プロジェクトの Firestore を共有してしまっています。// functions/src/usecases/characterJobChangeUseCase.spec.tsimport * as admin from "firebase-admin";import { characterJobChangeUseCase } from "@/usecases/characterJobChangeUseCase";admin.initializeApp({  projectId: "my-game", // ここが問題});const charactersCollection = admin  .firestore()  .collection("characters");describe(characterJobChangeUseCase, () => {  const targetCharacterId = "target-character-id";  beforeEach(async () => {    await charactersCollection.doc(targetCharacterId).set({        name: "アルス",        level: 10,        job: "すっぴん";    });  });  afterEach(async () => {    await charactersCollection.doc(targetCharacterId).delete();  });  it("キャラクターが転職した場合、レベルが1に戻ること", async () => {    await characterJobChangeUseCase(targetCharacterId); // characterJobChangeUsecase#handle に渡された引数の ID を持つユーザーのレベルが1に戻る    const jobChangedCharacter = (await charactersCollection.doc(targetCharacterId).get()).data();    expect(jobChangedCharacter.level).toBe(1); // 実行タイミング次第では、1になるはずが11になってしまう！  });});// functions/src/usecases/characterLevelUpUseCase.spec.tsimport * as admin from "firebase-admin";import { characterLevelUpUseCase } from "@/usecases/characterLevelUpUseCase";admin.initializeApp({  projectId: "my-game", // ここが問題});const charactersCollection = admin  .firestore()  .collection("characters");describe(characterLevelUpUseCase, () => {  const targetCharacterId = "target-character-id";  beforeEach(async () => {    await charactersCollection.doc(targetCharacterId).set({        name: "アルス",        level: 10,        job: "すっぴん";    });  });  afterEach(async () => {    await charactersCollection.doc(targetCharacterId).delete();  });  it("キャラクターがレベルアップした場合、レベルが1上がること", async () => {    await characterLevelUpUseCase(targetCharacterId); // characterJobChangeUsecase#handle に渡された引数の ID を持つユーザーのレベルが1上がる    const grownCharacter = (await charactersCollection.doc(targetCharacterId).get()).data();    expect(grownCharacter.level).toBe(11); // 実行タイミング次第では、11になるはずが1に戻ってしまう！  });});見ての通り、両方のテストが my-game プロジェクトの Firestore の、ID: target-character-id のドキュメントを更新してしまっています。キャラクターが転職したのにレベルが1に戻らない、キャラクターがレベルアップしたはずなのになぜかレベル1に戻ってしまうなど予期せぬ状態になってしまい、テストが落ちてしまう可能性があります。この状態ではテストコードが信用できないので、テストごとに向き先プロジェクトを変えてこの問題を解決していきます。データ競合解決後の構成上図②③のようにテストごとに接続先プロジェクトを独立させることで、他のテストとの並列実行が原因のデータ競合を防ぐことができます。admin.initializeApp()の第一引数に他のテストと重複しないプロジェクトID を渡すようにします。// functions/src/usecases/characterJobChangeUseCase.spec.tsadmin.initializeApp({  projectId: "character-job-change-use-case-spec", //  図の②に対応});// functions/src/usecases/characterLevelUpUseCase.spec.tsadmin.initializeApp({  projectId: "character-level-up-use-case-spec", // 図の③に対応});変更後のコードの全体像は以下のようになります。// functions/src/usecases/characterJobChangeUseCase.spec.tsimport * as admin from "firebase-admin";import { characterJobChangeUseCase } from "@/usecases/characterJobChangeUseCase";admin.initializeApp({  projectId: "character-job-change-use-case-spec", //  図の②に対応});// ここから下は構成変更前のコードと同じconst charactersCollection = admin  .firestore()  .collection("characters");describe(characterJobChangeUseCase, () => {  const targetCharacterId = "target-character-id";  beforeEach(async () => {    await charactersCollection.doc(targetCharacterId).set({        name: "アルス",        level: 10,        job: "すっぴん";    });  });  afterEach(async () => {    await charactersCollection.doc(targetCharacterId).delete();  });  it("キャラクターが転職した場合、レベルが1に戻ること", async () => {    await characterJobChangeUseCase(targetCharacterId); // characterJobChangeUsecase#handle に渡された引数の ID を持つユーザーのレベルが1に戻る    const jobChangedCharacter = (await charactersCollection.doc(targetCharacterId).get()).data();    expect(jobChangedCharacter.level).toBe(1); // 転職するとレベルが1に戻ることを検証できるようになった  });});// functions/src/usecases/characterLevelUpUseCase.spec.tsimport * as admin from "firebase-admin";import { characterLevelUpUseCase } from "@/usecases/characterLevelUpUseCase";admin.initializeApp({  projectId: "character-level-up-use-case-spec", // 図の③に対応});// ここから下は構成変更前のコードと同じconst charactersCollection = admin  .firestore()  .collection("characters");describe(characterLevelUpUseCase, () => {  const targetCharacterId = "target-character-id";  beforeEach(async () => {    await charactersCollection.doc(targetCharacterId).set({        name: "アルス",        level: 10,        job: "すっぴん";    });  });  afterEach(async () => {    await charactersCollection.doc(targetCharacterId).delete();  });  it("キャラクターがレベルアップした場合、レベルが1上がること", async () => {    await characterLevelUpUseCase(targetCharacterId); // characterJobChangeUsecase#handle に渡された引数の ID を持つユーザーのレベルが1上がる    const grownCharacter = (await charactersCollection.doc(targetCharacterId).get()).data();    expect(grownCharacter.level).toBe(11); // レベルアップした場合にレベルが1上がることを検証できるようになった  });});このようにテストごとに向き先プロジェクトを変えることで、それぞれのテストで担保したいことをちゃんと担保できるようになります。ちょっと微妙な点上記の方法でテストごとに独立した環境の Firestore を操作できるようになり、データ競合を防げるようになりました。しかし、この方法にはひとつだけ微妙な点があります。競合解決後の構成図を再掲します。上図①の接続先は、$ firebase use で指定したプロジェクトか、$ firebase emulators:start に --projectを渡した場合にはそのプロジェクトになり、そのほかの方法で変えることは今のところできないようです。そのため、プロジェクトをテストごとに分けた場合、上図②③のテスト中にテスト自体は動くものの、Firebase Emulator の UI からデータの内容を見ることはできなくなります。一応、接続先を $ firebase use で指定しているものに切り替えるようコードを書き換えたりすればデバッグはできますが、いちいち書き換えの手間が生じるので若干面倒です。また、これは Firebase Enulator の UI で立ち上がっているすべてのプロジェクトの Firestore を見られるようになれば解決する問題ではあり、実際に firebase/firebase-tools-ui リポジトリに issue も立っていますが、すぐに対応が終わりそうには見えない状況なので、しばらくは不便な状況が続くことが予想されます。所感Firebase は便利ですが、当然ながら全くハマらずに開発できる銀の弾丸ではないですね。今後も日々の開発で得た Firebase や GCP 周りの TIPS を書いていけたらと思っておりますので、よろしくお願いいたします 🙏

Firestore エミュレーターを使ったテスト同士の競合が起きないようにしていい感じにテストできるようにした話

<p>こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。いよいよ明後日は <a href="https://jp.rizinff.com/_ct/17440570">RIZIN.28</a> ですね！東京ドームで MMA（総合格闘技）のイベントが行われるのは、約 17 年半ぶりだそうです（Wikipedia 調べ）。ドキが胸胸します。</p>

<p>本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『ここがつらいよ普段使いのLinux』という発表をしました。タイトルは違いますが、気にしないで下さい。</p>

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTBXZg9pczERJABgT3Uuu922Ktcc91HHl00QOtySt7fFtxrL4NZOcco1BtkK_pDuFkO0Uo-JuAwBkoC/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


<p>Mac が重い時に IME 切り替えが一瞬遅れて、例えば「feedforce」とタイプする時に「ふぇえ...」になる現象に悩まされていました。</p>

<p>そこで約 10 年ぶりに Windows PC を購入して、同じく約 10 年ぶりに Linux を普段使いし始めました。</p>

<p>数々の諸問題が発生しましたが、無事全部解決（？）したお話です。</p>

<ul>
<li>キーボードショートカットがつらい</li>
<li>タッチパッドがつらい</li>
<li>指紋認証出来なくてつらい</li>
<li>たまにスリープから復帰しなくてつらい（一番つらい）</li>
<li>ちょっとした画像編集に GIMP を使うのはつらい</li>
</ul>


<p>みんなも Mac を捨てて Linux を使うといいと思うよ！</p>

<p>それでは！</p>

<p><div class="hatena-asin-detail"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" class="hatena-asin-detail-image-link" target="_blank" rel="noopener"><img src="https://m.media-amazon.com/images/I/51NEN46FW9L._SL500_.jpg" class="hatena-asin-detail-image" alt="だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス" title="だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" target="_blank" rel="noopener">だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス</a></p><ul class="hatena-asin-detail-meta"><li><span class="hatena-asin-detail-label">作者:</span><a href="http://d.hatena.ne.jp/keyword/%CE%EB%CC%DA%20%C5%AF%BA%C8" class="keyword">鈴木 哲哉</a></li><li>オーエス出版</li></ul><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" class="asin-detail-buy" target="_blank" rel="noopener">Amazon</a></div></div></p>


こんにちは id:masutaka26 です。いよいよ明後日は RIZIN.28 ですね！東京ドームで MMA（総合格闘技）のイベントが行われるのは、約 17 年半ぶりだそうです（Wikipedia 調べ）。ドキが胸胸します。本日、週次の社内勉強会 FFTT で『ここがつらいよ普段使いのLinux』という発表をしました。タイトルは違いますが、気にしないで下さい。Mac が重い時に IME 切り替えが一瞬遅れて、例えば「feedforce」とタイプする時に「ふぇえ...」になる現象に悩まされていました。そこで約 10 年ぶりに Windows PC を購入して、同じく約 10 年ぶりに Linux を普段使いし始めました。数々の諸問題が発生しましたが、無事全部解決（？）したお話です。キーボードショートカットがつらいタッチパッドがつらい指紋認証出来なくてつらいたまにスリープから復帰しなくてつらい（一番つらい）ちょっとした画像編集に GIMP を使うのはつらいみんなも Mac を捨てて Linux を使うといいと思うよ！それでは！だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス作者:鈴木 哲哉オーエス出版Amazon

『ここがつらいよ普段使いのLinux』という発表をした

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/f/feedforce_recruit/20210611/20210611163915.jpg" alt="f:id:feedforce_recruit:20210611163915j:plain" width="1200" height="700" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>こんにちは。人事の今岡と申します。
2021年もあっという間に6月ですね。</p>

<p>フィードフォースでは先日オンライン納会が開催され、半期に一度の「Engineer’s Principles Award 2021 Summer」の受賞者が発表されました。
今回アワードを受賞した開発メンバーと表彰内容をご紹介します。</p>

<p>前回の表彰者紹介はコチラ</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F12%2F28%2F131042" title="半期に1度の Engineer’s Principles Award 受賞者を紹介します - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2020/12/28/131042">developer.feedforce.jp</a></cite></p>

<h2>Engineer’s Principles Award とは</h2>

<p>Engineer’s Principles とは、フィードフォースの開発メンバー向けに現場が主体となって設定した、5つの行動指針です。
半期に一度、開発メンバー同士で投票を行い、行動指針の項目ごとに最も体現しているメンバーが選ばれ表彰されます。</p>

<p>Engineer’s Principles についてはこちら</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmedia.feedforce.jp%2Fn%2Fnd1f2236470b3" title="フィードフォースが目指すエンジニア像とは。「Engineer’s Principles」を紹介します｜フィードフォースのnote" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://media.feedforce.jp/n/nd1f2236470b3">media.feedforce.jp</a></cite></p>

<h2>受賞者紹介</h2>

<p>※表彰コメントは本来社内向けのものであるため一部変更させていただいています。受賞者によって各種アカウントを載せています。</p>

<h3>🏆「Stay Humble; 常に謙虚であるべし」受賞者</h3>

<h4>@len_prog さん</h4>

<p>表彰コメント：<br />
社内でメジャーな Rails 以外でバックエンドを実装する際に、なぜそうするのかという理由やレイヤーの切り方を他のメンバーにわかりやすく説明していました。
一方、自分自身で苦手なことがあった場合に、他の人に相談したり、フィードバックを求めそれを受け入れる姿勢は、まさに Stay Humble だと思いました。</p>

<p><i class="blogicon-twitter"></i> <a href="https://twitter.com/len_prog">Len (@len_prog)</a> , <i class="blogicon-entry"></i> <a href="https://len-prog.hatenablog.com/">Blog</a></p>

<h4>@katsunn さん</h4>

<p>表彰コメント：<br />
事前に色々なアイデアを用意しつつも、相談の過程でお互いの認識や意図を踏まえたうえで改善を進めていく一方、ただ受け入れるだけではなく、
プロフェッショナルとして自分なりに咀嚼したアウトプットにしていく姿勢が非常に素晴らしく、ベンチマークにすべきだと感じました。</p>

<p><i class="blogicon-twitter"></i>  <a href="https://twitter.com/nomo_017">のもち(@nomo_017)</a></p>

<h3>🏆「Be Positive &amp; Proactive; 常に肯定的・主体的であるべし」受賞者</h3>

<h4>@sukechannnn さん</h4>

<p>表彰コメント：<br />
エンジニアとして様々なチームビルディングや開発手法を試しているだけではなく、ビジネス視点からも方向性を考え、
プロダクトオーナーとしてプロダクトを成長させようとしている姿勢は、まさにこの言葉にぴったりだと思います。</p>

<p><i class="blogicon-twitter"></i> <a href="https://twitter.com/sukechannnn"> sukechannnn (@sukechannnn)</a> , <i class="fa fa-github" aria-hidden="true"></i> <a href="https://github.com/sukechannnn">sukechannnn</a></p>

<h4>@daido1976 さん</h4>

<p>表彰コメント：<br />
分野を問わず新しいことに前向きに挑戦し、気になったことはどんどん質問するのに加え、
育休中のメンバーに代わって、率先してチームを引っ張っている行動力が素晴らしいと思いました。</p>

<p><i class="blogicon-twitter"></i>  <a href="https://twitter.com/daido1976">Daido Shota (@daido1976)</a> , <i class="fa fa-github" aria-hidden="true"></i>  <a href="https://github.com/daido1976"> daido1976</a></p>

<h3>🏆「Be Prepared; 常に来たるべき機会に備えるべし」受賞者</h3>

<h4>@daido1976 さん</h4>

<p>表彰コメント：<br />
自分のキャリアや目指すべき方向を踏まえつつ、常にアンテナを立てて知識を広く持とうとしている姿勢がよいと感じています。
さらに、そうして蓄積したスキルを開発だけではなく、自ら手を挙げ講師をつとめた新卒向け Web 研修にも活かしている点がまさに Be Prepared だと思いました。</p>

<p><i class="blogicon-twitter"></i>  <a href="https://twitter.com/daido1976">Daido Shota (@daido1976)</a> , <i class="fa fa-github" aria-hidden="true"></i>  <a href="https://github.com/daido1976"> daido1976</a></p>

<h4>@namikingsoft さん</h4>

<p>表彰コメント：<br />
Omni Hub の開発において、あまり開発経験がなかったはずの Rust を使いこなしつつ WAF を含めたインフラ構築をしていて、
@namikingsoft さんの強みが発揮される局面でした。また dfplus.io でもパフォーマンス改善でコアな知識を活かすなど、まさにこれまでの準備の賜物だと思います。</p>

<p><i class="fa fa-github" aria-hidden="true"></i> <a href="https://github.com/namikingsoft">namikingsoft</a></p>

<h3>🏆「Share All; 己の知見、試行、失敗、遍く共有すべし」受賞者</h3>

<h4>@masutaka さん</h4>

<p>表彰コメント：<br />
Looker 導入において知見や失敗など社内共有しているほか、そもそも  esa にどう記録すべきかといった、「共有のための知見の共有」にまで配慮しています。
Slack や esa 、Blog への共有はエンジニアのみならず、全社的にプラスの影響を与えていて、まさに共有の神様と言えるでしょう。</p>

<p><i class="blogicon-twitter"></i> <a href="https://twitter.com/masutaka">Takashi Masuda (@masutaka)</a> , <i class="fa fa-github" aria-hidden="true"></i> <a href="https://github.com/masutaka">masutaka</a> , <i class="blogicon-entry"></i> <a href="https://masutaka.net/">Blog</a></p>

<h4>@kogai さん</h4>

<p>表彰コメント：<br />
Shopify 周りでは、社内だけでなく社外に対してのプレゼンスを示しています。また Omni Hub の開発で多忙な中、
社内勉強会 Rust の会では実際の新規事業のプロダクトコードを題材に実践的な知見を共有するなど、その共有力はフィードフォースエンジニアの鑑（かがみ）だと思います。</p>

<p><i class="blogicon-twitter"></i> <a href="https://twitter.com/iamchawan">茶碗 (@iamchawan)</a> ,<i class="fa fa-github" aria-hidden="true"></i> <a href="https://github.com/kogai">kogai</a> , <i class="blogicon-entry"></i> <a href="https://k9bookshelf.com/blogs/development">Blog</a></p>

<h3>🏆「Just Do It; 全力でやりきるべし」受賞者</h3>

<h4>@namikingsoftさん</h4>

<p>表彰コメント：<br />
Omni  Hub リリースまでの道筋をきちんと立ててスケジュール以上の速さで完走して去っていくその姿は、まさに Just Do It でした。</p>

<p><i class="fa fa-github" aria-hidden="true"></i> <a href="https://github.com/namikingsoft">namikingsoft</a></p>

<h2>周囲の賞賛・承認を共有するよい機会に</h2>

<p>以上、延べ9名の受賞者でした。</p>

<p>表彰コメントは、<strong>開発メンバー同士の投票時に自由記述できるコメントがもとになっているので</strong>、周囲からの賞賛・承認の声を全社で共有できるよい機会となっています。</p>

<p>前回に引き続き連続受賞しているメンバーもいますが、投票コメントには毎回違ったエピソードが集まっており、日ごろから継続的に実践をしているからこそ周りのエンジニアの目に留まるのだと感じました。</p>

<p>受賞者のみなさん、おめでとうございました！</p>


こんにちは。人事の今岡と申します。2021年もあっという間に6月ですね。フィードフォースでは先日オンライン納会が開催され、半期に一度の「Engineer’s Principles Award 2021 Summer」の受賞者が発表されました。今回アワードを受賞した開発メンバーと表彰内容をご紹介します。前回の表彰者紹介はコチラdeveloper.feedforce.jpEngineer’s Principles Award とはEngineer’s Principles とは、フィードフォースの開発メンバー向けに現場が主体となって設定した、5つの行動指針です。半期に一度、開発メンバー同士で投票を行い、行動指針の項目ごとに最も体現しているメンバーが選ばれ表彰されます。Engineer’s Principles についてはこちらmedia.feedforce.jp受賞者紹介※表彰コメントは本来社内向けのものであるため一部変更させていただいています。受賞者によって各種アカウントを載せています。🏆「Stay Humble; 常に謙虚であるべし」受賞者@len_prog さん表彰コメント： Len (@len_prog) ,  Blog@katsunn さん表彰コメント：  のもち(@nomo_017)🏆「Be Positive & Proactive; 常に肯定的・主体的であるべし」受賞者@sukechannnn さん表彰コメント：  sukechannnn (@sukechannnn) ,  sukechannnn@daido1976 さん表彰コメント：  Daido Shota (@daido1976) ,    daido1976🏆「Be Prepared; 常に来たるべき機会に備えるべし」受賞者@daido1976 さん表彰コメント：  Daido Shota (@daido1976) ,    daido1976@namikingsoft さん表彰コメント： namikingsoft🏆「Share All; 己の知見、試行、失敗、遍く共有すべし」受賞者@masutaka さん表彰コメント： Takashi Masuda (@masutaka) ,  masutaka ,  Blog@kogai さん表彰コメント： 茶碗 (@iamchawan) , kogai ,  Blog🏆「Just Do It; 全力でやりきるべし」受賞者@namikingsoftさん表彰コメント： namikingsoft周囲の賞賛・承認を共有するよい機会に以上、延べ9名の受賞者でした。表彰コメントは、開発メンバー同士の投票時に自由記述できるコメントがもとになっているので、周囲からの賞賛・承認の声を全社で共有できるよい機会となっています。前回に引き続き連続受賞しているメンバーもいますが、投票コメントには毎回違ったエピソードが集まっており、日ごろから継続的に実践をしているからこそ周りのエンジニアの目に留まるのだと感じました。受賞者のみなさん、おめでとうございました！

【2021年夏】半期に1度の Engineer’s Principles Award 受賞者を紹介します

<p>こんにちは。フィードフォースの <a href="https://ecbooster.jp/">EC Booster</a> チームで開発（主にプロダクトオーナー）をしている <a href="https://twitter.com/sukechannnn">@sukechannnn</a> です。元々ずっとバックエンドエンジニアでしたが、最近プロダクトオーナーをやるようになりました（理由はのちほど！）。</p>

<p>昨年のアドベントカレンダーで <a href="https://developer.feedforce.jp/entry/2020/12/11/172338">半年モブプロしたらチームが大きく成長した話</a> というブログを書いたのですが、2021年3月から <strong>モブプロを取り入れたスクラム開発</strong> をしています。それに伴って、"モブプロ" と "個人タスク⇢レビュー" の両軸で開発するようになりました（<a href="https://prtimes.jp/main/html/rd/p/000000040.000071307.html">先日リリースしたカイゼンカード</a> はスクラムで開発しました）。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F12%2F11%2F172338" title="半年モブプロしたらチームが大きく成長した話 - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p>

<p>今は良い感じに回っていますが、そうなるまでに色々と試行錯誤したので、そこで得た学びをお伝えできればと思います。全員リモートワークで開発するなら、モブプロを取り入れたスクラムはおすすめです！</p>

<ul class="table-of-contents">
    <li><a href="#モブプロの良さと難しさ">モブプロの良さと難しさ</a></li>
    <li><a href="#そうだスクラムしよう">そうだ、スクラムしよう！</a></li>
    <li><a href="#プランニングが終わらない問題">プランニングが終わらない問題</a></li>
    <li><a href="#原因はissue-が散らかっていることだった">原因は「issue が散らかっていること」だった</a></li>
    <li><a href="#issue-をグルーピング優先順位はそれぞれで">issue をグルーピング、優先順位はそれぞれで</a></li>
    <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="モブプロの良さと難しさ">モブプロの良さと難しさ</h2>

<p>モブプロ中心の開発を初めた当初は、以下の利点を感じていました。</p>

<ul>
<li>ドメイン知識の共有がしやすい</li>
<li>コンテキストの共有がしやすい（"何をどう作るか" という議論もしやすい）</li>
<li>レビューが要らない</li>
<li>リモートワークでもさみしくない（だいじ）</li>
</ul>


<p>しばらくモブプロを続ける中で、開発メンバー全員がドメイン知識やフロント〜バックエンド全体の技術的な知識を共有している状態になりました。なので、なにか悩みがあってモブプロで共有すると「わかる〜」となるし、何より単純に仲良くなったと思います（ﾖｼｯ!!）。</p>

<p>一方で、だんだんと <strong>モブプロだけ</strong> の開発が窮屈になってきました。</p>

<ul>
<li>知識の共有が進んできて "全員でやらなくても良くない？" というタスクが増えてきた</li>
<li>個人でじっくり考えた方が良いタスクもあるのが分かった（新しい技術の調査、設計の見直しなど）</li>
</ul>


<p>これはチームが成長したことで出てきた嬉しい悩みなのですが、とはいえ完全にモブプロを辞めるのも上述したメリットを失いそうで怖い...。チーム全員で「今後どう開発していこう？」というのを話し合い、<strong>モブプロを取り入れたスクラム開発</strong> を試してみることにしました。</p>

<h2 id="そうだスクラムしよう">そうだ、スクラムしよう！</h2>

<p>スクラム開発をしようと思ったのは、ストーリーポイント<a href="#f-9495249b" name="fn-9495249b" title="ストーリーポイント：プロダクトバックログ（タスク）を見積もるためにチームが使う単位で、前回の見積もりに対する相対評価を用いる">*1</a>で見積もって <strong>ベロシティ<a href="#f-33d76d3d" name="fn-33d76d3d" title="ベロシティ：スプリントの期間でチームが届けることができる見積もり（ストーリーポイント）の合計のこと">*2</a>を測りたい</strong> という別の目的もありました。</p>

<p>モブプロで開発していると新機能のメイン開発は着実に進んでいくのですが、それ以外の細かいタスク（主に保守系）が見積もりづらい状況で、空いた時間にやるという形になってしまっていました（それ用に時間は設けていましたが）。</p>

<p>モブプロ以外の個人タスクを計画的にやりたい、見積もりもしっかりやりたい、ということで、スクラムを導入することで、<strong>モブプロと個人開発のいいとこ取り</strong> をしようと考えました。</p>

<ul>
<li>新機能開発などのコンテキストの共有が重要なタスクは引き続きモブプロでやる

<ul>
<li>ストーリーポイントで見積もる</li>
</ul>
</li>
<li>それ以外は個人タスクとして各自で進められるように、プランニングでしっかり整理する

<ul>
<li>個人タスクもストーリーポイントで見積もる</li>
</ul>
</li>
<li>全てのタスクをストーリーポイントで見積もるのでベロシティが測れるようになる

<ul>
<li>振り返りで見積もりの精度を上げられる</li>
</ul>
</li>
</ul>


<p>めっちゃ良さそう...そう思っていざやってみたところ、１つ大きな壁にぶち当たってしまいました。</p>

<h2 id="プランニングが終わらない問題">プランニングが終わらない問題</h2>

<p><a href="https://www.shoeisha.co.jp/book/detail/9784798130507">エッセンシャルスクラム</a>にもある通り、１週間のプランニングに２時間以上かけるべきではありません。僕らは「１スプリント=１週間」で回しているため、２時間の予定で始めたプランニングですが、これが終わらない...。最初から何回かは４時間以上かかり、全員ヘトヘトになってしまいました。</p>

<p>モブプロはプランニングが簡単です。全員やることが同じなので、基本的にタスクが直列で繋がっていきます。そのため「今スプリントはここから⇢ここまで」という感じで Sprint Backlog 的なものを決めることができました。</p>

<p>しかし、スクラムの見積もりはもっと横断的なものです。単純に、今取り組んでいるものだけ見れば良いのではなく、これから取り組むものをたくさんある issue から選ぶ必要があります。そう、この <strong>たくさんある issue の中から今スプリントにやるタスクを選ぶこと</strong> に時間がかかってしまうのです。</p>

<p>以前にもスクラム開発を試したことがあるのですが、その時もこれが原因でプランニングがとても大変でした。気にするトピックが多すぎてだんだん何について議論してるか分からなくなり、空中戦になってしまうんですよね...。</p>

<p>その原因は、主に以下の２つでした。</p>

<ul>
<li>バックログの整理/管理に責任を持つ人（プロダクトオーナー<a href="#f-339964b7" name="fn-339964b7" title="プロダクトオーナー：プロダクトバックログの管理をする人で、優先順位を付けることに責任を持つ（１人の人間が務める、委員会ではない）">*3</a>）がいなかった</li>
<li>issue の数と種類が多く、バックログリファインメント<a href="#f-f2375d03" name="fn-f2375d03" title="バックログリファインメント：プランニングの前にプロダクトバックログを見直し、プランニング可能な状態にしておくこと">*4</a>をしても整理しきれなかった</li>
</ul>


<p>プロダクトオーナー不在の問題は、元々それっぽいことをしていた僕が、改めてプロダクトオーナーやりますと手を上げ、バックログ管理の責任を持つことになりました。</p>

<p>それでも、バックログリファインメントが上手く行かない問題は残っていました。リファインメントの概念は理解していて、しっかり時間も取っていたのに、いざプランニングをすると色々な issue を見すぎて伸びてしまう...。過去に何度も直面したこの問題に、改めて取り組むことにしました。</p>

<h2 id="原因はissue-が散らかっていることだった">原因は「issue が散らかっていること」だった</h2>

<p>僕たちが開発している EC Booster は、ショッピング広告の自動運用やデータフィードの更新など、様々なジョブが裏で動いています。そのため、運用作業が日々発生し、運用の中で見つかる例外ケースやバグの修正が多々あります。
また、フロントエンドとバックエンドを全員が開発するため、１つのリポジトリで管理していることもあり、色々な種類の issue が１つのレーンに入り乱れてしまっていました。</p>

<p>そのため、優先順位を付けるのも難しく、また「次スプリントで何をどこまでやるか？」を判断するのが難しくなってしまっていました。</p>

<p>プロダクトバックログを整理しなければ、というのは分かっているのですが、スクラムに関する本やブログには整理の方法は書いてありません。どうやって整理したら分かりやすくなるかな...と考えていたところ、同僚が共有してくれた以下の記事が参考になりました。</p>

<p><a href="https://note.com/gonjyu/n/nd7bf3efa0728">エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。</a></p>

<p>この記事の中で「issueには "種類" がある」と言っていて、issue の種類別に整理された図が載っていました。これだ...！</p>

<h2 id="issue-をグルーピング優先順位はそれぞれで">issue をグルーピング、優先順位はそれぞれで</h2>

<p>上記の記事を参考に、issue を <strong>新機能開発</strong>、<strong>バグ修正/運用改善</strong>、<strong>ライブラリーアップデート</strong> に分けて、それぞれのレーンで優先順位を付けるようにしました。</p>

<p><figure class="figure-image figure-image-fotolife" title="issue をグルーピング、優先順位はそれぞれで"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/sukechannnn/20210526/20210526215948.png" alt="f:id:sukechannnn:20210526215948p:plain" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>issue をグルーピング、優先順位はそれぞれで</figcaption></figure></p>

<p>issue の種類が同じなので、優先順位を付けるのは簡単です。さらに、スプリントバックログに入れるタスクを <strong>新機能開発：運用系 = ６：４</strong> の割合にする、という決めを作りました。さらに、何回かスプリントを回してベロシティも見えてきました。</p>

<p>ここまで情報が揃うと <strong>次のスプリントで何をやるか決める基準</strong> ができてきます。</p>

<p>そもそもの「次のプランニングでどの issue について話すか？」というのも、それぞれのレーンで優先順位が高い issue を６：４のバランスとベロシティを参考に選べるようになりました。<strong>プランニングの前</strong>にプロダクトオーナーが（開発チームと協力しながら）当たりを付けておくことで、プランニングで話すトピックを事前に共有できるようになり、開発メンバーそれぞれが事前に頭を整理しておくこともできるようになりました。</p>

<p>これにより、プランニングがかなりスムーズに進むようになったので、いよいよスクラムが回り始めました。新機能開発はモブプロの同期的な開発で、それ以外のタスクは個人タスク⇢レビューという非同期な開発で進められるようになり、デリバリーの最大化を目指しつつ、個人の稼働率も上げられるようになりました。</p>

<p><figure class="figure-image figure-image-fotolife" title="GitHub Project を使ってタスク管理してる様子...横に長いんですが、情報が整理されてる方が優先順位を付けやすい"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/sukechannnn/20210526/20210526212511.png" alt="f:id:sukechannnn:20210526212511p:plain" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>GitHub Project を使ってタスク管理してる様子...横に長いんですが、情報が整理されてる方が優先順位を付けやすい</figcaption></figure></p>

<h2 id="まとめ">まとめ</h2>

<p>issue をグルーピングしそれぞれで優先順位を付けたことで、プランニングが時間内に収まるようになっただけでなく、プランニングで話すトピックを絞ったことでより深い議論をすることができるようになりました。今は「モブプロを取り入れたスクラム」がとても良い感じに回っています！</p>

<p>↓ EC Booster チームでの「スプリントの回し方」資料を公開しているので、気になった方はぜひ見てみてください！（もっとこうしたら良いよ！という助言などあれば頂けると嬉しいです！）</p>

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTQY639rUAwDDtLfj_c9WbU1E0IlDSFzAbrP-XFCmbg8V_sNKPX_pCvKpiy50CQpS02nXvZnQHBb6JT/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="569" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


<p>こんな感じ開発している EC Booster ですが、ただ今 <strong>バックエンド（Ruby, Rails）が得意なエンジニアを猛烈に必要としています！！！</strong></p>

<p>もしちょっっっとでも興味があれば、 <strong>僕とお話しましょう！</strong> 以下から気軽に応募してください！
<a href="https://open.talentio.com/1/c/feedforce/requisitions/detail/19785">https://open.talentio.com/1/c/feedforce/requisitions/detail/19785</a></p>

<p>最後まで読んでいただき、ありがとうございました！</p>
<div class="footnote">
<p class="footnote"><a href="#fn-9495249b" name="f-9495249b" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://www.ryuzee.com/contents/blog/3716">ストーリーポイント</a>：プロダクトバックログ（タスク）を見積もるためにチームが使う単位で、前回の見積もりに対する相対評価を用いる</span></p>
<p class="footnote"><a href="#fn-33d76d3d" name="f-33d76d3d" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://www.ryuzee.com/contents/blog/4802">ベロシティ</a>：スプリントの期間でチームが届けることができる見積もり（ストーリーポイント）の合計のこと</span></p>
<p class="footnote"><a href="#fn-339964b7" name="f-339964b7" class="footnote-number">*3</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://www.ryuzee.com/contents/blog/7143">プロダクトオーナー</a>：プロダクトバックログの管理をする人で、優先順位を付けることに責任を持つ（１人の人間が務める、委員会ではない）</span></p>
<p class="footnote"><a href="#fn-f2375d03" name="f-f2375d03" class="footnote-number">*4</a><span class="footnote-delimiter">:</span><span class="footnote-text"><a href="https://www.ryuzee.com/contents/blog/5024">バックログリファインメント</a>：プランニングの前にプロダクトバックログを見直し、プランニング可能な状態にしておくこと</span></p>
</div>

こんにちは。フィードフォースの EC Booster チームで開発（主にプロダクトオーナー）をしている @sukechannnn です。元々ずっとバックエンドエンジニアでしたが、最近プロダクトオーナーをやるようになりました（理由はのちほど！）。昨年のアドベントカレンダーで 半年モブプロしたらチームが大きく成長した話 というブログを書いたのですが、2021年3月から モブプロを取り入れたスクラム開発 をしています。それに伴って、"モブプロ" と "個人タスク⇢レビュー" の両軸で開発するようになりました（先日リリースしたカイゼンカード はスクラムで開発しました）。今は良い感じに回っていますが、そうなるまでに色々と試行錯誤したので、そこで得た学びをお伝えできればと思います。全員リモートワークで開発するなら、モブプロを取り入れたスクラムはおすすめです！モブプロの良さと難しさそうだ、スクラムしよう！プランニングが終わらない問題原因は「issue が散らかっていること」だったissue をグルーピング、優先順位はそれぞれでまとめモブプロの良さと難しさモブプロ中心の開発を初めた当初は、以下の利点を感じていました。ドメイン知識の共有がしやすいコンテキストの共有がしやすい（"何をどう作るか" という議論もしやすい）レビューが要らないリモートワークでもさみしくない（だいじ）しばらくモブプロを続ける中で、開発メンバー全員がドメイン知識やフロント〜バックエンド全体の技術的な知識を共有している状態になりました。なので、なにか悩みがあってモブプロで共有すると「わかる〜」となるし、何より単純に仲良くなったと思います（ﾖｼｯ!!）。一方で、だんだんと モブプロだけ の開発が窮屈になってきました。知識の共有が進んできて "全員でやらなくても良くない？" というタスクが増えてきた個人でじっくり考えた方が良いタスクもあるのが分かった（新しい技術の調査、設計の見直しなど）これはチームが成長したことで出てきた嬉しい悩みなのですが、とはいえ完全にモブプロを辞めるのも上述したメリットを失いそうで怖い...。チーム全員で「今後どう開発していこう？」というのを話し合い、モブプロを取り入れたスクラム開発 を試してみることにしました。そうだ、スクラムしよう！スクラム開発をしようと思ったのは、ストーリーポイント*1で見積もって ベロシティ*2を測りたい という別の目的もありました。モブプロで開発していると新機能のメイン開発は着実に進んでいくのですが、それ以外の細かいタスク（主に保守系）が見積もりづらい状況で、空いた時間にやるという形になってしまっていました（それ用に時間は設けていましたが）。モブプロ以外の個人タスクを計画的にやりたい、見積もりもしっかりやりたい、ということで、スクラムを導入することで、モブプロと個人開発のいいとこ取り をしようと考えました。新機能開発などのコンテキストの共有が重要なタスクは引き続きモブプロでやるストーリーポイントで見積もるそれ以外は個人タスクとして各自で進められるように、プランニングでしっかり整理する個人タスクもストーリーポイントで見積もる全てのタスクをストーリーポイントで見積もるのでベロシティが測れるようになる振り返りで見積もりの精度を上げられるめっちゃ良さそう...そう思っていざやってみたところ、１つ大きな壁にぶち当たってしまいました。プランニングが終わらない問題エッセンシャルスクラムにもある通り、１週間のプランニングに２時間以上かけるべきではありません。僕らは「１スプリント=１週間」で回しているため、２時間の予定で始めたプランニングですが、これが終わらない...。最初から何回かは４時間以上かかり、全員ヘトヘトになってしまいました。モブプロはプランニングが簡単です。全員やることが同じなので、基本的にタスクが直列で繋がっていきます。そのため「今スプリントはここから⇢ここまで」という感じで Sprint Backlog 的なものを決めることができました。しかし、スクラムの見積もりはもっと横断的なものです。単純に、今取り組んでいるものだけ見れば良いのではなく、これから取り組むものをたくさんある issue から選ぶ必要があります。そう、この たくさんある issue の中から今スプリントにやるタスクを選ぶこと に時間がかかってしまうのです。以前にもスクラム開発を試したことがあるのですが、その時もこれが原因でプランニングがとても大変でした。気にするトピックが多すぎてだんだん何について議論してるか分からなくなり、空中戦になってしまうんですよね...。その原因は、主に以下の２つでした。バックログの整理/管理に責任を持つ人（プロダクトオーナー*3）がいなかったissue の数と種類が多く、バックログリファインメント*4をしても整理しきれなかったプロダクトオーナー不在の問題は、元々それっぽいことをしていた僕が、改めてプロダクトオーナーやりますと手を上げ、バックログ管理の責任を持つことになりました。それでも、バックログリファインメントが上手く行かない問題は残っていました。リファインメントの概念は理解していて、しっかり時間も取っていたのに、いざプランニングをすると色々な issue を見すぎて伸びてしまう...。過去に何度も直面したこの問題に、改めて取り組むことにしました。原因は「issue が散らかっていること」だった僕たちが開発している EC Booster は、ショッピング広告の自動運用やデータフィードの更新など、様々なジョブが裏で動いています。そのため、運用作業が日々発生し、運用の中で見つかる例外ケースやバグの修正が多々あります。また、フロントエンドとバックエンドを全員が開発するため、１つのリポジトリで管理していることもあり、色々な種類の issue が１つのレーンに入り乱れてしまっていました。そのため、優先順位を付けるのも難しく、また「次スプリントで何をどこまでやるか？」を判断するのが難しくなってしまっていました。プロダクトバックログを整理しなければ、というのは分かっているのですが、スクラムに関する本やブログには整理の方法は書いてありません。どうやって整理したら分かりやすくなるかな...と考えていたところ、同僚が共有してくれた以下の記事が参考になりました。エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。この記事の中で「issueには "種類" がある」と言っていて、issue の種類別に整理された図が載っていました。これだ...！issue をグルーピング、優先順位はそれぞれで上記の記事を参考に、issue を 新機能開発、バグ修正/運用改善、ライブラリーアップデート に分けて、それぞれのレーンで優先順位を付けるようにしました。issue をグルーピング、優先順位はそれぞれでissue の種類が同じなので、優先順位を付けるのは簡単です。さらに、スプリントバックログに入れるタスクを 新機能開発：運用系 = ６：４ の割合にする、という決めを作りました。さらに、何回かスプリントを回してベロシティも見えてきました。ここまで情報が揃うと 次のスプリントで何をやるか決める基準 ができてきます。そもそもの「次のプランニングでどの issue について話すか？」というのも、それぞれのレーンで優先順位が高い issue を６：４のバランスとベロシティを参考に選べるようになりました。プランニングの前にプロダクトオーナーが（開発チームと協力しながら）当たりを付けておくことで、プランニングで話すトピックを事前に共有できるようになり、開発メンバーそれぞれが事前に頭を整理しておくこともできるようになりました。これにより、プランニングがかなりスムーズに進むようになったので、いよいよスクラムが回り始めました。新機能開発はモブプロの同期的な開発で、それ以外のタスクは個人タスク⇢レビューという非同期な開発で進められるようになり、デリバリーの最大化を目指しつつ、個人の稼働率も上げられるようになりました。GitHub Project を使ってタスク管理してる様子...横に長いんですが、情報が整理されてる方が優先順位を付けやすいまとめissue をグルーピングしそれぞれで優先順位を付けたことで、プランニングが時間内に収まるようになっただけでなく、プランニングで話すトピックを絞ったことでより深い議論をすることができるようになりました。今は「モブプロを取り入れたスクラム」がとても良い感じに回っています！↓ EC Booster チームでの「スプリントの回し方」資料を公開しているので、気になった方はぜひ見てみてください！（もっとこうしたら良いよ！という助言などあれば頂けると嬉しいです！）こんな感じ開発している EC Booster ですが、ただ今 バックエンド（Ruby, Rails）が得意なエンジニアを猛烈に必要としています！！！もしちょっっっとでも興味があれば、 僕とお話しましょう！ 以下から気軽に応募してください！https://open.talentio.com/1/c/feedforce/requisitions/detail/19785最後まで読んでいただき、ありがとうございました！*1:ストーリーポイント：プロダクトバックログ（タスク）を見積もるためにチームが使う単位で、前回の見積もりに対する相対評価を用いる*2:ベロシティ：スプリントの期間でチームが届けることができる見積もり（ストーリーポイント）の合計のこと*3:プロダクトオーナー：プロダクトバックログの管理をする人で、優先順位を付けることに責任を持つ（１人の人間が務める、委員会ではない）*4:バックログリファインメント：プランニングの前にプロダクトバックログを見直し、プランニング可能な状態にしておくこと

プランニングの難しさを乗り越えて...スクラム開発が良い感じになった話

<p>こんにちは、<a href="https://twitter.com/meihong">meihong</a> です。</p>

<p>株式会社フィードフォースでは<a href="https://media.feedforce.jp/n/nc7a2e89635eb">定期評価ではなく本人の希望するタイミングで評価を行う制度</a>を導入しています。具体的には、各等級ごとに満たすべき基準・条件、またはスキルがあらかじめ提示されており、それを満たしていれば次の等級に進める制度になります。</p>

<p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmedia.feedforce.jp%2Fn%2Fn222a08fd3e2b" title="半年に1回の評価制度を毎月の評価制度に変えた話｜フィードフォースのnote" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://media.feedforce.jp/n/n222a08fd3e2b">media.feedforce.jp</a></cite></p>

<p>この基準やスキルを私たちはキャリアパスと呼んでいますが、今回、エンジニアのキャリアパスをアップデートしましたのでご紹介したいと思います。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/meihong/20210524/20210524010544.png" alt="f:id:meihong:20210524010544p:plain" width="1200" height="630" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<h2>なぜキャリアパスをアップデートしたのか</h2>

<p>もともとのキャリアパスは<a href="https://media.feedforce.jp/n/n222a08fd3e2b">導入当初に設計されたもの</a>をベースに、マネージャやエンジニア、新規事業向けエンジニアといった個々人の志向に応じて細分化されていました。</p>

<p>これはこれでよくできたものだったのですが、しばらく運用している中でいくつかの課題点を感じるようになってきました。
例えば、</p>

<ul>
<li>志向ごとに分かれすぎていて、志向を横断した動きが想定しづらくなった。</li>
<li>独り立ちと判断される等級であるメンバーとその一つ上のシニアの境界に「見えない高い壁」が存在するようになった。</li>
<li>シニア以上の等級になるとチームや会社を牽引することを求められ、技術をそれ以上深掘りすることに対して会社がどう考えているのかが見えづらくなった。</li>
</ul>


<p>といったところです。</p>

<p>特にキャリアパス全体として、職種問わず等級が上がれば上がるほどチームや会社への影響力が求められる設計になっています。</p>

<p>もちろんエンジニアも全体への影響力は持つべきなのですが、その持ち方は他の職種と異なり、技術力の広さ、深さといった持ち方もあるのではないかと考えるようになりました。</p>

<p>ここで、個人的にはプロフェッショナルとしてのスキルは体積であり、その底面積はスキルの幅広さだと考えています。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/meihong/20210523/20210523235853.png" alt="f:id:meihong:20210523235853p:plain" width="1200" height="731" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>極端に底面積が狭いのはさすがに現時点では厳しいとは思いますが、</p>

<ul>
<li>底面積がそれなりである代わりに高さ(= 深さ)がある</li>
<li>底面積が広い (= 引き出しが多い) 反面高さはそこまででもない</li>
</ul>


<p>の両者は体積という意味では同じはずです。</p>

<p><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/meihong/20210524/20210524000640.png" alt="f:id:meihong:20210524000640p:plain" width="1200" height="576" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></p>

<p>この両者が共存できる余地が欲しいと考えていました。</p>

<p>そんな中、弊社デザイナーのキャリアパスがアップデートされました。その中でも目を引いたのは、必須スキルと専門スキルという考え方です。</p>

<p>必須スキルはデザイナーとして必ず持っていて欲しいスキルである一方、専門スキルは本人の志向、特性に応じてピックアップできるというもので、大学の専攻を思い出す建て付けでした。</p>

<p><s>これをパクる</s>これにインスパイアされて、エンジニアのキャリアパスもアップデートすることにしました。</p>

<h2>どのように更新したのか</h2>

<p>結果から先にお伝えしておくと、大まかに以下のような方向性に改訂しました。</p>

<ul>
<li>志向ごとのキャリアパスは止めた。</li>
<li>旧来の「志向」を専門スキルに分解し、専門スキルの組み合わせで個々人の志向・特性を表現できるようにした。</li>
<li>等級が上がれば上がるほど満たすべき専門スキルの最低数が増えるようにした。</li>
</ul>


<p>その結果として、例えば</p>

<ul>
<li>バックエンドエンジニアに特化</li>
<li>フルスタックエンジニア</li>
<li>フルスタックな知識をベースに事業の 0 → 1 フェイズに参画できるエンジニア</li>
<li>カスタマーサクセスエンジニア</li>
<li>アジャイルコーチ</li>
</ul>


<p>といった、実際に社内に存在している各エンジニアの志向や得意なポイントを表現できるようになりました。</p>

<h2>産みの苦しみ</h2>

<p>ここに至るまでには色々な葛藤がありました。
社内の esa にキャリアパスを更新したいと宣言はしたものの、社内のエンジニア個々人の顔を思い浮かべつつ何を専門スキルとして設定するかを考えると想像以上に難しい問題だということに気付きました。</p>

<h3>必須スキルと専門スキル</h3>

<p>そもそも必須スキルと専門スキルとは何か、そこの定義から考えることにしました。</p>

<p>必須スキルとは文字通り、全てのエンジニアが共通に要求されるスキルセットのことです。どちらかというと「バックエンド」「フロントエンド」といった用語で定義されるスキルセットというよりも「フィードフォースに所属するエンジニアとしての振る舞い方」ではないでしょうか。</p>

<p>そう考えながら改訂前のキャリアパスを改めて眺めていると、改訂前のキャリアパスはその振る舞いを定義していることに気付きました。その結果、改訂前のキャリアパスが必須スキルのベースとなりました。</p>

<p>そうです、キャリアパスの改訂によって、より要求水準が上がったとも言えます。</p>

<p>一方、専門スキルは、本人の得意分野、志向、特性を定義するものです。
その志向・方向性で貢献するのであれば、各等級ごとにどの水準の成果を出すべきか。それを定義するものが専門スキルになります。</p>

<h3>専門スキルとはどうあるべきか</h3>

<p>本人の志向を定義するものが専門スキルと説明しましたが、例えばカスタマーサクセスエンジニアやエンジニアリングマネージャといった職種にしてもエンジニアの延長である以上はエンジニアとしての「共通言語」を身につけているべきです。</p>

<p>その「共通言語」とは、例えば設計力であったり、フロントエンドやバックエンドのスキルが該当します。</p>

<p>こういった知識を前提として例えば事業開発であったりチームビルディングを行うべきで、これらの知識がなければエンジニアとの「共通言語」を持っていないと判断せざるを得ません。</p>

<p>一方で、「フロントエンド力」と「バックエンド力」が同じくらい強いエンジニアというのは SSR エンジニアで、そうそう市場には存在しません。そこで、フルスタックとはいえどこかの分野に軸足を置くことができる制度というのも必須に感じました。</p>

<p>ただ、ここの軸足とはあくまでも「フロントエンド」「バックエンド」「インフラ」といった区分けで、エンジニアとしてコードを書き続ける選択をするのであれば、フロントエンド/バックエンド/インフラといった区分に関係なく設計力・実装力が担保されているべきでしょう。</p>

<h3>17 の専門スキル</h3>

<p>ここのバランス感が非常に難しい点でしたが、これを元に 17 の専門スキルを定義しました。
ただし、17 の専門スキルは完全に独立しているわけではなく、以下 6 つは本人の志向を定義するものとして、必ずどれか一つが必須選択としました。</p>

<ul>
<li>バックエンド</li>
<li>フロントエンド</li>
<li>データベース</li>
<li>基盤</li>
<li>カスタマーサクセス</li>
<li>組織支援</li>
</ul>


<p>さらに、上記のうち以下 4 つを選択した場合は「実装・設計」と呼ばれるスキルが必須となります。</p>

<ul>
<li>バックエンド</li>
<li>フロントエンド</li>
<li>データベース</li>
<li>基盤</li>
</ul>


<p>これにより、コードを書き続けるのであればただコードを書くだけでなく、実装力・設計力が要求される建て付けを実現しました。</p>

<p>また、詳細は省きますが、さらにいくつかの例外を設置することで、「全ての分野で等しく強い SSR なフルスタックエンジニア」が求められないようにしています。</p>

<hr />

<p>様々なエッジケースを考慮したせいでちょっと複雑になった感の否めない新しいキャリアパスですが、以前のものと比べるとその分より柔軟なものになったと思います。</p>

<p>今回は敢えて詳細を省きましたが、<a href="https://engineers.recruit.feedforce.jp/#entry">ご興味をお持ちいただけたら是非カジュアル面談でねっちょりとご説明します</a>！</p>


こんにちは、meihong です。株式会社フィードフォースでは定期評価ではなく本人の希望するタイミングで評価を行う制度を導入しています。具体的には、各等級ごとに満たすべき基準・条件、またはスキルがあらかじめ提示されており、それを満たしていれば次の等級に進める制度になります。media.feedforce.jpこの基準やスキルを私たちはキャリアパスと呼んでいますが、今回、エンジニアのキャリアパスをアップデートしましたのでご紹介したいと思います。なぜキャリアパスをアップデートしたのかもともとのキャリアパスは導入当初に設計されたものをベースに、マネージャやエンジニア、新規事業向けエンジニアといった個々人の志向に応じて細分化されていました。これはこれでよくできたものだったのですが、しばらく運用している中でいくつかの課題点を感じるようになってきました。例えば、志向ごとに分かれすぎていて、志向を横断した動きが想定しづらくなった。独り立ちと判断される等級であるメンバーとその一つ上のシニアの境界に「見えない高い壁」が存在するようになった。シニア以上の等級になるとチームや会社を牽引することを求められ、技術をそれ以上深掘りすることに対して会社がどう考えているのかが見えづらくなった。といったところです。特にキャリアパス全体として、職種問わず等級が上がれば上がるほどチームや会社への影響力が求められる設計になっています。もちろんエンジニアも全体への影響力は持つべきなのですが、その持ち方は他の職種と異なり、技術力の広さ、深さといった持ち方もあるのではないかと考えるようになりました。ここで、個人的にはプロフェッショナルとしてのスキルは体積であり、その底面積はスキルの幅広さだと考えています。極端に底面積が狭いのはさすがに現時点では厳しいとは思いますが、底面積がそれなりである代わりに高さ(= 深さ)がある底面積が広い (= 引き出しが多い) 反面高さはそこまででもないの両者は体積という意味では同じはずです。この両者が共存できる余地が欲しいと考えていました。そんな中、弊社デザイナーのキャリアパスがアップデートされました。その中でも目を引いたのは、必須スキルと専門スキルという考え方です。必須スキルはデザイナーとして必ず持っていて欲しいスキルである一方、専門スキルは本人の志向、特性に応じてピックアップできるというもので、大学の専攻を思い出す建て付けでした。これをパクるこれにインスパイアされて、エンジニアのキャリアパスもアップデートすることにしました。どのように更新したのか結果から先にお伝えしておくと、大まかに以下のような方向性に改訂しました。志向ごとのキャリアパスは止めた。旧来の「志向」を専門スキルに分解し、専門スキルの組み合わせで個々人の志向・特性を表現できるようにした。等級が上がれば上がるほど満たすべき専門スキルの最低数が増えるようにした。その結果として、例えばバックエンドエンジニアに特化フルスタックエンジニアフルスタックな知識をベースに事業の 0 → 1 フェイズに参画できるエンジニアカスタマーサクセスエンジニアアジャイルコーチといった、実際に社内に存在している各エンジニアの志向や得意なポイントを表現できるようになりました。産みの苦しみここに至るまでには色々な葛藤がありました。社内の esa にキャリアパスを更新したいと宣言はしたものの、社内のエンジニア個々人の顔を思い浮かべつつ何を専門スキルとして設定するかを考えると想像以上に難しい問題だということに気付きました。必須スキルと専門スキルそもそも必須スキルと専門スキルとは何か、そこの定義から考えることにしました。必須スキルとは文字通り、全てのエンジニアが共通に要求されるスキルセットのことです。どちらかというと「バックエンド」「フロントエンド」といった用語で定義されるスキルセットというよりも「フィードフォースに所属するエンジニアとしての振る舞い方」ではないでしょうか。そう考えながら改訂前のキャリアパスを改めて眺めていると、改訂前のキャリアパスはその振る舞いを定義していることに気付きました。その結果、改訂前のキャリアパスが必須スキルのベースとなりました。そうです、キャリアパスの改訂によって、より要求水準が上がったとも言えます。一方、専門スキルは、本人の得意分野、志向、特性を定義するものです。その志向・方向性で貢献するのであれば、各等級ごとにどの水準の成果を出すべきか。それを定義するものが専門スキルになります。専門スキルとはどうあるべきか本人の志向を定義するものが専門スキルと説明しましたが、例えばカスタマーサクセスエンジニアやエンジニアリングマネージャといった職種にしてもエンジニアの延長である以上はエンジニアとしての「共通言語」を身につけているべきです。その「共通言語」とは、例えば設計力であったり、フロントエンドやバックエンドのスキルが該当します。こういった知識を前提として例えば事業開発であったりチームビルディングを行うべきで、これらの知識がなければエンジニアとの「共通言語」を持っていないと判断せざるを得ません。一方で、「フロントエンド力」と「バックエンド力」が同じくらい強いエンジニアというのは SSR エンジニアで、そうそう市場には存在しません。そこで、フルスタックとはいえどこかの分野に軸足を置くことができる制度というのも必須に感じました。ただ、ここの軸足とはあくまでも「フロントエンド」「バックエンド」「インフラ」といった区分けで、エンジニアとしてコードを書き続ける選択をするのであれば、フロントエンド/バックエンド/インフラといった区分に関係なく設計力・実装力が担保されているべきでしょう。17 の専門スキルここのバランス感が非常に難しい点でしたが、これを元に 17 の専門スキルを定義しました。ただし、17 の専門スキルは完全に独立しているわけではなく、以下 6 つは本人の志向を定義するものとして、必ずどれか一つが必須選択としました。バックエンドフロントエンドデータベース基盤カスタマーサクセス組織支援さらに、上記のうち以下 4 つを選択した場合は「実装・設計」と呼ばれるスキルが必須となります。バックエンドフロントエンドデータベース基盤これにより、コードを書き続けるのであればただコードを書くだけでなく、実装力・設計力が要求される建て付けを実現しました。また、詳細は省きますが、さらにいくつかの例外を設置することで、「全ての分野で等しく強い SSR なフルスタックエンジニア」が求められないようにしています。様々なエッジケースを考慮したせいでちょっと複雑になった感の否めない新しいキャリアパスですが、以前のものと比べるとその分より柔軟なものになったと思います。今回は敢えて詳細を省きましたが、ご興味をお持ちいただけたら是非カジュアル面談でねっちょりとご説明します！