リモートでモブプロをやってみて
クオカード デジタルイノベーションラボの飯島、小林、森です。７月末から１月半ほど本格的にリモートでのモブプログラミング・モブ作業を取り入れてみたので、やってみてわかったことを共有します。ちなみに、この記事もモブプロ(モブ作業)で書いています。
背景
入社してからまだ数ヶ月のメンバーがいたこともあり、業務知識を共有するためにペアプロが自然と行われるようになっていました。その流れで、流行のモブプロを導入してはどうかという提案もあり、取り入れることにしました。なお、メンバーにモブプロ経験者はいませんでした。
モブプログラミングとは『モブプログラミング・ベストプラクティス』 から概要を取り上げると、三人以上の人々が１台のコンピューターの前に座って協力しながら問題を解決していく手法です。2000 年代には考えられていたが、当時はペアプロの方が主流で、顧みられていませんでした。2015 年くらいにWoody Zuillさんが開発手法として再発見しました。
導入にあたっての不安
モブプロを導入するにあたって、次のような不安がありました。
- 一つの作業をみんなでやって本当に効率いいの？
- スキル不足でチームの足を引っ張るのではないか？
- 個人の成果がだせなくなる（評価）のではないか？
これらの不安がありましたが、いざやってみるとその不安を上回るメリットがあることに気づきました（後述）。
現在の進め方
1日のセッションは次のようなスケジュールで行っています。
- 10:30 ~ 10:45 朝会
- 11:00 ~ 12:00 モブプロ（20 * 3）
- 14:00 ~ 16:40 モブプロ (20 * 4 + 休憩 + 20 * 4)
- 16:40 ~ 17:00 反省会
朝会(デイリースクラム)
以前はメンバーがそれぞれ下記に示す内容をデイリースクラム前に Slack で報告して発表するスタイルでした。しかし、モブプロが始まってからは、各自の内容が被ってしまうため、今は朝会の場で参加者全員で確認するスタイルになりました。
- 前日の成果の確認
- 当日の目標の確認
- スプリント計画を達成できそうか確認
モブプロ
このようなルールでモブプロを行なっています。
- インターバル２０分
- １周したら１０分休憩
- 役割を定めて行う
- ドライバー: ナビゲーターに言われたコードを書く
- メインナビゲーター: ドライバーにやってもらいたいことを言う
- その他メンバー: アイデア出し、タスク管理（Google docs）
インターバル２０分
初期は時間を決めていませんでした（キリのいいところまでやっていました）が、人によって時間が偏ってしまうという問題が発生したので時間を区切るようにしました。最初は30分でしたが間延びしている感じがあったため、20分にしてみたところ、スピード感が出ているように感じています。20 分だと時間が短いという意識が入るので、早く交代しようと思うようになりテキパキと開発を進められているからです。
１周したら１０分休憩
意外と脳を使っているようなので、休憩しないと集中力が下がって生産性が下がってしまうように感じています。
また、モビングセッションが長時間に渡ってしまい問い合わせがその間に来ていることがあり、その問い合わせに対応するため、この休憩時間を使って Slack を確認（本業である twitter を確認）しています。
役割
モブプロを始めた頃は特に役割を決めておらず、ドライバー（タイピスト）が書いたコードを他のメンバーが追承認するような形になっていました。これはこれでよかったかもしれませんが、議論を活性化したいので、なるべくタイピストの意思で入力しないようなルールをモブプログラミング・ベストプラクティスを参考に定めました。
反省会（レトロスペクティブ）
初期はなにもしていませんでしたが、学習している感覚がなく成長している実感もありませんでした。毎回のモブセッションが改善されていくようにしたかったので、モブプログラミング・ベストプラクティスを参考に反省会を実施してます。
- 事実の確認(数字で語る）
- 例：4 つのインターバルで Terraform で設定すべき内容を明らかにできた
- 肯定的な感想
- 例 : 実験的なリソースを作成すると Terraform に落とし込みやすい
- 批判的な感想(人の批判をしない/仕組み的な部分を批判する)
- 例 : インターバル 30 分は長い/ドライバーの交代がもたついてしまう
- 建設的な問題解決(解決方法を考えて合意を得る)
モブプロ以外の時間は、調べ物をしたりしています。モブプロでやるべきコーディング作業とかはやりません。
使っている便利なツール
- くじ五郎
- モブプロの順番は、自作のくじ五郎という Slack bot を使って朝会の前に決めています。
- ランダムで mob の順番をシュッと決める
- mob cli
- https://github.com/remotemobprogramming/mob
- git 管理のソースをいじる時に、driver の交代とかをシュッと実現できる
- starting-new-session シェルスクリプト
- https://github.com/mike-neck/starting-new-session
- ブランチの作成 + initial commit + PR 作成をシュッと実現できる
メリット
約1ヶ月半、モブプロを継続する中で下記のようなメリットを感じています。
- コードを共有している感覚が生まれた
- PR やっている場合に比べて、コードに対する理解度が向上した
- 個人への依存がなくなり、チームとして保守性が向上した
- ◎◎さんがいないと対応できないという状況がなくなり、チームとして生産性が向上した
- プレッシャーが軽減された
- Terraformによるインフラの構築などを実行する
- 本番環境へのアプリケーションのデプロイ
- チームとして幅広い技術を身につけられる
長期的な視野で見ると、突然の出来事にも強く、生産性が落ちない組織になっているように思えます。
最初に書いた通り、始める前にいくつか不安がありましたが、実際にやってみてそれを上回るメリットがあるように感じます。例えば、一つの作業をみんなでやって本当に効率いいの？ という不安に対しては、特定の人に任せようみたいなことがなくなり、誰かがいなくても仕事が回るようになりました。
また、スキル不足でチームの足を引っ張るのではないかという不安ですが、質問しやすい雰囲気でモブプロできており、詳しい人もいるし失敗しても取り戻せるという感覚があります。
個人の成果がだせなくなる不安に関しては、チームで成果を出せれば良いと言う上司の理解があり、実は元から解決していました。
デメリット
始めたときには想定していなかった以下のようなデメリットがあることもわかりました。
- モブプロが終わると結構クタクタになっている
- 最初は緊張して疲れていたが慣れてきて軽減した
- プロダクトオーナーが寂しそう（モブプロに遊びに来た）
- 他のチームとのコミュニケーションが減少した
これらの改善が今後の課題です。
書ききれなかった感想
- 他の人のコーディング作業を見るのが単純に楽しい
- 『モブプロ』(kindle) を読むと良い
- 「誰かの頭に浮かんだアイデアをコンピューターに送り込むためには、まず誰かほかの人の手を通らなければならない」(Llewellyn Falco) に挑戦中
- 議論がまだまだ足りてない感じがある
- フルリモートでも、問題なくモブプロできている
- 慣れるまでは結構疲れる
- 初日はやばかった、今はちょっとくらい
- メンバーは4人 ちょうどいい人数
我々はモブプログラミングに対して概ね満足しており、今後も続けていきたいし、より良くしていきたいと思っています。
クオカードでは一緒にモブプロしたいエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。
プロダクトバックログの作り方
クオカード デジタルイノベーションラボでプロダクトオーナーをしている齋藤です。
今回はどのようにプロダクトバックログを作っているかを説明します。
主に以下のような情報をもとにプロダクトバックログを作成しています。スピード感を大切にしつつ、一部の声の大きい意見のみに左右されることが無いよう、ユーザーテストなどで本当にその機能を実装した方が良いか確認しながら進めるようにしています。
生成的リサーチ
想定ターゲットにインタビューを行い、現状のペインポイントやゲインポイントとなる部分を確認し機能案を作成します。その後改めてその機能が有用なものかの調査を行う場合もあります。
狩野モデル
不定期にアンケート調査を行い、優先順位づけや実装可否など意思決定のインプットにしています。
社内からのフィードバック
経営陣や営業社員など、社内外からの要望がプロダクトオーナーに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 回くらいは勉強会を開催したいと思っています。クオカードではエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。
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日間サービスを停止して実施しました。お客様にご迷惑がかかる可能性があるので可能であれば無停止で行いたかったですが、予期せぬトラブルが発生しても対応できるよう今回はサービス停止を選択しました。 ある程度余裕を持ったスケジューリングだった為、リリース中に細かい問題が発生しましたが無事対応して予定時間前にリリースすることができました。
今回はまず内製ができる環境を作るというところが目的だったため問題を全て解消するという事はできませんでしたが、今後改善して行きたいと思います。 そのためにエンジニアを募集しています。
IntelliJの社内勉強会を開催しました
つい先日、社内勉強会で IntelliJ IDEA のショートカットとか使い方とかのレクチャーをしたので、その内容について紹介します。読むのにかかる時間は 3 分くらいを目指してます。
ここのところ、デジタルイノベーションラボではペアプログラミングやモブプログラミングを積極的に取り入れています。 そしてメンバーと一緒に数時間ほどして、メンバーが IntelliJ IDEA の操作に習熟できていないような印象を持ちました。 ペアプロ、モブプロの中で指摘してもいいのだけど、そうすると取り組みたい本質的な問題に集中できないように思われました。 そこで別途 IntelliJ IDEA の使い方講習を行う流れにしました。
そのときの資料がこちらになります。
内容を雑にまとめると、以下のような IntelliJ ならではのキーマップ・機能を覚えておくと便利です。
- 機能そのものを検索する(
⌘+⇧(shift) +A) - コードの問題点をいい感じに修正する(
⌥+Enter) - 名前のイニシャルを入力すれば絞り込んでくれる
では、ここでブログを書く人をバトンタッチして、実際の受講者に話しを聞いてみましょう。
こんにちは。デジタルイノベーションラボに 2019 年の 7 月からお世話になっている飯島です。
自分は元々 Emacs を使っていたこともあり、IntelliJ も Emacs キーバインドにして使用していましたが、持田さんの勉強会に参加してからすぐにデフォルトに戻しました。 特殊なキーバインドにしていると、特定のショートカットキーがオーバーライドされて存在しなくなってしまうことがあるからです。 また、デフォルトにしておくと便利なショートカットキーを簡単に口伝できるというメリットもあります。 IntelliJ インストール後にいちいちキーバインドの設定をする必要もありません。 あとこれが一番の理由かもしれませんが、Mac は最初から特定のキーマップが Emacs と同じため、デフォルトにしていても文字の編集操作がやりやすいというのがあります。 （デジタルイノベーションラボでは基本的に入社時点で最新の MacBook Pro が支給されます）
勉強会では数あるキーマップの中から持田さんセレクトで便利なモノを紹介してもらいましたが、自分が一番使うようになったのは 「⌘ + ⌥ + B」 です。 interface の実装クラスや実装メソッドを検索して飛ぶことができます。 「⌘ + B」と併せて使用することでソースコードを深く速く追っていけるようになりました。 キーマップは覚えなくても何とかなるので学習を後回しにしがちですが、知っているか知らないかでここまで効率に差が出てくるならば早めに覚えた方が良いと思いました。
とっぴんぱらりのぷう
QUOカードPayのモバイルアプリで利用している技術
デジタルイノベーションラボのゴルゴです。
今回はQUOカードPayのモバイルアプリで利用している技術を紹介します。
Androidアプリ
MVVM+Clean Architectureパターンで実装しており、以下のような技術・サービスを利用して開発しています。
言語: Kotlin 100%
ライブラリ: Rx, Retrofit2, Glide, Koin, Coroutine, Epoxy, Firebase
テスト: JUnit, Spek, Mockito, Espresso, Spoon
CI/CD: Bitrise
よくあるパターンなので特筆するところはそれほどないですが、開発当初の開発メンバでDagger2に慣れているものがいなかったので、習得しやすいKoinを採用しました。ハマることもなくすんなりと使えたので良かったです。ただ、KoinはInjectするオブジェクトを動的解決するので実行時エラーになるリスクがあり、今後も使い続けるかはわかりません。Dagger2のように静的解決してくれる、KotlinネイティブのDIツールの登場を待っていたのですが、どうやらDagger2がGoogle公式の推奨DIツールがなったようなので、本腰を入れて調べています。
また、Coroutineは当初experimentalだったこともあって非同期処理は主にRxで実装しており、今の所部分的にしかCoroutineは使っていません。
CIにはBitriseを利用しているのですが、モバイルアプリ向けに特化されていて使いやすいです。自作のSlack Bot、GitHubと組み合わせることで、Slackからメンションを飛ばすとストアへのアップロードまで自動で行われるようにしています。
iOSアプリ
MVP + Clean Architectureパターンで実装しており、以下のような技術・サービスを利用して開発しています。
開発言語: Swift5
ライブラリ: Rx, Moya, Nuke, R.swift, Realm, Firebase
テスト: XCTest, swift-snapshot-testing
ライブラリ管理: Carthage, CocoaPods
CI/CD: Bitrise
iOSアプリではAndroidアプリと比べてMVVMを採用した場合のRxSwiftへの依存度が高くなる等があった為、MVP + Clean Architectureを採用しました。 通信ライブラリにはAlamofireのラッパー的なMoyaを使うことでdebug時はスタブを利用するようにしています。 リソースファイルへのアクセスはR.swiftを使用しているので、プロパティとして取得できるためtypoがなくなりました。
CIはAndroidアプリ同様にBitriseとSlack Bot、Githubと組み合わせてSlackからApp Store ConnectへIPAアップロードを自動化しています。
設計
iOSとAndroidはそれぞれネイティブ実装していますが、ドメイン層に用意するUseCaseやRepositoryの設計は出来るだけ揃えることで相互のエンジニアがレビューしやすいようにしています。
プロダクトグループの評価制度
デジタルイノベーションラボの齋藤です。
クオカードは2019年4月から人事制度を変更しました。クオカードは30年以上の歴史があり、人事制度も今までパッチを当てて対応してきましたが、根本から整理するという事になり2018年の1年間をかけて整理を行いました。
通常であればデジタルイノベーションラボ所属のエンジニア/デザイナーもその新人事制度を導入するところだと思いますが、デジタルイノベーションラボはQUOカードPay立ち上げの為に今までクオカードにはいなかったアプリやサーバーサイドのエンジニアが所属しており、他部署と同じ評価制度で進めるのは適切でないのではないかと考え、独自の評価制度にさせていただきました。
また最近主に海外で人事評価制度を廃止する会社も出てきており、それを踏まえてデジタルイノベーションラボのエンジニア・デザイナーの人事制度を以下の通り作成しました。
年次の目標は策定しない
期待値との大きな乖離が無く、成果が出れば翌年度に1段階昇格
期待値との大きな乖離がある場合は、それ以上の昇格/降格もある
期待値とのズレは半期に1度のフィードバックではなく、毎週の1on1で伝える
能力ではなく、成果で判断する
それぞれを作った背景です。
年次の目標は策定しない
デジタルイノベーションラボはQUOカードPayという新規事業の為の組織です。QUOカードPayはまだ立ち上げフェーズの為、またスマホ決済は数ヶ月もすると環境が大きく変わってしまう為、年始に目標を立てても年末までに有効ではない目標になっている事があります。またデジタルイノベーションラボはできるだけ自走できる組織を目指している為、ゴールを共有し全員それを実現させることを目標としたいと考え、年次の目標は策定しないことにしました。
期待値との大きな乖離が無く、成果が出ていれば翌年度に1段階昇格。
公正・公平な人事評価は非常に難しく、また納得感の無い評価が退職理由になることも多いのではと考えています。また評価を気にして上司や同僚との議論を避けたり、評価に最適化された行動を取ってしまうのを避け、仕事自体に集中できる環境を作りたいと考え、このような形としました。副効用ですが、被評価者・評価者両方の目標設定・評価の時間がだいぶ削減できるとも考えています。
期待値との大きな乖離がある場合は、それ以上の昇格/降格もある。
期待を大きく超えて活躍した場合は1段階と言わず数段階昇格できるようにしました。
期待値とのズレは半期に1度のフィードバックではなく、隔週の1 on 1で伝える
なるべく早いフィードバックにより、双方の期待していること/やりたいことを調整したいと考えています。
能力ではなく、成果で判断する
例えば能力が非常に高いメンバーがいても成果が全く出ていなかったら貢献しているとは言えないと考えこのようにしました。
一旦このような形にしましたが、今後運用していく中で改善していければと考えています。