■

ある現場のチームで「チームのコアタイム」について質問を受けたので、簡単に紹介したいと思います。

『スクラム現場ガイド』で、チームのコアタイムを紹介しています。チームメンバーが全員そろっている時間を、ルール(ワーキングアグリーメントの一部)として決めるというものです。フレックスタイムのコアタイムにも似ています。

コアタイムがあると、コミュニケーションが確実にできる時間がわかります。ミーティングの予定を立てるときとか、誰かに相談したいというときに、コアタイム内に設定すれば基本的には全員そろうので、個別の調整をしなくてすみます。特にチームが離れた場所で作業しているときに、時間が節約できるようになります。(リモートはもちろん、同じビルだけどフロアが違う場合など)

さて、このコアタイムは、単にルールとして設定すべきというものではありません。コアタイムを設定するには、なんらかの動機があるはずです。外のミーティングが多いとか、個人や家庭の事情で朝遅い・夜早い人がいるとか、時差があるとか(中国チームがいるなど)。時間とコミュニケーションに関してチームが問題を感じたときに、使えるソリューション(のひとつ)がチームのコアタイムです。

スクラムチームが用いる“ルール”はいずれも、なにかしらの問題に対する解決策として採用するものです。ルールがあるほうがいいから……というだけでは、ルールを導入する十分な理由にはなりません。問題に対する解決策である以上、結果も求められます。問題が解決しないなら、そのルールはやめて他の方法を考えたほうがいい。

コアタイムを設定するときには、全員が無理なくいられる時間の共通部分を取ります。子供のお迎えの日は17時までという人がいるなら、コアタイムは17時までです。朝が弱い人がいるなら、その人が確実に来られる時間がコアタイムの開始です。時間を問わず打ち合わせが急に入る人がいたら、おそらくコアタイムは解決策にならないでしょう。

チームとプロダクトの状況はどうか(透明性、見える化)、なにが問題なのか(検査)、どんな解決策をとるか(適応)、解決策は効き目があるか(次のループ)。ルールや施策を考えるときは、この全体の流れを常に視野に入れておきましょう。

■

スクラムガイドにある「リファインメントは開発チームの作業の１０％以下」という箇所について、疑問が上がっていました(Facebook上で。限定公開だったのでリンクは貼りません)。そこにコメントしたのですが、私の解釈は以下のようなものです。

リファインメントはいろんなやり方があるので、「開発チームの工数の10%」という解釈がほぼ近いと思っています(工数、作業量、エネルギー、許容量、できること、そこの言葉の捉え方はいろいろありそうです)。POとミーティングをしてもいいし、開発チームだけで相談してもいいし、定例化してもいいししなくてもいいし、開発チームタスクとして作業をしてもいいし、ミックスしてもいい。

2週間スプリントでリファインメント「イベント」を週1回実施して、スプリント前半のリファインメントでは調査タスクを発生させ、後半までに開発チームで調べておく、というチームがありました。このときはイベント(全員)＋調査タスク(担当した人)あわせて「10％以下」の対象になります。

別のチームでは、スプリント中に新しい急ぎのPBIが頻発するので、毎日１５分確保しておき、急ぎのPBIがある日は内容を調べて見積もるようにしていました。

たしかケントベックが言ってた、「新しいストーリーはホワイトボードに貼っておいて、メンバーは気の向いたときにそれを眺めて、見積もりポイントを封筒に入れる。何人分か集まったら、その平均(だか最大値だか)を見積もりとする」というのも、スクラムであればリファインメント作業になると思います。

リファインメントはプロダクトバックログの「すぐやるやつ」と「今後の見通し」を把握するためにやるので、チームやプロダクトによっていろいろな形になるようです。「10%以下」は、そちらにのめり込みすぎないような、またプロダクトオーナーがやるべきことをチームに押しつけすぎないような、バランスのための目安かなあと個人的に思っています。

■

AIIT夏合宿に1日だけ参加し、TDDを紹介して、みんなでペアプロをしてきました。大学生って若いんだなあ。 #enpit

途中から参加者を放置して、メンターの太田さんとペアで書いた、HTML Canvas版ライフゲイムです。最低限ですが、ブラウザ上で動きが見られるところまでたどり着きました(本当に最低限なので、見て驚いてください)。
https://github.com/yattom/tdd_life_javascript

さて、このコードのキモは3つあります。

