読者です 読者をやめる 読者になる 読者になる

Septeni Engineer's Blog

セプテーニエンジニアが綴る技術ブログ

fastlaneの簡単な紹介と使用例

iOS android

こんにちは、GANMA!の開発を行っているtakezawa(@to4iki)です。

今回は、fastlaneの紹介と導入方法・簡易的な使用例を紹介します。
また、ブログ内で使用しているサンプルコードは公開しているので良かったら参考にしてみて下さい。
Sandbox-iOS/FastlaneBox

fastlaneとは

fastlane/fastlane: The easiest way to automate building and releasing your iOS and Android apps
fastlaneは主にiOS/Androidアプリのビルド、テスト、デプロイを行うためのRuby製のタスクランナーであり、
アプリ開発の様々なフローにおける自動化をサポートしてくれます。
Twitter傘下のFabricに取り込まれており、また幾つかのCIサービスにも標準搭載されるなど今とても勢いのあるツールです。

action, lane

fastlaneではアクションと呼ばれる機能(タスクコマンド)を組み合わせたレーンにおいて自動化を実現します。

f:id:to4iki:20160907161228p:plain

主なアクションをfastlane/READMEから抜粋しました。

iOS
アクション 説明
deliver スクリーンショットメタデータ、アプリをApp Storeにアップロードする
snapshot 全デバイスを対象にアプリのスクリーンショット撮影を自動化する
frameit スクリーンショットを各デバイス画像にはめ込む
pem プッシュ通知用のプロファイルを自動生成したり更新する
sigh プロビジョニングプロファイルの生成、更新、修復する
produce 新しいアプリをiTunes ConnectやDev Portalで作成する
cert 証明書の作成と管理をする
spaceship Apple Dev CenterやiTunes Connectにアクセスする
pilot TestFlightのテスターを管理する
boarding TestFlightのbetaテスターを招待する
gym アプリをビルドする
match Gitを使って証明書とプロファイルを管理する
scan iOSアプリ、Macアプリのテストを実行する
Android
アクション 説明
supply アプリ、メタデータGoogle Playにアップロードする
screengrab 全デバイスを対象にアプリのスクリーンショット撮影を自動化する

この他、公式で提供しているアクションはActions - fastlane docsにて確認できます。

など痒いところに手が届くようなアクションも用意されているので、組み合わせの幅も広がりますね。

導入

faslaneをinstallしてみましょう(ここから先はiOSプロジェクトを例に説明します)。

versionを固定するためにBundlerを使用し、Gemfileに依存を定義。

source 'https://rubygems.org'
gem 'fastlane'

install

$ bundle install --path=vendor/bundle
$ bundle exec fastlane -v
fastlane 1.102.0

セットアップ

プロジェクトのルートでinitコマンドを実行し、雛形の設定ファイルを作成します。

$ bundle exec fastlane init

ターミナル上でApp Identifier, iTunes Connectへのログイン情報など幾つかの質問を答えます(Androidプロジェクトの場合も同様にGooglePlayの情報を入力します)。

完了すると、

  • ./fastlane/Fastfile: レーン定義を記述するための雛形ファイル
  • ./fastlane/Appfile: Developerに関する情報が記載されているファイル

が作成されます。

簡易的なレーン作成

雛形で生成されたFastfileをベースに少しだけいじってみます(RubyDSLを書いていきます)。
因みに$ bundle exec fastlane actionsでアクション一覧$ bundle exec fastlane listで現在のレーンの一覧が見れます。

今回はテストを実行 > Slackに成功/失敗を通知するだけのシンプルなフローを定義してみます。

Fastfile

require "yaml"

fastlane_version "1.102.0"
default_platform :ios

CONF = YAML.load_file('conf.yml')

platform :ios do
  before_all do
    ENV["SLACK_URL"] = CONF["slack"]["webhookurl"]
  end

  desc "Runs all the unit and ui tests"
  lane :test do
    # cocoapods
    # cathage
    scan(
      scheme: "FastlaneBox",
      clean: true
    )
  end

  after_all do |lane|
    slack(message: "Successfully")
  end

  error do |lane, exception|
    slack(
      message: exception.message,
      success: false
    )
  end
end

conf.yaml

slack:
  webhookurl: "https://hooks.slack.com/services/#{your_webhook_url_path}"

Slackのwebhookurlはconf.yamlファイルを作成しそちらに定義。
また、実運用の際はローカルで実行した場合にもSlackに通知が飛ぶのはやり過ぎなので、CI環境下で実行した場合にのみ結果を通知するよう設定した方が良いでしょう。

# https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Actions.md#is_ci
if is_ci?
  scan(skip_slack: false)
else
  scan
end

では、実行してみます。

$ bundle exec fastlane test

