$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

#RSGT2026 に参加し、いろんな人から刺激をもらってきた

ブログを書くまでがカンファレンスということで、RSGT2026に参加しました記事です。

今回参加したのは、「開発フロー改善がうまくいって知見も溜まったし、どこかで発表したいな」と思った時にたまたまRSGT2026のプロポーザル応募をしているのを見て、勢いでプロポーザル応募したのがきっかけ。結果的にプロポーザルも通り、初参加 & QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化するという発表をしてきた。

初参加で、しかもこれまでスクラムやアジャイル系のイベントにはほぼ参加したことがなかったため、ほとんど知り合いがいないという状況だった。けれど今回の機会で色んな人と廊下や懇親会で話せて、興味深い議論をしたり知り合いを増やせたりしたなと思う。

セッションもレベルが高いものばかりで、特に以下の2つのセッションが参考になった。両方とも深い知見であると同時に、会社でまず一歩目を踏み出せそうな内容だった。

このような貴重な機会を作ってもらい、スタッフの皆さんありがとうございました。また来年も発表のネタを作って登壇できたらなと思います。

スピーカーディナー

知り合い全然いない!という状況でオロオロしていた。そんな中Bayashiさんが「ブログ見てます」と話しかけてくれて、さらには二次会にも連れていってもらえたのがとてもありがたかったです。

スポンサートークで市谷さんを初めて見て驚いた。昔「正しいものを正しくつくる」という本に感銘を受けていたので、参考になりましたと挨拶に行きたかったが、機会を作ることができず。また別の機会があれば話しかけにいきたい。

その場ではセッションなどには中々出にくいスタートアップ大変話が聞けて良かった。みんな大変なんだな〜と思いつつ、自分も大変な中頑張っていきたい。

An introduction to Beyond Budgeting – Business agility in practice

脱予算経営の話。僕自身は脱予算経営のことを全く知らなかったので勉強になった。このフレームワークを全部適用するのは難しすぎるんじゃない?と思いつつ、いくつかの考え方は使えそうだなと思った。

  • 予算はないが何に使ったかは透明になっている
    • 気づき: 透明性が異常な支出を抑えるという考え方が面白い
  • 誰かが違反するのは絶対起こる。連帯責任にはしない、その人に対して厳しい対応をする。
    • 気づき: これはルールを作る話にも似てる。失敗したからすぐに標準化したルールを作るとどんどん締め付けが強まる

懇親会で脱予算経営の話がいくつか出たが、全てをやろうとするのは逆に難易度を上げてるだけでは?という意見も出てきて面白かった。いくつかの会社では、予算の透明化&申請自体はノールックで承認ということをやっている会社があったのも興味深い。

「予算は最初に貰う的に妥当性をある程度判断するものである」と自分の中で固定観念があることに気づけた。

「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない

speakerdeck.com

アウトプット脳になりやすい職能をユーザー価値脳へ意識変革するのは難しいため、アウトプット脳のチームとユーザー価値脳のチームに橋をかけようという話が良い。以下三つを行うことで橋をかけられる。

    1. 実験の設計
    2. 安全な小さな実験から価値検証を始める
    1. 会話の設計
    2. 話す順番から会話をデザインする
    1. KPIの設計
    2. 評価指標から「仮説の集合」への再定義

発表中や発表の後にも質問させてもらったが、一気にやるのが難しかったら(1)からやれば良いとしつつ、(3)ができないと説明が難しくて辛くなるという話を聞いて、めっちゃ納得してしまった。

「私の要求最優先!あなた後回し」そんな対立を超えてビジネス、開発、顧客が本当に欲しかったものを全両立するプロダクト組織の作り方

speakerdeck.com

トレードオフを詳しく理解して、その理解を通して解決方法のパターンを知れる発表だった。発表中だけでは理解し切ることが難しく、次の日の朝に発表資料をもう一度読んで頭の中を整理していた。

