オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

開発部で1年間やったこと

f:id:allabout-techblog:20220330163558p:plain 毎年恒例オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒週間2022」を開催します。 今回は、オールアバウトマーケティング開発部の@woodyがお送りします。

1.はじめに

2022年4月に入社し、7月まで研修を受けたあと、開発部のマーケティング開発グループのチームに所属して業務を行っています。

本記事では実際にどんな風に業務を行ってきて、どんなことを感じたのかを書いています。

学生時代は統計学を扱う研究室に入っていてアプリ開発よりもデータ分析をメインでやっておりました。

分析だけでなく実際のプロダクトを作れるようになりたいと感じ、事業系会社のアプリ開発会社に就職しました。

初めてのことが多く学びが多かった一年となりました。

2.どんな業務をしているか

2.1.主な開発内容について

現在はコンテンツマーケティングプラットフォーム「PrimeAd」の中のビジネスマッチングプラットフォームの開発業務に従事しています。

広告を出したい広告代理店と広告を載せるメディアをつなぐプラットフォームです。

ビジネスマッチングプラットフォームは新規事業としてはじまり、2020年7月にローンチされたばかりで、現在も試行錯誤しながら事業拡大を図っています。

primead.jp

2.2.使用技術

基本的に以下の技術を使って開発を進めています。

3.業務の流れ

チームではアジャイル開発を採用していて2週間単位のスプリントで開発をしています。

私達のチームでは以下の流れで開発を進めています。

  1. 事業の課題をtrelloに記載し重要度を割り振る
  2. 重要度の高いものから、開発対象としてタスク化する
  3. スプリント内で解決すべきタスクを各レーンへ割り振る
  4. 設計 (ここからペアプロ)
  5. 実装
  6. レビュー
  7. ステージングリリース
  8. 本番リリース

f:id:allabout-techblog:20220329095051j:plain
スプリントの流れ

3.1.事業の課題をtrelloに記載し重要度を割り振る

チームとして事業の課題や開発タスクはTrelloのカンバンで管理しています。

ユーザーからヒアリングした課題や開発中に感じた課題がTrelloのカンバンボードに記載されていきます。

記載されているタスクをもとに重要度を割り振っていきます。

3.2.重要度の高いものから、開発対象としてタスク化する

重要度を割り振ったものの中でどのように開発を進めていくか議論をして、タスクとして進められるようにしていきます。

3.3.スプリント内で解決すべきタスクを各レーンへ割り振る

チームでは二人一組でペアを作って作業を進めています。各レーンに対して合計稼働可能時間を超えないようにタスクを割り振っていきます。

3.4.設計

担当を割り振ったら、設計を行います。 ここからペアで作業をしていきます。

機能の要件や画面設計をしていきます。

3.5.実装

開発するときはペアプログラミングを行っていて、二人一組で交代で意見を出しながら実装をしています。

3.6.レビュー

実装したものをチームでコードレビューをしています。コードレビューを挟むことでコードの品質を担保しています。

3.7.ステージングリリース

コードレビューを経て問題がなさそうであればステージングリリースまで行います。

ステージングとは本番環境と同様の状態でシステムの動作や不具合のチェックを行う段階です。

3.8.本番リリース

ステージング環境で問題がなさそうであればリリースを行います。

4.感じたこと

技術的な学びはもちろんありましたが考え方の学びが多かった一年だなと思います。大きく分けて3つの学びがありました。

4.1.開発においてはデバッグできるかが大事

デバッグとはバグと呼ばれるプログラム上の間違いを見つけて排除する作業のことです。

今まではどのようにコーディングするかが大事だと考えていました。しかしながら実際に開発をしていくと多くの時間をエラーの対応に使うことになりました。

人為的なミスや、想定していないパターンでのエラーはよく出てきます。なのでいかにデバッグを効率よくするかが大事です。

その時に特に「エラー文を出す」「問題を切り分ける」「質問する」ことの3点が大事だったなと感じました。

4.1.1.エラー文を出す

プログラムを書いていく中で、エラーが発生した時にエラー箇所とどんなエラー内容だったかを出力してあげるようにすることでバグの場所の特定が容易になります。

4.1.2.問題を切り分ける

エラーが出たとしてもどこが悪いのか見当がつかない時があったりします。その時は条件を固定したり、検証範囲を狭めたりして問題となりそうな部分をあぶりだすことが有効だったりします。

4.1.3.質問する

どうしてもわからなくなったときには質問して教えてもらったりすることが大事になってきます。

先輩エンジニアに質問をすることで自分が持っていない視点があったりするのですんなりと解決することがあったりしました。