f:id:to4iki:20160914000211p:plain 成功/失敗の件数が整形された状態で表示されました。
(テスト結果表示用JUnitのレポート形式のhtmlファイルが./fastlane/test_output/report.htmlに出力されています)

Slackにも良い感じに結果が表示されましたね! f:id:to4iki:20160914001547p:plain

Travis CIとの連携

Travis CI上でfastlene経由のテスト実行を試してみます。

まず、Travisから流すレーンをシェルスクリプトとして定義(実行scriptは肥大化する恐れがあるので、事前に別ファイル等に分割しておくのをお勧めします)

fastlane/travis.sh

#!/bin/sh
fastlane test

実行権限を付与

$ chmod a+x fastlane/travis.sh

.travis.yml に諸々定義(fastlaneは最新版にupdateしておく)

language: objective-c
osx_image: xcode7.3
env:
  global:
    - LC_CTYPE=en_US.UTF-8
install:
  - gem update fastlane --no-ri --no-rdoc --no-document
script:
  - ./fastlane/travis.sh

最後に、TravisからBuildする必要があるのでターゲットのスキームは公開しておいてください(Xcode > Manage Schemes… > Sharedチェックボックスをオン)。
これで、$ git pushのタイミングでfastlane経由のテストが走るようになりました。

f:id:to4iki:20160914155424p:plain

他にも、xcov用のアクションを組み合わせればカバレッジの計測ができるので良かったら試してみてください。

カスタムアクション

用意されたアクションの呼び出しだけではなく、独自のアクション定義も可能です。
次のコマンドを実行しカスタムアクションの雛形を生成します。

$ bundle exec fatlane new_action

現在時刻を標準出力するだけのsampleアクションを書いてみましょう。

actions/sample.rb

module Fastlane
  module Actions
    class SampleAction < Action
      def self.run(params)
        puts Time.now
      end

      # only iOS
      def self.is_supported?(platform)
        platform == :ios
      end
      ...
    end
end

./fastlane/actions/配下のファイルはfastlane実行時にロードされ、既存のアクションと同様に使用出来ます。

desc 'Custom action'
lane :my_action do
  sample
end

より具体的な実装例はfirefox-ios-build-tools/fastlane/actionsなどを参考にして見て下さい。
プロジェクト固有の設定/処理などはカスタムアクションを作成し、レーンで使い回すといった使い方が出来そうですね。

プラグイン

fastlaneにはプラグイン機構が存在します。

試しに、Xcodeのグループに合わせてファイル/ディレクトリ構造を同期してくれるsynxをアクションとして提供しているプラグインをinstallしてみます。

$ bundle exec fastlane add_plugin fastlane-plugin-synx

実行すると、gemfileライクな依存解決用のファイルを自動生成してくれます。

Pluginfile

# Autogenerated by fastlane
#
# Ensure this file is checked in to source control!

gem 'fastlane-plugin-synx'

Gemfileにもブリッジが定義されるので、$ bundle installで自動的にプラグインもinstallされます。

plugins_path = File.join(File.dirname(__FILE__), 'fastlane', 'Pluginfile')
eval(File.read(plugins_path), binding) if File.exist?(plugins_path)

これで、レーンからsynxアクションを呼び出すことが出来るようになりました。

desc "Runs synx to folderize the Xcode project"
lane :sync do
  synx
end

snapshot

次にfastlaneが提供するスクリーンショット作成用のアクションを試してみます。
fastlane/snapshot
XCUITextを利用してスクリーンショットを撮るので、プロジェクトにUITests用のビルドターゲットを新設しておきましょう。

準備

下記コマンドで、どのデバイス/言語をターゲットにしたスナップショットを撮影するか指定するための設定ファイル(Snapfile)の雛形を作成します。

$ bundle exec snapshot init

devicesに設定する名前は$ xcrun simctl listを実行して確認が出来ます。
検証用にiPhone6sの日本語環境下のみをターゲットにします。

Snapfile

devices([
  "iPhone 6s"
])

languages([
  "ja-JP"
])

自動生成されたSnapshotHelper.swiftはUITestsのターゲットに含めます。
あとは、UITests中の任意のタイミングでsetupSnapshot関数を呼び出しましょう。

override func setUp() {
    super.setUp()

    continueAfterFailure = false

    let app = XCUIApplication()
    setupSnapshot(app) // 起動時のスクリーンショットを撮影する
    app.launch()
}
実行

runコマンドでスクリーンショットの撮影を行います

$ bundle exec snapshot run

実行後はscreenshots/screenshots.htmlがブラウザで開かれ、スクリーンショットを一覧出来ます。

f:id:to4iki:20160913233909p:plain

またレーンとして定義も可能です。

desc "Creates new screenshots and uploads them to iTunes Connect"
lane :screens do
  snapshot
end

