BigQueryのシャーディングされたテーブルをOpenSearchへ連携する方法

皆さん，こんにちは！最近は検索エンジニアとしての仕事がメインの柏木（@asteriam）です．

はじめに

今回はTips的な記事になります．背景としては，アプリの検索ログをBigQueryに溜めているのですが，それを検索エンジンのサジェスト機能で使用するために，BigQueryからAmazon OpenSearch Serviceへデータ連携を実施しました．その際にBigQueryのシャーディングされたテーブルをどのようにして連携したかというお話になります．

検索システムのデータ基盤構築に関する過去のブログでも紹介していますが，我々はGlueを用いて検索エンジン（OpenSearch）へのデータ連携を行っています．今回はGlueを用いる点は同じですが，データソースはBigQuery，ターゲットソースをOpenSearchとしてデータ連携しました．

今回は以下の内容を紹介していこうと思います．

• BigQuery→OpenSearch連携の概要
• BigQueryのシャーディングされたテーブルを連携する方法

---

目次

---

BigQuery→OpenSearch連携の概要

今回紹介するデータ連携は至ってシンプルです．

下図にあるように，BigQueryにある検索ログをGlueでExtractし，検索エンジンであるOpenSearchへLoadする流れになります．

• データソース：BigQuery
• ターゲットソース：OpenSearch

データパイプラインの概略図

Glueには，BigQueryに接続するためのコネクターが用意されており，簡単に連携ができるようになっています．接続方法の手順はクラスメソッドさんのブログが参考になるので，そちらに譲ろうと思います．（コネクターをSubscribeする画面にも英語ですが，説明が記載されています）

参考：AWS Glue Connector for Google BigQueryを使ってBigQueryからS3にデータを転送する

データソース（BigQuery）の設定では，BigQueryのプロジェクトIDや連携したいテーブルIDなどの情報が必要になります．一方で，ターゲットソース（OpenSearch）の設定では，インデックス名やエンドポイント名などが必要になります．

ここで，連携したいBigQueryのテーブルは日付でシャーディングされており，そういったテーブルをどうやって連携するかが問題になります．

BigQueryのシャーディングされたテーブルを連携する方法

日付でシャーディングされたテーブルとは，下図のようにtable suffixが日付になっていて，日ごとにインクリメントされた形式のテーブルのことを言います．

シャーディングされたテーブル

このようなテーブルを連携したい場合にどうすればいいか？

Connection optionsのKeyにqueryを使う

BigQueryコネクターのConnection optionsに幾つかの設定が必要になりますが，そのうちの一つとして，queryというkeyを使うことでシャーディングされたテーブルの連携に対応することができます！

参考：Push down queries when using the Google BigQuery Connector for AWS Glue

下図はGlue StudioでのBigQueryコネクターの設定画面になります．

BigQueryコネクターで設定する内容は4つになります．

• materializationDataset: <BigQuery側で連携用に一時的に作成するデータセット名>
• parentProject: <プロジェクトID>
• viewsEnabled: <ビューの許可>
• query: <データ抽出するためのクエリ>

Glue Studio: BigQueryコネクターの設定

queryには実行したいクエリをそのまま入力します．例えば，現在から30日前までの検索ワードとそのカウント数を集計したデータを抽出したい場合は，以下のような感じになります．

SELECT
    word,
    count(word) AS word_count
FROM `hogefuga.search_events_*`  # 検索ログが入ったテーブル
WHERE 0 = 0
AND _TABLE_SUFFIX >= FORMAT_DATE('%E4Y%m%d', CURRENT_DATE('Asia/Tokyo') - 30 )
GROUP BY word

ただし，注意点があります．

• materializationDatasetに設定するデータセットは予めBigQueryに作成
  • 試行錯誤の結果，データセットがない場合にGlueは勝手に作ってくれず，エラーになってしまうので，予め作成しておく必要があります
  • 加えて，このデータセット配下に一時的に作られるテーブルに対するwrite権限が必要で，それがないとエラーになります

