APIStudy#2 開催報告
こんにちは！アプレッソ技術部對馬です。
タイトルの通り、APIStudy#2の開催がありましたので、その報告です。
APIStudyは、APIについて語って語ってベストプラクティスを突き詰めるという内容のワークショップです。
第1回の様子はこちらの記事にてレポートされていますのでご覧ください。
さて本題です！去る11月15日に無事第2回が開催されました！
第2回はゲストであるコイニー株式会社さんのオフィスをお借りしました。
ありがとうございます。
そしてなんと、今回はコイニーさんからピッツァの差し入れがありました！！
重ね重ねありがとうございます！！！
第1部：コイニーさん事例紹介
まず第1部では、コイニーさんのCoineyペイジAPIの開発秘話をお話しいただきました。
参加者の皆さんには、美味しいピッツァを食べながら聞いていただく予定だったのですが、素晴らしいことに皆さん非常に熱心で、ピッツァも早々にメモをとる手が止まらない様子でした。
それだけコイニーさんのセッションが興味深く、参考になる内容だったということですね。
確かに、これでもかというくらい、API開発についてかなり詳細までご紹介いただけました。
第2部：ディスカッションタイム！
そして第2部では、コイニーさんのセッション内容に対する質問をもとに、「参加者の皆さんが興味を持っていること」をいくつか挙げ、それについてのディスカッションを行いました。
ディスカッションテーマは以下の3つです。
- 認証について
- バージョンアップに伴うサポート対象外の基準
- 負荷対策やチェック基準
それぞれ話し合いたい内容ごとに集まって、時間の許す限り語り合っていただきました。
最後はチームで話した内容を全体に共有します。
認証チーム
内容「認証は難しいのでAWSに任せよう」
ここのチームは1番集まった人数が多かったです。
皆さん「認証」についてはやはり気になる部分なのですね。
弊社の脇野(APIStudy企画者)も気になっていたらしく、なぜか話し合いに割り込んで質問していました。
▲割り込みの図
サポートバージョン基準
内容「男前API(外資系)を見習いたい、が、勇気が足りない」
強気でいくのも大事ですが、バランスが重要ですね。
負荷対策
内容「負荷テストで高額かかる罠」
ご利用は計画的に…。
最後に
APIStudy#2も無事に終わることができました！
参加していただいた皆様、サポートしていただいた皆様、そして登壇・会場提供をしていただきましたコイニー様、この場を借りて感謝申し上げます。 ありがとうございました！！
そして！！！
当日も発表がありましたが、なんと！すでに第3回の開催が決定しています！
もっとAPIについて語りたい！というあなたも！まだ参加したことないというあなたも！ 是非上記URLから申し込んでください！
これからもAPIStudyをよろしくお願いします。
特大ペッパソン2016の振り返り
こんにちは、アプレッソ営業部の脇野です！
昨年に引き続き今年も特大ペッパソンへDataSpiderを提供させていただきました。 参加者は80名超え、API提供ベンダーが12社、総勢100名以上が集まり、さらにPepperが40台近くいるので言ってみれば150名が集うハッカソンというわけです。本当にすごかったです。
※写真は総勢40台が集まるダークな感じのPepperくん！圧巻ですね。
さて、ハッカソンに参加されるみなさまはどんなものをどうやって実現しようかと悩みながらハッカソンへ参加されていらっしゃると思うのですが、私たちAPI提供側もどうやって多くのみなさんにプロダクト/サービスを知り触っていただけるのだろうと色々と考えながらハッカソンに挑んでいます。
そこで今回はそんな取り組みを、開発現場を改善する方法としてよく採用されているふりかえりのフレームワーク「KPT」に習って考えてみたいと思います。
とその前に。。。
まずはペッパソンの結果を。
最優秀賞
最優秀賞は六元素チームの『手話通訳ボランティア by Pepper』
手話の動作をPepperで写真に撮り、解析して通訳してくれるという発想。とても衝撃的でした。
DataSpider賞
アプレッソからはDataSpider賞をチーム『嫁は何人いても…やっぱ困る。』の『Second Wife 』に贈らせていただきました。
名古屋ハッカソンに引き続き今回もご活用いただき本当にありがとうございました！
※詳しい内容はMashupAwardsのレポートをご覧いただければと思います。
ではKPTに移ります。
K=Keep（よかったこと）
- 事前にサンプルスクリプトと手順書を用意することができた
- 普段利用していなかった機能を提供することができた
サンプルスクリプトの提供
提供するDataSpiderの中にJSON変換スクリプトを作成しておきました。 ハッカソンでは各種APIとのやり取りにJSONフォーマットでデータをやり取りをすることが多くあるのでその変換方法を、それとすぐに動かせるようにHTTPトリガーの設定です。 これで環境を提供した直後に動作を試すことが可能な環境になっています。
手順書（Qiita）の作成
上記サンプルスクリプトの利用手順と、Pepperとの連携における概要をまとめ記事を作成しました。
P=Problem（悪かったこと）
- ハッカソン開催前に触れてもらえる環境、資料を用意することができなかった -開催中に ハンズオンの実施を考えたが触ってもらう環境の用意ができていなかった
まずは知ってもらうところから
個別に勉強会を開催されているベンダーさんのAPIはやはり利用頻度が高いです。 限られた時間の中で開発をしなければいけないので、機能の細かい所ではなく、全体を通じで何が実現できて、こうすれば動くというのを理解いただかなければ最後まで使っていただくことはできません。
APIの説明ですべてを伝えることができればよいのですが、言葉だけでは実装感まで伝えることはできない、なので一度は触ってもらう必要があります。そこで個別にハンズオンの時間もいただいたのですが、ハンズオン環境を用意する前にみなさんに集まっていただいたため、実際には個別の機能紹介だけになってしまいました。完全にハンズオンの準備不足でした。
T=Try（次に試すこと）
- 事前勉強会
- ハンズオン
- 手順書の印刷
事前勉強会
ハッカソン参加者向けに限定するわけではないですが、ハッカソンでよく利用してもらっている機能は一般的な用途でもきっと利用できることだと思うので、ハッカソンで得られたエッセンスを取り入れた勉強会や記事を定期的にアップしていこうと思います。
今回のペッパソンで得られたエッセンスで記事に起こしておきたいのはこれ。
- DataSpiderサーバをテンポラリとして利用する方法
- 中間テーブルを利用する方法
ハンズオン
個別チーム用インスタンスとは別にハンズオン専用のインスタンスを用意しようと思います。
DataSpiderはリポジトリDBを利用することで同一環境に複数の異なるユーザでログインすることができるので、事前に複数名分のユーザを作成することで、ハンズオン参加者にすぐ環境を提供することができるようになります。
あとは設定情報とハンズオンの手順を印刷しておこうと思います。 もちろん手順はWeb上にも掲載されているのですが検索する手間、ネット環境（ハッカソンでは大量のユーザがネットに同時に接続するのでなかなかつながらないことがあります）を考えると紙がやはり確実で早い、ということがあります。
さいごに
今回のハッカソン、正直なところなかなか利用していただくことができない厳しいものだったのですが、それ以外でいくつもの良い経験を得られました。
まず一つ目、「これはDataSpiderさんならできるかもしれない」と言ってAPI提供ベンダーさんが相談しにきてくださる、そして様々な実現方法を一緒になって検討しはじめる。これは自分たちのAPIが利用されるされないは関係なく、実現したいことを最短でできる方法はなんだろうと一緒に作っている瞬間で、こうした経験ができるハッカソンは楽しいのひとこと。
二つ目、「DataSpiderは連携処理を行うソフトウェアである」という固定概念を忘れて「DataSpiderというソフトウェアのアーキテクチャ」を考えてみれば実現可能だよね？という気付きがあったこと。柔軟に物事を捉える大切さを学びました。
そして最後に、今回アプレッソメンバーの都合がなかなかつかず、支援スタッフのアサインにとても困っていました。そんなとき、前職のメディアフォースのみんながスタッフとして力になってくれたこと。これは本当に心強く、ありがたかったです。会社が変わってもこうして一緒にチームとして参加できたことはとても幸せでした。
次回のハッカソンでも新たな発見を求めて、そしてこの経験をより良いDataSpiderのために活かしていきたいと思います！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その5
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその5になります。
前回は「アジャイルテストの自動化戦略」について書きました。
今回は「コーディングとテスト」のうち、バグの取り扱いについて学んだことを出力していきます！
まえおき！
従来型の開発スタイルであれば、我々QA担当者は発見した全てのバグをもりもりとバグトランキングシステム(BTS)などに登録するのが一般的なアクションかと思います。しかし、あとあと見返してみれば何年も前の課題が未だに対応されず残っている・・・。なんてことはありませんでしょうか。
未対応のまま残されている課題はそのまま管理し続けるのに値する何かがあるのでしょうか。もちろん中には残しておくことに意味があるものもあるでしょう。 しかし、それなりの数の課題が経緯もわからず残っているだけだったりしないでしょうか。
アジャイルなアプローチにおいてはBTSに登録しないという方法もあります。これは選択肢が増えた、ということを意味します。たとえば実装担当者に発見したバグを口頭で伝え、付箋でタスクを管理し、対応が完了すればそれで終了。という方法もとることができます。ときにQA担当者は発見した課題をBTSに登録するまでが仕事であると思いがちです。QAはQuality assurance = 品質保証の略であり、それが達成されることが最も重要なミッションです。
なにが対応するべきバグなのか
（P414 18.6 「バグに対処する」より）
さて、上記ミッションを達成する上で、対応すべきバグとは何でしょうか。意図しないエラーを修正するなどはもちろんですが、顧客とのやりとりから生まれた課題を取りこんでいく必要もあります。顧客が優先順位と価値を決めます。それを満たすのに必要なものは全て実行していく必要があります。（もちろん優先順位が変わればスコープからこぼれ落ちる機能もあることでしょう・・・）
また、技術的負債についてもバグの一種と考えることができます。これらが残ることによって潜在的なバグが残ってしまったり、柔軟性やチームのモラルに負の影響を及ぼすこともあるかもしれません。
バグの管理
（P417 18.7 「選択のすべて」より）
では、これは対応すべきバグだ！とした事象はどのように管理していくべきでしょうか。 これは前述のとおり多くの選択肢があります。たとえば・・・
- 発生したバグを付箋に書き、タスクボードに貼り付ける
- 機能と同様にひとつのストーリーとしてスケジューリングする
- BTSにバグとして登録していく
チームの練度が高ければ、単純にひとつのタスクとして対応していくというのも良いでしょう。はたまた遠隔地のエンジニアとリモートで共同作業している場合では、BTSに登録して共有していく必要があります。そのときそのとき、環境によって最適な対応を検討していくいきます。
しかし、もし可能であるならばバグのレポートは作成しないことを推奨されます。プログラマが正しい方向に変えられないときだけ、レポートを作成するのです。
どのバグを記録するのか決める
とはいえ、レポートの作成が必要なのか否かについてはそうそう決められません・・・。そこで著者は以下のような例を提示しています。
- 単体テストのエラー（ここではCIにて繰り返し実行されているテストを指している）
- 記録すべきではない。冗長で時間の無駄となる
- 概要レベルの反復テストのエラー
- 失敗したテストがレポートと同等のものと捉えられる
- ただし効果的な修正により多くの情報が役に立つ場合もあるため、レポートを作成する場合もある
- 現在の反復でのストーリーのバグ
- プログラマと協議し、すぐに修正できるものであれば記録しない
- 反復の後のバグ（あるいは、すぐに修正できないバグ）
- 記録する
- これはプログラマはすでに別のストーリーへと作業が移っているため
- レガシーシステムから
- 記録が前提となるが、長らく使われていた中で問題となっていないのであれば無理に記録する必要はない
- 本番で見つかるもの
- 全て記録する
いつバグを修正するかを決める
対応すべきバグが見つかった、ではいつ修正するか？については以下の3つ選択肢があります。
1. いま直す
バグは開発が進めば進むほど、修正に対するコストが増大していきます。見当がついているのであればすぐに対応することが望ましいですが、既存機能への影響などが考えられる場合は、顧客に対応への優先順位をつけてもらうこともあります。
2. あとで直す
発見したバグはチームで対応する前に顧客に優先順位をつけてもらう、対応すべきか否かを見当としてもらうというスタンスです。
3. 全く直さない
実装してはみたものの機能そのものがなくなる、または大きな変更が行われると考えられるときは対応しない選択肢もあります。 このとき、記録したレポートがあればオープンのままにしておかずクローズしてしまうことが推奨されています。
まとめ
今回はバグの取り扱いについてアウトプットしてみました。 まとめると・・・
- バグの内容や状況によって、対応は様々である
- どんなアクションをとるのが効果的か、はたまたとらないほうが良いのかの検討が必要
といったところでしょうか。
次回予告
次回も今回と同様にバグの取り扱いについてについてアウトプットしていきたいと思います。
ではまた！
最年少 DataSpider 技術者の誕生！ IoTとセンサーとAPIのごった煮ハッカソン参加レポート（後編）
それでは、前編に引き続いて「IoT とセンサーと API のごった煮ハッカソン」参加レポートをお送りします。
2日目オープニング
朝、会場に入るとこんなものが！これは徹夜したチームの皆さんの為ですね。
その後、みんなで恒例の体操の時間です。
身体がほぐれたところでハッキングタイムに移ります。
ハッキングタイム
まさかの追加要件
私は前日に続いて DataSpider を使ってもらっているチームのサポートに入ります。
「最年少 DataSpider 技術者」は飲み込みが早く、初めて触ったとも思えない速度で DataSpider の使い方を習得し、前日に「kintone へのデータ書き込み」「REST アダプタを使った雑談対話API(Noby API）への送受信」まで実装することができました。 残りは「Twitter への書き込み」「HTTP トリガーによる起動」だけだったのですが、ここにきて追加要件が発生！
「Gmail の送信」「受け取ったデータによる条件分岐」もやりたいということで、急ピッチで開発を進めます。
↑私は隣でやり方を教えるだけで、実際の開発はすべて隣の子が行っています。
残りは約5時間。間に合うのか！？
もう1つの DataSpider 活用チーム
今回はもう1チームで DataSpider を使っていただきました。
釣り竿とDataSpiderが繋がるという普段ではとても考えられない面白いものを作っています。
こちらのチームへは東京からヘルプに来てくれたメンバーがお手伝いさせて頂きました。
全体の様子
DataSpider を使っていただいているチーム以外の様子は深く知ることはできませんでしたが、ざっと見渡すと昨日より更に面白い事態にに。
鍬にはソニーさんのテニスセンサーやスマートウォッチが取り付けられています。
傘にも何か付いていますね。
どうやらこれは夫婦の食卓をシミュレーションしているようです。
発表が楽しみですね！
成果発表！
簡単に全チームの成果を紹介させて頂きます。
商店街のシャッター街を見える化する「街ing」。沼津の町おこしという目的が素晴らしいです。
「ノビィの耳はラズパイの耳」は時間が足りなくて完成までは行けなかったそうです。
家電が発生する魂の声を拾う「家電の魂」。こちらが最年少DataSpider技術者の子が作ってくれた作品です。
デモもバッチリ動きました。追加要件もすべて実装できたようです。
「味噌と奥さんとおはし」味噌汁の塩分量を検出し、部屋の明暗をコントロールします。
「自己主張○○s」デモでは傘とリモコンが自己主張していました。
「うなCOOLβ」もう1つの DataSpider 採用チームです。釣り竿の振動を検出して、DataSpider 経由で Twilio を利用して電話します。
「くわエクササイズ」見た目が一番気になっていたチームです。IoT は農業でも活躍できそうです。
どのチームもとても面白い作品で、時間があればもっと洗練されて良いものになりそうです。
審査結果発表
最優秀賞
Mashup Awards 二次予選への参加権を得られる最優秀賞は「自己主張○○s」でした。
アイデアが面白かったのに加え、すぐにでも実用化できそうな完成度も素晴らしかったです。
こちらは自己主張するリモコンの中身です。
DataSpider 賞
サポート企業からも独断で企業賞を出させていただくことができます。
今回は2チームに DataSpider 使っていただいたのですが、その中でも多くの部分で活用いただいた「家電の魂」を作った皆さんに賞をお渡しさせていただきました。
終わりに
ハッカソンは凄く楽しいと思うのですが、どうしても参加者の大半は開発者の方になってしまい、他の人にとっては敷居の高いイベントのように思います。私自身も1年前はハッカソンのサポートに行くのは自信がなく、またエンジニアの方の多い空気に馴染めずにいました。
しかし、実際にハッカソンやコミュニティイベントに参加してみるととてもオープンな雰囲気で、初めての参加であっても「楽しもう！」という気持ちさえあれば経験や技術力に関係なく楽しむことができます。また、ハッカソンで様々な人と出会い様々なサービスと触れることで、知識・人脈ともに普段の仕事にも活かせることがたくさんありました。
今は便利なサービスや API も多いので、プログラミングのできない人であっても kintone や mythings などを使うことでハッカソンに参加でき、DataSpider を使うことで重要な機能を担当することもできます。また、その時点では仕事上関わりのないと思った人であっても、業界は狭いのでそのうち仕事上でも接点ができ、お互い力になれることが必ず出てくると思います。
ハッカソンに行こうか迷っている方は、是非新しい自分を探すために一歩踏み出していただきたいと思います。
最年少 DataSpider 技術者の誕生！ IoTとセンサーとAPIのごった煮ハッカソン参加レポート（前編）
皆さん、はじめまして。東海・関西地区担当の築山と申します。営業マンのクセにでしゃばってエンジニアブログに進出してきました。
10月29,30日に Mashup Awards 名古屋ハッカソン「IoTとセンサーとAPIのごった煮ハッカソン」にサポート企業として参加してきました。客観的なレポートは事務局の方にお任せするとして、私からは主観たっぷりのレポートをお送りします。
Mashup Awards とは
Mashup Awards は賞金総額「500万円」と日本最大級のハッカソンイベントでして、アプレッソは昨年よりスポンサーをさせていただいております。
各地区の予選やWebでの審査を経て 12月17日に決勝を目指します。今回の名古屋ハッカソンはその一次予選も兼ねたハッカソンイベントとなります。
では、早速レポートに移ります。
開会～チームビルディングまで
オープニング
今回は事前申し込み24名の参加者に加えて、API、デバイス、ソフトウェアなどを提供するサポート企業が7社と大盛況。
サポート企業の机の上には様々なデバイスが並んでいるのですが・・・・
ん！？ これは・・・何故ラケット？？
ラケットのことが気になりつつも、いつもの通り伴野さん、まなみんの仕切りで始まります。
「Mashup」とは元々「複数の音楽を組み合わせる音楽の手法」で、Mashup Awards も様々な API やサービスを組み合わせることにより多くの賞を狙うことができるイベントとなっています。
様々なデータを連携することが得意な DataSpider とは非常に相性に良いイベントです。
インプットタイム
続いてインプットタイムです。各企業が参加者の方に自社のサービスを紹介します。 ここで魅力的だと感じて貰えた企業はたくさんのチームでハッカソンに採用してもらえるので、大事なアピールタイムとなります。
↑トップバッターはサイボウズの北川さん。kintone の紹介です。
↑ヤフーの清土さんからは myThings と myThings Developers
↑気になっていたラケットは SONY さんの持ち物でした。
デバイスをセットすることで、スイング速度、角度などの情報が得られます。
これを使ってどんな作品が出来上がるのか楽しみですね。
私からも DataSpider + Thunderbus の紹介をさせていただいたのですが、
エンタープライズの用途で使われていることをお話しても伝わりづらいので、
過去のハッカソンの制作事例を中心に紹介させていただきました。
↑大垣ハッカソンの最優秀賞作品 Bar Sota です。
アイデアソン＆チームビルディング
各社のサービスを頭に入れた状態でアイデアソンに移ります。
このようなアイデアシートを用いて、頭のなかにあるものを発散させていきます。
その後、アイデアを絵に変えていき、様々な人と会話してチームを作っていきます。
↑「通称：ナンパタイム」の風景
ランチタイム
アイデアソンを終え、チームができたところでお昼休憩です。
今回のハッカソン会場は名古屋工業大学をお借りしているのですが、お昼は学食にお邪魔します。
安い！
ハッキングタイム
お腹いっぱいになったところでお待ちかねのハッキングタイムです。我々サポート企業はアイデアソンの内容を聞いて、自社のサービスを使っていただけそうなチームのお手伝いに行きます。
最年少 DataSpider 技術者の誕生
ハッキングタイムが始まって早々に私に声をかけてくれたのが、なんと中学1年生の子。お父さんと一緒に参加しているのですが、「DataSpider を使ってみたい！」と言うことでお手伝いさせていただくこととなりました。
DataSpider で「スクリプト」と呼ばれる処理を作っていくのですが、どうやら API などの言葉もあまり知っていなかったようなので・・・
その場にあったホワイトボードを借りて授業が始まります。
やりたいことを聞きながら整理すると、マイクで拾った情報を元に mbed というデバイスがデータの送信元になります。DataSpider では mbed から送られてくるデータを受け取って、kintone へのレコード登録、雑談対話 API へのデータ送受信、Twitter 書き込みを DataSpider で実装する必要がありそうです。
随分とやることが盛り沢山で、この時点での私の気持ちは「完成しなくても DataSpider を使って楽しんで貰えればいいかな」という気持ちでした。
どうやら、ソフトウェアのインストールも初めてだったようなので、まずは DataSpider のインストールから一緒に進めていきます。（続く）
他チームの様子
ふと、周りに目を向けてみると・・・サポート企業に相談しながら皆様黙々と作業されています。
今回のテーマは IoT ですので、こんな作業も当然あります。
え！？えーと・・・それは「鍬（クワ）」ですよね？？これは完成が楽しみです。
長くなってしまったので、後半に続きます。
APIStudy#1が開催されました
こんにちは。そしてはじめまして、アプレッソ技術部の對馬です。
いつもはDataSpider Technical Networkでブログを書いているのですが、今回はブログ内容の関係でエンジニアブログにお邪魔することになりました。 もしかしたらこれからもたまにお邪魔して、ちょろっと書いていくこともあるかもしれません。 よろしくお願いします。
さて、エンジニアブログにお邪魔して何を書くかと言いますと！ この間、とある勉強会のお手伝いをさせていただきましたので、その勉強会の様子をご紹介しようと思います。
その勉強会とは…ずばり…「APIStudy」！！
APIStudyでは「APIのベストプラクティスを考えていく」ことを目的とし、APIを利用する人や提供する人に参加していただき、お互いにとって最適なAPI設計につながることを目指す勉強会です。
そして記念すべき第1回目が、10月13日(木)にサイボウズ株式会社 東京オフィスにて開催されました。 初回ということで「発散」のテーマのもと、まずは参加者が日ごろ感じているAPIへの熱い思いをぶつけ合って、APIのどこが好きか、どこを改善したいか、どこについて話し合いたいかなど、それぞれの思いを明確にしました。
オープニング＆インプット
まずはアプレッソ 脇野からAPIStudyの概要説明ののち、3名からAPIに関するLTがありました。
サイボウズ 後迫さんから「経験から学ぶkintone API」
kintone APIの歴史や、どのような目的で提供しているのか。kintone APIの貴重なお話でした！
ケンブリッジ・テクノロジー・パートナーズ 市川さんから、「オープンデータのAPI利用と開発について」
オープンデータを使うときにあるあるな悩みについて…、利用・開発する側のご意見を話していただきました！
Misoca 松本さんから「MISOCA API V3の開発するにあたって」
名古屋から来てくださいましたー！
MISOCA API V3になるまでの奮闘したことのご紹介や、APIについて気になる点を提示していただきました。
余談
ちなみに私はAPIについて全くと言っていいほど知識がないです。
なのでLTで一番熱くなったのは、市川さんのLT内で「ラブライブ！サンシャイン‼」という単語が出てきたときでした。
※ラブライブ！サンシャイン‼は静岡県沼津市が舞台となっているスクールアイドルの青春アニメです。※
そんな私ですが、3名のLTから APIに対する熱い思いが伝わってきて、「APIって実は相当面白いことなんじゃないか！？この勉強会は楽しくなるんじゃないか！？」とワクワクしだしました。
ブレインストーミング＆チームビルディング
LTが終わると勉強会の本題、「発散タイム」です。
まずは参加者の皆さんに「API」で思いつくキーワードを挙げてもらいます。
▲キーワードを書き出します
APIへの思いを出し切った後は、参加者全員分のキーワードをカテゴリ分けしていきます。
「エラーについて」「ドキュメントについて」の困った体験のカテゴリや、勉強についてのカテゴリ、セキュリティについて語りたい！というものなど、たくさんの人がいる分、キーワードもカテゴリも多様です。
そして自分が興味のあるカテゴリについて深堀するため、カテゴリ別にチームを作ります。
テーマの深堀＆発表
チームができたら、そのカテゴリについてチーム内で語ります。
こういう困ったことあるよね、皆さんはどうしていますか？など、今まで溜まりに溜まっていたAPIへの思いを吐き出します。
真剣にディスカッションをしながら「あるあるネタ」で笑いあうなど、皆さんがとても楽しそうで、勉強会が始まってすぐの「ワクワク」は当たっていたんだなぁと、何だか嬉しくなりました。
そして最後は、チーム内で話し合ったことを全体と共有します。
Documentチーム
作るの大変！化石化しちゃう！など様々なAPIのドキュメントについての問題の解決策を話し合っていました。
設計・Versionチーム
いけてるWebAPIとは何か！？について話し合っていました。
あるある話
kintoneについて物申したかったけど、もはやkintoneAPIだけではおさまらなかった全体的な「APIのあるある」について発表していました。
おわり
参加者の皆さんの反応が気になりすぎた初回でしたが、皆さん楽しんでいただけたようで何よりでした。 APIについて、こんなに注目した勉強会というのも、なかなかないのでは…。 そしてアウトプットをメインとした内容だったので、そういった意味でも充実感があった、という意見もいただきました。
皆さん、ご参加ありがとうございました！！！
そしてそして！！！
なんと既にAPIStudy #2が開催決定しております！！ ありがとうございます！
少しでも気になった方は、上記ページからお気軽にお申込みください！
是非一緒にAPIのベストプラクティスを考え、盛り上げていきましょう！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その4
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその4になります。
前回は「テスト自動化の阻害要因」について書きました。
今回は「アジャイルテストの自動化戦略」について学んだことをいくつかピックアップしてきます。
テスト自動化のピラミッド
(P274 14.1.2 「テスト自動化のピラミッド」より)
上記の図はテスト自動化における範囲や容易性などを示した図になります。
下に行くほど容易かつ広範囲をカバーすることができます。下から順に説明していきます。
単体テスト/コンポーネントテスト
- チームを支援する技術面のテスト（第1象限）
- 一般にxUnit系のツールを用いて、対象システムと同言語で記述される
- 高速で安価に記述できる(高ROI)
受入テスト（APIレイヤー）
- チームを支援するビジネス面のテスト（第2象限）
- 「正しいものを作ったか？」を確かめる為、機能テストやストーリテストなどが含まれる
- 単体テストに比べて大規模な機能の集合をカバーする
GUIテスト
- 頻繁に変更が入る可能性が高い
- 実行に時間がかかる
- 低いROI
手動テスト
- ビジネス面について批評するテスト（第3象限）
- 人間の手と目によって実施されるべき
- ユーザビリティテストなど
テスト自動化を検討するにあたってはこのピラミッドに当てはめて考えるとよいとしています。 テスターがまず取り掛かりそうなGUIテストの自動化は実のところ投資対効果があまり高くありません。 それは頻繁な仕様変更や実行そのものにかかる時間などからです。
また、ビジネス面について批評するテストは人間の手と目によって実施されるべきものです。自動化ではその価値が計れません。
何を自動化できるのか, 何を自動化するべきでないのか
（P277 14.2 「何を自動化できるか？」, P283 14.3 「何を自動化するべきでないか？」より）
上記の通り、開発工程の中で自動化できそうなものがあげられています。ここでは機能的な側面のテスト以外にも、定型的な繰り返し作業、たとえばテストの結果レポートをメールするといった作業についても自動化 候補として検討することが推奨されています。こういった周辺作業についても自動化を進めることによって、本来注力すべき作業の生産性もあがりそうです。
また、候補外とされているものについては、人間による批評が必要なもの、ROIが著しく低いと思われるものが含まれています。失敗する可能性がほぼないテスト（「絶対に失敗しないテスト」とありますが、「絶対」はありえません。念のため！）や1回限りのテストについて自動化することは、大きな無駄となってしまいます。
自動化の戦略を立てる---どこから始めるべきか？
（P287 14.5 「自動化の戦略を立てる---どこから始めるべきか？」より）
戦略を立てるにあたっては、冒頭の「テスト自動化のピラミッド」を参考にします。ピラミッドは下層にいくほどROIが高くなります。一方でビジネス面のテストを考えると上層にいく顧客が求める機能が実装されているか、状況が理解しやすくなります。
最下層のテストを充実させつつ、いくつかのテストケースにおいては手動で確認するようにするなど、目的に合わせて優先順位をつけていくことが重要と考えます。
テスト自動化にアジャイルの原則を適用する
（P297 14.6 「テスト自動化にアジャイルの原則を適用する」より）
テストの自動化においてもアジャイルの原則を適用して、その価値を利用していくことができます。テストの設計やスコープをシンプルに保つことが必要になります。これは様々な変化に対してテストが追従していくうえで重要な思想と考えます。また反復的なフィードバックも大きな効果をもたらします。よりよい自動化の方法やテストシナリオを検討してフィードバックしていくことが大切です。しかしここで忘れたくないのはROIを意識することです。全てをやり直すとなっては、今までかけた時間が無駄になってしまう可能性があります。顧客へ価値を届ける為に何が優先されるべきかをしっかり考えることが必要と思います。
また、チーム全体のアプローチはテスト自動化においても重要な考え方としています。テスタビリティが十分に考慮された実装となるように、プログラマやテスター、その他のチームメンバーが協力することで、複数の観点やスキルセットが得られます。チーム全体で助け合うことによって前進する勇気や自信が高まります。（いいですね！）
まとめ
今回は「アジャイルテストの自動化戦略」について学んだことをアウトプットしました。 まとめると...
- 「テスト自動化のピラミッド」を利用して、注力すべきポイントを検討する
- 開発にあたって自動化可能なもの（プロジェクト進行における定型業務含む）、自動化すべきでないもの（人間による批評が必要なもの、ROIが著しく低いもの）を考える
- 自動化に対してもアジャイルの原則を適用する
となります。またそれぞれROIをしっかり意識して検討/実施していくことが重要ですね！
次回予告
次回はすこし飛んで第18章「コーディングとテスト」についてアウトプットしていきたいと思います。
ではまた！