より実践的な使い方

  • iTunes Connectへアップロードするバイナリ生成のためのビルドやパッケージ化
  • プロビジョニングプロファイルの管理
  • テスト用のAdHoc配信(deploygateやcrashlyticsなど)
  • リリース前の外部テスト配信 in TestFlight
  • iTunes Connectのメタデータ更新

などリリースフローの自動化を始めとする実践的なfastlaneの使い方は試せていませんので、参考資料を貼らせて頂きます。

iOSアプリ開発に必要な証明書とプロファイルをGitHubのリポジトリで一括管理する
iOSアプリ申請を驚くほど簡単に!fastlaneではじめる自動化入門

まとめ

fastlaneの紹介と簡単な使い方を紹介しました。
リリースフローの自動化もそうですが、オレオレシェルスクリプトによる車輪の再開発を防げる、属人化しがちなビルドやテストなどの実行をfastlane内だけで完結することで保守性が高くなります。
皆さんもfastlaneを使って快適で安全なリリースフローを運用しましょう!

参考

ScalaのTry型での例外処理コスト

Scala

こんにちは、広幡です。

最近Scalaのコードを見ていると、Try(throw new Exception)していたり、Failure(new Exception)していたりと、
人によってバラバラなので揃えたいなーと感じています。

そこで、どっちを扱うほうがいいのか気になったので少し調べてみました。

続きを読む

ランチ事情

こんにちは、今年4月から新卒として入社した佐野と申します。入社してから半年弱、先日ようやく一通りの研修を修了し実務にジョインすることになりました。研修で得た経験を活かして、これから貢献していきたいと思っております。

さて、バリバリ仕事に打ち込むために弊社にはこんな3つのコアバリューがあるのをご存知でしょうか。先進充実という3つの価値を尊重し私たちは仕事に励んでいます。

この充実とは。

何をするにも健康が資本ですよね?公私の充実は胃袋からですよね?腹が減っては…

そこで、今回のブログでは私たちのランチ事情を紹介していきたいと思います!

続きを読む

ECS。Taskスケールアウトのテンプレート

AWS AWS,クラウド インフラ

たかこです。
弊社のインフラは、今までAWSのserviceは全てCloudFormationで管理・運用していて、
各サーバー(Gateway(nat兼任)・Frontend・Backend・Batch)の構築はChefを使っていました。
そこからDockerを利用して使い捨ての環境を作っていこう、DevOpsをスムーズにしよう!と変化し、
Chef(Gateway(nat兼任))+ECS(Frontend・Backend・Batch)の環境を構築することにしました。
今回はTaskスケールアウトのCloudFormationのTemplateを書きます。

続きを読む

2015〜2016年で開発組織を作るためにやってみたこと

Scala スクラム DDD 勉強会

こんにちは、杉谷と申します。 GANMA!を開発しつつ、社内環境を整えたりとかしています。 この会社に入社してから3年(+1ヶ月)経ちました。あっという間!

いろいろやってきた結果、組織がますます良い感じになってきたので、会社ぐるみで試みてきたことをご紹介します。

2013〜2014でやってみたこと

入社1〜2年目は以下のことを行いました

  • Chatwork / Stash(現BitBucket) / Confluence / JIRAの導入
  • 開発ポリシーの制定
  • TDD研修・スクラム研修
  • システムリーダー定例
  • 裁量労働制の導入
  • 評価制度の改善
  • 会社標準PCをMacBookPro 15インチ(松)に
  • ゲーム部を立ち上げてみた

詳しくは前回のエントリ 2014年。開発組織を作るためにやってみた事 をご参照ください。

Slackの導入

2013〜2014の段階ではChatworkを利用していましたが、Slackに移行しました。

Chatworkを利用していたのは、"既に利用していたから + 特に大きな不満はなかった"というのが理由なのですが、 システム連携の楽さ・豊富さ、開発のしやすさ、エンジニアうけの良さ、を求めてえいやっと切り換えてしまいました。

移行してみた感想としては

  • プラグインが豊富で楽。システム連携では殆ど自分で開発しなくてもよくなった。
  • 物理より文字で会話したい、なエンジニアにはよく馴染む感
    • 文字の書き味・表現力がだいぶ良い
    • でも発言は気安い、チャット感がある。
    • 絵文字でのReactionが最高。 Cult of the Party Parrotが大繁殖f:id:ysugitani:20160808113531g:plain:w16
  • エンジニア以外の方々にはChatworkのほうが良さそう感は強い
    • チャンネル名・人名に日本語が使える
    • レスも発言単位に行え、1発言がメールとチャットの中間の重みを感じる。

といった印象で、移行に満足しています。

社内全レビューと社外レビュアー

良い開発を行うためにコードレビューは欠かせないのですが、 経験の浅いチームや人数が少ないチームではレビューの質や、視点の豊富さに不安が残ります。 誰かの思い込みによる主張で良くない方向にコードが曲がってしまう、とか最悪ですね。