１．テスティングフレームワークがない。フレームワークの使い方ではなくテストの書き方、考え方に集中するために、その場でテストのロジックを書き、それが関数になり、実行の仕組みを作り…と、テスティングフレームワーク自体を育てていくアプローチをしています(最近のお気に入り)。必要最低限の「フレームワーク」ができて手頃ですし、「これ面倒だからフレームワークで対応したい」というペインポイントを感じながら作れるのがメリットです。

２．テストコードとプロダクトコードが渾然一体している。1ファイル(life.js)にテストコードとプロダクトコードが入り交じった状態で進めました(パターンになかったっけ)。最終的には、テストが「上のほう」、プロダクトコードは「下のほう」にまとまっています。これは配置だけの問題でなく、プロダクトコードの中にテストのためのコードが入り交じっているという状況も作り出しています(例: セルを描画した回数をアサートするために、プロダクトコードの中で数える)。この件は次のキモにつながり…

３．モック(テストダブル)を嫌う。Canvasに描画するという処理そのものをテストするのは困難です。そこでモックライブラリを導入して、描画処理が何回呼ばれたとか、正しいパラメータが渡されているとか確認するのが、常道です。しかし今回は(２．で触れたように)プロダクトコードのロジックの中にテスト用の処理(何回呼ばれたか数える)を埋め込んでいます。大変だ！プロダクトコードがテストで汚染された！

ですが、TDDであれば、あるいはTDDでなくても、プロダクトコードと自動テストとが一体となって作られ、一緒にコミットされ、変更やメンテナンスも同時です。プロダクトコードとテストコードの意味的な分離はそれほど、昔ほどは重要ではないように感じています。今回実際に書いてみて、このくらいなら複雑にもならないし、可読性も悪くないし、扱いやすいコードにできることがわかりました。少なくともモックを導入するよりは、プロダクト＋テスト全体としてシンプルになっています(実際の比較はしていませんけれど)。

もちろん、たかだか2時間で書いたコード量ですから、これから質・量ともに増えて複雑になっていけば、いつまでもモック不要とはいかないでしょう。一方で、プロダクトコードとテストコードの分離が絶対である、依存関係は一方通行であるというのは、ルールと言うよりはガイドラインに過ぎず、バランスやトレードオフを考えるべき条項なのではないでしょうか。

P.S.
Jim Coplienがセミナーで言っていました。「製品にアサートを(テストと言うよりはDbC的な表明だと思う)を埋め込んだまま出荷すべきと意見したが、止められた。なので会社を辞めた」。またハードウェアはたいてい、異常時にテストする仕組みを埋め込んでいます(内部の自動テストや、外部からテストする端子など)。

新米スクラムマスターにお勧めの本

「新米スクラムマスターが読むべき、読んでおくべき書籍や資料を教えてください」とFacebookで書いたところ、何人かのアジャイルコーチやスクラムマスターといった皆さんからお勧めをもらいました。

https://www.facebook.com/yattom/posts/1771377669542867 (ログインしなくても読めます。「コメント26件」みたいのを開いてください)

せっかくなので、ここにも転記しておきます。私の独断で分類しつつ、一部紹介コメントも追加しました。

超基本、必読

入門書

アジャイルやスクラムについての知識、ノウハウ

スクラムマスターとして人にスクラムを伝えるために

人、チーム、組織について

広い観点を得て深く知る

成功しているアジャイルの実例

それじゃあ価値はどこからくるの？

前回の続きです。

Gerald Weinbergは、「品質」という言葉を「誰かにとっての価値」と定義した。高品質のデリバリを達成するには、「価値を届ける相手は誰か」、そして「デリバリに求められる価値は何か」といった理解が必要だ。

(『インパクトマッピング インパクトのあるソフトウェアを作る』(ゴイコ・アジッチ、翔泳社、2013年) p.07 アクター)

もちろん、ストーリーを動くソフトウェアという形にしてユーザーに提供すれば、ユーザーはそれを使って何らかの便益を受けられます。すなわち、ユーザーは価値を得られます。こう考えれば、「価値がある」ストーリーには、文字通りユーザー価値があることになります。

しかし問題はそう単純ではありません。例として、ショッピングサイトを考えてみます。ストーリーは「商品カタログを見る」「注文する」「決済する」「発送する」などになるでしょう。すぐに典型的な疑問がわいてきます ―― 「注文する」ストーリーには単独で価値があるのか？すべてそろわないと価値がないのではないか？

ユーザーストーリーマッピングはひとつの答えになります。ユーザーが買い物をするという行為を完結できる一連のストーリーを選び、それを最小限の時間やコストで実現できる組み合わせにして、最初のリリースを定義する(これを私はMVP(Minimal Viable Product)とも呼んでいますが、人により解釈が異なるようです)。こう考えると、個々のストーリーの価値は問題ではなく、リリースというひとまとまりの動くソフトウェアに価値があることがわかります。