4.2.手運用でカバーすることも候補の一つ

顧客課題を解決するために機能を作っていきますが、やっていくうちにあれもこれもあったらいいとなって実装したい機能が多くなってしまいます。

時間と開発者は有限なので最小限の機能を考え、機能をリリースして顧客のフィードバックを元に改善していくことが大事です。

例えば本来システム化するところを人力で行って、利用されるかを試したりするなどの方法があったりします。

いかに素早く検証ができるかが大事だと身にしみて感じた一年でした。

4.3.どうやるかよりも取り組むべき課題の見極めが大事

どう実装するかも大事ですが、それよりも何を実装するかの方がとても重要です。実装したとしても使われなかったら意味がないので努力が水の泡となってしまいます。

そういった背景から実装している時間と同じぐらいチームでは課題に対する議論を行い、何を実装するかを検討しています。

また課題をいかに解像度を高めれるかが実装までスムーズに行えるかの分岐点となります。何を解決したいのか実際曖昧なまま進めてリリースできなかった機能があったりしたので気をつけたいところです。

5.おわりに

一年を通して開発エンジニアとして実装する力も大事ですが、取り組む上での姿勢やチームとしてどう動いていくかが重要だと感じました。

これからエンジニアとして業務に入る人の参考になれば幸いです!!

最後に、現在オールアバウトでは、エンジニアを絶賛募集中です。

ちょっと話を聞いてみたいなどでももちろん大丈夫です!

少しでも興味を持っていただけた方はぜひ採用サイトからご連絡ください。

corp.allabout.co.jp

CircleCi で OIDC(OpenID Connect) がサポートされたので Google Cloud で試してみた

こんにちは。オールアバウト SRE 所属 の@s_ishiiと申します。

先日 CircleCi で OIDC(OpenID Connect)がサポートされました。
Github Actions で OIDC がサポートされてからこの日が来るのを待ち望んでいたので早速オールアバウトの CI で利用してみました。

https://twitter.com/CircleCIJapan/status/1507524861396422657?cxt=HHwWgsDU2fn35uspAAAA

OIDC があると何が良いのか?

「そもそも OIDC って何が良いの?」という方のために OIDC 登場以前と以後の世界について簡単にご説明します。

従来 Google Cloud 等のクラウドAPI やリソース に CircleCi からアクセスするには、クラウド側でサービスアカウントキーを発行し、CircleCi の環境変数として登録する必要がありました。

この方法の問題点はサービスアカウントキーが本質的にセキュアでないという点です。
サービスアカウントキーは明示的に削除しない限り最長 10 年間認証可能なのでキーの漏洩リスクが常に存在します。

OIDC を利用することでサービスアカウントキーなしで認証を通すことができるためよりセキュアな運用が可能になります。

OIDC に関する説明は Github の以下ページでよくまとめられているので関心のある方は一読されることをおすすめします。 https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect

Understanding the OIDC token 以降は Github Actions 固有の話しです

Google Cloud で CircleCi OIDC を利用する手順

ここからは具体的な設定手順について解説していきます。

Google Cloud で CircleCi OIDC を利用するには以下 2 点が必要になります。

  • Workload Identity Pool の作成(Google Cloud)
  • アクセストークン取得用のコードの追加(CircleCi)

Workload Identity Pool の作成(Google Cloud)

基本的な手順は Github の以下ページで詳細に説明されています。 https://github.com/google-github-actions/auth#setting-up-workload-identity-federation

オールアバウトでは Google Cloud のインフラ群は Terraform で管理しているので以下のようなコードで設定しました。

locals {
    circleci_organization_id = "<CircleCi Organization ID>"
}

resource "google_iam_workload_identity_pool" "circleci" {
  provider                  = google-beta
  workload_identity_pool_id = "circleci-pool"
}

resource "google_iam_workload_identity_pool_provider" "circleci" {
  provider                           = google-beta
  workload_identity_pool_id          = google_iam_workload_identity_pool.circleci.workload_identity_pool_id
  workload_identity_pool_provider_id = "circleci-prvdr"

    attribute_mapping = {
        "google.subject"         = "assertion.sub"
        "attribute.actor"        = "assertion.actor"
        "attribute.repository"   = "assertion.repository"
    }

    oidc {
    allowed_audiences = [local.circleci_organization_id]
    issuer_uri        = "https://oidc.circleci.com/org/${local.circleci_organization_id}"
  }
}

module "circleci_sa" {
  source  = "terraform-google-modules/service-accounts/google"
  version = "~> 4.1.1"