「本当は〜したいが、仕方なく〜している」と思う時はあったが、その時にトレードオフ構造を図にして解決方法を探るという手法を使えてなかったなと気づいた。システム思考も関係しそうだし、もっと深く勉強して問題解決のアイテムとして身につけておきたいなと思った。

Day2でmoriyuyaさんに「トレードオフについて話しかけにいってもいいですか?」とXでメンションしたところ、快くOKしてもらい話すことができた。なんとコーチーズクリニックの場所に連れていってもらい、その場で1時間ほどノートに状況を書いてもらいながら会社の状況の整理をしてもらえた。とても頭が整理されたし、その時に得たものを一つずつでも実施していきたい。ありがとうございます🙏

自己管理型チームの一員となるためのセルフマネジメント:モチベーション編

speakerdeck.com

行動を阻害するフリクションの種類とそれぞれの対応方法についての説明が、僕の中では一番参考になった。以下のように言葉にすることで、ざっくりとした認識をカテゴライズして次に進むときの指針にできそうだった。

  • 物理的フリクション
    • 作業のステップ数が多いなど物理的な手間
  • 認知的フリクション
    • 頻繁な通知により断続的に集中が途切れるなど認知的負荷
  • 心理的フリクション
    • 不安感や抵抗感により動けない状況

また発表の進め方として、モチベーションの源泉や身の回りのフリクションについて、それぞれ2分ずつ周りの人と話すという時間があったのは良い。発表を聞くだけだと自分の経験と紐づけることができず結果的に内容を落とし込めないことが多い。しかしこの時間があったことで一種の「経験」となり、その後の発表の内容を落とし込めるようになった。

ABC理論の話に繋がるのも面白い。最初ABC理論と聞いたとき、「聞いたことない理論だな?」と思ったが、よく聞くと昔自分の勉強した認知行動療法の話だと気づいた。認知行動療法、自分の感情を理解するのにすごく良いよね。

ちなみに僕は自分の気持ちが落ち込んだ時は「ファイブコラム」という手法を使っている。これは出来事に対して以下の順で言語化することで、自分の解釈のバイアスの矯正も行う手法。「それ以外の可能性のある考え方」を考えることで、自分のバイアスを見つけられるのが良い。

  • 気分が落ち込んだ出来事
  • その時に起こった感情と強さ
  • その時心を占めた考え
  • それ以外の可能性のある考え方
  • 感情の変化と強さ

QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する

speakerdeck.com

自分の発表。#RSGT2026 で「QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する」という発表をしましたの記事に伝えたいことは書いたので、興味がある人がいたら見てもらえれば。

AI時代のアジャイルチームを目指して - "スクラム"というコンフォートゾーンからの脱却-

speakerdeck.com

AI時代だからこそ、チームで扱う変数を増やし、組織とチームの境目を積極的に溶かすという部分が良い。自分が無意識に定数にしてしまっているところを意識しないとなと思った。

懇親会でおよべさんに「モブプログラミングをしている時にAIからの返答待ちの時間は何をしてるんですか?」と聞いたところ

  • 「プログラミング」をしているわけではなくて、「仕事」を一緒にしている
  • 普段はAIの返答待ちの間に、別の仕事=Slackへの返信だったりその他だったりをしているわけで、そこも含めてモブでやる
  • そうすることで、仕事全体を学ぶという学習効果も生まれるよね

と話していた。こちらも自分の中で「モブプログラミングはプログラミングを一緒にする」という固定観念を持っていたんだなと意識できて良かった。

AI駆動開発の時代〜小さなチームで世界を変えよう〜

発表を見ていての一番の感想は「AI時代に改めてエンジニアリングを楽しんでいるんだなあ」ということ。僕は楽しんでいるクリエイターが好きなので、そういう意味で良い発表だった。

AI時代だからこそビジネス方面にもどんどん出ていくチャンスだなと思うので、逃げずにやっていきたい。

最後に

