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

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

re:Invent 2016 参加レポート

こんにちは、開発の田中です。
最近は HULFT IoT の開発や、エッジコンピューティングの研究開発なんかをやっています。

はじめに

本記事は、アプレッソ Advent Calendar 2016 7 日目の記事です。

アプレッソ Advent Calendar 2016

先週ラスベガスで開催されていた AWS re:Invent 2016 に参加しておりましたので、その参加レポートを書いておこうと思います。

re:Invent は開発者向けのイベントで、開発者の方であれば得るものも多く、非常に刺激のあるイベントです。
読んでいただいた方がぜひ行きたいと思う記事になればと思います。
(現地レポートや、まとめ記事、新サービスを網羅するような記事ではありません。)

私は昨年も参加しましたので、昨年と比較してどうかという感想も書いていきたいと思います。

2 つの Keynote

f:id:ktanaka89:20161206145632j:plain

re:Invent では 2 回の Keynote で怒涛の新サービス発表が行われます。
今年は昨年と比較してもより多くのサービスが発表されましたし、そのインパクトもいろんな意味で大きかったと思います。

私が気になったサービスをざっくりカテゴリ分けしてみました。

  • クラウドへの移行
    • AWS Snowmobile
    • AWS Snowball Edge
  • AI
    • Amazon Rekognition
    • Amazon Polly
    • Amazon LEX
  • プリミティブなサービスを補完する系
    • Amazon Lightsail
    • AWS Step Function
    • Amazon EC2 Systems Manager
    • AWS Glue
    • AWS Batch (?)
  • 開発者をサポート
    • AWS CodeBuild
    • AWS X-Ray
    • AWS Shield

特にプリミティブなサービスを補完するサービスについては、非常にインパクトがありました。
いままで AWS のパートナー各社が自力でやっていたようなサービスが AWS によって管理され、運用コストも減るとなればユーザーにとっては非常にありがたいのではないでしょうか。

AWS Glue は名前が示すとおり、糊付けを行うサービスとのことです。
ストレージとしては、S3, RDS, DynamoDB があり、DWH には RedShift があり、BI には QuickSight がある。
しかし、今までそれらを糊付けするサービスがなかったので、AWS Glue を作りました、とのことです。
実際 ETL はさまざまなパッケージベンダーが提供しているにも関わらず、なぜ AWS が自身で提供する必要があったのかという問には、ETL を実装しているユーザーはたくさんいるが、実際にそれらの製品を利用している人は少ない、とデータを示していました。
うむ。

Keynote を通してあまりにもたくさんのサービスが発表されるので、Keynote の終盤は周囲をみるとだんだんついていけなくなってる人がいたような...

また今回強調されたキーワードとしては、以下のものがあったと思います。

  • クラウドへの移行
  • パブリックセクター・金融業界での導入

全てを AWS クラウドへ持っていける/持っていきたいという意思があり、それを支えるだけのサービスは用意した、という感じです。
また、AWS クラウドは公共機関や、金融業界などのセキュリティ、運用可能性、俊敏性などあらゆる面でシビアな業界でも使用に耐えられるプラットフォームであると主張していました。
昨年の新サービスや流行りを思い出すと、AWS Lambda や AWS IoT, API Gateway, Kinesis Firehose など、クラウドの可能性を模索したり広げたりするサービスがメインであったなと思います。

ブレークアウトセッション

私は主に、IoT 関連のセッションを受けていました。

  • IOT303 - Innovation After Installation: Establishing a Digital Relationship with AWS IoT
  • IOT202 - Internet of Things (IoT) Edge and Device Services
  • IOT203 - 1-Click Enterprise Innovation with the AWS IoT Button
  • IOT205 - IoT Analytics: Insights for a Connected World
  • IOT304 - IoT and Beyond: Building IoT Solutions for Exploring the Final Frontier

IoT に関してもいくつか新サービスが発表され、その一つに AWS Greenglass があります。
ざっくりいうと、AWS Lambda がネットワークエッジに下りてきた感じです。
まだ実際に使ってみることができないし、詳しい情報も不明です。

f:id:ktanaka89:20161206151730j:plain

ネットワークが不安定な場所にいるネットワークエッジで、常に安定してデータを送ることができない状況では、エッジはエッジで自立して活動し、ネットワークが繋がったらクラウドと情報を同期する、というような使い方を想定しているようです。
どこまで通用しそうなものなのか早く試してみたいですね。

また IoT プラットフォームとしての AWS をどれだけ簡単に素早く検証してもらえるかの工夫もありました。
その一つが AWS IoT Button と AT&T の IoT Starter Kit です。
AWS IoT Button はまだ日本では使用することができませんが、Amazon Dash Button でまずはユーザーとして使うことができます。

f:id:ktanaka89:20161206151732j:plain

展示や日本人同士の交流

相変わらず展示会場は広大でした。

f:id:ktanaka89:20161206153239j:plain

昨年は日本からは私達 HULFT の展示だけだったかと思いますが、今年は SORACOM 様、スカイアーチ様、富士ソフト様、サイボウズ様、mobingi 様など、多くの企業が挑戦に来ていました。

re:Invent にはジャパンツアーで 400 人 (くらい?) が来ていて、その方々が一同に集まる懇親会が開催されます。
ラスベガスというある意味隔離された場所で、しかも re:Invent 中という限られた時間という状況だと、日本にいるよりも濃いコミュニケーションが取れると思いました。
普段お会いすることが無いような方とも話すことができますし、re:Invent に来るメリットの一つはここにあると思います。

全体感

開発者はぜひ一度は行くべきイベントだと思います。
カンファレンスの開催の仕方を見ると、この人達は世界を動かしているなと本気で思いましたし、顧客のためにあらゆる手を尽くすと感じました。
自分も同じ土俵で勝負をしてるんだなと思うと、じっとはしてられませんよね。

というわけでみなさんぜひ一度は AWS re:Invent に行きましょう!!

おまけ

宿泊したホテル「ベネチアン」。
周辺のホテルは全部巨大で、歩いていると距離感がおかしくなります。

f:id:ktanaka89:20161206150513j:plain

アメリカに来たのであればまずは肉を食わねば。

f:id:ktanaka89:20161206150343j:plain

AWS Snowmobile 。
Keynote での初登場時は何のジョークかと思いました。

f:id:ktanaka89:20161206153443j:plain

参考

前回の参加レポートはこちら

re:Invent 2015 0 日目 - AWS 訪問 & シアトルセッションレポート - Appresso Engineer Blog
re:Invent 2015 1 日目 - ウェルカムレセプション & ブース展示 - Appresso Engineer Blog
re:Invent 2015 2 日目 - 基調講演 & ブレークアウトセッション & 展示 - Appresso Engineer Blog
re:Invent 2015 3 日目 - 基調講演 & ブレークアウトセッション & 展示 - Appresso Engineer Blog

セッションの動画

www.youtube.com

JUnitを試してみる

アプレッソ品質マネジメント部の磯です。最近メインDAWをableton Live8 から Live9 へバージョンアップしようか悩んでいます(ニッチな話)。

ちょこちょことアプレッソ技術ブログにエントリを書かせていただいてますが、今回はAdventCalendarにも進出してまいりました。 5日目の記事になります。

qiita.com

ではまず自分語りから始めさせていただきましょう!!

自分語り

私はずっとQA領域でお仕事してきたわけなのですが、一口にQAといいましても現場により呼ばれかたは様々です。

  • QA
  • テスト
  • 検証

しかし、実態は同じだったり異なったり・・・。

