Appresso Engineer Blog

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

「探索的テスト(Exploratly Testing)」について

こんにちは、品質マネジメント部のいそです。

これはアプレッソAdventCalender10日目の記事になります。

qiita.com

何を書いていこうかとしばし考えていたのですが、ちょうどいい機会だったので「探索的テスト(Exploratly Testing)」についての学びをアウトプットしておこうと思います。

まずは基本的なところから・・・

探索的テストとは

  • テスト仕様などのテストソースを作成せずに、様々なインプット(対象の仕様書、過去の経験、勘)から仮説を立ててバグを見つけ出す
  • 一つのアクションをとるごとに次にどうするかを検討するため、柔軟にテストを進められる
    • 設計→実装された通常のテスト(スクリプトテスト)では、事前に検討されただけに網羅性は高まるが(探索的テストと比較して)重いテストとなる。
  • 探索的テストのモデル図
  • テスト仕様の作成コストを抑えられるといっても、テストの全てを探索的テストに置き換えるのはやりすぎ。スクリプトテストと探索的テストは補完関係にあるので、適材適所で用いる。

進め方

大きく3つのやりかた(下に行くほど厳格化していく)
  • すきにやる
    • すきにやる
  • チャータを利用する
    • 目的やそれを達成する為に必要な指針などを決めて書いておく
    • シナリオをチャータとして利用することもあるが、スクリプトテストでの具体的な「手順」とはことなりおおまかな記述とし、実行の幅を持たせたりする
  • セッションベースに行う
    • チャータを用いつつ1セッション1時間といった区切りを設定して実施する
    • 何に対してどこまで実施したかを管理しやすくなる

探索的テストを支えるツール群

  • Capture for Jira
    • JIRAと連携するCaptureツール
    • スクリーンショットに注釈をつけてJIRAにIssueを作成
    • そのままチームで議論したりできる

ja.atlassian.com

  • qTest Explorer
    • キャプチャや操作時のTimelineを残せる
      • いついつクリックした
      • いついつ入力した
    • Seleniumのテストシナリが出力できるので即自動化できる模様
    • 同社製のテスト管理ツールへとりこんだりJIRAと連携してIssueの作成もできる模様

www.qasymphony.com

などといったものがあるが、これらはWebアプリケーションのみでデスクトップアプリケーションが対象だった場合には使えない・・。 よさげなものはないかと探してみると↓のツールを発見した。

  • Rapid Reporter
    • Shmuel氏作成のフリーソフト
    • 無骨(シンプルともいう)
    • 自動記録はない

testing.gershon.info

動かしてみる

DataSpiderServistaのStudio for Desktopを対象に動かしてみる

起動すると下の画面が出てくる

f:id:yoiso:20171209200101p:plain

常に全面に表示される。ウィンドウの透明度を変更することもできる。 このウィンドウに1行程度のメモを書いていく。

ますは最初にReporterを入力、そしてCharterを入力する。

(Enterを入力するとIMEの日本語変換時でも即ログに書き込まれてしまうの悲しみある・・・。)

するとステータスが表示される。 カーソルキーの上下を押すことで、以下の通りに変更できる

  • Setup
  • Next Time
  • Question
  • Bug
  • Check
  • Test
  • Note

Noteまで進むとSetupに戻るので、学習や仮説検証のループを行いながら思考を記録できる。 記録したログは↓のような形でCSVもしくはHTMLで出力できる。

f:id:yoiso:20171209200144p:plain

まとめ

  • 対象に対する知識や同種のものに対しての経験も必要だったりするため、新人がいきなりふられるとつらそう感はある
  • とくに意識せず探索的テストをしている場面はちょこちょこある
    • 少ないインプットで作成したテスト仕様では、実際のテスト時に探索的なテストをして、元のテスト仕様にフィードバックしていることはある
    • そういった意味では普段やっていることの延長でもある
  • 改修確認時に周辺の確認をするのにも役立てられそう

そんなわけで・・

  • アプレッソではアジャイルな体制で開発を行っており、QAにおいても早さと品質を両立できるように日々スキルを研磨しています。興味があればご一緒しましょう!

www.wantedly.com

参考情報

アプレッソに入社してました

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

qiita.com

はじめまして。株式会社アプレッソ 開発部の野村です。
2017年8月にアプレッソに入社してました。

入社エントリをまだ書いていなかったので、この機会に書かせていただきます!

なにをやってきたか

新卒でソフトウェアベンダーに入社し、BtoBのWebサービス開発に携わっていました。 開発のほかにも、運用、サポート、営業支援と多岐にわたる業務を経験しました。 開発言語は Ruby on Rails で、それ以来 Ruby が好きです。

その後、教育系会社のエンジニアとして、受託案件のシステム・サービス開発に従事し、海外の開発ベンダーとのサービス開発などをしていました。

入社してやっていること

DataSpiderServista の開発チームに加わり、クライアントの開発や次バージョンに向けた開発をしています。

また、10月から初めた New Feature Showcase のとりまとめをしています。
New Feature Showcase とは、毎週「動くもの」を発表してドヤァ!とする場です。
もともとDataSpiderServistaチームはスクラムで開発していて、スプリントレビューで社内に新機能などをお披露目する機会がありました。
ですが、他チームの成果や、個々人で温めている機能改善案、ツールといった「動くもの」を披露する場は多くはありませんでした。

このような「動くもの」を共有して、技術の共有や製品の発展に役立てよう!というウィークリーイベントです。

f:id:nomuson:20171207180053j:plain:w300
IoTデバイスとDataSpiderの連携を発表中!

アプレッソに入社して感じていること

入社前から先進的な取り組みをしている会社だと思っていましたが、入社後もそのイメージは変わらず、柔軟なところが多いです。

例えば、11月に溜池山王にオフィスが移転したのですが、以前よりも通勤ラッシュに悩む人が増えていました。そこで、出退社時間をずらしたシフト勤務の導入が発議され、すぐに実運用に向けて動き始めていました。 このようなフットワークの軽さは、Advent Calendar 5日目の元開発部長佐々木さんの記事にある「Growth Mindset」や「ムダの排除」といった考え方に起因していると感じました。

今後やっていきたいこと

アプレッソでは1年半前からスクラムを取り入れています。私自身は1社目でもスクラムを経験していて、その効果に可能性を感じていました。
スクラムによる開発を突き詰めて、アプレッソのスクラムを形作っていきたいと思っています。

また、「アプレッソ」を多くの人に知ってもらいたいなと思っています。
勉強会、Meetup、ボードゲーム会など企画できたら嬉しいです。

APIStudy#5 開催報告

こんにちは。技術部對馬です。

去る2月21日に、APIStudy#5が開催されました。

前回の#4 の様子はこちらからご覧ください。

appresso.hatenablog.com

今回はゲストに乗り換え検索アプリ「駅すぱあと」でおなじみの株式会社ヴァル研究所さんを迎え、APIについて語り合いましたので、その様子をご報告します。

f:id:ytsushima:20170314132623j:plain

第1部 LTタイム

まずは恒例LTからです!

なんと今回はヴァル研さん含め3名が登壇してくださいました!

ヴァル研究所 丸山さん

最初は、ヴァル研究所テクニカルエヴァンジェリストである丸山さんから。

f:id:ytsushima:20170314132705j:plain

ヴァル研・駅すぱあとのご紹介をしていただいたあとに(運営脇野とヴァル研究所は同い年!)、こんな駅すぱあとWebServiceAPIは嫌だ!をテーマにAPIへの思いをぶつけていただきました。

f:id:ytsushima:20170314132825j:plain

  • APIKeyが紙で届く。コピーさせてくださいよぉ
  • 自動発行されない
  • パスが直感的ではない
  • パラメータ多すぎ
  • JSONが扱いづらい…

そして最後に恐ろしい画面が…!

f:id:ytsushima:20170314132842j:plain

道理で感情がこもっていたわけですね…。 そして#5開催日翌日(2月22日)が駅すぱあとの誕生日でした。惜しかった!おめでとうございました!

MOONGIFT 中津川さん

中津川さんはニフティクラウドのmobile backend エヴァンジェリストで、今回はmobile backendのお話でした!

そして、SNSで以下を呟いてもらうことが本日の目標。

#NCMBすごーい f:id:ytsushima:20170314132917j:plain

(出たな、サーバルちゃん…!)

というのは冗談で本当はこっち↓ f:id:ytsushima:20170314132940j:plain

アプリ作っていてサーバーを建てなければいけないときに、まるっとカバーできるのがニフティクラウドです。

しかしそのAPIに4つの問題があるので、そちらを紹介していただきました。

  • APIのバージョニング問題。  いつバージョンを切り替えるのが問題。
  • セキュリティ問題。  妥当性チェックのときに、APIをコールしないと正しいかわからず、ハードルが上がる。
  • 動的に変化するパス。  データストアでは勝手にクラス名をいじって保存場所を変更できる。 …が、美しくない!
  • ドメイン問題。  4つもAPIのドメインがあって管理が大変。

f:id:ytsushima:20170314133015j:plain

ヴァル研究所 伊藤さん

そして最後は、伊藤さんから「WebAPIでダブルバッファリング」について。

f:id:ytsushima:20170314133114j:plain

データのチェック処理で完了までには時間がかかるので集計途中のデータを確認したく、WebブラウザからAPIで引っ張っていました。これをバッチで並行に処理していきます。

しかしそのうちどんどん処理時間が長くなり、タイムアウトが発生してしまうようになってきます。

そこでちょっと前のデータを予め集計し公開を繰り返すようにし、リクエストとデータ更新がぶつからないように変数を分けておく必要があったと、つまりダブルバッファリングが必要だったいうお話でした。

切り替えイメージに、またしてもサーバルちゃん!!いや、これはサーバル!

f:id:ytsushima:20170314133047j:plain

すごーい!けもフレはやっぱり人気なんだね!

そして、レスポンスに時間がかかるWebAPIはどう処理するべきなのか、議論したいとのことでした。

第2部

さて、続いてはお待ちかねのディスカッションタイムです!

今回のテーマは…

  • レスポンスがかかる場合の方法
  • APIのサポートが増加した場合の対応
  • こんな最悪の状況いやだね!愚痴り隊
  • 複数のAPIをバラバラで使う場合の方法

そしてグループに別れ、発散発散!

f:id:ytsushima:20170314133141j:plain

f:id:ytsushima:20170314133206j:plain

共有タイム

レスポンスがかかる場合の方法

f:id:ytsushima:20170314133318j:plain

レスポンスの許容範囲どのくらいか、というのはバッチとリアルタイムによってきます。

バッチの場合は、単位が営業日単位。

リアルタイムでは、厳しいところだと200ミリsec以内。

UXも結構大事!

レスポンスを早くするためには、リアルタイムでDBにアクセスに行かないのが1つのベストプラクティス!

あとは、お客さんの許容範囲を知ることが大事。

そしてその概念を営業に植え付けとかないと「遅いって言われてる!!!」って慌てちゃうので、認識をもたせましょう。

APIのサポートが増加した場合の対応

f:id:ytsushima:20170314134458j:plain

サポート大変だよね問題。

  • 伝言ゲームが大変。
  • 質問が「エラーが起きたんですけど…」
  • 同じ人から何回も…

サポートの仕方はサイボウズさんがよくできているそうです! それは、コミュニティのユーザーさんが質問に答えてくれるエコシステム。 核となる人が必要なので、その人たちを見つけて意識付けをし、構築していきました。所謂エヴァンジェリストのような方々です。 見つけ方は、kintoneを作ったときに関わった人やTwitterによく書いてくれている人を…、ロックオン! kintoneのことが好きな人に、協力いただいているそうです!

またサンプルコードを充実させるのもよいプラクティス。 Azure API マネージドはいろんな言語でサンプルコードがあるから便利かも。 AIも使えるぞ!!!! あとは、問い合わせ自体を営業にやらせて鍛えるという案も。

営業さん!!狙われています!!!

こんな最悪の状況いやだね!愚痴り隊

f:id:ytsushima:20170314134543j:plain

再現ができないエラー、エラーメッセージの原因がいまいちわからないあるある!

エラー時のレスポンスコードが200でその中に理由が入ってて意外とわからない…。

エラー時のレスポンス出力コーディングまちまち…。などのエラーに関するあるあるから、 仕様がバラバラなどの仕様あるあるまで、たくさん発散していました。

ドキュメントが間違っている!!

パスワードつきのExcelファイルはいけてない!!!!!

…などなど、最後の方は滾っていましたね…。

複数のAPIをバラバラで使う場合の方法

f:id:ytsushima:20170314134608j:plain

いろんなAPIをまとめて使って、レスポンスや結果を返すことについて。

「分散処理してマージ」を繰り返すというのが実際にあったケースで挙げられました。

あと、A社B社C社のAPIを使いたいがレスポンスがそれぞれどのくらいで来るかわからない場合、どう処理するのか?の結果が以下2つ。

  • 時系列で処理するように実装していく
  • 処理ができた順番にレスポンスを返す

WebAPIには遅延がかならずあるので、そこの処理が重要になってくるという結論になりました。

人によってAPIの捉え方が違うし、APIへの関わり方によっても違ってくるので、いろんな立場の人とAPIについて話していけると面白い!

おわりに

f:id:ytsushima:20170314134632j:plain

LTでまさかサーバルネタがかぶるとは思いませんでした…。

そして今回も皆さん、十分に発散できたのではないかと思います!

いろんな思いを発散することができる!それがAPIStudy!(なのかもしれない)

今回のグラフィックレコーディング

完成したグラレコがこちら!

今回も素晴らしくきれいにまとまってますね♪ f:id:ytsushima:20170314134736j:plain

… ま た い た !

\サーバルだよ!/ f:id:ytsushima:20170314140047p:plain

なんだかんだで今回のMVPかもしれない…

そして

今回は開催報告が遅くなってしまって申し訳ないです…。

その為!!!!!

次回開催が定員オーバー!

なんということでしょう!

これも皆さんが楽しそうにAPIトークをしていただいているおかげです…。

次回はさくらインターネットさんで開催します。

apistudy.connpass.com

そしてなんと!この度#6開催の増枠が決定!(2017/03/15情報更新) 40名まで定員を増やしました!

(APIに飢えている)けものはいても、のけものはいない♪

Welcome to ようこそAPIStudyパーク!

宜しくお願いします。

ペアプログラミングしていてもレビューは必要か?

こんにちは、開発部の野口です。

この記事では、私が所属していたスクラムチームでペアプログラミングが始まって、コードレビューがどう変わっていったかというストーリーをお話しします。

目次

ペアプログラミングが始まる

私が所属する DataSpider Servista の開発チームでは、昨年の夏から、スクラムフレームワークにのっとって開発を行っています。

人数の多い *1 チームでスクラムをやっていると、自然とペアプログラミングが始まります。
ただでさえ短いスプリント(一週間)のなかで、仕掛り作業を増やしても効果的でないからです。

たとえば、6 名のプログラマが「せーの」でそれぞれにタスクを取ると、6 つのストーリー *2 に並行着手することになります。
すぐに終わるものもあれば、時間がかかるものもあるでしょう。

さて、計画やふりかえりの時間を除くと 4 日間しかない作業期間において、最も時間がかかるストーリーに着手した人が、次の日風邪で休んだらどうなるでしょう?(答 : おしまい)

こういった問題を防ぐため *3、チームは自然とペアプログラミングをするようになりました。
私は 2017 年の 1 月末までチームにいたのですが、その頃には、計画の日を除いて、毎日 4 ~ 5 時間ほどをペアプログラミングに費やしていました。

GitHub:Enterprise 上でのレビュー

本題に入る前に、少しだけアプレッソでのレビューのスタイルについて説明しておきます。

アプレッソでは、svn を使用していた頃の「コミッター(レビュイー)の横にレビュアーがついてコードをウォークスルーし、レビューが完了したらコミットする」スタイルを経て、現在は、GitHub:Enterprise の Pull Request 上でレビューをするスタイルを取っています。

Pull Request の導入によって、以下のような利点が生まれました。

  • 非同期でレビューできる
  • レビューの経緯がコメントとして残る

一方で、以下のような課題も生まれました。

  • いつレビュー(マージ)してもらえるのか不明瞭になりやすい
  • 大きめの Pull Request について、ゼロベースでコードを見ると、仕様(意図)の理解から始めるのでレビュアーの負担が大きい

このような課題は、「適宜声をかける」「Design Doc をつける」「必要なときにはレビュイーを呼んで説明してもらう(一緒にコードを見る)」等の運用でカバーしていました。

ペアプログラミングしているとレビューが楽になる

さて、一方で、スクラムチームではペアプログラミングが始まっています。
厳密に計測はしていませんが、ここ 2 ~ 3 ヶ月は、チーム内で書かれたコードの 8 ~ 9 割程度はペアプログラミングによるコードではないかと思います。

とはいえ、ペアプログラミングはただ自然発生的に始まっただけだったので、従来通り Pull Request 上でのコードレビューは行っていました。

ペアの誰かがレビューする

コードレビューの原則は、「コードを書いた人以外がレビューする」です。

ところが、ペアプログラミングが本格化してきたある時期、チームの中から「ペアの中で Pull Request のレビューもまかなったほうが効率的では?」という意見が出ました。

当然、「しかし、それではレビューにならないのでは?」という意見も出ます。

そこで出た折衷案が、「1 つのストーリー(→ Pull Request)にレビュアーを 2 人つけ、ペアの中でも、書いたコードのドライバーではなかった人が必ず(相互に)レビューする」でした。 *4

ペアの中で Pull Request のレビューをまかなうと効率的

実際にやってみると、とても「効率的」です。

ペアで書いたのだから、よく知っているコードです。とてもスムーズにレビューを進めることができます。
個人的には、「(はじめは)よくわからない、コードの塊をレビューする」とき特有のストレスがなくなっただけでも嬉しいと思います。

しかし……、そもそも、ペアで書いたコードにレビューは必要なのでしょうか?
あるいは逆に、「ペアの中で Pull Request のレビューもまかなう」ことが、「本当にレビューになっている」のでしょうか?

ペアプログラミングしていてもレビューは必要か

本題の「ペアプログラミングしていてもレビューは必要か」にたどり着きました。

いま、2 つの問いが生まれています。

  • 「すべてペアで書いたコード」を、あらためてレビューすることが必要か?
  • 「ペアの中で相互にレビューする」ことは、Pull Request のレビューとして十分か?

「すべてペアで書いたコード」を、あらためてレビューすることが必要か

ペアプログラミングは「継続的なコードレビュー」とも言われます。
だとしたら、「すべてのコードをペアで」書けば、コードレビューは不要になるのでは?

実際のところ、8 ~ 9 割のコードをペアで書いてみての感覚としては、「やはり必要」です。

ペアは自信を持って速く進む

ペアプログラミングの効果の一つとして、「必要なことに集中(フォーカス)できる」ということがあげられます。

ナビゲータは、大きな問題を塊で考えずに、一つひとつのタスクに集中するようにドライバーに促します。
結果として、テンポよく実装を進めていくことができるのですが、ときには、「イマイチな実装」で「とにかく進んだ」あと、その部分がなんとなくそのままになってしまうことがあります。

もちろん、理想はナビゲータが注意深くコントロールすること、あるいは「レッド→グリーン→リファクタリング」のサイクルを厳密に守ることなのですが、私たちのチームは、「完全」にはなりきれていません。

ペアによって「今必要なこと」に集中し、自信を持ってぐんぐん実装を進められることは、ペアプログラミングの大きなメリットです。
一方で、それをコントロールしきれず、細かい問題の処理が漏れることがあります。

ここで、私たちのチームでは、ペアで書いたコードも改めてレビューすることで、ペアで漏れた部分をレビューでカバーする、というやり方が機能しています。

分断された知識をレビューで拾い集める

また、これは私たちのチーム特有の部分かもしれないのですが、一つのストーリー(→ Pull Request)に対して、複数のペアでローテーションしながら開発を行っています。
コードの知識を偏在させず、「誰でも、どのコードも触れる」状態を目指してのことです。

具体的には、だいたい 1 件の Pull Request に対して 2 ~ 3 名(2 ~ 3 アカウント)のコミットが含まれます。つまり、3 ~ 4 名が関わります。
多いときは、5 名にのぼることもあります。

f:id:enk_enk:20170224184400p:plain
▲比較的関係者の多い Pull Request の例 *5

ペアは原則として 1 人ずつ交代(1 人が抜け、1 人が残る)するようにしてはいますが、どうしても知識が分断されてしまう部分があります。
たとえば、ストーリーに対して最初にコードを書いた人が「あとでやろう」と思っていたちょっとしたリファクタリングが、入れ替わりの中で忘れられ、コードの重複が最後まで残ってしまったりします。

こういった問題も、マージ前のコードレビューによって回収することができます。

コードの重複は、見ればすぐにわかります。
「ペアで書いたから」と思っていきなりマージしてしまうと重複がそのままマージされてしまいますが、少しだけ時間をかけて Pull Request 全体を見渡すことで、このタイプの「ペアとペアの間に落ちた問題」も拾い集めることができます。

他には、「ボトムアップでテストを書いてはきたが、最終的にカバレッジが足りているかどうか」みたいなことも、最終的なレビューのタイミングで確かめることができます。
ペアプログラミングをしていても、コードレビューを設けると、このように Pull Request の全体像を見渡すいいタイミングになります。

「ペアの中で相互にレビューする」ことは、Pull Request のレビューとして十分か

このように、経験から、コードの大半をペアプログラミングで書いていても、コードレビューは有用だと感じています。

では、逆に、今採用している「ペアの中で Pull Request のレビューもまかなう」方法は、本当にコードレビューとして十分機能しているのでしょうか?

コードへの愛着と批判的なコードレビュー

ペアでコードを書いていると、ドライバーではなくナビゲータであっても、自然とコードに愛着がわきます。

よく「一度書いたコードを捨てるのは難しい」と言われますが、それはペアの片割れであっても同じことです。
コードレビューの際に、「私たちが書いたコード」という意識をまったく持たないことは不可能だと思います。

かつて、「誰かが書いたコード」を「別の誰か」がレビューしていた頃は、かなり、批判的にレビューを行っていました。

まずビルドしての動作確認を行いながら、コーディング規約もきっちりと頭に入れておき、綿密に一行一行を確認し、また動作確認を入念に行い……。
こうして、何十件もの指摘を積み上げることも少なくありませんでした。*6

このように批判的にレビューすることで得られていた綿密さは、失われてしまったのでしょうか?

数値化できていないので、主観的な感覚ですが、失われている部分もある、と思います。
別の言い方をすると、ペアプログラミングを行いながらも、あえてコードに一切関わらなかった人が批判的なレビューを加えることで、よりコードの品質が高まる可能性がある、と思います。

圧倒的なコードの共同所有

ところで、先ほど「私たちが書いたコード」というフレーズが出ました。

ペアをローテーションしながら、コードレビューも複数名が入り混じって行っていると、コードはまさに「私たちが書いたコード」としか言いようのないものになっていきます。

XP のプラクティスの一つに「コードの共同所有」がありますが、この状態は言うなれば「圧倒的なコードの共同所有」と言えます。

ある意味、「時間差のあるモブプログラミング *7」とも言えるかもしれません。
複数の頭脳があわさって、一つの(とても賢い)頭脳となってコードを書いている状態です。

このとき、「そのコードに直接関わらなかった人による批判的なレビュー」をあえて追加投入する必要があるか? と考えてみます。

真に「共同所有 = 一つの頭脳」の状態になっていれば、コードに関わる人が単純に 3~4 名から 4 ~ 5 名に(1 名)増えただけ、ということにもなりえます。もはや、別段、批判的でもありません。
この場合、「どちらでもいい」ということになりそうです。純粋に「今よりも目の数を増やした方がいいか(→ ちょっとだけ賢くした方がいいか)どうか」で考えるわけです。

一方、本当に「一つの頭脳」にはなりきっておらず、「直接関わった人」と「直接関わらなかった人」とで多少なりとも視点の違いが出るようなら、そこには摩擦が生まれます。
この場合、「その摩擦が効果的な摩擦か」が判断基準になりそうです。

それが主にコーディングスタイルの問題に分類されるような摩擦なら、おそらく非同期のコードレビューよりも、ペア作業の中ですり合わせて解決していくほうが、効率的でしょう。

一方、「視点が異なることによって、バグを見つけ出す」ような摩擦なら、「別の人がレビューする」価値はあるといえます。

「ペアプログラミングしている」という事実から「コードレビューが必要か」はわからない

こうして考えてみると、一つだけはっきりとわかることがあります。

それは、「完全な共同所有かどうか」も、「効果的な摩擦が生まれるかどうか」も、「ペアプログラミングしている」という事実だけでは判断できないということです。

どのようなスキルと性格を持ったメンバーが、どのような特性を持ったプロダクトに対して、どのようにペアプログラミングをしているか。
そういったさまざまな要素によって、チームの状態が変わってくるはずです。

これは「どのようなタイプのコードレビュー *8 が最も効果的か」という議論にも似ているのかもしれません。
大量のサンプルを集めれば、おそらく一般的な傾向は見出だせるのだろうと思います。そういったデータが手に入れば、自分の状況と照らし合わせて、大いに参考にできます。

しかし、「ペアプログラミングしていてもレビューは必要か」という問いに一般的で簡潔な結論を出すことは難しそうです。

まとめ : プラクティスの効果には常に意識的でありたい

スクラムチームでのコードレビューの変遷から「ペアプログラミングしていてもレビューは必要か」について考えてきましたが、明確な結論は出ませんでした。

あえて言うなら、正しく「状況による」というのが答になりそうです。

現在私たちのチームでは、チーム固有の状況から、「ペアの中で相互にレビューする」ことが機能しています。
しかし、これも将来変わっていくかもしれません。

よって、この記事の結論は、「プラクティスの効果には常に意識的でありたい」ということになります。
ペアプログラミングしていてもレビューは必要か? と問い続け、可能ならばデータも集めることで、必要な場合には行い、不要な場合には行わず、行う場合のやり方もより効果的にしていくことができるでしょう。

関連エントリ

まだスクラムを始めていなかった 1 年前には、こんなことを考えていました。

appresso.hatenablog.com

こういったスタイルの背景となっているスクラムの実践についてはこちらをご覧ください。

appresso.hatenablog.com appresso.hatenablog.com

*1:プログラマ 6 名、テスター 4 名ほど。最適な人数(7±2 名)をやや超過しています……。

*2:正確にはストーリーとは限らず、Product Backlog Item(PBI)です。ですが、この記事では、通りがよい「ストーリー」という用語を使います。

*3:正確には、もっと色々な理由があります。たとえば、Sprint Backlog にも優先順位があり、上から順に終わらせていくというルールにしています。その場合、たとえば 6 つ同時に着手すると、いくつものストーリーが半端なまま完了できない可能性も出てきますが、上から順に 1 つずつ集中して終わらせていくと、少なくとも半分以上は確実に終わらせられます。実際、はじめの頃は、完了した PBI がたったの 1 件、というスプリントもありましたが、数ヶ月すると、完了できないものがあったとしても、一番優先度の低い 1 件だけ、といった状態になっていました。

*4:ペアプログラミングのスタイルによっては、ドライバーとナビゲータはとても頻繁に交代するので、「ドライバーではなかった人」という表現は正確さを欠くかもしれません。ここで意図しているのは、「(直接)自分が書いたコードを自分だけがレビューしておしまいにする」ことがないようにする、ということです。2 人で交代しながらコードを書くとして、2 人がそれぞれに(やや冗長性を持って)コードをレビューすることで、「ある人が直接書いたコード」を「他の人がレビューする」ことのカバレッジは 100% になる、はずです

*5:participants のうち一人は QA エンジニア

*6:当時は Pull Request そのもののサイズが大きかったこともありますが

*7:https://www.youtube.com/watch?v=dVqUcNKVbYg

*8:ウォークスルー、机上チェック、公式なインスペクション等

kintone Café 関東女子会 Vol.1 開催報告

こんにちは。またしても技術部 對馬です。

1月28日にkintone Café 関東女子会 Vol.1が開催されましたので、そのご報告をさせていただきます。

kintone Caféとは

まずkintone Café についてですが、これは「業務アプリ開発プラットフォームであるkintoneのユーザーコミュニティ」であり、全国各地に支部を設けユーザーが自発的に勉強会を開催しています。

詳細は公式サイトをご覧ください。

kintonecafe.com

関東女子会支部設立

そして今回新たに「関東女子会」という支部を発足しました。

私はこの支部の運営をすることになりました。

立ち上げの詳細はまた機会があったら書こうと思いますが、関東女子会の目的として「女性が活発になれる勉強会」をあげ、ハードルが低く参加者全員が気軽に発言できるようにしています。

女子会の活動はクローバにまとめてありますので、こちらも見てみてください。

kintonecafegirls.qloba.com

またクローバPAGE 利用事例に関東女子会を取り上げていただきました!

company.qloba.com

記念すべき第1回開催

f:id:ytsushima:20170207153742j:plain 第1回目ということもあり、内容はkintoneの紹介をメインにしました。

  • kintone紹介 (サイボウズ 李さん)

  • kintone活用事例 (アプレッソ 對馬)(It’s me !)

  • kintone活用事例 (サイボウズ 三宅さん)

  • kintoneデモ (ジョイゾー 四宮さん)

女子会ではみんなでわいわいしながらkintoneについて話していきたいと思ったので、

当日はお菓子やドリンクを用意しました。

f:id:ytsushima:20170207150438j:plain

食べながら飲みながらセッションを聞いてくれたらなぁと思っていたのですが、

お話が始まると参加者の皆さんは真剣な表情で前を向いて聞いていました。

f:id:ytsushima:20170207154259j:plain

もっとゆるい感じでいいのに…と思う反面、

実際どのお話も興味深く真剣に聞きたくなる内容でした。


f:id:ytsushima:20170207151416j:plain ▲李さんからのわかりやすい製品紹介

f:id:ytsushima:20170207151934j:plain ▲私も活用事例を紹介しました

弊社ではハンズオンセミナーの委託企業さんとの情報共有に活用していたり、

ハッカソンでの環境管理に活用したりしています。

活用の中でも、アプリの開発のしやすさがkintoneの魅力だと感じたので、そのご紹介をしました。


f:id:ytsushima:20170207152051j:plain ▲三宅さんからサイボウズ社内での活用事例

f:id:ytsushima:20170207152202j:plain ▲四宮さんからは質問疑問をその場で解決!な相談コーナー

f:id:ytsushima:20170207152507j:plain ▲関西女子会運営の池上さんからJAWS Daysのお知らせ

そしてASCIIさんに「今回の開催と立ち上げについて」を取り上げていただきました! こちらも併せてご覧ください。

ascii.jp

さいごに

f:id:ytsushima:20170207153119j:plain

参加者の皆さんに聞いたところ、やはり他の勉強会は「内容が難しそう」というような理由で参加してこなかったという意見がありました。

「男性がいると発言がしにくい」などもあり、そうなると親しみやすい「女子会」という括りも必要なのかなと思います。

また、発表者でも「今日は気楽に発表できます!」と言っていた方もいて、確かに心なしか運営もしやすかったので、参加者にとっても運営にとっても「活発に自分の意見を言える場所」となることが実感しました。

考えなければいけないことは多々ありますが、定期的に開催することをまずは目標に、頑張っていこうと思います。

Vol.2も近々開催予定ですので、みなさん宜しくお願いします!

APIStudy#4 開催報告

皆さんこんにちは。 技術部 對馬です。

APIのベストプラクティスを考える会「APIStudy」の第4回が開催されました。

今回もとても濃い内容となりましたのでご報告します。

前回の第3回開催報告はこちら。

appresso.hatenablog.com

去る1月24日に開催された第4回は、株式会社フロムスクラッチさんのオフィスにお邪魔しました。 f:id:ytsushima:20170203172810j:plain

また今回も市川さんにグラフィックレコーディングをしていただきました。

どんな仕上がりになるのか!楽しみです。(すっかりファンになりました私です) f:id:ytsushima:20170203172740j:plain

第1部

フロムスクラッチさんLT

まずはフロムスクラッチの井戸端さんからAPI連携開発における共通化についてお話がありました。 f:id:ytsushima:20170203172837j:plain

マーケティングプラットフォームであるB→Dashでは、データ取得のため様々なサービスとAPIで連携をしています。

しかし連携するサービスごとにAPIの仕様が異なり、ひとつひとつ開発をしていたが辛いので、昨年、共通化できる部分はマスタを作成し、サービス固有のところだけを開発できるように取り組んだそうです。

f:id:ytsushima:20170203173147j:plain

共通化することで、「新しい連携においてもマスタの追加だけで良くなった」「開発しやすくなった」「外部にも頼みやすくなった」とたくさんの嬉しいことがあったとおっしゃっていました。

有志LT

今回は初めて会場企業さん以外の方にもLTをしていただきました!

株式会社KUFU 芹澤さんから「RESTfulなAPIにおけるファイルアップロード」についてです。

f:id:ytsushima:20170203173259j:plain

SmartHRという労務管理ソフトウェアの開発をされていて、前職含めてWeb API関連のお仕事ばかりで、API漬けの人生を送られている芹澤さん。

そんな中で、ファイルの入力についてのベストプラクティス模索し、今回はその調査結果をご紹介していただきました。

インプットの方法について。

インプットは以下2つが主流パターン

  • multipart/formdata

  スタンダードな規格なので便利!

  • Base64

  ファイルのデータをエンコードして文字列型として扱う。

データの保存方式について。

  • リソース紐付けパターン

  特定アトリビュートに対してファイルデータを直接送る方法。

  • 汎用ファイルアップロードパターン

  ファイルアップロードのエンドポイントを作ってファイルを送る方法。

f:id:ytsushima:20170203173427j:plain

それぞれ2つの方法を、APIの性質やファイルの用途で適切に組み合わせることがベストプラクティス!だそうです!!

質問タイム

LT発表者に対して質問をする時間。

質問というより全体のディスカッションタイムみたいになっています。

f:id:ytsushima:20170203173517j:plain 活発に意見が飛び交っていて、チーム分けの前のこの時点でもう楽しそうです。

第2部

チームに分かれて好きなテーマをもとに話し合います。

今回のテーマは以下3つです。

  • APIの有効無効の通知、取り扱い
  • パラレルで叩くAPIの設計思想
  • エラーコード(発生原因による切り分け)

ディスカッション・発表

f:id:ytsushima:20170203173811j:plain

皆さん熱く討論をしています。

少人数でのディスカッションなので、じっくり話すことができます。

f:id:ytsushima:20170203173629j:plain

APIの有効無効の通知、取り扱い

f:id:ytsushima:20170203173843j:plain 企業にとって通知は面倒なので、だったら作ればいいじゃない!ということで kintoneのWebhookを利用して通知する機能を新たに開発すればいいという提案をされていました。

ディスカッションで新機能を提案しているのは新しいですね…。

ちなみに5月リリースだとか…?技術者はAPI Study参加者だとか…? 楽しみですね。

パラレルで叩くAPIの設計思想

f:id:ytsushima:20170203173919j:plain

APIによっていろんなものをとってこようとしたときに、何か処理が発生してしまいます。

そして複数APIを誰がハンドリングするのかという問題がありますが、 これは、クライアント側でだときれいではないのでサーバー側で一枚ファサードみたいなもの、APIの前にAPIを作ってそこで全て処理していくと綺麗にいくのではないか、という結果になりました。

しかし、となると「サーバーサイドでなんでもかんでもやることになる問題」も気にしなければならないど、バランスの良い設計について話し合うにはもう少し時間が必要のようです。

ただ、ファサード入れることでアプリからアプリを解析されたときにエンドポイントがバレて攻撃を受けるリスクを少し低減されるようになると良いと、メリットもあることをお話いただきました。

エラーコード(発生原因による切り分け)

f:id:ytsushima:20170203174240j:plain エラーコードだけでもなく200番台の話も。

AWS S3で分割アップロードするときは、とりあえず200を返すらしいです。

AWSがそうなら長いものには巻かれましょう!

また、複数返したいのなら207でカプセル化してボディで詳細とかもありではないかという意見も。

そして、ステータスコードにはいろいろなものがあるらしく…、

418  I’m a teapot (ティーポットです)

451  Unavailable For Legal Reasons 法的理由により利用不可能

402  Payment Required お金払ってないからあなたは使えない!

「402はすごい使ってみたかったから使いました!」by松本さん

今後のステータスコード発掘に期待です。

最後に

まずは今回のグラフィックレコーディング!

f:id:ytsushima:20170203174419j:plain やはり素敵ですね。

1部と2部、今回はかなり濃厚な内容でしたが、見事まとまっています。

ここは私の感想ですが、 APIStudyは回を重ねるごとに内容の濃さが比例して増しているような気がしています。

それが私はとてもうれしいです。開催報告は大変ですが。

そして!

APIStudy #5 の申込みがすでに始まっています!

そしてもうたくさんの方にお申込みを頂いておりますありがとうございます!!!

じっくりAPIについて語りたい方は、ぜひお越しください。

以下connpassページからどうぞ。

apistudy.connpass.com

API愛が濃ければ濃いほど喜ばれる、そんな勉強会です。

皆さん、宜しくお願いします。

APIStudy#3 開催報告

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

またしてもエンジニアブログにお邪魔して、開催報告させていただきますお邪魔します。

毎月順調に開催されているAPIStudyは、12月20日に第3回目を迎えました。

第2回の開催報告はこちらからご覧いただけます。

appresso.hatenablog.com

第3回では弥生会計の弥生さんにオフィスをお借りしました。 f:id:ytsushima:20161222171253j:plain

今回はなんと、ホワイトボードにグラフィックレコーディングを行いました!

担当は市川さんです! ありがとうございます! f:id:ytsushima:20161222171334j:plain

どんな仕上がりになるのでしょうか。 写真を本記事のまとめに掲載しますので、楽しみにしてください!

余談:運営挨拶

毎度、写真を撮ると目が閉じているので「今回は目をしっかり開けて話します」と、はじまる前にフラグを立ててしまったAPIStudy運営である脇野。 f:id:ytsushima:20161222174357j:plain フラグ回収おめでとうございます。

第1部:弥生さんLTタイム

まずは弥生さんによるLT「デスクトップ製品とのマスタデータ同期の苦悩」です。

f:id:ytsushima:20161222173427j:plain

APIエコノミー YAYOI SMART CONNECTについて。

SMART CONNECTでは弥生シリーズに様々なデータを取り込め、弥生だけでは実現できないところをカバーし、会計処理をシンプルにしていくことができます。

f:id:ytsushima:20161222173455j:plain

また弥生会計にはデスクトップとオンラインがあり、双方のデータ同期が必要です。

その仕組みには何万回もテストを要するが、地道なテストの積み重ねが品質につながるのだとお話しいただきました。


そんな弥生さんの切なる願いがこちらです。 f:id:ytsushima:20161222173532j:plain(NOT 弥生会計株式会社 YES 弥生株式会社)

ディスカッションタイム

今回は以下4つのグループが作成されました。

  • セキュリティ・例外処理について
  • 社内用APIならではの手抜き、問題点
  • バージョンアップしたら長く使うAPIのライフサイクルについて
  • フェーズごとのテストの考え方

f:id:ytsushima:20161222174549j:plain

皆さん話したいグループに入り、レッツ発散!

共有タイム

ディスカッションした内容を最後は全体に発散してもらいます。

セキュリティ・例外処理について

f:id:ytsushima:20161222174716j:plain

メンバーの3名のうち2名がサービス基盤をリプレイス中で、その話などをされていました。

侵入テストの際は『ホワイトハッカー』がよいらしく、実際に利用された方も。

見落とし箇所に気づくことができ、安心ができるようです。

社内用APIならではの手抜き、問題点

f:id:ytsushima:20161222175241j:plain

プロダクトは逆三角形の系図で表されます。

f:id:ytsushima:20161222175051j:plain

手抜きと呼ばれる社内用APIには「スピードアップ」、「エンジニアの裁量が上がる」というメリットがある、という結果になっています。

APIのライフサイクルについて

f:id:ytsushima:20161222175312j:plain

長く使うAPIは正しいの?という問題提起に対して、ディスカッションした結果

「長く使うではなく成長に合わせてAPIもバージョンアップしていくべきじゃないか」とまとめていました。

フェーズごとのテストの考え方

f:id:ytsushima:20161222175349j:plain

APIどうこうより、弥生さんのテストはどう行われたかについて話し合っていました。

ユニットで品質を担保できるか、そこでどれだけの認識齟齬をなくしていくかをターゲットにしてテストをしていたそうです。

最後に

f:id:ytsushima:20161222175800j:plain

悩みを話したり、共通の話題を見つけ盛り上がったりと、今回もにぎやかなワークショップとなりました。

そして!グラフィックレコーディングは最終的にこうなりました!

第1部 f:id:ytsushima:20161222175437j:plain

第2部 f:id:ytsushima:20161222175517j:plain

これをその場で書いているなんて驚きですよね。

まるで魔法のようです!

このグラフィックレコーディングがわかりやすすぎて、こちらを載せるだけで今回の開催報告は済んだのでは…と震えています。

そして!!!

な、な、なんと既に第4回の開催が決定!

次回はフロムスクラッチさんにお邪魔します!

apistudy.connpass.com

お申込みお待ちしております。

ではまた来月! 皆様、良いお年を&良いAPI設計を。