最後に，OpenSearch側の設定も載せておきます．

• path: <インデックス名>
• es.node: <エンドポイント名>

Glue Studio: BigQueryコネクターの設定

おわりに

単一のテーブルは簡単に連携できたのですが，シャーディングされたテーブルを連携する時にハマってしまったので，今回のTipsが誰かの役に立てば幸いです！GCP側の権限などはハマりポイントかなと思うので，試しながら試行してみて下さい．

検索ログが連携できたことで，サジェスト機能も前進しているので，これからも検索エンジンの改良を進めて行こうと思っています！

最後に，コネヒトではプロダクトを成長させたいMLエンジニアを募集しています！！（切実に募集しています！）
もっと話を聞いてみたい方や，少しでも興味を持たれた方は，ぜひ一度カジュアルにお話させてもらえると嬉しいです．（僕宛@asteriamにTwitterDM経由でご連絡いただいてもOKです！）

www.wantedly.com

また，コネヒトにおける機械学習関連業務の紹介資料も公開していますので，こちらも是非見て下さい！！

tech.connehito.com

参考

• AWS Glue Connector for Google BigQueryを使ってBigQueryからS3にデータを転送する
• Push down queries when using the Google BigQuery Connector for AWS Glue

スキルマップを使ったチームビルディング

こんにちは！エンジニアの富田です。先月末に開催したスキルマップを使ったチームビルディングがとても良かったので、内容を紹介したいと思います。

なぜやろうと思ったのか

前提として私が所属しているプロダクト開発チームは以下の構成です。

• PdM 1名
• デザイナー 2名
• エンジニア 4名

ご覧の通り職能横断型のチーム構成になっており、チームとして4ヶ月ほどプロダクト開発を進めているのですが、お互いのことをあまり知らないなと感じることがありました。もちろん自己紹介をしたり、スクラムの朝会でちょっとした小話をしているのですが、なかなか自分の得意なこと、苦手なことを開示する機会がありませんでした。

自己開示することで、自分のことを知ってもらったり、周りのことをより知ることができるので、結果としてパフォーマンスやモチベーションが向上するのではないかと考えました。何かしらチームビルディングのワークをやりたいと考えていたものの、稼働時間の限られている業務委託メンバーも一定数いるため、「作業時間を奪ってしまうかもしれない？」という懸念からなかなか一歩踏み出せませんでした。

そんな困っていた中、弊社のデザイナーチームが「スキルマップは自己紹介、リモート前提の業務設計ですごく役立つよ」と話していて、これは簡単で面白そうだと思い、スキルマップの進め方及びテンプレートを教えてもらい、スキルマップを使ったワークを試す運びとなりました。

どんなことをやったのか

好き・嫌い、できること・できないこと、を軸にして、付箋を貼ってチームメンバーで共有するというものです。それぞれ発表した後、チームの他のメンバーが「得意そうだとと思っていること」「苦手そうだと思っていること」を付箋に書いていって、認知のずれを確認し合うワークです。

スキルマップのテンプレート

テンプレートは上記の通り Miro で作成しており、3つのステップに大別されます。

1.(事前準備)自分のスキルを黄色の付箋に書いて貼ってみよう

• ハードスキルでもソフトスキルでもOK
  • ハードスキル：Swift、PHP、Photoshop・Notionを使ったタスク管理
  • ソフトスキル：ファシリテーション・コミュニケーション、誰とでも仲良くなれる

自分のスキルを付箋に記入して、好き・嫌い、できること・できないこと、を軸にマッピングします。 一見簡単そうに見えますが、自分のスキルと聞かれてパッと思いつく人は少ないのではないでしょうか。 実際、事前準備なしにワークをしたところ、悩んでいるメンバーも多く、付箋を書くのに15分ほどかかりました。 ですので、スキルに関しては事前に記入してもらうと、効率的にワークを進められるのでオススメです。

