「数学ガールの秘密ノート/学ぶための対話」は、学生時代に数学をパターン暗記で乗り切ってしまった人にお勧め

昨年参加したソフトウェアテストの合宿形式の勉強会・WACATEのお楽しみ抽選的なイベントで『数学ガールの秘密ノート/学ぶための対話』をいただきました。

色々とぐさりと来るところがあったので、ちょっと感想などを書いてみます。なお、数学ガールはシリーズものですが、私はこれ一冊しかまだ読んだことがありません。

この本をお勧めしたい人

数学が苦手で、パターン暗記で乗り切った人にお勧めします。私はほぼパターン暗記で学校の数学を乗り切ったタイプです。

なぜお勧めできるか

私は数学が苦手です。苦手な理由は、恐らくですが中学・高校時代に数学を理解せずにパターン暗記で対処していたからではないか、とこの本を読んで思いました。

本の中で何度か主人公で数学の得意な「僕」は、数学を教わりに来てる「ノナちゃん」から「暗記しますか?」と聞かれます。暗記ではなく理解するよう主人公は諭すのですが、まさに暗記してたのが昔の私です。たぶん今もその傾向は続いていると思います。

パターン暗記の問題点

自分の場合ですが、パターン暗記のやっかいなところは、パターン暗記で教科書の理解確認問題や中間テストは対処できるので、理解できてないことに気づきにくい点でした。そして、単に覚えているだけなので、当然忘れていきます。

範囲の広い実力テストなどになると、中間テストに比べると正答率が劣るので、うっすら「実は分かってないかも?」と疑います。その時に理解するよう動けばよかったんだと思いますが、今思うと、自分の対処は「暗記するパターンを増やす」と「反復練習して記憶から抜ける量を減らす」でした。受験対策としては間違ってないんですが、理解が進んだかといえば、ちょっと怪しいです。

この本のお勧めなところ

この本では、言及されている数学の範囲は、一次関数とグラフのみです。それだけなので、パターン暗記で覚えてしまおうとするとすぐ済む内容なんですが、暗記ではなく理解を促すように話が進みます。ちょうどパターン暗記してしまいそうになるあたりで、ノナちゃんが「暗記しますか?」と聞いてくれます。自分も暗記に走りそうになっていたことに気付けるので、ノナちゃんと一緒に意味を考えながら読めるようになっています。

数学をパターン暗記で乗り切った人が、意味を理解するってなんだろうと思いながら読むと、ちょうど良い本だと思います。

WACATE2019冬「あなたの番です」参加レポート2日目!

2日目レポートも行ってみまーす。

f:id:yuki_shiro:20191215130639j:plain
三浦海岸の朝焼け

モーニングセッション:Agile Testing Days 2019 参加レポート

ブロッコリーさん)
資料はこちら!
speakerdeck.com
Agile Testing Days:ドイツのポツダムで11月に毎年開催、全日程6日間、参加費は約30万円。
800人くらいが参加する。キーノートだけで14個!本会議のセッションは9レーン。
セッションには認知科学や健康がテーマのものもある。
「人間てのは壊れた櫛だよ。人それぞれ得意不得意がある。だからチームとして動くといいよねー」みたいなこと主張してるセッションがあったり、ホームズとワトソンになりきってるセッションがあったり、着ぐるみで発表しようとしたけど暑くて開始3分で脱いだり、とか多様すぎる。ドイツと南アフリカにすむ二人が学習パートナーシップを組んだ結果、毎日カンファレンスに参加している気分になった!→距離について言い訳するのはやめようぜ!

感想

国際カンファレンス楽しそう!特にAgile Testig Daysはフリーダム度が高くて面白そうなのが伝わってきました。資金面は何とかするにしても一度行ってみたいですね。なお、手軽に国際カンファレンスを楽しむ手立てとしては、OnlineTestConf Japanもございますので、よろしくお願いします(宣伝)!

アジャイルとテスト

(つのださん)
資料はこちら!
speakerdeck.com

アジャイルについて

世の中の流れが速い、ニーズをそもそも完璧に確定するのが難しい

  • アジャイル向きなシステム:外部要因に大きく影響を受ける
  • アジャイル向きでないシステム:不確実性があまりないシステム。ミッションクリティカルとか
  • アジャイルソフトウェア宣言→ソフトウェアをよりよく作るための考え方

アジャイルのテストについて

アジャイルのテスト→フィードバックを得るため

  • 頻繁なコミュニケーション
  • 手戻りを減らすための複数人同時作業
感想

