Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

JaSST'24 Kyushu参加レポート

こんにちは、マネーフォワード 福岡開発拠点でQAエンジニアをしているゆっきー(原口)です。

昨年の10月にマネーフォワードに入社し、早いことに一年が経ちました。ちょうど一年前にJaSST'23 Kyushu 参加レポートを書いたのがもう懐かしいです。今年もJaSST'24 Kyushuに参加したのでレポートを書きます。

はじめに

今年もマネーフォワードはスポンサーとして応援しました。

そもそもJaSSTとは?

"Japan Symposium on Software Testing" の略で、ソフトウェアテストのシンポジウムを指します。 現在、日本各地やオンラインで開催されており、NPO法人ASTER(ソフトウェアテスト技術振興協会)が主体となって運営しております。 JaSSTは開催地区ごとにいろいろな特色があり、ソフトウェアテストに関連した研究・事例発表にとどまらず、ワークショップや講演なども行われています。

必見!?JaSST'23 Kyushuの舞台裏全部お見せしちゃいますより引用

今年のJaSST'24 Kyushu会場は沖縄!肌寒い福岡と違い、沖縄はまだ夏でした。暑かったー! 前日から大雨警報も出ており、会場へ辿り着けるのか不安でしたが、当日は天気も落ち着いて無事参加できて良かったです。 レポートは参加メンバー全員で書きましたのでぜひお読みください。


[2024/11/18 追記]

JaSST'24 Kyushu公式レポートが公開されました!
そちらも併せてご覧ください。

https://www.jasst.jp/symposium/jasst24kyushu/report.html/www.jasst.jp

マネーフォワードからの参加者

マネーフォワードからJaSST Kyushuに参加した7人の集合写真。2人が前でピースをしており、5人がその後ろで肩を組んで立っている写真。上段左からgof・sekky・tosite・kinu・いいね、下段左からゆっきー・irie.shou。
写真上段左から、gofsekkytosite(JaSST Kyushu 共同実行委員長)、 kinu、 いいね (iine)
下段左から、ゆっきー、irie.shou

基調講演 「一周まわって考えるソフトウェアテストへのマインドマップの利用 @池田暁さん」

JaSST'24 Kyusyuの最初の講演はクオリティアーツ代表 池田暁さんの講演でした。

こちらの基調講演では、マインドマップについての座学が行われ、「マインドマップとは何か?」「マインドマップの歴史」「マインドマップの効果」について、マインドマップに初めて触れる初心者が理解しやすいように丁寧に説明していただきました。

池田さんの著書である「マインドマップから始めるソフトウェアテスト」をもとにされた講演となっていました。本に記載されていた内容に加えて、マインドマップがこれまでの日本のIT業界においてどのように活用されてきたか、マインドマップに対する池田さんの最近の考えなどについても説明いただきました。

マインドマップとは、脳の仕組みを取り入れた思考の表現方法です。図を用いることで、深層意識にアクセスし、思考の過程にフォーカスすることができます。特長として、バードビュー、MECE(Mutually Exclusive and Collectively Exhaustive)、学習が容易、半構造された形式などが挙げられます。

マインドマップはトニー・ブザンによって提唱され、2000年頃にオブジェクト指向が流行し始めたタイミングでソフトウェア開発の世界でも利用されるようになりました。さらに、2006年からはソフトウェアテストの分野でも活用されるようになりました。2012年頃まではチュートリアルが頻繁に開催されていましたが、普及が進んだため、その後は開催されなくなりました。それによって、マインドマップを利用する人自体は増加しましたが、体系的に学ぶ機会は少なくなってしまいました。そのような中、今回の講演で久しぶりにマインドマップが議題に挙げられることとなりました。

マインドマップは発想を豊かにするためのツールであり、思考の流れを整理することができます。発想を豊かにするための強力な手段となるでしょう。また、思考の結果だけを表現する単純なテキストよりも、思考の流れを視覚的に表現できるため、コミュニケーションツールとしても非常に有用です。
ただし、マインドマップを使ったからといって自動的に発想力が向上するわけではありません。普段から発想力を鍛えることが前提となります。 ソフトウェアテストの文脈においても、仕様分析・テスト計画・設計・実装など幅広い場面で使用することでその効果を実感できます。

sekkyの感想

私は現在CRE(Customer Reliability Engineer)として働いており、過去にテストに関わる職種に携わったことはありません。しかし、私のようにソフトウェアテストの知識が浅い人間にとっても非常に興味深く感じた講演でした。

