食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

生成AIを活用してGitHubのIssueをSlackから簡単に起票できる仕組みを作った話

皆さんこんにちは、ビビッドガーデンCTOの西尾です。 今回はGitHubのIssueをSlackから簡単に起票できるツールを開発し、運用しているお話をしたいと思います。

Issueの起票は意外と手間がかかる

弊社ではエンジニア、ビジネスメンバーともにGitHub Issuesにて課題管理をしています。 Issueに記載する内容はいくつかテンプレート化されているのですが、以下のような内容を記載することが多いです。

## 💫 目的や背景
## 💪 実現したいこと
## 🉑 受け入れ基準
## 📎 資料
## 🔧 タスク

Issueは誰が見てもわかりやすい記載をするのがベストではあります。

しかし、こんなことをいったら怒られてしまうかもしれませんが、このIssueを起票するという行為、さらにいうと文章をきちんと考えるのが意外と億劫だったりします。

弊社でも、「〇〇をIssue化しておいてくれませんか?」みたいなやりとりが発生することがたびたびありました。

生成AIを活用して、Slack上での会話を元にいい感じにIssueを起票する

Issueを起票をする前は、たいていSlack上でディスカッションをしていたりします。

これまでは、その会話を元に誰かがIssue化していたのですが、これをChatGPTにまるっとお願いしたら楽できるのでは? と思い、社内用のツール「alpha」を作りました。

例えば、Slackでディスカッションした内容をもとにalphaに依頼すると、自動でGitHub Issueしてくれます。

以下はその動作例です。これは適当な会話と適当なIssueですので、ご了承ください。

せっかく生成AIを使っているので、壁打ちできる機能も搭載しています。 Slackのスレッド上でいろいろディスカッションし、alphaにIssue化してと依頼をすると、以下のようにGitHub Issueが自動で起票されます。 過去の自分の発言やSlackスレッド内の会話を踏まえて、Issue化されます。

ツール alpha の仕組み

ここからは作成したツール alpha の仕組みを紹介します。

現時点では社内向けのコードが書かれているため、残念ながらソースコードがそのまま公開できません😢 これはどこかで直して公開できればいいなあとは思っています。

alphaはAWS Lambda上で動作しており、データはDynamoDBに保存されています。コードはRubyで書かれており以下のように動作します。

  1. SlackのEvent Subscriptionsの仕組みを使い、alphaにメンションされたら会話をAWS Lambdaに通知する
  2. メンションされた会話はDynamoDBに保存する
    • いままでのコンテキストを踏まえて動作するために、過去の発言はDynamoDBにいれておき参照する
  3. Issueを起票するべきか、ただ壁打ち相手となってもらうかのどちらのアクションをとるべきか、まずは判断する
    • 壁打ち相手になってほしい場合は、いままでの発言を含めてChatGPTに送り文章を生成して返す
    • Issueを起票すべきと判断して場合は、Step4に進む
  4. いままでの会話を踏まえて、Issueを起票する
    • Issueを起票すべきと判断した場合は、まずメンションされたスレッド内の会話をSlack APIで引っ張ってくる。会話が長いとChatGPTに渡せないので、ある程度要約をするというアクションも必要であれば取る
    • Issueのタイトルと本文をChatGPTで生成する
    • GitHub APIを利用して、Issueを起票する
    • 起票したIssueのURLをSlackのレスポンスとして返す

具体的には以下のようなコードを実行しています。 まずStep3では次に実行すべきアクションをChatGPTに判断してもらいます。

def get_action_command(message)
    messages = [
      {
        role: "system",
        content: <<~COMMAND,
          チャットボットです。回答は必ず日本語でしてください。
          あなたは以下コマンドを実行できます。ユーザーのメッセージをもとに、実行するコマンドを返してください。
          #{' '}
          A001. GitHubのIssueを起票する
          C003. 上記に当てはまらないコマンド

          コマンドを実行する場合は、コマンド番号を返してください。
          次にユーザーからのメッセージを送ります。
        COMMAND
      },
      {
        role: "user",
        content: message,
      }
    ]
    response = @client.chat(
      parameters: {
        model: "gpt-4o",
        messages: messages,
        temperature: 1.0,
      },
    )
    response.dig("choices", 0, "message", "content")
