Mobile Factory Tech Blog

技術好きな方へ!モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします!

社内勉強会を丁寧に改善し、フルリモートでシナジーを生み出す

この記事はCTOA Advent Calendar 2020モバイルファクトリー Advent Calendar 2020 の24日目の記事です。また先日のGaiax Technical Meetupsの登壇内容を元にした内容になります。


こんにちは。エンジニア組織開発責任者のkobaken(@kfly8)です。
明日はクリスマスですね。娘4歳はサンタさんにレゴをリクエストしていました。届くといいですね😊

今年の2月から、モバファクは新型コロナの影響でフルリモートの働き方に変わりました。
その影響もあり、組織開発観点では社内のコミュニケーションに課題を感じた1年となりました。

エンジニア組織に限らず、組織全体において、

  • 「他のチームがどんなことをしているのかわからない」
  • 「どんな人かわからなくて、話かけづらい」
  • 「さみしい..!」

なんて声を聞きました。特に、今年入ったメンバーからはよく聞きました。
新人の1人に聞くと、定期的に雑談する工夫をしたそうです。

tech.mobilefactory.jp

そんな話を聞くと、個人やチームの工夫があって組織はうまくいっていることを改めて感じます。一方、組織開発の担い手として、前提が変わってしまったことによる組織課題を丁寧に解決することが求められました。例えば、オンボーディング、リモートワークでのコミュニケーション、1on1、エンゲージメント改善のためのガイドや新人研修といった研修プログラムのオンライン化、新しい働き方に合わせた人事制度・福利厚生の改変などが挙げられます。

前置きが長くなりましたが、こういった組織開発の一環として、社内勉強会の改善事情について書きたいと思います。社内勉強会はスキルアップに注目されがちだと思いますが、コミュニケーションを促進し、シナジーを生み出す実感があり、フルリモートならではの課題をいくらか解決する施策だと思います。シナジー効果により、1人で達成できないことを組織で協力して達成しやすくなっていると嬉しいですよね。

他方で、社内勉強会の運用は良いことだけでなく問題もたくさんありました。運用に悩んでいる方もいらっしゃると思います。どう改善したのか一つの事例として読んでもらえればと思います。

モバファクの社内勉強会の概要

モバファクの社内勉強会は、1日1時間、コアタイム外はいつ誰でも勉強会して良い制度です。名前は「シェアナレ!」です。
最近だとこんな勉強会がありました。

  • 最強の〇〇環境プレゼン大会
  • エラー設計ワーキンググループ
  • スクラムガイド2020読書会
  • TCPにダイブ!
  • Certified Jenkins Engineer 2020になるまで
  • UX探検隊

f:id:kfly8:20201224100744p:plain:w300
先週金曜日に開催された勉強会

先週金曜日に開催されていた"最強の〇〇環境"と題したLT会では、最強のノマド環境、最強のインターネット環境、最強の育児環境といった話をしていました。最近だと、アドベントカレンダー執筆のためのもくもく会が多く開催されていたりします。おとといは今年1年をふりかえるエンジニアのLT会がありました。

現状のモバファクの社内勉強会の状況を簡単にまとめると、次のような具合で組織にいくらか浸透していると感じます。

  • 盛んに開催されている
  • 10年以上続いている
  • 知識を得るだけでなく、お互いを知る場にもなっている

問題はたくさん

現状、ほぼ毎日開催され、いくらか組織に浸透しているとは思いますが、問題はたくさんありました。中には現在も進行形の問題もあります。勉強会を運営している人にとって、身に覚えのある問題もあると思います。

f:id:kfly8:20201224100937p:plain:w500
問題は複雑に絡み合っている

こういった組織の問題を分析する時、面白い所が、一つの原因があるわけではなく、互いに繋がっていて原因をたどろうとしてもうまくいかないところです。典型的な悪手は、誰かのせいにすることです。全員にとっての100点はないですが、どうなったら嬉しいか、少しずつ改善していくことが解決の糸口だと思います。

丁寧に解決し続ける

行ったことのポイントは次の4つです

  1. 地続きのコミュニケーション
  2. 仲間を巻き込む
  3. サーベイ。そして対話
  4. 草の根活動

1. 地続きのコミュニケーション