  display_name = "CircleCi Service Account"
  project_id   = var.project_id
  prefix       = "sa-${var.env_code}"
  names        = ["circleci"]

  project_roles = [
    "${var.project_id}=>roles/artifactregistry.writer",
  ]
}

resource "google_service_account_iam_member" "circleci_sa" {
  service_account_id = module.circleci_sa.service_accounts[0].id
  role               = "roles/iam.workloadIdentityUser"
  member             = "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.circleci.name}/*"
}

やっていることをまとめると以下 3 点になります。

  • Workload Identity Pool の作成
  • Workload Identity Provider の作成
  • ID 連携用のサービスアカウントの作成

基本的には 上記で紹介した Github のページで説明されていることを Terraform で書いただけですが、audience として CircleCi のOrganization IDを追加で設定しています。

何故 audience の設定を追加しているのかというと、Github Actions と CircleCi で発行する OIDC Token の中身が違うためです。
具体的には CircleCi の OIDC Token には aud 値として CircleCi の Organization ID が入るため Workload Identity Provider 側でこの値を許可するよう設定する必要があります。

なお、CircleCi の Organization ID は管理画面の Organization Settings からご確認頂けます。

アクセストークン取得用のコードの追加(CircleCi)

Google Cloud の設定が完了したら次は CircleCi 側のコードを変更します。

CircleCi のドキュメントを読むと今回のリリースで CircleCi の各 Job で CIRCLE_OIDC_TOKEN という環境変数が利用可能になっており、この変数に OIDC Token が格納されています。
https://circleci.com/docs/ja/2.0/openid-connect-tokens/

この OIDC Token を最終的にサービスアカウントのアクセストークンと交換するようコードを書いてやる必要があり、具体的には以下のようなコードになります。

- run:
    name: Google Authentication
    command: |
        ACCESS_TOKEN=`curl -X POST -s \
            -H "Content-Type: application/json; charset=utf-8" \
            -d "{
                "audience": \"//iam.googleapis.com/projects/<< parameters.project_number >>/locations/global/workloadIdentityPools/circleci-pool/providers/circleci-prvdr\",
                "grantType": \"urn:ietf:params:oauth:grant-type:token-exchange\",
                "requestedTokenType": \"urn:ietf:params:oauth:token-type:access_token\",
                "scope": \"https://www.googleapis.com/auth/cloud-platform\",
                "subjectTokenType": \"urn:ietf:params:oauth:token-type:jwt\",
                "subjectToken": \"${CIRCLE_OIDC_TOKEN}\"
            }" \
            "https://sts.googleapis.com/v1/token" | jq -r .access_token`
        SA_ACCESS_TOKEN=`curl -X POST -s \
            -H "Authorization: Bearer $ACCESS_TOKEN" \
            -H "Content-Type: application/json; charset=utf-8" \
            -d "{
                "scope": [
                \"https://www.googleapis.com/auth/cloud-platform\"
                ]
            }" \
            "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<< parameters.sa_email >>:generateAccessToken" | jq -r .accessToken`
        echo $SA_ACCESS_TOKEN | docker login -u oauth2accesstoken --password-stdin https://asia-east1-docker.pkg.dev

<< parameters.sa_email >> には Google Cloud 作成したサービスアカウントのメールアドレスが入ります

詳細な説明は Google Cloud の以下公式ページをご確認頂くとして、簡単に説明すると 1 回目のリクエストで Workload Identity の認証を通し、2 回目で事前に設定したサービスアカウトを一時的に借用するためのリクエストを送信しています。

https://cloud.google.com/iam/docs/access-resources-oidc?hl=ja#exchange-token

動作確認

上記コードを動かすと以下のようになります。 (実際にはこの後続の step で Docker イメージを build して Artifact Registry に Push しています)

f:id:allabout-techblog:20220329210816p:plain

また、Google Cloud 側ではサービスアカウントが借用されたログを確認できます。 (事前に監査ログを有効化する必要があります)

f:id:allabout-techblog:20220329210851p:plain

まとめ

CircleCi の OIDC はサポートしたばかりのため Orb がまだ作られておらず、トークン取得周りのコードを自分で書く必要があります。
これはなかなか大変ですが、一度実装してしまえばサービスアカウントキーの管理から開放されるのでメリットは非常に大きいです。

今回は Google Cloud での実装例の紹介でしたが、もちろん AWS 等の他のクラウドでも利用できるので CircleCi を利用されている方は利用を検討することをおすすめします。

以上、「CircleCi  で OIDC(OpenID Connect) がサポートされたので Google Cloud で試してみた」でした。

新卒が感じた仕様調整の難しさ

