JaSST関西’18に行ってきた話（セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」編）

セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」

http://www.jasst.jp/symposium/jasst18kansai/details.html#S3A-3

JaSST の話題もいい加減古くなってしまいましたが、あまり気にせずに続けたいと思います。（まだ公式のレポートページもできてないことなので）

セッション3A-3は「お互いが納得感を得られるソフトウェアテスト思考の因子」ということで、特定の技法や技術というよりは考え方や心構え的な話でした。けっこう普段感じているようなことと同じようなシチュエーションが出てきてドキリとさせられるエピソードなども結構あったように思いました。Jasstは基本的にテスト設計やテストアーキテクチャを志向している講演が多い印象なのですが、こと関西（って関西しか参加経験ないですけど）においては結構テストマネジメントな話題もちょいちょいある感じですね。

講演者の杉本さんは現在京セラドキュメントソリューションズにお勤めで、その前はソフト開発会社でテスト業務の受託などもされていたそうです。なので、メーカーと請負の双方の立場を経験されていることになります。

講演の背景として、ネットワーク化が進み、また製品も単に提供されるだけではなくて、サービスやソリューションの一部になるということが年々増えており、システム同士がさらに上位のシステムを構成するというシステムズエンジニアリングなんてことが言われるようになっているという状況があります。ここで演者は問いかけます。「システムとシステム、モノとモノのつながりを論じる前に人と人のつながりはどうなっていますか？」と。

意外と価値観や意識の差があるままコミュニケーションしてませんか、というわけです。そのあたり、納得してコミュニケーションすることが必要だよね、という趣旨でどういうような要素があるのか、ということをお話する、という趣旨の講演でした。

というわけでステークホルダーとの関係構築に必要なスキルや心構えについて話が進んでいきます。一例として欧米やインドの話が出てきて、日本に比べるとより低コンテキスト、言われていることはきっちりやるけれど、それ以上は・・・。というようなエピソードが語られます。このあたり、別にどちらがいいというわけではありませんが、少なくとも日本風のコミュニケーションを期待していると痛い目には遭うので、そのあたり納得ずくでコミュニケーションしないと、というのはそのとおりだな、と感じました。

話はそういったコミュニケーションに必要な資質、というところになっていきます。このあたり内容の性格上、なかなか明確に言葉で定義するのが難しいこともあってか、事例に関しても

• センスのない例
  • 会話中に関係のない話をして何の話かわからなくなる
  • アウトプットがインプットに完全に依存している
• センスのある例
  • 御用聞き的な働き
    （＝不足している部分を見つけ出す、ってことですかね？）
  • ステークホルダー間のつなぎ
  • 想像力
  • 仮説思考、水平思考
    （＝これは課題にあたったときに止まってしまわないということかな？）

というような感じで少々エモい感じの表現になってます。

そして最後に出てくるのが『ゴッドハンド資質』なるもの。私の場合、テストでゴッドハンドと聞いて思い出すのはこれだったりします。

テスト設計コンテスト2013 関西地域予選 招待講演 - YouTube（28分55秒のくだり）
https://www.youtube.com/watch?v=zhIk9G7S1Ok&t=28m55s

といっても別にdisっているつもりはありません。一方で実感としてはわかります。何をやってもスジのいい人、というのはいてはります。ゴッドハンドにしてもスジのいい人にしてもその影にはそれなりの理屈なり何なりがあってある種必然的にうまくいっているわけですが、外側から見ている人にそれがすべてわかるかというとそれはまた別の話でして、十分に発達した科学は魔法と見分けが・・・というアレでしょうか。そんなわけで、そういったものを集めて分析する上で仮に「ゴッドハンド」とラベリングして貯めておく、コレクションする、くらいの感覚で捉えるのがいいのかな、と思いました。少なくとも『よーし、ウチでもゴッドハンドを育成しよう！』というのは私には無理だし、社内の他の人がやるにしても成功しない気がします。仮にできたとしても職人的になるでしょうから育成スピード的に見合わないのかなーとか。

話はもう少し具体的になっていって、今度は実際にテストエンジニアに必要な資質を

ヒアリングしてみた、という話題になります。出てくるキーワードは 

• 論理的、批判的
• 多能工（他人の領域にも踏み込んでいく）
• 理論的、理想思考（若手の場合、という条件がついていました）
• 論理的、現実思考（マネージメント層の場合、という条件がついていました）
• テストエンジニアに大丈夫と言ってほしい
  • テストの一般化
  • 客観的事実の積み上げ
• 設計者の後追いでないテスト
  • 独立した観点（ロバスト性、と言われていましたが、外乱に強い、というのとはちょっとニュアンスが違う気がします）

 という感じでした。一部独特な言葉づかいなところがありましたが、例えば「理論的、理想思考」というのはToBe志向（～であるべき）ということかな？逆に「論理的、現実思考」というのはAsIsとまでは言わないまでも、よく言われる地に足のついた、という感じでしょうか。

同じくテストの一般化、というのは多分、ですが「世間で言われているスタンダードなどに照らして妥当であることを説明してほしい」、みたいな感じでしょうかね。割とよく聞かれますよね「それってお前理論ちゃうんか？標準とか、なんかないの？」みたいな感じで。わかります。

さて、そんな理想に近づくにはどうすればいいのでしょうか。

