オクトのデザインチームを紹介するよ!

はじめに

初めましてデザインチームの杉本です。

 

オクトのデザイナーとして初めて書くことになったので、デザインチームの紹介をしていこうと思います。

デザインチームについて

デザイナーて何人います?

現在8人です。


1年前に3人でオクトのデザイン業務を回していたのでそこから考えると人数的に色々な事ができるようになって、機能も増えてきていて新しい事を考えたりブランディングにも力を入れ始めています。

 

   f:id:sugi0920:20200122111809p:plain

デザインチーム内の分担どうなっていますか?

基本的には、アプリやWebのUX/UIに関わっているデザイナーが6名、グラフィックデザインを主に行っているのが2名というふうに分かれています。


ここの分担は、曖昧で最近はブランディングが中心になっているデザイナーがいたりグラフィックからUI/UXの業務をやって貰ったりフロントエンドも兼任するデザイナーもいるのでやりたいことに手を挙げれば結構できる事が多いです。

新しいデザイナーが入ったらUI/UXとグラフィックが選べたりしますか?

基本的には別々に募集をかけているはずですが、両方ともに関わる事ができると思います。実際に人が少ない時にUI/UXもやりながらグラフィックのデザインもやってたので、UI/UXとグラフィック間の業務の行き来とかは簡単にできると思います。

 

開発体制について

デザインに使われているツールはなんですか?

Web・アプリのデザインはFigmaで、グラフィック関係はPhotoshopIllustratorで作るようになってます。
f:id:sugi0920:20200123104932p:plain

デザインする機能の分担はどうしています?

機能全てを改修することは少ないので何個かの機能を兼任するようになっています。僕の場合、新サービスやチャット、図面とかで要望とかが上がってきたり「新しい機能を追加するよー」となったら入っていくような感じになります。


 1から機能を開発する場合は、時間をさけるように兼任の他の機能のデザイン作業は少なくなっているような気もします。改修がある時はどうやっても上がってくるので並行して作業をすることも多いです。

 タスクなどの共有する時間はどうなっていますか?

毎週水曜日に自分たちが抱えているタスクを共有するミーティングをしています。最近は「Design doc」として要件を確認する時間を設けています。


さらに毎週金曜日にデザインのフィードバック会を行いデザインが要件を満たしているのかを確認するようになっています。

 

f:id:sugi0920:20200123112744j:plain

 

1人で作っていると気付けなかったことも他のデザイナーから意見が聞けるので前職で1人デザイナーやっていた時より気付きが多くて参考になります。

建築系のデザインする上で難しかったこととか面白いことありますか?

新しい知識を知るのは面白いです。工業高校の出なので建築とか工業の環境の方が近い環境だったので聞き覚えのある用語とか結構あったり、新築ができていく工程とかって自分が新築建てる予定がないと関わらないような知識が入ってくることなどです。

 

難しいことだとやっぱり情報量が多いことですかね。ANDPAD内には多くの機能があるので把握や用語を覚える必要があるので新入社員へのオンボーディングが課題として上がってきています。

uxmilk.jp

デザイナーはどの工程から入っていくことが多いですか?

僕の場合ですが基本的には要件がある程度できてから関わる場合が多い気がします。営業の方が利用中の会社からの要望を聞いている状態で入ることもあります。

開発部で自分たちがアプリを実際に使って欲しい機能を提案して作ったりすることもあるので、どこの工程から入っていっても要件に意見や感想を言いやすい環境ではあるので要件が決まっていても変えることもできると思います。

 

お客さんやエンジニアに見せるのはどのくらいの段階で見せますか?

お客さんに見せるのはデザイナー側でプロトタイプを見せることが多いです。機能のイメージを見て貰って実装前に意見を貰う事で手間のかかる実装後の改修を防ぐようにしています。

 

エンジニアの方に見せるのはデザインの方向性が決まってからです。そこで見せて意見や実装上難しい部分があればその意見を取り入れてデザインを作って改修したり、早めに見て貰っているとある程度の実装工数を見積もってくれるので調整が楽になりますね。

 

お客さんのところに行ったりとかしますか?

導入の説明会に行ったり遠方のお客さんだとビデオチャットで通話したりしています。最近、利用中の会社の方に協力していただいて開発から数人が現場に行ってどういった利用をしているかを実際に見せてもらいそれを撮影して社内に共有するという試みがされてました。

 f:id:sugi0920:20200123112623p:plain

 

普段なかなか見れない建築現場を見る事ができ、よりユーザーの理解ができる良い試みだと思います。

 

イベントとかって参加したりしてますか?

去年は希望者で「Designship」へ参加してます。色々なジャンルのデザインを見ることができたり有名なデザイナーの講演を聞くことができたのでいい経験でした。

あとは個人的に気になったイベントや展示会をデザインチーム内のチャットに共有しあったりしていますね。

おわりに

以上、今回はデザインチームの紹介をしました。最後まで読んで頂き、ありがとうございました!

少しでもご興味を持っていただけましたら、下記よりご連絡いただけますと幸いです!

 

hrmos.co 

テスト勉強会第5弾「自動テストの基礎」

はじめに

1月に入社したアプリチームの工藤です。

DeNA SWETグループの平田さんをお招きして、社内で第5回目のテスト勉強会を開催しました。この記事はそのレポートになります。

オクトでは定期的に社内勉強会を開催しています。

Vue.js勉強会や↓ tech.88oct.co.jp

SQL勉強会なども↓ tech.88oct.co.jp

今回は前回の反省を踏まえ、畳の小上がりスペースで行いました。
20名ほどの社員が真剣に耳をかたむけていて、雰囲気と場所のギャップが新鮮でした1

以前のテスト勉強会はこちら↓ tech.88oct.co.jp

内容

前半はユニットテストで重要な考え方であるFirst2とA-Rtip3に共通して挙げられている独立性・再現性について、後半は保守性の高いテストの設計について説明いただきました。