f:id:allabout-techblog:20220330090737p:plain

はじめに

オールアバウトグループの新卒1年目エンジニアが投稿する企画『テックブログ新卒週間2022』。

今回はタケウチがお送りします。

私は2021年4月に入社し、7月半ばまでオールアバウトグループ研修とアプリ開発研修を受けました。 研修後には、メディア開発1グループに所属し業務をしています。

本記事ではメディア開発1グループがどのような働き方で、私が実際にどのような業務に取り組んできたのかを紹介します。また振り返りを兼ねてチームで業務を進めるにあたって難しさを感じた他部署、他グループとの仕様の調整について紹介していきます。

どんな業務をしているか

私の所属するグループでは、All About、All About Newsという2つのメディア運営に関するシステムの開発・保守をしています。

具体的なシステムの開発・保守としては以下が挙げられます。

  • ユーザーが記事閲覧しやすいようにメディアのデザインや機能の改善
  • All Aboutの記事を他社のニュースプラットフォームへ提供・配信する機能の開発
  • 記事入稿システムの機能改善(記事入稿の補助機能など)

業務の進め方

業務の進め方としてはスクラムを採用しており、1スプリントの期間は1週間です。この期間で開発を進めています。

スクラムとは

www.otsuka-shokai.co.jp

スプリントは毎週木曜日に始まります。

木曜日にメディアを担当する企画チーム、編集部との定例で開発する機能や施策の優先順位を決めます。それからスプリントプランニングを行い、スプリントで実施する施策を決めます。そしてスプリントでやる内容を企画チーム、記事制作チームに確認してもらい、合意を得ます。

金曜日から水曜日で施策や機能の開発に取り組みます。

そして次のスプリントの初日である木曜日に、前回のスプリントで開発した施策や機能を企画チーム、編集部に向けてデモをしてレビューをしてもらいます。 その後に開発する機能や施策の優先順位を決めるといったサイクルでスプリントを回していきます。

f:id:allabout-techblog:20220325152727p:plain
スプリントのイメージ

また業務の特性上、エンジニアだけで完結する業務はほとんどなく、企画チームや編集部とコミュニケーションを取りながら仕様や開発のゴールを決めていきます。

その仕様決めのコミュニケーションがうまくいかず、スプリントに遅れが生じ、苦労したケースが何度かあります。次にそこを掘り下げます。

苦労した仕様決め

メディア開発1グループでは、プロジェクト管理ツール「Backlog」を用いてタスクを管理しています。定例ではBacklogを企画チームや編集部と確認し、開発の要件やゴールを記載していきます。

開発を進めていくにあたって新たな考慮点が発生することがあるのでその都度、仕様を決めていきます。

最も仕様決めに時間のかかっていた、メディア開発1グループに所属して数ヶ月間のコミュニケーションを振り返ってみると、簡単なタスクにも関わらず仕様を決めるのに数日かかっていました。また先輩の助け無しでは仕様漏れも現在より頻繁に起こっていました。

チームメンバーからの指摘もあり、以下が課題になっていると考えました。

  1. 文章を長く書いてしまって読みづらく、相手に意見を伝えるのに時間がかかる
  2. 仕様をどうするか全て質問してしまっている

1. 文章を長く書いてしまって読みづらく、相手に意見を伝えるのに時間がかかる

文章が読みづらいことが原因でコミュニケーションのラリーが何度も発生していました。そのため自分の時間だけではなく、返信している関係者の時間まで無駄に消費してしまう状態になっていました。

オールアバウトには『ななメンター』という制度があり、新卒に自分の所属するグループ以外の先輩がメンターとしてつきます。そのななメンターでのランチの際に先輩にコミュニケーションの取り方について相談しました。

ななメンターからは文章力についての本(『メール文章力の基本 大切だけど、だれも教えてくれない77のルール』)を紹介してもらいました。

本から得た文章を書く際の以下のテクニックを特に意識するようになりました。

  • 文章ではなく箇条書きを原則とする
  • 曖昧な表現を使用しない
  • 主語、主体を明確にする
  • 本文で説明するか、添付ファイルで説明するかを検討する

上記を意識して、社内のslackの文章で改善できる箇所を見つけて修正していくことで、本から得た学びをアウトプットしていきました。

そして、修正した文章をななメンターとのランチ会でレビューをしてもらいました。

また先輩方の文章などを参考にして徐々に改善していきました。

2. 仕様をどうするか全て質問してしまっている

質問相手に仕様を任せていることも同じくコミュニケーションが何度も発生する原因でした。

