JaSST'25 Tokyo ２日目 に行ってきました。
1日目の内容
セッションメモ
- ソフトウェア開発現代史：なぜ日本のソフトウェア開発は「滝」なのか？製造業の成功体験とのギャップ
Japan as number oneから50年。今はmagnificent7。
アメリカのMBCが1980年にアメリカが日本を特集していた。
デミング博士は日本でできていることはアメリカでもできると考えていた。
日本はアメリカが真似た製造業の産地のはずなのに
2020年時代で欠陥を右に流すなが守れていない。
2007年、トム・デマルコは日本のソフトウェア産業を批判していた。
アメリカと日本の文化の違いでアジャイルが根付かないのか？
1970年ロイズがフィードバック含めてウォーターフォールの話をした。
ただ、他の人間が別の解釈をして、滝が落ちる形となった。
間違ったウォーターフォールを続けていてよいのか？
ウォーターフォールはコンピューターの性能が今とはまったく違う時代に生まれた。
アメリカではうまくいかずラショナル・ユニファイドプロセスを生んだ。
品質系の人間中心に実績ソフトウェアエンジニアリングという本が改版されていった。
CMM登場し、日本企業も取り組んだ。日本は大きく躓きCMMが加速した。
アメリカは日本を研究し4年で追いついたが、アメリカで醸成された文化は移入されなかった。
日本の製造テクニックはアメリカで発展したが、アメリカでもソフトウェアの成長に苦戦した。
効果的に計測できないと改善ができないことが問題だった。
ただ今はツールも発展しているので、計測して改善をしていくことができる。
■感想
少し前にXで話題になっていたこのスライドを読んで今回の講演も楽しみにしていました。
最終的に測定が大事であるという結論から、Findy Team+に流れるのが凄い。
-
「舞踏会」が加速させる「知識の宴」— アジャイル思考で学びのサイクルを回し、継続的に進化する勉強会
ふりかえりをしたが学びのほうが必要だった。
学びのためにふりかえりではなく、勉強会をはじめた。
勉強会で消化しきれないためにふりかえりをはじめた。
勉強会で学びたいコンテンツに対して取捨選択をはじめた。
業務に適応できるもの、課題にあったものを厳選しはじめた。
継続した改善を続ける。
■感想
学びをチームのものとして進める重要性。
改めて形式に倣うだけでなく、実態をもとに何をするか考えたいと思いました。 - 現場からお届けします〜モバイルアプリテストにおける工夫と挑戦〜
■スピードと品質を保つために工夫していること。
・メルカリ
リリース判定用のリグレッションテストのテストスイートがある。
ケースが多くて実行が遅くなることを避けるため厳選している。
・マネーフォワード
判定会議で問題が発覚すると対応時間がない。
コードの変更行数に対して、バグの発生件数を見積もった。
その軸に対してバグの発生件数をもとに開発の健全性を測っている。
バックエンドのみに依存する改修はAPIテストにとどめるなど工夫している。
リグレッションはできうる限り自動化で打ち取れるようにしている。
・Voicy
手動でのリグレッションテスト。
もともと新規開発のときのテストケースがリグレッションテストになった。
機能が増えるほど苦しい状態が続いた。
基本動作のみ保証できるようにケースを厳選した。
■多様化するモバイルアプリ開発にどう立ち向かうか
・メルカリ
PlayWrightでのE2Eをマージ時と毎日自動で走らせている。
特に実行時間に問題は無いため、両方同じものを使っている。
E2Eの対象はビジネス上での重要度の高いものから実現している。
WEBなので実機依存は高くなく、シミュレーターを採用。
ユーザーに届けたい価値を既存しないことを確認するためにE2Eしている。
・マネーフォワード
自動テストは機能を乗せる遅くなるので対象を厳選している。
但し、手動テストはできる限り減らしたいので、適宜考えている。
MagicPod専属のQAメンバーがいる。
実機依存は高くなく、速度を重視してシミュレーターを採用。
・Voicy
重要度を高中低に分け、自動に向いているかで自動化を検討している。
（音声は向いていない）
具体的にE2Eに対する認識合わせをしている。
■クロスプラットフォームのメリデメ（メルカリ）
片方だけテストすれば結果が分かる。
但し、落ちるとダメージがでかい。
■QA改善のための工夫
・Voicy
再生・収録それぞれのアプリがあるためリリース頻度が多かった。
工数を作るためリリース頻度を下げた。トータルの機能数は別に減らなかった。
反発や悪いリアクションは無かった。
PdMとの調整は難しかったが、必要な場合は再生を連続してリリースするなど工夫をした。
・マネーフォワード
チームの合意を形成するために半期の目標に入れる。
■感想
かつてスマホアプリ開発に携わっていたため興味深い内容でした。スマホアプリ開発に限定せず学ぶ内容が多かったです。
当時は開発者でテストをしていましたが、アプリサイドとバックエンドで関心ごとが変わるので、QAという仲介者は必要だったのではと改めて思いました。
健全なプロダクト開発を実現するために、PdMとリリーススケジュールの見直しをするお話も、役割を越えたプロダクトに向き合う重要さを感じ、自分も意識したいと思いました。
Sammyさん、ここでのお話も興味深かったです。 - タイミーQAのリアルな挑戦：DevOps時代の開発生産性と品質文化を創造する
QAチームはQA Enabling Gとして、２つのストリームアラインドチームをイネーブリングしている。
価値あるプロダクトを素早く届けることをミッションにしている。
QAのタイミーは計６名。協力会社も状況によって採用。
テストは開発者全員が行っている。
QAチームができたのは2024年3月。
QAコーチ。スクラムチームが自律的に品質保証できるように支援。
リリース後の障害対応含めたプロセス改善。
品質指標の分析としてODC分析を導入。データドリブンなQAを実現。
障害の重大度の判定基準にSecurity Level（SEV）を導入。
開発者の障害に対する解像度もあがった。
SET（Software Engineer in Test）。
開発者の品質意識は高い。テストを書く文化はできていた。
ただ、全体見渡したバランスは取れていないため、整理を進めている。
今後、CriticalUserJourney（CUJ）をPOやSREと強調して品質基準の策定を考えている。
■感想
タイミーさんのチームトポロジーを中心としたお話、いつも勉強させて頂いています。
イネーブリングチームとしてのQAチームの役割の在り方について学びになりました。
特に品質に対するチームでの共通理解を作るための指標作りは取り組みたい。 - コドモンのQAの今までとこれから-XPによる成長と見えてきた課題-
自前の自動テストからAutifyで大枠のE2Eの準備を。
2021年からXPをスタート。
今まで。
・プラクティス：ペアプロ、TDD
壁１：最初は分からない言葉だらけだった。開発者に聞くことで解消。
壁２：チケットのストーリーが大きい。チケットを分解。
・プラクティス：受入テスト
PdM、PDが一番ユーザーに近い。その想いをテストケースとして起こせるようにした。エンジニアも機能の目的が分かるようになった。
・プラクティス：継続的インテグレーションテスト。
まず動く環境が必要。Github Actionsで構築。
今後。
XPでのテスターは、開発中に作るテストの質をコーチングによって高めていく人。
シフトレフト、シフトライトの判断力をあげていく。
※参考
※memo
■感想
今日一番刺さった発表だったかも知れません。
昨年１日打刻できない日がありましたが、その時は特に大きく意識はしていませんでした。
ただ、園で子供を預かった記録が残らないことは、よくよく考えるとけっこう大きな問題であり、
そういったことが無いようにシステムの品質を保つことがQAエンジニアの役目であると考えると、QAエンジニアの役割の大きさを感じます。
貴重な学びとなりました。そして何よりいつもアプリの健全な運営を下さり感謝です。 - リーダブルテストコード〜メンテナンスしやすいテストコードを作成する方法を考える〜
ユニットテストの全体感を表したうえで、細かい部分でのブラッシュアップを行う。
細かいブラッシュアップを行うことで、観点が明確になり分割ができるようにもなる。
分割すると観点が明確になりテストを消したいときに消しやすくなる。
テストレベルに対する考慮。
ピラミッドをもとに最適なテストの分解ができる。
ストーリーを細かい行動に落とすことで、E2Eからユニットテストまで落とし込める。
縦軸の正常系は重複を気にしない。ユニットテストは横軸での網羅ができているかを気にする。
E2Eはヒューマンリーダブル、マシンリーダブルを評価するために、アクセシビリティ特性が使われる。
アクセシビリティが高い画面はテスタビリティが高い。人間にやさしいものはAIにもやさしい。
※参考
■感想
デブサミでも興味深く聞いており、今回も楽しみにしていました。
t_wadaさんや末村さんのお話は自分の開発者としての延長線上で聞けるのに対し、ブロッコリーさんのお話がQAとしてのお話でアプローチが異なり、視界を開ける感じがします。
作りながら同じアプローチが取れたらと思いつつ、主観から離れづらいのだろうか。
４月から久しぶりに開発の実作業を担当できるので試してみたい。 - 「真の学び」が未来を拓く～成長するエンジニアのマインドセット ～
輝き続ける人、能力あるけどもったいない人の違い。
マインドセットが違う。
気構え・意識は、能力、行動を下支えしている。
年を重ねるごとに能力、行動が増大する。
・心の声
・実践
・師
心の声：自分がなにをしたのか。それはなぜか。目標より目的が大事。
実践：勉強より実践を通した学びのほうが大きかった
目的があると持続力がつく。目的を明瞭化する。
実践は継続的な反復。反復することで学びを得る。目的に向けた改善ができる。
勉強するだけではこの学びができない。
師：自分が心からこうなりたいと思える人。自分の成長分野で努力し成長し続けている人。他者の成長を心から喜べる人。
完璧な人はいない。否が見えた時に否を含めて受け入れることが重要。
組織は社会的な道具。組織で働く人を成長させるもの。
問題解決に対する学び。人の成長は問題解決にあたる学び。
実践して結果を出すと、自信ができる。成長につながる。
次の結果につながる。
時代の急速な変化により、問題がスピードがあがり、多様化、複雑化している。
卓越した技術・スキルが求められる。卓越性の追求。
現場は対応すべき課題が山積みで、目の前のことをやるしかなくなる。
刹那的達成感を克服しないと、組織も個人も成長しなくなる。
実践して得た結果は誇りになり、個人の行動変容を促す。
そのためには、卓越性が重要。問題解決と技術習得がそれを指す。
人にできないことをいくつできるようになったかが重要。
人は成長しないと退化していく。
自分の領域内のことだけではうまくいかない。
真似て。自分自身で答えを見つける。社外の常識に従う。
いいとこ取りではなくすべてを真似る。次に考え方を真似る。
次に自分自身で答えを見つける。そのために書く、話す、やってみる。
解決策のない問題はない。外に答えを見つけに行くことが重要。
それを習慣にしていく。
歴史に学ぶ。明治維新では既存の枠組みにとらわれず外を見ていた。
常に世界をみることが重要。
経営者に学ぶ。人が育つ仕組みを学ぶ。
■感想
人は勉強からは学べず、問題解決を通した学習からしか成長できないといったお話が刺さりました。
目的やそれに伴う問題意識を持って、知識・情報と接したい。 - クロージング
来年は3/20（金）（祝）東京ビッグサイトでの開催。
感想とまとめ
学ぶの多い２日間でした。
品質について、QAについて、テストについて、コミュニティについて。
Findyさんの朝一番の内容から最後の学びについての講演まで、
目的をもって問題を解決しながら学び、随時測定をしながら改善していくことの重要さを改めて学びました。
何より、勉強は活きず、問題解決でしか人は学べない、という言葉は、昨日の懇親会でも実感したことでした。
そのためにも目的を持って知識を得て、得た知識を実践して経験していきます。
経験を通して学んだことから、改めて知識や情報を整理し、次の適応をしていく。
それをひとりではなく、複数人で、チームで実践できるようにしたい。
今回一番嬉しかった出来事は、t_wadaさんにはじめてご挨拶できたことかも知れません。
オーム社ブースで実践ソフトウェアエンジニアリングを手に取ったところ、
t_wadaさんがいらっしゃりお声がけしてしまいました。
しかも廊下で！！t_wadaさんに！！嬉しいできごとです。
講演資料は後日公開されるし、なんなら動画も公開される。技術カンファレンスに参加しないと得られない価値は「廊下で話す」こと。 https://t.co/DqNuHJhHsj
— Takuto Wada (@t_wada) 2019年10月17日
t_wadaさんのテスト駆動設計のご説明の中の
テストを先に書くことで作り方だけでなく使われ方を意識でき、
フィードバックサイクルを回すことができるというお話が好きで、
そこから開発のプロセス内にフィードバックループを作る重要さに気付きました。
感謝です。。
今週月曜はFindyさんのイベントで増田亨さんにもご挨拶できたし幸せな１週間でした。
廊下話ではパウリさんにも初めてご挨拶を。
emconfはじめ、エンジニアとしてとてもお世話になっています。
ForkwellさんのEMについてのお話を聞いてから、EMというロールを意識でき始めました。
よく自分が出かけるイベントにいらっしゃるので、いつかご挨拶を～と思っていたので念願でした。
学びを現場に持ち帰ります。やりたいことが多くあります。
そして、メンバーと一緒にフィードバックを回したい。
蛇足
本日はつけ麺を。美味でした。