演者は、テストエンジニアと開発者はやりとりしているようで、実はテストエンジニアから開発者へは指摘なり要求ばかりの1wayな関係ではないか、と指摘します。なので、それにとどまらない多様なoutputを開発者に提供することで、この一方通行を改善してコミュニケーションをよくできるのでは、と言うわけです。例えばテスト手法とか問題の切り分け方などでそういったことができるのではないか、ということでした。これも感覚的にはよくわかります。「開発者にナメられないようによく勉強しましょう」とか、「一目おかれるテストエンジニアになれ」みたいなことでいいのかな？問題はどうやったらそうなれるか、わかんないってことですけども。このあたりは簡単な答えはないのでしょう、きっと。あとは自らパイロット運用して背中で語る、とかアウェーに身をおいて常に鍛える、などのことをおっしゃっていました。逆に上司への要望としては「上げた技術力に応えてほしい」「知識ではなくてアイデアを示してほしい」というようなことを挙げられていました。

全体的に課題を共有する、という感じでしたので、「よーしこれでわかったぞ」という感はないのですが、だからといって講演として良くないわけではなく、なかなか共感するところが多かったです。

「メーカーの人は作業が少なくなるのはいくら少なくなってもなーんにも言わないんですけどね、請負になると”稼働”の問題があってまた全然違うんですよねー」とかいうエピソードもワタシ的には “Exactly.（そのとおりでございます）” としか言えないし、（あるべき姿なのかどうかはさておき）非常によく分かるところです。どちらかというと講演というよりは懇親会でオフレコ話を聞かせてもらうといいのかもしれないな、とか思いました（笑）

JaSST関西’18に行ってきた話（セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」編）

もう記憶が遠のきまくりですが、JaSSTの話の続きです・・・。

セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」

http://www.jasst.jp/symposium/jasst18kansai/details.html#S3B-2

参考：https://www.veriserve.co.jp/event_seminar/2018/jasst_2018_kansai.html

3B-2ということで、並行セッションの２コマ目は設計セッションから選択してみました。（クロージングのときに実行委員の方から設計セッションと管理セッションの分類にはそれほど深い意味はない、と暴露されてしまいましたが・・・）

このセッションでは設計は設計でも「不具合分析」からのテストの「補強」です。

これは結構私の業務上で時々ある話でして、どんな流れでこういうパターンになるかというと、まず思うように品質が上がっていかない状況で開発の後半で思わぬ不具合に遭遇します。そうなると、「こんなのが出るってことは他にもチェックが甘いところがあるんじゃないか？補強を考えてくれ」ということになります。なるのですが当然内容をどうする、という段で今現在漏れがあるので、今のテストの延長ではちょっと、ということになって何か不足している観点なり切り口をどこからから入手できないか？と悩むのが次のステップ。そしてそうそう自分たちの抜けが意識できるわけもないので壁にあたると。で、なんとか手近なものからということで、例えば下流工程から指摘をくらっている不具合を分析して先回りできないか、みたいな話になるという感じで不具合分析に追われた経験持ちの私です。

なので結構このコマ興味ありまして、選択してみた次第です。

 ですが、「ロジックツリー」が少々独特でした。ロジックツリーというとものごとをMECEに枝分かれさせて分解していくやつを思い浮かべると思うのですが、この講演でいうロジックツリーというのはNGTのことでした。NGTというのはNotation for Generic Testingの略で電通大のにしさんの提唱しているVSTeP（Viewpoint-based Software Test Engineering Process）で使用する記法ですね。

お、じゃぁこの不具合分析はVSTePでやるのかな、と思ったのですが、どうも聞いていると記法を利用する、というスタイルのようです。でもとっつきやすさという意味ではそのほうがいいかもしれないな、と思いました。（とはいえNGTに親しんでいないので、この後の説明の理解に難儀しましたが）

（講演資料が今のところ公開されていないので、文章だけではちょっと伝わらないかもと思いつつ続けます・・・。）

そして何をツリー化するのかというと不具合の要素、ということでした。これがまたなかなか曖昧な感じですが、例えば

「バックグラウンドへ遷移したアプリに30秒以内に復帰した際に、再生コントロールが正しく動作しない」

という不具合だと「バックグラウンド遷移」「再生コントロールが正しく動作しない」「30秒以内」あたりが要素ということになるようです。なんとなくは分かるのですが、他人にうまく説明できるかというとできないなぁ、という感じ。講演中の補足を引用すると

• 発生しない条件と発生する条件の差異を抽出する
• 環境－前提―手順（＝トリガ）―振る舞い　を意識する

というあたりがポイントのようです。

そしてここで例になっている「30秒以内に復帰」に関して、実際の不具合例では17秒以上経過すると問題があるということがわかって改修した箇所、という説明があったので、ちょっと引っかかって質問してみました。

『なぜ17秒ではなくて30秒を要素として抽出するのか？』と。

私が思ったのは、「17秒が境界として存在するのであればその周囲を狙うのが不具合分析としては素直なのでは？」ということだったのですが、回答はちょっと意外な方向から来ました。

「我々は第三者検証会社なので不具合に関してその後の情報を得られることが少なく、なので改修に際して得られた情報はこの取り組みでは使用しない方針にしています」ということでした。

・・・。なんだか申し訳ない気持ちになってしまいました。私はたまたま不具合改修内容も確認できるような立場で業務をしているのですが、不具合報告しっぱなしでその後のフィードバックがないことも珍しくない、というのは少々衝撃的でした。そんな業務形態もあるのね・・・。