end

次にとるアクションをコマンド形式で返したあと、以下のように処理を振り分けます。 A001 なら Issue起票、それ以外ならいままでの会話をもとに壁打ちします。

  def dispatch_action(user_id, message, channel, timestamp, thread_timestamp)
    com_message = get_action_command(message)

    case
    when com_message.include?("A001")
      @slack_action.add_reaction(channel, timestamp, "github")
      summary = summary_thread_message(channel, thread_timestamp)
      github_title = get_github_issue_title(message, summary)
      github_message = get_github_issue_pbi(message, summary)

      create_message = create_github_issue(github_title, github_message)
      @slack_action.send_message(channel, create_message, timestamp)
    else
      ai_response = get_memory_openai_response(user_id, message)
      @slack_action.send_message(channel, ai_response, timestamp)
    end
  rescue => e
    pp e
    @slack_action.add_reaction(channel, timestamp, "dango")
  end

Issueを起票するための文章生成は、以下のようなコマンドを投げています。 ここは都度チューニングしていく必要があります。

  def get_github_issue_pbi(message, summary)
    com_messages = []
    com = <<~COMMAND
            あなたはプロダクトマネージャーです。GitHubのIssueを作成してください。だ、である調で書いてください。
            形式は以下のようにしてください。あなたの発言はそのままIssueとして作成されますので、回答は余計なメッセージを記載しないでください。

      ## 💫 目的や背景

      ## 💪 実現したいこと

      ## 🉑 受け入れ基準
                   #{'  '}
    COMMAND
    com_messages << { role: "system", content: com }

    com = <<~COMMAND
      次にいままでのコンテキストを渡します。この発言が関係あれば、それをIssueに反映してください。

      #{summary}
    COMMAND
    com_messages << { role: "system", content: com }

    get_openai_response(message, additional_messages: com_messages)
  end

最後にIssueをAPI経由で起票します。

require "octokit"

class GithubAction
  def initialize
    @client = Octokit::Client.new(access_token: ENV.fetch("GITHUB_TOKEN", nil))
  end

  def create_issue(repo:, issue_title:, issue_body:)
    issue = @client.create_issue(repo, issue_title, issue_body)

    issue.html_url
  rescue Octokit::Error => e
    puts "Error creating issue: #{e.message}"

    ""
  end
end

おわりに

Slackから気軽にIssueを作成できる仕組みを作成し、運用をはじめています。 社内でも少しずつ使われはじめています。

生成AIを活用することで、これまで煩わしかった作業を自動化できました。 AIを活用してどんどん楽をしていきたいですね!

アサインの悩みを解決するための取り組み

こんにちは、松久です。

デザインチームでは日々いろいろなことに取り組んでいます。 取り組むタスク(バナーづくりや、UIデザイン、マークアップなど)は、GitHub Project で issue を使って管理しています。 管理はしているのですが、誰が取り組むのかを決めていく上で悩ましいことがあります。 それは担当者の割り振り方法です。

今回は、悩んでいて解決していないアサインの話です。

現在のアサインの決め方

現在は、マネージャー(松久)が issue を見ながら誰に担当してもらうかを決めています。 issue には、グラフィック(バナーや、印刷物など)やUI など様々な依頼の種類があり、それぞれ得意な人にお願いしています。 なにかトラブルが起きているわけではないのですが、私が取りまとめて依頼をしているので「自主的に取り組んでいる」とはいい難く、私がいないと誰が何をやるのか決まらないことになっています。