アジャイルに向くもの、向かないものの説明も含めて、短いけど丁寧にアジャイルとテストをまとめてもらえたセッションでした。アジャイルのテストは「フィードバックを得るため」は、確かにそうだなーと思います。自分の現場でも、フィードバックを早めるための施策は試行錯誤してるので、レビューでのフィードバックなど地道にやっていきます。

ソフトウェアテスト業界でのステップアップを考えよう

(きんぢさん)
資料はこちら。

www.slideshare.net
メモも貼っておきます。
f:id:yuki_shiro:20191215130719j:plain

感想

「品質 is 何」や「3年後どうなっていたいか」のような問いかけで、班のメンバーから本当に現場に応じたいろいろな意見が出てきて面白かったです。自分にとっての品質は、「ユーザがシステムで解決したいことを解決できている」とか「やりたいことをより簡単に、楽にできるようになっている」とかだと考えています。これが医療機器とか自動車とかに携わる方になると、「人が死なないこと」とかが出てくるのだなーと自分にない視点が出てきて面白かったです。
テストの分け方はテストレベルやテストタイプ、自動化などいくつか種類があるので、この後のキャリアのために自分がどの位置で仕事しているのかを把握するのは重要だと思いました。キャリアマップを作りたいなーと思っているので、このセッションからヒントをいくつかもらえた気がします!

WACATE流勉強会の作り方

(えっちゅーさん)

  • 勉強会をやるとよいところ
    • プロジェクト運営の疑似体験ができる
    • アウトプットすることで思考の整理、分かるところ分からないところの明確化ができる
  • 勉強会をやるのに考えること

時間

  • 必要な時間は?
  • 会場、準備にかかる工数

会場

  • 人数と会場の広さ
  • 必要な設備が整っているか
  • 開催希望日に利用ができるか

事前準備

  • 参加者に事前にやってきてもらうと嬉しいことは?
  • 持ってきてもらいたいものはある?

開催回数

  • 今回限り? 何度も開催する? 定期/不定期?

対象者

  • どういった人に参加してもらいたい?

運営にかかるお金

  • お金をかけずに開催できる? かかる場合、何にどれくらいおかねがかかる?
  • 必要な金額はどうやって集めるか?

登壇者

  • 自分たちが話すか、講演者を呼んで話してもらうのか?
感想

WACATEに限らず応用できる話ですが、WACATEの実行委員の方々がすごくこだわって勉強会を作られてるのが伝わってきました。ここまで考えてくださってるの、本当にありがたいです。
自分が主催した勉強会で、テーマ設定と参加者のレベル感を上手く合わせられず、ちゃんと勉強会の設計しておけば良かったと後悔したことがあるので、次に活かします。

招待講演:テスト設計をより良くするモデリングと観点分析

資料はこちら!
speakerdeck.com

感想

講義のために簡略化されたとはいえ複雑なテスト対象をモデリングして、リスクまでクリアに見えてく様子がすごく綺麗でした!あれを自分でできるようになりたい。
モデリングはわりと難しくとらえてたところがあるのですが、比較的簡単なものはテスト技法ですでに使ってるというところで、ちょっと勇気が出ましたw にしさんの「絵(図だったかも?)を描け」に通じるところがあって、本質はたぶん同じことを言ってるのではないかと思いました。
モデリングで知識の部分はごく一部で、目的に応じて使い分けるところが難しいと感じます。テスト技法自体は知っていても、現実のどの場合にどの技法を当てはめればいいのか、すぐには判断つくようになりませんでした。要件レベルになると経験があまりないので挑戦になりますが、ここができるようになるとビジネスに貢献できる幅が広がるので、自分としては今後の挑戦のしどころです!

2日間を通じての感想

テストに情熱を持つ方々とワークしたり、お話したりできて楽しかったです!場を作ってくださった実行委員の方々、話してくださった参加者の方々ありがとうございます!
今後やりたいことへのヒントがもらえました。息切れしないようにちょっとずつ加速しますw Twitterアイコンとご本人が一致した方が増えたのも嬉しかったです。またどこかの勉強会でお会いすると思うので、よろしくお願いします。

WACATE2019冬「あなたの番です」参加レポート1日目!

ソフトウェアテスト業界にはお馴染みのWACATEにやってまいりました!
f:id:yuki_shiro:20191214231734j:plain
若手(若手じゃなくても)が手を動かして学ぶ2日間合宿形式のワークショップです!さあ、加速できるかな?

BPPセッション

(はるにゃんさん)
何も言わない。これを見てくれ。
f:id:yuki_shiro:20191214231620j:plain
石油王に敬意を表して、私にしてはグラフィックなグラレコになりました。
BPPをとるために戦略的に考えて、インパクトに残るポジションペーパーにしているのかの過程を説明してくれて、すごく分かりやすかったです。人生初の登壇だったそうですが、間の取り方もうまくて何度も爆笑が巻き起こったセッションでしたw
テストラジオでもBPPセッションの裏話が紹介されているので、ぜひこちらも聞いてください!
testradio.fm

