# タイトルコール テスティングジャーニーへようこそ。 本チャンネルでは、ソフトウェアテストの世界を探索するコンセプトに、 エンジニアリングマネージャー兼QAリーダーのさみぃが、 ソフトウェアテストのコツや品相性の奥深さ、そして意味考えていることをお話しします。 # 最近Claudeでよくやること3種類 こんにちは、さみぃです。 三連休、いかがお過ごしでしたでしょうか。 私はですね、この三連休とか連休の前からすごい大移動をしておりまして、 東京の出張行って、京都経由で奈良に行って、 で、また今度新大阪から広島行って、 で、昨日一泊ですから、広島一泊旅行をして帰ってきました。 広島もめっちゃ暑くてですね、 まあなんかこういうとこ行ったよとか何食べたよっていうのは昨日の放送でしているんですけれど、 昨日の夜帰ってきたらもうなんか腕とか足とかがすごい日焼けでですね、 体の内側からポポポポと熱がこもってしまって暑かったです。 今週も頑張っていきましょうということで、 今日はフェイブル5を使ってみてというトークテーマでお話をしてみようと思います。 フェイブル使いましたか?使っていますか? 私も仕事で毎日使わせてもらいましてですね、 まあなかなかめてこう振り返って今いるんですけれど、 何やったかなーっていうのを今日ツラツラお話ししていこうと思っております。 ざっくり分類すると、3つくらいになりそうですかね。 分析系はよくやってもらったのと、 あとコーディング系と文章とかスライドとかを作ってもらう系かな。 大体この3つが多かったように思います。 1つ目から話していくんですけど、分析系ですね。 仕事において、業務において判断することってたくさんあると思うんですけれど、 判断するためには情報が必要ですよね。 なので、情報をいろんな切り口で分析をしてもらう。 分析って言うと、そこから見えるものは何かっていうところまで入ってしまうので、 正確に言うと集計かな。データの集計。 こういう切り口で集計してほしいとか、こういうことを判断したいので、 こういうデータを分析してくださいみたいに言うと、 データの集計結果と、このデータから言えることはこういうことですよっていう分析の結果も出してくれますよね。 私はよく集計結果と分析結果はコンフルエンスにまとめてくださいって言って、 コンフルのページまでそのまま作成してもらったりとか、 そこから出てきた施策というか企画。 今回こういう課題があります。データを見るとここにこうあるからこういう課題があります。 なので今回こういう施策を打とうと思ってます。1,2,3,4,5ってあって、 その施策からさらにブレイクダウンしてトゥードリストまで作ってもらって、 そのトゥードリストを今度JIRAに寄付をしてもらうっていうところもやってもらってました。 そうするとというか、JIRAのこのエピック指定して、 ここにブラザール形でこの配下にタスクとして記表してくださいって言うと、 タスクと必要に応じてサブタスクもあったっけな、 タスクと説明文とかも一緒に全部書いてくれるので、 これまでだと自分で転記してた部分もあるんですけれど、 タスクの名前だけ書いちゃって説明欄が薄くって何やろうと思ったか分からなくなってたみたいなパターンもあったと思うんですけれど、 そこまでのコンテキストというか、こういう分析をして調査をしてこうだったからっていうものも含めて、 一緒に記表というか説明欄に書いてくれたりするので、それはプチ楽でしたね。 で、二つ目がコーディング系ですね。 最近だと、最近始めた新しい業務の効率化、特にAIを活用して効率化をするっていうところが一つ、 プチ目標、プチじゃないですけど目標としてあったりもするので、 MCPであってるのかな、クロードのスキルとかめちゃくちゃ作ってたりするんですよね。 そのスキルも自分だけ使えたり、あと編集できたりっていうところだと使い勝手が悪いので、 GitHub上で管理をしています。スキルの中身というかね。 なのでGitHubにプッシュしたりとか、レビューしてもらったりとか、 モロモロをマンジしたりとかっていう作業が必要なんですけれども、 全部クロード上から指示をして、コワークですね。 クロードのコワークから指示をして、全部今作業が完結するようになってますね。 スキル化するときも、インプットはいろんなインプットがやってきて、 それに対してある程度やしなり解釈をしながら作業、何かのタスクを行って、 最終的にアウトプットするということなので、 どういうロジックでインプットを判断して作業を行うのかっていうところは、 あまり適当にやっちゃいけないと言いますか、ある程度考えなきゃいけない部分もあったりする。 どういうロジックでやったら良いのか、自分のやりたいことが実現できるのかっていうところの 判断が必要になってくるので、周りの開発者に相談をしたりとか、 私はこういうことがやりたいんだけど、今スキルこういう内容になっていて、 もっと他に良い方法ないかとか、これで良さそうかとか、 何かセキュリティ的な問題ないかみたいなところとかも相談しながらスキルを作っていったりしてますね。 特に今、前デスクと連携させていろいろ作業の効率化というかを進めてたりもするので、 前デスクには顧客の情報もありますし、 ちゃんとマスキングをしてスラックに投稿してねみたいなこともやってたりしますし、 うっかりクロードがユーザーへ直接返信とかしてしまってほしくないので、今の段階では。 なのでちゃんとライトユーザーという返信はできない、 メモ、社内メモしか投稿できないアカウントもあったりするので、 そういうアカウントを使えばセキュリティ的にはというか間違ってユーザーに返答してしまうリスクもないよねみたいな、 そんなことも考えながらロジックを組んでたりします。 最後3つ目がテキストとかスライドとかを精々よくしてもらっているというところなんですけれど、 例えば登壇の資料とかかな、 アガイブ登壇も資料のところではなくてプロポーザルを作るところからクロードに一緒に話し合ってというか、 プロポーザルの構成案とか、 自分の方で今回こういうことを話したいんだけれど、 どういう風な構成がいいかなとかどういうタイトルがいいかなみたいなところから一緒に考えてですね、 プロポーザルの叩き台というか構成とかプロポーザルの内容自体を作ってもらう。 自分でもっと違和感あるところが絶対出てくるので、 そこはフィードバックをしてもっとこうしたいとか、 ここの文章はここを直してくださいみたいな感じでプロポーザーの内容を作ります。 今度採択いただいたらこのプロポーザーの内容からスライドの構成案を作ります。 その構成案で違和感とかがあればとか、 あるいはそのままスライドに出力してもらっちゃうこともあるんですけれど、 出てきた後ぶっと見て、 ここは自分の言いたいことじゃないとか、 私もっと言いたいところはここだみたいな違和感が出てくるので、 それをフィードバックしてスライドを作ってとか、 最後の方はAIっぽくないようにしたいんだよねみたいな話をして、 だったら本当はこういうのがいいですよとか、 こういう風な形式にしたらAIっぽくないですよっていうのも教えてくれたりするので、 そうやって手直しをしてスライドを作ったりもしましたし、 あとはクロードでいろいろ調べたりして出てきたもの、 その情報をベースにこの情報を誰々さんに伝えたいんだけどとか、 この誰々さんにこの企画を提案したいんだけどみたいなことを言うと、 それでスラックで提案してるので文面作ってって言うと文面作ってくれるので、 そこからちょっと違和感のあるところだけを修正して、 そのまま〇〇さんって苗字で言っちゃってるけど、 私はいつもあだ名で呼んでるから、 そこの名前を変えたりとかも含めてですけど、 細かいところをちょちょっと直して、スラックにベースとして何か情報を共有したりとか、 それこそ作ったスキルを入れて欲しい人には共有しなきゃいけないので、 プラグインとかスキルの使い方、セットアップの仕方とか使い方みたいなものを手順をまとめてもらって、 スラックで共有したりとか。 あとはその分析で行った結果ですよね。 試作こういうことをやりたいなっていうものが出来上がったら、 そう思ってこの出来上がったものというか、 今回のこの試作をだいだいさんに、冗長とかに提案したいので文章を作ってください。 なぜ必要なのかとか目的と、あと何で今で必要なのかみたいな、 そんな内容をテキストでも簡単に伝えたいですみたいなことを言うと、 それまで苦労が分析とか企画の文章というのも全部作ってくれているので、 その中から判断して、この辺伝えたらいいだろうというものをうまくまとめてテキストに起こしてくれるので、 それまで自分で考えていたなって思うんですよね。 何で必要なのかとか何で今なのかみたいなところも全部自分でテキストで考えていたけど、 提案してもらえるようになったので、すごく楽になった部分はたくさんあるなと思います。 # #579のコメント返し🥰 コメント返しのコーナーです。今回は579話目。 シンプリシティとは?のコメントを開始します。 コメントは、Kouheiさん、Mizukenさん、Wonder Heavenさんからいただいております。 いつもありがとうございます。 1人目、Kouheiさんです。 こんにちは。特にミーティングのコストを計算するというところが響きました。 私も結構、これにないなと思うミーティングはガンガン辞退しちゃいますね。 それで、あんまり困ったこともないので、これからコストを意識していきます。 ということで、ありがとうございます。 確かに、意味ないと思うミーティングは、本当に自分が出る必要があるのかとか、 このミーティングの目的は何ですか?というのを最初に確認したりとか、 あるいは、事前に確認したりすることもありますけれど、 ぜひ、コスト、意識、どのくらいこのミーティングにかかっているかというのを計算してみると、 ミーティングに対する意識というか、準備というのも変わってくるんじゃないかな、 なんて思っております。ありがとうございます。 2人目、Mizukenさんです。 無駄なミーティングがあったり、ミーティングに不要意に人を集めすぎたりってありますね。 そもそも、組織とかチームの役割が曖昧だったり、ミーティングの目的が曖昧だったり、 いろんな要因がありそう。 逆に、ミーティングしないといけないのにやらずに、 コミュニケーションロスを起こしていたりもしないように気を付けないと、とも思います。 ということで、ありがとうございます。 確かにね。ミーティングやらなくて大丈夫かなと思ったけど、 結果振り返ってみると、あの時ちゃんとやっとけばよかった、 テレビミーティングを組んで関係者を集めてやっとけばよかった、 なんてこともあったりしますよね。 組織も生き物だな、なんて思っているので、 その時々によってチームの役割とかも、カバー範囲とかも結構変わっていくので、 その中で今回のミーティング誰まで呼んだらいいんだっけ、 誰まで巻き込んだらいいんだっけっていうのは、悩む時は悩みながら私も日々仕事をしております。 ありがとうございます。 そして最後、ワンダイレブンさんです。 今日もいいねの絵文字ありがとうございます。 以上、コメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございます。 明日もですね、Voicyのトークテーマ 人に頼ることの大切さについてお話をしていきます。 どうですか?人に頼るのは得意ですか不得意ですか? 結構ね、人によってキャラクターというか 得意な人はすごく得意だし 苦手な人はすごく苦手な印象を持っているんですけれど 私はどうだろうな、多分おそらく人に お願いするとか頼るとか頼むっていうのは どちらかというと得意な方なんじゃないかなと思っておりますので どんなことを考えてお願いか頼っているのかな というお話をしていこうと思います。 今回の放送が役に立った 今日もきちんに来たようなやつで ハートマーク、いいね押していただけますと とっても励みになります。 ぜひぜひコメントもお待ちしております。 あなたのコメントは私の学びになります。 それではまた明日お会いしましょう。 ごきげんよう。