2.参加メンバーに自分のスキルを発表します

• 1人5分程度で発表します。ポジティブな話題の方が共有しやすいため、右上の得意なところから時計回りに話していくと良いです
• メンバーはチャットなどで感想を書いたり、質問をしてみましょう
• また、周囲から見て得意そうなこと・苦手そうなことを付箋に書いていきます

マッピングした内容を各自共有します。周囲からのコメントは周りにどう思われているか知る良い機会ですので、ぜひ感想や質問、または周囲から見て得意そうなこと、苦手そうなことを付箋に記入してみてください。

3.周囲から見て得意そうなこと・苦手そうなことをマッピングします

• 他のメンバーの認知と自分の認知の違いを見てみましょう
• ギャップがある時はなぜそこにマッピングしたかを議論してみましょう

周囲から記入してもらった得意そうなこと、苦手そうなことをマッピングします。周りから見て得意そうなことが自分にとっては実は苦手だったまたはその逆も然り。マッピングすることで暗黙知のギャップを埋めることができます。

結果はどうだったのか

実際にスキルマップを使ってワークを試してみました！

実際に試したスキルマップの一部

メンバーのコメントをいくつか抜粋します。

• デザイナーだけどフロントエンドの実装もしたい！
• 周りからは取捨選択得意そうに見えていたけど、ちょっと苦手に感じていた
• グラフィックデザインはできるんだけど、あんまり好きではない
• ファシリテーションが苦手なんだけど、周りは得意だと思ってくれていた
• コンテンツディレクションをしているけど、コンテンツ制作が若干苦手

結果として意外な発見も多く、認知のギャップを解消できました。今回のように職能が異なるメンバーが混在したメンバー編成時に試すと効果が高いと思います。

最後に

スキルマップを使って「得意そうだと思っていること」、「苦手そうだと思っていること」の認知のギャップを埋めるワークを紹介しました。

当初の「お互いのことをあまり知らない」という課題感に対して、一定の暗黙知を解消できたように思います。同じような課題感をお持ちでしたら、コストも低く、試しやすいワークになっていますのでお試しください。

直近ではドラッカー風エクササイズも試していますので、よろしければご覧ください。 tech.connehito.com

コネヒトでは一緒に働く仲間を募集しています！ そして興味持っていただけた方は気軽にご連絡ください！

www.wantedly.com

Character filterを用いたアルファベットの大文字小文字対応によるゼロ件ヒット改善

皆さん，こんにちは！最近は検索エンジニアとしての仕事がメインの柏木（@asteriam）です．

直近は，検索基盤が整ってきたので，検索エンジンの精度改善の取り組みを行っています．その一環としてゼロ件ヒットの削減に努めていて，今回は「アルファベットの大文字小文字」に対応した話になります．

はじめに

改めて，今回は「検索クエリにおけるアルファベットの大文字小文字に依らない検索結果」を出すための取り組みとして，Character filterを用いて検索クエリを正規化することでこの問題に対処した内容になります．

今回は以下の内容を紹介していこうと思います．

• 取り組みの背景と課題
• Character filterを用いた正規化
• 対応後のゼロ件ヒットの推移

※ 検索エンジンとしてAmazon OpenSearch Serviceを活用しています．これはElasticsearchから派生したOSSの検索エンジンであるOpenSearchのマネージドサービスになります．

---

目次

---

取り組みの背景と課題

背景

私たちのチームでは検索結果の改善を行うためにゼロ件ヒットのログを収集しています．僕はそれを毎日眺めているのですが，その中でドキュメントとして存在してそうなワードが含まれているのに何故かゼロ件ヒットとして検索されている回数が多いものがあったため，調査したのが始まりです．

実際のゼロ件ヒットワードの一例ですが，「hpvワクチン」というワードがありました．小文字では検索結果が0件でしたが，これを大文字の「HPVワクチン」で検索するとドキュメントが数十件と返ってくることを確認しました．