（実際にはこの例でも改修情報についてコメントがあったくらいなので、全然情報が無いわけでは無いでしょうし、得られた範囲で情報使っているとは思いますが、それにしてもなかなか・・・）

と、話をもとに戻して要素をNGTでツリーにする話。

ただ、前述したようにNGTの予備知識が無いので、このあたりが理解に難渋しました。

そのあたりは置いておいて、要素間の関係としては以下の4つがあるそうです。

• And
• Then
• After
• Behavior

多分このへんは全然わかってなかったので今後もしっかりフォローしないとダメだな・・・(泣)。

ついで要素をつなげていきます。このあたりもなんとなくな雰囲気になるのですが

• 画面状態とある機能が動作している状態
• 画面状態の遷移
• 画面状態と各操作
• 端末種類と各種操作

あとはこれをフレームワーク（環境―条件―状態―操作）に当てはめるということで新規なテストケースにしていきます。

要素を新たにつなげたルートをフレームワーク上でたどるといいようです。

まとめとしてはこの手法である程度不具合を追加で発見できたこと、また、実施タイミングとしては進捗が75%くらいのところでやるのがいいよ、ということでした。

感想としては

　まずはこの方法をやるのであれば、NGTちゃんと勉強しないといけないな。

（実際演者さんの会社ではにしさんをお招きして勉強会したそうです）

というのと、もう少し要素の抽出方法や組み合わせ方を言語化というかきっちりさせたいなぁ、というあたりでしょうか。似たようなシチュエーションに遭遇することがあるので、非常によくわかるのですが、うまいこと機能や状況をシステマティックに組み合わせるというとろまでもう一歩な感じのもどかしさを感じました。多分講演した本人が一番そのあたりは実感されているのではないかという気がします。「コツ」という表現をされていました、できれば使いたくない、と思ってそうだなーと。

ETwest2018に行ってきてみずのりさんの講演を聞いてきた話

Jasst関西の話をまだ全部書いてないのですが、大雨のなかETwestに行ってきました。

目当ては以下のカンファレンスです。

「なぜ組込みシステムにおけるテストは難しいのか」

水野 昇幸氏（株式会社Codeer ソリューションエンジニアリングマネージャ）

http://www.jasa.or.jp/etwest/conference2018/confpage-hu05.html

資料公開されたのでURL追記しておきます（2018/08/11）

https://www.slideshare.net/NoriyukiMizuno/etwest2018

時間をかけてレポート書いてもそんなに熟成している感じがしないので、今回は逆にささっと感想書いて聞き取ったメモをそのまま貼り付けてみようかなと思います。

[感想]

• 「アーキテクチャ」と表現するのがいいのかわからないが、受けが良いときもある、というのは少々泥臭い香りがしましたが、名を捨てて実を取るというか、結果にコミットする的な姿勢なのかな、と思いました。プロとしては重要ですよね
• どうして○○できないの？という言い訳が出た時、言い訳には内在している問題が含まれているので整理してうまく解決すると改善につながる、という話はなるほどと思いました。このあたりはTOCの考え方（UDE→DE）的なものも感じました。
• 正直なところ、コスト感が大とか効果感が薄いというのは割と心理的な話だったり、マネージメント系の話なので、設計でなんとかなるのかなぁ、と思いつつ聞いていたのですが、モデリングなどして見えるようにできるんだよ、見えるようになれば見積もりいつもやってるんだからできるでしょ、というのは新鮮な印象がありました。
• ２つのアーキテクチャ（テストシステムアーキテクチャとテストスイートアーキテクチャ）ですが、私はテスト寄りなこともあって、せいぜいテストスイートアーキテクチャ（それもきちんと意識できているかは疑問）的なものしか頭になかったのですが、設計を拡張する形でテストシステムアーキテクチャを考えれば攻めどころがわかりやすくなる、というのはなるほどなと思いました。このあたりもボトルネックを攻めるということでTOC的な風味を感じました。
• あとは自分がこの内容をどう活かすかだけど・・・・

以下はメモ。あまり整理されてないので読みにくいでしょうが、無いよりマシという程度に。（悪天候で行けなかった、という人に役立てばいいのですが、伝わるかどうか・・・。）

「なぜ組み込みシステムにおけるテストおよびテスト自動化は難しいのか」

イントロ

• タイトルに「自動化」を直前で追加した
• Codeerブースで自動化ツールご紹介しています
• https://www.codeer.co.jp/
• 組み込みテストは難しいとよく言われるが、それを整理して改善の一助にしたい
• 組み込みといっても幅が広いので直接解決にならないかもだけど、ヒントになれば
• 終了後にCodeerブースでテストに関するご相談受け付けます

自己紹介

• 現在はCodeerに在籍しつつ、個人でも要件定義やソフトウェアテストの支援をしている
• 北海道メインですが、日本中あちこち行ってます
• テスト設計コンテストというのがあってそれで優勝しました
• ソフトウェアテスト関連、TOC（Theory of Constraints）関連でけっこう発表実績あります

テストが難しい

• 「テストをより効果的にせよ」「自動化を推進せよ」「コストダウンせよ」と上から言われたら？
• 言い訳が出がち
• でも言い訳をうまく整理すれば課題が見えてくるかも
• どんな言い訳が出る？
• システムが複雑
• どこテストしていいのかわからない・・・などなど
• 集めて分類してみると以下のようなものになりそう

1. 対象がそもそも複雑
2. ツールにコストがかかる
3. テスト実施の難しさに対処できない
4. 効果を感じることができない、効果感うすい