業務でも活用できるソフトウェアテストの7原則

(ブロッコリーさん)
資料やセッションの経緯は、ブロッコリーさんがブログで公開してますので、ぜひこちらでどうぞ。
nihonbuson.hatenadiary.jp

感想

ワークは、実際にテストの現場でありそうな会話から、テストの7原則に反してそうなものを見つけるという内容でした。ワークのまとめで言及されていたのですが、テストの7原則を理解した上で、「7原則があるからと言って、正義を振りかざすべきタイミングを見極める。原則に沿えない場合もあるので話を聞いて障壁を取り除く」ことができるのが重要だと感じました。次のワークでも感じましたが、相手を詰めても前に進めないので、7原則は、背景などを話した上で「じゃあどうするか」を考えるための材料にするべきものですね。

物語を想像して問いを立ててみよう

(かおりっとさん)
資料はこちら!
speakerdeck.com
「問い」をうまく活用して、相手の考えていることを紐解いていくセッションでした。
ワークで実施した内容は次の通りです。

  • 相手に何かを思い浮かべてもらう
  • 相手が思い浮かべたものを当てるために、「問い」をしていく。ただし「問い」で使えるのは、Yes/Noでこたえられる質問のみ。
  • ワークでは時間が限られるため、実行委員が用意してくれたテストに関するキーワードの中から「答え」になるものを選ぶ
  • 質問は5個まで

実際にやってみると、色々な想定外が発生し、思った以上に難しかったです。

  • 「問い」を立てるって難しい
  • 自分が「問い」で使った言葉で相手が同じものをイメージしているとは限らない
    • 「イベント」という言葉でWACATEやJaSSTを想定していたけど、相手は「レビュー」などの粒度で想定していた、という例があった
  • キーワードの中から答えを選ぶ形式で、選んだものが同じ事態が発生。同じものを選ばないだろうというバイアスが働き、答えを当てられなかった
感想

問いって本当に難しいなーと感じました。問いはうまく使わないと、相手を詰めてしまう凶器になりかねないとは思ってます。ワークの短い間でも、背景のずれやバイアスがかかったりとかを、ちゃんと意識できる状態で体感して、「ここまでずれるものなのか!」という実感が持てたのは大きいな、と思います。
「自分たちのシステムを使う人はどういう人だろう?」と考えるときとか、何かの認識ずれでバグが発生してしまった時のふりかえりとかで「問い」が使えそうな気がしています。

形式手法ってなんだろう?

(べにさん)
speakerdeck.com
形式手法は数論理学に基づいた手法。

  • 仕様を厳密に書ける、明確に意味を一つに絞れる
  • プログラミング言語そのまま? いいえ、実装ではなく仕様を記述することが可能です

形式手法のいいところ

  • 仕様を厳密に書ける
  • 実装ではなく仕様を記述できる
  • 実装前に検証が可能
  • 何が複雑なのかを把握できる
感想

形式手法は、基礎知識がないと難しいと感じました。例を真似すれば書けはするのだけど、自分が何を書いてるのかわからなくて同じチームの方に解説してもらいました。チームメンバに助けてもらえるの良かったです。ただ、すみません、形式手法は私には早かった。。。あまり理解できてないので要復習です。。

ディナーセッション、夜の分科会

美味しいごはんを食べたり、飲む人はお酒をいただきながら夜23時までテストについて語り合う変わり者たちの宴です! 夜の分科会では、よしたけさんのテスト観点共有会のセッションに参加しました。電話番号に関する観点を出し合ったのですが、みんなで観点を出し合うと、自分にはない観点をもらえたり、相手の出した案に乗ってそれをより深められたりというのが面白かったです。
成果物はこちら。
f:id:yuki_shiro:20191217204142j:plain
テスト観点共有会の詳しいやり方は、よしたけさんのブログをどうぞ!
yoshitake-1201.hatenablog.com

おまけ

WACATEはご飯も美味しいですよ!
f:id:yuki_shiro:20191217204108j:plain
f:id:yuki_shiro:20191217204122j:plain
三浦半島の海の幸を堪能する意味でもぜひWACATEへ!

テストマネジメントツールを適用する前に考えること

この記事は、ソフトウェアテスト Advent Calendar 2019の10日目の記事です。
qiita.com
前の記事はこちら。
halspring.hatenablog.com
9月にいくつかテストマネジメントツールについての勉強会に参加して、考える機会が多かったので、ちょっとアウトプットしてみました。参加したイベントはこちら。
connpass.com