このように幾つかのワードで，アルファベットの大文字小文字の違いによるゼロ件ヒットを確認し，中にはゼロ件ヒットワードとして，2~3週間で数百件以上検索されているものもあったので，この問題の解決に当たろうと思いました．

課題

課題としては明確で，アルファベットの大文字と小文字の違いだけで検索結果が変わってしまいユーザーの検索体験がマイナスになっている ということです．そもそもドキュメントが存在しない場合と違って，僕たちのドメインでは普通に使われうるワードでゼロ件ヒットしてしまうことは，検索に対する期待も下がってしまいますし，アプリからの離脱も発生します．

また，この問題は登録しているユーザー辞書による影響もあり，以前からユーザー辞書の整理は必要だと考えられていたため，そこをまとめて整理する良い機会でもありました．

Character filterを用いた正規化

前提理解

この問題を解決するためには，ElasticsearchにおけるAnalyzerの処理の流れを理解する必要があります．

1. 0個以上のCharacter filters
2. 1個かつ必須のTokenizer
3. 0個以上のToken filters

参考：Anatomy of an analyzer

こちらの図がわかりやすいので，引用（Elasticsearch のアナライザをカスタマイズする）させて貰います．

引用：Elasticsearch のアナライザをカスタマイズする

上図では，それぞれどのような動きをしているかというと，

1. HTML要素を除去するCharacter filter
2. 空白で分割するTokenizer
3. 大文字を小文字に変換するToken filter

となっています．

ここで，ユーザー辞書が適用されるのは2番目のTokenizerを行う部分になります．我々が元々設定していたAnalyzerの定義では，Character filterとしてicu_normalizerのみを適用してました．Token filterはTokenizerの後に適用されるため，ユーザー辞書に基づいたトークナイズが優先され，アルファベットの大文字ワードをToken filterで小文字化しても別ワードとして処理される状況でした．このためシノニム辞書を用意していても別ワードとして処理されます（大文字と小文字は別物になってしまいます）．

対応方法

この解決方法としては2種類あると思います．

1. Character filterを使ってアルファベットの大文字を小文字にする（Character filterによる正規化）
2. API側で検索エンジンに入れる前にアルファベットの大文字を小文字にする

そして，辞書に登録するワードは全て小文字で登録する．

今回は，検索されたワードは検索エンジン側で処理が全て完結するようにしたかったため，1番目の方法で対応することにしました．

処理の追加自体はとても簡単で，下のサンプルコードのように，char_filterに新しくフィルターを追加し，そのmappingsに愚直に大文字と小文字の変換を入れるだけになります．

# sample
{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_analyzer": {
          "tokenizer": "standard",
          "char_filter": [
            "alphabet_mappings_filter"
          ]
        }
      },
      "char_filter": {
        "alphabet_mappings_filter": {
          "type": "mapping",
          "mappings": [
            "A => a",
            "B => b",
            "C => c",
            "D => d",
            "E => e",
            "F => f",
            "G => g",
            "H => h",
            "I => i",
            "J => j",
            "K => k",
            "L => l",
            "M => m",
            "N => n",
            "O => o",
            "P => p",
            "Q => q",
            "R => r",
            "S => s",
            "T => t",
            "U => u",
            "V => v",
            "W => w",
            "X => x",
            "Y => y",
            "Z => z"
          ]
        }
      }
    }
  }
}

あとは，ユーザー辞書とシノニム辞書に登録されているアルファベットを全て小文字に変更することで，大文字と小文字の区別なく検索結果として同じ結果が返ってくるようになります．

1つ注意事項として，今回のようにAnalyzerの定義が変更されて，それに伴って辞書の更新が入る場合は都度インデックスの再作成が必要になるので注意が必要です．

事象としては，辞書が変更されたことにより，元々インデックス化されていたトークンとの整合性が取れずに何もヒットしない状態でした．改めてインデックスを作り替えることで，トークンが正しい状態でインデックス化された状態になりヒットするようになります．