実際のところ何が難しい？

• 話が噛み合わないことがある。人によって「組み込み」と言ってもいろいろ
• これも整理してみた
• 今までに無いものを達成しないといけないというパターン
  どうやってテストしたらいいのかわからないという問題
• 多数のインターフェースが存在するというパターン
  システムが複雑でテストが大変という問題
• システムはなんとか開発できているのだが、派生と改良したようなシチュエーションで、多彩なパラメータに対して安定性が求められるパターン
  要求されるレベルの信頼性を検証するとなると開発に対してテストのコストが見合わないという問題

このままでよいの？

• 組み合わせテストや結合テストで停滞してませんか？
  見込みより大幅に遅延する
• テストで妥協してませんか？
  大量過ぎ、手間かかりすぎということで妥協する。「代表的なパラメータで大丈夫でしょ・・・」
  効果が感じられないテストだとなおさら妥協してしまいがち
  でも後で不具合が出てギャフンとなる
• 全部はテストできないので辛い問題。マネージャー視点だと手間かかる＝札束飛んでいく、ということでもある
• どうやって対応しているか聞いてみた

1. オフショア（同量の作業を安く上げる）
2. 探索的テスト（同じ手間でより多くの効果を得る）

• 現状で十分って人もいるかもしれない
• でもずーっとそれで大丈夫？
• リリースサイクルはどんどん短く
• 繰り返しの負担感がだんだん重く
• となると妥協発生しやすくなっていく・・・

世界的な潮流

• Googleは420万の独立したテストを1日あたり1億5000万回実行している（Jasst’18 Tokyo基調講演）
• Facebookは１００人体制で開発していて２週間おきにリリース、ユーザーは１００万人。マニュアルのプロセスはスケールしないため自動化ナシはありえないと断言、10%のエンジニアが自動化に従事（ICST2018）
• これらはWEB業界の巨人の話ではあるけれど、組み込みでも同じ方に風が吹いている。どこかでマニュアルテストはありえない、となるところがやってくるはず。
• なので組み込み業界でも効率的、自動的な仕組みが必要
• 実際にエリクソンなどもそちらに変化してきている。日本だけ今のままマニュアルテストで許されるのか？？

提案の方向性

• 演者の経験として、サブシステムからなるシステムの一番問題のある箇所だけをツール入れて効率化したらそれをきっかけに良い方に回りだした（手間が減る→浮いた手間で自動化→テスト実施量増えて不具合減）ということがあった。なので一部だけに導入する、というやり方でも効果はある。
• また、組み込みとはいえ普通は操作用のツールが存在するのでそれを自動するというようなアプローチが考えられる。
• 結果判断は人力、としても結構効果が出たりする
• ただ、それとは系統の違う課題もある（＝テストの手間の問題ではなくて、テストの効果が薄い、という問題）
• その場合はテストケースの量ではなくて質的な改善が必要になる
• どちらから着手するか、は皆さん次第だが、整理して分けるだけで渾然一体となっているときに比べて行動しやすくなるのでは？

２つのアーキテクチャ

テストシステムの改善（テストシステムアーキテクチャ）

• テストの手間を減らすためにはテストシステムを考慮した改善が必要
• 例えばシステムの設計時にはほぼ必ずモジュール分けやインターフェースを検討するための絵（モデル）を描いているはず
• これを拡張してテスト実行ツールやテスト環境も含めて描いて検討しましょう、という話
• 時間さえ確保できれば現状の延長にある話なのでできるはず
• 記法としてはUTP（UML Testing Profile, https://www.omg.org/spec/UTP/About-UTP/ ）なんてのがあります
• 例えばテスト設計コンテストの題材のカラオケシステム
• どこまでテストするのかを考える、作り込む必要がある
• SUT（System under Test）としてカラオケシステム、周辺のテストコンポーネントとしてリモコンのシミュレータとか、ログ確認ツールとか、楽曲DB制御ツールとかとか。これらを書きながらテスト環境の構成をかんがえていき、テストシステムを設計する
• 絵を書くと見積もりができるはず（普段システムエンジニアはそうやって見積もりをしているので同じようにすればできる）
• 見積もりができればコスト感や効果感も判断がしやすくなるはず

テストスイート（＝テストケースの集合）の改善（テストスイートアーキテクチャ）

• テストケースを表すアーキテクチャ
• テストケースの意図
• テストケースで保証できる範囲の説明など
  を表す構造。テスト設計コンテストで提案されているものはだいたいテストスイートアーキテクチャと言えるのではないか
• 例えばテストカタマリー
• テストベース（仕様書）から導かれるものがあったり
• そうではないが必要なテストをまとめてグルーピングしたり
• テスト対象の機能によってパラメータがどのくらいあるかなどを整理して考えられる
• 階層的な表現も可能
• テストケースの構造を示しながらここで何を保証するのかと言うモデルを表現できる
• 他の例
• VSTeP
  http://qualab.jp/vstep/
• TestAspect
  http://aster.or.jp/workshops/insta2018/img/InSTA2018-Proposal_for_Enhancing_UTP2_with_Test_Aspects.pd
• テストスイートアーキテクチャを導入することで
• 俯瞰しやすい
• 段階的に思考過程を表現できてレビューしやすい
• 類似プロダクトにも応用しやすくなる

更に両者をくみあわせてみた