勉強会で話を聞いたら「ハイ!おしまい!」でなく、勉強会の始まる前から終わった後まで地続きでコミュニケーションを設計すると良いと思います。

例えば、誰かがいいアウトプットをしたなら、イイネと素直な気持ちを表明する。めんどうなことは続かないですが、イイネといったちょっとしたリアクションが話した人のやる気や、社内勉強会の活性化に貢献すると思います。

f:id:kfly8:20201224101130p:plain:w300
社内バズ?みたいなこともある

最近だと「スクラムガイド2020でましたね」と誰かがチャットで話せば「一緒に読みますか」といった話に繋がっていました。

勉強会の場だけでなく、会社の中に会話が溶け込むのが理想だと思います。

2. 仲間を巻き込む

あーしようこうしようと一人相撲をしても、当たり前ですが文化はできないです。社内勉強会の文化を改善していくにあたり、公募で運営メンバーを募りました。どの施策よりも効いたと思います。運営メンバーの皆には感謝です。

運営の仲間を巻き込む狙いは2つありました。

1つ目の狙いは、自分ごとにする現場目線での発信です。それまでは管掌部署のヒューマンリレーションズ部が発信していましたが、メンバーの話を聞くと発信を自分ごとにしにくかった面が正直ありました。会社にはいろんな人がいるので、誰が伝えるかで伝わり方も変わると改めて感じました。同じ現場の人が、会社を良くするために前向きに取り組みをしていたら、良い刺激を受けるんじゃないかと思います。

2つ目の狙いは、文化の担い手づくりが狙いです。組織を変えられる実感を持つ人が増えた方が、自分たちの会社をハンドメイドする感覚が持てて楽しいんじゃないかと思います。そんな実感なく、将来、組織を良くしてくださいと言われても、どこからどうすればいいか困ると思います。組織開発をじっくり実践する場になればと思っています。

こうやって、少しずつ仲間を巻き込んでいきたいです。

3. サーベイ。そして対話

これも当たり前ですが、当てずっぽうで施策を打つわけにはいきません。どれだけ社内勉強会を薦めたいかNPSとフリーコメントを集めて、運営チームで”診断型組織開発”、つまりデータを観察し、対話しながら解釈をして、仮説をたて、改善のアクションにに繋げるといったことをしていきました。

f:id:kfly8:20201224102116p:plain:w400
徐々に良くなってきている

サーベイの結果を見て、杓子定規に受け取るのではなく、どういう意味があるのか対話をしていきます。例えば、5点が多いのはなぜか?8点は多いけれど、9点が少ないのはなぜか?推奨となるとためらう気持ちが生まれやすいのか?解釈を話します。

同時に、どんな勉強会でありたいかといった話も混じえます。何というか眉間にシワを寄せて話し合っても、勉強会の楽しい雰囲気を作れないと思います。何が好きか、やりたいか、こういった価値観の要素は制度・仕組みの設計以上に育てにくいところなので、大切に拾っていきたいと思っています。

4. 草の根活動

ここまでおおよそ制度・仕組みの改善ですが、やはり、草の根活動はあります。例えば、発表できそうな人を探す、定期イベントを開催する、新人研修に組み込むといったことをしています。

例えば、参加しやすく、発表しやすくを狙いに、社内カンファレンスを開催しています。5月に開催された「新人研修では聞けない〇〇な話」では、キャッチーさ・お祭り感を演出しています。

f:id:kfly8:20201224110203p:plain:w300
ちょっとしたお祭り感のある勉強会も開催

全部が全部こんな感じで頑張ると大変ですが、フルリモートの世界観になって、お互いの気配を感じにくくなっているので、お祭り感の演出も大切かなと思っています。今は部屋の移動もなくサクッと勉強会に参加できて、それこそ、ながらで参加することもできるので社員の半数が参加することもあります。皆の様子が見えるのは安心感が生まれると思います。


運営として、意識していること

施策の例を挙げてきましたが、当然、状況次第で施策も異なると思います。また、制度・仕組みといったハード面での改善実例を中心に挙げていますが、そこからきちんと運用し続け、文化・価値観といったソフト面で根付くことが本質的に大事だと思います。そのためにも、どういったことを意識しているのかを書いて終わりにしたいと思います。

  1. 元々の文化を活かす
  2. 余裕を持つ
  3. 丁寧に。丁寧に。