今回の4日間で非常に刺激をもらえた。ここで得たものを現実を見据えながら一歩ずつ実践していきたい。

#RSGT2026 で「QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する」という発表をしました

RSGT2026に参加して発表してきました。スクラム系のイベント初参加・初発表・かなり大きなホールでの発表ということで緊張した〜。

発表資料はこちら。QAフローの最適化とタイトルに入っていますが、QAチームの立場からというより、開発チームのソフトウェアエンジニアの立場から開発フローを改善していく話です。

speakerdeck.com

資料を作っていて、「うーん自分は結局この発表で何が伝えたいんだろう?」と迷っていたのですが、作っていく中で言語化できたように思います。それは今回のフロー変更がうまくいったのは2つの成功要因があり、さらにこの成功要因はQAだけでなく開発フロー改善全体に言えることだなということです。

簡単にこの部分で話したことを要約するとこんな感じ。

  • QAフローや開発フローの改善をするとき、最初からフロー設計をするのではなく、必ず事業やサービス理解から始める方が良い
    • よくある罠として、QAでどんな障害・バグも防ぎたいとなり、どんどんQAコストが膨らみ、その結果開発〜リリースまでのリードタイムが伸び、アジリティの高い開発が徐々に失われてしまう
    • そうならないように、「何は絶対に守りたいか」を先に明確にする。絶対に守りたいことを言語化すれば、障害などの問題が起きても、今後QAで継続的に確認すべきかを考慮できる
    • 絶対に守りたいことは、事業やサービスのコア価値にあり、それはサービス紹介資料・営業資料・PMの頭の中などに存在する。先にその内容を理解すれば、満たしたい品質水準を達成しながらコスパの良いQAを設計できる
  • 開発フローの改善を設計する前に、必ず開発フローの中で変更しやすい・変更しにくい部分の理解から始める方が良い
    • よくある罠として、開発フローで大きな課題を感じ、理想のフローの設計を始めてしまう
    • しかし事業の特性などで開発フローには制約がある。さらにこれまでの歴史的経緯などの理由で開発フローには慣性が生じている。そのため変更しにくい部分を無理に変更しようとしても反発が起きる
    • 反発が起きると変更自体は良い方向に向かうはずなのに、「全ての変更が失敗であった」となってしまい、何も変えられずに終わってしまうケースが多い
    • そのため、先に変更しやすい・変更しにくい部分を理解しておき、その情報を改善設計に組み込むことで、スムーズに変更を進められる

このような発表をしたので、もし興味が湧いたらぜひ資料も見てもらえればなと思います!

発表概要

QAフローが大変で開発したもののリリースに時間がかかってしまうという悩みはありませんか?

クラスター株式会社では障害を最小に抑えるため厚いQAフローを運用していました。このフローによってサービスの可用性品質は非常に高い一方で、開発を終えたものをリリースするまで最低でも12日かかるという課題がありました。

ソフトウェアエンジニアの立場からこの課題を解決するため、障害数をコントロールした上でリリースまでの期間を最短化する方法を模索・提案し、改善を進めました。具体的に次のことを一つずつ進めました。

  • 事業の特性を理解して達成したい品質基準を決める
  • 開発フローの制約条件を理解する
  • 達成したい品質条件や制約条件を満たすように、QAフローおよびその周辺の開発フローを再検討する
  • QAメンバーと一緒に、QAのregressionテストのテストケースや、テストすべき内容を決め直す
  • 決定した理想系に向けて移行計画を作る
  • 3ヶ月かけて、理想系まで移行する

改善の結果、以前は開発終了からリリースまで12日必要だったものが、今は最短で6日ほどでリリースできるようになりました。さらに新しいフローになった後も顕著な障害増加はなく、可用性品質をコントロールできている状況を作り出せました。

本セッションでは、私がQAフローの運用の最適化を行なった具体的な経験を紹介し、QAフローを最適化する時、もしくはQAフローを新しく始めたい時に何が大切かをお伝えします。