IT業界で仕事をしていると、大小様々な課題に遭遇します。これに対する理解度の深さ、つまり解像度は課題によって異なります。特に、これまで関わったことがない分野の課題や、入社直後に遭遇する課題は解像度が低いことがほとんどでしょう。

私は入社してからチームのグローバル化に取り組んでいますが、過去に同様の課題に取り組んだことはなく、「こんな感じで大丈夫かな?」と少し不安を感じながら進めていました。このように、課題の中でもやっとした箇所に遭遇した時、単なるテキストやマークダウン形式での情報整理は難しい部分があります。意識していないと論理展開や流れがぐちゃぐちゃになってしまうためです。

今後同様の状況に遭遇した時は、今回の講演を思い出し、マインドマップにチャレンジしてみたいと思いました!

ゆっきーの感想

私はマインドマップの本を読んだことがあり、実際にテスト活動で利用しています。しかし、マインドマップで上手くテスト観点を発想・発散できないこともあり、改めてもう一回全体を読み直し、振り返ってみたいと思いました。

今回の講演を通じて印象に残ったのは「"発想"という行為と向き合う」という言葉です。ここに私の悩み解決のヒントがありました。マインドマップを長く利用していますが、私は発想との向き合い方を間違った方向に捉えつつあったように思います。「今、思いついていない新しい観点を思いつかなきゃ」と考え、「そのためにマインドマップを描かなきゃ」という思いに捉われてしまい、その思いが逆に自分を縛っていたことに気づきました。潜在的な記憶にある知識や経験をハッと思い出す感覚を「新しいことに気付いた、思いついた」と勘違いしていたのです。池田さんがおっしゃるように、知識や情報、経験といった発想の源泉を増やしていかない限り、マインドマップをどれだけ描いたとしても発想が豊かになることはない、と改めて心に響きました。

今回の講演をもとに、日々の勉強や経験を大事にし、楽しみながらマインドマップを使い続けたいと思います。

ワークショップ「実践!マインドマップを活用したソフトウェアテスト+活用事例」

  • @kinu
  • @いいね (iine)

本ワークショップでは、基調講演の内容や講師である佐藤さんの説明をもとに、マインドマップを活用したテスト分析に取り組みました。 ワークショップの具体的な内容については公開が制限されているため、それについては今回は割愛しますが、得られた学びを共有します。

公開された当日の資料はこちらです。

kinuの感想

基調講演を聴いて、「マインドマップは思考の発散に威力を発揮するツールである」と理解したのですが、実際にマインドマップを描くことで、何を発散の起点にするか(セントラルイメージ1の置き方)、どう発散させていくか(メインブランチ2の置き方)、といった難しさを実感しました。 セントラルイメージがあいまいだと思考が発散しすぎて収拾がつかなくなりますし、メインブランチの置き方が不適切だと思考を制限してしまいます。
一人で考えているとそのあたりで思考が詰まってしまいますが、今回はペアワークだったので、ペアを組んだいいねさんと相談しながらマインドマップを改善できました。
特に私といいねさんとではロールが異なっていることもあり、お互いに自分では思いつかなかった観点を取り入れることもできました。基調講演でも複数人によるマインドマップ作成の良さは語られていましたが、それを身をもって実感できたのではないかなと思っています。

いいねの感想

マインドマップの「思考を辿る」という側面が、最近チームで実践しているADR(Architecture Decision Record)に通じるところがあるなあと感じました。どちらも意思決定を行う際の結論に至るまでの流れを重視しており、チームが拡大するにつれて発生する「経緯の認識合わせの難しさ」への回答の一つだと感じました。特に、マインドマップは1ドキュメントであるADRに対して、マインドマップを描いていくことそれ自体を実際の体験として情報共有を行うことができます。マインドマップは、自分の思考を整理するためのツールとしてだけではなく、他の人に思考の流れを伝えるためのツールとしても使えるなと、ワークショップを通して実感することができました。自チームでもマインドマップワークショップを実施してみたいと思いました。