企画チームや編集部は仕様を全て把握しているわけでは当然ないので、質問されてからどうするかを考える時間が発生します。

また仕様によって開発の工数も変わるので、企画チームや編集部は容易に決めることができません。

例えば、『記事の更新日を記事の上部に表示したい』という施策があったとします。

これまでは以下のように企画チームに質問していました。

PC版の記事更新日の表示位置を変更する施策について質問があります。
具体的に記事のどの箇所に追加したらよろしいでしょうか?

これでは企画チーム側でどの箇所に表示をしたいかを0から考える必要があります。

そのため質問として相手側に丸投げするのではなく、こちらから案を出すように意識的に変えていきました。

PC版の記事更新日の表示位置を変更する施策について相談があります。
記事更新日をどの箇所に表示しましょうか?

記事更新日の表示位置についてPC版のモックを3案作成しました。
スプレッドシートに記載しております。
どの案が良いか、もしくは他の表示位置を検討する必要があるかをご意見いただきたいです。

上記のように相談することで、相談される側もどう返事をするかを考えやすくなりますし、仕様のすり合わせにかかるコミュニケーションの量も以前より減らすことができました。

終わりに

メディア開発1グループに所属した自分がどのように業務をしているのか、苦労した仕様決めのコミュニケーションをどう改善していったのかを紹介しました。

開発が思うように進まなかったり、仕様をなかなか整理できなかったりとうまくいかないことが多い新卒の1年間でした。

しかし、このブログを書くにあたり過去のslackでのコミュニケーションや資料、プルリクエストなどを振り返ると成長していることは感じられました。

今後も開発の力とコミュニケーション力を鍛えて、出来ることを着実に増やし、仕事を楽しく進めていきたいと思います。

オールアバウトエンジニアのSlack人気スタンプを調査してみた

毎年恒例オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒週間2022」を開催します。

今回は、オールアバウトメディア開発部の@eeveeがお送りします。

はじめに

突然ですが、皆さんはSlackをご存知ですか?

株式会社オールアバウトでは、社内のコミュニケーションツールとしてSlackを採用し、業務上のやりとりを行っています。

Slackでは投稿に対して文字で補足や反応する代わりに絵文字でリアクションを取ることができます。

Slack公式の定義にならい、この絵文字でのリアクションのことを絵文字リアクションと呼びます。

社内Slackでは、多種多様なカスタム絵文字が登録され、絵文字リアクションがコミュニケーションの一環として使われています。

社内Slackの絵文字リアクションを集計してみるとチームごとのコミュニケーションの違いが現れておもしろいのではないかと思い、人気絵文字リアクションを調査してみました。

本記事では、その調査方法と結果を紹介したいと思います。 社内Slackのデータを分析してみたい方、またオールアバウトの開発チームのSlack事情気になる!という方の参考になれば幸いです。

自己紹介

私は非情報系学部出身で、業界未経験から新卒入社しており、今回のようなWEB APIを使ったデータ集計は初めての試みでした。 そのためかなりの試行錯誤を経て集計しており、今回ご紹介する実装方針はあくまで一例であるということを前提に読んでいただければと思います。

私は開発部の中でも、オールアバウトで運営するメディアや社内CMSの開発・メンテナンスをするチームに所属しています。 個人作業のときもありますが、基本はペアで開発業務を進めています。

私のチームはエンジニア同士だけではなく、企画グループや社内CMSを利用する記事編集グループなどと部署内外問わず様々なやりとりを行っています。

チーム内での報告・連絡・相談や部署内外でのやりとりでは、「はじめに」で記載したようにSlackを利用しています。

一行で済む返信は絵文字リアクションで伝えて良いこととしたり、問い合わせが来た場合には確認したら絵文字リアクションをとるようにするなど、Slackでのコミュニケーションを重要視しているチームです。

Slackのスタンプを解析してみた

同じ開発部でもチームによって、Slackの使い方の方針は異なるようです。

Slackの絵文字リアクションを集計してみるとチームごとの特徴・働き方の違いが現れておもしろいのではと思い、普段使われている絵文字リアクションのデータを分析してみることにしました。

集計ルール

今回の集計ルールは以下のとおりです。

  • 集計項目
    • メッセージに対する絵文字リアクションの使用回数
    • カスタム絵文字と通常の絵文字どちらも対象とする
  • 集計範囲
    • タイムラインに載っているメッセージのみ集計範囲とする
    • 直近の2000件のメッセージが対象
    • メッセージに含まれる絵文字は絵文字リアクションではないため対象外

全体の実装の流れ

今回のようなデータ分析を行うときはPythonを用いることが多いと思いますが、今回は勉強のために業務で用いるPHPで実装を行いました。

