KPTに慣れたチームが、よりよい振り返りを行うために、K / P / T のそれぞれにフォーカスをあてた考察(それぞれは、何でないかの考察も添えて)

location_city Online schedule Oct 1st 02:25 - 02:45 PM JST place A Track people 10 Interested

KPTについて、Keep・Problem・Try それぞれに対して、考察した結果を共有します。

世界にはたくさんの振り返り(レトロスペクティブ)の手法が存在します。その中で KPT は市民権を得て、多くの現場で使用され、そのパワーを発揮しています。一方で、そのフレームワークとしての使いやすさ、わかりやすさの影に隠れて、「なんかしっくりこない」「惰性だけで続けている感じがする」「議論がうまくいかない」という現場も多いのではないかと推察しています。もちろん、多種多様な振り返り手法にスイッチしてチームの活動に変化をつけることもよいと思います。ただ、本セッションでは、あえて王道とも言える KPT を考察することで、KPT に慣れたチームの振り返りを、よりよくアップデートする方法を提案します。

考察は、検査と適応・タイムボックス・コミットメントという、アジャイルやスクラムの観点をベースにします。Keep・Problem・Tryは、それぞれ、何であり、何でないのか。どのように定義づけて、何を大切にするのか。そして、自分がファシリテータの時に、どのようにチームメンバーへ促していくのか。スクラムマスターとして、複数社・複数チームの振り返りファシリテートを実践した経験を通して、共有します。

そこには、振り返り・チームビルディングに興味関心があり、KPTを実践された経験のある方ほど、「はっ!」とする気づき、「なるほどみ」があるのではないかと思います。

例えば、こんなお話をします。

  • Keep
    • ”よかったこと”ではない(それは、Good・Win・lucky)
    • 他のメンバーに再現性のあることを、因果の証明なしで説明する
  • Problem
    • ”推論”ではない(事実の共有、深掘りこそが重要)
    • 自分自身の不快な気持ちもまた、事実として共有する
  • TRY
    • 全ての Keep, Problem を落とし込む必要はない
    • 問題の棚上げこそが最適解であることがありえる

上記、明言した表現・断定した表現にしていますが、絶対的な正解は、どこにもないと思います。本セッションでは、KPTに慣れた方や、言葉にできない課題を感じている方、課題はないけどよりよくしたいと思う方が、”KPTという枠組みを振り返る”きっかけとなれば幸いです。

 
 

Outline/Structure of the Talk

  1. KPTのパターンを確認
    1. KPT, GKPT, KPTA をおさらい
    2. KPTが拡張された背景にあるものを推察する
  2. フォーカスする前に立脚点を置く
    1. 検査と適応
    2. タイムボックス
    3. コミットメント
  3. Keepにフォーカス
    1. Keepとは、何であるのか
    2. Keepとは、何でないのか
    3. ここで得たい、大切なことは何か
  4. Problemにフォーカス
    1. Problemとは、何であるのか
    2. Problemとは、何でないのか
    3. ここで得たい、大切なことは何か
  5. TRYにフォーカス
    1. Keepとは、何であるのか
    2. Keepとは、何でないのか
    3. ここで得たい、大切なことは何か
    4. TRY(ACTION)を決める方法の種類とオススメ
  6. メッセージ
    1. KPTに参加するあなたへ贈るTIPS
    2. KPTをファシリテートするあなたへ贈るTIPS

Learning Outcome

  • KPTから多くの学びをチームに還元できるヒントを得られる
  • KPTから多くの変化をチームに還元できるヒントを得られる
  • 来週の振り返りを、楽しく、有意義に、やってみよう!待ち遠しい!と思える

Target Audience

KPTを使用して振り返りをしているが、言葉にできない課題を感じている方。課題はないがよりよくしたいと思う方。

Prerequisites for Attendees

  • スクラムガイドを一読したことがある
  • KPT(Keep / Problem / Try)をチームで実践したことがある

Slides