テストマネジメントツールとは

テスト管理ツールは、主にテストケース、テスト実施結果(OK/NG/再実施など)、進捗、実施履歴などをWebで管理するツールです。要件管理はあるものとないものがあります。呼び方は「テストマネジメントツール」だったり「テスト管理ツール」と呼ばれていたりします。

導入時に考えること

テストマネジメントツールに限らず、ツール導入の際にはいくつか事前に考えておくべきことがあります。

  • ツールで解決したい問題は何か?
  • ツール導入でメリットは得られるのか?(デメリットの方が大きくなることはないか?)
  • ツールが課す制約がこれまでのテストのフローを妨げる場合、それを許容できるか?
    • 導入時には「ツールで解決したい問題」に目が行きがちですが、「ツールが課す制約」についても考える必要があります。これについては後で述べます。
  • コストはどのくらいか?
    • 初期費用や月額費用
    • 導入にかかる教育コスト
    • 運用コスト(手順を整えたり、オンプレやOSSの場合は自前でメンテナンスするコスト)

導入してメリットがある条件

ツールのメリットを享受するための前提はあまり触れられてないなと思ったので、自分なりに整理してみました。なお、テストマネジメントツールを使わない場合、テストケースの管理はExcelスプレッドシートで行われることが多いので、比較対象はスプレッドシートとします。

複数人で使用すること

利用者が一人であるなら、次の理由からスプレッドシートでよいと思います。

  • 管理対象とするテストケースや結果が、自分で把握、説明できる分量に留まると予想される
  • すでにスプレッドシートで運用しているなら、学習コストや利用フローの整備、ツールの利用料などのコストを払うのに見合わない
  • 古のExcelの場合、複数人で操作してファイルが壊れることを想定しなくてよい(それでも「予期せぬエラー」で壊れる場合は想定しておいた方が良い)
テストケースの再利用を前提としていること

テストマネジメントツールは、テストケースの「普遍的な部分(実施手順、確認内容など)」と「テスト毎に毎回変わる部分(実施予定日、実施予定担当者など)」を分けて管理できます。普遍的な部分を資産として持っていて、そこからテスト実行ごとに「テスト毎に毎回変わる部分」を付加して、「テストインスタンス」を生成するイメージです。湯本剛(@yumotsuyo)さんの資料の説明が分かりやすいので、引用させてもらいました。

資産化しておくことでテストケースの複数回の利用を容易にしているのが、テストマネジメントツールの利点であるため、単発でしかテストケースを使わないのであれば恩恵は大きくはないと思います。
テストケースを再利用することを前提とすると、テストマネジメントツールの恩恵を受けやすいのは継続して開発、リリースする案件で使うことだと思います。条件に合う案件は、自分の観測範囲では自社サービス、ツールの開発案件が多い印象です。
単発の案件であっても、同じような案件が複数あるのであれば、観点とか項目といったナレッジの蓄積を目的として使うのは意味がある気はします。

ツールが課す制約を許容できるか

制約というちょっと強い表現を使いましたが、ツールを導入することによって今までと作業フローが変わったり、不便なことが出てきたりするが、それを許容できるか、という観点です。これ以下の内容は、私の主観が強いので当てはまらない場合もあると思います。

前提

私が触れたことのあるテストマネジメントツールは、Squash TM、TestRailの2つ、あとはKazu Suzuki(@kz_suzuki)さんのブログでPracti Testを少し眺めたくらいです。
www.kzsuzuki.com
そのため、それら2つ(+1つ)をベースにして、スプレッドシートでの運用と比較しています。
スプレッドシートでのテストケースの運用時には、「ID、テストケース名、手順、期待結果結果、実施予定日、実施予定担当、実施結果」を1行で管理しているものと仮定します。

テストケースの一覧に見るテストマネジメントツールスプレッドシートの比較

テストマネジメントツールスプレッドシートでは、設計の思想が違います。テストマネジメントツールは、もちろんテストに関するあれこれ(要件、テストケース、実行結果など)の管理を目的として作られたツールですし、スプレッドシート表計算を主眼として作られたツールです。
テストマネジメントツールスプレッドシートでテストケースを作成する場合、テストケース一覧の表示内容、運用に差が顕著に出ていると思ったため、次の項目について比較してみました。比較したのは、「前提」でスプレッドシートでの運用時に管理対象として仮定した「ID、テストケース名、手順、期待結果結果」とプラスアルファです。「実施予定日、実施予定担当、実施結果」については、テストマネジメントツールの場合、テストケース作成の段階で管理しないため省略しました。