一般的にはQAというとプロセスについて着目した活動が多い印象があります。 一方テストというとシステムテストなどのフェーズ、GUIを伴った対象を動かして得た結果から品質を確認していくといったところでしょうか。

f:id:yoiso:20161204174810p:plain

このあたりも現場によっては統合テストよりになることもあるかと思います。

ちなみにアプレッソにおける品質マネジメント部の業務としては、上記の一般的なQA/テストで行われる業務のハイブリッドとなっています。

テストの自動化

さて、今回はテストの自動化に絡んだお話をしたいと思っています。

以前より、わたしの生息するQA/テスト界隈でも自動化の波が押し寄せてきています。

Selenium Selenium - Web Browser Automation

Appnium Appium: Mobile App Automation Made Awesome.

かつては高価なプロプライエタリのソフトが主流だった中で、OSSも洗練され大きく利用されるようになってきました。

こういったものを利用することで、基本的なテストは自動化を行って、よりクリエイティブなテストは手動で行っていくということが実現できます。

また、これらはプログラマブルである以外にも、実際の操作を記録して再現するといった機能を有しています。

以前にこういったエントリを書きました。

appresso.hatenablog.com

単体テストの自動化がアジャイルな体制においての品質保証の土台として大きく貢献する、ということでした。

また、アプレッソではスクラムによる開発を行っていますが、野口からのエントリにもありましたとおり、機能横断的なチームという点では課題があります。

appresso.hatenablog.com

現状において、GUI上からのテストについては自動化を進めていますが、さらなるスピード感をもって臨機応変にQAしていくためにはさらに必要なのはなにか・・・。

そうだ! プログラミングを学んで単体テストにも手を広げていねば!と思い至りました。

(そもそも「コード書けんのかい!」というツッコミもありそうですが、職能的に書けることが必須ではないため、往々にしてそんな状態の人が多いのではないかと思われます。)

というわけで、私はそこそこおじさんなのですが、新卒社員の様にこつこつとJavaを学んでいるところなのであります。

JUnit はじめの一歩

前置きが長くなりましたが、JUnitを試してみましょう!

導入

Eclipse, IntelliJ IDEAなどメジャーなIDEにはあらかじめJUnitが付属しているため、あらためてインストールする必要はありません。

今回はEclipseを使っています。

新規メニューから「その他...」を選択するとウィザードが起動します。

f:id:yoiso:20161205012347p:plain

たしかにJUnitテストケースが作成できますね!

つかってみる

今回は以下のような(かわいらしい)コードを使って単体テストを書いてみました。

入力値が偶数/奇数をチェックするクラス(hogehoge)およびテストケース(hogehogeTest)です。

入力値が2で割りきれる場合に「偶数です」、2で割り切れない場合に「奇数です」と文字列が返されます。

(なぜかはてなのスーパーpre記法がうまく働かなかったので、gistから貼り付けています。)

これを実行してみると、Eclipseの左ペインに結果が表示されます。

f:id:yoiso:20161205013320p:plain

緑になりました!

さて・・・現状ではここまでですw

おわり

はじめの一歩というよりも、下駄箱から靴を取り出そうとしたくらいではありますが、俺たちの本当の戦いはこれからだ!マインドで日々精進していきたいと思っております!

(追記12/6: JUnitをJunitと記載していたのを修正・・むむ!)

わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか

こんにちは、開発部の野口です。
最近メイン DAW を Cakewalk SONAR から PreSonus Studio One に移行しようかどうか検討中です。(ニッチな話)

本記事は、Appresso Advent Calendar の 3 日目の記事です。

qiita.com

昨日の記事の最後に、スクラムマスターの土岐からバトンを受け取ったので、今日は「1 週間スプリントのプランニング」について書きます。

目次

はじめに

私は DataSpider Servista の次期バージョン開発チームで、開発者をやっています。

昨日の記事で紹介したように、3 ヶ月前からスクラムによる開発を行っていて、スプリント期間は 1 週間に設定しています。

スクラムによる開発を始めた経緯や、スクラムによる開発の様子については、ぜひ昨日の記事をご一読ください。

appresso.hatenablog.com

この記事では、「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」について、その始まりから、実践、メリット、今後の課題についてお話ししていきます。

やる前に ― 与えられた状況と不安

スプリント(イテレーション)期間を 1 週間にする!」という話を聞いて、「なるほど 1 週間か、いいね、それでいこう」とただちに思える開発者は、まだそれほど多くないと思います。

始めた頃の私たちもそうでした。

なにしろ、ほんの半年ほどまではこのようなプロセスで開発していたので、

https://cdn-ak.f.st-hatena.com/images/fotolife/t/tokita93/20161201/20161201165659.png

「1 週間? いいネ、毎週デリバリーしてこ!」といきなり思えるほうがおかしい。

与えられた状況

本物のスクラムでプロジェクトを運用すると決めたとき、私たちが受け入れることにしたのは以下のような条件でした。

  • スプリント(計画に始まり、機能を開発して、ふりかえりに終わる)期間を 1 週間にする
  • スプリント計画では、すべてのタスクを 0.5h or 1.0h まで分解する

根拠は、昨日の記事でも何度か登場した、認定スクラムマスター研修講師の江端さんのおすすめです。
私も研修に参加したのですが、この話が出たときあまりのショックに思わず「マジでやるんですか」と聞いたら「やるんです」と言うので、「やるか」と思いました。

でも、やるんだよ!―それが君のなすべきことなんだとしたらね」
――― Jonathan Rasmusson(『アジャイルサムライ』pp.287)

1 週間だ。私を信じろ
――― Ron Jeffries(『スクラム現場ガイド』pp.178)

やるんです
――― Kazumasa Ebata(某日某所 認定スクラムマスター研修会場にて)

そもそも、スプリント計画とは何か?

ところで、スプリント計画(Sprint Planning)とは何でしょうか。

Sprint Planning はスクラムフレームワークで定められたセレモニーの一つで、簡単にまとめると、以下のようなものです。

  • 参加者はスクラムチーム全体(開発チーム、スクラムマスター、プロダクトオーナー)
  • 優先順位付けされたプロダクトバックログから、今スプリントで開発する PBI(Product Backlog Item)を選び出す
  • チームはタスクレベルでの計画を行い、最終的にスクラムチーム全体として計画へのコミットメントを行う

Sprint Planning によって、短期(スプリントレベル)の ROI を最適化します。
プロダクトオーナーによって最も必要とされている PBI が選び出され、チームは最大限の PBI を完成させられるように計画を行います。

成果物は、コミットメントです。
「完成できそう」「完成できるかもしれない」ではなく「完成させます」という「約束」です。当然ながら、「すみません、一日遅れます」もありえません

予想ではなくコミットメントであるということは、スクラムの透明性を確保するために重要な部分だと思います。

できるのか

とは言ってみたものの、不安です。

1 週間以内の完成を約束する? そのためにタスクを 1 時間以下の単位に分割する?
どちらも、できそうなイメージが湧きません。

以下のような不安がいくらでも湧いてきます。

  • 2 週間のイテレーションによる開発を既に始めてはいた……ものの、タスクの見積もり単位は 4h とか 8h とかだった。それをさらに 4 つ、8 つに分ける? 細かすぎませんか? 数が多すぎませんか?
  • 計画した機能を期間内にすべて完了できたこともほとんどなかった。2 週間でも! なのに、さらにその半分の期間だって?
  • 1 週間で「完了」させ続けるなんて、オーバーヘッドが大きすぎて何もできないのでは?
  • 1h 以下に分割するには、メソッド単位の設計が必要になりそう。BDUF(事前の過剰な設計)を助長するのでは?