schedule Submitted 11 months ago

  • Takeshi Kakeda
    keyboard_arrow_down

    Takeshi Kakeda - XPの旅 〜 そして全体性へ

    Takeshi Kakeda
    Takeshi Kakeda
    Owner
    Zensow
    schedule 1 year ago
    Sold Out!
    90 Mins
    Keynote
    Intermediate

    1000

    概要

    自らを「忘れられたXPer」と称し、20年にわたり様々な領域に知見を広げ体験してきた。その歩みは同時に日本のアジャイルの始まりと普及への歩みでもあった。著者の身体に強く深く刻まれたアジャイル黎明期の体験、出会った人たち、そして優れた師友の回想をまじえながら、その体験的実験的踏査を克明かつ情熱的に綴る。KKDワールドをはぐくんだ全体性探求の旅の記録。

    もう少し詳しい概要

    私がXPに出会って20年以上が経ちました。XPから始まった旅は、よりよいソフトウェアを開発したいい、という個人的な望みからはじまって、多くの仲間とともに、日本全体に「これまでになかった新しい変化を生み出し広げていく」という稀有な体験を私にもたらしてくれました。

    本講演の前半は、昨年のXP祭りで発表した『忘れられたXPer』をベースにしています。私とXPとの出会い、コミュニティへの参加、日本にXP、スクラムが紹介され、アジャイルという言葉が生まれ、少しづつ日本に普及していく20年間の様々な体験をしました。2022年の今に繋がる日本のアジャイル普及の物語、新しいアイデアが広がっていく様子を、私の体験・視点から語ります。

    そして、後半はそれらの「XPの旅」を通じてたどり着いた、最後の謎である全体性について目を向けます。なぜアジャイルは広まったのか、今後はどうなるのか、その鍵となるのは全体性というキーワードだと考えています。XPの旅が、どのようにして全体性に結びつくのか、全体性とはなにか、全体性を育むにはどうすればいいのか、それらについて今の私の考えを皆さんと分かち合います。

    インスパイアされた本

    宮本常一『民俗学の旅

    9784061591042.jpg

     

     

     
     

     

     

  • seko satomi
    keyboard_arrow_down

    seko satomi - リモートワーク第一世代の若手SE女子がアジャイルマインドで時代の変化を乗り越えた話

    seko satomi
    seko satomi
    engineer
    NEC Corporation
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    ジョブ型雇用の浸透、働く人の多様化など。。

    今までの当たり前がこれからの当たり前になるとは言えない時代になりましたよね。皆さんの中にも不安を感じる方がいらっしゃるのではないでしょうか。
     
    このように周囲の環境が複雑で多様に変化している現代、逐次フィードバックを得ながら継続的に価値を積み上げていくアジャイル開発の考え方が注目されています。
     
    さて、私もそんな悩みを抱える一人でした。
    さあキラキラ社会人生活を送るぞと意気込んだ2020年、
    まさかの新型コロナウィルス流行により予期していない環境の変化に戸惑いました。
     
    しかし、2年目の異動にてスクラムチームに所属しアジャイル開発を学んだことが転機となり、変化する環境をアジャイル開発の原則を活かすことによって自分なりにも乗り越えることができました。

    本セッションでは変化に適応するためこれから実践できること
    リモートワークにおける業務において役に立ったプラクティスをお話しします。
    今アジャイル開発をやっているかた、やっていない方どちらも大歓迎です。
    皆さんの参考となれば幸いです。
  • Masataka Mizuno
    keyboard_arrow_down

    Masataka Mizuno / Makoto Takaesu / Takao Kimura - ゾンビスクラムから回復しよう~継続的改善編~

    100 Mins
    Workshop
    Intermediate

    みなさんのスクラムは、成果を上げていますか?「期待とは違うんだけど...」なんて感じていませんか?

    遠くから見るとスクラムのようでも、近くで見るとそれとは程遠い、やる気を失わせる残念なスクラムを「ゾンビスクラム」と呼びます。スクラムイベントを型どおりになぞってはいても、期待した効果が得られていない――そんな状態です。ゾンビスクラムにかかると「ステークホルダーのニーズを知らない」「速く出荷しない」「継続的に改善しない」「自己組織化しない」の4つの症状が現れることが分かっています。どうです?身に覚えありませんか?

    本ワークショップは、ゾンビスクラムの見分け方や回復するための様々な実験を紹介した書籍『ゾンビスクラムサバイバルガイド』をもとに、ゾンビスクラムの症状・原因をお話しします。そして、4つの症状のうち「継続的に改善しない」に着目し、チームが改善する能力を高めるのに役立つ実験を体験していただこうと思います。

    さあ、役にたっていないスクラムに血を通わせよう!

  • Kaori Tobe
    keyboard_arrow_down

    Kaori Tobe - 営業職からプロジェクトマネージャーになったら大事にしてたことが全部アジャイルにあった話

    Kaori Tobe
    Kaori Tobe
    Project Manager
    -
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    私は2021年に営業職からプロジェクトマネージャーに転向しました。

    毎日が勉強の日々。必死で過ごした1年はあっという間で、できること・できないことが明確になる1年でもありました。
    あわせて、プロジェクト運営、チームビルディングについて考え、その中でスクラムマスターという役割を知りました。
    現在はアジャイル開発に携わっていないけれど、きっとスクラムマスターについて学ぶことはプロジェクトを担う上で、チームを作っていく上で役に立つ!と思い、スクラムマスター研修への参加を決意しました。

    そんな私がスクラムマスター研修を受けて感じたこと、考えたことについて想いを語ります!

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Yuki Hattori - InnerSource : 内製化の一歩先を見つめるコードの共同所有の取り組み

    45 Mins
    Talk
    Beginner

    InnerSource インナーソース という取り組みがあります。「コードの共同所有 (Collective Code Ownership)」はXPの重要なプラクティスの一つですが、これを社内で行うためには、さまざまな部署が協調的に働く環境づくりが必要になります。しかし私たちは、その点について十分な移行戦略や説得のボキャブラリーを持っていないことが多いと感じています。

    一方でGAFAなどの米国大手IT企業では、シングルリポジトリ(会社全体で一つのコードリポジトリ)をやっているという話を聞いてきました。日本企業でシングルリポジトリになるのは、なかなか大変だなー、と思ってきた方も多いのではないかと思います。

    米国のMicrosoftも、実はシングルリポジトリではなかった企業の一つです。事業間はある種競争関係でもあるので、基本的にはソースコードは共有しないもの、とされてきました。しかし、クラウド中心へのビジネス全体の転換を進める中で、ここ数年は1ES(One Engineering System) という、共通基盤の普及を進めてきたそうです。これを始めたのが Agile 2015 で基調講演を務めた Sam Guckenheimer 氏です(現在は引退、退職)。私も、2019年に彼のオフィスを訪ねています

    本セッションでは、Sam さんの下で働いたこともある服部さんに、Microsoft の 1ES の取り組みがどのようなものであったのかを紹介していただくところから始めたいと思います。一次情報がやっぱり一番うれしいと思いますので。そのうえで、その取り組みの先にある、企業をまたいだ活動である InnerSource Commons について最近私が勉強したことをまとめてみようと思います。

    InnerSource Commons は内製化を進める大企業が参加し、どうやって部署をまたいだコードの共同所有を社内に生やしていくか?その中で他部署からのコントリビューションを得るにはどうしたらいいのか?そして、オープンソース文化では基本知識となっている、プルリクエストベースのコードのコントリビューションの仕組みや体制をどのように作っていくのか、開発者として何を学ぶ必要があるのか、について知見を整理してくれています。

  • Fumihiko Kinoshita
    keyboard_arrow_down

    Fumihiko Kinoshita - アジャイルな働き方の本質 〜ドラッカーとXPからの考察〜

    Fumihiko Kinoshita
    Fumihiko Kinoshita
    Agile Coach
    ESM, Inc.
    schedule 10 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    アジャイル開発においては受発注の垣根を越えて、発注者を受注者が1つのチームとなって働きます。

    こう書くと「そんなのけしからん!」「それは偽装請負にあたるのではないか」という疑念を抱かれることが多くありました。

    これに対して、2021年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」が発表されています。ここでは発注者側と受注者側の開発関係者が対等な関係の下で協議することや開発担当者が自律的に判断して開発作業を行うといったアジャイルな働き方が前提として謳われています。

    本セッションではアジャイルな働き方について、その起源や背景、従来の指揮命令型の働き方との対比なども含めて解説します。

    さらに、前述の疑念が生じてきた背景には、ソフトウェア開発そのものに対する誤解があるように感じています。「工程」「人工(にんく)」「作業」といった言葉に代表されるように、ソフトウェア開発が工業製品の大量生産のメタファで語られることが多いことに私は違和感を憶えていました。私が経験したソフトウェア開発は創造的かつ探索的であり、専門家の知識と協調によって成立するもので、大量生産とは対極にあるものでした。

    ピーター・ドラッカーが知識労働者(ナレッジワーカー)という言葉をはじめて使ったのが1959年に発行された著書『変貌する産業社会』の中でのことです。知識労働というコンセプトが発明されたにも関わらず、知識労働であるソフトウェア開発を大量生産を前提とした未熟練労働のように捉えることによる誤謬によって、ソフトウェア開発者が本来持つ創造性は完全に失われてしまいました。

    そんな暗黒世界からソフトウェア開発を救い出したのが、そう、エクストリームプログラミングだったのです。

    続きはXP祭りで。

    (2020年のXP祭りで話した『近代史とアジャイル』以来、2年の時を経て、またまた懲りずにXP祭りでドラッカーの話をします。)

  • Akiya Mizukoshi
    keyboard_arrow_down

    Akiya Mizukoshi - エンジニアからPdMになって苦労している話

    Akiya Mizukoshi
    Akiya Mizukoshi
    engineer
    NaviPlus Co., Ltd.
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    チームのエンジニアをしていたけど、前のPdMが抜けたので代わりにPdM(≒プロダクトオーナー)になって数ヶ月が経ちました。それまでPdMに対して内心持っていた期待や不満が自分に返ってきてプレッシャーになっていますが、チームのみんなに支えられながら何とかやっています。となりのチームや営業の人たちとの摩擦もあったりしてなかなか簡単じゃないですが、いろいろ工夫したりカイゼンしたりしていることを紹介します。

  • Yusuke Suzuki
    keyboard_arrow_down

    Yusuke Suzuki - サービスブループリントによるシステム設計手法の紹介

    Yusuke Suzuki
    Yusuke Suzuki
    CEO
    Graat
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    現代においては

    • CX(顧客体験)、EX(従業員体験)を向上させる必要性の高まり
    • SaaS/PaaSを前提とする「組み合わせ」によるシステム構成
    • アジャイルによる段階的な機能整備

    といった状況から、システム設計が複雑化しています。本講演では、時間軸をベースにCX/EX/システムアーキテクチャの整合性を確認しつつ、段階的な機能整備を可能とするための手法としてサービスブループリントを紹介し、その特徴や設計の進め方について講演者の実践的な経験をもとに説明します。

  • Masaru AMANO
    keyboard_arrow_down

    Masaru AMANO - 日本におけるアジャイル開発の認知度の変遷を情報処理技術者試験の問題から考察してみた

    Masaru AMANO
    Masaru AMANO
    Programmer
    ESM
    schedule 11 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2000年2月に「extremeprogramming-jp」というメーリングリストが活動を開始し、2000年12月に「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」という翻訳本が出版され、日本でXPを実践する人が出てきました。

    2001年2月に「アジャイルソフトウェア開発宣言」が公開され、「アジャイル」という言葉も広く知られるようになってきました。

    当時、このような情報を入手し、活用できていたのはごく一部のアーリーアダプターと呼ばれるような人たちでした。XP祭りの開催主体である日本XPユーザグループは2001年4月に設立されており、当初から運営に参加している人たちは、まさにアーリーアダプターです。

    その後、アジャイル開発に関連する知識はどのように日本で広まっていったか、情報処理技術者試験で出題されるアジャイル開発に関連する問題からその傾向を調査し考察しました。

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi / Arata Fujimura / Sakano Nao / Sugii Msakatsu / Takeshi Fukasawa / yasuyuki kamitokusari - 週刊スクラム御意見番:クラスメソッド版 XP祭りスペシャル

    45 Mins
    Talk
    Advanced

    クラスメソッドのCX事業本部には、スクラムマスターが組織横断で緩くつながる目的で結成した、『スクラムマスター向上委員会』という非公式グループがあります。

    今回スクラムマスター向上委員会のメンバーが、CX事業本部内の各スクラムチームのスクラムイベントを順に見学し、われらが御意見番が、厳しくも愛のある、ご存じ『喝!』に加え、吟味に吟味を重ねたスーパープレーに与えられる『あっぱれ!』ってことをやりたいと思います。

    例えば‥

    • 大きなプロダクトをアジャイルにできるか
      • 複数の開発チームでPOが大変・・・!?
      • なんちゃってLeSS、なんちゃってSAFe
    • 主体性の強すぎるチーム
      • 開発チームとPOでしっかり連携
      • スクラムマスターはいらない・・・!?
    • スクラムイベントのファシリテーターの悲哀
      • 誰も返事してくれないオンラインミーティング
      • しゃべり続けちゃうファシリテーター
  • Takaki Sumita
    keyboard_arrow_down

    Takaki Sumita - 不確実性に向き合うために、チームのアジリティを高める開発タスクの切り方

    45 Mins
    Talk
    Intermediate

    サービス開発をしていると、不確実性が高い様々な事象がチームを容赦なく襲います。

    そんな中、不確実性への対応力を上げるために、皆さんはどんなことに取り組まれていますか?

    自分のチームでは、スクラムとともにアジリティを高めるために「開発タスクのバッチサイズを小さくする」ことに日々取り組んでいます。

    この発表では、受け渡し型開発(リレー形式・ウォーターフォール)がなぜ不確実性をコントロールしにくいのかや、明日からできるチームのアジリティを上げる開発タスクの切り方を紹介します。

     

  • Yamato Naka
    keyboard_arrow_down

    Yamato Naka - to the begining -コミュニケーションスキルを使う前に-

    Yamato Naka
    Yamato Naka
    Senior Consultant
    MicroStrategy Japan
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    コミュニケーションスキルを学び始めると最初の頃に出てくるテクニックを例として、学ぶ際の注意点や誤用の原因といった、予め認識しておくことをお勧めする知識を話します。
    昨年と異なりLight Sideな話です。

  • Takefumi Iseki
    keyboard_arrow_down

    Takefumi Iseki - プロジェクト開始時点からテストを考えることの勧め

    45 Mins
    Talk
    Beginner

    ソフトウェア開発でどのようにテストをされていますか?

    TDD などを取り入れたいまどきのプロセスでテストをされていますでしょうか?

     

    テストには、計画、分析、設計、実装、実施のプロセスがありプロジェクト開始時点からテストを考慮してかないと、特に最終工程でテストが必要という状態になると、オーバーヘッドが大きく後戻り、後戻りができるのならまだよくプロジェクトが破綻することもあります。

     

    私たちは、エンタープライズ系のパッケージ製品を作成しており、ウォーターフォール型の開発プロセスであり、残念ながら TDD などの今時なテストは実践できておりません。

     

    しかしながら、アジャイルやスクラム型の開発プロセスへの変革とはいきませんが、後工程という意味での「テスト」を概念、マインドを改めて、テストと開発(設計、コーディング)と融合させるプロセスを考えてきました。

    これは、製造、テストの工程を分断するのでなく、安心・安全に製品開発・リリースを行うためです。

     

    また、「ホリスティックテスト」という概念がありますが、いつでもテスト、どこでもテストを目指しており、シフトレフトとなり効果的・効率的なテストを実施できることも考えたプロセスとしています。

     

    上記のテストプロセスを考えて製品開発の実践していること、そして理想と現実と、そして将来に向けた歩みと挑戦を話していきたいと思います。

     

     

  • Sakano Nao
    keyboard_arrow_down

    Sakano Nao - プロダクトオーナーの消失

    Sakano Nao
    Sakano Nao
    Scrum Master
    Classmethod.inc
    schedule 11 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    初めてスクラムマスターとして立ち上げ期から参画したプロジェクトで、

    最初は回っていたチームだったが、途中からプロダクトオーナーが消失し、最終的にスクラムチームが崩壊した話を、反省を踏まえ話そうと思います。

    もしかするとレアケースかもしれませんが、今後そのようなことに陥る前に自分は何ができるのか、みなさんと一緒に考えたいと思います。

  • Yuhei Koito
    keyboard_arrow_down

    Yuhei Koito / Junya Miyake - いいチームを作りたい!!〜関係の質を改善するために私たちがやったこと〜

    45 Mins
    Talk
    Beginner

    皆さんの思う"いいチーム"ってどんなチームでしょう?

    生産性の高いチーム、自律したチーム、色々な考えがあると思うんですが、
    最初からいきなり”いいチーム”が出来るわけではないですよね

    では、何から手をつければ良いんだろう?
    他のチームではどんなことをやっているんだろう?
    そんな疑問に答えるべく、
    5月に発足したばかりのKDDIアジャイル開発センター株式会社(長いw)の2人が
    ダニエル・キム氏の提唱する「成功の循環」モデル(※)に基づき、関係の質を改善するという観点で
    自分たちのチームで実際にやってみてよかったこと/ よくなかったことについてお話ししたいと思います

    私たちの取り組みに対するご意見や、皆さんのチームでやっていることも聞いてみたいので
    Discordでワイワイ進めましょう!!

    ※ https://www.humanvalue.co.jp/keywords/theory-of-success/

  • Taku Fujii
    keyboard_arrow_down

    Taku Fujii - ついに邦訳が出ましたマネジメント3.0のモデル超入門+議論

    Taku Fujii
    Taku Fujii
    Agile Advisor/Trainer
    M3&T Lab.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    マネジメント3.0では、アジャイル開発のように自己組織化するチームのマネジメントのあり方(モデル)を複雑系の科学等の観点に基づいて提案している。本セッションでは、複雑系、自己組織化などの基本概念を説明し、それらを踏まえたマネジメント3.0モデルの6つの視点を時間の許すかぎり紹介する。また、可能であればグループでの議論を交えつつ、可能な限り議論を行っていこうと考えている。

  • Koichi ITO
    keyboard_arrow_down

    Koichi ITO - 組織のアジリティを向上させるエンジニアリングマネージャーの仕事

    Koichi ITO
    Koichi ITO
    Engineering Manager
    ESM, Inc.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    私はエンジニアリングマネージャーという比較的歴史の新しい仕事をしています。本編はここ一年のエンジニアリングマネージャーとしての活動をふりかえった内容です。

    エンジニアリングマネージャーとしての実践と観察の中で感じるのは、ソフトウェア開発組織が多様なようにエンジニアリングマネージャーも一義的なものではなく、組織の事業課題によって求められる像が異なるようです。勤務先の「永和システムマネジメント」はアジャイルソフトウェア開発を20年近く続けてきている企業ですが、そんな老舗の中でどんな組織課題の解決を進めているのか、その一例をお伝えします。

    また、昨今はソフトウェア業界全体として人材不足が取り上げられて久しいところ、人材への採用面や育成面についてもフォーカスする予定です。

  • Yuta Yasugahira
    keyboard_arrow_down

    Yuta Yasugahira / FUJITA kazuhiro / Sho Kurogi / Takashi WADA / Takayuki FUJITA - 古くて新しい本の読み方"会読"を体験しよう!XP会読会 出張版 in XP祭り2022

    45 Mins
    Workshop
    Beginner

    私たちはXP会読会という小さな読書会のメンバーです。

    隔週日曜の夜に、XPの書籍やパターンの書籍などを10名前後で音読して、その後書籍の内容について議論しています。

    私たちはこの"会読"という本の読み方が大好きです。
    事前準備が不要なので気軽に開催でき、他のメンバと会話することで書籍の理解が深まるからです。

    本ワークショップでは、登壇社と参加者で一緒に会読をして、会読の手軽さ・楽しさを体験していただきます。
    きっとこの体験を通じて、参加者の読書方法の手札の1つに会読を加えてもらえることでしょう(^^)

    今回はXP祭り2022への出張版ということで、XP白本2版(オーム社)を会読します。
    お手元に用意の上参加ください。

    出入り自由です。

    7k74Dmc.png

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - extreme blogging〜680日ブログを書き続けている理由と継続して得たもの〜

    45 Mins
    Talk
    Beginner

    2020年に、あるイベントに参加したことがきっかけでブログを始めました。

    ブログを始めた時は、継続したい気持ちはありつつも長続きしないと思っていましたが、継続するためにいろいろな工夫を取り入れたりブログを見た方々から様々な感想をいただくことで、680日以上毎日連続でブログを書き続けることができました。

    本発表では、ブログを500日以上毎日書き続けてみて思ったことや、500日間継続できた理由...について話してみようと思います。

    当日はやや突拍子もなく感じる内容もあると思いますが、いくつかの工夫を持ち帰りいただくことで、物事を継続するコツや継続によって得られるものを知っていだければと思っています。

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - おいしいドッグフードの食べ方

    20 Mins
    Talk
    Beginner

    ドッグフード、食べてますか?

    開発している製品を自分たちで利用しテストするドッグフーディング。
    長らく自社開発の現場に関わっているためドッグフーディングをする機会は多く、
    なんなら毎日ドッグフードを食べているような状況です。

    これまではすでに稼働しているサービスをドッグフーディングしフィードバックするというケースが多かったのですが、直近で開発に関わった「散歩ルート」では仮説を立てプロトタイピングし、市場リリースするまでのプロセスで何度かドッグフーディングする機会がありました。

    参加しているメンバーたちが主体的にドッグフードを喰らい、ドッグフーディングを通してぼんやりした要求をくっきりさせていく。技術的な課題を明らかにし、つくりこんでいく。このプロセスは中々に心地良いものでした。一方で、開発している自分たち自身がドッグフーディングすることで生まれる課題というのも、やはりありました。そういった、実体験を通して改めて気づいたドッグフーディングの良さ、そして課題についてお話する予定です。

    突き詰めれば一般的にいわれているドッグフーディングの効能と課題に行き着きそうな気もしますが、具体的な体験を通してドッグフーディングについて語るということに価値があると信じています。

     

     

help