独立性

テストが増えるにつれ実行速度が課題になります。
改善するためには並列で稼働させる必要がありますが、テスト同士に依存関係がなく独立した状態でないといけません。

f:id:oct_k_kudo:20200117144203p:plain

これはテストをランダム実行することでチェックできますが、使える環境と使えない環境があるので注意が必要とのことです。

再現性

f:id:oct_k_kudo:20200117144243p:plain

CI環境は常に動くことが重要です。 たまに失敗したり再実行すれば成功するテストを放置していた結果、自動テストが信用されなくなってしまった現場を以前見たことがあり、この部分は当時を思い出しながら聞いていました。
再現性の低下に対処するには、可能性があるものをどれだけ知っているか?がカギになるそうです。

保守性について

f:id:oct_k_kudo:20200117145547p:plain

テストコードが徐々に負債になるというのはあまり意識したことがなく、非常に勉強になりました。
レガシー化した部分の改善を容易にするためにも、シンプルなテストコードを意識するのが重要とのことです。 書き方の参考として、 AAA・Four-Phase Testというパターンを紹介いただきました。

質問タイム(特に印象に残ったもの)

Q. テストケース名に日本語を使うか?

A 無理に英語にする必要はないが、日本語はプラットフォームや環境によっては正しく実行できないことがあるので確認してから使う。
AndroidではJunit5からは @DisplayName が使えるので活用すると良いと後から教えていただきました。

Q. 既存コードに対するテスト追加とテストのためのリファクタリングはどちらを優先すべきか

A リファクタすべきという危険を感じ取ったら(スライドの表現を使って匂いと表現されてました)、まずはリファクタリングすべき。
リファクタ前に無理やりテストコードを書いたとしても、リファクタ後にそれが負債になってしまう。

最後に

テストカバレッジなどは元々知識として知っていたものの、テストコードの保守性のために設計が必要という事に気づけたのが良かったです。 今はモバイルアプリのCD/CI環境整備を進めていて、自動テストのコードも徐々に増えてきています。
私も早くテストコードの匂いを感じ取れるように成長していきたいです。

こちらのサイトもよろしくおねがいします!

engineer.88oct.co.jp


  1. 写真を撮り忘れてました。。。

  2. 「Clean Code アジャイルソフトウェア達人の技」

  3. 「達人プログラマー―ソフトウェア開発に不可欠な基礎知識」

ベタなiOSアプリのCI/CDのワークフローを組む

こんにちは。モバイルアプリの開発を担当をしているzigeninです。

ANDPADのiOSアプリのCI/CDワークフローを紹介します。 ベタなツールにベタなワークフローですので、他のiOSアプリにも適用できると思います。 一例として参考になればと思います。

目次

事前情報

ビルドに使用しているツール

ツール 用途
Bitrise 特定のブランチにpushした時にワークフローを実行
Firebase App Distribution アプリの配布
fastlane matchでアプリの署名用のcertificates & provisioning profileを取得
pod 依存ライブラリを入手

iOSアプリのビルドScheme

Scheme 用途
andpad Release版アプリをビルドする。
andpadUITests Release版アプリで、安定したUIテストのみ実行する用。
andpad_develop Develop版アプリをビルドする。Unitテスト実行用でもある。
andpadUITestsDevelop Develop版アプリで、安定したUIテストのみ実行する。
andpadNightlyUITests 全UIテストを実行する。

ANDPADではビルドSchemeによって、普段の開発に使うDevelop版アプリと、Storeに公開する用のRelease版アプリを分けています。 Develop版アプリは開発用アプリで、developサーバと接続しています。 Release版アプリはStoreに公開するアプリと同一で、本番サーバに接続しています。

UIテストのSchemeを3つ分けていますが、状況によってUIテストの実行の仕方を変えるためです。 UIテストをCI/CDのワークフローに組み込むための肝です。 詳細は、後述のNightly UI Testのワークフローで説明します。

ブランチ戦略

大体、GitHub Flowです。