1. 元々の文化を活かす

モバファクの社内勉強会の場合「話したいから話す」といった自主性に根ざした色があります。そういった色は簡単には出来上がらず、貴重な価値だと思います。運営が良かれと思った改善としても、文化を殺していないか、様子の観察は忘れないようにしたいです。

2. 余裕を持つ

会社でやっていることなので、効果、成果を求めるところはあります。個人的にも事業インパクトを生み出す事例が生まれないかと楽しみではあります。ですが、求めすぎ余裕がなくなると、発表のハードルが上がり、参加へのプレッシャーが大きくなり、制度の存在意義が不明瞭になります。フルリモートの今なら、チームを超えたコミュニケーションを促せるなら良しと捉え、いい意味で無駄を楽しむ方が良いのかなと思っています。

3. 丁寧に。丁寧に。

組織を変化させるには、丁寧さが必要だと思います。丁寧というのは、実態を見て解決の手立てを考えることや、繰り返し伝えていくことです。組織には多くの人がいて感じ方も人それぞれなので、全員が満点になることはないです。例えば、今年フルリモートに舵を切り、覚悟を持って断行した企業もあると思います。会社のために良かれとやっていることだと思います。だとしても、ぞんざいにして良い理由はなく、変化に適応することは負担になるので、丁寧に、丁寧に行うことを意識しています。

まとめ

組織開発の一環として、社内勉強会の改善事例をお伝えしました。社内勉強会は、スキルアップといった側面だけでなく、お互いを知りシナジーを生み出すコミュニケーション効果もあります。また、仕組みがあればうまくいくものではなく、その運用改善のため、丁寧に自分たちの文化となるよう解決を進めています。

関連

一つ一つの具体的な施策を広報がインタビューしてくれています。よければこちらもご笑覧いただければと。
corpcomn.mobilefactory.jp corpcomn.mobilefactory.jp corpcomn.mobilefactory.jp corpcomn.mobilefactory.jp


明日は最終日ですね!明日の記事は、CTOAアドベントカレンダーはCTOA代表理事の松岡剛志さん、 モバファクのアドベントカレンダーは、id:odan3240です。お楽しみに!

Androidアプリの動作確認をAWS Device Farmで自動化してみた

この記事はモバイルファクトリー Advent Calendar 2020 23日目の記事です。


こんにちは、id:nesh です。

はじめに

今回の記事は2年前の記事と関連して、モバイルアプリのテストを自動化する話です。過去の記事 AppiumでAndroidアプリの自動テストをPerlで書いてみた - Mobile Factory Tech Blog では、Perl + Appium を使ったAndroidアプリのテストについて書きました。

今回の記事には、Appium + AWS Device Farm + Jenkins を使い、Androidのモバイルアプリの動作確認を複数端末における自動化について書きます。

背景

運用中サービスのアプリに変更を入れる場合、当サービスがサポートする端末でアプリの動作確認をするのが理想的だと思います。 コロナ禍前は、会社に検証用の端末があるため、サポートする端末や問題がありそうな端末を複数台確保して、動作確認を行いやすかったです。 しかし、2月からフルリモートで働くようになってから、手元に検証用の端末は(複数台)ない状態になっています。

手軽に複数端末で、モバイルアプリのテストをしたいので、今回目をつけたのは AWS Device Farm です。

AWS Device Farm

Device Farm は、実際に Amazon Web Services (AWS) によりホストされている電話やタブレットで、Android や iOS、およびウェブアプリを物理的にテストしてやり取りできるアプリテストサービスです。(AWS公式サイトより引用)

モバイルアプリの開発における様々な端末での動作確認を楽にしてくれるAWSのサービスです。 このサービスの使い方は2つあります。

  1. 自動アプリテスト
  2. リモートアクセスの操作

今回は様々の端末での動作確認を自動化したいので、自動アプリテストを使います。

自動アプリテスト

事前準備

Testing mobile apps across hundreds of real devices with Appium, Node.js, and AWS Device Farm | Front-End Web & Mobile