一方で、マインドマップを描くのは記法の訓練、イメージ・ブランチの置き方の訓練が必要だなあと思いました。セントラルイメージ・メインブランチの切り方はキモの一つで、ここがちゃんとできるかどうかでマインドマップが収束するかが決まります。セントラルイメージ・メインブランチがふわっとしてる場合、自分の中でのイメージがうまく広がらず、その枠を超えて新しいアイデアを出すのが難しかったです。ワークショップ内でも触れられていましたが、セントラルイメージ・メインブランチの設計に十分な時間をかけることが大事だなあと思いました。こういった課題は、マインドマップを書籍を元に学習するだけではあまり強く実感できなかったでしょう。今回ワークショップに参加し実際に触れることができて本当によかったです。

講演振り返り

@irie.shou

講演の最後はQ&Aコーナーがあり、色々な質問が会場やオンラインの参加者から飛び交いました。 特に今回の講演の主題であるマインドマップについての質問がやはり多かったです。 その中のいくつかをご紹介いたします。

Q.マインドマップのルールや定義を教えてください。
A.ライセンスがあるので、具体的なことを伝えるのは難しい。しかし描き方はある程度揃っていたほうがいいなと思う。コーディングルールと一緒。その描き方が揃っていれば、あとは自由に描いてみる。私(池田さん)の場合は目的を定めるためにセントラルイメージ描くだけで20分〜30分かかることもある。絵=第一言語なので、それをしっかり描くようにしている。楽しみながら描く。

Q.マインドマップは手書きでやった方がいいのでしょうか?
絵心がなかったり、字が汚かったりする場合、XMindのようなツールを使ってもいいのでしょうか?

A.絵心がなくてもシールで代用する人もいるので、アイデア次第だが手書きにこだわるべきだと思う。 手書きにこだわるのは思いついたものを残しておきたいから。PCだと簡単に消せる反面、思考の過程まで削除されてしまう。付箋を使うのもいいかもしれない。

Q.PCでマインドマップツールを使うと、手書きでのメリットがなくなってしまいますか?
A.PCでマインドマップツールを使う場合、複数人で編集するシーンもありそう。ただ、初期の頃はマインドマップは個人でやったほうがいいかもしれない。他の人の内容に引っ張られて、うまく発散できないことがある。最後に、複数人が発散した内容を集約する時にPCツールを使うのは良さそう。

などなどです。

irieの感想

私も今までマインドマップを描く作業はすべてPCで行っていました。手書きでマインドマップを描くのはほぼ初めての体験だったため、似たような疑問を感じていました。 「本当にセントラルイメージは絵を描く必要があるのか?」や「手書きで大きな紙に描いていく必要があるのか?」などです。

しかし改めて、池田さんのアンサーを聞いて、なるほどな、と納得感を得られました。 確かに今回、ワークショップで手書きで絵を描きながらマインドマップを作成してみて、楽しいなと感じることがありました。PCでマインドマップを作成している時は、ただの作業感しかなく、淡々と行っていることがほとんどでした。 しかし手書きでいろんな色を使って、絵を描いたり、文字を装飾したりして発散していく作業は楽しいし、線の曲線一つ一つを描くことにも神経を使い、脳を刺激されるような感覚でした。 確かにPCでマインドマップを作成することは楽で、作業も早いですが、まずは手書きでマインドマップを作成する思考プロセスを習慣化することで、現在のマインドマップのスキルを更に向上させられるのではないかと感じました。 今後は積極的に手書きでマインドマップを作成していこうと思います!

実行委員セッション

ここはgofが感想を書きます!

実行委員セッションとして「勉強したらどうなるの?」と「CREの守護者たち DevOps×シフトレフト - 俺またプロダクト救っちゃいました!?」というタイトルでLTがありました。

「勉強したらどうなるの?」について

話す勢いがあってとても魅力的でした!

もし勉強しなくても仕事が回っている状況であっても、勉強を続けることでどのような変化が起きるのか、また逆に勉強しなかった場合にどのような悪い変化が起きる可能性があるのか、という発表でした。
私自身、日々の勉強の重要性は理解しており、日々努力を続けています(もしかしたらまだ足りないかもしれませんが、そこはご愛嬌ということで)。

発表を通して特に印象に残ったのは、「今まで見えなかったものが見える」「知識は使ってみて、応用してみて、経験して初めて生きてくるのです」という部分です。これは確かにその通りだと思いました。 私の具体的な経験を一つ挙げると、昔「とあるソフトウェアテストの本」を読んで、組み合わせテストという手法を知りました。その時は「テストケースの数を減らせる便利な手法だ!これは使えるぞ!」と思い、早速現場で使ってみました。 しかし、最初に活用したときには、特定の組み合わせを全て網羅するテストが必要で、「有則」3なテストでは2因子間網羅では不足してしまう場面があり、うまく活用できませんでした。 それでも、その苦い経験を経て数年後、現在では「ここは組み合わせテストが使えるのでは?」と自信を持って活かせるようになりました。学ぶことで自分ができることが増えるのは本当に面白いですよね。応用して自分のものにすることの大切さを改めて感じました。 これからも学んだことを積極的に活かしていきたいと思います!

