QUO CARD Digital Innovation Lab Tech Blog

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

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

こんにちは、デジタルイノベーションラボで ビルドおじさんを担当している もちだ です。ここ最近の開発言語は HCL です。

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

f:id:quo-digital:20200925182049p:plain

続きを読む

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

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

現在以下の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

リモートでモブプロをやってみて

クオカード デジタルイノベーションラボの飯島、小林、持田、森です。7月末から1月半ほど本格的にリモートでのモブプログラミング・モブ作業を取り入れてみたので、やってみてわかったことを共有します。ちなみに、この記事もモブプロ(モブ作業)で書いています。

背景

入社してからまだ数ヶ月のメンバーがいたこともあり、業務知識を共有するためにペアプロが自然と行われるようになっていました。その流れで、流行のモブプロを導入してはどうかという提案もあり、取り入れることにしました。なお、メンバーにモブプロ経験者はいませんでした。

モブプログラミングとは『モブプログラミング・ベストプラクティス』 から概要を取り上げると、三人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していく手法です。2000 年代には考えられていたが、当時はペアプロの方が主流で、顧みられていませんでした。2015 年くらいにWoody Zuillさんが開発手法として再発見しました。

導入にあたっての不安

モブプロを導入するにあたって、次のような不安がありました。

  • 一つの作業をみんなでやって本当に効率いいの?
  • スキル不足でチームの足を引っ張るのではないか?
  • 個人の成果がだせなくなる(評価)のではないか?

これらの不安がありましたが、いざやってみるとその不安を上回るメリットがあることに気づきました(後述)。

現在の進め方

1日のセッションは次のようなスケジュールで行っています。

  1. 10:30 ~ 10:45 朝会
  2. 11:00 ~ 12:00 モブプロ(20 * 3)
  3. 14:00 ~ 16:40 モブプロ (20 * 4 + 休憩 + 20 * 4)
  4. 16:40 ~ 17:00 反省会

朝会(デイリースクラム)

以前はメンバーがそれぞれ下記に示す内容をデイリースクラム前に Slack で報告して発表するスタイルでした。しかし、モブプロが始まってからは、各自の内容が被ってしまうため、今は朝会の場で参加者全員で確認するスタイルになりました。

  • 前日の成果の確認
  • 当日の目標の確認
  • スプリント計画を達成できそうか確認

モブプロ