• テストシステムの構造をUTPで記述
• テストケースをTestAspectで記述
• ○○のシステム（ツール）が用意できるとこのテストケース群が実行できる、というようなことがわかりやすくなる
• コストをUTP使って見積もって、効果をTestAspectで見積もる、なんてことができるようになる
• テスト環境をテストシステムアーキテクチャ、各段階のテスト内容をテストスイートアーキテクチャで考えると便利。試作段階ごとに考えたり、というようなことが容易に。

まとめ

• ２つのアーキテクチャでよりよいテストを実施していきましょう

JaSST関西’18に行ってきた話（セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」編）

 セッション3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
https://www.slideshare.net/keinakahara3/ss-102572276

似たような会社に勤務しているというところもあり、気になっていたセッションです。講演者の中原さんは豆蔵やチェンジビジョンを経て2012年にコニカミノルタ入り。この講演は老舗の製造業系事業会社勤務の人向け、ということで私は対象ど真ん中な感じですね。

コニカミノルタさんはご存知写真がメインで創業事業ですが、今やそれはやっておらずという状況で、これからは業界や分野を越えた新事業が必要だ、というのがおおまかなバックグラウンドになります。ということで、経営のトップ階層からは「何か儲かる新規サービスを開発せよ」というお題目。ありがちです。私の周りでも年中聞こえてきます。新規サービスといっても難しい。

何が難しいか、中原さんは以下の２つを挙げます。

• 何が売れるのか不明（＝プロブレムソリューションフィット）
  開発するソリューションが顧客の課題を解決するのかどうか、という点だそうです。なにかにつけては手持ちのソリューションをねじ込んでいき、あまり満足いただけない、みたいなことをよく見聞きしますね。
• （売れたとして）儲かるのか不明（＝プロダクトマーケットフィット）
  こちらはちょっとピンと来なかったのですが、ソリューションとしてすごくいいんだけど、個別過ぎてとか、対象が限られすぎてビジネスとして成長できない場合があって、そういう場合は売れても儲からない、となるそうです。（成長できない＝売れないって気もするのですが、伸長していかない、というのが適切なのかな）

特にこの講演では前者を対象とするようなのですが、難しい以上「迅速に仮説検証しながら育てていく」進め方が良い、と中原さんは言います。スライドには「リンスタ/アジャイルやん」と書かれています。そんなことは自明と言わんばかりの書き方ですね。確かに最近の流行で言えばそうなりそうですが、これが老舗メーカーでは難しいと。ようやく本題に近づいてきました。

で、老舗メーカーでは何が難しいのかというと、「組織構造と文化」が問題とのことです。セクショナリズムとか「これまでやってたから大丈夫だろう」みたいなことですね。これをなんとかしようということで、中原さんがやられたのが

• チーム構成とマインドセットを変える
• 開発の進め方を変える
• 品質保証方法を変える

の３つということでした。

組織構造と文化により発生する具体的な問題としては２つあって、以下を挙げられていました。

• 「役割によってゴールが違う」問題
  企画の人は企画を考えるのがゴールであり、ソフト開発は要求どおりのソフトをQCD守って作るのがゴール、というわけです。なのでコミュニケーションもうまくいかないし、そもそもうまく合意に到達できるわけもない、と。
• 「情報劣化や誤解」問題
  ボールを投げるんだけどグレーゾーンがあってうまく伝わらない問題。「言わんでもわかるやろ」と「書いてないやん」が飛び交うというわけです。これは心当たりもあり、わかりやすいですね。

で、これをなくすために組織構造と文化を変えるということで、組織構造を変えるというのが壁をなくす、文化を変えるというのが「あとはよろしく」とか「ここまでが僕の仕事」というのをなくす、ということに相当すると。

徐々に核心に近づいていく感じです。組織の壁を取るために部門を横断したチームを構築したということを紹介されていました。いわゆるスクラムチームというやつで、企画部門がPO、開発部門がDev/ScrumMasterとなるようなチームを作ったそうです（外部からコーチを１名入れて、それが中原さん自身、ということでした）。正直なところ、それをどうやったのかとかいうあたりを聞いてみたかったのですが、そこはバッサリとカットされている感じでした。

参考としては https://www.slideshare.net/keinakahara3/ss-81883094 が挙げられていました。

ちょっと肩透かしをくらった感はあります。でもまぁ落ち着いて考えると、こんなもんは一念発起してやる以外にうまい手なんてないんですよ、という話なのかもしれません。参考資料のスライドの最終ページにも「勇気＜覚悟」って書いてあるし。言っちゃなんですが、私なんかは勝手に問題が解決することだけを期待してぼーっとしている部分がないといえばウソになるでしょうし。やっぱり行動しないといけないんだろうなぁと・・・。

やや脱線しましたが、文化の方の話にもどります。こちらはこれまで要求ありきだったのをみんなで考えるようにしたと。ソフト屋さんは脱御用聞きでチーム全体で要求そのものを開発するんだ、ということでした。そのためには開発者もビジネスを知らなければならないと。なのでビジネスの状況を共有したり、ビジネス上の仮説をカンバン化したり、リリースの狙いをボードにして共有したという事例が紹介されていました。

もう少し具体的な手法の説明としてはやや用語というか手法の名称先行な感じではありますが以下のような順で進んでいきます。

1. 利害関係者の特定
   インセプションデッキ/ステークホルダーリスト
2. ターゲットユーザーの共有
   誰が使うのか
   ペルソナを使用
3. 顧客課題の共有
   カスタマージャーニーマップ（ASIS）
   UXベースで考える。不満は何かの機能に偏在しているのではなく、そこに至るまでの体験にも左右されている。
