スクラム開発を経験してわかった「やらないほうがいいこと」（開発者目線）
はじめに 開発者としてスクラム開発を経験して、私が感じた**「やらないほうがいいこと」**をスクラムイベントごとにまとめました。 開発者目線だけではなく、スクラムの中の1人のメンバーとしての目線も含まれています。 ※ 本記事の内容は内容はあくまで私個人の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 デイリースクラム 「忙しい」を理由にかんばんボードのステータスを更新しないこと 忙しいあなたの状況こそが、デイリースクラムで最も共有されるべき情報です。 進捗が滞っていることを正しく共有して、対策を講じてもらうように働きかけたほうが、その状況が正しく改善されます。 「忙しいから、かんばんボードのステータスの更新に手が回らない」ではなく「かんばんボードのステータスの更新ができていないから、忙しくなる」ということです。 議論すること デイリーで課題を共有すると議論が発生
LLMによるLLMの評価とその評価の評価について
LLMをプロダクトに活用していく上でプロンプトの出力結果を評価していかなければいけない訳ですが、可能な限り自動で定量評価できると改善もしていきやすくなり大変助かります。 そこで所謂LLM-as-a-Judgeと呼ばれるLLMに評価してもらう手法を取るわけですが、やはり「このスコアはどれくらい信じられるのか...?」という疑問が湧いてきて"評価の評価"がしたくなってきます。 というところで、本記事では使いそうなLLM-as-a-Judgeの手法について調べた後、"評価の評価"の仕方を調べてみた結果をまとめていきます。 LLM-as-a-Judgeの手法 まず初めに、LLM-as-a-Judgeにも様々な手法が存在するので、それらを確認していきます。 スコアベース 一番ベーシックなものはスコアをつけてもらうやり方です。 次のように実際のインプット、それに対するLLMの回答をプロンプトに加えて、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