生成AI「戦力化」の教科書を読んだ

社内でAI活用を推進するにあたって、どのようなコツがあるかの知識を付けたいと思い、生成AI「戦力化」の教科書を読んだ。

この本は、LLMを自社業務に組み込むための実践的な方法論がまとまっていた。ナレッジベースの構築、転記・抽出、文書作成、レビューといった具体的な業務への適用方法が整理されていて参考になった。

印象に残ったのは以下のポイント。

  • LLMの仕事は常にレビューするべき。そのためLLMに任せるべきかの軸として、ワークフローの入力と出力を人が正解かどうかを判断しやすいかという視点も大切
  • ナレッジベース構築をするための具体的なステップが解説されていたのが良かった。特に(5)のステップは大事だなと思う
    • (1) そもそもナレッジベースをどのようなアウトカムに繋げたいのかから考える
    • (2) 目的にあった文書・情報をリストアップ
    • (3) ベテラン社員がこれらの文書をどのように探し、活用しているかを分析
    • (4) 文書のどこに必要な情報があるのか、その情報から何を得ようとしているのかに着目し、抽出方法などの参考に
    • (5) システムを組む前にどのようなプロンプトで活用するのか検証。この検証段階ではナレッジベースを構築する前に、手動で関連文書を選び、それをプロンプトに含めて応答を確認する
    • (6) プロンプトでの活用イメージがつかめたら、あとはそのプロンプトに必要なデータが検索できるよう、情報を集約する仕組みを考える
  • 転記・抽出、文書作成、レビューそれぞれのワークフロー構築のコツが整理されていて参考になった

AI活用をより社内に広げたい人にとって参考になる本だと思う。そのような人におすすめ。

読書ノート

- マニュアル不足で回答が見つからなかった場合、マニュアルが見つからなかったと明確に返答するように工夫した方が良い 54
- LLMの出力は下書きと考え、最後は人がレビューする必要がある。下書きとして業務フローに加えるだけでも相当な効率化につながるケースが多く見つかる 58
- 洗い出された業務プロセスをもとに、ホワイトボードにどのようなステップの組み合わせになっているか書き出す。ステップごとにそれぞれ何の入力・出力があるかを明確にする。するとそれを生み出すための方法を検討できる 96
- LLMの仕事は常にレビューするべきなので、入力と出力を見た時、人が正解かどうかを判断しやすいかという視点もLLMに任せるべきかの軸に大切 100
- 非構造化データをうまく扱うには、(1)言葉で検索すること、(2)メタデータを付与して整理することの2つが必要 111
    - メタデータは一般的な分類よりも、企業特有のメタデータを付与することが重要
- データレイク、データウェアハウス、データマート、データカタログ 113
    - 非構造化データに応用すると、データレイクとして全ての文書を保存し、データウェアハウスとして業務目的別に整理・加工し、目的に応じたサブセットとなるデータマートに該当するナレッジベースを作り、データカタログでそれらを検索・発見できるようにする、などの構造
- 情報の関連性をグラフと呼ばれる構造で表現し活用可能にしたナレッジグラフを使うと、LLMは単にチャンクを検索するだけでなく、そこから関連する必要なチャンクをうまく見つけられるようになる 119
- ナレッジベース構築と活用をするときの流れ 126
    - (1) そもそもナレッジベースをどのようなアウトカムに繋げたいのかから考える。どのような場面で何を達成するために用意するのか
    - (2) 目的にあった文書・情報をリストアップする。情報がいつ追加・更新・削除されるかのライフサイクルを知ってナレッジベースを常に有効な状態に保つための背景を知っておく
    - (3) ベテラン社員がこれらの文書をどのように探し、活用しているかを分析。このプロセスはナレッジベース設計にもそのまま反映できる
    - (4) 文書のどこに必要な情報があるのか、その情報から何を得ようとしているのかに着目。抽出方法などの参考になる
    - (5) システムを組む前にどのようなプロンプトで活用するのか検証。この検証段階ではナレッジベースを構築する前に、手動で関連文書を選び、それをプロンプトに含めて応答を確認する
    - (6) プロンプトでの活用イメージがつかめたら、あとはそのプロンプトに必要なデータが検索できるよう、情報を集約する仕組みを考える。どこから情報を持ってくるか、更新をどうキャッチするか、どうタグ付けや分類、加工するのか