4. 提供価値の共有
   カスタマジャーニーマップ（TOBE）
5. 最小限の提供価値と実現範囲特定
   ユーザーストーリーマッピング

と書き並べてみたものの、（アジャイル関係に明るくない私には）さっぱりわかりません。このあたり手法としては有名なのである程度名称だけで話が通じる前提で講演が進んでいく感じでした。とりあえず用語関係、結構しっかりフォローしないと理解が難しそうです。

なんにせよポイントとしては

• 誰のどんな課題をどのように解決し、どんな効果を狙っているのか
• そのために何をどこまで作るか

という2Stepであると説明されていました。特に仮説検証のための最小限以上のものは作っても無駄になる、というのが印象的でした。確かに間違っていたときの被害を最小限にするためには余裕があるからといって作りすぎは良くないですが、なかなか実行するとなると難しいですね。あれこれ積んでしまいがち。

講演内容が「アジャイル型要求開発」なので、あとはこれを繰り返すだけ？と思いきや続きがあります。『サービスとアクターのインタラクションしか表していない』ので、足りないと中原さんは言いますが、これまた勉強不足なのでその表現だとさっぱりわかりません。もう少し具体的には「機能横断的な非機能要求がカバーできてない」。これならイメージできそうです。負荷とか応答速度とかそういうやつですね。この辺次第でアーキテクチャはいくらでも変わるので、その辺を抜きにして要求が十分かというとそうではないということですね。なるほど。

でもまだ足りないと話が続きます。最後に出てくるのは「価値提供に値する品質なのかどうか」。品質、これがまた難しい用語ではありますが・・・。これに対するアプローチとして品質に精通している人に協力してもらうというのが出てきました。ちょっとJaSSTということで取ってつけたのかな？という気もしましたが、そうでもなさそうです。

参考に挙げられていた https://www.slideshare.net/keinakahara3/ss-81883094 でもそうですが、開発をアジャイルにしてもQA以降はプロセスが定義されていてウォーターフォール的に、というのは私の周りではちょいちょい目にします。最終製品としては出荷タイミングがあるんだからそれを基準に社内イベントを、というパターンですね。でもそれはこの講演の趣旨から行けば壁を容認することになるわけでダメですよね。となればQAを巻き込んでしまえというのはある意味自然な流れかなと思いました。（できているのが超スゴいなぁ、どちらかといえばそこまでの道のりを詳しく聞きたいなとも思いました。）

実際やったこととしては品質レベルをチームで決める（なぜならば提供する価値が仮説なので品質もまた仮説、よって品証部門だけに責任を押し付けられない）ということをやったそうです。確かに斬新すぎで評価できないというのはありそうな気がします。特に老舗だと分化が進んでいるのでQAがついてこれない、みたいなことは結構あるのかもしれません。となるとQAの巻き込みもそこまで見透かして（＝QAに振り回されたくないための作戦）のことかもしれないですね。受け入れ基準を自然言語で定義して開発がそれをテストケース化し実行、結果は自然言語でレポート、というのも受け入れ基準作成にQAを参画させてしまうためのやり方、という見方ができるかもしれないな、と思いました。

最後に質疑応答などありましたが「なぜなのかを明確に伝える」というのが回し方のポイントいう話をされていて、チーム体制とか文化を顧客中心な感じに組み替えていくと結局そうした組織の中で意思疎通するにはそういう軸で語ることが大事になるのだろうな、とある意味納得しました。

 ・・・

正直もうちょっとノウハウ的なものを労せずにいただけたりしないかなーと思っていたのですが、当然ながら現実は甘くなく、精進が必要だということを再認識した次第です。あと、アジャイル関係の用語とかは勉強しないとそもそも話が通じないなというのを強く思いました。カタカナ語難しい・・・。

JaSST関西’18に行ってきた話（スポンサーセッション編）

基調講演編に続いてはテスト管理セッションとテスト設計セッションになります。
これらのセッションは2トラック×３コマになっていまして、計６コマのうち３コマを選択して聴講となります。

私の選択は以下でした。

1. セッション 3A-1「老舗メーカーにアジャイル型要求開発を導入してみました」
2. セッション 3B-2「ロジックツリーによる不具合分析からのテストの補強」
3. セッション 3A-3「お互いが納得感を得られるソフトウェアテスト思考の因子」

 とその前に基調講演のあとにあったスポンサーセッションの話を少し。

基調講演後のスポンサーセッションは富士通さん、ベリサーブさん、JSTQBさんの３社でした。まず富士通さんですがINSTANTCOPYというスクリーンショット取得用のツールの紹介でした。

なんというか、ツールとしての需要は当然それなりにあるし、（賛否はともかくとして）テスト方面でいかにも使いそうではあるのですが、いかんせん基調講演の超洗練されたTDDのライブコーディングから「スクリーンショットを簡単に取得できてExcelテンプレートにはめこめますー」、という話が落差ありすぎて、「お、おぅ・・」という感じになりました。とはいうものの、スポンサー様のおかげで比較的リーズナブルな金額でありがたい講演が聴けるわけですし、スクショツールもある意味ソフトウェアテストの”リアル”なので（良いかどうかはもちろん別の話）そういうのを目の当たりにできるのもJaSSTのいいところかなぁ、と思います。ただこの順番はコントラストがキツすぎてちょっと残酷な感じでしたね・・・。

