QUO CARD Digital Innovation Lab Tech Blog

クオカード デジタルイノベーションラボの技術ブログです

GitHub Actions の composite run steps action を 試してみた

今回はちょっと前(2020 年 8 月 7 日)に公開された GitHub Actions の composite run steps action を 試してみました。これは Dockerfile や node js のコードを書かなくても(書けなくても) 通常の GitHub Actions のワークフロー YAML が書ければ、 action を作成・公開できるという仕組みです。

続きを読む

デジタルイノベーションラボのチーム構成

今回はデジタルイノベーションラボのチーム構成について書きます。

現在以下の4チーム体制になっています。

  • QUOカードPayチーム(3名)
  • QUOカードPay ECチーム(2名)
  • 新規プロジェクトチーム(5名)
  • 運用チーム(3名)
  • UI/UXチーム(2名)

UI/UXと運用チーム以外はスクラムで進めており、コーディング作業はペアプロ/モブプロを中心に進めています。

QUOカードPayチーム

QUOカードPayのサービスイン前後からいる古株が集まったチームです。 主に以下の開発を行っています。

サービスインに向けて急ぎ作った箇所もあるので、今後の長期の運用に耐えられるよう、新しい技術を取り入れる等して、自動化やブラッシュアップを進めています。 例えば、最近ではCircleCIからGitHub Actionsに完全移行するなどしました。

