DataSpiderがクラウドサービスに! 遂に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」について開発者が語る
2016年12月8日に発表されたクラウド型データインテグレーションサービス「DataSpider Cloud」。2017年1月22日から提供が開始される本サービスは、豊富なデータ連携機能と高いユーザビリティを誇るデータ連携ツール「DataSpider Servista」が100%クラウドネイティブなiPaaSとして手軽に利用できるもので、今後の大きな活用の広がりが期待できる。
DataSpider Cloudは、DataSpider Servista(以下DataSpider)が持つ多彩なデータ連携機能が利用できるのはもちろん、クラウドサービス向けにチューンナップされたインストールレスNativeクライアント「Studio」を搭載。その軽快な操作性を活かしてデータ連携処理の効率的な開発が可能だ。
また、クラウドサービスとして運用するためのさまざまな運用機能も本サービス向けに開発されており、簡単にさまざまな設定や運用処理を行うことができる。
本サービスの開発を担当したのが、株式会社アプレッソと株式会社テラスカイの共同開発チームだ。DataSpiderの開発ベンダーである株式会社アプレッソ、そして先駆的なクラウド型データ連携サービス「SkyOnDemand」を展開してきたクラウドiPaaSリーダーの株式会社テラスカイ。フロントエンド、バックエンド、クラウド、データ連携など双方が持つ多様な分野の技術を持ち寄り、相互作用することによって本サービスの開発が行われた。
開発者から見たDataSpider Cloudとはどのようなサービスなのか? どのように開発が行われたのか? そして今後のDataSpider Cloudはどのような進化が待っているのか? アプレッソ・テラスカイの共同開発チームの開発者に話を聞いてみた。
取材・文:dstn編集部
(※) 本記事はアプレッソ Advent Calendar 2016 - Qiita 18日目の記事です
DataSpiderの「手触りの良さ」を「進化させる」、その思いで開発をした
まず、遂に発表されたDataSpider Cloudとはどのような製品なのだろうか? アプレッソ開発チームの細見氏はこのように語る。
「 DataSpiderの現在の最新バージョン4.0をベースに、テラスカイ社の「SkyOnDemand」を組み合わせて拡張した汎用的なクラウドサービスです。DataSpiderはExcelファイルやデータベースなどオンプレミスのシステムのデータ連携はもちろん、近年はAmazon Web Services(AWS)やセールスフォース、kintone、Azure、Googleなど様々なクラウドサービスとの連携アダプタ・トリガー機能も多く搭載しました。
その多種多様な連携機能をクラウド・サービスとして手軽に利用できるようにしたのがDataSpider Cloudです」(アプレッソ 細見氏)
▲DataSpiderに搭載された豊富なアダプタ・トリガー群で、ノンコーディングでさまざまなアプリケーションやデータベース、ファイルなど簡単に連携が可能だ
もともとDataSpiderは「On Cloud」への対応として、ブラウザ上で利用できる開発クライアントStudio for Webという機能があった。DataSpider CloudではStudio for Webをベースに、操作性をさらに高めたインストールレスなNativeクライアントのStudioが利用できるようになっている。
「従来のStudio for WebはSilverlightで実装されていました。ただしブラウザ上で動作させるために機能的な制限があり、またSilverlightのサポート終了も近づいているということも考慮して、DataSpider Cloudでは新しいプラットフォームでよりユーザービリティの高いクライアントを提供したいという思いがありました。
HTML5などさまざまな技術を検討した結果、WindowsのWPF(Windows Presentation Foundation)を採用したインストールレスのネイティブ・クライアントとして提供することにしました。」(アプレッソ 清水氏)
▲DataSpider Cloudに搭載されたインストールレスNativeクライアントのStudio(画面は開発中のものです)
さらにクライアントの刷新に加えて、「クラウドプラットフォーム」でより使いやすくするためのさまざまな改善が行われていると、アプレッソ開発チームの細見氏は語る。
「例えばDataSpiderのログはシステムを運用していくための重要な情報ですが、DataSpider Servistaではすべてのログを見るためにはOSのファイルシステムにアクセスする必要がありました。DataSpider Cloudではログを確認するための作業がStudio上ですべて行えます。またダウンロード後すぐにディレクトリやファイルを開くことができるようにし、一連のステップがストレス無く行えるようにしています。
DataSpider Cloudでは、従来のDataSpider Servistaにあった「手触りの良さ」を決して損なうことなく、「進化させる」という意気込みで開発しました」(アプレッソ 細見氏)
DataSpider Cloudの運用のために一から開発されたシンプルでモダンな管理画面。その操作性を体験してほしい
DataSpiderは企業内で使用されることを想定したパッケージ・ソフトウェアであるため、そのままではクラウド・サービスとしてリリースすることは不可能だ。テラスカイ社は先駆的に展開していたiPaaSサービス「SkyOnDemand」で培った技術を活かしつつ、さらにDataSpider Cloud向けに新機能を開発したとのころだ。テラスカイ開発チームの荒木氏は以下のように語る。
「テラスカイの開発チームではSkyOnDemandのクラウド・プラットフォームをベースに、DataSpider Cloud向けにさまざまな拡張や改修を行いました。Amazon EC2の仮想インスタンスの構築を始め、新しいクライアントの配布システムの設計・実装や、ユーザーが個別にパッチを当てる機能の実装などクラウドサービスとしてユーザーが必要になる機能をさまざまに実装しました。
より手軽に利用できるようになったDataSpiderを、ぜひこれまで以上に活用してほしいです」(テラスカイ 荒木氏)
パッケージ・ソフトウェアとクラウドサービスが大きく異なるのが、「バージョンアップ」の際の動作だ。パッケージ・ソフトウェアではユーザーが自身のオペレーションによってバージョンアップ作業を行うのが通例であるが、クラウドサービスでは一般的に自動的にバージョンアップがなされる。
ミッション・クリティカルなシステムの場合、この自動的なバージョンアップが動作に影響を与え、予期しない処理結果となってしまう可能性がある。これに対してもDataSpider Cloudは「プレリリース」という機能で対応しているとテラスカイの中山氏は言う。
「自動的なバージョンアップは、ユーザーが自身でバージョンアップ作業をすることなく最新機能が自動的に適用されるというメリットがある反面、未検証の新機能が適用されてしまうという懸念があります。SkyOnDemandから用意されていた「プレリリース機能」は、バージョンアップ適用後の動作をバージョンアップ前に検証できる機能です。これにより、十分に検証を行った上で新しいバージョンのDataSpider Cloudを適用することができます。」(テラスカイ 中山氏)
またクラウドサービスとして運用するために開発された管理画面は、DataSpider Cloudのためにテラスカイ開発チームが一から開発した新機能とのことだ。
▲連携サーバーやネットワーク・アクセスの管理ができる管理画面。通信量の確認など利用状況の確認も可能だ(画面は開発中のものです)
「DataSpiderをクラウドサービスとして運用するためには、連携サーバーやネットワーク・アクセスをより容易に管理することができるようにする必要がありました。そのために、我々のチームではStudioとは別に、管理画面を一から開発しました。とてもシンプルでモダンな作りを意識した画面設計となっていると思うので、ぜひ操作性を試していただきたいです」(テラスカイ 荒木氏)
データ連携のアプレッソとクラウドのテラスカイ。双方の相乗効果が製品に結実した
「データ連携」のアプレッソと「クラウド」のテラスカイという異なるバックグラウンド技術を持つ2社。この2つの開発チームの共同作業はどのように行われたのであろうか? アプレッソ開発チームの細見氏によると、「ミーティングを定期的に行い方向性を確認して進めていきました。技術情報を素早い共有はSlackで、課題管理をCybozu Liveで行いました」とのことだ。
ではそれぞれの担当はどのようなものだったのか? アプレッソ開発チームの細見氏はこのように言う。
「テラスカイ開発チームにはインフラ全般を担当していただきました。SkyOnDemandなどで培ったクラウドサービスの運用ノウハウは我々には無いものであり、絶大な信頼を持ってお任せしました。実際に、その深い知識には感服しましたね。またシステム・インテグレーターとしての手順を尽くした開発の進行は素晴らしいと感じました。
我々のアプレッソ開発チームは安心してDataSpiderエンジンの改良に全力投球することができました。このような明確な役割分けを行うことができたので、スピーディに開発を行うことができたと思います。」(アプレッソ 細見氏)
このような流れで開発されたDataSpider Cloud。2つのチームが相互に刺激し合い、苦労しながらも良い相互作用が発揮されて開発が進んだようだ。テラスカイの荒木氏はこのように語った。
「苦労もありましたが、学ぶこともとても多い開発でしたね。アプレッソ開発チームのアイディアの創出、それを検証・実現まで素早くやってしまうフットワークの軽さには感心しました。
開発作業の中でデータ連携のアプレッソとクラウドのテラスカイという2つのノウハウを持ち寄り、相乗的な効果を得ることができ、それがDataSpider Cloudという製品に結実していると思います」(テラスカイ 荒木氏)
「使い勝手の良い」クラウドサービスとは? 開発チームが挑んだ難問
DataSpiderとSkyOnDemandというベースとなる製品があったとはいえ、「クラウドサービス」をリリースするというのは当然のことながら容易なことではないはずである。具体的にどのような課題があり、どのように克服していったのかは、開発者としては非常に興味深いところである。
まずはテラスカイの中山氏に聞いてみた。
「DataSpiderエンジンとクラウド基盤という明確な役割分担は非常に効率的ではあったんですが、やはりそこで問題になるのはシステム統合。予め準備をしてきたとはいえ、プロジェクトの終盤に統合を行うことになり、問題解決のスピード感が求められました。
しかし共同開発チームの得意な技術分野からアイディアを出し合い、我々だけでは実現できなかったアプローチでスピーディに解決することが無事できてほっとしました。共同開発の強みが活きたところですね。」(テラスカイ 中山氏)
また、前述したバージョンアップ前の「プレリリース機能」は特に今回の開発をするあたってはハイライトとなったようだ。
「SkyOnDemandでも同様の機能は用意していたのですが、DataSpider Cloudでは基盤の再設計から行ったためその仕組みがそのままでは適用できず、対応方法に悩みました。しかし我々はこのような機能はクラウドサービスに一般的なものであり、ユーザーに信頼していただくクラウド・サービスの使い勝手としては必須だと考えています。苦労はしましたが、DataSpider Cloud上で問題なく機能を利用できるように無事対応できました。」(テラスカイ 荒木氏)
アプレッソ側では、DataSpider Cloud向けにプラットフォームを刷新したStudioの実装がやはり最大の焦点となった模様だ。特に「SilverlightとWPFの違いを1つ1つ対応していくのが大変でした」とアプレッソの清水氏は言う。
「同じC#のコードではあるんですが、大きなところから小さなところまでさまざまな挙動や見た目の違いがありました。例えばリンクボタンやフォームなどのコントロール・コンポーネントを自作し直したり、画像がなぜか大きくなったり・・・。ドキュメントに無い動作もあったりして、嵌ってしまうことも多くありましたね。1つ1つ検証しながら潰していきました。大変な作業ではありましたが、その結果より使いやすく、これからも長く使えるクライアントに仕上がったと思います。」(アプレッソ 清水氏)
また、データ連携処理の開発効率に直結するクライアントだけに、「使い勝手」に大きなこだわりをもって開発を行っていたようだ。
「従来のStudio for Webに比べ、大きくユーザビリティは向上していると思います。まずサクサクと動く軽快な動作感を感じていただけると思います。またさまざまなキーボード・ショートカットが使えるようになり、Ctr+Sで保存、F1キーでヘルプ画面表示など、スピーディな一連の操作が可能です。その他にもさまざまな工夫がしているので、ぜひその使い勝手を体験していただきたいですね。」 (アプレッソ 細見氏)
双方の開発者の言葉に「使い勝手」というキーワードが共通していることが見てとれる。いかにユーザーに「良い使い勝手」という価値を届けるか。アプレッソとテラスカイの開発者はその難問に挑み、試行錯誤の結果辿り着いた解が、DataSpider Cloudにあるようだ。
DataSpider Cloudの未来、「クラウドサービスのあるべき姿」への進化へ向けて
いよいよ提供日の2017年1月22日が近づいてきたDataSpider Cloud。現在の心境について聞いてみると、テラスカイの荒木氏は「大きな達成感がありますね」と笑顔で語る。
「もともとSkyOnDemandはDataSpiderのOEMだったんですが、その機能がDataSpiderの一部になるということは私にとってとても感慨深いです。テラスカイは創業時より「クラウド専業」を掲げて事業を展開してきたんですが、それが正しかったことが裏付けられるようで、とても嬉しいです。」(テラスカイ荒木氏)
その一方で、今回のリリースでは対応できなかった機能に関してアイディアが溢れているようだ。テラスカイの中山氏はこう語ってくれた。
「現在はご利用申し込みから実際のご利用までに少しお時間をいただいてしまうことがあります。これをもっと自動的に素早く提供できるようにしたいです。また、SkyOnDemandでは出来なかった機動的なアップデートや、独自アダプタの提供などやりたいことは沢山あります。 クラウドサービスのあるべき姿に進化させたいですね。」(テラスカイ 中山氏)
アプレッソ細見氏も、Studioがブラウザの制約から開放されたスタンドアロンのクライアントになったことで、「一定のユーザビリティ向上は果たせた」としながらも、さらなる「手触りの良さ」の向上について意欲を燃やす。
「まずは"できなかったことをできるようにする"ということを優先して今回のプロジェクトは開発を行いました。まだまだ自分としては、「クラウドサービス」だから提供できる価値へむけて進化すべきところが多くあると思っています。また、Undo/Redoなどクライアント・アプリケーションとして必要な機能の搭載がまだ不完全であり、そのような「手触りの良さ」を継続して取り組んでいきたいと考えています。
ロードマップではv1.1では多言語対応・Thunderbus(オンプレミス連携)対応、さらにv2.0も計画されています。今後も足を止めることなく加速して、DataSpider Cloudを立派なサービスに育てていきたいという思いがあります。」(アプレッソ細見氏)
▲DataSpider Cloudのロードマップ。v1.1、そしてv2.0に向けてさまざまな新機能が計画されている
DataSpiderをこれまで活用してきた人にも、これから使用してみたい人にもDataSpider Cloudのメリットは大きい
DataSpider Cloudは、2017年1月22日にリリースされ、提供が開始される。開発者にユーザーに使っていただくリリース日は、不安とともに大きな楽しみであるはずである。どのようなユーザーに使っていただきたいかについて聞いてみた。
「データ連携ツールの導入をご検討されていて、自社でサーバー管理をすることが難しい方には、クラウドサービスの利点を活かしてぜひDataSpider Cloudをご使用いただければと思っています。DataSpider Cloudなら導入の手間なくどのような製品かを体験することも出来ます。
また既にDataSpiderを導入されている方でも、バージョンアップ作業が自動的に出来たり、コンピューティングリソースの拡張により規模に応じた利用プランでご利用ができたりと、大きなメリットがあると思います。」(テラスカイ 荒木氏)
「DataSpiderというデータ連携基盤がクラウドサービスになったことにより、すべてクラウド上でデータ連携処理を完結させることが可能になりました。特にデータがクラウド上にある場合は、オンプレミスにデータ連携基盤を置くことなく100%クラウドで管理できるということは大きなメリットだと思います。ぜひこれまでDataSpiderを活用してきたユーザーにもそのインパクトを体験してだきたいですね。
また、これから購入を検討していただいている方にも、DataSpiderの使い心地をすぐに体感していただくことができるので、ぜひオススメしたいです」(アプレッソ 細見氏)
▲DataSpider Cloudが提供する価値として、「Fully-managed」・「Ease of use」・「Elastic」が挙げられている
DataSpider Cloudというこの新しいクラウド型インテグレーションサービスは、「データインテグレーションにアジリティを」というキャッチコピーの通り、「アジリティ=敏捷性」が1つのテーマになっている。これまでDataSpiderを活用してデータ連携をしていた方にも、これから使用しようという方にも、その「アジリティ」は絶大な効果をもたらすようだ。
いよいよ2017年1月22日に世に解き放たれるDataSpider Cloud。ぜひその「アジリティ」を体感してみてほしい。
(※) 本記事はアプレッソ Advent Calendar 2016 - Qiita 18日目の記事です
CSPO 研修を受けてわたしたちのスクラムについて思うこと
アプレッソ開発部の佐々木です。
開発部のマネージャーをやりながら、アプレッソの主力プロダクトである DataSpider Servista のプロダクトオーナーを担当しています。
本記事は、Appresso Advent Calendar の 15 日目の記事です。
先月、Odd-e Japan の認定スクラムプロダクトオーナー研修を受講してきました。
研修は 3 日間で行われ、スクラムの概要やスクラムにおけるプロダクトオーナーの役割、然るべき振る舞いなどを学んできました。この研修の中で、DataSpider Servista の開発チームが実践しているスクラムに対して多くの気づきがあり、この記事ではその気づきを紹介していきたいと思います。
アプレッソが現在実践しているスクラムについては、Appresso Advent Calendar の 2 日目、3 日目で詳しく紹介されていますので、そちらを読んでいただければと思います。
目次
スクラムにおけるプロダクトオーナーの役割
スクラムにおけるプロダクトオーナーは、プロダクトのビジョンを明確にし、チームの ROI を最大化させることに責任を持つ役割になります。
プロダクトのビジョンは、市場に対してプロダクトが目指す方向性のことで、その方向性をチームに示すためにプロダクトオーナーは首尾一貫した決断力と確かな情報収集力が必要だと思います。
チームの ROI はプロダクトのビジョンに従ってチームが具現化した価値とそれにかけたコストの割合のことで、その割合を最大化することがプロダクトオーナーの責任です。
プロダクトバックログ
プロダクトバックログとは、プロダクトの要件を一覧で見える化したものです。 プロダクトバックログはプロダクトオーナーとチームの持ち物ですが、プロダクトバックログアイテムを書いてそれぞれのアイテムに優先順位を付けるのはプロダクトオーナーの仕事です。
INVESTなプロダクトバックログアイテム
プロダクトバックログアイテムを書く上で意識していることが「INVEST」です。INVESTとは、良いとされるプロダクトバックログアイテムの特徴を表した以下の単語の頭文字です。
- Independent (依存しない)
- Negotiable (交渉可能)
- Valuable (価値がある)
- Estimatable (見積り可能)
- Sized Right/Small (手頃なサイズ / 十分小さいサイズ)
- Testable (テスト可能)
Independent
プロダクトバックログアイテムそれぞれが単独で成立している、つまり他のプロダクトバックログアイテムとの依存関係が排除されているということです。プロダクトバックログアイテムに依存関係があるとチームの見積りが難しくなるだけでなく、作業効率にも悪影響を及ぼします。
Negotiable
プロダクトバックログアイテムの内容に対してチームが交渉可能なことで、プロダクトオーナーが決めたことが絶対ではないということです。交渉の余地がないとチームにとって自由で柔軟な発想がしづらくなるでしょう。
Valuable
プロダクトがターゲットにしている市場に対して受け入れられること、つまりビジネス価値があるということです。プロダクトオーナーの妄想でビジネス価値の無いプロダクトバックログアイテムを作ることは、チームの成果を台無しにしてしまう裏切り行為と言えるでしょう。
Estimatable
プロダクトバックログアイテムの内容が見積り可能ということです。見積りが難しい内容になっていると、スプリントプランニングの際、チームがタスクを見積ることが困難になり、それだけ見積り作業に時間が取られることになります。見積りしやすいプロダクトバックログアイテムを作ることは、チームのコスト削減の観点からも重要です。
Sized Right/Small
プロダクトバックログアイテムがチームにとって手頃なサイズ (十分小さいサイズ) になっているということです。プロダクトバックログアイテムのサイズが大きいと、見積りが難しくなるだけではなく、不確実性やリスクが多く含まれている可能性がある状態になります。この状態だとチームはスプリントプランニングに多大な労力をかけることになり、ベロシティを上げることが困難になります。
Testable
テストが可能になっているということです。テストが可能になっているということは、チームにとって自分達の作業範囲や完了基準を明確にできるという点で重要です。
Independent と Sized Right/Small の関係性
ここで、Independent を重視して依存関係を排除した結果、Sized Right/Small が十分でなくなるケースが考えられます。このような場合は、小さく分割したプロダクトバックログを後からまとめることは簡単だけど分割するのは手間がかかるので、Sized Right/Small を重視してサイズは小さくしておくことが望ましいと考えます。
プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分
上記の特徴を意識してプロダクトバックログアイテムを書く場合、現状の私だと数分から長いときだと数時間程度かかることがあります。 ただし、認定スクラムプロダクトオーナー研修の中で講師の江端さんが言っていたのが
プロダクトバックログアイテムを書くスピードは 1 つにつき 1 分
ということでした。
これを聞いたときは、できるイメージがまったく浮かばず呆然としてしまいましたが、現状プロダクトバックログアイテムを書く時間がかかっている理由を考えてみると、プロダクトバックログアイテムを書く際に既存機能の動作を確認したり、アイテムのサイズが想定よりも大きくなって分割したり、曖昧な表現を修正したりと、実に試行錯誤しながらやっていました。
情報収集の大事さ
そのような状況になる大きな要因として、「情報収集が足りない」ことが考えられます。
持っている情報が足りない状態で書こうとすると時間がかかるわけで、十分に情報を持ったうえでプロダクトのビジョンが明確に整理されていれば、それを文字に起こすのはそう時間はかからないはずです。
他にも
情報収集が足りないことがチームに対して良くない影響を与えるケースも考えられます。
それは、チームからプロダクトオーナーへの質問に対しての回答が遅くなるということです。スプリントの中で、プロダクトオーナーはチームから質問を受けることが良くあります。その際、プロダクトオーナーが持っている情報が不十分だと、誤った回答をしてしまう、その場で回答を探るような議論が展開されてしまう、プロダクトオーナーが持ち帰って回答までに時間を要してチームの作業が止まってしまう、というようなことが考えられます。
プロダクトオーナーはチームに対して満足のいく回答ができるよう十分な情報収集を行い、質問に対する回答までの時間を短くすることを意識する必要があります。さらにそこから発展させて、チームからの質問回数を減らしてチームが開発作業に集中できるようにすることも重要だと考えます。
プロダクトバックログはプロダクトオーナーの腕の見せどころ
プロダクトオーナーにとってプロダクトバックログとは腕の見せどころで、とにかく数多くプロダクトバックログアイテムを書くことで良くなっていくと講師の江端さんも言ってました。
チームにとって作業しやすい手頃なサイズであること、誰が読んでも同じように理解できる受け入れ条件になっていること、優先順位がつけられていること、これらの条件が揃った一貫性のあるプロダクトバックログを作ることによって、チームの ROI 最大化に貢献できると考えます。
プロダクトオーナーは誰よりも多くプロダクトを触る
プロダクトオーナーは誰よりもプロダクトを使い倒して、その良し悪しを把握している必要があると思います。
しかしながら、10年以上今のプロダクト開発に携わってきて現状プロダクトオーナーの立場である私は全てを把握できていません。その理由は、「プロダクトを触れていない」ことが大きいと思います。
スプリントの中で積極的にプロダクトを触る
スプリントを開始した当初は、プロダクトオーナーである私はプロダクトを触らずにプロダクトバックログアイテムに定義された受け入れ条件を確認していました。
プロダクトを動かさずにどうやって確認できるのか?
それは、スプリントレビューの場でチームによるデモで確認していました。
しかし、スプリントレビューは、スプリントの成果をチームが発表し、プロダクトを改善するためのフィードバックを得る場です。チームの成果が受け入れ条件を満たしているかどうかは、スプリントの中でチームが作業を完了したタイミングでやるべきです。そのタイミングでやることでチームは成果に対して素早いフィードバックを得ることができます。
スプリントレビューでチームにデモをやらせるのはプロダクトオーナーの怠慢で、スプリントレビューで本来やるべきことを阻害していることに気づきました。
プロダクトオーナーはスプリントの中でも積極的にプロダクトに触ることが重要で、その土台となるのは積極的にチームに関わっていくマインドを持つことだと思います。
「完了」の定義 (Done と Undone)
スクラムでは、作業の完了についてスクラムチーム全体で共通理解を持ち、透明性を確保するためにプロダクトのリリースまでに必要なすべての作業を一覧にして見える化します。これを「完了の定義」と言います。完了の定義は、チームが毎スプリント必ず担保する作業を「Done」、担保できない作業を「Undone」としてグループ分けします。
アプレッソのスクラムで Done に分類されているものは、例えば「コーディング規約に則っていることの確認」や「ユニットテストの作成および実施」があります。
一方、Undone に分類されているものは、「ヘルプドキュメントの作成」や「リリースノートの作成」があります。
Undone はプロジェクトが進むにつれて増えていく
Undone はいわば負債のようなもので、Undone を回収しないままプロジェクトを進めていくと Undone が増えていくことになります。
例えば、あるスプリントの中で一つの機能が実装されたとします。その機能のヘルプドキュメントを書くことはプロダクトをリリースする上では必要な作業ですが、Undone なのでスプリントの中では行いません。このような機能が毎スプリント実装されるとスプリントを重ねるごとにヘルプドキュメントの Undone が増えていくことになります。
スプリントが終わるまで Undone が回収されずに増えていくということは、つまりプロダクトのリリースに対してリスクが高まっていくことになります。
Undone は細かく回収する
Undone を増やさないためにプロダクトオーナーが打つ施策としては毎スプリントで「Undone は細かく回収する」ことになります。これは認定スクラムプロダクトオーナー研修で「呪文のように覚えろ」と言われた言葉で、今では私の耳から離れないフレーズになってます。
毎スプリント Undone を細かく回収するには Undone 自体がプロダクトバックログで管理されて、チームが見積り可能な状態になっている必要があります。Undone が残っていて、それをスプリントでどのように回収するかの責任はプロダクトオーナーにありますが、Undone を回収するのはチームです。
チームは生産性を向上させるという観点から、自律的に Undone の回収に取り組む思考が必要ですが、Undone の回収に取り組むためにも、まずはベロシティを安定させることが重要です。
プロダクトオーナーはそのようなチームの活動を支援するために、Undone をチームが扱いやすい状態で管理しておく必要があります。
終わりに
プロダクトオーナーという立場では、今回書いたことを踏まえてチームの成果を多くのお客様が価値として認めていただけるようなプロダクトを開発していきたいと思います。
一方で、開発部のマネージャーという立場では、組織の成長、プロダクトの成長の両方の軸から、プロダクトオーナーの育成や組織上の立場をどうするかなどについて、自分で何ができるか考えて行動していきたいと思います。このあたりの取り組みについては、今後記事として書いていけたらと思います。
最後に、昨日の記事にも書いてありましたが、Odd-e Japan の認定スクラムプロダクトオーナー研修はおすすめです。
re:Invent 2016 参加レポート
こんにちは、開発の田中です。
最近は HULFT IoT の開発や、エッジコンピューティングの研究開発なんかをやっています。
はじめに
本記事は、アプレッソ Advent Calendar 2016 7 日目の記事です。
先週ラスベガスで開催されていた AWS re:Invent 2016 に参加しておりましたので、その参加レポートを書いておこうと思います。
re:Invent は開発者向けのイベントで、開発者の方であれば得るものも多く、非常に刺激のあるイベントです。
読んでいただいた方がぜひ行きたいと思う記事になればと思います。
(現地レポートや、まとめ記事、新サービスを網羅するような記事ではありません。)
私は昨年も参加しましたので、昨年と比較してどうかという感想も書いていきたいと思います。
2 つの Keynote
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 がネットワークエッジに下りてきた感じです。
まだ実際に使ってみることができないし、詳しい情報も不明です。
ネットワークが不安定な場所にいるネットワークエッジで、常に安定してデータを送ることができない状況では、エッジはエッジで自立して活動し、ネットワークが繋がったらクラウドと情報を同期する、というような使い方を想定しているようです。
どこまで通用しそうなものなのか早く試してみたいですね。
また IoT プラットフォームとしての AWS をどれだけ簡単に素早く検証してもらえるかの工夫もありました。
その一つが AWS IoT Button と AT&T の IoT Starter Kit です。
AWS IoT Button はまだ日本では使用することができませんが、Amazon Dash Button でまずはユーザーとして使うことができます。
展示や日本人同士の交流
相変わらず展示会場は広大でした。
昨年は日本からは私達 HULFT の展示だけだったかと思いますが、今年は SORACOM 様、スカイアーチ様、富士ソフト様、サイボウズ様、mobingi 様など、多くの企業が挑戦に来ていました。
re:Invent にはジャパンツアーで 400 人 (くらい?) が来ていて、その方々が一同に集まる懇親会が開催されます。
ラスベガスというある意味隔離された場所で、しかも re:Invent 中という限られた時間という状況だと、日本にいるよりも濃いコミュニケーションが取れると思いました。
普段お会いすることが無いような方とも話すことができますし、re:Invent に来るメリットの一つはここにあると思います。
全体感
開発者はぜひ一度は行くべきイベントだと思います。
カンファレンスの開催の仕方を見ると、この人達は世界を動かしているなと本気で思いましたし、顧客のためにあらゆる手を尽くすと感じました。
自分も同じ土俵で勝負をしてるんだなと思うと、じっとはしてられませんよね。
というわけでみなさんぜひ一度は AWS re:Invent に行きましょう!!
おまけ
宿泊したホテル「ベネチアン」。
周辺のホテルは全部巨大で、歩いていると距離感がおかしくなります。
アメリカに来たのであればまずは肉を食わねば。
AWS Snowmobile 。
Keynote での初登場時は何のジョークかと思いました。
参考
前回の参加レポートはこちら
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
セッションの動画
JUnitを試してみる
アプレッソ品質マネジメント部の磯です。最近メインDAWをableton Live8 から Live9 へバージョンアップしようか悩んでいます(ニッチな話)。
ちょこちょことアプレッソ技術ブログにエントリを書かせていただいてますが、今回はAdventCalendarにも進出してまいりました。 5日目の記事になります。
ではまず自分語りから始めさせていただきましょう!!
自分語り
私はずっとQA領域でお仕事してきたわけなのですが、一口にQAといいましても現場により呼ばれかたは様々です。
- QA
- テスト
- 検証
しかし、実態は同じだったり異なったり・・・。
一般的にはQAというとプロセスについて着目した活動が多い印象があります。 一方テストというとシステムテストなどのフェーズ、GUIを伴った対象を動かして得た結果から品質を確認していくといったところでしょうか。
このあたりも現場によっては統合テストよりになることもあるかと思います。
ちなみにアプレッソにおける品質マネジメント部の業務としては、上記の一般的なQA/テストで行われる業務のハイブリッドとなっています。
テストの自動化
さて、今回はテストの自動化に絡んだお話をしたいと思っています。
以前より、わたしの生息するQA/テスト界隈でも自動化の波が押し寄せてきています。
Selenium Selenium - Web Browser Automation
Appnium Appium: Mobile App Automation Made Awesome.
かつては高価なプロプライエタリのソフトが主流だった中で、OSSも洗練され大きく利用されるようになってきました。
こういったものを利用することで、基本的なテストは自動化を行って、よりクリエイティブなテストは手動で行っていくということが実現できます。
また、これらはプログラマブルである以外にも、実際の操作を記録して再現するといった機能を有しています。
以前にこういったエントリを書きました。
単体テストの自動化がアジャイルな体制においての品質保証の土台として大きく貢献する、ということでした。
また、アプレッソではスクラムによる開発を行っていますが、野口からのエントリにもありましたとおり、機能横断的なチームという点では課題があります。
現状において、GUI上からのテストについては自動化を進めていますが、さらなるスピード感をもって臨機応変にQAしていくためにはさらに必要なのはなにか・・・。
そうだ! プログラミングを学んで単体テストにも手を広げていねば!と思い至りました。
(そもそも「コード書けんのかい!」というツッコミもありそうですが、職能的に書けることが必須ではないため、往々にしてそんな状態の人が多いのではないかと思われます。)
というわけで、私はそこそこおじさんなのですが、新卒社員の様にこつこつとJavaを学んでいるところなのであります。
JUnit はじめの一歩
前置きが長くなりましたが、JUnitを試してみましょう!
導入
Eclipse, IntelliJ IDEAなどメジャーなIDEにはあらかじめJUnitが付属しているため、あらためてインストールする必要はありません。
今回はEclipseを使っています。
新規メニューから「その他...」を選択するとウィザードが起動します。
たしかにJUnitテストケースが作成できますね!
つかってみる
今回は以下のような(かわいらしい)コードを使って単体テストを書いてみました。
入力値が偶数/奇数をチェックするクラス(hogehoge)およびテストケース(hogehogeTest)です。
入力値が2で割りきれる場合に「偶数です」、2で割り切れない場合に「奇数です」と文字列が返されます。
(なぜかはてなのスーパーpre記法がうまく働かなかったので、gistから貼り付けています。)
これを実行してみると、Eclipseの左ペインに結果が表示されます。
緑になりました!
さて・・・現状ではここまでですw
おわり
はじめの一歩というよりも、下駄箱から靴を取り出そうとしたくらいではありますが、俺たちの本当の戦いはこれからだ!マインドで日々精進していきたいと思っております!
(追記12/6: JUnitをJunitと記載していたのを修正・・むむ!)
わたしたちがスクラムのスプリント期間を 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章 コーディングとテスト」の反復指標について学んだことをアウトプットしたいと思います。
ではまた!