このような状況になっている理由は以下の通りです。

  • issue をみんなが揃っている時に、みんなで見ていない
    • チームメンバーには限られた時間帯で稼働している人もいる(約半分)ため全員が揃う時間は有りません
    • issue を見て何をするのか判断して業務に取り組んでもらう必要があります
  • 何をするのか書いていないissueがある
    • 何を実現したいのかわからないので、担当者に聞いて確認したり、相談したりすることが必要になります
    • issue の担当者に詳細を聞くとしても、担当者とデザイナーで勤務する時間帯が必ずしも同じとは限らず、詳細が分かるまでに待機時間が発生することもあります。
  • 急ぎの取り組みが多い
    • 20営業日の間に平均14件前後の急ぎがあります
    • 急ぎの対応が必要な場合、自主的に取り組むのではなく、なんとかする!という気持ちで担当を決めてしまうことが1日に1回ぐらい発生しています

この状態だと、やらされている感がどうしても出てしまいます。チームで成果を出していると感じることも少なくなりそうです。

少しでも解消するために

何をするのか書いていないissueを減らしたり、わからない状態を脱しやすくする取り組みを始めました。issue に書いていない、読んでもわからないことをハッキリさせるために、GitHub Project のボードに「Un Ready」というカラムを用意して issue を入れることにしました。 このカラムのことを他チームとも共有して、空のissueに情報を書いてもらったり、取り組むための情報が足りていないことを知らせることが出来るようになりました。

おわりに

理想はあるけれど、いくつかの理由で現実との差分が生まれている状態です。 いちどに全部を解決することは難しいですが、1つ1つ解決をしてチームで「食べチョク」の改善ができるようにしていきます。

デザインチームの業務効率化を目指し #Figma プラグインの開発に挑戦

こんにちは、松久です。

食べチョクのデザインチームでは、Figma を利用して日々の業務をしています。 Figma は、何かを作り、様々な職種の人とコラボレーションをすることに長けたツールです。細かいアップデートで使い勝手が良くなることも多いので、Figma を使っています。

Figma の特徴の1つにプラグイン機能があります。審査が通ればプラグインによる機能拡張ができます。
今回は、特徴の1つである Figma のプラグインを自作して普段の業務にある面倒くさいを減らす試みの話です。

プラグインを作るきっかけ

毎月作成しているバナーを一覧ファイルにまとめ、過去の履歴を辿りやすくするという業務があります。
ただ、手作業で作成しているため手間も多く、間違い・漏れが発生しやすい状態でした。

毎月のバナー制作一覧

手作業をある程度でも自動化できないかと思ったのが、プラグインづくりのきっかけの1つです。
もう1つは、自身の開発機会が減っていたこともあり、「プラグインづくりにて TypeScriptを用いた開発機会を補いたい」という目的もあります。

プラグインを作り始める

ドキュメントを読めば始められるのですが、英語のドキュメントなので不安がありました。そんなときに、Figma Office Hours で「デザインと開発の生産性向上: Figma APIによる自動化とプラグイン開発」が 開催されました。 そこに 参加し全体像を知った上で、 ドキュメントを読みつつ、開発を始めることができました。

https://www.figma.com/community/file/1355039140557528563/www.figma.com

プラグインを作るときに困ったこと

プラグインを作る時にドキュメントを読めばわかるけれど、すぐにはわからなかったことをいくつか紹介します。

色指定

RGB では 255 までの指定ではなく 0〜1までになります。なので、 255 で割りました。

color: { r: 184/255, g: 28/255, b: 37/255 }

点線

点線は プラグインの API は dashPattern で指定します。 REST API では異なります。

frame.strokes = [{ type: "SOLID", color: { r: 0, g: 0, b: 0 }}];
frame.strokeWeight = 10;
frame.dashPattern = [20, 20];

findAll で取得した node は 全て SceneNode型になる

このため、Section だけを取得したつもりが、SectionNode ではなく SceneNode になっています。