とにかく、やってみるしかありませんでした。

やっていく ― それから 3 ヶ月後のわたしたち

9 月前半にスクラムによる 1 週間単位の開発を始め、それから 3 ヶ月あまりが経ちました。

それがとてもうまくいっていることは、昨日の記事で紹介された通りです。

では、「1 週間のスプリント計画、タスクは 1 時間以下」という制約を、どのように克服したのでしょうか。

どうやっているのか

はじめに言っておくと、さまざまな紆余曲折を経ました。

スクラムでは毎スプリントの終わりに必ずふりかえり(Sprint Retrospective)を行い、開発チームとして、必ず何か一つ(以上)の改善アクションに合意します。
そうやって少しずつ改善してきました。

その経緯をくだくだしく説明することはしません。現在のやり方を、かいつまんで紹介します。

1. PBI ごとにチーム分け

1 時間未満に分割しようとすると、タスクの数は膨大になります。(たとえば、今スプリント = 今週のタスク数は付箋の数で 82 枚でした)
もちろん、そのために設計上の調査や議論も必要になります。

だから、私たちは、PBI をある程度(ストーリーポイント数から判断して、ほぼ確実にコミットできるだろうという数だけ)選択したあと、まずチームをいくつかに分けて、並列で見積を始めます。

最近は、1 スプリントでだいたい 4 つ~ 6 つ程度の PBI に取り組むという傾向です。
ただ、並列度を最大化するのではなく、だいたい 2 ~ 3 チームに分かれて見積もります。1 チームが平均 2 つの PBI を見積る計算になります。

2. DEV メンバと QA メンバでそれぞれ計画

これは課題でもあるのですが、チームには開発部のメンバー(DEV メンバ)と品質管理部のメンバー(QA メンバ)が混在しており、スキルセットがかなり異なります。
この図を見れば、その背景をわかっていただけるかと思います。

https://cdn-ak.f.st-hatena.com/images/fotolife/t/tokita93/20161201/20161201165659.png
▲前バージョンまでの開発体制。「開発チーム」と「QA チーム」は部レベルで異なる(開発部と品質管理部。もちろん上司も違う)

そのため、(残念ながら)計画においても、実行においても、DEV タスクか QA タスクかによって担当者が限られます。
よって、DEV メンバと QA メンバはそれぞれでタスクの見積りを行っています。

前項の「PBI ごとに分かれる」ことと組み合わせると、結局、スプリント計画中に最大で 4~ 5 グループ程度に分かれて調査・見積を行っています。

3. 「チェックポイント」を設ける

DEV / QA のスキルセットが大きく異なるという背景もあり、「プログラマが実装してから、テスターが手動テストをする」というモデルが残っています。*1
しかし、「すべての開発が終わってからテストを始める」のでは、とても 1 週間では完了できません。

だから、「チェックポイント」を設けて、計画中に「ここまでできたら、ここまでテストできる」ということを取り決めます。
この取り決めは、分かれたグループごとに DEV / QA で集まって行っておき、のちにチーム全体でレビューします。

4. タスクに分ける

さて、いよいよタスク分割です。

当然ですが、計画では、実際のコードを見ます。
ときには少しだけコードを書いてみて、動作を確かめたりもします。

設計上の議論もしますが、UML のような成果物は原則として残しません。議論したことを覚えていれば十分だからです。一週間なら、覚えていられます
量が多く、覚えていられなそうなときには、試しに書いたコード辺のスクリーンショットを撮ったり、クラス名をメモしたりします。
どれくらいメモするかということは経験による感覚なので、一概には説明できません。

ある程度設計が見えてきたら、タスクを作っていきます。
基本的には作業の順に上からタスク化していき、1 時間以内におさまるものはそのままタスクに、1 時間でできなそうな作業は、どうすれば分割できるか考え、分割して、1 時間以下のタスクの集まりにします。

私は DEV メンバなので、残念ながら QA メンバのタスク分割に参加したことはありません。(本当に残念です……)
現在は、テスト項目の大まかなリストを作っていて、1 時間以内の単位で区切ってタスクとしているようです。

5. QA 観点チェックとフィードバック

前述のように、QA メンバはテスト項目の大まかなリストを作ります。
テスト専門家のリストなので、DEV メンバが想定するものよりも、より広範で緻密な観点になっていることが往々にしてあります。

だから、そのテスト項目リスト(「QA 観点」と呼ばれています)を DEV メンバはレビューし、設計上の考慮漏れや自動化テストの不足を補います。
また、時には実装上リスクの高い箇所のテストが案外手薄なこともあり、その場合は QA メンバにフィードバックします。

6. チーム混ざってレビュー

計画もいよいよ大詰めです!

チェックポイントを定め、すべての作業を 0.5h または 1h のタスクに分割し、DEV / QA 間のフィードバックも行いました。

はじめにグループを分けて計画を始めましたが、1 週間で確実に機能を届けるために、すべてのメンバが、任意のタイミングで、任意のタスクを実行できることが目標です。

だから、できあがったタスクリストを、皆で集まってレビューします。そして、タスクに不明瞭な点(「このタスクは何だ? 私はこのタスクを正しく実行できそうにない」)があれば、質問します。
結果として、計画がより洗練され、実際のところ、誰でも任意のタスクを実行できる状態になります。

わかりやすい指標を上げると、1 つの PBI(→1 件の Pull Request になる)には、だいたい 2 ~ 3 名のコミットが含まれます
もちろん、2 ~ 3 名を予めアサインしているのではなく、日々の状況に応じて各自が最適なタスクを取った結果、2 ~ 3 名が 1 つの PBI に関わることになります。

ただし残念なのは、このプロセスも基本的には DEV と QA で分かれて行っていることです。

7. 調整&コミットメント!

こうやって、1 週間で実行する、数十(今スプリントでは、82)のタスクができあがります。

タスクの見積を合計し、今スプリントの稼働時間と比較します。この際は、これまでの実測データに基づくバッファ率を掛けてから比較します。

見積が稼働時間を下回っていたら、PO に新しい PBI を選んでもらいます。(もちろん、収まりそうなサイズのものにします)
あまりありませんが、見積が稼働時間を上回っていたら、泣く泣く PBI を一つ諦めます。*2

開発チームとプロダクトオーナーが共に計画に満足したら、スクラムチーム全体としてコミットメントします。

閑話 : 紆余曲折について

私たちは、さまざまな紆余曲折を経て、今このプロセスで計画を行っています。
そして、これからもプロセスを変えていくでしょう。

スクラムにおいて、いやスクラムではなくても、チーム活動において、難しい課題に際して、チームとして紆余曲折を経ることは、おそらく必要です。

「うまいやり方」はあるでしょう。
しかし、それを読んだり聞いたりして、そのまま真似しても、うまくいかないと思います。「そのチームのやり方」になっていないからです。

結論が同じだとしても、チームとして紆余曲折を経て得た解決策は機能し、ただ輸入しただけの解決策は不完全にしか機能しません。
不思議ですが、それが人間の集まりというものなのだと思います。

こんなに苦労して、なにが嬉しいのか

f:id:enk_enk:20161202175814j:plain
▲スプリント中のスプリントバックログの様子。真ん中の「P O」は「この PBI の開発完了したのでプロダクトオーナーは動作を確認してね」という意味です

閑話休題。

ようやく「なぜか」の話にたどり着きました。

わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか。

実際にそのやり方で 3 ヶ月やってみて、以下のようなメリットを感じています。

非常に正確に予測し、コミットメントができるようになった

計画した機能を期間内にすべて完了できたこともほとんどなかった。2 週間でも! なのに、さらにその半分の期間だって?

