# タイトルコール テスティングチャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索するをコンセプトに、 エンジニアリングマネージャー兼経営リーダーのサミーが、 ソフトウェアテストのコツや品質保証の奥深さ、そして日々考えていることをお話しします。 # miisanとアフタートーク ということですね、みーさんとのアフタートークということで、まず最初に簡単にこのチャンネルの紹介もさせていただければと思うんですけど Testing Journeyといいまして、基本的にはソフトウェア品質だったりソフトウェアテストの話をしているんですけど 最近チャンネル名変えましてTesting Journeyっていう言葉に込めた思いが ソフトウェアの世界だったりソフトウェアテストの世界を探索するっていうのをコンセプトに 日々考えていることとか、うまくいったことを失敗したこととかを探検していくっていうのを 私だけじゃなくて大きいレクサクいてくださっている方々と一緒に探索していきたいな、一緒に学んでいきたいなという思いを込めて Testing Journeyというチャンネルを運営しております。 毎日お昼の12時半に放送を出していますので 空いてる時間、ランチの後とか、あとは通勤中だったり家事をしながらとか ぜひ聞いていただけると嬉しいです。 チャンネル紹介でした。 逆にといいますか、みいさんのことをもしかしたら知らない方もいらっしゃるかもしれないので 簡単に自己紹介をお願いできますでしょうか。 今日お昼のイベントでご一緒させていただいた、今所属はレイワトラベルという旅行プロダクトを作っている レイワトラベルに所属しているみいさんと申します。 今チャンネルのお名前の話を聞いてめっちゃいい話と思っていて 旅とかってまさに探索だなと思って、そこをすごく奥深いなと思って聞いていました。 よろしくお願いします。 ありがとうございます。そうなんですよね。私もみいさんも旅行好きというところがあって 旅行っぽいワードも入れたいなと。 めっちゃいいですね。 思ってジャンニーという言葉を入れました。 素敵です。 じゃあ早速アフタートーク入っていきたいと思うんですけれど、何から話しますかね。 いろいろと触れきれなかったこともたくさんあったなと思ってますけど 最後仕様の話とかは結構直近、今の私の会社でも何がいいんだっけっていう話は すごいしているので、そのあたりは各社どうしてるのみたいなのは正直聞いてみたいなっていうところではありました。 仕様の管理っていうのは日々、いろいろ変わっていくというか、今の既存の仕様とかも含めて 新しい案件の仕様も含めてどういうふうに管理してるかっていう話ですかね。 課題感どんな感じですか。 自分が今はすごく難しいなと思っていることが、人間とAIがどちらも理解できる形で どうコンテキストを設計するのかっていうのが、今までは人が理解できるっていう文脈での過読性をすごく重視していたけれども データベースだったりとかコンテキストをどう設計したかで、その後続の速さと質を結構変えるなっていうふうに思っていて 例えば今複数のプロダクトとか事業をやっている中で、いくつかトライアルをしているんですけど ある新規事業とかでは100%GitHubでドキュメント含めて管理してやってみようみたいなことをやったりとかしたときに 全部そこで情報の本的とか完結するので、やっぱり誤字脱字とかそういうレベルのものは全然起きなかったりとかするみたいなところで どこに共通コンテキストを置くのかみたいなことをいろいろ考えていて でも果たして他のプロジェクトだかと、もともとNotionに慣れ手があってFigmaにUIがあって さらに言うとDocsにあってMiroにあってみたいな、いろんなところにいろんなコンテキストが散らばっていて さあこれ仕様の管理をどうしていくと一番いいんだっけみたいなところがすごい悩ましい どうしてるんだろう他の会社さんはみたいなところをすごく今は悩んでいるところですね なるほどですね ボイシー社はあんまりそこまで行っていないというのが正直なところで いろんなところに散らばってるっていう そうですよね、そうなりますよね それはもううちもそうです そうですよね 新機能のPRGの要件とかはコンフレンスにまとまっているので コンフレンスだとクロードコードからは読みに行ける気がしますね どこにUIとかロジックとか元々がどうあって変えた部分とかってあります? それこそ今回のイベントのAIが出てきて変わったこと変わらなかったことみたいなところとかも 1個質問とかにありましたけど変わったポイントもしくはそのまま今やってるポイントとかってありますか? 変わったポイントね、ちょっとパッと出てこないのあるかな コンフルを使い始めたプロダクト開発でも ここにしっかり集めていこうねみたいな流れになったのは割と最近なんですけど でもそれがAIだからっていうわけではないですね なるほど、ベースとしてのドキュメンテーションの管理の仕方として コンフレンスを採用してやっていくといいんじゃないかみたいなのが いろんな文脈であったみたいなことですかね そうですね、結構Kiberaも使っているし コンフルもあるしグーグルドックスもあるし っていう風になってたんですが 少なくともプロダクト関連のものはコンフルに集めていきたいよねみたいな感じになっていて ジラの方というかトラシアの製品の方にAIの機能が載ってきて 確かに確かに、なるほど 要約ができたりとか ジラのタスクの検索が自然言語で簡単にできたりとか っていうのがあるのでそこをうまく活用できるかなみたいな流れですかね なるほど、ちなみにコンフレンスを採用したのは ジラとかをもともとタスク管理で使ってたとか 他の相性の組み合わせで決められたんですか どうなんですかね、コンフルは結構前から使っていて 社内ルールとかでも使っていたようで なので逆にアサナからジラにしたっていう感じです 確かにそこはその方が確実に良さそう 連携がしやすいですよね、プロダクト開発っていうのと 連携しやすいからジラにしましょうって言って アサナからジラに移行しました いいですね、なるほど そういう隣のものとの組み合わせでの最適化を 考え直すみたいなこともあって そこの新しいものを入れる、これ入れないとかの 意識点も含めてすごく難しいなって最近思ってますね 仕様の管理のところはねわトラベルさんでは どういう風にやってるとかやりたいなみたいなのあるんですか ベースは最終的にアウトプットが出るラインに寄せるみたいなのが 一番変じゃないかみたいな仮説があって それもあってGitHubにドキュメンテーション寄せたらどうなるみたいなことを ちょっとやってみようよみたいなことが 今年にあった動きとしてあったんですけど とはいえ元々のやっぱそのものを全部代移動するとかっていうのは 現実的にはなさすぎてやりきらないよねっていうところがありましたと 元々どういうベースの環境があったかで言うと 使用のコアロジックみたいな部分とかは ノーションベースで管理されていて UI UXとかの体験に近いものは デザイナーさんとかが使いやすいみたいな文脈も含めて Figmaに管理されていたっていうところがあって Figmaとノーションを行き来するみたいなことが 使用みたいなベースで言うと前提としてあったので その2つを一気にGitHub上に移動するって 大工事ですよねっていうので ちょっと既存のプロジェクトに関しては それを急いでやるかっていうのは今は ステージしてるっていうところになってますと ただ早くどこがもっと効率的にできるかなみたいなところで言うと FigmaのAI機能だったりとかを うまくコンポーネント化して使うっていうところで うまくフロントエンドの作り込みみたいなところを 共通化できないかみたいなところの動きは ちょっとずつ進んでるみたいなところが 直近で変化みたいな感じですかね 私ちょっと分かってないのは AIに加わせるとかインプットするにあたっての コンテキスト揃えるみたいな文脈で ツールも揃えたほうがいいものなんですかね すごく難しいですよね 今日のお昼の話でもどんどんAI使ってもらいたいから 制約なく今は使ってますみたいなことを 小石さんでもやってるってことを おっしゃってたと思うんですけど 例えば今日さみさんも事例として紹介してくださった クラウドスキルとかも ナレッジというかアウトカムを得るためには ベースそこのラインに乗ってないと それを享受できないみたいな ある種の制約みたいなのはあるなと思っていて その時に自由とどこに集着させていくのか みたいなのはすごいバランス難しいなと いろんなツール上にいろんな 私のいいナレッジ構築術みたいなのができても 隣でどうやるんだっけみたいな プロジェクト変わって 次のチームはベースの考え方が 全然違うツールの中で開発しますとかだと キャッチアップコスト含めての高さとか 弊害とかがいろいろ 将来的に出てくるよなっていうのは ちょっとずつ感じているところですね 今はこれだけ使ってねみたいなのは 大枠のラインではないですけど 多分そういうことは起きるんだろうな みたいなことは思っていて 一定のこれ使ってねみたいなのは 制約は出てくるんじゃないかなとかは ちょっと思ったりとかしてます そうですよね 多分あと半年後なのか1年後なのか 等々出されていくと だんだん使うツールが決まってくるのかもしれないですよね 私が言いたかったのは AI使って 例えばテストなんとかをする 計画だったり分析だったり 何でもいいんですけど インプットするFigmaの情報だったり EPRDの仕様の情報っていうものを みんさん先ほどGitHubをまとめて インプットしやすいようにした というふうな話だったと思うんですけど そこをGitHubに寄せたほうが AIにとっていいことっていうのは 情報探しにいくスコープとかが 減るっていう話なんですかね そうですね そこも多分1個あるかなと思っているのと それこそ今回はガードレール デザインのルールとか品質のルールに合わせて 動いてくださいねみたいな指示書を含めて 同じ箱に作れるので そのベースラインから 開発をしてってくれるっていうことになるので 逸脱したアウトプットが すごい出づらいなみたいなことが 1個期待できるかなとは思ってますね ありがとうございます 今ちょっとまたいらっしゃった方がいるので たかださんとなすてちさんと さっきしゅみずけんさんがいらっしゃったんですけど 消えましたね ありがとうございます よく遅いらっしゃいました 何だっけ 仕様の話ですよねツール すごいリスナー なんかすごいラジオみたいです すごいですねさすが慣れてらっしゃる ありがとうございます お名前とかお呼びした方がやっぱり 確かに 嬉しいかなと私も嬉しいですし 今ハートマークが飛びましたね ポイシーマークが いい話だ 何だっけ 仕様の話かな ツールはタブとか コンテキスト一箇所にまとめられるから その方がAIが処理をしやすいというか コンテキスト一箇所にまとめた方が 管理も楽だし 出力の時のブレというか ハルシネーションというか コンテキスト読みやすくなるってことですよね そうですね あとあれだ 今ファッと整理していただいたことで 思い出した副次的な効果みたいな 話であったことで言うと 途中から参画した 人間のオーボーディングもめっちゃ早かった っていうのがあって なんか通常って あの話ってどこのチャンネルの何でやりましたっけ みたいな 散らばったものをまず探し出して 繋ぎ合わせるみたいな作業を 結構QAとか途中でアサインされることとかも あるあるだと思うんですけど その時に結構まず情報の整理をして で何が課題でみたいなことを 結構やりがちだと思うんですけど 結構もうここを見れば 全部決まってて どういう決定がしたのかみたいな ログレベルで全部残ってるので 人間が途中で参画した時も 基本そこだけ見てねで 全部何でこれが変わったのか どう変わってったのかが Gitの差分とかも含めて見れるので それで人も理解度みたいな 解釈みたいなところは早かったみたいなのは あんま期待しなかったところだったんですけど そういうのも何かあったっていうのは 面白かったなと思いましたね 情報が集約されてってことですもんね 確かに確かに ですです ありがとうございます あと聞いてくださっている方向けに ぜひ質問とか何でも構いませんので コメントお便りをいただければと思います 遊びに来たようなコメントでも 構いませんので じゃあ次の話いきますかね はい 私がぜひお話を聞きたかったのが アプリのリリースを 週1だったのが週3になったみたいな お話がすごい驚愕的というか めっちゃやりたいみたいな そこらへんちょっと 状況とかこういうことやったとかを ぜひお聞きしたいです ありがとうございます まず自分もこれは 驚愕してるんですけど メンバーの皆さんが本当に素晴らしいなと思いながら 実績ベースで 結果としてそれがあったっていう感じで 初めからあんまり そこ目指しましょうってやってたっていう感じでは まず前提ないんですけど もともと自分もやっぱモバイルって 他のプラットフォームとの違いとしては センサーがあるっていうので どうしてもこっちのコントロールだけでは できないこともあるので 週1回にまとめたほうが結果的に コストとかバランス含めて 一番いいんじゃないかな 最速レベルなんじゃないかなっていうところで そこでやってたんですけど まず前提として もともとiOSとAndroidそれぞれで ニュートというプロダクトを ネイティブで書いてるっていうのがあったので そこの越境範囲は それぞれのモバイル単位での まず積み上げっていうことをやってたんですけど 他のエンジニアも含めて iOSとAndroidネイティブのエンジニアも ここ両方書けるようにしていきましょうっていうのを まず方向性としてやっていきましょうってことを やりましたと そうするとiOSとAndroidで どっちが先に出せるかとか 同じタイミングで必ずしも出すじゃなく できたものから出して 早く効果検証できたほうが 次のプラットフォーム列でどうしたほうがいいかが 分かるよねみたいな いいポイントあるんじゃないみたいなのが 一つ起動式としてあって その中で早く効果検証できるようにするために いくつかのハードル それこそ機能検証をどう早めていくのか リグレッションテストをどう回していくのか 審査だったりとかどう早めていくのかみたいな すごくざっくり分けていくと何箇所か ポイントになるところがあって そこを一個ずつどう高速化してあげていくのか みたいなことをブレイクダウンしながら やっていってるっていう感じですね すごくざっくりと言うと ありがとうございます 情報量が多くて そうですね すみません でもそうすると 機能検証と何でしたっけ 3つぐらい機能検証と 高速化する上でのケアしなきゃいけないポイントの 大枠の止まるポイントになるなというのが 1個が機能検証のレベルを上げないと 高速化のデグレが起きてますよみたいなのが 結局なると早く出せないので 1個1個の機能の単体テストを 質を上げていくっていうのが1個目と もう1個が東映その他で何が起きてるのか 完全にはもうらしきれないという中で デグレってちゃんとないのねっていうところの デグレッションテストを どう高速化していくのかっていうのが 2つ目のゲートベイとしてあって 最後審査っていうところを出すみたいな ワークフローとか承認プロセスですよね っていうところをどうやって 早くしていきますかみたいなのが 大玉QA目線でいうところの大玉は その3箇所があったんじゃないかなと思ってます 確かに確かに デグレッションテストのところ もうちょっと深掘りしたいんですけど E2Eとかで自動化を進めたとか そういう感じですか いろいろあるかなと思うんですけど まさにありがとうございます 1つは今おっしゃってたところですね E2Eを内製化というか もともとマジックボットかなとかを 使いながらやってたんですけど 開発が書いてそのまま書いたほうが いいんじゃないとか 機能テストをやったから 別にデグレッションテストではやらなくていいよね みたいな判断をしていくとか そういったところで どこで何を検証したかと言えるかみたいな 結構ワークフローを整理したっていうのは まず前提でありますね 今おっしゃってたデグレッションテストっていうのは 機能全体のというわけじゃなくて 案件の中での新機能テストと デグレッションテストというニュアンスですか それって言うと2つあって 機能の中でのデグレッションテストと あと全体のデグレッションテストもありますね 全体のデグレッションテストのほうも もう既に機能テストで確認してるから みたいな感じで省いたりしてるっていう感じなんですか クリティカルパスは基本的には通すんですけど 例えばアーキテクテルレベルで 今回ここって絶対いじってないですよねみたいな ニュートンのプロダクトでいうと 例えばツアーとホテルみたいな 大垣の軸で分かれてたりとかするので そこで今回ホテルのここしか触ってないなら ツアーってやる必要あるみたいな感じで マスターできるみたいなことはありますね 確かに確かに 自動テスト以外にもデグレッションテスト周りで こういうことやったとかっていうのはあるんですか もともとが結構デグレッションテストで カバーするみたいな結構 細部がんばるみたいなところが もともと結構あったところもあるんですけど 受け入れ条件というか どこで何を確認するのかっていう話と 本当に最終工程としてデグレッションテストで やらないといけないことってなりみたいな ボリュームをまず結構整理したっていうのは 大きいかなっていうところと もともとデグレッションテストが シナリオベースのテストケースの流れで 作っていたんですけど それじゃなくて単位をフューチャー単位 みたいなところで区切っていって それで不要な 明らかに影響範囲ではないよねっていう部分を パスできるシナリオの範囲を変えていくみたいな もともとのデグレッションテストの設計のあり方を 一部変えたりとかっていうところは それによって今までだったら 120件やらなきゃいけなかったけど 今回の影響範囲で言うと60件で十分ですよね それでも大丈夫って言えますよね みたいなのがある程度 できるような巧みに変えたみたいなところは 大きいかなと思います ありがとうございます AIで見た文脈で言うと どういうふうに活用とかされてるんですか それで言うと QAがというところではないかもしれないんですけど ベースのセルフQAというか 開発者自身のクオリティアシュランスのレベルを上げていく上で AIのナレッジを借りるみたいなところは 多分大きいなと思っていて どう最初のテスト観点を作っていくのか それは結局実装レベルにも反映されているので かなり上段のタイミングから 開発者自身がケアできるみたいな範囲だったりとかが 増えていったっていうのは 一個大きいかなと思っていて なので速度感とかリグレーションテストの回数とか 上げてるんですけど リグレーションテストでデグレが見つかるみたいな数とかも 一応トラッキングしてるんですけど 前期とかの方が何なら多かったかもなとかって思う感じなので 今の方がそこの前提 もっと前段でちゃんと不具合だったりとか その影響範囲を見極めておくみたいなところは なんかより強化できてる感覚はありますかね 確かに確かに そうですよね 使用決めたりとか受け入れ条件とか決めたりするタイミングで テストの観点とかみたいなのも そうですね 注入すると品質の作り込みみたいなところもできますので そうですね 今お話を伺ってって そういうアプローチというか今言ったみたいに 今私もその要件のレビューに入ったりとか あとは受け入れ条件をQAのメンバーが叩き台を作って これで合ってるよねみたいなのを チームの中で開発のスクラムとかの中で認識合わせるみたいなことも 今やってはいるんですけど 言ってるけどアプリは週1リリースなんだよな そこをどういう風に変えていったら もうちょっと頻度高く出せるのかな リリースの前の全体のリグレッションテスト機能の動作確認というところで 今Pujiだと丸々一営業日かけてやってるんですけど そこら辺って全然違うんですかもしかして状況が そうですねおっしゃるとおりですね もともとは弊社も一営業日リグレッションデイみたいな感じでやってたんですけど それだと出したいスピードに間に合ってないよねっていうところがあったので 今だとiOSとAndroidとWebアプリケーションあるんですけど 1プラットフォームに対して2から4時間以内に終わらせたいよねみたいなところで リグレッションテストでのカバー範囲みたいなのをギュッと その手動レベルですけど手動はそれぐらいで あとはE2Eとか他のところで担保みたいなところに寄せてる感じですね そうですね一営業日かかってるとなかなか週に複数回ってのはそもそも無理ですよね 確かに今AndroidとiOSを同じ日にやってはいるので iOSとAndroidを一緒に出さなくてもいいみたいなところが結構そうなのかって新しい発見だったんですけど ユーザー目線というか懸念とかないんですかね ちょっとそこの今の影響 結果的に今そこのカスタマー体験がどうなってるんだっけっていうのは ちゃんと定量訂正含めて確認した方がいいだろうなとは思っているんですけど ベースとしての弊社の利用OSの比率感で言うと 日本だと一般的なOSが多いっていうところで 結構それがさらに言うと顕著な状態になっているので iOSでしっかりAB含めて検証できたものを後からAndroidで出すみたいなことをしても そんなに気になるような状態にはそこまではならないような状態 利用者の層だったりとかみたいな含めるとあるのかなっていうので 体験が例えば違くてもあれこっちでできたよってできないよねっていうのは まだそんなに分かるような利用率でもないのかなっていうところはあるかもしれないですね 1個すごく今話してて違いだなと思ったことが Voicyさんのアプリケーションって毎日何度も接点を持つっていうことが すごくカスタマー価値とか大事なポイントだなというサービスだと思うんですけど 旅行って1日に何回も問い合わせしないんですよねアクセスとして なので次に来るタイミング旅行に行きたいなと思ったタイミングでの 体験がどうだったかっていうことのほうが結構でかくなるので そこのカスタマーとの接点の数とかっていうのが大きく違うみたいなところが もしかしてどんどん出して検証していこうよみたいなところとの サービス特性の違いとしてもあるのかもっていうのを 今話聞きながらちょっと思いましたね 確かにそうですね1日に3回ぐらいはアクセスしてほしいですよね 3回来た時に朝来た時と夜来た時に全然体験変わってるんだけどってなると 昨日まで使いやすかったのに何で変わったのみたいな 差分もすごく伝わってしまうっていう中でいうと 体験を変えていくっていうこと自体も結構慎重になるんじゃないかなと思うんですけど 弊社の場合はそこの次にアクセスするみたいな時が結構タイムラグとしてでかくなっているので そこの差分感みたいなところが伝わらない 逆に来た時にめっちゃ良くなってるじゃんっていう体験するために どんだけピリセル繰り返しといていいものにしておくかみたいな方が結構ポイントなのかなみたいな そこの違いちょっと今話聞いてて思いましたね 確かにありがとうございます そうか勝手にリリースの頻度ってめちゃくちゃ高い方がいいんじゃないかって思ってたんですけど サービスの特性 あると思います 微修正みたいなちょっと不具合修正みたいなアプリ直したらすぐ出せるようになるっていうのがすごくいいなと思うんですけど 確かにCoreの体験みたいなところはそうですね でもそれはどのタイミングで公開するかっていう話かなと思うので そうですねそれとアプリのリリース自体でいつでもというか週に3回とか複数回出せるようにするっていうのは もしかしたらちょっと違うかもしれないですね でもサービスの違いっていうのはすごく確かにいいと思いました 毎回その機能差分を出せっていうかで言うとぶっちゃけそんなこともなくて 本当あの不具合をとかこの文字だけちょっと変えてほしいみたいなレベルも含めて出してはいるので とにかくできた大丈夫だよねってものを出せる状態にしましょうみたいな方に一旦力をグッと寄せたっていう感じなので そのリリース頻度に応じてカスタマー価値が上がってるかで言うとまだそんなことはないかなとも正直は思いますね 確かに今ここまでのところの話を伺ってて毎週出してはいるんですけど 必ずしもその週に大きな回収が入らない時もあるじゃないですか その時も全部今あるリグレッションテスト基本回してるのでそこは改善の一部かもしれないですね 確かにそうですね リグレッションテストもリリースのために全く同じその修正ポイントじゃないと ここは今回リグレッションテストのスコープになるならないみたいななんか足し算引き算をしているんですけど 週に1回はその通しのテストをやってもし1個前のタイミングで見つけなくても1週間に1回を確認できるよねみたいな 常に同じ流度で同じことをやり続ければいいというのなくどこかでキャッチはできる 最低限とどこで何するみたいなところはチューニングしてるっていう感じには持ってますね いいですね確かに ありがとうございます あともう一個別のというか審査のところであんまり早くなるイメージはないんですけど そこはリリースのプロセスとかを何ですかね順番なのか早めに出しとこうねみたいなそういう感じなんですか そうですね例えばなんかストアの審査を早くするは祈りしかできないというか どうしてることも今で言うと弊社もやってはいないんですけど その前後にかかるその意識っていうか 今日ってこのタイミングにこれ本当に出していいのみたいな 今までだと週に1回だったのである程度PMがこういうこといらっしゃいますよね ストアに載せる画像を作りましたみたいなのがあるタイミングで発生するっていうことをやってたんですけど 今日出していいですかみたいなこと突然出てくるとえーみたいなことになってしまうので その出していい出しちゃダメな判断基準とか その本番に出すビルドをどんだけ早く作れるようにするかとか そういうなんか小さなことを早くするみたいなことをやりましたね ありがとうございます ちょっとなんか話ずれるかもしれないんですけど リリースの判断ってどういうロールの方がやってるんですか PMとか今ちょっとちらっと聞こえたなと思いつつ 最初はそうなんですけど なんかこう今出すプロジェクト軸みたいな軸があったら そこにEMが1人必ずEMとPMみたいな感じでついているので そこがこの日に出しますがどうできていれば一旦大丈夫だという中で OKっていう感じにしてますね 聞き方が私も良くなかったですけど 全体のそのリグレッションテスト回して最終的にこれでいいよねみたいな あーはいはいはいはいはいはいはいはいはい それで言うとリグレッションテスト自体はQAが出してるので 結果を例えば今回だとiOSだけ出しますみたいな時もあるので そうするとiOSのチームの人にその結果を伝えて でリグレッションテストで全部クリアだったので 本番ビルド出しますみたいなところだけ全体の周知して それEMとかPMとかみんな見てるのでOKみたいになったら パチッとできるっていう感じです 答えになってます? あってますあってます じゃあそこは一緒でした 違う部分とかあるのかなとか聞いてみたんですけど一緒でした プリリリースそうですね ちょっとなんかできそうなことがありそうだな また後で録音ちゃんと聞き直してちょっと考えてみます いやでもなんかこう今の話を自分も話をしながら 結果的にカスタマーの価値どれだけ上がってるのみたいなのが 本質だと改めて今話聞いてて思ってて 結局なんかできたよねっていうものを なるべく早く届けるっていう力学を一旦作りたかったので デプロイに制限を作らないとか モバイルのエンジニアだけ週に一回だから それ以上の速度を出そうとしないみたいなことが起きないように いつでも出せるから早くサイクルタイム早めようよみたいな っていうところも文脈含めてデプロイ頻度を上げていく みたいなことをしてたんですけど 結果的にそれでお客様にとって何が良かったのみたいなことは ちゃんと振り返らないといけないなっていうのを 今改めて思ったのでありがとうございますって思いました いいえそうですよね 見つかった不具合を直せる出せるようになったとかでも 全然効果は説明できそうですよね 確かにそうですね 眠ってた不具合とか確かにそれは頻度が上がって スッとちょっとこれも入れちゃいましたみたいなことは できるようになっているので それは確かにちょっとかもしれないですけど 確かに 確かにな ありがとうございます もう一個ぐらい別のネタいきたいんですけど 何がいいかな 何か話したいことあります? なんかそれこそ開発とか少し頑張ってるよみたいな話とか あえて言って言うと一興みたいな今回テーマだったと思うんですけど 私も話しながらすごくいいことだけを教育してたんですけど その影響することと ちゃんと評価するみたいなこととかを ちゃんとひも付けないとか しないと役割を設計するの難しいなと思ってたんですけど 頑張ってねっていうだけだと そういうチャレンジとかしづらいなと思ってて VCさんはそういう開発のこと挑戦してみたっていうことが できてるのはどういう仕組みとか構造なのか ベースのスタンスがすごくオーナーシップ高いんだとか っていうのも全然いいんですけど どうやって作れてるんだろうみたいなのは 純粋に気になりましたね そうですね 結構カルチャーとかもあるかもなと思うんですけど 開発チーム全体、組織全体として AIをちゃんと使っていきましょうねじゃないですけど AIを使いこなして業務を推進していきましょうっていうのが まずトップからというか やっていきましょうっていう方針がまず一個出たっていうところ あそこはMiiさんのところとかも近いかもしれないですけど 半期の目標っていうところでもきちんと一個入れる これまでが組織として整えてもらったところではあるんですけど じゃああとは何をやっていこうかっていうところで 私自身の目標というかだと AIを活用して客に価値を届けるみたいなのが 超ざっくりした抽象的な方向性が一個あるんですよ AIを使ってっていうところで その中で何が自分ができたら 顧客価値とか体験向上とかにつながっていくかなっていうときに考えた で出てきたのが一個が不害の修正だったっていう感じなんです なのでそれ以外にも今日お話ししたクロードスキルズみたいなところも そうですしより効率的にベストの業務が進むみたいなところが 結果的にスピーディーに機能を提供することができて トライアンドエラーできるよねっていう機能の検証とか サービス出したものを出した機能がどのくらい価値あったかみたいなところの検証のサイクルを早く回せるので 結果としてユーザーに価値を届けるとか 企業の価値というか価値検証を回せるっていうところ 早く回せるっていうところに貢献できるかなみたいなのは考えてやってきましたよね 大事ですね Qエンジニアとしての今お話しいただいたところの役割って 新しいわけではないけれども 本質の深いところをちゃんとどう体験していくのかみたいなところに 責務を果たそうとしているみたいなところはすごく深いなと思っていて その越境ともう一個進化っていう話を自分はしましたけど そこのどちらも網羅できるような形でのプロダクトとか 組織への貢献の仕方だなと思って そこはすごくいい話だなと今思っていてましたね 確かにそうですね 越境と進化と そうですね 越境の部分が不愛称制というかコーディングにチャレンジするっていうところですし 深める方の進化 テスト業務をどうもっと早くとか効果的にできるかってところですもんね そうですね それを一緒にいらっしゃるQエンの方とかも 開発だったりとかに挑戦してってことをやってらっしゃるので すごくそこの一部の人がやってるというか みんなでそこやろうよみたいなところができてるってところが 改めて素晴らしいなと思いましたね そうですね 今ボイシーマークが止めました ありがとうございます そうですよね そこは何ですかね 新しいこととかチャレンジしていこう まずやってみようっていうところは すごくカルチャーとしてありそうですよね うーん ですねですね なんかこう 皆さんもきっとそういうことやってみたいなと思っても 上手くやりきれなかったりとか どこでやったらいいんだろうみたいなこととかは やっぱ思いがちだと思うんじゃないかなと思ってて なんか皆さん他の方の環境とかっていうのは もちろん違うと思うんですけど なんかこういう一歩目踏み出せるといいよとか こう考えるといいんじゃないみたいなポイントとか ヒントになることとかってありますか どうなんだろうな なんかそうねやっぱ お昼にミサもおっしゃってたんですけど 中期的にやっぱりすごい大事なことだと思っていて なのでその短期的には時間がかかってしまうから もしれないけれど 効果があるはずだと信じて 一歩進むみたいなのは結構あるのかな なんか今回初めてボイシーで プログラムの修正をして出した モバイル両方アンドロイドタウンス出したんですけど その時にやって 副次的にやってよかったなっていうのが コーディングをしてから デプロイというか ビルドとかビルドとかして 世に出るまでの一連の流れを 初めて自分で体感したんですよね それまではなんかなんとなくしか そのプロセスを知らなくって そこがすごく解像度が上がったので 特になんだろうな ビルドするとかのところって リグレッションテストの責任者というか っていう意味だと 実はちゃんと知ってなきゃいけなかった 詳細のプロセスとか どのくらい時間かかってるのかみたいな そこが自分の実際にやれるようになったというか 解像度上がったことで さらにリグレッションテストを スムーズにやっていくために 今後のその改善に絶対 生かせるなと思ったんですよね 確かに そこはすごくやってよかったなと思って そういうまさに越境の部分で 見えてなかった部分が見えるようになったら 絶対よりスムーズに いくはずなんですよね めっちゃいい話 本当にそうだわ そこにちょっと工数をかける そんなにいっぱいは確かに かけられないかもしれないんですけど 別にそこは1割って決めてもいいかもしれないし 1週間のうちに 確かに そういう意味で言うと 1週間のうちに何時間まで使うか っていうのは決めてましたね なるほど 再現はないですもんね 取り過ぎないように 基本的には作業は1時間とか2時間とか 誰かのミーティングしてもらう時間を取ってもらうのは 1週間 毎週30分までっていうのを 自分の中では決めてました 素晴らしい いい話だな ちょっとQAの話から 逸れてしまうかもしれないんですけど 今は前者の部分関係なく 本当に前者のAIDテラシを上げるっていうことを 今自分やってるんですけど スキルを渡しただけでも 別に活用には どの技術もそうだと思うんですけど Howを分かってても どのタイミングでそれを取り出したりとか すればいいのか分かってないと ちゃんと活用しきるっていうことが 難しいっていうのがあるなと思ってて 自分この前期に コーポレートの部門のマネージャーをやっていて そのタイミングで 今前者の部門がどういうことをやってるのかって 全部眺めて メンバーが何いて 誰が得意で何がすごくて みたいなことが なんとなく頭の中に入っていて それでこの業務に対しては 何がやればいいんだっけみたいなことを 自分も引き出せるっていうことが 一個できていいなと思ってて 今自分はコーポレートやった時に 何で今このタイミングで私やるんだろうみたいな ぶっちゃけ思ってたところもあったんですけど 今思うと さっきの話と共感というか 共感力というか これってどうしてそうなってるのかを 理解してるからできることみたいなのって 巡ると繋がっていくじゃないですけど って思うと これって今目の前で開発を 私がやらない方がいいかもしれないけど それってここに繋がってるんだよね みたいなところが ちゃんと巡ってくるタイミングが 来るよなと思うと それは組織にとってもハッピーなことだし あいつのことを理解できる人が 人でも増えてるっていう状態自体は すごい組織的にも嬉しいことだなと思ったんで ちょっとずつ染み出していくみたいなのは 具体的なのでは定量的にどうなのよとかって 言われがちですけど そうじゃない部分でのいい話って すごくいっぱいあるんだろうなっていうのを 今話聞いてて思ったし 自分もそれを体験してるなっていうのを 思い出せましたっていう感じでしたね ありがとうございます そうですよね なんか業務で全部繋がってるので いろいろ 本当に開発の流れにしても そこを思いやれるために やっぱり知らなきゃいけなくて 知るために その影響をするというか チャレンジしてみるっていうのは すごく大事だなというふうに思いますね 大事ですね 本当に なんかやらされてるなって思ってるところから なんでやってるのか 自分がやることによって そういうことなのねって理解して 協力的になれるとか なんかすごいそういう 思いやりの話も今出てましたけど 相手の理解できることって やっぱ機条とは違って 経験からしか得られるものとかも やっぱあるなと思うので そういうのすごくいい話だし そういうのは当たり前になってる ボイシーさんの環境 すごく優しそうな環境なんだろうなって 勝手に想像しましたね 確かにみんな優しい 今お便りをいただきました 読み上げたいと思います やらない後悔よりやる後悔を取るっていうマインドも 手を動かす動機としてあるのかなと 話を聞いてて思いました いい感じ 確かに 確かに やってみたら それがたとえうまく思ったり うまくいかなくても 学びになるので やってみることって めちゃくちゃ大事ですよね いや 本当にそうですね やってみる 大事ですね やってみないと分かんないこと多いですね 確かに この間EMのイベントに出た時も どうやったらこういう 越境できるようなメンバーとか 一歩目を応援できますか? みたいな質問があった時に その時は答えられなかったんですけど 初めて挑戦するものに対しては 正解じゃなくてプロセスで評価してみてはどうですか? みたいな話を 自分話したんですけど やってみてダメだったのやったと それでもう次の挑戦を 止めてしまうかもしれないなって 思ってるので とりあえず新しいチャレンジのものに対しては やったということを そもそも評価するみたいな それがあると やってみてダメだった じゃあ次それを仮定にして何するか みたいなことを 考えにつながるかなって 思ったんで 手を動かしてみるって とりあえずやってみるって めっちゃいい話だなと 今またこのコメントを見て思いました ありがとうございます ちょっと全然違う話をしたいんですけど もちろんね おまけの話というか あのー あ、なんで えっと みーさんが ちょっとこう 音声発信とか 興味あるとかないとかって はいはいはい お耳に挟みまして はいはいはい なんかどうですかっていう どうですかってないですけど あのー 今日生放送とか そうですよね 仮定見てとか はい まずさみーさんが すごい いかにすごいかってこと 私は 今日ずっと体験してる っていう感じ ありましたっけそんな あります すごいこと なんかあの 今日のお昼のイベントからも 思ってたんですけど 私最近 イベントの登壇は まあまあするんですけど その オフラインでの登壇が 結構増えていて なんかその 目の前の人の反応で 何を話していくのか みたいなことを 結構こう してたなと思った時に こう 相手が見えない中で ちゃんとこう 聞きたいものを 届けていくみたいなことの 難しさとか どう自分の話してることが 伝わってるのかが見えない 不安感とか すごいあるんですけど さみーさんは そこがすごく 今 相手こういう風に思ってるから こういうこと 今入れた方がいいなとか っていうのなんか されてて こんなに器用なことは 私にはできないかもしれないな っていう ちょっとそっちの方が 強くなっちゃう なんかありましたっけ 全然思わなかった ありましたよね しぶしから 私は感じていますし 今この時間をすごく すごい ファシリしていただいて ありがたいなと思ってます ありがとうございます なんか そうぜひ ぜひ あの ドイツでも チャンネル作ってもらったら もらえたら 嬉しいなって思い 私自身も思ってますし なんかみーさんのその 日々考えてること のなんか脳内垂れ流しとか でも全然いいと思ってます だから ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ ぜひ # 次回予告 いかがでしたでしょうか。 みーさんとはですね、結構いろんな共通点もあったりしましてですね、 旧エンジニアからエンジニアリングマネージャーにチャレンジしたりみたいなところもそうですし、 それ以外のモバイルアプリを今作っている、モバイルアプリのあるプロダクトに関わっているとか、 通信向けだったりとかも結構共通点もいろいろあるのかなーなんて思っておりまして、 また、そのうちゲストでお呼びできたら嬉しいなというふうに思いますし、 チャンネル開設がされたらめちゃくちゃ嬉しいなというふうに思っております。 はい、ということで今回も最後までお聞きいただきありがとうございました。 次回の放送は品質特性のクイズになります。 品質特性も実は残りあと2つになりまして、 明日は保守性って何?ということで保守性に関するクイズを出します。 今回の放送を聞いて、なるほどな、確かにな、学びになったな、 そしてぜひみーさんにチャンネル開設してほしいぞという方は、 ぜひぜひハートマークでいいねを押していただけると、とっても励みになります。 またですね、次回のゲストトークのゲストが決まりましたので発表です。 次回のゲストは森崎先生です。パチパチパチパチ。 1月19日月曜日の夜8時から9時でボイシ生放送対談をします。 テーマは論文の読み方とか選び方です。 ぜひぜひ予定を押さえていただければと思います。 それではまた明日お会いしましょう。ごきげんよう。