これを防ぐため、チーム外からもレビューが行える仕組みを整えました。

我々はコード管理にAtlassian社BitBucketを利用しているのですが、そのプラグインに グループ単位でレビュアーを自動で追加できるプラグインWorkzoneというものがあります。

これを利用して、社内の全てのレビューに参加するグループを作成、 視点が偏らないように社外レビュアーとしてScalaドメイン駆動設計(DDD)伝道師のかとじゅん氏にも参加していただき、 現時点では2名で社内の全てのレビューに参加をしています。社外レビュアーはもう1名増える予定です。

なお、全レビューはあくまでアドバイスなので、指摘があってもマージなどはしても良いルールなので チームの自治権は維持されています。

"技術指針"の制定

上記全レビューを行う際、どういった基準で指摘を行うかを定めておかないと無用な混乱が発生するので、 前回エントリーで制定した"開発ポリシー"を進化させ、会社としての品質に対する考え方、採用する技術やその理由と例外、などをまとめた技術指針を作成しました。

内容は以下のような物です

  • 我々は”高速高品質”を目指す
  • 我々は保守性のあるコードを高速に生産する
  • Scalaを使う理由は気軽に品質を維持するため / Scalaを利用しない場合
  • スクラムを採用する理由はプロダクトオーナーがハンドルを握るため / スクラム以外を利用する場合
  • DDDを採用するのはチーム全員で要件の芯を捉え続けるため / DDDを採用しない場合
  • ユニットテストを書く理由はリファクタリングをし続けるため
  • テストを書く=遅いという思い込みを止めよう / テストを書かない場合
  • レビューを行うのは意識を保ち続けるため / レビューを行い続けるため属人性を高めない / レビューを行わない場合

全アクティブプロダクトでのScala・DDD採用率 100%

積極的に開発を続けているプロダクト全てが Scala・DDD採用となりました。(2016/8月次点で6プロダクト)

普及の経緯は以下の通りです

  1. GANMA!でScala・DDDの初採用
  2. GANMA!チームに他プロダクトから留学
  3. 留学を終え、Scala・DDDで新規プロダクト開発に着手。外部アドバイザーとしてかとじゅん氏も加わる。
  4. その後どんどん株分けが進み全てのプロダクトがScala・DDD化

ScalaMatsuri将軍スポンサー + 勉強会の多数実施

環境としてはずいぶんと胸を張れる状態になってきたので、知名度を上げようといろいろ活動するようになりました。

ありがたいことに、これらのイベント経由で弊社を知った、というご応募を頂くことも多くなってきていますし、実際に入社に至った方ももう数名になります。

今後もイベントを続けていく予定です。connpassの Septeni×Scalaグループに入っていただくと新しいイベントの通知が届くので便利です。

今後と求人

今後もプロとして誇れる仕事ができる職場でありつづけられるよう邁進してゆきます。

もし弊社にご興味をもっていただけたかたがいらっしゃいましたら 弊社コーポレートサイト経由のセプテーニ・グループ中途採用窓口までご応募ください。 オフィスツアーも毎月実施しています。こちらもオススメです!

以上です。 読んで戴きありがとうございました。

【保存版】Scala/Scrum/DDD 困ったこと50連発ガトリングトークでの質問に対する回答

Scala DDD スクラム 勉強会

こんにちは。 @kimutyam (木村)です。

先日は『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク』という勉強会にて登壇させていただきました。

scala-scrum-ddd-gatlingtalk.connpass.com

登壇後はガトリングすぎたのであっという間に終わったという意見がありましたので、

勉強会で質問していただいた内容の回答をまとめるエントリとします。 

勉強会内容について

www.slideshare.net

 

50連発でもスライド数173枚到達しました。

元々は100連発にしようと目論んでいたけど辞めてよかった...

以下のカテゴリで困ったことを50連発して各社でどのように解決してきたかというのが、このイベントの趣旨です。 詳細はスライドを参照ください。 

Q&A (Scala)

Question 1

Scala関連のドキュメントが英語ばかりで辛いです!良い読み方はありませんか? 英語覚えろks!以外でコツがあれば

Answer 1

セプテーニ・オリジナル 杉谷

英語を読むしか無いように思います。あるいは「100万円払うからplay2.5のドキュメント日本語化して!」と叫ぶとか。

オプト 平岩さん

自動翻訳して間違っててもいいから大意を掴み(掴んだ気になり)、その後目的の箇所を中心に読み進めるとかですかね? あと、英語は「覚える」ものなのかについては諸説ありそう。

CyberZ 門田さん

技術英語は読むんじゃなくて感じるんです

Question 2

非エンジニアにScalaをどうやって認めさせましたか? 「Scalaにしてる暇あったら機能増やして」に勝つ方法が知りたいです。