1 週間スプリントを始める前に感じていた不安の一つです。

結果はどうだったでしょうか?

スプリント期間を 1 週間にして最初のスプリントでは、完了できた PBI は 1 件でした。
わはは。

誰だって、始めたばかりの頃は下手クソでした。開発チームも、プロダクトオーナーも、(結果が直接見えないのでわかりませんが、たぶん)スクラムマスターも。

でも 3 ヶ月たった今、コミットメントした PBI をほぼ確実に届けることができています。*3

なぜかベロシティも上がった

1 週間で「完了」させ続けるなんて、オーバーヘッドが大きすぎて何もできないのでは?

これもまた、不安の一つでした。

結果はというと、以下の通りです。

  • 2 週間スプリント期の平均ベロシティ : 5.4(※1 スプリントあたりに換算)
  • 1 週間スプリント期の平均ベロシティ : 8.65

ベロシティ = スループットが、60% 向上しました。

不思議ですが、これが結果です。

でも、まだまだ、まだまだです。
これからもっと上げていきます。

より集中できるようになった

ベロシティが上がった理由の一つとして、「より集中できるようになった」ことが挙げられると思います。

開発者として、かつては、「仕様・設計・実装を同時に(並行で)考える」ことを日常的にしていました。

しかし、1 週間スプリント・1 時間以下のタスク分割を実践するようになった今、それが大きなストレスだったことがよくわかります。

美しい仕様と美しい実装は、しばしば対立します。そのため、実装中に(不確定な)仕様のことを考えるのは大きなストレスになります。(「ユーザにとってはこちらの方がいいはずだ。しかし、実装は難しい。設計レベルの変更が必要だ。待てよ、本当にユーザにとってはこちらのほうがいいのだろうか? いや、しかし……PO に相談しようか? でも、実現可能性がわかってからの方がいいよな……」)

スプリント計画でタスクを 1 時間以下に分割すると、仕様上の懸念点は計画中にほぼ一掃されます。
そのため、軽快に実装を進めることができます。

たのしい!

軽快に実装を進めることは、たのしいです。

悩むのが好きな人もいるでしょう。私もそうです。
人口上位 5% には入る自信があります。

しかし、1 時間以内のタスクを軽快に消化していくたのしさには、なかなか代えがたいものがあります。
毎日会社に行くのが楽しみになります。

苦しくない

魔法はありません。

軽快に実装を進めるのがたのしいということは、そのための準備が決して楽なものではないということです。

タスクを 1 時間以下に分割する作業は、楽ではありません。

しかし、ここがスクラムのいいところで、それを一人で行う必要はありません。

スプリント計画は、セレモニーです。チーム全体で行います。

苦しいのは自分だけではない。そのことが、計画の苦しみを軽減させます。

実際のところ、苦しいというほどのものではなくて、課題の厳しさを感じることもありますが、それもまた楽しいものです。

BDUF ではない

1h 以下に分割するには、メソッド単位の設計が必要になりそう。BDUF(事前の過剰な設計)を助長するのでは?

最後に、この不安について。

まず、メソッド単位の設計は、時には必要です。
○○クラスに○○メソッドを追加する、みたいなタスク、ちょいちょい出てきます。

でも、ものによってはそれほどでもありません。
たとえば、「プロジェクト名、スクリプト名、○○、○○を保持するモデルクラスを作る」みたいな書き方になっていたりもします。これで十分小さく、またチーム全員に通じるからです。

そして何より、Big ではありません。
たかだか 1 週間分の計画です。1 週間分の作業を 1 時間以下の単位で設計しても、BDUF(Big Design UpFront)とは言えない、というのが率直な実感です。

BDUF の問題点は、のちの要求変更などによって、多くの事前設計、事前作業が無駄になることです。
1 週間分の PBI、それも優秀なプロダクトオーナーによってよく書かれた PBI であれば、そのために行った作業が無駄になることはまずありません。

もちろん、「モデルクラスを作る」の例に見られるように、不要な詳細までは設計しません。
ここは実装者におまかせでいいよね」というのが計画中の頻出フレーズとなっています。

課題

1 週間スプリントの計画について、その端緒から、実践、メリットについて書いてきました。

現状の課題についても、簡単に記しておきます。

計画に時間がかかる

現状、計画にはだいたい 6 ~ 7 時間くらいを費やしています。
ほぼまる 1 日です。

スプリントが 1 週間なので、実に全体の 20% です。

それでもやる価値は(間違いなく)あると感じていますが、一方で、(生み出す計画の価値を落とさずに)これを短縮できたら、確実にベロシティが向上します。(開発に使える時間が増えるわけなので)

だから、計画をより素早く終えることが一つの大きな課題となっています。*4

DEV と QA が分かれている

これまでに何度も言及したように、私たちのチームには、DEV と QA という 2 つの役割があります。

QA メンバは、「DEV のタスク」を決して実行しません。(DEV メンバは、稀に「QA のタスク」を実行することがあります)

本物の職能横断型チームを目指して、少しずつ、徐々にであっても、これをならしていく必要があります。

個人的には、飛躍的なベロシティ向上の鍵がここにあるのではと踏んでいます。

おわりに

書かなかったこと

この記事では、書かなかったこと(字数の都合上、書けなかったこと)がいくつかあります。

  • 予め計画するタスクと、計画できない(計画時点では特定できない)追加タスクについて
  • スプリントバックログの運用について
  • ペアプログラミングの活用とその効果について
  • チーム内でのスキルのバラツキについて
  • 稼働時間の算出について
  • そもそも、プロダクトオーナーは 1 週間に収まる PBI をどうやって書くのか

こういったことについては、今後書いていけたらと思います。

反論がないはずがない

「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」について書いてきましたが、「いやいや、その理屈はおかしい」「馬鹿げている」という反論はきっとあるものと思います。

実践する前の私なら、間違いなく反論しています。

その反論の多くは単なる思い込みの可能性が高いと思いますが、中には、たぶん当たっているものもあります。

実際、世の中には向いていない人はいるでしょう。その中にはスーパーエンジニアもいるかもしれません。向いていないプロダクトというのもあるのかもしれません。
しかし、試してみる価値はあります。

このやり方に向いていないスーパーエンジニアを抱えて開発していくほうが、すぐれたプロダクトができるかもしれません。
このやり方に向いていないスーパーエンジニアと(残念ながら)別れ、このやり方に舵を切ったほうが、すぐれたプロダクトができるかもしれません。

どちらの可能性もあります。
プロダクトの性質、市場の性質、規模、メンバの性質、さまざまなものが要因として考えられます。

もちろん、組織内で方法論を併用し、共存していく方法もあるでしょう。
これが一番いいかもしれません。

スクラム実践上のおすすめ

もしこれをやってみようと思ったら、この記事や本だけを読んで試してみるよりは、決して安くはありませんが、Odd-e Japan の認定スクラムマスター研修を受講されることをおすすめします。
スクラムは人の問題を扱っていて、人の問題を文字情報だけから理解するのはなかなか難しいからです。

Jim CoplienJoe Justice といった外タレが来日して行う研修も行われているようですが、個人的には江端さんの研修をおすすめします。

*1:もちろん自動テストは書いていますし、CI も行っていますが、アプリケーションレベルのテストの多くを手動でも行っています

*2:なお、1 時間や 2 時間程度の超過なら、多少の残業を覚悟してコミットすることもなくはないです

*3:ほぼです。まだ、たまに失敗します……