このようなルールでモブプロを行なっています。

  1. インターバル20分
  2. 1周したら10分休憩
  3. 役割を定めて行う
    • ドライバー: ナビゲーターに言われたコードを書く
    • メインナビゲーター: ドライバーにやってもらいたいことを言う
    • その他メンバー: アイデア出し、タスク管理(Google docs

インターバル20分

初期は時間を決めていませんでした(キリのいいところまでやっていました)が、人によって時間が偏ってしまうという問題が発生したので時間を区切るようにしました。最初は30分でしたが間延びしている感じがあったため、20分にしてみたところ、スピード感が出ているように感じています。20 分だと時間が短いという意識が入るので、早く交代しようと思うようになりテキパキと開発を進められているからです。

1周したら10分休憩

意外と脳を使っているようなので、休憩しないと集中力が下がって生産性が下がってしまうように感じています。

また、モビングセッションが長時間に渡ってしまい問い合わせがその間に来ていることがあり、その問い合わせに対応するため、この休憩時間を使って Slack を確認(本業である twitter を確認)しています。

役割

モブプロを始めた頃は特に役割を決めておらず、ドライバー(タイピスト)が書いたコードを他のメンバーが追承認するような形になっていました。これはこれでよかったかもしれませんが、議論を活性化したいので、なるべくタイピストの意思で入力しないようなルールをモブプログラミング・ベストプラクティスを参考に定めました。

反省会(レトロスペクティブ)

初期はなにもしていませんでしたが、学習している感覚がなく成長している実感もありませんでした。毎回のモブセッションが改善されていくようにしたかったので、モブプログラミング・ベストプラクティスを参考に反省会を実施してます。

  • 事実の確認(数字で語る)
    • 例:4 つのインターバルで Terraform で設定すべき内容を明らかにできた
  • 肯定的な感想
    • 例 : 実験的なリソースを作成すると Terraform に落とし込みやすい
  • 批判的な感想(人の批判をしない/仕組み的な部分を批判する)
    • 例 : インターバル 30 分は長い/ドライバーの交代がもたついてしまう
  • 建設的な問題解決(解決方法を考えて合意を得る)

モブプロ以外の時間は、調べ物をしたりしています。モブプロでやるべきコーディング作業とかはやりません。

使っている便利なツール

  • くじ五郎
    • モブプロの順番は、自作のくじ五郎という Slack bot を使って朝会の前に決めています。
    • ランダムで mob の順番をシュッと決める

f:id:quo-digital:20200909120824p:plain

メリット

約1ヶ月半、モブプロを継続する中で下記のようなメリットを感じています。

  • コードを共有している感覚が生まれた
    • PR やっている場合に比べて、コードに対する理解度が向上した
    • 個人への依存がなくなり、チームとして保守性が向上した
      • ◎◎さんがいないと対応できないという状況がなくなり、チームとして生産性が向上した
  • プレッシャーが軽減された
    • Terraformによるインフラの構築などを実行する
    • 本番環境へのアプリケーションのデプロイ
  • チームとして幅広い技術を身につけられる
    • 情報共有だけでなく、質問もしやすくなった
    • 他メンバーのツールやショートカットの使い方を知ることができた
    • チュートリアルをモブでやることで、理解度が上がる
      • 一人だとわかった気になって飛ばしちゃう
    • AWS / Terraform / Kotlin / TypeScript / Reactの技術を共有できた
    • クロスファンクショナルなチームがなりつつある

長期的な視野で見ると、突然の出来事にも強く、生産性が落ちない組織になっているように思えます。

最初に書いた通り、始める前にいくつか不安がありましたが、実際にやってみてそれを上回るメリットがあるように感じます。例えば、一つの作業をみんなでやって本当に効率いいの? という不安に対しては、特定の人に任せようみたいなことがなくなり、誰かがいなくても仕事が回るようになりました。

また、スキル不足でチームの足を引っ張るのではないかという不安ですが、質問しやすい雰囲気でモブプロできており、詳しい人もいるし失敗しても取り戻せるという感覚があります。

個人の成果がだせなくなる不安に関しては、チームで成果を出せれば良いと言う上司の理解があり、実は元から解決していました。

デメリット

始めたときには想定していなかった以下のようなデメリットがあることもわかりました。

  • モブプロが終わると結構クタクタになっている
    • 最初は緊張して疲れていたが慣れてきて軽減した
  • プロダクトオーナーが寂しそう(モブプロに遊びに来た)
  • 他のチームとのコミュニケーションが減少した

これらの改善が今後の課題です。

書ききれなかった感想

  • 他の人のコーディング作業を見るのが単純に楽しい
  • 『モブプロ』(kindle) を読むと良い
    • 「誰かの頭に浮かんだアイデアをコンピューターに送り込むためには、まず誰かほかの人の手を通らなければならない」(Llewellyn Falco) に挑戦中
  • 議論がまだまだ足りてない感じがある
  • フルリモートでも、問題なくモブプロできている
  • 慣れるまでは結構疲れる
    • 初日はやばかった、今はちょっとくらい
  • メンバーは4人 ちょうどいい人数

我々はモブプログラミングに対して概ね満足しており、今後も続けていきたいし、より良くしていきたいと思っています。

クオカードでは一緒にモブプロしたいエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。

quo-digital.jp

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

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

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

f:id:quo-digital:20200803184638p:plain
プロダクトバックログを作っている図

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

生成的リサーチ

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

狩野モデル

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

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

経営陣や営業社員など、社内外からの要望がプロダクトオーナーに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の社内勉強会を開催しました

こんにちは。デジタルイノベーションラボに 1 月からお世話になってる 持田 です。

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


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

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

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

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

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

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

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

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

とっぴんぱらりのぷう