実装の流れはざっくり以下のとおりです。

  1. SlackAPIを利用する準備

    • Slack Appの作成
    • scopeの設定
  2. 実装

    • Slackからメッセージ履歴とカスタム絵文字データを取得
    • 絵文字データを抽出・集計

SlackAPIを利用する準備

SlackAPIとは、他のアプリケーションでのAPIと同様に外部アプリケーションからSlackを操作するための仕組みです。

SlackAPIの中でもWebAPIやEventsAPIなど様々な種類のAPIがありますが、今回はWebAPIを使用します。

公式のドキュメントはこちらです。

api.slack.com

必要なSlackAPIが何なのかはこちらが参考になります。

api.slack.com

まずはSlack Web APIを利用するための準備をしていきます。

Slack Appを作成する

データ調査を行うためにはまず、SlackAppを作成する必要があります。

そのApp用のトークンを発行し、トークンを用いてApp経由でチャンネルのデータを取得します。

ここは検索してみるとやり方をまとめたQiitaがすぐに出てくるのであまり苦労することはありません。 今回は以下のQiitaを参考に設定しました。

qiita.com

また、作成したSlackAppには使いたいメソッドごとに必要な権限を付与しないとAPIを利用できません。

ここで注意する点があります。

付与する権限はUserとBotで別れており、Appをどのように用いるかで利用する権限が異なります。

botとして権限を付与すると、データを取得したいチャンネルにSlackAppを登録しないとAPIを利用できないようです。

使いたいメソッドのリファレンスに、必要な権限も書いてあるためしっかり確認しておきましょう。

実装の流れ

SlackAPIメソッドを使って、メッセージ履歴とカスタム絵文字を取得します。 これに必要なメソッドはそれぞれ、conversations.historyとemoji.listです。

それぞれのメソッドのリファレンスはこちらです。

api.slack.com

api.slack.com

メソッドにはそれぞれ必要な権限があるので、使うメソッドを決めたらそのメソッドのRequired scopesを確認してSlackAppに必要な権限を追加しましょう。

メッセージ履歴とリアクションの取得

APIメソッドを使用する際、引数のchannelには、Slackのチャンネルリンクを発行した際にわかるIDを設定します。

今回は特定のチャンネルを指定してそのメッセージ履歴を取得するので、IDを引数にベタ書きしました。

ほかのやり方としては、channels.listというAPIメソッドもあり、publicチャンネルIDの一覧がとってこれるのでそれを使うこともできると思います。

conversations.historyではメッセージそれぞれに対するリアクションとして絵文字名とその回数を取得できます。 ここでemoji.listメソッドを使い、絵文字リアクションをカウントアップしていきます。

絵文字一覧の取得

emoji.listメソッドで取得できるのはカスタム絵文字の登録名と画像のURLの一覧です。 Slackに登録されているデフォルトの絵文字は入っていません。

もしカスタム絵文字以外のデフォルトの絵文字でもカウント対象としたい場合は、どうすればよいのでしょうか。

いろいろなやり方があるとは思いますが、今回は、カスタム絵文字データから絵文字名を抽出し、絵文字名をキー、回数(初期値として0)をバリューにした連想配列にしてカウント用の絵文字リストを作りました。

そして、conversation.historyで取得した絵文字リアクションが絵文字リストに含まれている場合はそのままバリューをカウントアップし、含まれていないデフォルトの絵文字の場合は絵文字リストに追加してキーとバリューを登録するようにしました。

これで全絵文字がカウントできるようになりました。

カウントする際に気をつけるポイント

conversations.historyメソッドではとってこれるメッセージ数のlimitとしてMAX1000件となっています。

引数で取得したいデータの期間を設定できますが、1000件以上になると意図した期間のメッセージをとってこれないので気をつけてください。

また、conversations.historyメソッドではスレッド内のリプライは基本的に取得できません。スレッド内のリプライであってもチャンネルに送信すれば、タイムラインに載るためメッセージとして取得します。

あくまでもチャンネルのタイムラインに投稿されているメッセージだけを取得するメソッドなので気をつけましょう。

もしリプライもとりたい場合は、conversations.repliesというメソッドをさらに使用する必要があります。

とってこれるデータや必要な引数がconversations.historyと少し異なりますので、リファレンスのテスターから試して確認してみてください。以下がリファレンスです。

api.slack.com

もう一点気をつけたい点として、SlackのAPIメソッドは定期的にアップデートされるということです。 今回紹介したメソッドが廃止されてほかの名前になっていることもありえます。