*4:なお、Scrum Guide には、スプリント計画は 1 ヶ月スプリントの場合で最大 8 時間、と書いています。これを演繹すると、1 週間スプリントであれば 2 時間で計画を終えなければならないことになります。よって、私たちは(この点に関しては)スクラムフレームワークにのっとっていないことになるのかもしれません。しかし、「それでもやるべし」と言ってくれた江端さんの言葉を信じて実践し、今のところこの方向は正しいと感じています。もしかしたら遠くない将来、この「2 時間」を意識する日が来るのかもしれません。

「1週間ずつ製品を作る」のが最強である説 ~スプリントを「1週間」でガチでやってみた結果

アプレッソ開発部の土岐です。最近メインDAWをAbleton LiveからPresonus Studio Oneに移行中です(ニッチな話)。

というわけでAppresso Advent Calendarの2日目! ということで今回は「スプリント1週間」について書きます。

qiita.com

はじめに

DataSpider Servistaなどのデータ連携製品を開発する弊社アプレッソ。開発部では最近、スクラム・アジャイルを取り入れた開発にチャレンジしています。

特に今年夏以降は、ガチで「スクラム」というものをやってみようという、ということで現在DataSpiderの次バージョン開発は、完全にプロセスも体制も含めて「スクラム」でやっています。

その中でいろいろな気付きがありました。書きたいことは様々あるのですが、特に「スプリント/イテレーションを1週間でやる!」=「1週間ずつ製品を開発する」という試みは、チームに予想以上の良い衝撃を与えた模様です。

  • 自然なリズムの中で素早く開発できる
  • 問題が早く見つかって解決が速くできる
  • 集中すべきことに集中できて無駄な作業が無くなる
  • 短いサイクルで改善し続けることができる

チームからはこのような声が上がっています。

「イテレーション/スプリントを導入する」ことによるメリットは様々な形で語られていますが、「その期間はどのくらいが最適か?」というのはあまり情報が多くなく、チームにとって悩みどころです。

我々のチームはイテレーション/スプリントを「無し」→「2週間」→「1週間」という3段階で経験して、

スプリント1週間が最強である

ということを深く確信した次第であります。

ということで、今回の記事では、この「1週間スプリント」にフォーカスして書こうと思います!

(※) このタイムボックスを一般的なアジャイル開発では「イテレーション」、スクラムでは「スプリント」と呼びます。2週間で行っているときはスクラムではなかったので本当は「スプリント」では無いのですが、混在している分かりにくいので以下は便宜上このタイムボックスを「スプリント」と統一します。

スクラムを「1週間スプリント」をガチでやり始めた経緯

ということで、まず「1週間スプリント」に至った経緯について簡単に書こうと思います。

もともと開発部では、開発フェーズ・テストフェーズが完全に分かれていました。各個人が基本的に自分の裁量で仕様策定・開発を行い、開発フェーズが終わったらテストフェーズに入りテストを行うという形です。

f:id:tokita93:20161201165659p:plain ▲従来の開発イメージ図。開発フェーズ・テストフェーズが完全に分割されている

厳格なウォーターフォールほどフェーズが分割されているわけではありませんが、開発フェーズ・テストフェーズは完全に分かれていて「緩やかなウォーターフォール」といった趣でした。

これ自体はさまざまな経緯があってこの形になったんですが、製品規模が拡大するについてこのやり方での問題が明らかになり、「アジャイル開発」を模索し始めることに。この辺りの経緯は以前本ブログに書いたりしました。

appresso.hatenablog.com

で! 導入したのが「スプリントを2週間でやる」というもの。「必ずスプリントが終わったときにテストが完了したリリース可能な製品を作ること」というルールで、開発とテストが協働して製品を開発する「タイムボックス」での開発がスタートしました。

f:id:tokita93:20161201170736p:plain ▲スクラム導入後。QAと開発は同じチームとして協働で作業をし、スプリント中にリリース可能なプロダクトを作る

このタイムボックス内での開発は、これまでと異なり「チーム」として短期的にリリース可能な製品を作り上げていくということで、さまざまなメリットがありました。 例えば、

  • チームの生産性(ベロシティ)が判明するので、リリース時期までに対応可能な範囲(スコープ)が予測しやすくなる
  • 開発してすぐにテストされるため、早期に問題が発生されて修正が早くなる
  • リリース可能な製品が常にあるため、動きを見せてフィードバックを得る機会が早くなり製品に取り組める

などが挙げられます。

で! さらに「もっと良いやり方は無いか?」と模索する中で、自分がScrum Alliance認定スクラムマスター研修を受講。「スクラム」について刺激的に学ぶ中で、強烈だったのが講師の江端一将氏のこの言葉。

スプリントは「1週間」です! ルール上は1~4週間ですが、私は「1週間」以外無い、と思っています。 世界の生産性の高いチームは「1週間」でやっています。貴方のチームがそういうチームと闘いたいのならば、「1週間」を導入すべきです。

本来はプロジェクト中にスプリントの期間を変更することは厳禁なのですが、どうしても「スクラムをやりたい! しかも1週間スプリントで!」ということでスクラム開発を開始したのが2016年9月。それから3ヶ月だったのが現在、というわけです。

www.instagram.com ▲壁に貼られたスクラム概要。この1週間のループの中でさまざまなセレモニー(MTG)をしながら1週間を駆け抜ける

江端氏はこうも言っていました。

このやり方でとりあえず3ヶ月やってみてください。そうするとその良さが実感できますよ。

ということで、3ヶ月経過した現在。どうなったかと言うと・・・。

良いリズムができて「製品(プロダクト)と踊(ダンス)っちまったんだよ・・・」

↑という見出しは個人的に書きたかっただけだったりしますが(元ネタ)、実際にやってみた結果、一番大きなメリットとして痛感するのが

「良いリズムが出来る!」

ということです。

メンバーからもその感想は多く出て、それはスクラムマスターとしてやっている自分も凄く実感します。

もともと「2週間」でスプリントをやっていたときもある程度リズムは出来ていてそのメリットは理解できていたのですが、「1週間」でやってみるとさらにそのリズムが身体に馴染むような気がしています。

具体的に1週間のメリットとして、「常に良い緊張感を持って開発できる」「しっかりと計画して取り組める」「タスクの優先順位が把握しやすい」ということが上げられると思います。実際に2週間と1週間のイテレーションを比較すると。以下のような感じです。

項目 2週間 1週間
緊張感 終了までの期間が長いので1週目はゆるい。2週目に入って徐々に緊張感が出る 常に終了までの時間が見通せるので、緊張感を持って取り組める
計画性 2週間でやれることなどで「できそう」というイメージで粗めの計画を行う。結果、予想外のタスク増加が多く成果が予想よりもぶれやすい 1週間で出来ることを0.5時間~1時間単位に分割して「できる!」となるまで細かく計画する。そのため予想よりもぶれにくくなる
優先順位 営業日の「10日」の中で、今日どのタスクを消化すれば良いのか把握しにくい 営業日が「5日」しかないので(実際は計画の日を除くとほぼ4日)、今日やるべきタスクがより明確になる

f:id:tokita93:20161201172615p:plain ▲2週間スプリントと1週間スプリントの違いのイメージ図。1週間だと終了までの見通しがはっきりしているため、緊張感を常に保ちつつ優先度を明確にしてタスクに取り組める

 なぜ「1週間」だとより良いリズムが出来やすいのか?

なぜ「2週間」と「1週間」でこのような感覚の違いが出るのか? あくまで自分の考察なのですが、大きく以下の3つの理由ではないかと思っています。

  1. そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる
  2. ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい
  3. 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい

それぞれについて以下に説明します。

  1. そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる

我々現代人は、小さい頃から「1週間単位」で生活を行っています。そして物事を考えるときもこの単位を基本セットとして考えていると思います。 今日が金曜日だとして、

「先週の金曜日」何やりましたか?

と聞かれると、だいたい思い出せると思いますが、

「先々週の金曜日」何やりましたか?

と聞かれるとどうでしょう。より昔なので曖昧になるのは当たり前とはいえ、その期間以上に数十倍記憶が曖昧になると思います。

逆に未来で言うと、

「来週の金曜日」に何をやりますか?

「再来週の金曜日」に何をやりますか?

というのは、来週の方が数十倍イメージしやすいと思います。この生活の単位と「製品を作る」という単位を一致させることで、「このスプリント中での働き方」というのがものすごく具体的なイメージで作ることができるのではないか、と思います。

  1. ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい

「人間のワーキングメモリに保持できる情報は7±2個」ということが認知心理学の研究で実証されています。

ワーキングメモリ - Wikipedia

この「7±2」というマジカルナンバーは、スクラムでは「チームの基本人数のルール」として使われたりしています。

「2週間」は営業日数「10日」になりますが、この日数はこのワーキングメモリから溢れています。そのため、それぞれの日でどのような動きをするか、というのを脳内でイメージするのは人間の認知能力の限界を超えていることになります。「1週間」の「5日間」はワーキングメモリ内で収まる日数であり、この「5日間」をどのように働いていくか、というイメージが脳内でしやすい、ということがあるのでは、と思います。

  1. 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい

何のこっちゃ、って感じだと思いますが、このリズムは重要です!

我々は「水曜スプリントスタート、火曜スプリント終了」というようにスプリントを組んでます。 これに従ってスプリントをこなすと、スプリント以下のような流れになります。

計画 実行 実行 休み 休み 実行 実行・レビュー&振り返り

1日を計画の日とし、2日実行して週末休み、そして残りの2日を頑張って終了、というサイクルになります。ちょうど実行の半分のところで休みがあるので、一旦休んだ後に残りを頑張ろう、という気になります。

また、月曜の朝がちょうど半分のところになるので、この日の朝会(我々のチームは9:45からやっています。スクラムでは「デイリー・スクラム」と呼びます)は「作戦会議」と位置づけています。ここでは、

  • このスプリントはこのまま進んで完了できるか?
  • 今の作業を止めて注力すべきタスクは無いか?
  • 優先度の高いアイテムに注力すべきなのではないか?

などを検討します。これは週末にリフレッシュして頭をスッキリさせた後で話すのにちょうど良いタイミングで、休み明けに頭を起動させていくのと共に非常に良い機会になっています。

この流れはとてもスプリントのリズムに良い影響を与えているように思います。

ちなみに唐突ですが、上記のサイクルを太鼓にしてみましょう。

f:id:tokita93:20161201172950j:plain

ドン・ドン・ドン・<休>・ドン・ドドン

こ、これは・・・我々はよく似たリズムを知っている・・・・!

ドン・ドン・ドン・<休>・ドドン・ドドン

日本古来に伝わる音頭のリズムだ! このリズムがつまり、製品(プロダクト)を踊(ダンス)させちまうのでは・・・

なんてことは無いと思います。

こういう思い付きで胡散臭いことを言う人に惑わされないように注意していきたいですね。

改善の機会が倍増し、改善アクションが試行錯誤できる!

話を戻します! 他のメリットとして、「ふりかえり・改善が素早くできる!」ということがあります。

2週間スプリント期でも「ふりかえり」という形でKPTを行い、スプリントを振り返って改善を繰り返していました。これも「1週間スプリント」により効果的な改善ができるようになった感じます。

その理由として、まず「ふりかえりの機会が2倍になった」ということが大きくあります。1週間動いてみてはふりかえることで、短い単位で軌道修正してプロジェクトを進めることができます。

また、先ほどの考察にもあったように「ふりかえるときに記憶が鮮明」ということも大きなメリットです。「2週間前にあったこと」は既に記憶が薄れかけているのですが、「1週間前」だと鮮明です(実際やってみると「1週間前」であっても忘れていたりということがよく起きる!)。この記憶が鮮明な状態でふりかえることで、より良いアクションを導くことができるように思います。

スクラムを実施するにあたってふりかえりの形式を変えたことも、良い影響を及ぼしているように思います。スクラムにおける「ふりかえり」は「スプリント・レトロスペクティブ」という名前でのMTGになるのですが、これのルールとして「次スプリントで生産性を改善するための具体的なアクションを1つ以上必ず決める」ということがあります。

www.instagram.com

▲スプリント・レトロスペクティブで次のスプリントで取るアクションについて検討中

このアクションは多少大胆であっても「とりあえず1週間改善案を試してみようぜ!」という感じで臆することなく気軽にアクションを試すことができます。2週間だと失敗したときの影響が大きいのですが、1週間だったら「試してみてダメだったらやめよう!」という感じで気軽に人体実験感覚で試すことができます。このアクションの取りやすさも「1週間」だからこそ、と感じます。

「1週間で製品を作る」ためにやったこと

ということでいろいろメリットはあるんですが、実際のところ「1週間」というのはその決定的な「短さ」故の大変さがあります。事実、我々のスクラムチームでやろうとしたときも「本当に可能なのか?」という疑問も当初はありました。

認定スクラムマスター研修で江端さんが研修の最初に強調していたことがあります。

スクラムをやることによって「生産性を4倍にする」などと謳う本もありますが、絶対にそんなことはありません。 もし生産性が4倍になるとしたら、チームが頑張ることによってのみ可能です。スクラムはそれを支援するフレームワークです。

ということで、我々のチームもこの短いスパンで製品を作り上げるため、プロダクトオーナー・スクラムマスター・チームのそれぞれが知恵を工夫を持ち寄って頑張っています。

具体的には、我々のスクラムチームでは以下のようなことを行って1週間のスプリントを行っています。

  • プロダクトオーナーはプロダクトバックログのアイテムをできるだけ小さくしスプリントに収まるようにする。また受け入れ条件を明確にしてスプリント中の相談コストを低減させる
  • チームはスプリントプランニングでタスクを1時間か30分まで細分化し、計画をより正確にする
  • チームは開発・テストの流れをできるだけスムーズにするようにアイテムをテスト可能な単位にさらに分割して(「チェックポイント」と呼んでいます)、テスト開始までの時間を最低限にする
  • スクラムマスターはCIによるビルド自動化やSlack通知などのシステムをメンテし、フローの無駄を省く。またスプリントのデータを可能な限り収集・見える化し、改善のきっかけを探す

などさまざまな方策を行っています。 (上記の1つ1つの項目はいろいろ掘り下げがいのあるテーマなので、別途取り上げたいと思います)

www.instagram.com

▲スプリントプランニング中の1コマ。ストーリーのタスク分解を徹底的にやっています。

これらのことをやり遂げて1週間のスプリントをこなす我々のチームを私は誇りに思います。と同時にまだまだ満足はできません。プロダクトオーナー・チームとスクラムマスターで協力しあい「スクラム」を組んで、さらに向上を目指したいと考える所存です。

で、結局スプリントの期間は何週間が良いの?

いろいろ書いてきましたが、しかしこれは我々のチームの話。結局のところそのチームでの「最強」の方法はそのチームで探すしかないわけであります。

その探索の一助としてスプリント期間を決めることについて参考になる書籍があるので紹介します。『スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-』です。

https://www.amazon.co.jp/dp/B01D4JHITO/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

この第6章に「スプリントの長さを決める」というズバリな章があります。