比較対象 テストマネジメントツール スプレッドシート
ID
テストケース名
優先度
手順 ×
期待結果 ×
表示項目のカスタマイズ ツールで表示対象に設定できる項目のみ 追加が可能(組織でテンプレートとして定められている部分を除く)
一覧に表示できる行数 制限あり(TestRailでは2000行だった) スプレッドシートの限界までは理論上可能

凡例:
〇:デフォルトで表示対象、記載対象とされている
△:デフォルトではないが、多くの場合表示/記載あり
×:なし(表示できる対象として設定されていない)
  補足:テストケース名から参照的に手順、期待結果を表示することは可能。ただし選択した1ケースのみ。

テストマネジメントツールの導入で変わる部分

スプレッドシートでの運用している時と比べると、変わる点は次のようなものがあると考えています。

  • 手順、期待結果をレビューする場合、テストマネジメントツールではテストケースの一覧上でできない
    • 手順、期待結果を含めたCSVなどでのエクスポートは可能
    • ただし、ツールによってはテストケース名の一覧と手順・期待結果の一覧は別のシートで出てきて多少見づらい
  • テストケース名で、テスト内容の分かりやすいサマリを表現することが求められる
    • 期待結果が一覧上でも見えていれば、テストケース名を多少適当につけていても、テストの意図を補完できたが、それができなくなる
    • スプレッドシートでもテストケース名を分かりやすくつけていた場合は従来と変わらない
  • 一覧に表示する項目をカスタマイズできない
    • スプレッドシートだと、運用上の良し悪しは置いておいて、欄外にメモ欄など追加できたが、ツールではできない

上にあげた例では、スプレッドシートでの運用に問題があるものもありそうですが、ツールの導入によって、今まではできていたことができなくなることは考慮する必要があります。

まとめ

テストマネジメントツールは、ツールのメリットを出せる状況下で使えば、効率化を素晴らしくサポートしてくれるものだと思っています。ただ、ツールの導入には利点だけでなく、従来はできていたことに制約がかかるパターンがあるので、制約を考慮した上でもなおツール導入のメリットがあるのかは考える必要があります。

福岡で小早川隆景、乃美宗勝の足跡巡り+柳川で立花氏巡り

JaSST Kyushuに行くついでに前日ちょっと早く福岡入りして、私の好きな戦国武将である小早川隆景乃美宗勝ゆかりの地を巡ってきました。

宗勝寺

乃美宗勝のお墓のあるお寺です。
f:id:yuki_shiro:20191128132838j:image

福岡の交通網が集まる天神からバスで20分程度で到着します。近所には毛利氏の勢力と大友氏の勢力が攻防を繰り広げた立花山城があります。宗勝公は朝鮮出兵時に病を得て、九州に戻ってきてこのあたりで亡くなったと伝わっています。ごく普通のお寺なので、本堂に軽く参拝してから宗勝公のお墓へ。

f:id:yuki_shiro:20191128133834j:image

本堂左手の細い山道を通って向かいます。地蔵堂らしきところの裏手を通ってさらに山の中へ。

f:id:yuki_shiro:20191128133934j:image

落ち葉がこんもり積もり、ところどころで倒れた竹が邪魔をしてきます。案内板が順路はこちらと示しているし、道はこれ以外にないので乗り越えて進みます。ちょっと愛を試されてる気分のする道でした。雨が降ってたら引き返してたかもしれませんw曇りぐらいで本当によかった。あと夏だと虫が多そうなので、冬でよかったです。

ほどなく重臣のお墓へたどり着きます。
f:id:yuki_shiro:20191128141046j:image

この奥に宗勝公と奥様のお墓がありました。f:id:yuki_shiro:20191129015053j:image

向かって左のお墓に「宗勝寺殿」「勝運」の文字がありますので、こちらが宗勝公ですね。f:id:yuki_shiro:20191129015117j:image

なかなか福岡までくる機会がないので、今回お参りできてよかったです。基本的に曇ってたのですが、宗勝公のお墓の前に来た時にちょうど晴れ間が来たのも嬉しかったです。偶然晴れただけとは思いますが、なんか「よく来たな!」って歓迎された気分になれました。

筥崎宮

日本三大八幡といわれる筥崎宮にお参りしてきました。こちらは小早川隆景によって楼門が造営されています。

f:id:yuki_shiro:20191129015149j:image

元寇の際に敵国の調伏を祈ったことから「敵国降伏」の額が掲げられています。筑前は豊臣政権期に小早川が領有していたので、こちらの筥崎宮太宰府天満宮に隆景公の足跡がちょこちょこ見られます。今回は太宰府まで足を延ばせませんでしたが、また太宰府にも訪れたいと思います。

柳川藩主立花邸御花

筥崎から足を延ばして柳川まで行ってきました。