前回紹介した、ストーリー1つに独立して価値があるという考え方もあります。いまの時代にショッピングサイトを作るとしたら、他社にない特別な優位性が求めらるはずです。そうした優位性のアイデアが「注文する」ストーリーに込められているなら、単独で価値を持つと考えられます。リーンスタートアップのアプローチであれば、この優位性(の仮説)を検証するために、集中して実験することになります。注文の部分だけソフトウェアで実現して、ターゲットユーザーに試してもらうかもしれません。

プロダクトの強みとなる箇所だけを取り出し、検証する作業に当たります(これをMMF(Minimal Marketable Feature)と呼んでよいと思いますが、人により解釈は異なるようです)。最終的にプロダクトとしてユーザーに利用してもらうときは、一連のストーリーが必要になります。ギルドワークス株式会社の市谷さんは「学びを得ることと価値提供を混同しない」と言っています。

ユーザーストーリーマッピングに限らず、アジャイルなソフトウェア開発では、リリース計画やロードマップが用いられます。いずれも、顧客に動くソフトウェアを届け、価値を提供するための計画です。どういうタイミングで、なにを提供すれば、届ける価値を最大化できるのか。

リリースからはさらに、生のユーザーフィードバックを得られるようになります。こうしたフィードバックをどうやって得ていくかも、リリース計画の一部となります。フィードバックは様々な種類があり、ユーザー行動分析もそうですし、クチコミの評判もあれば、市場や競合の変化もそうです。売上やマーケットシェアの変化もフィードバックとなります。プロダクトの性質により、リリースが何スプリントに一度の場合も、1スプリント内に何度もリリースする場合もありますが、基本的には変わりません(間隔の長いリリースのほうが、計画が難しくなる傾向はあるようです)。

こうなると、次のリリースの内容は、その先のリリースまで見据えたものになってきます。そのため、リリース計画においてはその先のリリースも含めた、ロードマップの検討と更新が欠かせないものになります。ロードマップはプロダクトビジョンの実現、今後のプロダクトの向かう先を示すもので、チーム全体の方向をそろえる道具のひとつとなります。

ユーザーストーリーの価値