「CREの守護者たち DevOps×シフトレフト - 俺またプロダクト救っちゃいました!?」

話す勢いがあってとても魅力的でした!(10分ぶり2回目) 実行委員長二人ともエネルギッシュで、イベント全体が元気になるのを感じました。

この発表では、チームリーダーの立場からの取り組みの共有でした。具体的にはCRE(Customer Reliability Engineering)として「攻めの運用」と「守りの運用」の定義、E2Eテストの運用を通じたシフトレフトなどについて発表されていました。

また、シフトレフトについて「プロダクトに携わる開発者全員が意識を向けるべきもの」という点は非常に共感しました。 私はQAエンジニアの立場からシフトレフトに取り組んでいます。例えば仕様に関するレビューを通して、テスト実行時ではなく早め早めに不具合を予防できるように努めています。なぜそのようなことをやっているかと言うと、「テストの原則3. 早期テストで時間とコストを節約4」にも書いてありますが、不具合の発見が後工程になるほどコストがよりかかってしまうため、それを避けるためです。 私自身もシフトレフトに貢献している部分はあるのですが、QAエンジニアだけがシフトレフトを実現することはできないと常々思っています。仕様に関するレビューを例とすると、私だけが仕様を決めることはできないですし、QAエンジニアだけがレビューしたとしても、他のエンジニアが対応してくれないと実現できません。つまり関係者全員の協力が必要です。そういう意味でも全員がシフトレフトに意識を向けるべきというのは、すごく共感できる内容でした。

さらに、「攻めの運用」と「守りの運用」を明確に定義し、実際に6:4の割合で「攻めの運用」を実現している点は魅力的でした。 一般的には運用は「守りの運用」が主流であり、今まで私自身の運用の経験のほとんどが「守りの運用」でした。思い返せば、シフトレフトということを意識することができなかったため、問い合わせとその不具合対応だけが中心になっていて、改善する時間がなかったのかもしれません。当時を振り返ってシフトレフトを検討すれば良かったという思いも踏まえて、私の近くのチームがシフトレフトを加えて「攻めの運用」を推進できていることは魅力的に感じました。

他には、「E2Eテストの運用改善」に関して、QAエンジニアとして私も携わっていたので、こういった場面で発表してもらえるのは非常に誇らしい気持ちになりました。 私はシフトレフトのアプローチの一環として、今後ユニットテストの品質向上に取り組んでいきたいと考えています。その時は開発エンジニアのてっしーさんと協力させていただいて、さらなる成果を生み出し、どこかの場で発表できるよう頑張っていきます!

さいごに

いかがでしたか?
今年の講演もお昼から夕方まで、とても濃い時間でした。講演で得た知識をワークショップで実践できる流れはとても良かったです。
最後にてっしーさん!3年間、JaSST Kyushuの実行委員長、本当にお疲れ様でした!

マネーフォワード 福岡開発拠点ではQAエンジニア・SDET・エンジニアを募集しています!
カジュアル面談も実施しておりますので、少しでも興味を持たれたそこのあなた!ぜひエントリーお待ちしております!
hrmos.co

福岡開発拠点のサイトもあるのでぜひご覧ください。
fukuoka.moneyforward.com

余談

こんにちは。マネーフォワード ERP開発本部 ガーディアングループ クラウド経費チーム 兼 JaSST'24 Kyushu 共同実行委員長のてっしーこと@tositeです。
改めてJaSST'24 Kyushuにご参加いただいた皆さま、本当にありがとうございました!

私は今回が3回目の沖縄だったのですが、参加したマネーフォワードメンバーのうち、多くのメンバーが初めての沖縄とのことでした。
そこで、「JaSST'24 Kyushu アフターツアー in マネーフォワード」と称して、参加した社内のメンバーとともに沖縄を巡るツアーを企画しました。
「沖縄と言えばやはり大自然を感じるビーチ!」ということで、シーカヤックをメインに、綺麗な青い海を一望できる古宇利大橋、そして沖縄らしく沖縄そばを組み込んだプランを立てました。
一週間前までは雨予報となっており、当日までどうなることかと心配していましたが、どうやらメンバーの日頃の行いがよかったのか、当日は快晴で迎えることができました。