Answer 2

セプテーニ・オリジナル 杉谷

Scalaは型があり/表現力が豊か/IDE支援が強力、などの特徴から、慣れた後であれば他の言語に比べて圧倒的に楽にしっかりとした実装ができるし、慣れるのは大変ではない。PHPで同じ水準を保とうとすると大変だし、なによりPHPでそこまでちゃんとやりたがる人は多くない。つらい言語で衛生状態の悪いプロダクトをつくって人が寄りつかず衰退するよりは、より目的に合う言語で衛生状態の良い環境をつくり、組織を育てていくのであればScalaを積極的に利用しよう。という理屈でセプテーニ・オリジナルはScalaを利用しています。

オプト 平岩さん

一言で言うと、既成事実化しました(ニッコリ) ソフトウェアの減価償却の耐用年数を過ぎたら経営判断としてリプレースを検討した方が良いと思うので、それまで待つとか。

オプト 貴田さん

新機能の種類にもよりますが、マイクロサービス化できそうなのを立ち上げ時点からScalaで開発する方向はいかがでしょうか?

CyberZ 門田さん

誰か一人の意見ではなく、組織内のエンジニアの複数人の意見として上げました。メリットデメリットとか提示しつつ。 そもそも言語にこだわりは無いはずなので、越えるべきはラーニングコストかとおもいます。管理画面とか、ちっちゃいシステムとかでひっそり使って少しづつ慣れるのが一番かなと懐います。 それでも無理ならCyberZへお越しください

Q&A (DDD)

Question 1

DDDでドメインをコードに落とし込むところに工夫していることはありますか?

Answer 1

セプテーニ・オリジナル 杉谷

レイヤードなりヘキサゴナルなり、DDDに関係する全てのアーキテクチャドメイン層に余計なことをかかないようにするために産まれた物なので、ドメイン層にドメイン外のことをできるだけ書かずに済むよう気をつけます。またドメインに書くべき事がドメイン外に漏れ出さないようにも気をつけます。

オプト 平岩さん

DDDやってませんが、名前重要という空気と無駄な依存は作らないという空気はあります。

CyberZ 門田さん

名前付けですかね。ドメインに密接に関係すると何気ない名前でもすごく意味を持つので、後世のメンバーに誤解されないかをレビューなどでいろんな観点から考えます。ドキュメントも書きますけど、読まなくていいほうがカッコイイので。

Question 2

DDDって何が嬉しいのでしょうか?

Answer 2

セプテーニ・オリジナル 杉谷

セプテーニ・オリジナルでは採用するのはチーム全員で要件の芯を捉え続けるためにDDDを採用しています。「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。

オプト 杉泊さん

DDDやってませんが、とりあえず弊社内にて質問してみたところ、誰も答えをくれませんでした……。 DDDやってない人が傍から見て簡単にわかるような嬉しみは無いのかもしれませんね。

オプト 平岩さん

概念だけでも参考になる部分はあり、学ぶべき価値のあるものだと思いますが、実践するまでのコストをどう捉えるか、という要素はあるかなと思います。最終的にはやりたいかどうかなので、やりたい人がいれば是非チャレンジした方が良いと思います。

CyberZ 門田さん

ベタな話は置いといて、 ビジネスロジック部分に対してアプローチするフレームワーク的なものってあまりないので、一番フワッとする部分の「標準化」を図れるのはすごく大きいかなと思います 

Q&A (開発ツール)

Question 1

使えるツールやライブラリを探すときは、 どうやって探してますか?(有益なサイトとか)

Answer 1

セプテーニ・オリジナル 杉谷

ググったりして見つけた物で、githubで人気のありそうなものを選びます。あとはTwitterでスゴそうな人がオススメしているものを選ぶとか

オプト 平岩さん

うちのメンバーの場合はtwitterが多そう。あとはgithubのtrendをウォッチしておくとか。 【宣伝】技術系キュレーションメディアです、私も公式Clipperというのを務めさせていただいてます。ツールを探すときにもオススメ!

CyberZ 門田さん

サイバーエージェントグループ内の知り合いにざっくり聞いたりとか。 いくつかグループ内のGithubを覗いて使ってるもの見たりもします

Question 2

仕様をドキュメントで可視化するために、 何か便利なツールやライブラリがあれば教えてください

Answer 2

セプテーニ・オリジナル 木村

我々はAtlassian(JIRA,Confluence,Bitbucket, Bamboo)を使っており、 ドキュメントは基本的にJIRAとの相性がいいConfluenceを使っています。 グラフィカルなドキュメントが必要な場合は別のツールを使うこともあります。 コンテキストマップはCacoo。シーケンス図、フローチャートmermaidを利用しています。