例として、conversations.historyメソッドができる前は、channels.historyという名前の別のメソッドだったようです。二次情報の記事の内容は参考程度にして、メソッドが存在するかや必要な権限は自分で確認するようにしましょう。

調査結果

それでは、調査結果を載せていきます。

対象のチャンネルは、以下のとおりです。

  • エンジニア同士の連絡用チャンネル
  • 私の所属するメディア開発1グループ
  • AllAbout IDの開発をおもに手掛けるメディア開発2グループ
  • BMP(ビジネスマッチングプラットフォーム)の開発をおもに手掛ける、マーケティング開発グループ

まずはエンジニア同士の連絡用チャンネルの結果です。

大事な連絡事項が多いチャンネルのためか、『確認中』の意味の目の絵文字リアクションが一位でした。確認済みであることがひと目でわかって便利な絵文字リアクションですよね。

特徴的だったのは、クラッカーの絵文字リアクションがランキングに入っていたことです。

これはリリース完了連絡に対するお祝いやねぎらいの意味合いで使用されているようです。ちょっとした気持ちを伝えられるのも絵文字リアクションのよいところですよね!

また、Slackbotのリマインダー通知に対する『それな。』や『済』の絵文字リアクションがランキングに色濃く反映されていたのはおもしろかったです。

ここからは、開発グループごとの結果を見ていきたいと思います。 私の所属するメディア開発1グループの結果です。

前述の通り、積極的に絵文字リアクションを活用するようにルールとして決めていることもあり、スタンプの総数が多かったです。

『ありがとうございます』や『承知しました』だけでなく、『いいね』や『確認中』の意味の目の絵文字も多く、メッセージに対して絵文字リアクションをとる文化が定着していそうだということがわかりました。 また、自分のメッセージに対して絵文字リアクションをとることで自分の状態を表すといった場合もあるため、人気ランキング10位圏外にも多種多様なカスタム絵文字がありました。

続いて、メディア開発2グループです。

人数が少ないこともあってか、1Gと比べてメッセージ自体も絵文字リアクションの総数も少ないことが印象的でした。

1Gでは報告・連絡・相談は基本的にSlackでやりとりしているのに比べて、2Gでは口頭などのSlack以外のコミュニケーションがメインと考えられます。

Slackでは必要最低限のコミュニケーションをしているように感じました。

人気絵文字リアクションの種類は業務連絡が多いことについては似ていますが、1Gとの違いがわかりますね。

続いて、マーケティング開発グループです。

こちらも人気絵文字リアクションの種類はほかと似ていますが、『ありがとうございます』と『いいね』の絵文字リアクションが大半を占めているのが特徴的でした。

メッセージ自体の数は1Gよりは少ないですが2Gよりも多く、Slackでも活発にやりとりされていることがわかりました。

人気ランキング圏外にも、チーム内で感謝を伝えるときに用いるカスタム絵文字があったりしておもしろかったです。

最後に

今回は社内Slackで使われている人気絵文字を調査してみました!

グループごとに雰囲気や働き方の違いがかなり現れていて、おもしろかったです。

また、APIを使って個人的にデータを分析してみたり集計してみたりといったことは初めて行ったので、よい勉強の機会になったと感じました。

試行錯誤する中で妥協した点至らなかった点もあり、現時点での自分の力を図ることもできてよかったです。

新卒一年目を卒業するということで、これからはインプットだけではなく今回のようなアウトプットの機会も積極的に設けていければと思います。

開発部で1年間働いてみて学んだこと 〜想像よりも幅広かったエンジニアの仕事〜

毎年恒例オールアバウトグループの新卒1年目エンジニアが投稿する企画「テックブログ新卒週間2022」を開催します。

今回は、オールアバウト開発部の@barmがお送りします。

1. はじめに

今年の4月でオールアバウトに入社してから1年が経ちます。 研修を終えた後、All Aboutの会員基盤であるAll About IDの構築に参加し、会員専用ページにデザインを適用したり、既存のサービスから会員専用ページへの導線を追加する実装を主に担当していました。 現在は構築した会員基盤をもとにしたサービスの開発を進めています。

今回の記事では、これらの業務をやってきた中で学んだことを、入社直後に思っていたことと比較して紹介していきたいと思います。

2. 学んだこと

コードを書くことだけが開発じゃない