ブランチ 用途
master Storeに公開したアプリのコードの置き場所
develop 開発本線。最新のコードの置き場所
feature/* 機能開発用ブランチ

運用図は、ワークフローの全体像と一緒に示します。

ワークフローの全体像

GitHubのブランチをベースに、ワークフローを示します。

f:id:zigenin:20200114160516p:plain:w640
ブランチ戦略とワークフローの関係性

主要なワークフローは3つです。

  • 内部配信のワークフロー
    • 用途
      • Develop版アプリの自動テストを実施 + 社内にアプリを配布する
    • トリガー
      • ブランチをdevelopにマージした時
    • やること
      • ビルドの準備をする
        • コードのチェックアウト
        • 証明書をfastlane matchで入手
        • 依存ライブラリをpodで入手
      • Unitテストを実行する
      • アプリをビルドする
      • ビルドしたアプリをFirebase App Distributionに配布する
      • 安定しているUIテストを実行する*1
      • ビルドの後始末をする
        • テスト結果を保存する
        • Slackにビルド結果を通知する
  • Store配信ワークフロー
    • 用途:Release版アプリの自動テストを実施 + Storeにアップロードする
    • トリガー:developブランチをmasterブランチにマージした時*2
    • やること(内部配信フローと大体同じ。違いは太字で強調)
      • ビルドの準備をする
      • Unitテストを実行する
      • アプリをビルドする
      • ビルドしたアプリをStoreに配布する
      • 安定しているUIテストを実行する
      • ビルドの後始末をする
  • Nightly UI Testワークフロー
    • 用途:追加したばかりのUIテストが安定していることを確認する
    • トリガー:毎日定刻に、developブランチに対して実行
    • やること(内部配信フローと大体同じ。違いは太字で強調)
      • ビルドの準備をする
      • Develop版アプリで 全てのUIテストを実行する
      • ビルドの後始末をする

以降、この3つのワークフローとそれらを構成するユーテリティワークフローを、Bitriseでどのように設定しているかを紹介します。

ユーティリティワークフロー

先程示した3つのワークフローには、共通部分が多いです。 共通部分は、4つのBitriseのユーテリティワークフローとしてまとめています*3

  1. ビルドの準備(_BeforeCommonWorkflow)
  2. Unitテスト実行&アプリのビルド(_BuildAndUnitTest)
  3. UIテスト実行(_UITest)
  4. ビルドの後始末(_AfterCommonWorkflow)

ワークフロー名の先頭に"_"を付けると、ユーティリティワークフローとなります。ユーティリティワークフローにすると、他のワークフローの部品として扱われ、独立して実行することができなくなります*4

4つのユーテリティワークフローの設定の詳細を紹介します。

ビルドの準備(_BeforeCommonWorkflow)

f:id:zigenin:20200114003504p:plain:w240
_BeforeCommonWorkflowを構成するStep

  • Activiate SSH Key
  • Git Clone Repository
  • Bitrise.io Cache:Pull
  • fastlane match
    • Develop版アプリの署名用のcertificates & provisioning profileを取得するStep*5
    • "fastlane lane"に"match development"を設定
    • fastlaneに必要なFASTLANE_USER, MATCH_PASSWORD, FASTLANE_PASSWORDは、BitriseのSecretsに設定
  • fastlane match
    • リリース版アプリの署名用のcertificates & provisioning profileを取得するStep*6
    • "fastlane lane"に"match appstore"を設定
  • Run CocoaPods install

このワークフローは、ワークフローごとにパラメータや処理に違いはありません。

Unitテスト実行&アプリのビルド(_BuildAndUnitTest)

f:id:zigenin:20200114115350p:plain:w240
_BuildAndUnitTestのStep

  • Set Xcode Project Build Number
    • Bitriseのビルド番号をアプリのBundle Versionとして設定するStep
    • 配布したアプリと対応するBitriseのビルドが分かりやすくなり、問題が起きた時の追跡などの時に便利です
    • "Info.plist file path"に"$BITRISE_SOURCE_DIR/$INFO_PLIST_PATH"を設定
      • AndpadではDevelop版とRelease版でInfo.plistが違うので、フローごとに切り替える必要がある
  • Xcode Test for iOS
    • Unit Testを実行するStep
    • Schemeとして、"andpad_develop"を設定
    • Simulator Deviceには、"iPhone Xs Max"を設定
  • Xcode Archive & Export for iOS
    • アプリをビルドするStep
    • "Rebuild from bitcode"を"no"に設定
      • export methodが"development"の時にbitcodeを生成するかのオプション
      • 內部配信の場合、bitcodeをリビルドする意味があまりない*7 かつ ビルド時間短縮のために、Offにしている
    • "Select method for export"に"$BITRISE_EXPORT_METHOD"を設定
    • "Configuration name"に"$BUILD_CONFIG"を設定
    • "iCloud container environment"に"$ICLOUD_CONTAINER_ENVIRONMEN"を設定
  • IPA info
    • ビルドしたアプリの情報をBitriseの環境変数に設定してくれるStep
    • ここで設定される$IOS_IPA_PACKAGE_NAME(値はBundle Identifier)をビルド結果をSlackに通知する時に使う

UIテスト実行(_UITest)

f:id:zigenin:20200114131312p:plain:w240
_UITestを構成するStep

  • Xcode Build for testing for iOS
    • UIテスト用のアプリをビルドするStep
    • "Configuration name"に"$BUILD_CONFIG"を設定
    • "Scheme name"に"$BITRISE_UITEST_SCHEME"を設定
  • iOS Device Testing
    • UIテストをFirebase Test Labで実行するStep
    • "Test devices"に"iphonexs,12.3,ja,portrait"を設定(iPadや複数OSバージョンをTestするようにする予定です))

ビルドの後始末(_AfterCommonWorkflow)

f:id:zigenin:20200114005906p:plain:w240
_AfterCommonWorkflowを構成するStep

  • Bitrise.io Cache: Push
  • Deploy to Bitrise.io - Apps, Logs, Artifacts*8
    • Slackで結果を通知しているのでEmail通知は無効化
      • "Notify: User Roles"を"none"に設定
  • Send a Slack message
    • ワークフローごとに通知先のチャンネルを切り替えられるよう設定
      • "Slack API token"に$SLACK_API_TOKENを設定($SLACK_API_TOKENの値はBitriseのSecretsで設定)
      • "Target Slack channel"に$SLACK_TARGET_CHANNELを設定
        • Web Hook URLを使わないのは、Web Hook URLだとチャンネルの数だけSecrets変数が設定が必要なため
    • SlackのメッセージにBundle IDを含めるように設定
      • "A list of fields to be displayed in a table inside the attachment"に次の内容を記述。
      • App|${BITRISE_APP_TITLE}
        BundleID|${IOS_IPA_PACKAGE_NAME}
        Branch|${BITRISE_GIT_BRANCH}
        Workflow|${BITRISE_TRIGGERED_WORKFLOW_ID}

      • BundleIDを含めるのは、ビルドされたのがDevelop版なのかRelease版なのかを区別するため

内部配信ワークフロー

Steps

f:id:zigenin:20200114161954p:plain:w240
內部配信ワークフローを構成するStep

ワークフローの大まかな構成を示します。 - BeforeCommonWorkflow - BuildAndUnitTest - 內部配信ワークフロー本体のStep - UITest - AfterCommonWorkflow

長く見えますが、ほぼ前述のユーテリティワークフローで構成されています。 このワークフロー本体のStepは、Firebase App Distributionのみです。

  • Firebase App Distribution*9
    • ビルドしたアプリをFirebase App Distributionに配布するStep
    • "Firebase Token"には、Firebaseの認証トークンを設定
    • "Release Notes"には以下を設定
      • $GIT_CLONE_COMMIT_MESSAGE_SUBJECT

        $GIT_CLONE_COMMIT_MESSAGE_BODY

    • "Test Groups"には、Firebase App DistributionのTester Groupを設定
    • "Firebase App ID"には、Firebase上のアプリのIDを設定

環境変数の設定

本体のStepが少ない分、環境変数の設定が重要になるので、示しておきます。

環境変数 用途 使っているワークフロー
BITRISE_PROJECT_PATH xcworkspaceファイルの場所を指定 andpad.xcworkspace BuildAndUnitTest, UITest
BITRISE_SCHEME アプリのビルドSchemeを指定 andpad_develop _BuildAndUnitTest
BITRISE_EXPORT_METHOD アプリのビルド時のExport Methodを指定 development _BuildAndUnitTest
SLACK_TARGET_CHANNEL ビルド結果の通知先のSlackチャンネル名 #andpad-app-build _AfterCommonWorkflow
ICLOUD_CONTAINER_ENVIRONMENT アプリビルド時のiCloud Containerを指定 Development _BuildAndUnitTest
BITRISE_UITEST_SCHEME UIテストアプリのビルドSchemeを指定 andpadUITestsDevelop _UITest
BUILD_CONFIG アプリのビルドconfigを指定 Debug BuildAndUnitTest, UITest
INFO_PLIST_PATH Info.plistの場所を指定 andpad-develop-Info.plist _AfterCommonWorkflow

Store配信ワークフロー

Steps

f:id:zigenin:20200114172628p:plain
Store配信ワークフローを構成するStep

ワークフローの全体構成を示します。 - BeforeCommonWorkflow - BuildAndUnitTest - Store配信ワークフロー本体のStep - UITest - AfterCommonWorkflow

このワークフロー本体のStepは、Deploy to iTunes Connectのみです。

  • Deploy to iTunes Connect
    • ビルドしたアプリをStoreに配布するStep
    • "Apple ID"に、Storeにアップロードする権限のあるユーザIDを設定
    • "Password"には、Storeにアップロードする権限のあるユーザのパスワードを設定
    • "Team ID"には、iTunes ConnectのアプリのTeam IDを設定
    • "App Bundle ID"には、アプリのBundle IDを設定。
      • _BuildAndUnitTestのStep "IPA Info"のおかげで$IOS_IPA_PACKAGE_NAMEが使えるので、それを設定

環境変数の設定

本体のStepが少ない分、環境変数の設定が重要になるので、示しておきます。

環境変数 用途 使っているワークフロー
BITRISE_PROJECT_PATH xcworkspaceファイルの場所を指定 andpad.xcworkspace _BuildAndUnitTest, _UITest
BITRISE_SCHEME アプリのビルドSchemeを指定 andpad _BuildAndUnitTest
BITRISE_EXPORT_METHOD アプリのビルド時のExport Methodを指定 app-store _BuildAndUnitTest
SLACK_TARGET_CHANNEL ビルド結果の通知先のSlackチャンネル名 #andpad-app-build _AfterCommonWorkflow
ICLOUD_CONTAINER_ENVIRONMENT アプリビルド時のiCloud Containerを指定 Production _BuildAndUnitTest
BITRISE_UITEST_SCHEME UIテストアプリのビルドSchemeを指定 andpadUITests _UITest
BUILD_CONFIG アプリのビルドconfigを指定 Release _BuildAndUnitTest, _UITest
INFO_PLIST_PATH Info.plistの場所を指定 andpad/Info.plist _AfterCommonWorkflow

Nightly UI Testワークフロー

Steps

f:id:zigenin:20200114181600p:plain
Nightly UI Testワークフローを構成するStep

ワークフローの全体構成を示します。 - BeforeCommonWorkflow - UITest - _AfterCommonWorkflow

このワークフローは、本体のStepはなしです。

環境変数の設定

環境変数の設定は內部配信のワークフローとほぼ同じです。違いだけ示します。

環境変数 用途 使っているワークフロー
BITRISE_UITEST_SCHEME UIテストアプリのビルドSchemeを指定 andpadNightlyUITests _UITest
SLACK_TARGET_CHANNEL ビルド結果の通知先のSlackチャンネル名 #team-qa-mobile-cicd _AfterCommonWorkflow
IOS_IPA_PACKAGE_NAME Slackで通知のアプリのBundle ID jp.reformpad.ios.develop _AfterCommonWorkflow

Slackの通知先のチャンネルを、弊社のアプリのCI/CDを整備する活動のチャンネルにしています。 定期実行のテスト結果を、配信用のチャンネルに通知すると、配信の情報が埋もれるためです。

補足

このワークフローは、追加したばかりのUIテストの安定性を確認するために、毎日定時に実行しています。

UIテストはUnitテストに比べると不安定です*10。 そのため、最初から內部配信ワークフローやStore配信ワークフローに組み込んでしまうと、ビルドエラーの頻度が上がります。 そうなってしまうと、UIテストのせいで却って開発効率が落ちてしまいます。

そこで、毎日定時にUIテストを実行し、連続で7回成功したら、配信ワークフローに組み込む運用にしています。 それであれば、配信ワークフローで実行するUIテストを安定したものだけに限定できます*11。 全UIテストを実行するSchemeを"andpadNightlyUITests"と、配信ワークフロー用のUI TestのSchemeを"andpadUITests", "andpadUITestsDevelop"に分けることで、この運用を実現しています。

参考情報

参考書籍

本ワークフローを構築にするにあたって、以下の書籍の「9章 CI/CD」を参考にしています*12

iOSテスト全書

ここで紹介したワークフローは、書籍で紹介されているワークフローを大分デチューンしています。 もっとしっかりしたワークフローを組みたいという方は、この本がおすすめです。テストやCI/CDのそもそも論も学べます。

Bitriseの設定のソースコード

---
format_version: '8'
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: ios
trigger_map:
- push_branch: develop
  workflow: InternalRelease
- push_branch: master
  workflow: Release
- push_branch: test/*
  workflow: RunAllUITests
workflows:
  InternalRelease:
    steps:
    - firebase-app-distribution@0.5.0:
        inputs:
        - firebase_token: "$FIREBASE_TOKEN"
        - release_notes: |-
            $GIT_CLONE_COMMIT_MESSAGE_SUBJECT

            $GIT_CLONE_COMMIT_MESSAGE_BODY
        - groups: Andpad
        - app: "$FIREBASE_APP_ID"
    before_run:
    - _BeforeCommonWorkflow
    - _BuildAndUnitTest
    after_run:
    - _UITest
    - _AfterCommonWorkflow
  Release:
    steps:
    - deploy-to-itunesconnect-deliver@2.17.0:
        inputs:
        - itunescon_user: "<アプリのアップロードする権限を持つユーザID>"
        - team_id: <アプリのTeamID>
        - bundle_id: "$IOS_IPA_PACKAGE_NAME"
        - password: "<アプリのアップロードする権限を持つユーザのパスワード>"
    envs:
    - opts:
        is_expand: false
      BITRISE_SCHEME: andpad
    - opts:
        is_expand: false
      BITRISE_EXPORT_METHOD: app-store
    - opts:
        is_expand: false
      APP_BUNDLE_ID: jp.reformpad.ios.production
    - opts:
        is_expand: false
      FASTLANE_MATCH_TYPE: appstore
    - opts:
        is_expand: false
      ICLOUD_CONTAINER_ENVIRONMENT: Production
    - opts:
        is_expand: false
      BITRISE_UITEST_SCHEME: andpadUITests
    - opts:
        is_expand: false
      BUILD_CONFIG: Release
    - opts:
        is_expand: false
      INFO_PLIST_PATH: andpad/Info.plist
    before_run:
    - _BeforeCommonWorkflow
    - _BuildAndUnitTest
    after_run:
    - _UITest
    - _AfterCommonWorkflow
  _BeforeCommonWorkflow:
    steps:
    - activate-ssh-key@4.0.5:
        run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
    - git-clone@4.0.17: {}
    - cache-pull@2.1.3: {}
    - fastlane@2.7.0:
        inputs:
        - lane: match development
        title: fastlane match
    - fastlane@2.7.0:
        inputs:
        - lane: match appstore
        title: fastlane match
    - cocoapods-install@1.10.0: {}
  _AfterCommonWorkflow:
    steps:
    - cache-push@2.2.3: {}
    - deploy-to-bitrise-io@1.9.5:
        inputs:
        - notify_user_groups: none
    - slack@3.1.3:
        inputs:
        - channel: "$SLACK_TARGET_CHANNEL"
        - fields: |
            App|${BITRISE_APP_TITLE}
            BundleID|${IOS_IPA_PACKAGE_NAME}
            Branch|${BITRISE_GIT_BRANCH}
            Workflow|${BITRISE_TRIGGERED_WORKFLOW_ID}
        - api_token: "$SLACK_API_TOKEN"
    before_run: []
  _BuildAndUnitTest:
    steps:
    - set-xcode-build-number@1.0.9:
        inputs:
        - plist_path: "$BITRISE_SOURCE_DIR/$INFO_PLIST_PATH"
    - xcode-test@2.4.3:
        inputs:
        - generate_code_coverage_files: 'yes'
        - scheme: "andpad_develop"
        - simulator_device: iPhone Xs Max
    - xcode-archive@2.7.1:
        inputs:
        - compile_bitcode: 'no'
        - export_method: "$BITRISE_EXPORT_METHOD"
        - configuration: "$BUILD_CONFIG"
        - icloud_container_environment: "$ICLOUD_CONTAINER_ENVIRONMENT"
    - ipa-info@1.1.0: {}
    before_run: []
    after_run: []
  _UITest:
    steps:
    - xcode-build-for-test@0.4.0:
        inputs:
        - configuration: "$BUILD_CONFIG"
        - scheme: "$BITRISE_UITEST_SCHEME"
    - virtual-device-testing-for-ios@0.9.10:
        inputs:
        - test_devices: iphonexs,12.3,ja,portrait
    before_run: []
    after_run: []
  NightlyUITests:
    envs:
    - opts:
        is_expand: false
      SLACK_TARGET_CHANNEL: "#team-qa-mobile-cicd"
    - opts:
        is_expand: false
      BITRISE_UITEST_SCHEME: andpadNightlyUITests
    - opts:
        is_expand: false
      IOS_IPA_PACKAGE_NAME: jp.reformpad.ios.develop
    before_run:
    - _BeforeCommonWorkflow
    - _UITest
    after_run:
    - _AfterCommonWorkflow
app:
  envs:
  - opts:
      is_expand: false
    BITRISE_PROJECT_PATH: andpad.xcworkspace
  - BITRISE_SCHEME: andpad_develop
    opts:
      is_expand: false
  - opts:
      is_expand: false
    BITRISE_EXPORT_METHOD: development
  - opts:
      is_expand: false
    SLACK_TARGET_CHANNEL: "#andpad-app-build"
  - opts:
      is_expand: false
    ICLOUD_CONTAINER_ENVIRONMENT: Development
  - opts:
      is_expand: false
    BITRISE_UITEST_SCHEME: andpadUITestsDevelop
  - opts:
      is_expand: false
    BUILD_CONFIG: Debug
  - opts:
      is_expand: false
    INFO_PLIST_PATH: andpad-develop-Info.plist
  - opts:
      is_expand: false
    FIREBASE_APP_ID: "<FirebaseのアプリのID>"
meta:
  bitrise.io:
    machine_type: elite

*1:アプリ配布後にUI Testを実行させているのは、アプリ外の要因でUIテストが失敗することがあるためです。テストが失敗した時、ログを見て外部要因であれば、アプリの再配信はしない運用にしています。

*2:masterにマージする前に、Develop版アプリを使って手動テストを実施しています。それで問題なければ、masterにマージしています。

*3:詳細は https://devcenter.bitrise.io/bitrise-cli/workflows/#utility-workflows を参照

*4:これがユーテリティワークフローの良い所です。手動でビルドを開始する時などにワークフローリストに表示されなくなるので見通しが良くなります。

*5:fastlane matchを使っているのは、Bitrise導入前からfastlane matchでcertificates & provisioning profileを管理していたのを踏襲したからです。

*6:Develop版とリリース版アプリの両方のcertificates & provisioning profileが必要になるケースがある

*7:bitcodeは、Storeにアップロードした時に、Apple側で最適化をするためのもの。

*8:iOSテスト全書の事後ワークフローに含まれていませんが、個人的には含めておいた方が良いと思います。Unitテストの結果がBitriseのTest Reportで見れる、ビルドログやビルドしたアプリがArtifactに保存される、BitriseのSlackやメールの通知からアプリをインストールできるなどの利点があります。

*9:設定の意味の詳細は、 https://firebase.google.com/docs/app-distribution/ios/distribute-cli?hl=ja を参照。

*10:通信が発生する、OSバージョン、Deviveの置かれた環境に依存するためです。弊社固有の事情ですが、最近まで弊社にモバイルアプリのUIテストのノウハウがなかったことも原因です

*11:なお、OSのバージョンアップ等で、配信ワークフローに組み込んだUIテストが不安定になってしまった場合は、配信ワークフローから外す運用です

*12:弊社のテスト面の技術顧問の平田さんが記述しています

2019年の振り返りを B2B SaaSエンジニアMeetup - Sharing Issues で登壇してきました

はじめに

はじめまして〜

オクトでVPoEやってる @gessy0129 です。

年始一発目とのことで、2019年を振り返りました。

発表をこちらのイベントで行いました!

smartcamp.connpass.com

資料

登壇して

忘年会で飲食していいよ!という話しだったので、登壇一発目にも関わらずビール片手にやらせて頂きました。

 

会場には40名程いたかと思いますが、程よく笑いも取れたので登壇一発目としてはまぁまぁ場を作れたような気がします。LTなのにちょっと詰め込み過ぎて時間が足りなくて早口になってしまったのはごめんなさい。。

 

奇しくも、弊社の開発組織戦略顧問である井原さんと一緒に登壇することになりましたが、お互い共に前後に予定があり、それぞれの発表だけ聞けないという事態になってしまいました(笑)

 

 

2019年を振り返って

2019年は開発組織的には大成功の年だったかなと思います。10月にオフィス移転もして、順調に成長していると感じています。

tech.88oct.co.jp

 

2020年の目標

振り返りにも書きましたが、テックブログのシェア数が少ない!

まだまだ認知が少ないです。。。シェア数を伸ばすことをまず第一に考えていきます!

 

そして、2020年の目標的なものを次回のイベントで発表出来たらいいなという気持ちです(絶賛資料作成中)

 

宣伝

こちらのイベントで登壇してきます。既に定員オーバーしてますが、定期的にイベント登壇したいと思うので、宜しくおねがいします!

 

techplay.jp

開発部全体にVue.jsハンズオン勉強会を開催した

はじめに

どうもオクトテックブログ編集長の藤井です!(なぜか流れで編集長を拝命した。やりたい人いたら変わって欲しい)

 

先日、ANDPADのVue.js技術顧問をして頂いている喜多さん(@kitak)さんに開発部向けにVue.jsのハンズオン勉強会をして頂きました!

 

そのレポートになります!


経緯

基本的にANDPADにおける新規サービスのフロント側はVue/Nuxtで作っています。そして既存のANDPAD施工管理の一部もすでにVue.jsを採用しており、今後全面的にAngularからVueへの移行をしていこうとしています。

 

そういう状況ですので、フロントエンドやバックエンドなど関係なく社内のエンジニアにはVue.jsがなんなのかということを認識しておいて欲しいと考えました。

 

もちろんみなさん知っている方は多いのですが、実際に触ったことがある人は少ないはず!そんなことから、喜多さんに相談してハンズオンにしてみようとなったのです!

 

前準備

一応事前に開発部のみんなにはアンケートをslackで流して、回答してもらいました。

  • jQueryを使ったことがある
  • Angular.jsを使ったことがある
  • フロントエンド全般に苦手意識がある(少なくとも得意とは言えない)
  • Vueについて知りたいこと・気になっていることがあったら自由に記述してください
  • etc....

そして回答を見ると色々と傾向が見えました。

 

f:id:yohei-fujii:20191223173102p:plain

問1の回答集計グラフ↑↑

 

 

jQueryを使ったことがあるのが、だいたい85%近く。そしてフロントエンド全般に苦手意識があると答えたのが約70%、などなどANDPAD開発部の傾向が見えました。

自由記述では、「Reactなどとのフレームワークの違い」「大規模向けと小規模向けと言われる違い」などなどが上がってきました。

 

これを元に、どのような内容にするか相談した結果、今回の勉強会では、ターゲットとして「JavaScript/jQueryを書いた経験がある人が、Vueの基本文法や概念を理解して、業務でVueを使う足がかりにしてもらう」と設定しました。

 

 

当日の様子

時間になったらみなさん集まってきました。

f:id:yohei-fujii:20191224100857j:plain

 

今回嬉しかったのは、エンジニアだけでなくデザイナーの方々も参加してくださったことです。 VueはtemplateにHTML構文で書けますのでデザイナーの方々にこそどんどん携わって欲しいと思っています。

 

 

f:id:yohei-fujii:20191224100945j:plain

 みんな真剣。どっかの学校みたいw 

内容

主に3つのセッションに分けて開催しました。

概要説明

まず、「なぜVueを使うのか(jQueryからVueへ)」というタイトルで説明から入りました。喜多さんが見やすい資料を用意してくださっていたのでとても助かります。

 

f:id:yohei-fujii:20191223180353p:plain

 

この部分では、概念の比較から入り、そのあとjQueryとVueのコードを比較しながら、実際にどう書き方や設計が違うのかという説明をして頂きました。

 

f:id:yohei-fujii:20191225224942p:plain

ハンズオン

そしてその次は、ハンズオンです。話を聞いただけでは人はわかったつもりで終わりますので、実際に手を動かしてVueに触れてもらう時間を作りました。

 

喜多さんが準備してくださったリポジトリからプロジェクトをcloneして、実際に触りながら進めました。このパートでは、Vue.jsのおさえて置きたいコア機能として、以下の3つをメインに手を動かしながら説明してくださいました。(初めてVueに触る人もいるため文言はわかりやすくして頂いてます)

 

    - Vueインスタンスが持つ状態・データ

    - 状態が変更されると自動で画面が更新される

  • ディレクティブ

    - v-で始まる特別なHTML属性

    - DOM要素を拡張して、属性やスタイルの操作、

      条件分岐、繰り返し処理などを実現する

    - ビューを部品として、整理・再利用するための仕組み

 

基本的な書き方である、v-ifやv-forなども入れつつ、コンポーネントの切り出しやpropsでの子へのデータ渡しもやりました。

 

そして最後に事前のアンケートで上がっていた質問に対する回答ののち、質疑応答の時間を持ちました。

 

最後に

今回は時間が限られていたので、結構進むスピードが早くなってしまいました。ハンズオンは初学者もいれば熟練者もいるので進めていくスピード調整が難しいです。フィードバックももらったので、次は少し改善を考慮してみたいと思います。

 

このように今回フロントエンド エンジニアに対してだけではなく、普段はバックエンドやアプリ、インフラを触っている人たちにもVue.jsに触れてもらう機会を作りました。

 

昨今盛り上がりを見せているVue.jsに興味はあったが、実際には触ったことないという人たちにとっては良い機会になったと思います。

 

もちろん、まだまだVue.jsの一部しか紹介しておらず、本当の魅力などはもっとありますので、第2弾を検討中です!次はVuexに関することや、Nuxt.js、そして実際にANDPADのソースコードを使った開発に触れながら勉強会ができればいいなと考えております。

 

 

 

 

 

社内SQL勉強会とランチLTが被っちゃったよ

はじめに

久々の更新になります!フロントエンドチームの藤井です!

 

先日、社内でランチLTやるぞって意気込んでいたのですが、まさかの昼休みは「SQL勉強会」とバッティング。朝から社内は荒れ模様です。

f:id:yohei-fujii:20191210163620p:plain



イベントスペースがまだ限られているので、場所の取り合いが起きてしまいました。確かにネタではあるので、ブログのタイトルどうしようかと迷いましたが、おとなしめのタイトルにしておきました。

 

ランチLTとは?SQL勉強会とは?

tech.88oct.co.jp

ランチLTは秋葉原に引っ越す前から、始まった月一開催のイベントです!気軽にLTしたい人がLTして、ランチ食べながら聞くというスタイルのカジュアルな感じです。より詳しくは上の記事を見てみてください。

 

一方でSQL勉強会は、オクトを「最も応援される建築・建設テクノロジーサービス集団」にするべく、PMの谷口という一人の男が、ANDPADをよりよく変えよう動き出した素晴らしいイベントです。
エンジニア経験がない人でも講義を5回受けるとなんと一人でSQLでエンジニア並みのデータ分析をすることができるそうです。(本当か!?)

・SELECT文の使い方
・WHERE句の使い方
・論理削除と物理削除の違いは?

 

先月末に提案があったのですが、かなり期待する反響がありました。ビジネスサイドからそちらへの参加申し込みは社内では圧倒的でしたね。

 

そんな正義なイベントにランチLTを被せちゃうなんて・・・。なんてやつだ!(ぼくじゃない)って感じですが、そんなことはもう仕方ない。どっちかを選ぶしかないのです。

 

ぼくはランチLTで今回話しますから、必然とそちらに参加しましたが、SQL勉強会の様子もチラッと見にいきました。

 

社内SQL勉強会の様子

f:id:yohei-fujii:20191210134235p:plain

 

こちらは、さすがちゃんとしたイベント(ランチLTがちゃんとしてない訳ではないw)なだけあって、参加が人事部からCS、管理部など社内のいろんなメンバーが来ていました。講義と実践が組み込まれているようで、みんな真面目に聞いていらっしゃる。

 

f:id:yohei-fujii:20191210134232p:plain

 

一方で、ランチLTの方は・・

f:id:yohei-fujii:20191210135213p:plain

 

和気藹々と砕けた感じで、やりました。人がどんどん増えてる実感がこうやってみるとありますね!

 

f:id:yohei-fujii:20191210135255p:plain

 ランチLT提唱者のからまげさん(左)と発表中の後藤さん(右)↑↑

 

今回は4人がLTしました。

1人目

まずは、Railsエンジニアの福間さんから「はじめてのドラッカー風エクササイズ」でした。最近、ANDPADではメンバーがかなり増えており、新しいチームもできてきています。そんな中でどのようにチームを作り、メンバーとして動くのか。チームビルディングの手法をLTされました。 

 2人目

その次に、リードデザイナーの後藤さんから「Design Docについて」です。Design Docを利用することで、「なぜ」という部分を深掘りします。本当に必要なデザインだろうか、機能だろうか。言われたから作るではなく、本質の部分を見極める為に役立っているそうで、そのお話でした。

 

Figmaで資料を作ってくださいましたので、こちらのリンクからご覧ください。

3人目

私から、「体験をシェアしよう!」です。

10月にロシアにふらっと行ったのですが、その際におきた出来事、そしてそのあとその体験をシェアしたことでどう感じ、思ったのかについて話しました。

4人目

そして最後に、からまげさんから「SSRF脆弱性攻撃入門」のお話でした。セキュリティへの意識がより一層高まりますが、その注意勧告をして頂きました。

blog.tokumaru.org

今回は、こちらの記事を参考にお話頂きました。

 

おわりに

今回はたまたま社内でイベントが重なってしまいましたが、普段はきちんと別の日に行い、出来るだけ多くの人が参加できるようになっています!

 

ANDPADではこのように、社内に向けた勉強会も頻繁に行なっており、各部署だけでノウハウや知見を閉じ込めるのではなく、出来るだけオープンに部署横断で一緒に成長して行きたく動いています。

 

ぜひ以下のサイトも拝見ください!

テスト勉強会第2弾「テストを知ろう」

はじめに

以前行った初回となる勉強会「テストとは」に続き、2回目の勉強会になります。

(前回の記事↓)

tech.88oct.co.jp

 

今回もDeNA SWETグループの平田さんを講師にお招きして、開催して頂きました!実際に勉強会で見せてくださった資料と共に紹介していきます。

 

目的

今回の勉強会の目的は「『テスト』について『まず』知ること」です。普段何気なく口にしている「テスト」とういうものについて再定義を行うことで

  1. プロダクトを作るにあたってのより良いものを作れる
  2. 共通語彙により意思の疎通ができる

という2つを達成しようという狙いがありました。

 

結構な人数が集まりました。この人数なら別のスペース確保しておけば良かったとも・・。

f:id:yohei-fujii:20191018202050p:plain
 

内容

まずは前回の復習からです。

  • テストというのは「現在の状況」を教えてくれる
  • テストがあるから品質がよくなる訳ではなく、プロダクトをよくするのは我々であるということ
  • 知っておくと良い品質良識(狩野モデル・VerificationとValidation・CheckingとTesting)

改めてテストの意義と分類について整理しました。

 

そして今回のテーマは「テスト技法を知ろう」です。さまざななテスト技法がある中で、今回はその中でも2つを取り上げていただきました。

 

同値分割・境界値分析

1つ目が、「同値分割・境界値分析」です。

f:id:yohei-fujii:20191018130405p:plain

聞きなれない言葉ですが、意味を理解すると難しくはありません。何気なく普段からテストで行っていることを言語化しただけとのことです。

f:id:yohei-fujii:20191018130409p:plain

連続性の説明と注意点です。確かに、ここにあるように、お金と言っても米ドルのような通過になってくると、一概に連続性の単位が同じである訳ではないので気をつけなければなりませんね。

そしてなぜ境界値に気をつけなければならないのかという点ですが、日本語の難しさも絡んできます。

f:id:yohei-fujii:20191018130835p:plain

 

むむ。これ見ると確かに!と感じるかと思います。人によっては認識がズレる箇所でもありえます。

 

ここで平田さんが、わかりやすい図を出してくださいました。例として、パスワード登録をあげてくださっています。

 

f:id:yohei-fujii:20191018131937p:plain

テスト結果によってグループ分けされた値の集まりを「同値クラス」と言うそうです。そしてその中でも、有効であるものと無効であるものがあります。

 

上の例では、4文字未満、そして16文字以上である場合に、パスワードとしては無効になってしまいますので、「無効同値クラス」と呼ばれます。また使用禁止である「@」が入っている場合ももちろん無効となりますね。

 

そしてこの情報を元に、「同値クラステスト」と「境界値クラステスト」を行います。

f:id:yohei-fujii:20191018152827p:plain

同値クラステスト」では、「有効」「無効」それぞれのクラスから代表値を、「境界値クラステスト」では、境界値と境界値の1つ上と1つ下を選ぶんですね!

 

テストケースの例として以下のようにわかりやすく説明されています。

f:id:yohei-fujii:20191018195121p:plain

 NGのケースで、2つ目に挙げられているのがポイントですね。2つの要因を組み合わせないということ。確かに同時にやると、何が原因でテストが落ちるのかわかりにくくなります。この考え方は、普段実装する上で、不具合やエラーを探す時の考え方としても大切だと感じました。

デシジョンテーブル

そして2つ目が「デシジョンテーブル」つまり「意思決定表」です。

条件が複数ある場合に利用されるテスト技法です。

 

 「ソフトウェアテストの教科書」にあった例を参考に、説明して頂きました。

f:id:yohei-fujii:20191018195644p:plain

遊園地の乗り物などは、身長制限や年齢制限があったりもします。その際には、どのようにテーブルを作るのでしょうか。

f:id:yohei-fujii:20191018195739p:plain

まず、このように枝分かれした図をイメージします。今回は3つの条件があり、それぞれに対して、YesとNoがあります。つまり、8通りのケースが考えられます。

 

そしてそこからこの8パターンをテーブルに落とし込みます。

f:id:yohei-fujii:20191018200303p:plain

1番の人、つまり3つの条件を全てクリアした人が乗れる人ということになります。 

 

本来であればもっと複雑化していくと思います。他の例だと、会員種別やお金の割引率に関するものも紹介して頂きました。(「因子」や「水準」といった話も出てきましたが、長くなりますので割愛させて頂きます)

 

この説明を行いながら、このデシジョンテーブルを作るには仕様を把握していなければならないということを指摘されていました。。つまり「副次的効果として仕様確認ができる」という点がデシジョンテーブルにはあるということです。

 

テストケースの整理にもなるし、仕様把握の確認にもなるし、便利ですね!

さいごに

今回挙げてくださったテスト技法は、どのテストにおいても有効なものだということで、ご紹介頂きましたが、確かにわかりやすく、知っておいて良かったなと思うものでした。

 

最後に参考図書として、3つを挙げて頂きましたが、社内図書にもあるので、一通り読んでみようと思います。

  1. ソフトウェアテストの教科書
  2. はじめて学ぶソフトウェアのテスト技法
  3. ソフトウェアテスト技法ドリル