また以前まではスプレッドシートで統合テスト仕様書を記載してましたが、 統合テストを自動(コード)化する動きをとり、Bitbucketで管理するようにしました。 自動化出来てない部分はMarkdownで記載後、Bitbucketリポジトリ上で管理してます。 これによりバージョニングも可能になります。

オプト 平岩さん

いろいろ試した結果、仕様については、マークダウンに向いてること or マークダウンでも頑張ればできることは極力マークダウンでgithub管理した方が良いよね、って流れになりつつあります。 あとはだいたいgoogle driveでやってますが、仕様書を補足するようなもの(管理資料や、仕様書になる前段階のもの)に限定しつつある感じです。議論しながら多人数でドキュメントを更新できるのは便利ですね。

CyberZ 門田さん

今全社あげて丁度探してるところです(笑)

Q&A (チーム運営・スクラム)

Question 1

振り返りで課題が出ないということはつまるところチームの運用が 上手いこといっているというポジティブな勘違いに至ることはないでしょうか?

Answer 1

セプテーニ・オリジナル 木村

勘違いしている可能性はあると思います。 ただ、本当に課題が出ない状況なのかは個人的には意識しております。 たとえ1~2週間の期間のスプリントでも課題が発生しないことの方が少ないからです。

例えば進捗が悪く見えるのに何も課題がないとなると、課題を言いづらい状況なのか 危機管理能力が欠落しているのかのどちらかだと思います。 課題を出さずにスプリント未達成になることは最悪なので、 そのような事案が発生しないように予防線をはっておくべきではあると思います。

オプト 平岩さん

課題が出ないのは、

- チームが取り組んでいるミッションの難度が低すぎる

- きちんと振り返れてない のどちらかなのではないかなと思います。

振り返りでしゃべってくれる人があまりいないこともあるかもしれませんが、チームの皆で互いにファシリテートしあえることが理想ですが、最初のうちはリーダークラスの人(スクラムマスターとは限らない)が責務としてファシリテートをやっていった方が動き出しやすいと思います。

ファシリテートについては、議論が進むように各人に発言を促したり、課題を示唆したり、といった司会っぽいファシリテートもありますが、発言しやすい空気、心理的安全をどうやって作るかということも重要になります。例えば、お茶やお菓子をいただきながらやっちゃう、という手段もあると思います。

CyberZ 門田さん

慣れたチームだとたまにあります(笑) 基本的にはマンネリになっている可能性が高いかなと思います。 無意識のうちに過去出したものを避けていたりなど。 ただ、今までやったKPTを見返してみたら、「そういえばあれTryで続いてたけど、最近やってないね」とかありますし、やり方や場所などをガッツリ変えてみたら大体うまく行きます。

Question 2

コードレビューをする側の時に気を付けていることはなんですか? レビュアーは何に気をつけるべきでしょうか?

Answer 2

セプテーニ・オリジナル 木村

【コード内容について】

- 要件を満たしているか  

大前提となります

- 何をレビューして欲しいのかが明確になっていること

明確になってないとレビューできません。

- コード内容を全て説明できること

例えばコピペが検知できたら理解せずに書いてる可能性が高い

- レビュアーへの配慮ができているか

レビュアーが理解できる粒度まで落とし込まれているかを確認します。 大抵はレビュイーよりレビュアーの人数が多いので、 レビューのコストを下げるためにレビュイーが コストを支払う方が全体コストが抑えられる可能性が高くなります。

【コミュニケーションについて】

- 指摘する際はサンプルコードを付与する

- 人格否定をしないこと

 

弊社社員がまとめている記事も合わせて参考にどうぞ

【暫定版】新人エンジニアのプルリクエスト入門

オプト 渋谷さん

重視すること

- 複雑でないこと

- 名前大事

- 異常値・エラーを正しく処理しているか

- 適切にテストコードでカバーされていること

- トレードオフについて検討がなされていること

 

重視しないこと

- ソースコードの書式や整形

CyberZ 鈴木さん

・人格を否定するコメントは一切書かないこと

・キツい指摘になる場合は、「かも」などをつけてやわらげること 以上、2点に気をつけています。

 

レビュー関係でモチベーションを下げることは気をつけたいですね。

Question 3

プルリクエストレビューについて、例えばRubyJavaがあって、 担当者の得意不得意があって Rubyのレビュアー、Javaのレビュアーが 固定されたりするのについて対策ありますか?

Answer 3

セプテーニ・オリジナル 杉谷

そのようにレビュー不能になる段階で組織の負けなので、できるだけ属人性が高まらないようにチームを組んでいきます。 GANMAの場合、iOSしかみれないサーバ側しか見れない、というのは少数で、Scala/Swiftどちらもみれるとか、iOS/Android/Play全部いじれるというのは普通です。

オプト 平岩さん 