まずやっておくことは、AWS Device Farm上の準備ですが、上記のブログ記事を参考に作業します。

  1. テストするアプリを用意
  2. 動作確認をAppium (Node.js) のテストで実装
  3. AWS Device Farm上で設定し、自動テストアプリを実行

テストするアプリを用意

テストするアプリはAWS Device FarmやAppiumが用意してくれたサンプルアプリを使うのもできますが、今回は自分で作ったHelloWorldを表示するアプリを使います。

GitHub - fadlil/HelloWorld

app/outputs
└── app-debug.apk

動作確認をAppium (Node.js) のテストで実装

テストしたいことは、アプリを起動できるかどうかだけにします。

// テストフレームワーク
var expect = require('chai').expect;

// node.js でappiumを使う
var wd = require('wd');
var driver = wd.promiseChainRemote({
    host: 'localhost',
    port: 4723
});

var assert = require('assert');
describe('AWSDeviceFarmReferenceAppTest', function () {
    before(function () {
        this.timeout(300 * 1000);
        return driver.init();
    });

    after(function () {
        console.log("quitting");
    });
   
    // アプリが起動できて、'Hello World!!' が表示されるテスト
    it('test_app_is_loaded', async function () {
        const element = await driver.elementById("com.example.nesh.helloworld:id/change");
        expect(element).to.exist;
    });
});

このテストをそのままローカルで実行すると失敗します。 driver.init() に必要なデバイスの情報が足りないからです。 ただ、AWS Device Farm上で実行される時、これらの情報がよしなに補完されます。

このテストファイルをAWS Device Farmで使うために、 npm-bundle と zip化する必要があります。

AWS Device Farm上で設定し、自動テストアプリを実行

  1. 新しくプロジェクトを作成
  2. 新しいrunを作成して、必要な項目を設定
    • アプリの *.apk ファイルをアップロード
    • zip化されたテストファイルをアップロード
    • デバイスを選択
  3. 必要設定を埋めたら、自動アプリテストを実行

必要な作業は大体上記の通りです。

ここまでの作業で、モバイルアプリを複数端末で手軽に自動テストできるようになりました。 しかし、AWS Device Farm上の操作自体が手間になると思います。 この手間を無くし、継続的にテストを回せたいと思っているので、Jenkins で自動化することにしました。

Jenkinsで自動化

自動化するのは、 AWS Device Farm上で設定し、自動テストアプリを実行 の操作です。 操作自体は単純で手間ではないのですが、自動にできる部分は自動化したい気持ちです。 自動化するといっても、JenkinsにAWS Device Farm用のプラグインが用意されてるので、簡単に自動化できます。

AWS Device Farm の Jenkins CI プラグインとの統合 - AWS Device Farm

Jenkinsで使うプラグインは aws-device-farm | Jenkins plugin です。 この記事は上記に用意したサンプルリポジトリを使った場合、設定のスクリーンショットをいくつか貼ります。

f:id:nesh:20201222101827p:plain:w500
Jenkinsのプロジェクトの設定1

ProjectDevice Pool はAWS Device Farm上に設定されてるものを参照します。Application はサンプルリポジトリ上のアプリファイルのパス

f:id:nesh:20201222101833p:plain:w500
Jenkinsのプロジェクトの設定2

今回のテストは Appium (Node.js) を使うので、該当テストファイルのパスを入力します。

f:id:nesh:20201222102115p:plain:w500
Jenkinsのプロジェクトの設定3

テスト環境の設定は、AWS Device Farm上に手動で自動アプリテストを実行した時のものをそのまま使います。

f:id:nesh:20201222103034p:plain:w400
Jenkinsでの自動化が成功

これで、Jenkinsでの自動化のための設定ができて、実行して成功できました。

試してみた所感

  • AWS Device Farm の自動アプリテストはアプリ開発時の動作確認に便利
    • 最初の設定も簡単で、テストするアプリさえあればすぐにできる
    • テストデバイスの起動時間が合計1,000分まで無料なので、気楽に試せる
  • アプリ開発時のサポート端末での起動確認などで使えそう
  • 自動化に関しては、アプリのビルドやテストファイルの npm-bundle + zip などの作業も自動化すれば理想的

日々の面倒な作業を自動化して、快適な開発ライブを充実しましょう。


明日の記事は id:kfly8 さんです!