リバーシ（オセロ）を部分的に実装して、ソフトウェア開発関係者であることを証明する ー その1

　ソフトウェアエンジニアならリバーシ（いわゆる、オセロ）の実装くらいできるだろう、というのが話題になっていたので、やってみることにしました。

「職業プログラマーな方でもオセロすらプログラミング出来ない人が大勢いるよ」というツイートがありました。
強いのは無理でもゲームのルール通りに動くくらいならオセロを作れない人は少数派だと思う。

— akiyama924🏝 (@akiyama924) 2018年6月30日

　8×8マスの情報を保持するための「配列」、マスの状態を一つ一つ見ていく「繰り返し」、石をおける/おけない、返る返らないの「判定」など、プログラミングの基本概念を知っていれば、実装できそうです。
　では、わたしのような者にとって、ここで選ぶべき「言語」は何でしょう。

　そうです、Microsoft Excelですね。
　あ、いいえ、VBAではありません、Excelワークシート関数です。
　何しろワークシートを方眼紙状にすることで、盤面を即、表現できますから。

　といっても、全部やるほどの週末はないので、「そのセルに黒石をおけるかを判定する」部分を作ってみました。

自然言語で表現する

　あるマスに黒石をおくためには、そのマスの上下左右、斜めの計8方向のいずれかについて、以下の条件を満たしていることが必要です。

1. 対象の位置に、石がない。
2. 対象の方向に、黒石がある。
3. 一番近い黒石との間がすべて白石である。

Excel関数で表現する

前提

　白石を「1」、黒石を「10」で表現します。Excelなら条件付き書式が使えるので、色も変えられますね！ 薄い青は、石が置かれていないマスを表現しています。

条件1

　これは簡単です。たとえばセルD5であれば、

D5=""

で判定します。いやいやそこはISBLANK関数だろ？と思う方もいると思いますが、ISBLANKを使うと後で詰みます。

条件2

　たとえば右方向に「10」があるかどうかを判定するには、MATCH関数を使えばいいですね。 セルD5について判定するには、

=MATCH(10,E5:$J5,0)

とします。対象セルとすぐ右から一番右端までをチェックしています。第3引数を「0」にしておくと、一番最初に見つけた（つまり一番近い）位置を返してくれます。

条件3

　セルのすぐ右隣のセルと、条件1のMATCH関数で得たセルの間が、すべて白であることを確認します。そのために使うのは、OFFSET関数とSUM関数です。

=SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))

　OFFSET関数は、基準となるセルから、第2・第3引数で起点を決め、第4・第5引数で高さと幅を決めることで、領域を指定することができます。わかりづらいですが、ここでは「対象セルのすぐ右のセルから、一番近い黒石のすぐ左のセルまでの領域」を指定しています。これはつまり、「黒と黒で囲まれた領域」ですよね。その領域がすべて白（「1」で表現される）であれば、領域の数字のSUMは、領域のセル数に一致するはずです。3マスなら、3。

　つまり以下のような判定がTRUEであれば、黒と黒にはさまれた領域はすべて白です。

SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))=1*(MATCH(10,E5:$J5,0)-1

　なお、黒を「0」や「-1」にしていないのは、この「一致」の判定でしくるだろうなと思ったためです。

判定

　条件1～3をANDで結ぶだけですね。

=AND(
D5="",
MATCH(10,E5:$J5,0),
SUM(OFFSET(D5,0,1,1,MATCH(10,E5:$J5,0)-1))=1*(MATCH(10,E5:$J5,0)-1)
)

　とてもシンプルに表現することができました。

右方向を判定した盤面

　先の結果を、判定用の盤面全64マスに適用します。
　元の盤面は、判定用盤面の対応位置の判定が「TRUE」であれば、黄色に塗ることにしましょう。こんな感じになります。

　まだ「右方向」しか判定できないので、ちょっとさみしいですね。
　次回は、「上下左方向」をどう実装していくか見ていきましょう。

データサイエンスが今もなおセクシーだと感じるビッグデータの使い方

　2007年の米国で大規模な景気後退が始まったとき、ストレスにさらされた大人たちによる、児童への虐待が増加するのではないかと危ぶまれました。しかし公式データによると、虐待保護件数はむしろ減少。特に、不景気の影響が大きい州ほど減少の幅が大きかったそうです。
　そんなことがあるのだろうか・・・？ 景気後退に伴い、本来報告を行う人が手一杯だったり、失業していたりしていただけではないか。
　Googleの検索データを調べると、「ママがぼくをぶつ」「パパに殴られた」という検索の件数は、景気後退の間に跳ね上がり、失業率データを一致していたというのです。

誰もが嘘をついている ビッグデータ分析が暴く人間のヤバい本性

人々が情報を求める検索は、それ自体が情報なのである。人々が何かの事実、発言、ジョーク、場所、人物、物事、あるいはヘルプについて検索するとき、それは彼らの本当の考え、望み、あるいは恐れについてどんな推測より正確に明かすものとなる。

　本書はこのような事例をふんだんに盛り込んだものです。
　著者は、検索エンジンを「デジタル自白剤」と呼び、伝統的な調査では得られない質・量のビッグデータから、これまで読み取ることのできなかった知見が得られるとしています。

　たとえば2015年にアメリカで起きた、銃乱射事件。数日後のオバマ大統領が受容と寛容を説いた演説の裏で、「イスラム教徒」とともに複合検索されていた言葉は、演説の内容とは正反対のものだったそう。成功と言われたこの演説が、現実には逆効果をもたらしていた可能性が、データ分析からわかっています。

　個人的な感覚では、「データサイエンティストってセクシー！」って言われまくった数年後の今、みんなが機械学習の話をしている感があるのですが、「たくさんのデータ」を相手にするのにデータサイエンスはやはり強力、ということをあらためて思い知らされます。

　ちなみにこちらは、著者が検索データをビッグデータとして扱うきっかけとなった、Googleトレンド。「big data」と「deep learning」の検索の趨勢を比較してみました。

　ビッグデータを用いた斬新な分析に続き、後半では、ビッグデータの限界や、従来の分析との組み合わせ、そして「やってはいけないこと」について言及しています。「やってはいけないこと」は、機械学習の文脈でも似たような話が出てきますね。たとえば「人の趣味や言葉遣いなどのデータを用いて、人材採用や犯罪予測の手がかりにすることは正しいのか」といったものです。

　なお今「後半」と書きましたが、わたしはこの本を最後まで読みました。そのモチベーションは、目次に目を通したときに見てしまった、「ここまで読み通してきた人は何人？」という最終章のタイトルです。こんな皮肉を言われてしまったら、読むしかないでしょう。
　本書最後の文章も、とってもひねくれたものでした。みなさんもぜひ、「ここまで読み通して来た人」になりましょう。ちなみに著者らによると、トマ・ピケティの『21世紀の資本』を読了した人は3%未満、だそうです。読み始めただけでもえらいと思うけれど！

少しばかりの統計学の技術と山ほどの好奇心を持ち合わせているなら、データ分析の世界に足を踏み入れてほしい。

データサイエンティスト養成読本 登竜門編 (Software Design plus)

　こちらは何だか不思議な本で、確かにデータサイエンティストになるために必要な素養を広く紹介してくれてはいるのですが、とても基本的なLinuxコマンドやExcel関数（！）にまで踏み込んだ記述があって、「とりあえず手を動かすために必要な知識を全部ぶっこみました」という感じがとても好きです。

【翻訳】モダンテスティングの原則

　同僚に紹介してもらった「Modern Testing Principles」、わかりやすくていいなと思ったので、許可を得て翻訳してみました。原文のブログ「AB Testing」は、ABテストとは関係なくって、PodcastとSlackを主宰しているAlanさんとBrentさんの名前からですね。

www.angryweasel.com

　なお、Work in Progressということで今後も変更されていくようなので、現時点での原文を引用しておきます。

1. Our priority is improving the business.
2. We accelerate the team, and use models like Lean Thinking and the Theory of Constraints to help identify, prioritize and mitigate bottlenecks from the system.
3. We are a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures.
4. We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture.
5. We believe that the customer is the only one capable to judge and evaluate the quality of our product
6. We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.
7. We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.

　では以下、翻訳です。
　誤訳や改善点あれば、Twitterなどでご指摘ください。

翻訳

モダンテスティングのミッションステートメント

　リリースに足る*1品質の達成を加速すること。

モダンテスティングの原則

　これらはまだ仕掛かり中であり、コメントを歓迎します。また、より踏み込んだ議論のために、slackグループに参加してください。
　モダンテスティングの7つの原則は、以下の通り。

1. わたしたちは、ビジネスの改善を優先する。
2. わたしたちは、チームを加速させる。リーンシンキングや制約理論（TOC）といったモデルを利用して、システム*2のボトルネックを特定し、優先順位をつけ、軽減するのを助ける。
3. わたしたちは、継続的な改善の力である。欠陥を捕まえるセーフティネットを提供するよりも、成功するための適応・最適化を助けるのだ。
4. わたしたちは、チームの品質カルチャーに十分注意を払ったうえで、さらに成熟した品質カルチャーに向かうために、チームを助け、導き、育てていく。
5. わたしたちは、自分たちのプロダクトの品質を判断・評価することができるのは、唯一お客様のみであると信じる。
6. わたしたちは、広くデータを用いてお客様の使い方を深く理解し、プロダクトの仮説とビジネスインパクトの間にあるギャップを小さくしていく。
7. わたしたちは、テストに関する能力やノウハウをチームに広める。そのことが時に、テストのスペシャリストを専任でおく必要性を減らして（あるいはなくして）しまうことを理解したうえで。

所感

　これを読んで、「当たり前のことしか書いていない・・・」と感じる人と、「はあ？」と感じる人がいるかもしれません。カルチャーやコンテキストによっては、この原則と真っ向からぶつかると思います。たとえば以下のような風土・考え方をもつ組織とは、合いそうにないですよね。

• テストチームの第一の目的は、できる限りたくさんのバグを見つけて、外部品質を高めることである。
• 開発チームは自分たちで品質を判断できないので、テストチームが判断する必要がある。
• QA組織は、開発組織と独立した部門であり、開発の最後に品質保証の活動を行うものである。

　どっちが正しいかはわかりませんし、状況によるのかもしれませんが、どっちが楽しそうかといえば、「モダンテスティング」の方が楽しそうだなーとわたしは思います。

　これらの原則から感じられるのは、「お客様」と「チーム」という2つの視点ですね。
　特にわたしが好きなのは、7です。テストチームは、テストをする人のポジションを守るためにあるものではなく、お客様のビジネスとチーム全体をよくするためにあるもの。「テストチーム」を守るために、テストの技術を秘法にするのでは、チームの加速に寄与することなんてできない。7が、自分自身の否定につながると感じるなら、それは成長のための学習を怠っているからでは？と言われているように思います。

　あ、リーンシンキングとTOCですか？ もちろん書籍を持っていますよ。

　持ってはいます！
　・・・成長のための学習を怠っているなあ。（ザ・ゴールの焼けた背表紙を見つめながら）

ザ・ゴール ― 企業の究極の目的とは何か

リーン・スタートアップ

*1:「Shippable」（出荷可能な）意訳です。定訳あるでしょうか？

*2:ここでいう「システム」とは、コンピュータシステムではなく、開発チーム・プロセスのことを指していると考えています。

寿司とシャンパン、ディープラーニングとExcel、そんなマリアージュ

　『大予測 次に来るキーテクノロジー2018-2019』という本を読みました。野村総研のアナリストである城田真琴さんが、「次に来る」8つのテクノロジーの今とこれからについて、ふんだんな事例とともに解説したものです。　

大予測 次に来るキーテクノロジー2018-2019

• 第1章　人工知能
• 第2章　自動運転
• 第3章　音声インタフェース
• 第4章　チャットボット
• 第5章　VR・AR・MR
• 第6章　バイオメトリクス認証
• 第7章　センシング、IoT
• 第8章　ブロックチェーン

　多くの人にとってはほとんどが、聞いたことのあるテーマ・分野だと思います。タイトルに「2018-2019」と明示しているだけあって、「すぐに古くなることは承知で、今まさに旬な情報を詰め込んだ」という割り切り方で、先端企業の取り組みを幅広くカバーしています。たとえば音声インタフェースであれば、Amazon、Google、Appleといった巨大企業の覇権争いに、日本からはLINEが殴り込みにいき、音楽配信サービスとの連携でも火花を散らしていますね。

www.phileweb.com

　新しい技術がもたらす既存の社会システムとのズレについても、興味深いものがありました。ハイレベルな自動運転が実現され、運転の過失をユーザに問えなくなったとき、自動車保険はどのような形をとるべきか。音声認識端末がホテルの部屋に設置された場合、ユーザと、（録音のログを確認・管理できる）オーナーが一致しなくなるが、プライバシーはどう守るべきか。偏見なしで中立的な判断をしてくれるかのような人工知能に、人種差別的なバイアスが含まれるとしたら？などなど。

smartdrivemagazine.jp http://www.sekaiwoyakusu.com/entry/machineracismwww.sekaiwoyakusu.com

　また、チャットボットは「次に来る」イメージがわたしにはなかったため、取り上げられていたこと自体が意外でした。「なんとなく不自然な受け答えをして、結局正解にたどり着けないナニカ」という思い込みしかなかったので・・・。
　サービスを提供する企業にとってチャットボットは、スマホアプリやSNSの次の顧客チャネルという位置づけになっており、そこでのサービス展開が重要になってきているのだそうです。 　

　チャットボットもそうですが、紹介されているテクノロジーの多くが、人工知能・ディープラーニングとともに語られているのも印象的でした。何らかの判定を行うための基幹技術としてディープラーニングが前提となっているのです。もはや、テクノロジーを成立させるための基盤技術なのですね。

　そんなディープラーニングを学び始めるのに適した本はたくさんあると思うのですが（ここから本題）、その中で異彩の放ち方が異彩すぎるのがコレ、『Excelでわかるディープラーニング超入門』。

Excelでわかるディープラーニング超入門

　いやいや・・・。・・・いやいやいや！ Excelでって！
　ってなりませんか？
　表紙でこんな風に煽ってきます。

難しい数学計算はExcelに任せて ディープラーニングのしくみを 動かしながら理解できる！

　「難しい数学計算」といいますか、本書は偏微分どころか行列もΣも出てきませんからね。ほぼ、加減乗除のみです。

　本書の目的は、数学やプログラミングの素養があまりない人が、「身近な」Excelを使ってディープラーニングを理解できるようになることです。なので、Excelの基本的な関数を丁寧に追っていけば、ディープラーニングが詰まるところ何をしているのか、がわかった気になります。重みづけとは、閾値は結局何なのか。どうやって文字を判定しているのか・・・。
　そして途中でExcelの限界につきあたり、その限界を畳み込みニューラルネットワークで一度超えて、「それでもやっぱりこれ以上は無理だよね」というところまで導いてくれる。それが本書。

　使う関数は、以下の通りです。特に難しいものはありません。

• SUM: 目的関数の計算
• SUMPRODUCT: 入力の線形和
• SUMXMY2: 平方誤差の検出
• EXP: シグモイド関数
• MAX: MAXプーリング、ReLU
• RAND: 初期値設定
• IF: 画像の判定

　3×4のビットパターンに対し、「〇」か「×」かを判定するアプローチは、こう*1。

　ビットパターンをExcelの3×4マスを使って表現している・・・*2。 この発想、面白過ぎると思うんですよね。言われてみたらできそうな気はするけど、本当にやる？っていう。

　こちらが、入力層→隠れ層→出力層までを計算するExcelワークシート。

• 隠れ層には3つのニューロンがあり、ビットパターン4×3セルに対応する重みづけの初期値がRAND関数で選ばれる。 閾値も同様で、ニューロン3つに対応して3つ設定されている。
• 入力層のビットパターンと隠れ層の重みづけがSUMPRODUCTで掛け合わされたうえでシグモイド関数にかけられて、隠れ層の出力になる。
• 隠れ層での出力と、出力層の重みづけ・閾値も同様に計算され、出力層の出力になる。
• 誤差は、出力層の値と正解のゼロイチとの平方差分がとられる。
• 各「画像」に対する判定結果に対する差分の和が、QT。

　最後に、上の絵でいう色塗りされたセル（最初にRAND関数でランダムに決めたもの）を変数とし、QTを最小化するようソルバーで計算させます*3。
　これで確かに、「難しい数学計算はExcelに任せて」、最適なニューラルネットワークを求めることができました・・・・。

　Excelのサンプルワークシートがあるし、説明も冗長なくらい丁寧なので、Excelに慣れている人ならこの理解ルートは意外にたやすいのでは！？と思ってしまいます。ディープラーニングの本の数式に慄いてしまった方は、この道も考えてみてください！

*1:技術評論社の「サポートページ」に掲載された自習用Excelのキャプチャです。

*2:灰色セルには「1」が立っていて、計算に使われます。

*3:わたしのパソコンでは10秒ほどで計算が終わりました。

アジャイル開発におけるメトリクスには、どういうものがあるのか

　アジャイル開発において、プロダクトや組織の現状を把握するのに役立つメトリクスを知りたいと思い、「agile kpi」などでググって上位のサイトを読むという丁寧なサーベイを敢行。20個くらい読んでいくとだいぶネタも尽きてきたので、整理してみました*1。参考にしたサイトについては、記事の最後に載せておきます。
　なお以下では、アジャイル開発とスクラム開発をほぼ同じ意味で使っていますが、怒らないでいただきたいですね。

メトリクスとKPI

　メトリクス（metric / metrics*2）とKPIはごちゃごちゃに使われがちです。こちらの資料では、以下のように説明しています。

Agile KPIs from Gaetano Mazzanti

www.slideshare.net

• メトリック: プロセス・プロダクト・チームの定量的な評価・制御・改善のための物差し、またはその組み合わせ
• KPI: 戦略的な目標に強く紐づけられた、最低1つの期限付き目標をもったメトリック

　KPIの設定方法として、有名な「SMART」や「INVEST」といった基準に言及しています。

　では、各サイトで言及されているメトリクスについて紹介していきます。
　ざっくりと、「開発能力」「進捗」「プロセス」「品質」に区分していますが、複数の区分にまたがるものもあります。

開発能力

　チームの開発能力を測ることのできるメトリクスは、以下のものです。

1. ベロシティ
2. サイクルタイム
3. 平均欠陥修復時間 (MTTR)

ベロシティ

　スプリント内で完了できた仕事の量。
　仕事の量は、見積もり規模であったり、ストーリーポイントであったり、チームによってさまざまでしょう。
　ベロシティを測定する目的の一つは、自分たちが一定期間に開発できる量を知り、見積もりの精度を上げることです。スプリントを重ねていくと、ベロシティが安定していくことが期待できます。低下傾向にあるようなら、開発プロセスに非効率な部分があるとか、コードの保守性が悪化しているといった問題の兆候かもしれません。

サイクルタイム

　タスクの消化にかかる平均時間。要件の特定からリリースまでの「リードタイム」（TTM）の対となる概念という扱いです。
　具体的には、タスクが仕掛中（doing）になっている時間を測っています。タスクが適切に分割されていれば、サイクルタイムは一定になるはずで、開発能力や開発プロセスの安定を見ることができるという理屈です。
　このメトリクスは今回の調べる中で初めて知ったのですが、扱っているサイトは多く、一般的なもののようです。

　下の図は、Main Agile Software Development Metrics and KPIsから引用したものです。平均、移動平均、標準偏差と、サイクルタイムを1つの図に表現しています。

　サイクルタイムが短いということは、開発の能力が高いというだけでなく、品質問題による手戻りが少ない、作業の待ち時間が短い、コンテキストスイッチが少ないなど、品質や開発プロセスの良さによるものかもしれません。逆もしかりで、サイクルタイムの悪化は、品質やプロセスに何か問題のある兆候と考えられます。
　サイクルタイムは「安定して」「徐々に短くなっている」ことを目指すことになります。実装と欠陥改修のタスクを分けて計測しているケースもあるようです。

平均欠陥修復時間 (MTTR)

　欠陥修復までの平均時間。欠陥数 / 改修のためのコーディング時間 で算出します。
　MTTR（Mean Time To Repair、平均修理時間）は、コンピュータシステムの保守性を表す指標として有名です。これを開発チームの効率を測るのに使ったものです。

www.dospara.co.jp

　ここでは「開発能力」にカテゴライズしていますが、問題発見から原因特定・改修・テストまでのプロセスが円滑であるとか、原因の特定や改修が容易な、保守性の高いプロダクトであるといったことも考えられます。
　この指標も、たとえば「バージョンを重ねるごとにMTTRが低下しているのは、技術的負債が増加しているためでは」「品質が悪すぎるので、新規開発を止めて改修に専念すべきなのでは」というように、問題の兆候と捉えたり対策を打ったりするのに役立ちそうです。　

進捗

　開発の進捗を測ることのできるメトリクスは、以下のものです。

1. バーンダウンチャート
2. テスト進捗率

バーンダウンチャート

　進捗をみるうえで代表的なのが、タスクの消化具合を可視化した、このバーンダウンチャートでしょうか（バーンダウンチャート自体はメトリクスではありませんが・・・）。残日数と仕事量から算出した理想線と実際の線を比較することで、進捗状況の把握や、完了見込みの推定を行います。スプリント単位でも、バージョン単位でも用途があります。

　ポイントとして、「開発の途中での総作業量の増加」を見える化することも大事です。ある1日に10SPの仕事を消化した一方で、何らかの理由で10SPの仕事が追加されてしまった場合に、単に「グラフが下がらない」と見えるだけだと困ります。「消化した分、下がる線」（傾きがベロシティに相当）と、「追加された分、上がる線」（各時点での全作業量に相当）を見られるようにしておくべきでしょう。
　他の表現方法として、「追加された分を棒グラフの負の側に出す」というものもありました。こちらの方が直観的にわかりやすいかもしれません。

　下の図は、サイクルタイムと同様、Main Agile Software Development Metrics and KPIsから引用しています。

　なおアジャイル開発において、1つの開発バージョンの中でスコープの変更が起こることは必然です。一方スプリントの中で頻繁にスコープクリープが発生するのはよくないことでしょう。要件の受け入れやタスクの工数見積もりに問題がないかの確認が必要です。

テスト進捗率

　テスト全数に対し、完了しているテストの数で、時間推移を見ます。
　チケット管理と一元化されているか、テスト管理ツールで別管理するかはチームによります。

プロセス

　プロセスの良しあしを測ることのできるメトリクスは、以下のものです。

1. タスクのステータス分布
2. リリースオーバーヘッド
3. フロー効率性
4. 予見性

タスクのステータス分布

　タスクのステータス（たとえば todo、doing、doneの3種類）を色分けして積み上げたもの（累積フローチャート、累積フロー図）です。doingの層の横幅が、上述のサイクルタイムに相当します。また、Main Agile Software Development Metrics and KPIsから引用しています。

　健全な状況では時間ともにdoneの割合が増えていくことが期待されれます。
　doingの割合が増加傾向にあれば、doneに進められないようなプロセス上の問題や、ブロックしているバックログがあるのかもしれません。あるいは、WIP（Work in Progress）タスクが多すぎてコンテキストスイッチが多発し、開発効率が落ちているかもしれません。チームメンバーのWIP数と流出欠陥には相関があるという調査（PDF）もあります。

　これもやはり、問題を早期に発見するためのツールといえるでしょう。
　タスクの種類が、実装なのかバグの改修なのか、はたまた環境構築なのかによってグラフを分けてみれば、新しい知見があるかもしれません。インシデントレポートはどんどん増えているのに、一向にdoingにならない、とか・・・。　

リリースオーバーヘッド

　リリースのためにかかる時間やコストを表します。
　短い周期で定期的にリリースするのであれば、そのための時間とコストを小さくする必要があります。RC（Release Candidate）のテストやデプロイ前の確認フェーズでの時間やコストを計測し、ボトルネックを見つけることで、プロセスの効率化を図ります。

フロー効率性

　実働時間と待ち時間の割合を示します。
　他のタスクの完了を前提とするようなタスクが増えてくると、前提タスクの完了を待つ時間も長くなってしまします。そのような非効率を可視化し、プロセスの劣化やボトルネットを検出することができます。

　このフロー効率性と、対をなす概念であるリソース効率性については、以下のページがとてもわかりやすいです。

i2key.hateblo.jp

予見性

　各メトリクスにおける計画と実績の乖離をみるという、メタ的なメトリクスです。
　メトリクスについていろいろな記事を読んでいると、「開発能力が高い」ということと同じくらい、「安定している」ことが求められていることに気づきます。プロセスが安定していて、見積もりの精度が高い。これをpredictability（予見可能性）と呼んでいます。
　予定との差の大きさや、実績値の標準偏差を測定し、ばらつきが少なくなるように改善をすることになります。ばらつきが少なければ、見込むバッファも小さくてすむようになります。　

品質

　もともとこれが知りたくて調査を始めたのでした。
　品質の良しあしを測ることのできるメトリクスは、以下のものです。

1. コードカバレッジ
2. コードの複雑度
3. コードチャーン (code churn)
4. 欠陥密度
5. 欠陥の出方
6. DDP (Defect Detection Percentage、欠陥検出率)
7. 平均欠陥検出時間 (MTTD)
8. テストの成功率
9. ビルドの成功率

コードカバレッジ

　JSTQB用語集（PDF）での定義は、以下の通り。

テストスイートが、ソフトウェアのどの部分を実行（カバー）し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。

　品質の十分条件というより、必要条件的に使われることが多いと思います。
　ステートメントカバレッジ・デシジョンカバレッジ100%を目指す組織もあれば、『知識ゼロから学ぶソフトウェアテスト』では「一般の商用ソフトウェアなら60～90%で十分」としています。（60～90は幅広いですけど・・・）

知識ゼロから学ぶソフトウェアテスト 【改訂版】

　カバレッジの種類はいくつかあるので、意味を理解しておく必要があります。このブログでは以下で紹介しています。

www.kzsuzuki.com

コードの複雑度

　ソースコードがどれだけ複雑かを定量化したものです。
　コードが複雑であれば、欠陥を埋め込みやすく、テストも複雑になるため、プロダクトの品質の悪化につながるでしょう。 また、同じ理由で改修も難しくなってしまうので、保守性も悪くなり、長期的な品質に影響します。複雑度は、欠陥を埋め込みやすいリスクの高いコードを特定し、コードレビューやリファクタリングの優先順位付けに利用することができます。

　複雑度の例としては、ネストの深さやクラスの結合度、McCabeのCyclomatic複雑度、Halsteadの複雑度などがあります。ただ、人間と機械では複雑さに対する感覚が異なるので注意が必要です。先日の機械学習のイベントでも、富士通アプリケーションズさんのお話で、「コード解析では複雑と判定されなくても、人間にとっては読みづらいコードを学習させる」というお話がありました。

www.kzsuzuki.com 　またこれ以外のコードメトリクスとして、コードクローンやセキュリティ脆弱性など、主にツールを使って検出するものもありますね。

コードチャーン (code churn)

　どのくらいのコードが追加・削除・変更されたかという情報から、開発ステージごとのコードの安定性を見る指標です。
　Qiitaの @hirokidaichi さんの記事では、以下のように説明されています。

複数人で複数回にわたって編集されたファイルは複数の目的でコードが編集されている訳ですから、「単一責務原則」を違反している可能性が高く、潜在的にバグを内在していそうだということです。

qiita.com

　増加傾向（コードの修正が頻繁になっている）であれば、テストが不足している可能性があります。また、リリース直前に複数の人間による多くのコミットがあれば、そのコードが安定しているかを調査する必要があるでしょう。

欠陥密度

　開発規模（SLOC、FP、ストーリーポイントなど）あたりの欠陥の数です。WFでも何かと議論になりがちなメトリクスですね。
　たとえばSLOC（source lines of code）を分母とするケースでのわかりやすい欠点としては、実装の難しさやコードの複雑さが考慮されないというものがあります。「大きな組織で1つの基準を設け、全プロジェクトでその基準を参照する」よりは、1つのプロダクトの中でトレンドを見る方がよさそうです。SPを分母にする場合は、他チームとの比較がそもそもできないでしょう。
　ベロシティなどと同様、安定していれば見積もりにも使えるようになりますし、何らかの異常を検知することもできます。

欠陥の出方

　アジャイル開発に限った話ではありませんが、欠陥をいろいろな観点で分析することは重要です。たとえば、機能・ストーリーでの分類、重要度での分類、品質特性（機能性、性能、ユーザビリティ、保守性、・・・）での分類、オープン/クローズの時間推移など。
　ただ、分類と数字だけで判断するべきではなく、傾向を見つけたらそのエリアのバグ票の中身にまで突っ込んでいくことが必要になるでしょう。
　アジャイル開発においてもシフトレフトアプローチは有効で、早期に見つけるほど改修コストは下がります。

DDP (Defect Detection Percentage、欠陥検出率)

　プロダクトの全欠陥のうち、開発の中で摘出できたものの割合です。DDPが高いほど、開発の中でしっかり欠陥を刈り取れているということになります。

　ウォーターフォールの文脈ですが、『システムテスト自動化 標準ガイド』では、「開発中」と「リリース後」の二分だけでなく、開発中の各テストフェーズでのDDPを算出する話が出てきます。たとえば、結合テスト（欠陥80件）→システムテスト（欠陥15件）→ユーザ受け入れテスト（欠陥3件）→リリース（欠陥2件） とすると、以下のように計算できます。

• テストのDDP = (80+15+3) / (80+15+3+2) = 98.0 %
• システムテスト完了時点での結合テストのDDP = 80 / (80+15) = 84.2 %

システムテスト自動化 標準ガイド (CodeZine BOOKS)

　たとえばテスト工程をスプリントで読みかえて・・・ということも考えてみますが、適切な読み替えではなさそうでもあり。アジャイル開発の文脈で、DDPをうまく使っている例があれば知りたいです。

　リリース後の欠陥という観点では、fabric.ioのようなサービスを利用しての、モバイルアプリクラッシュステータスの監視に言及しているサイトもありました。

平均欠陥検出時間 (MTTD)

　MTTRがはシステムの保守性を表していたのに対し、MTBF（Mean Time Between Failure）はシステムの信頼性を表現するメトリクスです。
　MTTDはそのアナロジーで、「テスターが次の欠陥にぶつかるまでの平均時間」になります。これはプロダクトの品質・信頼性に依存しますが、テストの質やテストエンジニアの能力にも依ります。

テストの成功率

　実行したテストの成功の割合です。時系列でみると、向上していくのが理想です。終盤で伸び悩んでいる場合は、欠陥をクローズできていないなどの問題があり、危険の兆候です。
　もちろん、テスト側に問題があることもあります。テストの期待値が誤っている、テストが壊れている、など。

ビルドの成功率

　「最後のビルド失敗からの日数」「ビルド連続失敗回数」などで表現するもので、ビルドプロセスが安定しているかの指標になります。
　システムテストに入る前のコードに問題がないか、チームのホワイトボックステストのやり方に問題ないかといった観点での改善につながります。

メトリクスの扱い方

　さて、アジャイルに限ったことではありませんが、メトリクスには以下のような注意点があります。

1. 報告される側は、個人の評価に使わない。
2. 報告する側は、取り繕うためにデータを歪めない。
3. 収集に手間がかかりすぎるものは避ける。できるだけ自動で取得・集計・表示できるように。

　またこちらのページでは、短期と長期に分けて、ダッシュボードで見える化することを勧めています。
　メトリクスの例は、以下の通りです。

• 短期　ビルドの成功率、自動テストの成功率、、バーンダウンチャート、追加された致命的バグ、未解決な致命的バグ、・・・
• 長期　テストの失敗率、テストの数、ベロシティ、種類別バグ、・・・

Agile KPIs from Gaetano Mazzanti

www.slideshare.net

おわりに

　一通り紹介してみましたが、いかがでしょうか。
　もともとの動機が「品質に関わるメトリクス」だったので、偏りがあると思います。進捗を表すメトリクスが2つしかないし、コストに関しては1つも書いていません。実は、EVM（Earned Value Management）をアジャイルに適用する試みについての記事も読んだのですが、割愛しています。

www.infoq.com

　みなさんのチームで使われているナイスなメトリクスも教えていただきたいです。特に品質！

追記

　Twitterなどで寄せていただいた有益なサイトへのリンクです。

https://www.slideshare.net/oota_ken/agile-mericswww.slideshare.net

　辰巳さんからご紹介いただいた、SHIFTの太田さんのスライド。よっぽどちゃんとまとまっていました・・・。

メトリクスによる「見える化」のススメ: エッセンシャル・リーン from Hiroyuki Ito

www.slideshare.net

　LINEの伊藤宏幸さんの資料（楽天在籍当時）。Twitterで言及していたところ、ご本人に紹介いただきました。ありがとうございます。
　CFD、スループット、サイクルタイム、リードタイムなどに言及があります。

現場実践主義としてのリーン開発とアジャイル from Rakuten Group, Inc.

www.slideshare.net

　こちらも伊藤さんの資料。実際に現場で適用した内容なので、説得力が違いますね。
　また、メトリクスの悪化やボトルネックを発見したときも、対処は1つだけではないということを教えてくれます。

参考サイト

　本文中で直接言及していない記事・資料について、以下に列挙します。

reqtest.com www.getzephyr.com

Agile metrics and quality from Anu Khendry,ACC,SAFe Aglst, PMI-ACP,CSPO,PMP

www.slideshare.net

The AgileSparks Way Of Measuring Improvement On The Agile Journey/Transformation from AgileSparks

www.slideshare.net

Simple Lean Agile KPIs from Yuval Yeret

www.slideshare.net www.atlassian.com www.testdevlab.com https://www.testingexcellence.com/how-do-we-measure-software-quality-in-agile-projects/www.testingexcellence.com Agile Metrics - What You Need to, Want to, and Can Measure（PDF） www.capriconsulting.co.uk http://www.everydaykanban.com/2016/09/25/flow-efficiency/www.everydaykanban.com

　まだ読み切れていないものも参考までに・・・。

implementingagile.blogspot.jp www.scaledagileframework.com www.swtestacademy.com techbeacon.com nesma.org

*1:メトリクスの複数形は「metrics」なのに、勘違いしてURLを「metrix」にしてしまい泣きたい。

*2:最初「metrix」と書いていたのを修正しました、しかしカスタムURLには残っている、恥しかない・・・。