フルスタック指向のある人はどんどん色んなことをやってもらうとか? スキルの問題なのか(知識不足・経験不足)人の問題なのか(意識、仲の良し悪し)は切り分けても良さそう。両方のケースが多いと思いますが。

CyberZ 門田さん

ビジネスロジックのレビューについては、よほど苦手意識が無ければみんなレビューは可能かなと思います。 言語的なレビューになるとある程度得意(好き)な人がやるので良いとは思います。 

Question 4

>プルリクエストの指摘

レビューの確認項目は大分類すると

1.業務要件が満たされているか

2.コードの美しさ

の2つあるかと思いますが、 この2つが混在するとコメントが増えていったり 本来レビューするべきことを見失ったり、 今の現場で起きています。

 

レビューの確認項目で何かルール決めなどされていたら教えてください

Answer 4

セプテーニ・オリジナル 木村

我々は『pull requestを利用した開発ワークフロー』を参考にして レビューコメントにタグをつけています。

 

業務要件が満たされていることは必須条件です。[must]のタグをつけてます。

 

コードの美しさは保守や拡張におけるコストを削減したいので求めたいです。 ただ、コードの美しさについては思想の違いによって 美しさの定義もばらばらですし、 ビジネスサイドとの兼ね合いも関係しますので、必要条件ではないです。 [IMO]のタグをつけます。

 

[IMO]をつけることで議論対象にし、 ROIがもっとも見込める選択をレビュイーとレビュアー間で合意した上で決定します。 コードの美しさにおける対応遅延が発生している状況はデイリースクラムで検知し、 プロダクトオーナーと相談して対応スコープを考え直すこともあります。

オプト 平岩さん

[MUST] とか [IMO] とか [nits] とかやってなくはないですけど、厳密にルールは決めてないです。 レビューの場だけでなくて、普段からオーラルコミュケーションも含めて取るようにしておくと、レビューも円滑に進むのではないかと思います。

オプト 貴田さん

まだ始めたばかりですが、レビュアーを複数アサインするのを試しています。「コードの美しさ」の方はどのレビュアーも気づいたら言ってくれると思いますので、業務要件の方をしっかり見てくださいという人を1人(以上)指名しておくのもいいかと思います。 

CyberZ 門田さん

スライドにも書いたのですが、リアルファイトにならないよう、 主張か事実かをはっきりするとかですね。

Question 5

タイムゾーンが合わない状況でどうやってビデオ会議するんでしょうか? 結構きつくないんでしょうか?

Answer 5

オプト 平岩さん

普段はそういう機会はあまりないですけど、一回、自社のイベントでlightbendの横田さん(マサチューセッツ州在住)にオンライン登壇していただいたときは、発表順を一番最後にすることで何とかしました。それでも向こう早朝だけど。 アメリカと打合せするときは、どちらかが早朝でどちらかが夜みたいな合わせ方が多い気がする。

CyberZ 門田さん

CyberZ USA(サンフランシスコ)にエンジニアが居て、日本のチームと一緒に開発していますが、日本の午前中が向こうの夕方ぐらいなので、リアルタイムに話す時間帯を絞ればそんなにめちゃくちゃキツくはないです。ただ、向こうの治安が悪いのであまり遅くまではやらないです。 

Question 6

Scurmってどんな問題をどのように解決してくれる手法何でしょうか?

Answer 6

セプテーニ・オリジナル 杉谷

 セプテーニオリジナルではプロダクトオーナーがハンドルを握るためにスクラムを採用しています。開発においてリソースが潤沢であることは希で、殆どの場合、限られたリソースの振り分け判断が重要となります。スクラムバックログを通してプロダクトオーナーの意図を表せますし、スプリントとストーリーポイントにより、コストも根拠を持って可視化することができ判断が的確になります。

オプト 平岩さん

ベロシティ計測が意味を持ち始めるには1年以上とか続けないと意味ないのではないかなとも思います。 私は諦めました><

CyberZ 鈴木さん

請負的な雰囲気なチームを主体的に持っていくマインドを変えるための手法です。

Scrumは、

・全てチームの承認を元に実行

・スプリントというマイルストーンごとでの計画

・少人数でのチーム編成 という各メンバーの責任感と一体感を醸成できる手法なので変化に強いと考えています。

Question 7

今までスクラムをやったことのないチームに 導入するのに苦労したことはありますか?

Answer 7

セプテーニ・オリジナル 杉谷

スクラムとはなにか、どういったルールになるのか、という基礎部分を全員理解するところがスタート地点である、というところが最も難しいところです。セプテーニ・オリジナルでは会社に講師をお招きし、社長も含め全社員が研修を受けました。

オプト 平岩さん

個人的には立ち上げたばかりの会社でやったので導入は苦労しなかったですが、以前流行ってたころに比べて、世の中的にスクラムというものに対して幻滅期に入ってる部分もあると思うので、「スクラムをやる意図」を関係者で合意する必要があると思います。 