f:id:yuki_shiro:20191129015216j:image

ほぼ佐賀の隣なので、筥崎から移動すると1時間強かかります。正直1日に詰め込みすぎな気はしましたが、目的は好きな戦国武将である立花宗茂ゆかりの資料館を見たり、ウナギのせいろ蒸しを食べたりすることでした。

柳川藩主立花邸御花は、明治維新以降に華族となった立花家の邸宅が公開されており、同じ敷地内にレストランやホテルも建っています。現在も立花家が経営されています。旧大名家、華族の多くが、明治維新や戦後に資産を手放されたことを考えると、現在も経営されているのはすごいことなのでは、と思います。

さて正面から入ると、瀟洒な洋館が迎えてくれます。

f:id:yuki_shiro:20191129015235j:image

敷地内のレストランでウナギのせいろ蒸しをいただきました。レストランのナプキンに立花家の家紋が入っていて、この時点でテンションがあがります。


f:id:yuki_shiro:20191129015253j:image

せいろ蒸しは蒸し上がるのにちょっと時間がかかるので、その間に洋館内部を見学しました。伯爵家にふさわしい格式のために、意匠に凝っているところや、家族だけが使うためシンプルに作られているところなど丁寧に解説されていて、興味深く見学できました。柳川名物のさげもんが飾ってあって、写真を撮れるスポットなんかも準備されてました!

f:id:yuki_shiro:20191129015318j:image

さげもんの拡大したものがこちら。色とりどりでとてもきれい。

f:id:yuki_shiro:20191129015330j:image

洋館部分と接続して和風建築も建てられており、そこからはお庭が眺められます。縁側、とよぶにはちょっと規模が大きい気もしますが、縁側もあるのでのんびり庭を眺めながら一息付けます。

f:id:yuki_shiro:20191129015410j:image

別の建物からお庭全体と和風建築部分を眺めてみました。

f:id:yuki_shiro:20191201235211j:image

見学を終えて戻ると、ちょうど蒸したてのせいろ蒸しがやってきました。せっかくなので奮発して、う巻きとうざくのついたおすすめセットにしてみました。


f:id:yuki_shiro:20191129015436j:image

蒸してあるのでウナギがふわふわ、たれのしみ込んだご飯も美味しくてペロっと食べてしまいました。せいろの下部分は全部ご飯なのでかなり量はあるんですけどねwしっかり蒸しあげてあるためか、ごはんも最後まで温かい状態で楽しめました。

敷地内にある立花資料館にも行ってきました。立花宗茂所蔵の鎧や江戸期の大名としての立花家に伝わる華やかな大名道具が見ごたえありました。

特に宗茂所蔵の鎧は、一度見てみたかったので良かったです。腕の部分は全部鎖帷子風になっていて、シンプルで動きやすそうな印象を受けました。色々な逸話から、いざとなれば自分も前線に出て戦うタイプの方という印象があるので、何となく納得感のある鎧でした。宗茂公は70代で島原の乱に出陣して、有馬城の一番乗りをされた方ですからね。

個人的に小早川隆景立花宗茂は、大河ドラマの主人公になってほしい歴史人物のNo.1、2なので、弾丸旅行でもこの二人にゆかりのある地を巡れてすごくよかったです!

JaSST '19 Kyushuに参加してきました!

JaSST Kyushu初参加!今回はテーマなし、とのことですが、緩やかに関係性とチーム、開発とテストのお話です。
f:id:yuki_shiro:20191129231408j:plain

「チケットシステムで理解するあのチーム」

(関さん、miwaさん)
あのチームの紹介

  • テストを中心とした反復開発のチーム、20年近く続いている
  • セーフティクリティカルのシステムを開発している

反復開発

  • V字モデルを何度も何度も繰り返すやつ

すべての活動をテストする

  • 実装、仕様、要求、作り方
  • テストは終端ではなく発端
  • すべての活動を「くり返し」できるように

あのチームの特徴

  • 非常に大きい
  • 組織変更と関係なく長生き
  • Wikiの規模は約9万ページ、毎日1000ページが編集
  • チケットシステムは非常に長生きしている(結果として長生きになっただけ)

1. チケット編:チケットは仕事の一つの単位
2. インデックス編:大量にあるチケットをどう扱うか
3. 朝会編:どう観察しているか