対応後のゼロ件ヒット率の推移

ゼロ件ヒット率の推移を見てみると，下図から今回の対応前後で数値が減少していることがわかります．実際の割合で言うと，減少率は1%以下ではあるものの，検索数ベースだと数百件は減っていることになります．

ここで，ゼロ件ヒット率=全検索数のうち検索結果が0件であった検索数の割合と定義しています．

ゼロ件ヒット率

今回の施策では，他の「検索利用率・1訪問あたり平均検索回数」といったメトリクスには影響は見られませんでした．

そもそもゼロ件ヒットの検索数は全検索数のうち数%しかないため，改善できる幅はそれほど大きくなく，減少率で言うと大きな改善にはなっていませんが，ゼロ件ヒットの上位ワードは今回の対応で改善できたので，よりニーズのあるワードへの対策は実施できたのと，ドキュメントが存在しているのにヒットしないのはユーザー体験にも大きく影響するので，実施したことに価値はあったと考えています．

おわりに

今回はCharacter filterを用いてアルファベットの大文字小文字対応（Character filterによる正規化）を行いました．その結果としてゼロ件ヒットの削減に貢献できました！

今回の改善でも実感しましたが，トークナイズに影響を与える辞書整備は重要で，その整備がまだまだ十分行えていないので，ガッと進めて行きたいと思っています．

また，捨て仮名/中点対応，ひらがな/漢字対応なども今後進めて行く予定です！

千里の道も一歩からということでゼロ件ヒット削減に向けて，今回の取り組みや辞書更新，今後の取り組みを通して，小さな積み重ねでユーザー体験の向上目指して改善して行きます！

最後に，コネヒトではプロダクトを成長させたいMLエンジニアを募集しています！！（切実に募集しています！）
もっと話を聞いてみたい方や，少しでも興味を持たれた方は，ぜひ一度カジュアルにお話させてもらえると嬉しいです．（僕宛@asteriamにTwitterDM経由でご連絡いただいてもOKです！）

www.wantedly.com

また，コネヒトにおける機械学習関連業務の紹介資料も公開していますので，こちらも是非見て下さい！！

tech.connehito.com

参考

• Anatomy of an analyzer
• Elasticsearch のアナライザをカスタマイズする

ドラッカー風エクササイズをやってみました!

こんにちは。コネヒトに8月に入社し、サーバーサイドエンジニアをしている高橋です。

今回は私自身のチームジョインや、更なる新メンバーのジョインもあったので、「お互いを理解し期待をすり合わせる」ことを目的に「ドラッカー風エクササイズ」を開催しました！ オンラインでも開催できるように今回はmiroを使って実施したので、ご興味ある方はぜひご覧ください。

目的・背景

• メンバーのスキルや経験、価値観、期待値などをお互いに理解し、期待をすり合わせる

→背景は新メンバージョインに伴いチーム人数が多くなったので、チーム内でお互いの得意なことや期待値を把握し、理解促進を図りたいと思ったからです。

ドラッカー風エクササイズとは

ドラッカー風エクササイズとは、アジャイルサムライの著者Jonathan Rasmusson(ジョナサン・ラスマセン)が名付けたチームビルディングのことです。 4つの質問に全員が答えることで、相互理解の促進と期待の擦り合わせという効果があります。

ワークの進め方

今回は9人で実施をしたので進め方を工夫しました。

• 事前にワーク内容を伝え、自己開示パートの3つの質問はある程度考えてきてもらう
• タイムマネジメントをしっかりと行う

今回は90分の枠をとって実施をし、以下のような流れで行いました。

1. 導入 (5分)
2. ワーク内容の説明 (5分)
3. チェックイン (2分)