CyberZ 鈴木さん

いきなりガチガチのスクラムを行うのではなく、最小限から入っていくという感じです。 結局ガチガチのスクラムは、回すのも大変なので、最終的にゆるいスクラムになっていますが。

Question 8

スクラムにおけるポイント見積もりのコツってありますか?

Answer 8

セプテーニ・オリジナル 木村

- 複雑度で相対評価

- ポイントが大きくなるにつれて不確実性が増すことのでポイントの幅を増やす

フィボナッチ数列を採用するケースが多い印象

- ポイントが大きいチケットに関しては分割を検討

 

基本的に『エッセンシャルスクラム』を参考にしています

CyberZ 門田さん

スクラムでポイントは付けていないです。タスクを理解(イメージ)できているかどうかは、スプリント計画時に確認するのであまり問題はないです 

 

Question 9

レビューの大きさってどんなもんでしょうか? 小さな単位(メソッドの単位とか)でやるとやりやすいとは思うんですが、 全体を俯瞰してレビューできないかな、とも思います。

Answer 9

セプテーニ・オリジナル 木村

レビューのそれぞれ解決したい内容が異なるはずなので、 一概に粒度のレギュレーションは決めかねますが、 レビューしてもらうモジュールを限定的にする努力はしてもらう感じです。 チケットスコープ=プルリクエストスコープである必要はないと考えます。

 

また、単一責務の原則(SRP)、開放/閉鎖原則(OCP)が守られていないとレビュー粒度が肥大化すると思います。 責務=変更の理由であり、変更の理由が複数になっている場合は修正範囲が増える傾向があります。 拡張に対して開いていればコードの再利用ができ、修正に対して閉じていれば修正箇所を限定でき、 結果レビュー粒度が小さくなります。

 

土台コードが腐っているとレビューの度にボディブローを浴びるので、 そのような状況の時は技術的負債を返済する動きをとって事前に予防するのも大切かと思います。

オプト 平岩さん

コードレビューをするということと、ハイレベルアーキテクチャを把握するということは、別のタスクではないかなと思います。

 

ハイレベルアーキテクチャを理解できていないことが、コードレビューにとってマイナスになるなら、レビューに入る前にアーキテクチャを理解する工数を確保すべきかなと。方法はいろいろ(ひたすらドキュメント読む、詳しい人と打合せする)あると思いますが。

CyberZ 鈴木さん

全体のレビューは、GitHubではなく別で設計レビューという形でやっていますね。

 

なので、GitHubで見るコードレビューは基本的には、 小さい単位に分割してWIPでもらってレビューを実施しています。

Question 10

スクラムからDevOpsへ移行する検討はあるのでしょうか?

Answer 10

セプテーニ・オリジナル 杉谷

DevOpsとされるものの効果の「頻繁なリリースを可能にする」と相反するのでは?というご質問だとすると、スクラムだからといってスプリント区切りでしかリリースしないわけではないので、移行する物では無く共存する言葉だとおもいます。

オプト 平岩さん

スクラムとDevOpsは対立する概念ではないと思います。スクラムは方法論に近く、DevOpsは概念に近いかなと。

CyberZ 鈴木さん

スクラムとDevOpsは対立する概念ではないですね。 

Q&A (その他)

Question 1

PHPの開発で破綻したことはどんなことだったのでしょうか?

Answer 1

セプテーニ・オリジナル 杉谷

テストも無く設計のポリシーや知識もないまま機能追加を塗り重ねた結果、不具合が頻発し、業務として使い続けるには信頼できる品質ではなくなってしまった、という内容です。なお言語が悪いわけではなくPHPでも技量と衛生維持の意識さえ有ればちゃんとやることは可能です。

勉強会風景

勉強会は弊社の牧場スペース(!?)で行いました。

オープニングトーク(杉谷)

f:id:kimutyam:20160727194139j:plain

発表(木村)

f:id:kimutyam:20160727195649j:plain

LT&懇談会

f:id:kimutyam:20160727215015j:plain 

感想

この勉強会はScala将軍達の後の祭り#7 市ヶ谷Geek★Night「Scala大名の平成維新〜殿中でScala!〜」の懇談会で技術話をしていたCyberZさんとオプトさんと類似した開発手法および技術を扱っていることに気付き、3社で何か共同勉強会をやってみれば面白いんじゃないかとなったのが話の発端です。

Scala/Scrum/DDDで各社話そうと言ってましたが、会社の色がそれぞれ出ていて面白かったです。

CyberZさんとオプトさん改めてありがとうございました。 

 

各社のTipsのまとめとしてイベントに参加いただいた方含め、このエントリをみていただいている方の何か役に立てると大変嬉しく思います。