1. チケット編
  • 前提:ワークフローが変わるもの(変化を促す、邪魔しない)
  • サマリ:一行で表す「できること」、自分たちが分かれば十分、分からなかったら誰か突っ込むからいいかな
  • チケットの種類
    • story、bug:触って確かめるテストを書く
    • task:システムの変化がないもの
  • 状態
    • openとcloseだけ
  • 見積もり
    • あと何日かかりそうか、何日かかったか
    • 順調なのか、困っているのか、いつ試せるのかにフォーカス
    • あのチームでは、納期を約束させたり速度を競ったりはしない
  • 忍者式テスト
    • すべてのチケットにそれを確認するテストを書く
    • 毎日テストする、テストが増える
    • 試した人結果を記録
    • 履歴のすごいものは2003年のチケットが見直されたりする
    • テストスイートを日単位で全部網羅するのは不可能
    • →、1ヶ月とかで見たら網羅できるように今日のテストスイートを出せるアルゴリズムをシステムに組み込んだ
2. インデックス編

チームがどの製品、バージョンに集中してるかわかる

3. 朝会編

朝会で考えること

  • 「この製品を変更するべき」かの表明、どう変更しようと思っているかが問われる
  • 朝会は45分、延長なし
  • 朝会で使われるインデックスページは壁と付箋に似ている
    • 物理ではできない、過去のチケットの更新とか過去のチケットを見る習慣ができる
感想

チケットシステムを通して、あのチームのやり方やどうしてそうなっているのかがわかる紹介でした。チームが必要としている状態にフォーカスしていく様子が分かって、結果として長生きしていることが納得できました。チケットシステムの機能を、あえてチームに必要なことに絞って、他への報告に必要な機能を削いでいるのがすごいなと思います。「他への報告が求められないのは、チームがしくじってないから」というあのチームがカッコよすぎる。

「フレーズで体験するあのチーム」

問題を解決していく最中に起こる「小さな会話」が「良いチーム」を作るのではないか
フレーズ

  • 「うまくいったらどうなるの?」
  • 「見せて」
  • 「ワザと?」
  • 「わかんない」
「うまくいったらどうなるの?」

どこまでうまくいってて、どこから分からないかが明確になる。ゴールが明確になる。ゴールが明確になってない場合は、ゴールが明確になってない状況が分かってみんなで解決できる。どこまでも間違ったまま行くことがなくなる。
「うまくいったらどうなるの?」ポジティブな問いかけの言葉。またテスト可能。「なんでこれやるの?」だと上からになりがちだし、答えづらい。

「見せてー」

製品でもコードでも現物を見ることを大事にしている。見ると放っておけなくなる。みんなの自分事になる。
途中のものを見せるのがストレスになる人もいる。ただ、印象としては見せた方が楽になる人の方が多そうに見えるらしい。
※JaSST Kyushu実行委員ははZoomの画面共有で「見せてー」をやっているそうです。

「ワザと?」

制約や思い込みを取り外して考え始める。本来あるべき姿や理想。
おかしいと思っているけど、おかしいと言いづらいときや、混乱しているように見えるときに使える。
理想的な対策ではないけど、時間内では許容範囲な対策などを行い、その後「時間内では許容範囲な対策」だったことが忘れ去られた場合とかに使える。
「ワザと?」はチームに対する問いかけ。自分自身への問いかけにも使える。本当は自分は気に入らないけど、他からの強い要望があった場合とかに本音を言いやすくなる。

「ワザと?」はちょっとキツく感じる言い方なので、ニュアンス同じでもっと柔らかい言い方ないかなー、とつぶやいたところ2案いただきました。

  • @shimashima35さんから「それは意図通り?」
  • @YasuharuNishiさんから「なにか思うところがあったりしたんじゃない?」
「わかんない」

瞬時に自分の違和感を伝えられる。なぜわからないかをみんなが一斉に考え始められる。たいていの場合、課題(問題)が見つかる。
みんなわかってるけど、わからないときなどに使える。
このフレーズを使えるまでには時間がかかるので、新人が入った場合は、3か月くらい一人にさせないとか、「自分がわからなくて自分の時間を無駄にすると、チームの時間を無駄にする」意識の浸透などの前提が必要そうな印象を受けた。

感想

最後の「明日からできそう?」という問いかけには、「見せてー」とか逆に「これ見てー」あたりはできそう、「ワザと?」はニュアンスは分かったけど自分やチームになじむフレーズにするにはちょっと時間が必要そうかな、というのが今のところの自分の答えです。チームで成果を出すということに、チームがフォーカスする文化と一体のフレーズな気がするので、自分のところの文化になじませるには、自分の言葉や言い方をできるよう調整が必要な気がしてます。案をいただいた2つも、誘導尋問にならないようには注意して使おうと思ってます。

「オンラインコミュニケーション時代における日本語文章の書き方 ~チーム内とチーム外のコミュニケーションで気をつけること~」