モバイルアプリで利用している技術 (https://quo-digital.hatenablog.com/entry/2020/01/27/124302)

バックエンドで利用している技術 (https://quo-digital.hatenablog.com/entry/2020/01/20/131409)

QUOカードPay ECチーム

QUOカードPay オンラインストア(https://pay.quocard.jp/)を担当しています。QUOカードPay オンラインストアは最初は外注で構築し内製化をしました。経緯はこちら(https://quo-digital.hatenablog.com/entry/2020/07/03/130141) ゼロから社内で構築したものはKotlinで作っていますが、こちらはJavaで構築したものを徐々にKotlin化しようとしています。また技術的には色々と改善したいものが残っている状態なので、機能追加や仕様変更の対応を行いつつ徐々に改善を進めています。

一般のECサイトとは少し異なり、法人の顧客の方が多く生のフィードバックも得られやすいため、仕事の成果が目に見えて実感できます。 現在、QUOカードPay ECチームはスクラムの開発チームとしては最小とされる3人を下回っているため、一緒に働くメンバーを募集しております。

新規プロジェクトチーム

QUO カード Pay のバックエンドを改善・再構築して QUO カード Pay ビジネスを柔軟かつ迅速に進化するために日々躍進しているチームです。しかし、今のところ大した成果を上げていないので日陰者のような生活をしています。 基本的には他のチームと同様に、Kotlin アプリケーションを Terraformで構築した ECS クラスタ上で動かすようなシステムの構成になる予定です。 これまたほかのチームと同じですが、2 週間のスクラムをチーム全体の仕掛中の作業が複数にならないようにモブプログラミング・モブ作業の形態で取り組んでいます。モブ〜の取り組みについては、以前書いた記事(https://quo-digital.hatenablog.com/entry/2020/09/09/121233) を参照していただけると詳細がわかると思います。

運用チーム

QUOカードPayに関わる様々な運用作業を担当しているチームです。 定期的な作業や非定期な依頼をはじめとして、各部署やQUOカードPayをご利用されている企業様からのお問い合わせや、システムの障害にも対応しています。 運用チームのモットーは「安全・安心・確実」と「運用改善」で、「縁の下の力持ち」を目指して日夜奮闘中です。 突発的な業務が多く、現在はカンバンのような形で進めていますが、将来的には各スクラムチームに合流する予定です。

UI/UXチーム

QUOカードPayのユーザー体験の改善をするために、ユーザーへの調査を実施し、調査より浮かんできた問題点や改善点を明確化し、より良い体験へアプローチするデザインを作りエンジニアと二人三脚でサービスに落とし込んでいくチームです。 ユーザーの声を幅広く知るため、コールセンターとも連携し、お客様の声を汲み取り、より良いサービスデザインを目指します。 また、企業のプロモーション企画にQUOカードPayを採用してもらうための企業調査や、マーケティングチームとの連携もしていきます。

クオカードでは現在エンジニアを募集しています。

quo-digital.jp

プロダクトバックログの作り方

クオカード デジタルイノベーションラボでプロダクトオーナーをしている齋藤です。

今回はどのようにプロダクトバックログを作っているかを説明します。

プロダクトバックログを作っている図

主に以下のような情報をもとにプロダクトバックログを作成しています。スピード感を大切にしつつ、一部の声の大きい意見のみに左右されることが無いよう、ユーザーテストなどで本当にその機能を実装した方が良いか確認しながら進めるようにしています。

生成的リサーチ

想定ターゲットにインタビューを行い、現状のペインポイントやゲインポイントとなる部分を確認し機能案を作成します。その後改めてその機能が有用なものかの調査を行う場合もあります。

狩野モデル

不定期にアンケート調査を行い、優先順位づけや実装可否など意思決定のインプットにしています。

社内からのフィードバック

経営陣や営業社員など、社内外からの要望がプロダクトオーナーにSlackで届くようになっているので、こちらもインプットとして利用しています。

エンドユーザーからのフィードバック

コールセンターやアプリのレビューなどを確認しています。

開発チームからの改善提案

テストツールの導入など、主にシステム面の改善提案が上がってきます。開発中に気づいたバグの中で、緊急度が高いもので工数が大きくかからないものはスプリント内で20%程度はスプリント外の作業をすることにしているのでそこで対応、そこで吸収できないものはプロダクトバックログに記載し優先順位を付けて対応しています。

主に上記のインプットをもとに、何をすれば競争優位性が高まるか、また自社のポジショニング的に内部化する必要があるかなどを検討し実現可否や優先順位付けを行なっています。例えばQUOカードPayは個人でも購入できますし個人の方からの購入は大歓迎ですが、メインのターゲットはセールスプロモーションを行う企業になります。その為機能の優先順位を付ける場合はまずセールスプロモーションを行う企業のペインポイントやゲインポイントを考慮し進めています。

作成したプロダクトバックログはジャストインタイムで詳細化しており、長期的なロードマップは作成しないという方針で進めています。競争環境が変化する為、随時優先順位を組み替えて行くべきという背景でそうしています。

失敗した点

「非技術系のステークホルダーにとって、バーティカルスライスは一般に理解したり確認したりするのが容易で、ビジネス価値を評価しやすいものである。バーティカルスライスはチームにとって、リリースを早め、実際のビジネス価値とリアルなユーザーフィードバックを実現するための選択肢を増やすものとなる。」

Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標 (Japanese Edition) (Kindle Locations 2351-2353). Kindle Edition.

上記のようにMore Effective Agileで書かれている通り、スクラム導入時にホリゾンタルスライス(エンドツーエンドで開発を進める形)で進めようとしましたが、今までの進め方がバーティカルスライスだったためスムーズに移行ができませんでした。そのためプロダクトバックログバーティカルスライスを意識したものになってしまっていました。現在は極力バーティカルスライスで進めるようにしています。

工夫した点

全ての作業をプロダクトバックログで管理する形にすると開発中に見つけた細かいバグや問い合わせなどの対応が全て翌スプリントになってしまうので、スプリントの20%程度はそのような作業に充てる事にしています。ツールやライブラリの調査もその時間を使えるようにしています。

社内Terraform勉強会を行いました

クオカード デジタルイノベーションラボの齋藤です。

先日社内でTerraform勉強会を行いました。

現在エンジニアが15人程所属していますが、それぞれアプリやバックエンド、インフラ等強みが異なっています。 今までTerraform修正等インフラ作業は主にインフラエンジニアが行なっていましたが、バックエンドとインフラ担当者間で認識の齟齬や連携漏れ、特定の部分でボトルネックが発生するような事がありました。 ボトルネックの発生や連携漏れなどを減らしていくためできるだけ各メンバーが複数の役割を担える事にしたいと考え、社内でTerraform勉強会を行うことにしました。

今まで全くTerraformを触った事が無いメンバーもいるので基本的な所からはじまり、現在のコードを理解する為に必要な知識について下記の通り説明してもらいました。

  • terraform のインストール
  • terraform の各コマンド
  • tfstate ファイルの扱い
  • モジュールの構成の仕方
  • tf ファイルの書き方

以下資料です。

https://qiita.com/kobayashi-m42/items/247cf9708044db8a234e

現在全員フルリモート勤務となっているので、Zoomで行いました。 リアルタイムでリアクションや質問があったので、オンラインでも進めやすかったそうです。

このような感じで、ラボでは月に 1 回くらいは勉強会を開催したいと思っています。クオカードではエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。

https://quo-digital.jp/

QUOカードPay オンラインストアを内製化しました

2020/6/24にQUOカードPay オンラインストア(https://pay.quocard.jp/)を内製化しました。

今回はその背景や内容について記載します。

背景

QUOカードPay オンラインストアは最初のローンチ時はエンジニアの手が足りていなかった為外注で構築し、運用も外注していましたが、スピード感を持って機能追加や改善を進める為内製化することにしました。 また元々EC2などマネージドではないサービスを利用していましたが、運用の効率化の為ECSなどマネージドなサービスを利用する形に変更しました。

技術的な変更点

言語

Javaで作られていましたが、部分的にKotlinを導入しました。今後も順次Kotlin化を進める予定です。

インフラ

EC2でしたが、ECS(Fargate)に変更しました。またストレージとしてEFSを使っていましたが、疎結合にするためS3に変更しました。

テスト

ほぼ手動でテストを行う形でしたが、実装の変更による影響を素早く検知して対応するために自動テストは必須であると考えています。その為、徐々に自動化を進めようとしています。できればUnit Testを用意する形にしたいのですがテストするために大幅なリファクタリングが必要になるところが多い為、まずはE2Eのテストを用意した後に書き換えを進めようとしています。

バッチ

JP1から起動する形でしたが、AWS Step Functionsを利用する形に変更しました。また夜間バッチである必要の無いものは徐々にオンライン化する、または営業時間に実行する形にするなどを検討しています。

監視

DataDog,Sentryを導入しました。また1次対応はMSP(外部の監視・運用会社) にお願いしています。

期間

10人程度で約5ヶ月で完了しました。 ブルックスの法則を避ける為、最初から全員参加する形にしました。

リリース

営業日に2日間サービスを停止して実施しました。お客様にご迷惑がかかる可能性があるので可能であれば無停止で行いたかったですが、予期せぬトラブルが発生しても対応できるよう今回はサービス停止を選択しました。 ある程度余裕を持ったスケジューリングだった為、リリース中に細かい問題が発生しましたが無事対応して予定時間前にリリースすることができました。

今回はまず内製ができる環境を作るというところが目的だったため問題を全て解消するという事はできませんでしたが、今後改善して行きたいと思います。 そのためにエンジニアを募集しています。

https://quo-digital.jp/

IntelliJの社内勉強会を開催しました

つい先日、社内勉強会で IntelliJ IDEA のショートカットとか使い方とかのレクチャーをしたので、その内容について紹介します。読むのにかかる時間は 3 分くらいを目指してます。


ここのところ、デジタルイノベーションラボではペアプログラミングやモブプログラミングを積極的に取り入れています。 そしてメンバーと一緒に数時間ほどして、メンバーが IntelliJ IDEA の操作に習熟できていないような印象を持ちました。 ペアプロ、モブプロの中で指摘してもいいのだけど、そうすると取り組みたい本質的な問題に集中できないように思われました。 そこで別途 IntelliJ IDEA の使い方講習を行う流れにしました。

そのときの資料がこちらになります。

内容を雑にまとめると、以下のような IntelliJ ならではのキーマップ・機能を覚えておくと便利です。

  • 機能そのものを検索する( + (shift) + A)
  • コードの問題点をいい感じに修正する( + Enter)
  • 名前のイニシャルを入力すれば絞り込んでくれる

では、ここでブログを書く人をバトンタッチして、実際の受講者に話しを聞いてみましょう。

こんにちは。デジタルイノベーションラボに 2019 年の 7 月からお世話になっている飯島です。

自分は元々 Emacs を使っていたこともあり、IntelliJEmacs キーバインドにして使用していましたが、持田さんの勉強会に参加してからすぐにデフォルトに戻しました。 特殊なキーバインドにしていると、特定のショートカットキーがオーバーライドされて存在しなくなってしまうことがあるからです。 また、デフォルトにしておくと便利なショートカットキーを簡単に口伝できるというメリットもあります。 IntelliJ インストール後にいちいちキーバインドの設定をする必要もありません。 あとこれが一番の理由かもしれませんが、Mac は最初から特定のキーマップが Emacs と同じため、デフォルトにしていても文字の編集操作がやりやすいというのがあります。 (デジタルイノベーションラボでは基本的に入社時点で最新の MacBook Pro が支給されます)

勉強会では数あるキーマップの中から持田さんセレクトで便利なモノを紹介してもらいましたが、自分が一番使うようになったのは 「⌘ + ⌥ + B」 です。 interface の実装クラスや実装メソッドを検索して飛ぶことができます。 「⌘ + B」と併せて使用することでソースコードを深く速く追っていけるようになりました。 キーマップは覚えなくても何とかなるので学習を後回しにしがちですが、知っているか知らないかでここまで効率に差が出てくるならば早めに覚えた方が良いと思いました。

とっぴんぱらりのぷう