まずはレンタカーを借りて、今帰仁村へと向かいました。
今帰仁村は、沖縄本島の北部に位置し、美しい海岸線が広がる場所です。
懸念していた天気も申し分なく、むしろ日差しは刺すような暑さでしたが、穏やかな海と波の音を背景に、最高のコンディションでシーカヤックを楽しむことができました。

シーカヤックからの写真。透明なシーカヤックからは青い空や海だけでなく、透明な海底を一望できる。時折現れるサンゴ礁には色とりどりの熱帯魚の姿も垣間見えた。

その後は古宇利島へ。
古宇利島は、古宇利大橋という橋が架かった直径約2kmほどの小さな島です。
古宇利大橋から望む今帰仁村の海岸線は、まさに絶景という他なく、青い海と青い空が一体となって、まるで絵画のような美しさでした。

kourijima.info

その後は古宇利オーシャンタワーに登り、360度のパノラマビューを楽しみました。

古宇利オーシャンタワーからの風景。360度どこを見渡しても白い砂浜とサンゴ礁が織りなす海が広がる。海底はサンゴ礁と白い砂浜が織りなすコントラストが綺麗で、まるで映画の世界の海のようだった。

アクティビティの後、沖縄らしく沖縄そばを堪能し、沖縄の自然を満喫した一日を終えることができました。

tabelog.com

余談ですがここの沖縄そばはシンプルながらも非常に力強い昆布と鰹節の甘味と風味を感じることのできるもので、沖縄で食べたそばの中でもかなり上位に入る美味しさでした。
沖縄そばと言えば欠かせない調味料としてコーレーグース(島唐辛子の泡盛漬け)が挙がりますが、この素朴ながらもどっしりとした旨味のスープは、コーレーグースの強い香りに負けることなく、互いが互いを支え合って一段階上の味わいを提供してくれました。

また、麺も若干太めかつ固めに茹でられており、沖縄そばの欠点である食感を見事にカバーしていました。
三枚肉やソーキは非常に柔らかく、甘辛く煮込まれており、それでいて全体の風味を妨げることのない優しい味わいでした。

「昔ながらの沖縄の食堂」といった風体で、実際に多くの地元の人々が利用される店舗でしたが、その分、リアルな「地元の味」を提供してくれるお店だと感じました。
また機会があれば伺いたいです。

三枚肉そば。一般の沖縄そばと違い、結び昆布があしらわれている。トッピングは非常にシンプルで、三枚肉・結び昆布・刻みネギだけであった。

なかなか会社のメンバーと旅行や遊びに行く機会もありませんが、今回のツアーは非常に楽しいものでした。
私の過去の沖縄の経験を活かして、楽しいアフターツアーを企画できたのであれば幸いです。
最後に、参加者全員で撮影した集合写真を掲載して結びの言葉とします。
また次回のイベントでお会いしましょう!

古宇利オーシャンタワーで撮影した集合写真。青い海を背景に、参加した7人が写っている。左からsekky・kinu・tosite・いいね・gof・irie.shou・ゆっきー。


  1. セントラルイメージとは、テーマをイメージした象徴的なイラストのことを指す。一般的にマインドマップはこのセントラルイメージを紙の中心に描くところから始まる。
  2. メインブランチとは、テーマであるセントラルイメージから伸びている一階層目の太いブランチのことを指す。
  3. 「有則」とは、組み合わせに特定のルールがあるものを指す。「無則」とは、組み合わせに特定のルールがないものを指す。例えば入場料のテストを考える場合、「人数(10人以上の場合に割引)と年齢(18歳以下の場合に割引)の組み合わせ」は有則に該当する。一方、「各クレジットカードブランドと各ブラウザごとの組み合わせ」は無則に該当する。
  4. 「プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。SDLC の後半に発生する故障が少なくなるため、品質コストは削減される(Boehm 1981)。早い段階で欠陥を見つけるために、静的テスト(第3 章参照)と動的テスト(第 4 章参照)の両方をなるべく早い時期に開始すべきである。」 JSTQB®, テスト技術者資格制度 Foundation Level シラバス, Version 2023V4.0.J02, https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf