わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか
こんにちは、開発部の野口です。
最近メイン DAW を Cakewalk SONAR から PreSonus Studio One に移行しようかどうか検討中です。(ニッチな話)
本記事は、Appresso Advent Calendar の 3 日目の記事です。
昨日の記事の最後に、スクラムマスターの土岐からバトンを受け取ったので、今日は「1 週間スプリントのプランニング」について書きます。
目次
はじめに
私は DataSpider Servista の次期バージョン開発チームで、開発者をやっています。
昨日の記事で紹介したように、3 ヶ月前からスクラムによる開発を行っていて、スプリント期間は 1 週間に設定しています。
スクラムによる開発を始めた経緯や、スクラムによる開発の様子については、ぜひ昨日の記事をご一読ください。
この記事では、「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」について、その始まりから、実践、メリット、今後の課題についてお話ししていきます。
やる前に ― 与えられた状況と不安
「スプリント(イテレーション)期間を 1 週間にする!」という話を聞いて、「なるほど 1 週間か、いいね、それでいこう」とただちに思える開発者は、まだそれほど多くないと思います。
始めた頃の私たちもそうでした。
なにしろ、ほんの半年ほどまではこのようなプロセスで開発していたので、
「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 メンバ)が混在しており、スキルセットがかなり異なります。
この図を見れば、その背景をわかっていただけるかと思います。
▲前バージョンまでの開発体制。「開発チーム」と「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
開発チームとプロダクトオーナーが共に計画に満足したら、スクラムチーム全体としてコミットメントします。
閑話 : 紆余曲折について
私たちは、さまざまな紆余曲折を経て、今このプロセスで計画を行っています。
そして、これからもプロセスを変えていくでしょう。
スクラムにおいて、いやスクラムではなくても、チーム活動において、難しい課題に際して、チームとして紆余曲折を経ることは、おそらく必要です。
「うまいやり方」はあるでしょう。
しかし、それを読んだり聞いたりして、そのまま真似しても、うまくいかないと思います。「そのチームのやり方」になっていないからです。
結論が同じだとしても、チームとして紆余曲折を経て得た解決策は機能し、ただ輸入しただけの解決策は不完全にしか機能しません。
不思議ですが、それが人間の集まりというものなのだと思います。
こんなに苦労して、なにが嬉しいのか
▲スプリント中のスプリントバックログの様子。真ん中の「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 Coplien や Joe 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週間」について書きます。
はじめに
DataSpider Servistaなどのデータ連携製品を開発する弊社アプレッソ。開発部では最近、スクラム・アジャイルを取り入れた開発にチャレンジしています。
特に今年夏以降は、ガチで「スクラム」というものをやってみようという、ということで現在DataSpiderの次バージョン開発は、完全にプロセスも体制も含めて「スクラム」でやっています。
その中でいろいろな気付きがありました。書きたいことは様々あるのですが、特に「スプリント/イテレーションを1週間でやる!」=「1週間ずつ製品を開発する」という試みは、チームに予想以上の良い衝撃を与えた模様です。
- 自然なリズムの中で素早く開発できる
- 問題が早く見つかって解決が速くできる
- 集中すべきことに集中できて無駄な作業が無くなる
- 短いサイクルで改善し続けることができる
チームからはこのような声が上がっています。
「イテレーション/スプリントを導入する」ことによるメリットは様々な形で語られていますが、「その期間はどのくらいが最適か?」というのはあまり情報が多くなく、チームにとって悩みどころです。
我々のチームはイテレーション/スプリントを「無し」→「2週間」→「1週間」という3段階で経験して、
スプリント1週間が最強である
ということを深く確信した次第であります。
ということで、今回の記事では、この「1週間スプリント」にフォーカスして書こうと思います!
(※) このタイムボックスを一般的なアジャイル開発では「イテレーション」、スクラムでは「スプリント」と呼びます。2週間で行っているときはスクラムではなかったので本当は「スプリント」では無いのですが、混在している分かりにくいので以下は便宜上このタイムボックスを「スプリント」と統一します。
スクラムを「1週間スプリント」をガチでやり始めた経緯
ということで、まず「1週間スプリント」に至った経緯について簡単に書こうと思います。
もともと開発部では、開発フェーズ・テストフェーズが完全に分かれていました。各個人が基本的に自分の裁量で仕様策定・開発を行い、開発フェーズが終わったらテストフェーズに入りテストを行うという形です。
▲従来の開発イメージ図。開発フェーズ・テストフェーズが完全に分割されている
厳格なウォーターフォールほどフェーズが分割されているわけではありませんが、開発フェーズ・テストフェーズは完全に分かれていて「緩やかなウォーターフォール」といった趣でした。
これ自体はさまざまな経緯があってこの形になったんですが、製品規模が拡大するについてこのやり方での問題が明らかになり、「アジャイル開発」を模索し始めることに。この辺りの経緯は以前本ブログに書いたりしました。
で! 導入したのが「スプリントを2週間でやる」というもの。「必ずスプリントが終わったときにテストが完了したリリース可能な製品を作ること」というルールで、開発とテストが協働して製品を開発する「タイムボックス」での開発がスタートしました。
▲スクラム導入後。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日)、今日やるべきタスクがより明確になる |
▲2週間スプリントと1週間スプリントの違いのイメージ図。1週間だと終了までの見通しがはっきりしているため、緊張感を常に保ちつつ優先度を明確にしてタスクに取り組める
なぜ「1週間」だとより良いリズムが出来やすいのか?
なぜ「2週間」と「1週間」でこのような感覚の違いが出るのか? あくまで自分の考察なのですが、大きく以下の3つの理由ではないかと思っています。
- そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる
- ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい
- 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい
それぞれについて以下に説明します。
- そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる
我々現代人は、小さい頃から「1週間単位」で生活を行っています。そして物事を考えるときもこの単位を基本セットとして考えていると思います。 今日が金曜日だとして、
「先週の金曜日」何やりましたか?
と聞かれると、だいたい思い出せると思いますが、
「先々週の金曜日」何やりましたか?
と聞かれるとどうでしょう。より昔なので曖昧になるのは当たり前とはいえ、その期間以上に数十倍記憶が曖昧になると思います。
逆に未来で言うと、
「来週の金曜日」に何をやりますか?
「再来週の金曜日」に何をやりますか?
というのは、来週の方が数十倍イメージしやすいと思います。この生活の単位と「製品を作る」という単位を一致させることで、「このスプリント中での働き方」というのがものすごく具体的なイメージで作ることができるのではないか、と思います。
- ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい
「人間のワーキングメモリに保持できる情報は7±2個」ということが認知心理学の研究で実証されています。
この「7±2」というマジカルナンバーは、スクラムでは「チームの基本人数のルール」として使われたりしています。
「2週間」は営業日数「10日」になりますが、この日数はこのワーキングメモリから溢れています。そのため、それぞれの日でどのような動きをするか、というのを脳内でイメージするのは人間の認知能力の限界を超えていることになります。「1週間」の「5日間」はワーキングメモリ内で収まる日数であり、この「5日間」をどのように働いていくか、というイメージが脳内でしやすい、ということがあるのでは、と思います。
- 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい
何のこっちゃ、って感じだと思いますが、このリズムは重要です!
我々は「水曜スプリントスタート、火曜スプリント終了」というようにスプリントを組んでます。 これに従ってスプリントをこなすと、スプリント以下のような流れになります。
水 | 木 | 金 | 土 | 日 | 月 | 火 |
---|---|---|---|---|---|---|
計画 | 実行 | 実行 | 休み | 休み | 実行 | 実行・レビュー&振り返り |
1日を計画の日とし、2日実行して週末休み、そして残りの2日を頑張って終了、というサイクルになります。ちょうど実行の半分のところで休みがあるので、一旦休んだ後に残りを頑張ろう、という気になります。
また、月曜の朝がちょうど半分のところになるので、この日の朝会(我々のチームは9:45からやっています。スクラムでは「デイリー・スクラム」と呼びます)は「作戦会議」と位置づけています。ここでは、
- このスプリントはこのまま進んで完了できるか?
- 今の作業を止めて注力すべきタスクは無いか?
- 優先度の高いアイテムに注力すべきなのではないか?
などを検討します。これは週末にリフレッシュして頭をスッキリさせた後で話すのにちょうど良いタイミングで、休み明けに頭を起動させていくのと共に非常に良い機会になっています。
この流れはとてもスプリントのリズムに良い影響を与えているように思います。
ちなみに唐突ですが、上記のサイクルを太鼓にしてみましょう。
ドン・ドン・ドン・<休>・ドン・ドドン
こ、これは・・・我々はよく似たリズムを知っている・・・・!
ドン・ドン・ドン・<休>・ドドン・ドドン
日本古来に伝わる音頭のリズムだ! このリズムがつまり、製品(プロダクト)を踊(ダンス)させちまうのでは・・・
なんてことは無いと思います。
こういう思い付きで胡散臭いことを言う人に惑わされないように注意していきたいですね。
改善の機会が倍増し、改善アクションが試行錯誤できる!
話を戻します! 他のメリットとして、「ふりかえり・改善が素早くできる!」ということがあります。
2週間スプリント期でも「ふりかえり」という形でKPTを行い、スプリントを振り返って改善を繰り返していました。これも「1週間スプリント」により効果的な改善ができるようになった感じます。
その理由として、まず「ふりかえりの機会が2倍になった」ということが大きくあります。1週間動いてみてはふりかえることで、短い単位で軌道修正してプロジェクトを進めることができます。
また、先ほどの考察にもあったように「ふりかえるときに記憶が鮮明」ということも大きなメリットです。「2週間前にあったこと」は既に記憶が薄れかけているのですが、「1週間前」だと鮮明です(実際やってみると「1週間前」であっても忘れていたりということがよく起きる!)。この記憶が鮮明な状態でふりかえることで、より良いアクションを導くことができるように思います。
スクラムを実施するにあたってふりかえりの形式を変えたことも、良い影響を及ぼしているように思います。スクラムにおける「ふりかえり」は「スプリント・レトロスペクティブ」という名前でのMTGになるのですが、これのルールとして「次スプリントで生産性を改善するための具体的なアクションを1つ以上必ず決める」ということがあります。
▲スプリント・レトロスペクティブで次のスプリントで取るアクションについて検討中
このアクションは多少大胆であっても「とりあえず1週間改善案を試してみようぜ!」という感じで臆することなく気軽にアクションを試すことができます。2週間だと失敗したときの影響が大きいのですが、1週間だったら「試してみてダメだったらやめよう!」という感じで気軽に人体実験感覚で試すことができます。このアクションの取りやすさも「1週間」だからこそ、と感じます。
「1週間で製品を作る」ためにやったこと
ということでいろいろメリットはあるんですが、実際のところ「1週間」というのはその決定的な「短さ」故の大変さがあります。事実、我々のスクラムチームでやろうとしたときも「本当に可能なのか?」という疑問も当初はありました。
認定スクラムマスター研修で江端さんが研修の最初に強調していたことがあります。
スクラムをやることによって「生産性を4倍にする」などと謳う本もありますが、絶対にそんなことはありません。 もし生産性が4倍になるとしたら、チームが頑張ることによってのみ可能です。スクラムはそれを支援するフレームワークです。
ということで、我々のチームもこの短いスパンで製品を作り上げるため、プロダクトオーナー・スクラムマスター・チームのそれぞれが知恵を工夫を持ち寄って頑張っています。
具体的には、我々のスクラムチームでは以下のようなことを行って1週間のスプリントを行っています。
- プロダクトオーナーはプロダクトバックログのアイテムをできるだけ小さくしスプリントに収まるようにする。また受け入れ条件を明確にしてスプリント中の相談コストを低減させる
- チームはスプリントプランニングでタスクを1時間か30分まで細分化し、計画をより正確にする
- チームは開発・テストの流れをできるだけスムーズにするようにアイテムをテスト可能な単位にさらに分割して(「チェックポイント」と呼んでいます)、テスト開始までの時間を最低限にする
- スクラムマスターはCIによるビルド自動化やSlack通知などのシステムをメンテし、フローの無駄を省く。またスプリントのデータを可能な限り収集・見える化し、改善のきっかけを探す
などさまざまな方策を行っています。 (上記の1つ1つの項目はいろいろ掘り下げがいのあるテーマなので、別途取り上げたいと思います)
▲スプリントプランニング中の1コマ。ストーリーのタスク分解を徹底的にやっています。
これらのことをやり遂げて1週間のスプリントをこなす我々のチームを私は誇りに思います。と同時にまだまだ満足はできません。プロダクトオーナー・チームとスクラムマスターで協力しあい「スクラム」を組んで、さらに向上を目指したいと考える所存です。
で、結局スプリントの期間は何週間が良いの?
いろいろ書いてきましたが、しかしこれは我々のチームの話。結局のところそのチームでの「最強」の方法はそのチームで探すしかないわけであります。
その探索の一助としてスプリント期間を決めることについて参考になる書籍があるので紹介します。『スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-』です。
https://www.amazon.co.jp/dp/B01D4JHITO/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
この第6章に「スプリントの長さを決める」というズバリな章があります。
どんなチームにもピッタリ合う魔法のようなスプリントの長さはない。
という言葉から始まるこの章では、具体的なスプリントの長さの検討例から始まって、長さを決定する際に考慮する要素について解説しているのでとても役に立ちます。
特に最後の章では「スプリントの長さ決めクイズ」として、以下のような質問をしています。
プロジェクトの期間は?
顧客やステークスホルダーはフィードバックやアドバイスをどの程度できるか?
スクラムチームの技術的なスキルはどれくらいか?
これらの答えによって、最適な長さが点数で分かる一覧表があります。悩んでる方は試してみると参考になると思います。(ただし著者も「賢く使うこと」と注釈を付けている通り、これも絶対ではありません。
また、第12章「ストーリーやタスクを分割する」は「なぜスプリントは短い方が良いのか?」ということを分かりやすく説明しています。
この中の具体例で、「4週間のスプリント」でストーリーを完了させることができないスクラムチームが出てきます。「スプリントを5週間にすれば終わるんだけど、そうすべきか?」と悩むスクラムマスターに対して、XP(Extream Programming」の提唱者の一人でもあるロン・ジェフリーズはこうアドバイスします。
「スプリントを短くした方がいいよ」ロンは素っ気なく言った。 チーム一堂ぽかんとなったのに、ロンも気づいたと思う。
「聞き間違えか」と戸惑うチームにロンは、「なぜ短い方がいいのか」を具体的に説明します。その結果
「1週間だ。私を信じろ」
と1週間のスプリントへのチャレンジを促します。この辺の理由の詳細は面白く、かつ納得がいく話なのでぜひ本著で読んでみてください。「やっぱり一週間スプリントが最強だ!」と合点いくと思います。その他、ストーリーの分割方法や分割の指標についても参考になる情報が書いています。
終わりに
ということで「スプリント1週間」についていろいろと書いてきました。この「1週間スプリント」をやり始めてチームから
楽しい!
という声が上がることが多く、それが「最強」である最大の理由だなぁと思うところです。
恐らくアジャイル・スクラム開発に取り組んでるチームはこの「スプリントの長さ」についてはいろいろ意見を持っていると思います。我々のチームでの経験から考察してきましたが、ぜひ機会あればご意見をぶつけさせていただければと思います。
実は今回はテーマがぶれてしまうので詳細は書かなかったのですが、「スプリント計画時、タスクを30分~1時間まで徹底的に分解して見積りを行う」ということはこの「1週間スプリント」を構成する最重要要素だったりします。このスプリント計画(スプリント・プランニング)については、「チーム」の立場から開発部の野口が明日のAdvent Calendarで書いてくれるはず・・・! ですので、バトンを渡してこの記事を終わります。
楽しくより良い製品を素早く作っていきましょう!
アジャイル開発になったらQA担当者はどうなるの? 〜「実践アジャイルテスト」で学んだこと〜 その6
こんにちは、品質マネジメント部の磯です!
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその6になります。
前回は「第18章 コーディングとテスト」のうち、バグの取り扱いについて書きました。
今回のエントリですが、予定を変更して「第18章 コーディングとテスト」のうち、リグレッションテストについて学んだことを出力していきます!
リグレッションテスト
(P429 18.9 「リグレッションテスト」より)
ビルドを「緑」に保つ
プログラマはコードをチェックインする前にxUnit系の単体テストツールで「緑」の状態、つまりはテストが全て成功している状態にしておく必要がありますが、開発が進むにつれ何らかの要因で成功しない場合があります。 たとえば、ローカル環境では通っていたが、CIで毎ビルドする際には失敗してしまう・・・といったことです。こういった事態が発生した場合は、最も優先度をあげてビルドが成功するよう、修正することが必要です。
ビルドの失敗や、いま直している!というステータスを示すのに以下のような方法が例示されています。
- ビルドのあとに結果をメール通知する
- ぬいぐるみをビルドを壊した人の机においておく
- 失敗時に信号を点灯させる
- アンビエントオーブを使う
- GUIのビルド監視ツールを使う
私たちの現場ではJenkinsで状態がわかるようになっているので、そこからSlackでお知らせといった感じになっています。お知らせは人力なので自動化の余地ありだなと思いました。 それにしてもアンビエントオーブとは何だろうと思ったのですが、↓こういうのがあるみたいですね。
The Orbならわかるのですが・・・q(^^)p
ビルドを早くする
ビルドに対してはなるべく早くフィードバックしたいものですが、ビルドの時間が長すぎるとテスト実施までの時間も伸び伸びになってしまいます。 XPのガイドラインでは10分以内にビルドが完了するのが望ましいとされています。長時間かかってしまう場合はまずそこを目指しましょう。 著者は以下の方法を例としてあげています。
- データベースのアップデートを含むテストをはずす
- 単体レベルでの機能テストをはずす
- GUIのテストスクリプトをはずす
といったものです。これらは実施しなくて良いのではなく、別プロセスで行われるのが良しとされています。
リグレッション環境を作る
既存のリグレッションテストを自動化したり、新規に自動化されたリグレッションテストを追加するなどした際は、プロダクションコードと同じリポジトリでバージョン管理されるべきです。 また、追加するリグレッションテストは素早くフィードバックできるように選定する必要があります。
上記のように追加したリグレッションテストは開発を推進するものでなく、新しいバグを見つけるためでもありません。これらを実施する目的は予期せぬ変化やシステムの副作用を見つけるためです。
大きな視野を持つ
前述のように追加したリグレッションテストですが、これらを過信してしまうことも望ましくないとしています。場合によっては手動による探索的テストが適切であるという可能性も考慮して、視野を大きくもっておくのが良いでしょう。
まとめ
さて、今回のアウトプットは以上となります。
- 効果的なフィードバックをするために、適切なリグレッションテストを頻繁に実行できるよう、ビルドプロセスに組み込んでいく
といったところでしょうか。
次回予告
次回は引き続き「第18章 コーディングとテスト」の反復指標について学んだことをアウトプットしたいと思います。
ではまた!
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 を使うことで重要な機能を担当することもできます。また、その時点では仕事上関わりのないと思った人であっても、業界は狭いのでそのうち仕事上でも接点ができ、お互い力になれることが必ず出てくると思います。
ハッカソンに行こうか迷っている方は、是非新しい自分を探すために一歩踏み出していただきたいと思います。