const page = figma.currentPage;
const sectionNodes = page.findAll(node => node.type === 'SECTION');
// MEMO: findAll で取得すると SceneNode になる。SectionNode ではない。
// https://www.typescriptlang.org/docs/handbook/advanced-types.html
// https://forum.figma.com/t/type-scenenode-is-not-assignable-to-type-componentnode/19694/2
sectionNodes.forEach((sectionNode) => {
  const section = sectionNode as SectionNode;
  section.children.forEach((child) => {
    if(child.type === 'FRAME') {
      const frame = child as FrameNode;
    }
  });
});

非同期処理が多い

フォントの設定なども非同期になっています。そのため思った以上に1つのプラグインの中に非同期処理があります。

料金プランで使えない機能がある

API があることは確認したのですが、料金プランによっては使えないことが後からわかり残念でした。

おわりに

月に1回だけ使うプラグインですが、Figma で公開をしています。料金プランによっては、チーム内で公開できる機能もあり、社内特有のルールにあわせたプラグインを作ることも可能なようです。

プラグインを作ってみて、制作時に使うだけではなく、日々のメンテナンスのためのプラグイン作成もありだとわかりました。

日々の業務で出てくる面倒を減らすため、プラグインを作ることにも取り組んで「食べチョク」の改善を進めていきます。

デザイナー間での桃色の共有化と改善による成果

こんにちは、松久です。

今年も「桃」の季節になりました。
食べチョクでは、昨年に引き続き「夏の桃ラボ」と題して、色々な桃を味わえる特集をしています。デザインチームは、桃の特集を今年も実施するだろうと予想し、2 月頃から準備をしてきました。

品目毎の色パレットを作る

準備したのは、品目毎の色パレットを作ることです。
きっかけは、「桃やぶどうのような同じ品目でバナーを作る前に事前準備したこと」で紹介した品目毎の特集の色の管理で良かったことを徹底し、できなかったことを減らしたい気持ちからでした。

数人のグラフィックデザイナーでバナーなどを作るときに、それぞれが色を検討すると時間もかかりますし、色もなんだかバラバラになっていきます。また「食べチョク」らしさというのも揃えにくいことを感じていました。

Starbucks Creative Expression」を参考にして、品目毎のカラーパレットを作ることにしました。「Starbucks Creative Expression」は、スターバックスを利用するお客様の体験のため作られたクリエイティブに関する事例の集まりになっています。

GGitHub issue に要件をまとめつつ検討を開始し、グラフィックデザイナーが中心となって、Figma 上で形にしていきました。 昨年の制作物を活かしつつ、他の色ともバランスをとって作っていくことができました。

GitHub issue を用意して、目的や取組方法の案を書き始めました

Figma で制作を始めて色の配分なども含めて検討

実際に作ってから

2 月末ぐらいから始めて、4 月末ぐらいには夏頃の品目について準備ができたので制作を担当したグラフィックデザイナーから、デザインチームの他メンバーへ共有しました。 社内で運用している esa に色のページを設けてメルマガなどでも使えるように周知を始めました。ここは、去年は取り組めなかったことなので、適用できる範囲を広げることができました。

バナーと特集ページを作ってから、esa で色の共有を始めました

運用を始めると、足りないこともわかってきました。
例えば、グラデーションはどうするか?ありなのか?なしなのか?色だけじゃない表現サンプルは必要なのか?などが話題にでました。もっと良くするための話ができたのは、次回に向けての大きな収穫でした。

おわりに

「桃色」のパレットを作ったのでデザイナー間で「桃色」が共有化できていることを感じています。共有化したことで、足りないところも見つけることができました。 気づいた足りないことも、今後埋めていくことで「食べチョク」の改善を進めていきます。

Figmaプラグイン「Google Sheets Sync」を活用したSNS投稿用画像生成

こんにちは松久です。

生産者さんだから知っている そのままおいしい野菜の食べ方」が先日発売されました。本には生産者さんからの知恵が色々掲載されています。そこで、生産者さんが本の紹介をX(旧Twitter)やInstagram で投稿しやすいように、生産者さんごとの投稿用画像を用意することになりました。

この本には生産者200名ほどの方が掲載されています。そのため、生産者さんごとに掲載されているページや、品種・品目の情報がある画像を用意する必要があります。そこで、Figma の「Google Sheets Sync」を使って投稿用画像を生成することにしました。