どんなチームにもピッタリ合う魔法のようなスプリントの長さはない。

という言葉から始まるこの章では、具体的なスプリントの長さの検討例から始まって、長さを決定する際に考慮する要素について解説しているのでとても役に立ちます。

特に最後の章では「スプリントの長さ決めクイズ」として、以下のような質問をしています。

プロジェクトの期間は?

顧客やステークスホルダーはフィードバックやアドバイスをどの程度できるか?

スクラムチームの技術的なスキルはどれくらいか?

これらの答えによって、最適な長さが点数で分かる一覧表があります。悩んでる方は試してみると参考になると思います。(ただし著者も「賢く使うこと」と注釈を付けている通り、これも絶対ではありません。

また、第12章「ストーリーやタスクを分割する」は「なぜスプリントは短い方が良いのか?」ということを分かりやすく説明しています。

この中の具体例で、「4週間のスプリント」でストーリーを完了させることができないスクラムチームが出てきます。「スプリントを5週間にすれば終わるんだけど、そうすべきか?」と悩むスクラムマスターに対して、XP(Extream Programming」の提唱者の一人でもあるロン・ジェフリーズはこうアドバイスします。

「スプリントを短くした方がいいよ」ロンは素っ気なく言った。 チーム一堂ぽかんとなったのに、ロンも気づいたと思う。

「聞き間違えか」と戸惑うチームにロンは、「なぜ短い方がいいのか」を具体的に説明します。その結果

「1週間だ。私を信じろ」

と1週間のスプリントへのチャレンジを促します。この辺の理由の詳細は面白く、かつ納得がいく話なのでぜひ本著で読んでみてください。「やっぱり一週間スプリントが最強だ!」と合点いくと思います。その他、ストーリーの分割方法や分割の指標についても参考になる情報が書いています。

終わりに

ということで「スプリント1週間」についていろいろと書いてきました。この「1週間スプリント」をやり始めてチームから

楽しい!

という声が上がることが多く、それが「最強」である最大の理由だなぁと思うところです。

恐らくアジャイル・スクラム開発に取り組んでるチームはこの「スプリントの長さ」についてはいろいろ意見を持っていると思います。我々のチームでの経験から考察してきましたが、ぜひ機会あればご意見をぶつけさせていただければと思います。

実は今回はテーマがぶれてしまうので詳細は書かなかったのですが、「スプリント計画時、タスクを30分~1時間まで徹底的に分解して見積りを行う」ということはこの「1週間スプリント」を構成する最重要要素だったりします。このスプリント計画(スプリント・プランニング)については、「チーム」の立場から開発部の野口が明日のAdvent Calendarで書いてくれるはず・・・! ですので、バトンを渡してこの記事を終わります。

楽しくより良い製品を素早く作っていきましょう!

アジャイル開発になったらQA担当者はどうなるの? 〜「実践アジャイルテスト」で学んだこと〜 その6

こんにちは、品質マネジメント部の磯です!

書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその6になります。

www.shoeisha.co.jp

前回は「第18章 コーディングとテスト」のうち、バグの取り扱いについて書きました。

appresso.hatenablog.com

今回のエントリですが、予定を変更して「第18章 コーディングとテスト」のうち、リグレッションテストについて学んだことを出力していきます!

リグレッションテスト

(P429 18.9 「リグレッションテスト」より)

ビルドを「緑」に保つ

プログラマはコードをチェックインする前にxUnit系の単体テストツールで「緑」の状態、つまりはテストが全て成功している状態にしておく必要がありますが、開発が進むにつれ何らかの要因で成功しない場合があります。 たとえば、ローカル環境では通っていたが、CIで毎ビルドする際には失敗してしまう・・・といったことです。こういった事態が発生した場合は、最も優先度をあげてビルドが成功するよう、修正することが必要です。

ビルドの失敗や、いま直している!というステータスを示すのに以下のような方法が例示されています。

  • ビルドのあとに結果をメール通知する
  • ぬいぐるみをビルドを壊した人の机においておく
  • 失敗時に信号を点灯させる
  • アンビエントオーブを使う
  • GUIのビルド監視ツールを使う

私たちの現場ではJenkinsで状態がわかるようになっているので、そこからSlackでお知らせといった感じになっています。お知らせは人力なので自動化の余地ありだなと思いました。 それにしてもアンビエントオーブとは何だろうと思ったのですが、↓こういうのがあるみたいですね。

ambient orb - Google 検索

The Orbならわかるのですが・・・q(^^)p

ビルドを早くする

ビルドに対してはなるべく早くフィードバックしたいものですが、ビルドの時間が長すぎるとテスト実施までの時間も伸び伸びになってしまいます。 XPのガイドラインでは10分以内にビルドが完了するのが望ましいとされています。長時間かかってしまう場合はまずそこを目指しましょう。 著者は以下の方法を例としてあげています。

  • データベースのアップデートを含むテストをはずす
  • 単体レベルでの機能テストをはずす
  • GUIのテストスクリプトをはずす

といったものです。これらは実施しなくて良いのではなく、別プロセスで行われるのが良しとされています。

リグレッション環境を作る

既存のリグレッションテストを自動化したり、新規に自動化されたリグレッションテストを追加するなどした際は、プロダクションコードと同じリポジトリでバージョン管理されるべきです。 また、追加するリグレッションテストは素早くフィードバックできるように選定する必要があります。

上記のように追加したリグレッションテストは開発を推進するものでなく、新しいバグを見つけるためでもありません。これらを実施する目的は予期せぬ変化やシステムの副作用を見つけるためです。

大きな視野を持つ

前述のように追加したリグレッションテストですが、これらを過信してしまうことも望ましくないとしています。場合によっては手動による探索的テストが適切であるという可能性も考慮して、視野を大きくもっておくのが良いでしょう。

まとめ

さて、今回のアウトプットは以上となります。

  • 効果的なフィードバックをするために、適切なリグレッションテストを頻繁に実行できるよう、ビルドプロセスに組み込んでいく

といったところでしょうか。

次回予告

次回は引き続き「第18章 コーディングとテスト」の反復指標について学んだことをアウトプットしたいと思います。

ではまた!

APIStudy#2 開催報告

こんにちは!アプレッソ技術部對馬です。

タイトルの通り、APIStudy#2の開催がありましたので、その報告です。

APIStudyは、APIについて語って語ってベストプラクティスを突き詰めるという内容のワークショップです。

第1回の様子はこちらの記事にてレポートされていますのでご覧ください。

appresso.hatenablog.com

さて本題です!去る11月15日に無事第2回が開催されました!

第2回はゲストであるコイニー株式会社さんのオフィスをお借りしました。

ありがとうございます。 f:id:ytsushima:20161118174142p:plain

そしてなんと、今回はコイニーさんからピッツァの差し入れがありました!!

重ね重ねありがとうございます!!! f:id:ytsushima:20161118174259j:plain

第1部:コイニーさん事例紹介

まず第1部では、コイニーさんのCoineyペイジAPIの開発秘話をお話しいただきました。 f:id:ytsushima:20161118174452j:plain

参加者の皆さんには、美味しいピッツァを食べながら聞いていただく予定だったのですが、素晴らしいことに皆さん非常に熱心で、ピッツァも早々にメモをとる手が止まらない様子でした。

それだけコイニーさんのセッションが興味深く、参考になる内容だったということですね。

確かに、これでもかというくらい、API開発についてかなり詳細までご紹介いただけました。 f:id:ytsushima:20161118174702j:plain

第2部:ディスカッションタイム!

そして第2部では、コイニーさんのセッション内容に対する質問をもとに、「参加者の皆さんが興味を持っていること」をいくつか挙げ、それについてのディスカッションを行いました。

f:id:ytsushima:20161118175009j:plain

ディスカッションテーマは以下の3つです。

  • 認証について
  • バージョンアップに伴うサポート対象外の基準
  • 負荷対策やチェック基準

それぞれ話し合いたい内容ごとに集まって、時間の許す限り語り合っていただきました。 f:id:ytsushima:20161118175226j:plain

最後はチームで話した内容を全体に共有します。

認証チーム

f:id:ytsushima:20161118180345j:plain

内容「認証は難しいのでAWSに任せよう」

ここのチームは1番集まった人数が多かったです。

皆さん「認証」についてはやはり気になる部分なのですね。

弊社の脇野(APIStudy企画者)も気になっていたらしく、なぜか話し合いに割り込んで質問していました。 f:id:ytsushima:20161118180421j:plain ▲割り込みの図

サポートバージョン基準

f:id:ytsushima:20161118175303j:plain

内容「男前API(外資系)を見習いたい、が、勇気が足りない」

強気でいくのも大事ですが、バランスが重要ですね。

負荷対策

f:id:ytsushima:20161118175417j:plain

内容「負荷テストで高額かかる罠」

ご利用は計画的に…。

最後に

f:id:ytsushima:20161118175531j:plain APIStudy#2も無事に終わることができました!

参加していただいた皆様、サポートしていただいた皆様、そして登壇・会場提供をしていただきましたコイニー様、この場を借りて感謝申し上げます。 ありがとうございました!!

そして!!!

当日も発表がありましたが、なんと!すでに第3回の開催が決定しています!

apistudy.connpass.com

もっとAPIについて語りたい!というあなたも!まだ参加したことないというあなたも! 是非上記URLから申し込んでください!

これからもAPIStudyをよろしくお願いします。

特大ペッパソン2016の振り返り

こんにちは、アプレッソ営業部の脇野です!

昨年に引き続き今年も特大ペッパソンへDataSpiderを提供させていただきました。 参加者は80名超え、API提供ベンダーが12社、総勢100名以上が集まり、さらにPepperが40台近くいるので言ってみれば150名が集うハッカソンというわけです。本当にすごかったです。

f:id:hiroyoshi_wakino:20161113155454j:plain ※写真は総勢40台が集まるダークな感じのPepperくん!圧巻ですね。

さて、ハッカソンに参加されるみなさまはどんなものをどうやって実現しようかと悩みながらハッカソンへ参加されていらっしゃると思うのですが、私たちAPI提供側もどうやって多くのみなさんにプロダクト/サービスを知り触っていただけるのだろうと色々と考えながらハッカソンに挑んでいます。

そこで今回はそんな取り組みを、開発現場を改善する方法としてよく採用されているふりかえりのフレームワーク「KPT」に習って考えてみたいと思います。

とその前に。。。

まずはペッパソンの結果を。

最優秀賞

最優秀賞は六元素チームの『手話通訳ボランティア by Pepper』 手話の動作をPepperで写真に撮り、解析して通訳してくれるという発想。とても衝撃的でした。 f:id:hiroyoshi_wakino:20161113161117j:plain

DataSpider賞

アプレッソからはDataSpider賞をチーム『嫁は何人いても…やっぱ困る。』の『Second Wife 』に贈らせていただきました。 名古屋ハッカソンに引き続き今回もご活用いただき本当にありがとうございました! f:id:hiroyoshi_wakino:20161113161027j:plain

※詳しい内容はMashupAwardsのレポートをご覧いただければと思います。

ではKPTに移ります。

K=Keep(よかったこと)


  • 事前にサンプルスクリプトと手順書を用意することができた
  • 普段利用していなかった機能を提供することができた

サンプルスクリプトの提供

提供するDataSpiderの中にJSON変換スクリプトを作成しておきました。 ハッカソンでは各種APIとのやり取りにJSONフォーマットでデータをやり取りをすることが多くあるのでその変換方法を、それとすぐに動かせるようにHTTPトリガーの設定です。 これで環境を提供した直後に動作を試すことが可能な環境になっています。

手順書(Qiita)の作成

上記サンプルスクリプトの利用手順と、Pepperとの連携における概要をまとめ記事を作成しました。

P=Problem(悪かったこと)


  • ハッカソン開催前に触れてもらえる環境、資料を用意することができなかった -開催中に ハンズオンの実施を考えたが触ってもらう環境の用意ができていなかった

まずは知ってもらうところから

個別に勉強会を開催されているベンダーさんのAPIはやはり利用頻度が高いです。 限られた時間の中で開発をしなければいけないので、機能の細かい所ではなく、全体を通じで何が実現できて、こうすれば動くというのを理解いただかなければ最後まで使っていただくことはできません。

APIの説明ですべてを伝えることができればよいのですが、言葉だけでは実装感まで伝えることはできない、なので一度は触ってもらう必要があります。そこで個別にハンズオンの時間もいただいたのですが、ハンズオン環境を用意する前にみなさんに集まっていただいたため、実際には個別の機能紹介だけになってしまいました。完全にハンズオンの準備不足でした。

T=Try(次に試すこと)


  • 事前勉強会
  • ハンズオン
  • 手順書の印刷

事前勉強会

ハッカソン参加者向けに限定するわけではないですが、ハッカソンでよく利用してもらっている機能は一般的な用途でもきっと利用できることだと思うので、ハッカソンで得られたエッセンスを取り入れた勉強会や記事を定期的にアップしていこうと思います。

今回のペッパソンで得られたエッセンスで記事に起こしておきたいのはこれ。

ハンズオン

個別チーム用インスタンスとは別にハンズオン専用のインスタンスを用意しようと思います。

DataSpiderはリポジトリDBを利用することで同一環境に複数の異なるユーザでログインすることができるので、事前に複数名分のユーザを作成することで、ハンズオン参加者にすぐ環境を提供することができるようになります。

あとは設定情報とハンズオンの手順を印刷しておこうと思います。 もちろん手順はWeb上にも掲載されているのですが検索する手間、ネット環境(ハッカソンでは大量のユーザがネットに同時に接続するのでなかなかつながらないことがあります)を考えると紙がやはり確実で早い、ということがあります。

さいごに


今回のハッカソン、正直なところなかなか利用していただくことができない厳しいものだったのですが、それ以外でいくつもの良い経験を得られました。

  • まず一つ目、「これはDataSpiderさんならできるかもしれない」と言ってAPI提供ベンダーさんが相談しにきてくださる、そして様々な実現方法を一緒になって検討しはじめる。これは自分たちのAPIが利用されるされないは関係なく、実現したいことを最短でできる方法はなんだろうと一緒に作っている瞬間で、こうした経験ができるハッカソンは楽しいのひとこと。

  • 二つ目、「DataSpiderは連携処理を行うソフトウェアである」という固定概念を忘れて「DataSpiderというソフトウェアのアーキテクチャ」を考えてみれば実現可能だよね?という気付きがあったこと。柔軟に物事を捉える大切さを学びました。

  • そして最後に、今回アプレッソメンバーの都合がなかなかつかず、支援スタッフのアサインにとても困っていました。そんなとき、前職のメディアフォースのみんながスタッフとして力になってくれたこと。これは本当に心強く、ありがたかったです。会社が変わってもこうして一緒にチームとして参加できたことはとても幸せでした。

次回のハッカソンでも新たな発見を求めて、そしてこの経験をより良いDataSpiderのために活かしていきたいと思います! f:id:hiroyoshi_wakino:20161114121226p:plain