4. ワーク (60分)

   自己開示パート 以下の3つの質問に回答してもらい、本人から説明していただきます。

   • 自分は何が得意か
   • 自分はどういう風に仕事をするか

   • 自分が大切に思う価値は何か

     

   各質問を最大3つに絞ることで自分の中でも特に大切にしている価値観が整理することができます。

   期待値パート

   • 自分がメンバーから期待されていると思うこと この質問は先入観が生まれないよう紹介はせずに以下の回答をそれぞれが他のメンバーに書いていいきます。

   • 自分以外のメンバーがその人に期待していること その後ファシリテーターから上記2点を紹介し、なぜこの人にこう書いたか、どういった背景で書いたのか、など深掘りを一人ずつしていきます。

   • ファシリテーターが一人ずつ発表

5. 感想一人一言 (10分)

また今回急に参加が難しくなってしまったメンバーに対しては、事前に付箋を記入してもらい、他のメンバー同様に期待値なども欠席者のところに貼るようしました。そして後日ワークの動画を共有しました。 ワークの様子を動画で正確に残せるのはオンライン開催の良いところですね。

注意点

目的は期待をすり合わせることになるので、ワークをする上で以下の2点留意しましょう！

• メンバーを否定しない
• 期待されていることは鵜呑みにしない→絶対にやらなくてはいけないということではない

私は過去にドラッカー風エクササイズを行い、自分が思う期待値とメンバーからの期待値に違いがあり少しマイナスな印象を抱いてしまったので、あくまで意見として捉えることが大事です。

感想

メンバーのことを知れるというのはもちろんですが、自分の価値観を整理できるいい機会になったと強く感じることができました！ 私は一児の母ということもあり、メンバーからの期待してることに「当事者ならではの視点」という付箋が多く自分がどう期待されているか具体的に知ることができました。 また「遠慮しないでもいいよ」というような付箋もあり、もっとこうしていいんだというこれからの動き方にもいい変化が出てきそうと感じました。

改善点

• 期待値が現状行っていることの延長線上が多い
  • こうしたらよかったんじゃないか？みたいな課題に対するアクションもセットで書けると良さそう
• 自己開示パートの時間が少し短かったので、メンバーの価値観を知り切れなかった
• 自己開示パートは事前記入しておいてもらった方がスムーズだったかも
• チームとして何を目指すかなどが話せなかったこと

メンバーからの感想も一部挙げておきます。

• 自分で思いつかなかったポイントで期待されている側面は学びになりました！
• 改めて自分が大事にしていることってなんだっけ？を見つめ直すいい機会になりました！
• 各メンバーがそれぞれ、自分に対してもしくは他人に対して感じるものを言語化したことで、自己認識・他者認識の再構築ができて良かった。
• 新メンバー参画の際にまたやりたい！
• 定期的にやりたい

まとめ

今回のドラッカー風エクササイズを通じてメンバーからはポジティブな意見が多く、開催してよかったなと思っています。人の価値観、モチベーションなどは変化していくものでもあると思うので、定期的にチームビルディングを開催していきたいです。 すごく良いチームであるのでもっともっとお互いに刺激し合えるチームになっていけたらと思っています。

過去のチームビルディングのブログ記事↓ tech.connehito.com

tech.connehito.com

コネヒトでは一緒に働く仲間を募集しています！ そして興味持っていただけた方は気軽にご連絡ください！ https://www.wantedly.com/companies/connehito/projects

「スマイル制度」を利用してBabelのスポンサーになりました

こんにちは、エンジニアの富田です！ 今回は社内制度を利用して、Babelのスポンサーをした事例を紹介したいと思います。

Babelが資金難であることを知った

時は遡ること1年前ですが、当時以下の記事からBabelが資金難で困っていることを知りました。

www.publickey1.jp

コネヒトのフロントエンド開発でもBabelを使っているため、なんとか支援できないかなと考えてみたものの、「会社での支援って大変そう？」という思いから具体的なアクションに結びつけられませんでした。

支援したいという気持ちの再燃

何もできないまま時は流れていましたが、たまたまトヨクモさんのOSSに関する支援活動を知って、素晴らしい活動をされていると共感しました。

oss.toyokumo.co.jp

上記をきっかけになんとか小さく始められないかと模索し見つけたのが、コネヒトの「スマイル制度」です。

スマイル制度を使って支援

コネヒトには「スマイル制度」という制度があります。これは開発組織のインプットとアウトプットの活性化を促進する制度です。とてもコネヒトらしい制度になっているので、詳しくはスマイル制度をご覧ください。

tech-vision.connehito.com

上記の制度を活用して少額ではありますが、Babelスポンサーをさせていただきました！

github.com

最後に

1年越しに支援できたことを嬉しく思うのと同時に、コネヒトは他にも様々なOSSを利用しているので、私たちが使っているOSSに関して支援できることがないか引き続き考えていきたいと思います。

Xcode14対応

こんにちは！コネヒトでiOSエンジニアをやっていますyanamuraです。

ママリのiOSアプリでXcode14でビルドが通るように対応を行いました。そんなに大変ではありませんでしたが、多少修正するところがあったのでまとめてみました。

やったこと

ライブラリのアップデート

ママリではRealmを使っていて、バージョンを上げる必要がありました。RealmSwiftを10.28.1、RxRealmを5.0.4にアップデートしました。

また、Xcode14にするとSwiftのバージョンが5.7になります。ママリではswift-formatを使っていて、こちらのバージョンを0.50700.1にアップデートしました。

ソースコードの修正

以下のようなエラーがコンパイル時に出るようになったので修正を行いました。

The compiler is unable to type-check this expression in reasonable time: try breaking up the expression into distinct sub-expressions

コンパイルエラーが発生した箇所はcombilneLatestでネストしている部分でした。

このようにcombineLatestの数の制限を突破するためにネストしている箇所が！

Observable.combineLatest(
    Observable.combineLatest(
      x,
      y
    ),
    a,
    b,
    c,
    …
    )
)

このようにネストしている箇所を外に出してやることでエラーは解消できました。

let xy = Observable.combineLatest(
      x,
      y
)

Observable.combineLatest(
    xy,
    a,
    b,
    c,
    …
    )
)

archiveに失敗する問題対応

上記対応でビルドはできるようになったのですが、archiveで失敗するようになりました。

CocoaPodsで追加しているライブラリで署名のエラーが出ました。

Signing for “XXX” requires a development team. Select a development team in the Signing & Capabilities editor

CocoaPodsのほうでもissueとしてあがっていました。 https://github.com/CocoaPods/CocoaPods/issues/11402

解決方法としてはこちらのようにTeam IDを設定するか https://github.com/CocoaPods/CocoaPods/issues/11402#issuecomment-1149585364

post_install do |installer|
  installer.generated_projects.each do |project|
    project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings["DEVELOPMENT_TEAM"] = " Your Team ID  "
         end
    end
  end
end

CODE_SIGNING_ALLOWEDをNOにすることで解決できました。 https://github.com/CocoaPods/CocoaPods/issues/11402#issuecomment-1201464693

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
      target.build_configurations.each do |config|
          config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
      end
    end
  end
end

まとめ

Xcode14にあげることで、iOS16の実機デバッグができるようになりますし、Swift5.7の新機能が使えるようになります。

Swift5.7ですぐに使いたいのがif letなどの短縮で

var startDate: Date?

