Cookpad Tech Kitchen #7 ～ 理想の開発現場の「ふつう」のお話 ～というイベントに登壇した
Cookpad Tech Kitchen #7 ～ 理想の開発現場の「ふつう」のお話 ～というイベントに登壇しました。
登壇といっても、お話をしたのは90分中15分くらいですから、全体の1/6程度です。
内容は、 id:akatsuki174 さんのブログが最高によくまとまっていますので、ここでは書く必要がありません。ここでは、裏話的なことを書きとめておこうと思いました。
経緯
たしか、2017年の1月末あたりに誘われたように思います。そのときに、咳さんとmiwaさんのセッションを行うことが決まっていまして、あとからジョインした形です。
スケジュールや内容の調整はTwitterのメッセージツールで行いました。Slackでという提案もあったのですが、私が「それは嫌」と反対しました。老人のわがままです。
でもって、当初、
・テストエンジニアと開発者の両方がターゲット
・咳さんとmiwaさんのチームの「普通」を集めて伝える
（普通の影響を知りたい）
・4月に50人規模でできるといいな
といった枠組みで始まりました。
割と当初から「フレーズ」というキーワードはでていました。
イベントの一月くらい前に、「普通」についてこんなメッセージをしていました。
スライドのたたき台が出てきたのが4月14日で開催の1週間前でした。
私は、スライド作るの遅いので「早っ！」って思いました。その日のうちにmiwaさんから時間割の案も提示され、『自分は論文の説明をする役割』と理解しました。
話そうとした内容
最初のうちは（クリストファー アレグザンダーのいう）「フォース」について話したいと思っていました。私は、フォースを「場の力」のように考えていますので、咳さんとmiwaさんのチームの場にはこんなフォースがあるという仮説を問いかけてみようと考えていました。
でも、4月19日の某所の宴会で栗Tさんが「秋山さんはさっきのミーティングで『社外活動で集まった仲間はダイバーシティ状態なので、我々がそういう状況でのチーム運営の方法についても教えるべき』といったけど、ダイバーシティだけじゃだめで、ダイバーシティ＆インクルージョンなんだよね。インクルージョンが大切なんだ」と言っていて、『そういえば、そうだったな』と思いだしまして、2日寝かした後、突然、『このイベントでインクルージョンの話をしたい！』って思いつきました。
で、宣言しました。
そのあとに速攻でカンペを作って恵比寿に向かいました。
どうして「関さんに馬鹿にされる」と思ったかといいますと、「僕らはインクルージョンを目指してきたわけじゃない。結果として、その概念で説明できるかもしれないけどね。……そうして分かった気になってればいいさ」といわれるだろうなーって。
そういわれたら、「そのとおりですね」としか言いようがなく、それでも、私は（たとえ不十分と分かっていても）言葉にして伝えたいという性格ですので伝えました。と、そんなわけなのさー。
『テスト設計の実例と解説』 小田部 健 著
はじめに
2016年9月15日。SQiPシンポジウムの基調講演の直前に東洋大の井上円了ホールのロビーで待ち合わせ、カードゲームのバグッパと一緒に著者ご本人から購入させていただいた薄い本（同人誌）です。サインしてもらうのを忘れたのが残念です。
さて、そのときに小田部さんから「感想をブログか何かに書いてもらえたらうれしいです。でも、この本の内容をブラッシュアップして、テスト設計コンテスト（以降テスコンと略す）の予選会に出す予定なので、予選会の11月5日までは（ブログ等の感想文を書くのを）まってください」と言われました。
その気持ちはわかりますので、11月に書こうと思っていたのですが、予選を通過してしまったので、「それでは決勝戦（2月23日）以降に書こう」と思っていたら今日（2017年3月17日）になってしまいました。
感想
1. 本書の構成
本書は
第一章 テスト設計の基礎知識
第二章 テスト設計の実例と解説
第三章 テスト設計の進め方
の3章構成になっています。
そして、それぞれの章末に、えびたこ氏のカラオケ小説が分割して掲載されています。
第一章では、第二章以降を理解するために必要となる小田部さんが考える「テスト設計」のプロセスと意義、そしてテスコンの審査ポイントに対する小田部さんの理解について書いています。
第二章は、本書の中心である小田部流のテスト設計方法をテスコンの提出物を使って解説しています。
第三章は、第二章の補足といいますが、TIPS集といった感じです。
2. 小田部流テスト設計
本書の中心である「小田部流テスト設計」の特徴的なところについて感想を述べます。
2.1 魅力の調査
テストベースの分析において「テスト対象（＝今回ならカラオケ）の利用者にとって『何が魅力』なのかを調査した」そうです。
とても良いと思います。
利用者だけでなく利害関係者（ステークホルダ）にとっての魅力分析も行うとさらに良いです（「欲しい」分析はしてはいるのですが、ステークホルダに対しては調査では無く推測です）。調査できないときに推測すること自体は悪くないのですが、その後のフェーズで事実なのか推測なのかについて曖昧になりがちですので注意が必要です。
ところで、テスト設計・実装にこの「魅力の調査結果」が活かされていない点が残念です。
本書を読む限り、テスト設計・実装では「仕様の検証」が中心で「調査した魅力が作りこまれたか」の確認の視点が少ないように感じました。テスコンの審査をしていたときに良く思ったのですが、それぞれのプロセスをみるといい感じであっても、全体を貫く幹が無いと残念感のほうが大きくなり評価が上がりません。
2.2 ステークホルダアクションの全体図
ステークホルダの行動を分析して全体像を作っているところはとてもよいです。
でも、いわゆる「業務フロー図」の作り方のセオリーを無視しているので粒度がそろっていなかったり抜け漏れが散見されます。
要求獲得技術の基本は抑えておいたほうが良いと思います。（もしくは専門家と協業するか）
2.3 Fujiブロック図
本書では、テストケースをテスト開発用に書き直す（最適化する）ことを推奨しています。
そのうちの一つが筆者が考案したFujiブロック図です。
Fujiブロック図は複数の機能の呼び出し関係と入出力がモデル化されたものです。
図にロジック（分岐条件等）は描かれませんのでFujiブロック図からテストケースを自動生成することは困難と思われます。たとえば「機能図式」のような既存のモデルと比較すると良いと思いました。
でも、Fujiブロック図自体は、手軽に描けてフリーに情報を書き込める点が実用的だなあと思いました。
ひょっとしたら「ブロック」という（比較的粗い）粒度で描くことで、抽象的なシステムが苦手な利用者やステークホルダーと一緒に描きながら、テストベースの合意を取るという使い方なのかもしれません。
なお「ハード」というブロックは「コントローラ」や「アイテム」のほうが良いのでは？と思いました。
2.4 マインドマップをロジックツリーにリライト
本書では、マインドマップでは観点漏れが発生するため、Excelを使用して表形式でロジックツリーに書き直すことを推奨しています。
そうすることで、手書きの良さと（表にすることでの）抜け漏れチェックのしやすさの両立をはかることができます。
しかし、二度手間（そんなに手間ではないですが）であり、現場に受け入れられるかな？と思いました。
そろそろ手書きマインドマップをスマホで読み込んで、その先の作業が続けられるようになるマインドマップツール（もちろん、逆方向もシームレスに変換するツール）が生まれてもよさそうです。
2.5 各種テスト技法
本書では、デシジョンテーブル、CFD、PictMaster、状態遷移図、そしてユーザー視点の非機能チェックリストとシナリオ等々の適用例が載っています。
ただ技法に当てはめる前の要素について「抽出した」という一言で終わっているため、読んでいてモヤモヤしました。
3. 全体を通して
全体を通して、自分のアイデアを隠すところ無く丁寧に書いてある点がすばらしいと思いました。「ここは俺様のノウハウだから書かない」といったところが無くてよいです。
ただ、記述の前後はあまり練られていないようにも思いました。どうしたら読者に伝わるかをもう少し考えるとさらに良くなると思います。
こういうテスト本ってこれまでありませんでしたのでユニークで貴重ですよね。
QCストーリー
この記事は、
TEFに投稿したけど無反応で寂しいぴょん
— きょん＠うさみみモード (@kyon_mm) 2017年3月2日
という書き込みを昨晩見かけて、「何を投稿したんだろう？」って思って、Gmailを開いたら「QCストーリー」についての投稿でして、これなら答えられるかもしれないと思って返信したものです。
きょんさんのメールには、
QCストーリーをやっている、やっていた。 という方がいらっしゃれば、参考情報や、QCストーリーでなかなか改善できなかった実情みたいなものを聞けたらうれしいです。
と書かれていました。
そうかー。『QCストーリー』なんて知っているのは、私の世代（1960年代生まれ）までかもしれないし（90年代にQC活動自体が大きく衰退したので）。
それじゃあ、本の紹介でもしようかなと思って軽い気持ちで石川馨の『品質管理入門』を開いたのでした。
確かに『QCストーリー』は載っていました。でも、本に書かれていたのはステップ名だけだったのです。
きょんさんがもとめていらっしゃるのは「実情」です。また、読書家の彼に今更イシカワ本を紹介しても「知ってるよー」と思われるに違いありません。
さて、「どうしよう？」と15秒ほど悩み、『そうだ、コンサルの場で使っているメモ（システム手帳に手書きしたメモ）を紹介するのがいいかも』と思いまして、鞄からシステム手帳を取り出しメモを見ました。
でも、それは、ものすごくいい加減なメモで、使い物にならなかったので書き下ろしました。スマホだったこともあり、誤記もあるので、それらを直しつつ、補足も加えてブログ化したのがこの記事です。
- はじめに知ってほしいこと
- QCストーリーって何？
QCストーリー - Wikipediaにあるように、「問題解決活動、または発表の手順」です。
その「問題改善活動の進め方」がQCストーリーなのですが、Wikipediaにあるとおり「発表の手順」でもあります。
でも、それは表向きの話です。QCサークルという小集団活動がありました（今も細々とありますが往時は全社を挙げての活動でした）。QCサークルでは、身近な職場の問題を自分たちの力で改善するのです。
「発表の手順」、、、違和感を感じてください。往々にして、こういう変な言葉のほうに真実が隠れています。そう。QCストーリーは「発表の手順」なのです。なお、課題解決型QCストーリーなど、いくつか派生型もありますが、ここでは触れません。QCストーリーと言えば問題解決型がほとんどだからです。 - 発表の手順ってどういうこと？
この2つのツイートは、TEFにメールした翌日に私がツイートしたものです。@kyon_mm では何故ストーリーがあるのかというと、QCサークル発表大会や上司への報告の時にわかりやすく、カイゼン活動に問題があったらそれを指摘しやすいからです。
— akiyama924 (@akiyama924) 2017年3月2日
メールに書いた「ポイント」について守られていなかったら「そこは直した方がよい」と言います。ぶっちゃけ上司用です。
要するに「好き勝手な発表をされても講評者（先生）は困るし、講評者から良いコメントも引き出せない」ということです。
だから、『QCストーリー』という定型化された作法に則って改善活動を報告しようと、そういうものです。
- QCストーリーの10ステップ
先の石川馨の本にQCストーリーの10ステップが載っていましたので、それにそって活動すべき内容を説明します。なお、世の中的には10ではなく8ステップが主流と思います。たいして変わらないのですが、気になる人はググってみてください。
- テーマ
テーマ選定を行いテーマ名を「xx におけるyyのzz」という文にまとめます。
ここで、
・ xx はwhereです。改善するスコープ（範囲）、背景、理由です。
・ yyはwhatです。狙い目や改善したいことの管理特性です。
・ zzはyyをどうするのかの、howです。活動目標などです。
例をいくつか書きます。
・ 新サービスにおけるリリース後の不具合の半減
・ コンポーネントテストにおける自動化率の倍増
・ OSSにおける信頼性の測定 - 取り上げた理由・根拠（パレートの原則）
このテーマを選んだ理由をパレート図を描いて説明します。
改善したということは改善前に問題があったわけです。問題は一つに限りません。たくさんあったはずです。多数の問題の中から「何故このテーマ」を選定したのか。
選択したテーマの価値が高いのことについて二・八の法則（パレートの法則）で説明します。 - 現状の把握（事実とその層別）
このステップのポイントは、事実をありのままに表現することです。
この段階でしてはいけないことはデータの加工です。平均値や分散を計算してその値で現状を把握してはなりません。
まずは、素直な目で素データに向かい合い、データの声に耳を傾けます。
具体的には、散布図を描いてバラツキを把握します。
描き方ですが、先に結果系となる縦軸を決めます。（結果系は、テーマのyyなので決まっているようにみえますが、QCストーリーは説明のためのストーリーですので、テーマ名は最後に決まります。この段階では漠然とした問題意識があるだけです）
さて、yy は漠然と感じている問題から持ってくるので簡単そうにみえますが、案外データを取ってみると意外な結果となることが多いものです。
たとえば「テスト時間が長いなあ」と思ってデータを取ると一日3時間しかテストしていなかったり。
良い感じにデータがばらけているyyを見つけたら次は横軸探しです。
横軸は原因にあたります。原因が分からないので困っているわけですから、思いつく原因候補を横軸にとって縦軸は同じにして、何枚も散布図を描きます。
縦軸（結果）を従属変数といい、横軸（原因）を独立変数と呼びます。
独立変数は自由に選べますが、従属変数は自由に選んだ独立変数により決まります。 y = f(x) の関数のyが従属変数、xが独立変数です。
さて、散布図を描いてどうするかというと、層別します。
散布図の中に固まりが見えるものがあればラッキーです。固まりは因果関係がある証拠ですので、原因が見つかったも同然です。
あとは、外れ値を捨てて絞り込みます。 - 結果および工程の解析（要因の追求）
3の後半で実施した散布図を何枚も描いて層別する作業のことです。 - 対策・実施
ここでは、対策の中身もさることながら、改善目標を立ててから対策を実施することが大切です。小集団活動なのだから目標を決めずに果敢にアタックしたほうが良いと言う意見もあります。失敗を許容しようと言う考えです。
ただ、効果確認をするためにも私は目標は立てたほうが良いと思います。無理しなくても達成できるものにして達成感を味わうほうが良いと思うからです。
改善目標は、「何を」、「どれだけ」、「いつまでに」を決める（計画を立てる）ことです。実施は計画に従って進めます。 - 対策の確認
書籍には、「対策の確認」と書いてあるのですが、一般的には「効果の確認」と呼ぶほうが多い思います。
対策をして、効果が出なかったときには因果関係の判断ミスがあったということです。そのときは、3に戻って、横軸探しをやり直します。
特性要因図という図があります。マインドマップと同じようなものです。それらを作って要因候補を見つけます。
簡単ですぐに効果確認出来る場合はすぐに実施すれば良いのですが、そうでない場合は実施が無駄にならないように先に因果関係のありなしを測る予備実験をします。
いわゆる実験計画法を使います。分散分析をして少数の実験で因果関係を確認してからステップ5の実施に戻ると無駄な実施を減らすことが出来ます。 - 標準化(歯止め）、再発防止
PDCA のAct/Actionです。KPTのKと言ってもよいでしょう。上手くいったことを次のプロジェクトや周りのチームでも使えるように、マニュアル（標準書という場合もあります）にまとめます。 - 管理の定着
一般的な論文では、ステップ8以降はありません。
QC ストーリーは結果が良ければ全てよしではなく、仕事のしかたを重視しますのでステップ8以降も大切です。
標準化したものが守られているか？
と言うよりも、きちんと標準化したものが改訂されてみんなが使っているかをみます。 - 反省と残された問題点
改善に終わりはありません。同じ仕事をしているようでも時代が変わりますし技術も進化するからです。だから残課題の整理は重要です。 - 今後の計画
9で残課題の整理ができたらステップ3に戻ってスパイラルアップです。
PDCA を回すってやつです。
QC ストーリーの進め方は以上です。
この結果をA3・1枚にまとめて上司を含め他人に理解してもらうまでがQC活動のワン・ターンです。
イーソルトリニティ 機能安全セミナー
2016/7/22（金）にイーソルトリニティ株式会社主催の「ISO 26262機能安全統合ソリューションツールmedini™ analyze セミナー」へ参加してきました。とても興味深いセミナーでしたので内容のごく一部をご紹介します。
オープニング
オープニングは、主催者であるイーソルトリニティ株式会社の上山伸幸社長による会社紹介です。
もともと1975年にエルグ株式会社として設立されたイーソルという売上54億41百万円（2015年度）、従業員数366人（2015年度）という会社があり、2015年にイーソルトリニティ株式会社、2016年に株式会社オーバス（デンソー＋イーソル＋NEC）を設立しました。
と、ここまではニュースや記事で知っていましたが、3社のミッションの違いについてはよくわかっていませんでした。簡単に言うと、本体のイーソル社がリアルタイムOS（RTOS/AUTOSAR）やRuntime Softwareを担当し、イーソルトリニティがRuntime Softwareを使いこなすための教育とツールとコンサルティングを担当し、オーバスがデンソーの車載電装品技術とNECの通信技術とイーソルのRTOS技術を活用し自動運転などの成長領域のプラットホームライセンスや支援サービスをおこなうとのことでした。
そうそう。RTOSの領域でも8コアなどのマルチコア、さらにMany-coreの世界になってきているとのことでした。こういう最先端技術を取り扱うということでワクワクしますね。
基調講演
基調講演は今回のセミナーの目玉であるmedini analyzeツール開発もとのDr.Eckhardt Holz氏によるものでした。
medini analyzeツールは、簡単に言うと、車載システムの安全性を保証するためにISO 26262（自家用車の安全規格）が求めていることができるというものです。
特長は「単一情報方式」である点で、何度も強調されていました。
「単一情報方式」とは、入力した情報は、さまざまなツールで使いまわすため一貫性ある品質保証ができるというものです。さすが欧州のツールです。
事例紹介
パナソニックAISの藤山氏からISO 26262への取り組みの様子とmedini analyzeツールを使用した事例紹介がありました。
とてもわかりやすい説明でした。
興味を引かれたのは「OEMとサプライヤの開発分担と開発の流れ」の説明でした。「機能安全コンセプトの策定」まではOEM側の責任という境界線があるものの、昨今はサプライヤにその部分、いえ、その上の「機能安全要求」から受け持ってもらえないかとの要求があるそうで、要求仕様までがOEM、実現手段の設計はサプライヤという昔のプロセスではなくなったのだなーと思いました。
ただ、ツールの活用については（わかりやすく説明するために話を省略されたのだと思いますが）「フォールトと故障の因果関係を入力するとFMEAが自動生成される」といったことをおっしゃっていたのでちょっと心配になりました。
イーソルトリニティのコンサルティング活動
今回、このセミナー参加の動機となったセッションです。イーソルトリニティの宿口さんの講演を聴きたかったのです。
内容は機能安全活動を支援するとはどういうことかがよくわかり、また、見識の高さに舌を巻きました。参加してよかったです。
ライセンスについて
最後はツールのライセンス形態や価格のご説明がありました。
ということで、車載システムの機能安全についての概要と最新ツールを見ることができて満足です。今後もセミナーが開かれる予定とのことですので興味のある人はこちらのサイトにアクセスされると良いと思います。
Yacttのご紹介
Yacttとは
Yacttは“Yet Another Combinatorial Testing Tool”のことで尊敬する居駒さんが趣味で？作られた組合せテスト（Pairwise）の表を自動生成するツールです。
以下のウェブサイトにアクセスすると誰でも使えます。
https://yactt.herokuapp.com/yactt/home
Yacttの使い方
上記のウェブサイトにアクセスしたら説明なしでわかります。
とはいえ、簡単に説明しますと「Specify PICT parameters」のテキストエリアにPICTという有名なPairwiseツールの形式でパラメータ（因子（水準））や制約式（水準間の禁則規則） を入力し、下のほうにある【Generate Test Data】ボタンを押すと一番下に表が出力されるというものです。日本語もOKです。日本語を含むものをファイルから読み込む場合は文字コードをUTF-8でとしてセーブしておきます。
Yacttの仕組み
生成エンジンとしては大阪大学の土屋先生が開発したCIT-BACHが使われています。
なお、GitHubにあるソースをダウンロードすれば、PICTクローンとして動きます。
Yacttを使ってみよう
習うより慣れろです。まずは、PICTのマニュアルにある以下の内容をコピペしてボタンを押してみましょう。
Type: Primary, Logical, Single, Span, Stripe, Mirror, RAID-5
Size: 10, 100, 500, 1000, 5000, 10000, 40000
Format method: quick, slow
File system: FAT, FAT32, NTFS
Cluster size: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536
Compression: on, off
IF [File system] = "FAT" THEN [Size] <= 4096;
IF [File system] = "FAT32" THEN [Size] <= 32000;
下のほうに組合せテスト用の表ができます。
Yacttウェブの「Set execution parameters (option)」のところで生成オプションを設定できます。
Solver
SolverはPairwise表を生成するツール（生成エンジン、生成アルゴリズム）の選択です。ウェブではCIT-BACHというBDDソルバアルゴリズムしか選択できない（2016/07/15時点）ようですが、ソースをダウンロードしてがんばれば別のソルバを使用することもできます。
でも、ソルバとしてはCIT-BACHがよいと思います。
Pair Strength
Pair Strengthは、いくつのパラメータ間の組合せまで100%にしますかということです。2を選択（デフォルト）すれば任意の二つのパラメータを取り出したときにその値の組合せが全部テストされる表（オールペアの表）ができます。