- 転記・抽出の実現方法 134
    - 必要なのは、書類の読み方・抽出の仕方を教えるワークフローと、過去の抽出例を保存したナレッジベース
    - 「書類のどの部分に注目しているのか」を明確に。どこを見るか明示することで、関係ない項目から間違った値を取り出すことを避けやすくなる
    - どのようなルールや基準で、どの情報を抜き出しているのかを整理する。「契約期間は開始日と終了日をセットで取得する」など
    - 抽出した内容が正しいかどうかを「どのような方法で検証しているのか」、例えば過去の抽出例や他の項目との整合性チェックなども重要なポイント。過去の類似例との比較が必要など
    - 抽出結果を「どのようなフォーマットでまとめる必要があるか」。出力に「参照元ページ」「該当セクションの見出し」など人間が検証しやすいメタデータを付与しておくと、レビューしやすい
- 文書作成の実現方法 142
    - 文書作成業務の基本情報をまとめる。文書を書くことの目的(どのような業務のための誰に対して何を伝えるべきかなど)、文体など
    - 完成品に対してどのような視点で人が読むのか整理する。事実関係や正確性をどのようにチェックしているか、社内のトーンに沿っているかをどう判断するか、など
    - すでに存在している完成品の文書を分解する
    - 個別のセクションの書き方を考える
    - ワークフローを作るときは、セクションごとに一つずつ実現していく
    - 完成物はナレッジベースに登録することで、LLMや人の両方の財産になる
- レビュー観点を分析するには、既存のレビュー済み文書とその指摘・修正履歴を集め、どのような観点でレビューが行われたのか分析する。ChatGPTなどを活用して文書とレビュー結果を提示し、「どのような観点でレビューされたと考えられるか」を推測させるのも有効 155
- ナレッジマネジメントで人がやっていた分類やタグ付け、ようやく作成はLLMとワークフローで自動化できるようになった 167
- エージェントとは「与えられた目的を達成するために、自律的に推論し、計画を立て、状況に応じて対話や外部ツールの操作といった行動を起こすソフトウェア主体」 173
    - 「自律性」「目的志向性」が重要
    - プログラムされた手順をこなすのではなく、最終的なゴールを見据え、その達成のために「今何をすべきか」を自ら判断し、行動を選択する能力を持つ
    - エージェントの代表的な機能要素 176
        - Planning: ユーザーに与えられた課題を どのように解決するか行動計画を考える。
        - Knowledge: エージェントがPlanningや実際の行動の中で 利用できる知識。
        - Tool Use: 外部のツールを動かすエージェントのための 道具の呼び出し。
        - Memory: エージェントがユーザーとどのようなやり取りを 行ったかなどを記憶し処理をパーソナライズする。
        - Evaluation: ユーザーの指示と行動した結果を比較・評価し 次のPlanningに反映する。
- LLMは「ミスを犯しやすい」が、AIエージェントはLLM呼び出しを大量に行うため、エラーの蓄積効果が起きる。各ステップの成功率が90%あっても、5ステップをノーミスでクリアするのは59%まで低下してしまう 184
- エージェントとどう付き合うか 185
    - 全ての業務をエージェントにしようとしない
    - やり方が明確な業務は「ワークフロー」で良い
    - 人間とのコラボレーションを前提とする。人間がレビューや修正を行う前提で設計する
    - 新人の部下レベルであるということを社内で期待値コントロールする
    - 常に人間に「ホウレンソウ」させる。重要な判断を行う前や、一定の処理が完了した時点で
- 業務の自動運転の6段階 201