stefafafan の fa は3つです

"すてにゃん" こと id:stefafafan のブログです

トップ > 技術

Design Dontaku vol.2 #デザドン にエンジニアとして参加しました

技術

今回は福岡で開催されていた以下のイベントにブログ枠として参加してきました！以下エンジニアとしての感想を書いていきます。
nulab.connpass.com

テーマはエンジニアとデザイナーのコミュニケーション

Design Dontakuなので、デザイナーメインのイベントではありますが、テーマがエンジニアとのコミュニケーションだったので、エンジニアである私も惹かれて参加登録しました。

今回は「エンジニアとデザイナーのコミュニケーション」をテーマに、各社LTとパネルディスカッションを行います。

「デザイナー」と「エンジニア」、プロダクトを作るという立場では同じながらも別の役割、視点を持っています。それぞれの力を最大限発揮するために、どのように協業しているか、どんな工夫があったのかなどをお話します。

Design Dontaku vol.2 - connpass

結論としてはエンジニアとしてもとてもいい話が沢山聞けてとてもよかったです。

個別のLT

今回は4社によるLTがありました。

株式会社ヤマップさんより「YAMAPらしい共創文化」

YAMAPという登山家向けのアプリを開発されているヤマップさん。社内でどのようにして色んなメンバーが共同でコミュニケーションをとりいい感じに共創していってるのかという話をされました。

個人的ハイライトとしては、ツールやプロセスも大事だけど最終的に一番大事なのは「マインド」であるということと、ヤマップさんでは社内登山制度があるということでした。特に登山制度について、確かにみんなで運動したら連帯感が出てくるのはもちろんだし、その上で自分たちのアプリを実際に利用する機会になって当事者意識ができるのはいいな〜と思いました。

最終的にメンバーが職種問わずアプリのミッションについて話し合えているのは理想な状態で素敵だなと感じました。

株式会社ヌーラボさんより「チームの目線をあわせる「言葉」の話」

次のLTはヌーラボさんのUXライターの方によるお話でした。恥ずかしながら私はUXライターやUXライティングがどういうお仕事なのか分からなかったのですが、このLTのおかげで少し理解が深まりました。

UXライターの方はお一人で全ての文章を単独で書き上げられるのではなく、結局はエンジニアやデザイナーなど他の職種と共に協力してプロダクトやユーザにとって最適な文章を書き上げることが仕事（なのだと理解しました）。その中で、やはり共創が重要になってくるので、実際にヌーラボさんでも色んなメンバーと協力して仕事をしているそうです。

個人的にはこのUXライティングに大事な要素を語っているスライド群が面白く、また興味深いお仕事だなと感じました。いちエンジニアとしてはこういうお仕事は自分で挑戦するには難しそうと思ってしまいましたが、同じチームにこういう方がいたら何かできるところから協力したいなと思わされました。

株式会社マネーフォワードさんより「エンジニアとの円滑なコミュニケーションを図るコツ」

マネーフォワードさんはお二人で前後編で話されていました。最初はデザイナーとしてデザインシステムを上手く構築するのに苦労している方のお話でした。デザインシステム、確かに単独で進めていくのはいかにも大変そうだなとエンジニアとしても話聞いていて思いましたが、最終的には自分で頭を悩ませながら進めるよりは、エンジニアの方と認識合わせをしてからのほうがすんなり進んだそうです。

どうしてもエンジニアとデザイナーそれぞれで分業っぽくなり、お互いに最低限やってほしいことを依頼し合う仲になってしまいがちですが、そもそも何が課題でどこに向かっていきたいのかを前提を揃えることが大事だなと改めて思いました。

株式会社マネーフォワードさんより「Figma運用とデザイン共有のコツ」

マネーフォワードさん2人目のお話はFigma運用に関する話でした。

まず個人的にいいなと思ったのは、Figmaを使ってメンバーにデザイン共有するときにそれぞれの職種ごとに困っていることがうまくスライドにまとまっていることです。また、ここから全員が幸せになる方向で考えているのがとてもよいですね。

最終的には進捗がわかりやすくなるように細かいタスクの状況を簡易的に可視化したり、タスク管理ツールとの行き来がしやすいようにFigma上にリンク集をまとめるコンポーネントを設置したそうです。こういった工夫も地味だけど実は結構効果があったりしてやるといいのかもなと思いました。



株式会社ゆめみさんより「チームを超えてわいわいつくってみた話」

最後はゆめみさんの新卒デザイナーによるLTでした。新卒として、まだ大きな仕事を振られていなかったタイミングでたまたまコーポレートエンジニアの方と一緒に仕事をすることになって、デザインをがんばった話。

もともとはドキドキしながらデザインの指摘をしたりしてみたけど、エンジニアは真剣に向き合ってくれて、ポジティブな反応をもらえたそう。その経験から気軽に異職種と相談できるようになったといういい話でした。

また、どうやら初めの頃はエンジニアのことを桃太郎に登場する鬼のような存在だと思っていたらしく、「そんなに！？」といちエンジニアとしても思ってしまいましたが、はじめて共創するときはそうなのかもしれませんね……。実際は鬼ではなく仲間だったということで一安心。



座談会そして懇親会

LTが終わったら座談会がはじまりました。座談会ではLTに登場した会社さんとpostalk株式会社さんのメンバーがエンジニアとデザイナーの共創について色々とお話されました。スタートアップの場合1人目のデザイナーはいつ雇うのかとか、デザイナーとエンジニアって仲が悪いのか？などとても盛り上がりました。「良いデザイナー」とは、みたいな話もあったりして興味深かったです。どれも明確な答えはなかったですが、結局はそれぞれの会社のやりたいことやフェーズによって要求はさまざまなのかなと聞いていて感じました。

懇親会では数人と少しお話しました。デザイナー不在の会社に勤めていて、デザイナーを雇おうと思っているけどどういう基準で雇えばいいのか……と悩んでいる方の話を聞いたり、エンジニアとデザイナーの隔たりをどうやって解消していけばいいんでしょうねと話したりしました。

全体の感想

これだけ多くのデザイナーさんとリアルで対面してそれぞれの思いをLTや懇親会で聞く機会が私は今までなかったので新鮮で参加できてよかったです。また、だいたいの話に共通することとして改めて認識したのは、「目線合わせが大事」ということだと思いました。

様々な職種が同じプロダクトに携わるとして、目先のテクニックをどうこう考える前にそもそもそのプロダクトがどうあるべきか、どういう課題がありどう乗り越えたいのかを全員で認識合わせをしない限り空回りするということなのかなと。今後私もエンジニアとして相手を「デザイナー」と意識する前に「チームメンバー・仲間」として今後どうしていきたいかを話し合ってから「じゃあエンジニア・デザイナーとしてどう分担しましょうか」と話すようにしていきたいなと思いました。とても有意義な会をありがとうございました！

GitHub App の権限で Songmu/tagpr を利用する

技術

id:Songmu さんが作られた https://github.com/Songmu/tagpr を先ほど使ってみたのですがリリースフローがGitHub Actionsでまとまっているし、リリース内容がPull Requestにまとまってマージしたらいい感じにtag打ってくれるしでとても体験がよかったです。

ただし一点気になるとするならば、 リリース用のpull requestを自動作成し、マージされたら自動でタグを打つtagpr | おそらくはそれさえも平凡な日々 の記事や README には、GITHUB_TOKEN を活用する例や Personal Access Token を使う例はあっても、GitHub Appを作ってその権限を利用する方法は詳細には書かれていなかったのでメモとしてブログに書いておきます。

GitHub Appのトークンを返してくれる便利GitHub Actions

少し前まではGitHub Appのトークンを利用するための便利Actionsがサードパーティとしていくつか存在していて人々はこれを使ったり自作したりしていました。

これらは使えますが、いかんせん公式ではないので、セキュリティ面を気にしてGitHub Appのトークンを使いますというときに採用するのはちょっと緊張感はあるかもしれません。

そんな中最近公式が同等の機能を持ったActionsを出してくれました。

github.com

今後はこれ一択で使っていくと良いと思います。

actions/create-github-app-token の使い方

基本的にはREADMEにUsageがあるのでそちらをみてください。流れとしては以下のような感じです。

  1. GitHub App を作成する (権限は必要最低限に絞りましょう)
  2. Appを作る中でApp IDやPrivate Keyが取得できるので使うリポジトリのSecretsに登録しましょう
  3. GitHub App を対象のリポジトリに対してインストールしましょう

Songmu/tagpr と合わせて使う際は、設定後に tagpr のActionを動かしてみて、途中で権限不足っぽいエラーが発生したらGitHub Appの権限を見直して、インストールしたリポジトリ側で追加された権限を承認して再実行して調整するようにします。自分の場合はRelease Notesの生成のために Contents の権限が漏れていました。

実際のWorkflowの例

最終的にこういう設定になりました。ブランチ名やRepository Secretsの名前とかは設定次第で変わるかもしれませんが、基本的にどのリポジトリもこういうWorkflowを追加すると動くと思います。みなさんもお試しください。

name: Release with tagpr

on:
  push:
    branches: ["main"]

jobs:
  tagpr:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/create-github-app-token@v1
      id: app-token
      with:
        app-id: ${{ vars.APP_ID }}
        private-key: ${{ secrets.PRIVATE_KEY }}
    - uses: actions/checkout@v4
      with:
        token: ${{ steps.app-token.outputs.token }}
    - uses: Songmu/tagpr@v1
      env:
        GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}

追記

Songmu/tagpr 本体で設定されている tagpr.yaml では tibdex/github-app-token が使われていることを後で発見したので、 actions/create-github-app-token を使いませんかとP-Rを出してみました。
github.com

ぼんやり思っていることを整理するためにカンファレンスのCfP (Call for Proposals) を利用する

技術

最近少しずつ技術系のイベントでの発表機会を増やそうとしています。その中で、大きめなイベントだとまずCall for Proposals (CfP) という、プロポーザルを出したらそれによって選考が行われ実際に発表できるかどうかが決まる制度があります。ここで出したプロポーザルは必ずしも通るわけではないですが、出さない限り発表はできません。

プロポーザルを出すためにネタがないといけませんが、最近自分は「完璧な資料やアウトラインはないけども、当日までにまとめることはできそうだな」という感じのものをプロポーザルとして出したりしています。

具体的には、

プロポーザルを出しているということは喋ることのイメージが100%まとまっていると思われるかもしれませんが、実際のところは全然そんなことはなく、全体の流れはイメージがついているくらいです。上記のイベントはどれも12月〜2月の開催なので当日まで十分時間があり資料をまとめられそうだから不安に思っていません。ただしさすがにあまりにもイメージが曖昧だとプロポーザルとしても曖昧になってしまいます。なのでプロポーザルを出す前に軽く考えを整理しなければいけません。

何も機会がなければ自分はだらけたくなるので、プロポーザルを利用して締め切り駆動で動けるようにしようとしています。プロポーザルを出すとなると赤の他人に読んでもらうことにはなるし、あわよくば通してもらいたいので、1段階整理する必要があります。この段階で資料はできていなくても、ゴールのイメージを作る必要があります。

次に仮にプロポーザルが通った場合資料を実際に作って発表できる形にするという2段階目の整理が必要となります。その上で無事発表を終えてブログなどにまとめられたら、今後のエンジニア人生で自分や同僚が似たような境遇になった際に自分の残した資料を参考にしてもらえるようになります。ここまで来たら一番良いですね。

プロポーザルを出したりイベントに出たりしなくとも、考えたことを個人ブログにこのようにしてまとめて出すだけでも考えの整理としては十分かもしれません。でもやはりエンジニアコミュニティにももっと顔を出して実際に懇親会などで顔を合わせて色んな話を同期的にして情報交換したいなという欲求が増してきているので今後もこの調子でチャレンジしていきたいと思っています。

Go言語でsliceの重複排除 (slicesやsamber/loパッケージを使う場合)

技術

Go言語でsliceの重複排除について書きます。Go 1.21前提です。

slices パッケージを使っての重複排除

Go 1.21から slices パッケージが増えました。ここに生えている関数を利用して重複削除のコードが書けます。
pkg.go.dev

例えば int の slice の重複排除は以下のように書けます。

integers := []int{1, 2, 2, 1}
slices.Sort(integers) // [1 1 2 2]
uniqValues := slices.Compact(integers) // [1 2]

slices.Compact は連続する値を1つにまとめる関数なので、重複排除したい場合は slices.Sort で先にソートする必要があります。

User という struct の slice を id で重複排除したい場合はどうすればいいかというと、比較関数を自分で渡せる slices.SortFunc と slices.CompactFunc も用意されているので、以下のように書けます。

slices.SortFunc(users, func(a, b User) int {
	return cmp.Compare(a.id, b.id)
})
uniqUsers := slices.CompactFunc(users, func(a, b User) bool {
	return a.id == b.id
})

Go Playground での例

samber/lo パッケージを使っての重複排除

samber/lo というLodash風のサードパーティなライブラリがあり、これを使うとより短い記述で同じことが実現できます。
github.com

int の slice の重複排除は1行で実現できます。

uniqValues := lo.Uniq([]int{1, 2, 2, 1}) // [1 2]

User の slice の重複排除は UniqBy という便利な関数が用意されているので以下の3行でシンプルに書けます。

uniqUsers := lo.UniqBy(users, func(u User) int {
	return u.id
})

Go Playgroundでの例

記述量の少なさでは samber/lo のほうが優れていますが、サードパーティパッケージを依存に入れる必要があるのでそこをどうするかは個人の判断になります。

Goの標準パッケージにUniqやUniqFuncが増えることはないのか

標準パッケージに lo.Uniq や lo.UniqBy に対応する関数が増えたら便利そうに思いますが、入る余地はあるのでしょうか。

Goのリポジトリのissueを見ていたら以下のようなコメントがありました。

特に Russ Cox による「重複排除とソートはわけたほうがよいと考えている」という意見が大きいのかなと思っていて、確かにUnixで sort してから uniq するという書き方と揃う。

ちなみにじゃあなんで Compact って名前になったのかというと色々議論があった上、重複排除してくれる関数なのだとユーザが勘違いしそうということで最終的に Russ Cox の意見が通ったようです。 https://github.com/golang/go/issues/45955#issuecomment-880076961

また、Rob Pike さんもコアライブラリに Uniq や UniqFunc いらないのではとコメントしていた。（重複排除について言ってるのか、 Compact も要らないと言ってるのかは読み取れなかったですが） https://github.com/golang/go/issues/45955#issuecomment-861173504

こういう感じなので、proposalを出したらチャンスはゼロではないかもしれないですが、「SortしてからCompactでいいのでは？」と言われる可能性が大きそうな印象を受けました。

GitHub Actions から Google Cloud を使う際の gcloud バージョンを固定することにした

技術

弊チームではGitHub ActionsからGoogle Cloud Runにアプリケーションをデプロイしてプレビュー環境として利用しています。具体的な構成などについては以下の記事をご参照ください。
developer.hatenastaff.com

先日、内部で使われているGoogle CloudのCLI gcloud のバージョンが上がったことによりこの環境が正常に動かなくなって困った事例があったので、今回これを機にバージョンを固定することにしました。

gcloud のバージョンが上がってどのように壊れたのか

445.0.0 (2023-09-06) から 446.0.0 (2023-09-12) に上がった結果以下の Issue Tracker にあるような挙動の変化がありました。
https://issuetracker.google.com/issues/300221542

弊チームではCloud Runのリビジョンタグを使って、ブランチごとのプレビュー環境を実現していますが、この日から突然さまざまなブランチの環境が最新のリビジョンに向くようになり、環境が正常に動かなくなりました。

翌朝確認すると 446.0.1 (2023-09-14) のバージョンがリリースされこの不具合は修正されて事なきを得ましたが、それでも突然環境が壊れた当日は原因の切り分けがすぐにできなくて時間をとられてしまいました。
cloud.google.com

google-github-actions/setup-gcloud で利用する gcloud のバージョン固定

GitHub Actionsで gcloud をセットアップする際は google-github-actions/setup-gcloud というActionを使うと楽です。元々Action自体のメジャーバージョンしか固定していなかったので、以下のように2行足して内部で利用している gcloud のバージョンも固定することにしました。

      - name: Setup Cloud SDK
        uses: google-github-actions/setup-gcloud@v1
+       with:
+         version: "446.0.1"

まとめ

  • google-github-actions/setup-gcloud を使うと便利にGitHub Actionsから gcloud が使えるけど Action そのもののpinの他に内部で使っている gcloud のpinもすると良いかもしれません
  • Google Cloud CLI - Release Notes  |  Google Cloud CLI Documentation に gcloud のアップデート情報が載っているので挙動の変化を感じたらみると良いですが、今回のような意図しないバグなどはここみてもわからないことがあります
    • その場合は Google Issue Tracker をみると何か他のユーザが書き込んでいるかもしれないので覚えておきましょう