町田さん
日本語の書き方に取り組むようになったのは、仕事でのレビューがきっかけ。日本語が好きなので、間違いが気になってしまう、自分が気になることを共有することでレビューの負担を減らしたい、もきっかけ。
文書は残せる点がメリットだが、間違うと間違えたまま残るのでディスコミュニケーションの元になる。
少人数チームによる開発では不完全な文章でも伝わるなどで、文章を書く機会は減る。ただ、付箋やホワイトボードを含め、正しく書くことの重要性は高い。

町田さんの3つのポリシー

1.読み手の立場に立つ
2.一字一句に魂を込める
3.できるだけ書かない
 →コードを書かなければバグは生まれない
 

心がけていること7点
  • 読み手によって求めることが違う
  • 読み手によって好む文章が違う
  • 背景を伝える
  • 簡単な言葉を使う
  • ごちゃごちゃした文章(文書)は読む気がなくなる
  • 文章は読まれない
  • 簡潔に書く
実践している7つ+1つ
  • 何度も読み返す
  • 真似をする
  • 意味を調べる
  • 類義語を調べる
  • 校正ツールを使う
  • 頭を冷やす
  • 俯瞰する
  • 英語に翻訳する
    • 翻訳して意味が通じなければ、ややこしい日本語
こだわっている7つのこと
  • 係り受け
  • 主語
  • 長文
  • 指示代名詞
  • 否定文
  • 専門用語
  • 助詞
感想

オンラインだろうと文章を書くことは必要なので、分かりやすい文章を見直すきっかけになりました。実践している7つのところで、プラスとして言われた英語に翻訳する、は確かにそうだなと感じました。翻訳しにくい日本語は、その時点で長文すぎたり、主語が抜けてたりして、実際読みにくいです。場面に応じて、町田さんが気を付けてることや実践していることを真似させてもらいます!

ふりかえりタイム

ふりかえりタイムをとってもらえるのが理解の促進になって、ありがたかったです。フレーズのところの質問で「NGワード」についての質問が出たのがすごくよい質問で、自分には思いつけなかったし、あのチームがフォーカスしてることをより深く知れるきっかけになりました。「生産性」とかはあいまいなんですよね。

おまけ

実行委員の方が周辺のランチマップを公開してくれたり、テスト酒場の方が前夜祭と懇親会を企画してくださったりと至れり尽くせりでした。どれも美味しかったです!
前夜祭の二次会で食べた「土竜が俺を呼んでいる」の梅塩とんこつラーメン。
f:id:yuki_shiro:20191201232123j:plain
ランチの「とんかつ若葉」さんの低温でじっくり上げたとんかつ。
f:id:yuki_shiro:20191129231446j:plain
懇親会の「だるま屋」さんのごまサバ。刺身もほかの料理もすごくおいしかった!
f:id:yuki_shiro:20191129231454j:plain

登壇者、実行委員、参加者の方々ありがとうございました!関係性とチームについて改めて考える機会をいただきました!

第14回Ques「Agile Testの今」に参加してきました

11/15(金)に行われた第14回Quesに行ってきました!いつもいけてる話題ですが、今回もいけてる話でした!
ques.connpass.com

ソフトウェアエンジニアと共にテストを作るチームでの、テストエンジニアの関わり方(越中谷さん)

資料はこちら。
speakerdeck.com
ちょっと遅刻してあまり聞けてないのですが、ベースとなっている部分は、別の日に行われた「SPEEDA Testing Day」と同じなのでそちらのメモを貼ります。
f:id:yuki_shiro:20191117222619j:plain

感想

自動テストが仕様になっているのいいなーと思いつつ、それをキープするのはきっと地道な作業なので、きちんと定着してるのがすごいと思いました。仕様のやりとりや最新をどうキープするかは目下の悩みどころなので、テストできっちり押さえてるのすごく素敵です。ハッピーパスはきっちりテスト項目が押さえてます、くらいからなら取り入れやすいかな。

顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み(常松さん)

資料はこちら。
speakerdeck.com
メモは二枚になってしまいましたが貼っておきます。
f:id:yuki_shiro:20191117222640j:plain
f:id:yuki_shiro:20191117222646j:plain

感想

課題の見つけ方とそれぞれの対処方法がすっきりまとめられていて、とても聞きやすかったです。「ツールがあるとツールの使いこなしに目が行く」とおっしゃってたのが印象的でした。確かにツールがあるとツールで管理できない部分は意識に上がってこないのですよね。自分のチームでも部分的に物理カンバンちっくな内容を取り入れてみてるので、すごく共感して聞けました。いい文化は残しつつ、地道に文化を作っていくは、自分のチームでもぜひ取り組みたいです!

今回も参考にしたいお話が色々聞けて、本会から懇親会まで楽しめました!登壇者、運営の皆様ありがとうございました!