if let startDate = startDate {
…

と書いていたのが以下でよくなりますね！

var startDate: Date?

if let startDate {
…

Swift 5.7については公式のだとSwift language announcements from WWDC22 が見やすい感じになっていますのでXcode14対応が終わったら見てみると良いかなと思います。

例年春頃にはXcode14にあげないとAppStoreに申請できなくなってしまうのでお気をつけください。

---

コネヒトでの開発に興味を持っていただいた方はカジュアルにお話しましょう〜 TwitterのDMなどでも大丈夫ですのでお気軽にどうぞ www.wantedly.com

3年ぶりにCTO Night & Dayに参加してきました！

こんにちは。CPOをやっている@itoshoです。

先日AWSさん主催のCTO Night & Day 2022 in 長崎（以下、CTO Night）に参加させていただきましたので、簡単にレポートをお届けします。*1

長崎とCTO Nightと私

CTO Nightとは技術の立場から経営に参画するリーダーが一堂に会する招待制カンファレンスですが、今年は3年ぶりにオフサイト開催となりました。僕自身も前回参加させていただいたのが、3年前の京都開催のCTO Nightでしたので、久しぶりのオフサイト開催は"くる"ものがありました。*2

CTO Night and Day 2019 | AWS Startup ブログ

長崎については、僕は初上陸で観光はほとんど出来なかったのですが、随所に異国情緒を感じさせる建造物があったり、レトロな路面電車が走っていたりと歴史を多層的に感じられる素敵な街でした。また、ワークショップで軍艦島ツアーに参加させていただいたのですが、悪天候*3で残念ながら上陸できなかったため、再チャレンジするためにもまた長崎を訪ねたいなと思いました。

長崎の思い出

偶発性の高いセッション

クローズドな内容もあるため詳細を語ることは出来ませんが、今回も非常に学びのあるセッションが数多くありました。例えば、Diversity, Equity & Inclusionについてはコネヒトの事業柄、より意識して行動していく必要があると感じました。

Web3に関しても様々な議論が巻き起こっていますが、Web3の真のビッグウエーブが来たとき"沖"に立っていられるよう、一人の技術者として要素技術をしっかり理解しておく必要性があると感じたので、手始めにDAppの個人開発をはじめてみようと思いました。

また、CTO Nightのような大規模なカンファレンスのセッションは一方向のコミュニケーションになりがちですが、今回のCTO Nightでは感想戦が用意されていたり、セッション自体もオーディエンスを巻き込んだりしていたのが印象的で、ネットワーキングの時間を含めて偶発的なコミュニケーション機会が多く、対面の良さを十二分に感じることが出来ました。

僕も有り難いことに登壇の機会をいただいたのですが*4、そこでも短時間ではあるものの参加者の方と対話をすることが出来たので、非常に"お土産"の多い3日間となりました。

ちなみに、僕の登壇の様子はAWSの畑さんのレポートにチラッと掲載していただいております。

note.com

3年ぶりの参加で感じたこと

今回、本当に多くのCTOの方が参加しており、良い意味でCTOという役割がコモディティ化しているなと感じました。その中で飽くなき挑戦を繰り返している参加者の方からは良い刺激をたくさんいただきました。一方で、僕も3年ほどCTOを務めて、コミュニティへ還元できる部分も出来てきたので、改めてCTOないしは技術コミュニティを盛り上げていくぞ！という気持ちを新たにしました。*5

というわけで、コネヒトはTech Visionでも「技術コミュニティになくてはならない開発組織をつくる」という方針を掲げているので、他社やコミュニティの方々と手を組んだ形でのイベントも一緒に出来ればと考えています。一緒にやってもいいぞ！という方や少しでも興味のある方はTwitterやFacebookまでお気軽にご連絡いただければと思います。

最後に

最高の場を用意してくださったAWSさん、本当にありがとうございました！

DAY1の集合写真（撮影：漆原未代さん）

*1:現職はCPOですので、ex-CTOとして参加させていただきました。

*2:もちろん、感染対策は丁寧に施されており、安心して参加することが出来ました。

*3:船の揺れと水しぶきと寒さが本当にヤバかったので、2022年トップクラスの"ハードシングス"でした。

*4:余談ですが、前回の京都開催に引き続きチャペルでの登壇となりました。

*5:個人的には今回改めてSaaS系スタートアップの盛り上がりを感じたので、争うわけではありませんが、toC系のインターネット企業も盛り上げていきたいです。