良いユーザーストーリーの条件として、よくINVESTが挙げられます。(参考: https://blog.guildworks.jp/2015/06/03/how_to_deal_with_invest_of_userstory/ )

  • Independent 独立している
  • Negotiable 交渉可能である
  • Valueble 価値がある
  • Estimable 見積り可能である
  • Sized Right (Small) 適切な大きさである(小さい)
  • Testable テスト可能である

この中のValuableについて考えてみます。ユーザーストーリーは価値がなければいけない。1個1個のユーザーストーリーに価値があれば、プロダクトオーナーは依存関係を意識せず並べられ、開発者はテストを含め完全に完成させられ、顧客は毎スプリント価値あるアウトプットを受け取れます。価値があるユーザーストーリーとは素晴らしい。

本当でしょうか。本当に、ユーザーストーリーは「価値があるべき」であり、「価値を持てる」のでしょうか。

ユーザーストーリーを扱う上で、よくある悩みは「1スプリントで完成できない」というものです。スクラムマスターは「それではストーリーを分割しましょう」と言います。Richard Lawrenceによればストーリー分割には以下のようなパターンを使えます。

  • 原則
    • 優先順位が違うものを分ける
    • だいたい同じ大きさ(小ささ)に分ける
  • パターン
    1. ワークフローのステップごとに分ける
    2. ビジネスルールのバリエーションで分ける
    3. 最初の1個目で基本形ができるように分ける
    4. シンプルな部分と複雑な部分に分ける
    5. データのバリエーションで分ける
    6. データ入力の方法で分ける
    7. パフォーマンスを別に切り出す
    8. 操作(CRUD)で分ける
    9. スパイクを切り出す

いずれももっともですし、効果的な分割ができそうです。でも分割したものには価値があるのか？あるとしてどのくらいなのか？測る方法はあるのか？

そもそも価値とはなんなのか。

エクストリームプログラミング入門の第1版で、ケント・ベックはこう書いています。

第15章 計画戦略 計画ゲーム (p.89):

計画ゲームのゴールはチームが生産するソフトウェアの価値を最大化することである。

計画ゲームは3週間ごとにおこなうとされています。常に、ソフトウェアの価値を最大化するよう計画すると述べているものの、ストーリー1つひとつに価値があるという言及は、この本には見つかりません。

アジャイルマニフェストのアジャイル宣言の背後にある原則の1番目は「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」とあります。ここにも、継続的に提供するのは価値のあるソフトウェアであって、ストーリーとか、機能とか、フィーチャーとかPBIとかいったものが個々に価値があるとは言っていません。

エクストリームプログラミング(第2版)では、こうなっています。(訳は筆者)

Chapter 7. Primary Practices - Stories

顧客が理解できる機能の単位を使って計画する。……見積りにより、ビジネス側と技術側の観点から相互に対話する機会が生まれ、そのおかげで価値を早期に、一番ポテンシャルが高い時期に作り出せる。コストがわかれば、その機能の価値を鑑みながら分割したり、結合、拡張することもできるようになる。

ここでは、ストーリーは相互の対話、インタラクションのためにあると言っています。ユーザーストーリーの3Cにもあるように、ストーリーに会話は不可欠です。

ここに、ストーリーが「価値がある」意味が出てきます。価値とは、それがなんであれ、誰のためであれ、ストーリーに背景を与えます。技術側はその背景を理解して初めて、ソフトウェアの価値に貢献できるようになります。技術側は正しいものを作るために、ビジネス側の観点を持たなければならない、そのための「ストーリーの価値」です。

アジャイルマニフェストの原則ではまた、「できるだけ短い時間間隔でリリースします」「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」とあります。ここから、ビジネス側の人、ひいては顧客側は開発者にフィードバックをするチャンスが得られます。ストーリーに価値があれば、その部分をさわって、満足か不満か、直すべき点はどこかという情報を開発側は受け取れます。開発者の知識とソフトウェアの実装は一致しています。そこにビジネス観点から見て間違いがあれば、開発者の知識を修正でき、ソフトウェアも正しくなります。そして「チームが生産するソフトウェアの価値を最大化する」ことに近づきます。

以上から、ユーザーストーリーが価値があるのは、正しいもの、価値あるソフトウェアを作るためと言えます。そうなる確率を上げるために、作る前の会話を効果的にし、作った後の確認も容易になります。これはすなわちリスクマネジメントの手法と言えます。価値があるユーザーストーリーを書くと、ソフトウェアが失敗するリスクを下げられる。

ストーリーに価値があるのは、実現したらソフトウェアの価値がそのぶん増すというような、単純なものではないのです。リスクマネジメントの手法なので、どんなリスクを想定するか、どんな情報を得たいか、そのうえでどれを優先すべきか、考えるための道具として使うものです。「間違ったものを正しく作る」事態を避ける道具のひとつなのです。

(まだ十分に考えが整理されていないのですが、いったんまとめるために本稿を書きました。観点の不足もあると思うのですが、コメントなどで突っ込んでもらえると嬉しいです。)

■

年末にThinkPad X1 Carbonを手に入れ、環境を作っていました。これまではホストOSをWindowsに、開発などではゲストOSをLinuxにしていましたが、今回はホストをLinuxにしようとしていろいろ試してみました。結論としては、これまでと変わらずホストWindowsになってしまったのですが、それまでの経緯や調べたことなどを記録しておきます。誰かの参考になるかもしれないので、役に立ったリンクも張っておきます。

3行まとめ

  • ホストLinuxでは新しめのハードウェアに苦労する
  • GUIアプリの操作感は、ゲストOSはだいぶ不利
  • それ以外のパフォーマンスは、ゲストOSでも遜色ない

やったこと

新マシンのスペックはこんな感じです。

Windowsプレインストールですが、回復メディアを作ったらさっさと初期化、まずはUbuntu Desktop 14.04を入れてみました。そこから、Ubuntu上で暮らしていけるかの確認(主にハードウェア)と、Windowsをゲストにして作業が快適か(主にOfficeを使う)を、調べていきます。

ハードウェアについては、自分にとってはいきなり致命的だったのが、WiGigドックとBluetoothマウスの問題でした。WiGigドックはLinuxでの情報が見つからず(「数年以内にはサポートするんじゃない？」とか )、断念。

マウスはロジクールのMX Anywhere 2のBluetooth接続ですが、Ubuntu 14.04ではPINなしのペアリングに対応してないとのこと。回答の中に「DON'T DO THIS!」とあったりもしたので、こちらも諦める方向(実のところPPA追加だけなので、大した騒ぎではないのですけど)。

また指紋認証も、fprintのサポート外デバイスらしく、使えるようにできませんでした。 (こちらのリンクの138a:0090に該当。)

Windowsゲストの導入

気を取り直して、Windows 10をゲストでインストールします。qemu+kvmとVirtualBoxをそれぞれ試しました。Windows10はインストールUSBディスクを作っておいたものの、VMをUSBブートさせる方法がわからず、isoイメージから。基本的には問題なかったものの、引っかかった点をいくつか。

Windows上ではブラウザやIntelliJ IDEAを操作してみましたが、もっさり感があるのと、キーリピートが不自然に中断されるなどの微妙な使いにくさがありました。(これは対策したけど変わらず)

ベンチマーク(要約)

その後、新マシンにあらためてWindowsを(ホストとして)新規インストールして、さらにVirtualBoxとHyper-VそれぞれでUbuntu Desktop 14.04を入れ、PCMark8や、pythonのベンチマークを取ってみました。ここでは要約だけで、より詳しくは下の方に載せておきます。

PCMark8はWindows専用で、ブラウジングなど一般的なアプリケーション利用の操作感のスコアを出してくれる、ようです。ホストの時は2644、ゲストの時は1250前後となり、半分くらいでした。ただし項目ごとに見ると、差があるのは一部の項目だけで、そこまでの差はないようです。

Pythonでは総合的なベンチマークを取りました。こちらの結果は、傾向としてLinuxホスト＞Linuxゲスト＞Windowsホスト＞Windowsゲストという、わかりやすい順位になりました。

ベンチマークのスコアを見る限りでは、どちらがホストでも極端な差は出ないようです。ただしアプリケーションの操作感は、Linuxホスト/Windowsゲストだとどうも使い辛く感じます。気のせい、プラセボ、思い込みかもしれません。

当面の結論

なにより、使いたいハードウェアを使えないという点で、WindowsをホストOSにして(もう少し)生きていくことにしました。ただし開発はゲストのUbuntu Desktop上で、IntelliJ IDEAも含めて使っていくつもりです(Windows上のPythonは、慣れたけど、やっぱりツライ)。

環境にかける情熱がだいぶ減っているなあというのも発見でした。なんとかなりそうでも、すぐ面倒くさくなる。いったん解決できても、今後のことやまたトラブル出たらと、思ってしまう。前にやった解決方法とかも、毎回忘れてるし。

そういえばゲストWindowsでOfficeを使ってみれば良かったなあ(面倒なので諦めた)。

ベンチマーク結果

PCMark8のベンチマークはWindows専用です。無料で使えるHome Conventional 3.0を実行します。結果、ゲストではホストの約半分のスコアでした(2644に対し1250前後)。qemu(1259)とVirtualBox(1235)では、目立った差はありませんでした。

しかし項目別に見ると、Casual GamingとVideo Chat encodingが極端に悪いものの、それ以外ではそこまでの差はないように見えます。(いずれも、ホストの場合を1.0とした相対値。[s][ms]は時間なので長い方が遅く、[fps]は短い方が遅い)

ゲストを実際に操作すると、もっさりというか、引っかかるというか、使い辛い気がするんですが、ユーザーの操作に対する反応性だけであって、総合的なパフォーマンスは悪くないようです。

pythonのパフォーマンスはPython benchmark suiteというものを使いました。様々なベンチマーク(純粋なPythonの処理から、Web、DB、json、xmlなどまで)をまとめて実行してくれるものです。画面表示・描画はありません。
グラフはそれぞれのかたまりがベンチマークの種類に対応し、その中の7本のバーが左から、以下の順序になっています。長さは実行時間で、長い方が遅くなります。いずれのベンチマークでも、Windowsゲストを1.0とした相対値になっています。

  1. Windowsゲスト(VirtualBox上)
  2. Windowsホスト
  3. Linuxゲスト(Hyper-V上)
  4. Linuxゲスト(VirtualBox上)
  5. Linuxホスト
  6. X240sでのWindowsホスト(参考値)
  7. X240sでのLinuxゲスト(Debian。参考値)



全体的な傾向としては、前述のように 5>4>3>2>1の順に速く(グラフは短く)なっています。項目によっては、Windowsのほうが速かったりと、異なる傾向のものもあります。(なお、極端な差が出たり、環境によって実行できなかった項目は、除いています。) Linuxゲストは、Hyper-VよりVirtualBoxのほうが成績が良いようですが、厳密に同じ設定になっていないかもしれないので、ここは参考程度に。

なおPython benchmark suiteで利用しているGitHub - vstinner/perf: Toolkit to run Python benchmarksというモジュールが現在Windowsで動かず、パッチを作って使いました。うまくいけばそのうち取り込まれると思います。