続きましてベリサーブさんのTESTRUCTUREなるテスト設計支援ツールの紹介でした。ツールの特徴はいくつかあるのですが、今回のセッションではトレーサビリティの確保が容易、という点を押しておられました。特にテスト設計の際に仕様書記載の要件を網羅するように設計しているのだが、時に抜けが発生してしまいヒヤリとするというエピソードを紹介されていました。このツールを使えばビジュアルに仕様書上にタグ付けして要件などを表示し、さらにそれに紐づけてテスト観点やテストケースをたどって行けるような雰囲気の紹介でした。さらにテストケースを自動生成（All-Pair法などを利用）する機能もあるそうです。観点や因子を指定すると組み合わせテストケースを生成する感じですかね？（さすがに手順などまで記載されたものを自動生成するわけではないですよね）ベリサーブさんのようないろんな会社からテストを受託してきてそれぞれのところの流儀があるようなところではこういうのに蓄積するのがいいのかもしれませんね。ウチはそこまでスケールしてない感じですね（設計者が少ない・・・）特許も取得しているということだそうです。（特許第6148362号、http://www.conceptsengine.com/patent/grant/0006148362 ）ちょっと読んでみましたが、仕様と観点を格納していてテスト生成機能があってそれらの関連がわかるように表示する、みたいな感じだったので、この手のツールだと何しても該当しちゃいそうな印象ですが、特許的にはどういう感じなのでしょうか・・・。

最後はJSTQBさんでした。いつものような感じで資格制度の説明と直近の話題としてシラバス（FL Agiletester、AL TechnicalTestAnalyst）の紹介でした。シラバスが世に放たれたとなると近日これらの資格認定試験もはじまるのでしょうか・・・。AL-TTAとったらAL完全有資格者になれるらしいのですが、ノンプログラマな私になんとかなるんやろか・・・。（まぁ職場じゃ ALとTMの区別を人事に説明するのが面倒すぎて人事データベースに登録することに挫折してしまいましたが。）ぼつぼつシラバス読んでいかないといかんですね。

スポンサーセッションだけでちょっとした長さになったのでこのへんにしておきます。
しかしまぁスポンサー様のおかげさまで比較的お安くありがたい話が聞けて感謝感謝ですね。

（一昔前は五千円でお弁当ついた上に日経コンピュータ1年購読がおまけとかものすごいお得イベントだったのですが、今でも1日5千円でたっぷりテスト話が聴けるイベントなんてなかなか無いのです。特に関西方面では）

JaSST関西’18に行ってきた話（基調講演編）

毎年のことなのですが、JaSST（ソフトウェアテストシンポジウム）関西’18に行ってきました。過去のプログラムを見ると2010年あたりから見覚えのある内容になっているのでかれこれ7-8年は通っていることになります。

 なんでまた急にブログるのと言われると、電子化された予稿集を参照するために今年からノートPCを投入するようになったのと、その勢いではてなブログの開設手続きをやっちゃったからだったりします。正直なところ、ほぼ講演と同時進行で実況

#jasstkansai - Twitter Search

はされてるし、多分すごい詳しいエントリとかも投稿されるんだとは思いますが、自分の感想の整理を兼ねてやってみようかなと。（多分小学生の作文みたいに、あとに行くほどしぼんでしまう感じになりそうだけど）

ということで早速基調講演の内容です。TDD（テスト駆動開発）で有名なt_wadaこと和田卓人さんの講演です。（後日資料公開あると言われていたのでそちらも参照ください）

ネットではライオンのAAが有名だそうで、実際”t_wada”でグーグル画像検索したら上位５位までライオンAAがでてきました。一種のなまはげみたいなもんとご本人もおっしゃっていました。「テスト書いてないとライオン来るよ」みたいな感じでしょうか。もちろんご本人の人格とは異なりますとのこと（そりゃそうですね）

あ、あと、今どきのモダンな開発では「テストコードを書いていない」ことはレビューをリジェクトする立派な理由になるんだそうです。「テストコード書いてきてから出直してね」というわけです。ウチの勤務先でもテストしてない、ってことはないにしてもテストコードを全部書いてるかというと多分そうじゃないと予想するので、世の中もうそこまで進んでるんだなーと思いました。

また、書籍「プログラマが知るべき97のこと」（監修）、「SQLアンチパターン」（監訳）、「テスト駆動開発」（翻訳）、そしてpower-assertというテストフレームワークなどを手がけられているそうです。（すいません開発しないのであまりよくわかっていません）

そして本題ですが、今回の基調講演ではTDDやってるところを聴衆に見せて、その上でソフトウェアテストとの接点を探りたい、ということでした。和田さんはJaSSTで講演されるのは2回め（以前にJaSST北海道で講演されたことがある）なんだそうですが、過去の講演で多かった質問が「TDDがなんなのかわからない」「やりかたがわからない」というものだったそうです。それに対する答えが「これからあなた方が目撃するものがTDDです」。うーん、カッコ良すぎですね。（より詳しくは書籍「テスト駆動開発」参照ということだそうです）私もたまーに社内で研修の講師やれよと言われますが「これからあなた方が目撃するものが○○です」とかよう言わん。講師自身がよくわかってないこともあるし（汗）

ということで、実際に講演でTDDがはじまります。ライブコーディングです。目の前でガリガリとコードとテストが書かれていきます。このあたり、自分が開発経験ないので、うまく表現できませんが、ガサゴソとネット検索してみたら、以下が見つかりました。

channel9.msdn.com

23:00付近からのデモを見れば講演時のライブコーディングがどんな様子だったのかを感じていただけると思います。

細かい話は私にはわからないところもあるので、概念としてこれはと感じたあたりを以下列挙です。 

• 要求を箇条書きにし、さらに表現をそろえつつ「一撃」（ひとくちサイズ）できる粒度に調整していくところ
  これは開発に限った話ではなく、色んな所で重要だと思います。特に言い換えたりして表現を揃えていく、というのは大事だなと思いました。グーグル翻訳とかで入力の日本語をコネコネするような感じでしょうか。調整せずにそのままやりきってしまおうとすると無理が生じる、というのはどんなことでもよくあるな、と。
  問題を小さく分割して各個撃破するのと、最適な順番を考えるというのはTDDに重要なスキルなんだ、と説明されていました。
• タスクは重要なものからやるか、簡単なものからやるか、だがオススメは後者
  これも序盤に勢いつけたいとか、準備が重いのでタスク自体は軽めのものから入るほうがいい、とかプログラミングにかかわらず有用なノウハウだなぁと。
• 「ただし」は要注意ワード
  これはテストするときでもあるあるですね。正常系以外の内容や例外条件とかが出てくる予兆ですね
• TDDではテストコードのそのまた下に当たる部分（＝検証部分）を先にかく。目的をブレさせないため。
  考えながら走っていると目的地を見失う、というのはよくあるので先にゴールを設定しておくというわけですね。これもいろんなことに共通で使える考え方ですね
• 作る前に使う側に回って考える
  作ってしまうと「こうこう使ってほしい」というバイアスが発生するので作る前に使う側に回って考えて検証部分を先に書いてしまうと。余計な束縛を受けないための知恵ですね。テストでも事前に中身を知りすぎると無意識に遠慮したりするという心理はありそうなので、そういったところをカバーするのにいい考え方ですね。

さて一通りライブコーディングが一巡したところで、話はテストへと向かっていきます。次の疑問はこれです。

「TDDになって開発者がテストするようになったらテストエンジニアはもう不要なの？」

TDDのTは当然テストですが、このテストについて和田さんはこう言います。TDDのテストは動作するきれいなコードに到達するための手段だと。これはJ. マイヤーズのいうところのソフトウェアテストの定義「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」とは違ってますよね、と和田さんは続けます。TDDのテストはプログラミングテクニックであってソフトウェアテストではないと。TDDのテストは

www.developsense.com

で言われているところの“Checking”だとあっさり認めてしまいます。実際チェッキングだよねと。なんでTDDはCDD（Checking Driven Development）にならないんだろう、という点については書籍「テスト駆動開発」の付録C参照、だそうです(笑)

アジャイルテストの4象限だとビジネス面/技術面、チーム支援/製品批評の2軸があるのだそうですが、TDDのテストはそのうちのチーム支援が主眼なので製品批評的なテスト、探索的なテストやセキュリティテストはTDDではカバーできないので引き続き必要になるはずだ、ということでした。

では両者は独立した別々のものなのでしょうか？和田さんはテスティングフレームワークを用いている以上、両者をなだらかにつなぐことができるのではないかといいます。TDDに必要なスキルにテストの構造化とリファクタリングがあり、そこにテストエンジニアの貢献を期待しているというのです。どういうことかというと、TDDで作成したテストコードのメンテナンスコストを抑えるために、保守性を確保する必要があるが開発者は実装を進めていく以外の動機が弱いのでいろいろと困ることが出てくるのだそうです。

例えば先程のFizzBuzz問題のライブコーディングに戻ってみると、○○を渡したら文字列××を返す、みたいな具体的な振る舞いだけが記載されたテストコードが多数並んでいます。だけど、一口サイズに分割した結果、もともとこれらのテストケースを作成しなければならなかった理由、つまりFizzBuzzの仕様はテストケースからはよくわからない状態になっています。この状態で担当者が代わったりしてしまうと、テストケースの重要度や階層構造が全くないので全部のテストを丸呑みしてしまわざるを得なく、それがメンテナンスコストを押し上げているというわけです。

これを解決するにはテストコードを構造化したり、それぞれのテストケースに根拠を与える必要がありますが、そういったことに長けているのがテストエンジニアで、値の選び方とかツリー化やテストケースの増減に対する根拠付けなどの面で開発への貢献が可能なんだ、という話をされていました。書くだけがテストなんじゃなくて、考えて分類して、というのが大事なんだけど、そのへんが開発者には足りないことが多いのでテストエンジニアと協業できるんではないか、という話でした。

質疑ですが、「テストコードがないコードを抱えている状態である場合、どうすれば良いですか？」という質問が出ていました。これはもっともよく現場で要望されることらしく、詳しくは「レガシーコード改善ガイド」という書籍を参照のこと、ということでしたが、こういう状況の場合無理やり大外（WEB系ならばEnd to Endとか）からテストを書いていくか、もしくはテストが書けそうになるまで慎重にリファクタを続けていく、の2択だそうで、ご紹介の書籍には後者のノウハウが豊富（stack overflowでの被引用数No.1）なんだそうです。

たぶんこのエントリもリファクタしないといけないのだろうなー、と思いはするのですが、とりあえずGreenになったということで乱文ご容赦いただければ。

しかし講演内容をまとめるのは大変だな・・・・。速報的に投稿してる人たちはすごいなぁ・・・。基調講演以外をエントリできるのはいつのことやら・・・。