入社した当初、指示通りのものを作ることがエンジニアの仕事だと想像していました。 実際にそういうこともありましたが、エンジニア側でもどういうものを作ればいいのか、ユーザーが使ったときにどう思うのかを考えながら開発を進めていくことが多かったです。 例えば以下のようなことは話し合われていました。

  • アンケートの入力フォームの送信・修正ボタンの配置はどうあるべきか
  • アンケートに回答し終わったらユーザーはどの画面に戻りたいか
    • マイページなのか、All Aboutのトップページなのか
  • エラーが起きたとき、ユーザーにどう動いて欲しいのか
    • 例えば、同じウェビナーに2回申し込みをされたときに「申し込み済みです」と画面に出すか、エラーページに遷移させるか

ただ指示されたものをコードに書き起こすだけでなくて、どう出来上がると嬉しいかを考えることも開発の一部ということを学びました。

レビューをもらうことの重要さ

自分が書いたコードをチームのメンバーにレビューしてもらうことにはメリットが多いです。 最初は、コードをレビューすることの主な目的はミスがないかのチェックだと思っていました。 ですが、実際にはやりたいことをより効率よく実現できる方法をレビュアーを含めて考え直す機会としてレビューを使用することも多かったです。

実際にあったのは、ほとんど同じ処理を行っている2つのクラスがあって、それを共通化して1つのクラスにするべきか、しないべきかをメンバーで話し合いました。 その時は、同じ処理をしていてもそれぞれのクラスで役割が違うこと、後から読み返した時の理解のしやすさを考慮して共通化しないと決めました。 どうするべきかなかなか決めきれず時間もかかりましたが、最終的に理由をつけた上で方針を決定することができました。

やったことに対して指摘が入ることに抵抗を感じることもありますが、メンバーと話しながらより良いコードにしていく活動は開発する力を高めていく上で重要だと思います。

話し合いながらコードを書いていくことのメリット

オールアバウトでの開発は基本的にはペアプロで行われます。 チームのメンバーとペアを組んで1つのプログラムを書いていきます。 入社するまで、ペアプロをしたことがなかったので、思った以上にペアとずっと話しながら作業しているなと、メンバーのペアプロを見た時に思いました。

はじめてペアプロをした時は、使用している言語や設計に関して持っている知識と、コードを書いていくスピードの違いにメンバーとの大きな差を感じました。

知識に差があるのはどうしようもないので、自分でコードを書く際は具体的なコードの書き方を教えてもらったり、書いたコードに対してアドバイスをもらいながら実装を進めていました。 設計については、どんな設計でアプリを作っていけばいいのかなどを一緒に考えたりすることで、 開発に必要な技術的な知識と後々困らないような設計を考えることの重要さを学びました。

工夫したところとしては、スピードについていけていない、ペアの書いているコードが理解できない時はペアを組んでいる相手にそのことを伝えて、 分からないところや何を考えてコードを書き進めているのかを教えてもらうようにしていました。 こうすることで自分に理解のスピードを合わせてもらえてかつ、学習にもつながりました。

継続してインプットすることの大切さ

日常的にコードを書いたり、アプリを作ったりしていない状態で入社をしたので、勉強するべきことは非常に多かったです。 最初は使用している言語についての知識さえあればいいと考えていましたが、作ったものをサービスとして出していく上でそれ以外の技術も学ぶ必要がありました。 学んだことを列挙すると以下のとおりです。

この中でも特に、Webアプリケーションを作る上で重要な、Webに関わる基本的な技術や、主に使用している言語であるPHPの基本的な書き方は入社する前から触れておいた方がよかったと感じています。

インプットの仕方は、業務中では新しく学んだことをメモして業務終了後に見直していました。 業務外では主に書籍を使って学習を進めていました。 勉強してたことをいくつか挙げておきます。

  • MySQLの練習問題を解く
  • 「独習PHP」を読む
    • 学んだことの共有
    • サンプルコードの写経
  • テスト駆動開発」を読む
    • サンプルコードの写経

まだまだ学ぶべきことは多いのですが、教えてもらうことを理解しやすくなったり、自分でわからないことを調べるときの足がかりになったり、業務を進める上で役に立っていると思います。

3. 終わりに

今年どうだったか

1年目からAll Aboutの新規機能の開発に関わり、自分が何もできない状態であったことを知りました。 開発進める力を自分とメンバーで比較したときに、足元にも及ばないなと感じています。 ですが、業務の中で知識をつけたりメンバーに色々教えてもらう中で学べたことも多かったです。

来年度に向けて

1年ですごく開発ができるようになったわけでもないので、できることを増やせるような活動はしていきたいです。 すぐにできることは本や記事を読んでインプットすることですが、アウトプットする活動も意識してやっていきたいです。 現段階で構想はないのですが、何かアプリを作れるのが一番いいと思っています。 できることを増やして、楽しくサービスの開発することにつながればいいなと思います。