導入までの流れ

作成までの全体の流れは以下のとおりです。

  1. Figma でテンプレートを作る
  2. 表示するデータを用意する
  3. Figma に「Google Sheets Sync」を入れる
  4. 実行

Figma でテンプレートを作る

Figma で画像を生成するためのテンプレートとしてコンポーネントを用意します。 コンポーネントを作るときに、レイヤー(Groupなど)の名前に #producer_name というふうに # を頭につけ、Google スプレッドシートの項目と一致させる必要があります。 データを入れたあとのことを想定し、文字数などでレイアウトが変わることもあるので、AutoLayout を使う必要があります。

コンポーネントを作ったら、生成が必要な分のインスタンスを作ります。

表示するデータを用意する

生産者さんのデータを用意するために、Redash を利用しました。デザインチームも SQL を書いたら利用できるようになっています。 本の掲載ページ数や、品目・品種については Google スプレッドシートに入れてもらうことにしました。

画像もいれることが出来ます。画像は、公開されているURLで Google スプレッドシートに記載します。今回は、Redash で 画像の URL も生成して用意しました。

Google スプレッドシートのデータを作るときに1行目は、Figma のレイヤー名と合わせる必要があります。ただし、# は抜きます。 準備ができたら、Google スプレッドシートの共有のURLを取得してください。URLは「リンクを知っている人」全員に「閲覧権限」を付与します。

Google スプレッドシートにデーターを入れている様子

Figma に「Google Sheets Sync」を入れる

Google Sheets Sync」を開き、Plugin をインストールします。

プラグインを実行して生成する

これで準備は整いました。あとは実行のみです。

  1. Google Sheets Sync(プラグイン)を起動
  2. Google スプレッドシートの共有リンクを入力して、 Fetch & Sync を押します

少し時間がかかりますが、200枚ほどの画像は生成されました。

おわりに

ダミーデータをいれる時に便利なプラグインなのですが、テンプレートを用意して大量の画像生成もできます。 Figma のプラグインは大変便利なので、普段から使ってみることで急な依頼でも対応できる方法を思いつくことがわかりました。ツールを使いながら「食べチョク」の改善を進めていきます。

宣伝

Amazon などで販売中です。

食べチョクでは Ruby3.3.1 + YJIT の運用を開始し、サイトが10%高速化しました

皆さんこんにちは、ビビッドガーデンCTOの西尾です。

食べチョクでは2024年5月23日より、Ruby3.3.1とYJITの運用を開始しました。 その結果、サイト全体のレスポンスが10%ほど高速化されましたので、詳細をご報告いたします。

サイト全体のパフォーマンスが10%高速化

以下は食べチョクの商品詳細ページのパフォーマンスです。

商品詳細ページのパフォーマンスが10%高速化

食べチョクはECサイトであり、商品詳細ページが最もよく見られるページとなっています。 このページのレスポンスが150〜160msだったところが、140ms程度まで改善しました。

最もよく見られるページが10%高速化したことは、すなわちサイト全体のパフォーマンスが10%高速化したということです!

商品一覧ページのレスポンスも改善

商品一覧ページのレスポンスも改善しました。 もともと300ms近くだったレスポンスタイムが、Ruby3.3.1 + YJITの導入により250〜270msまで改善しました。

商品一覧のパフォーマンス

ただし、食べチョク社内ではGETレスポンスタイムを200ms以下にしようという取り組みを続けており、このページのレスポンスタイムはまだ満足のいくものではありません。 引き続きパフォーマンス改善に努めてまいります。

導入にあたり発生したあれこれ

YJITの導入は以前から社内インフラチームで検討しており、Ruby3.3系になったら導入しようと計画していました。 しかし、Ruby3.3.0では動作が不安定になるという問題が発覚したため、導入を見送っていたのがあります。

この問題の関連Issueは https://bugs.ruby-lang.org/issues/20085https://github.com/ruby/ruby/pull/9371 です。

2024年4月23日にリリースされたRuby3.3.1でこの問題は修正されましたが、今度はbootsnapに関する不具合が発覚し、Railsが立ち上がらないという問題に直面しました。 関連Issueは https://bugs.ruby-lang.org/issues/20450 です。

このコメントにあるようにパッチを適用することでRuby3.3.1でも動作するようになりました。 具体的には以下コマンドでRubyのインストールをしなおしました。

rbenv install -v --patch 3.3.1 < <(curl -s https://raw.githubusercontent.com/havenwood/rvm-1/696d4f652864109a0cffff62e30a9e405fb0636a/patches/ruby/3.3.1/fix_bootsnap.patch)

パッチを当てることでRuby3.3.1でも動くようになったのですが、このままパッチをあててまで本番リリースするのか、急いでリリースしなくても次のリリースまで待てばいいんじゃないの? といった声はメンバーからあがりました

ただ、今回はYJITを有効化するとサイトのパフォーマンスが10%向上する! みたいな記事をちらほらみかけ、Rubyを変えるだけでパフォーマンスがあがるんだから導入しない理由はない! という話をしたところ社内エンジニアの納得も得られたので、Ruby3.3.1 + YJIT導入に踏み切りました。

パフォーマンスがあがるといったわかりやすい理由があると、バージョンアップのモチベーションにつながるのだなと感じました。

まとめ

Ruby3.3.1 + YJITを有効化することで、食べチョクのパフォーマンスは10%高速化しました。 Railsを使っている皆さまも、ぜひYJITの導入を検討してみてください。

これからも食べチョクのさらなるパフォーマンス改善に取り組んでまいります。

デザインチームの成長を加速する!内省(リフレクション)の技術

こんにちは、松久です。

各自で「ふりかえり」をして、人事評価がされます。 私も「ふりかえり」をするのですが難しいです。適切な「ふりかえり」だったのかわからず、手探りで行うことが難しく感じます。 そこで「ふりかえり」をどうやっているのか、まとめてみました。

ふりかえりとはなにか

経験したことを身につける(自分の知恵)にすることです。 反省する(過ちを認める)ことが「ふりかえり」ではないです。

経験したことを身につけるというのは、以下の3つのステップに分解できそうです。

  • 認知:知った・(他者から聞いて)知っている
  • 行動:使った
  • 結果:成功・失敗

経験とは、知ったことをもとに行動し結果を知った状態になることとします。 自分の知恵にするには、これらを「抽象化」して「次の行動を決めること」が必要になります。

経験したことを身につけるための「ふりかえり」は3ステップになります。

  1. 経験の確認
  2. 経験を抽象化をする
  3. 抽象化したことから、次の行動を決める

目標とふりかえりの関係

目標は「成果(結果)」のための「行動」を設定しています。 目標で設定した行動をして成果(結果)がどうだったか確認し抽象化して次の行動を決めるまでが「ふりかえり」となります。

抽象化するということは、認知にも繋がります。認知になると、次の経験のためのスタートになります。 そのため、目標をたてたら、ふりかえりをすることで循環させていく取り組みになっています。

ふりかえりをする

ふりかえりをする前に

ふりかえりは、具体から抽象を引き出して、具体にしていきます。また、過去に何をしたのか確認する工程があるので、思い出す時間も必要となります。 そのため、おさえておくと良さそうなポイントは以下のとおりです。

  • 落ち着いた時間を確保すること
    • なにかをやりながらは、ダメ
    • 細切れな時間ではなく、ある程度続けた時間であることが理想です
  • 疲れているときにはしない
    • ネガティブなことばかりになりがち
    • 反省になってしまう

実際にふりかえりをする

何をして、どんな事が起きて結果どうだったかを確認します。 サンプルを用意してみました。

何をしたか?から始めて、次の行動まで書き出してみる

  • どんな行動をしたか?
    • LPを作った
  • どんな事が起きたか?
    • 期日に間に合った
    • CSS を書く時にクラス名の命名で困ったが解決方法がわからなかったままになった
    • CSS 変数の便利さがわからなかったが、便利な場面に出会った

行動して起きたことを書き出したら、抽象化をしてみます。 抽象化の前に、出来事の原因を探します。そこから抽象化をしてみます。

  • 起きたことを抽象化する
    • 期日に間に合ったのはなぜ?
      • デザイナーさんとレイアウトが見えてきた時点でマークアップを始めたから
        • 抽象化 => 手戻りの可能性がない部分を明確にすることで、開発着手を早めてスケジュールの短縮に繋がる
      • デザイナーさんと進捗の共有をしたから
        • 抽象化 => 初期段階で関連ステークホルダーとコミュニケーションを取り、進捗を共有することで、手戻りの可能性を減らしたから
    • 解決方法がわからなかったままになった
      • なんとなくで命名して解決してしまった <= 見返しポイント
    • 便利な場面に出会った
      • 何度か使ってみていたから出会えた <= 見返しポイント

抽象化から、行動を書き出してみます。 「行動」はカタチに見える行いを「行動」とします。 例えば「考える」だと何か具体的なカタチに見えるものがないので「行動」とは呼びません。

  • 次の行動を決める
    • 期日に間に合ったのはなぜ?
      • 自分ができるところから着手を始めて、後で変わるのか、変わらないのかを把握する
      • 把握するためにも、ステークホルダーと進捗の共有を毎日する
    • 解決方法がわからなかったままになった
      • 次の行動なし <= 見返しポイント
    • 便利な場面に出会った
      • 次の行動なし <= 見返しポイント

書き出したものを見返す

ここで、もう一度見返します。行動のところから見返していきます。

見返すポイント
  • 上手くいったのはなぜ?系
    • 「リリースできた」「100%以上の達成をした」時は、なぜ出来たか?要因を探ります
      • 要因を定着させることを次の行動にします( Keep となる行動をみつける )
    • 200% の成功になるには何が足りなかったかを探るのも出来そうです
  • わからなかった系
    • わからないときに、なにもしないのはなぜか?を探ります
      • わからないんだったらどうする?はエマージェンシーリーダーシップがあるか?のポイントになります
      • どこまでわかって、何がわからないのか探ります
  • わかった系
    • 本当にわかった?わかったことを広げられない?を探ります
    • わかったあとに、定着を目指す行動がないかを探ります
  • 行動しなかった時
    • なぜ行動しなかったんでしょうか?を探ります
      • 「体調を悪くしていた」などやむを得ない事情もあります
      • 他の急ぎがあった時は、別なことの行動のふりかえりをします
        • ただ、OKR 以外のことが発生した理由を探るのもアリです
    • サボった、という話であれば、とにかくやる、時間の使い方の配分を検討します
  • 実は問題ではなかった
    • 問題だと思っていたけれど、誰も困っていない時は、問題ではないことに気づいた、とします

上記のようなふりかえりの見直しをして、抽象化と次の行動を書き出して「ふりかえり」とします。 抽象化は、「他でも起こせること」「ベストプラクティスをつくる」「教訓」などと言い換えられそうです。 起きたことから気づいたことを抽出するようなイメージです(インサイトを見つけるとも言えそうです)

ふりかえり方法のまとめ

ふりかえりは3ステップです。

  1. 具体:経験の確認
  2. 抽象:経験を抽象化をする
  3. 具体:抽象化したことから、次の行動を決める

上記の流れで、具体と抽象を行き来するので、時間も必要となります。 落ち着いたまとまった時間を確保して行うことをおすすめします。

おわりに

「ふりかえり」について具体的にどうすればいいのかデザイナーに説明することがあり、実例で書き出してみました。 書き出してみてから「ふりかえり」をしてみると、抽象化が大切になっていると実感しました。

個人の「ふりかえり」をすることで、個々人の学習を組織に広めて「食べチョク」の改善を進めていきます。

参考書籍