概要

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

もう少し詳しい概要

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

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

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

インスパイアされた本

宮本常一『民俗学の旅』

Planning an event for your company or trying to host a fundraiser can get complicated in a hurry. There is so much to think about when you consider all of the pieces that need to be seamlessly integrated for an amazing experience. Don’t waste your time making rookie mistakes. Here is a quick list of planning tips that will ensure your event goes off without a hitch.

Tip #1: Prioritize Communication

There are a lot of people involved with the planning, whether vendors, entertainers or even the guests. Everyone needs to stay on the same page. This requires prioritizing communication. Keep the information clear and consistent and follow up to confirm all involved parties understand their role in the overall picture.

Tip #2: Cater to Your Audience

Making an event memorable is all about ensuring each detail specifically addresses the hopes and expectations of your audience. This is true whether you are planning a Galapagos cruise for a big family reunion or you are organizing an awareness walk. Venues should be chosen according to the impression you want to create and the people you want to attract, and the remaining details should support your overall goals.

Tip #3: Avoid Decisions Based on Bulk Reasoning

In an effort to stretch the planning budget, many event planners will make decisions concerning food, decor or favors based on what can be purchased in bulk. This kind of decision severely limits the creativity of the event. Buying in bulk is not always cheaper, and if you are trying to earn new business or score a partnership from your event, customized options go a long way. Avoid unnecessary expenses to put extra money toward unique food items or welcome gifts.

Tip #4: Don’t Fudge the Budget

You should have your event budget well laid out before you start your planning. This must be in place as it is the foundation of what will be possible for the occasion. If you keep making exceptions, you will find yourself in murky waters, especially if the company is picking up the tab. Stick to your budget by arranging the different elements according to priority. For example, the venue and the catering are typically more important than hiring a valet parking attendant. Guestimate costs for the event when you are first establishing a budget to prevent sticker shock when the planning gets underway.

Tip #5: Develop an Event Timeline

As you begin planning an event, craft a timeline for what needs to occur in order to pull off the event without any surprises. Include things like paying the venue deposit and ordering the invitations all the way down to a schedule for the day of the event. There will be a lot of traffic on the day of the event, and you don’t want vendors and staff getting in each other’s way. Set up a timeline for each party involved and submit copies to each of these individuals. Have them confirm your timeline or adjust the schedule as needed.

Tip #6: Create a Confirmation Checklist

As the event gets closer, things will start to move at a whirlwind pace. Don’t get lost in the moment and forget what needs to be done. Develop a confirmation checklist that includes all of the details for the event and the contacts in charge of these elements. Confirm everything from payment methods, delivery or arrival times and departure or clean-up schedules.

Tip #7: Don’t Delay on Invitations

Everyone’s lives are full of obligations and responsibilities, so sending out an invitation at the last minute will lead to few people making it to your event. Invitations should be one of the first things you work on, especially if you need RSVP information for catering and venue arrangements. In addition to sending out a formal invitation, consider adding a digital element that will automatically put the event on their digital calendar.

Event planning doesn’t have to be stressful and chaotic. Use these tips to organize your event and keep both yourself and the guests happy.

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

チームが一致団結して開発する日々の様子を、メンバーの立場から体験できるボードゲームを作りました(作っています)。以下のような和やかなやり取りをしながら進めるゲームです(予定です)。

「ちょっとこのタスク誰がやるのよ」
「いまリファクタリングしとかないとヤバ…」
「依頼してよかったですよ、ありがとうございます。次のも楽勝ですよね？」
「品質に問題があります」
「これできる人いたっけ？」
「グロース！！」
「おれiOSしかやりたくないなあ」
「楽しく仕事しましょうね、楽しくね」

4人1グループで、90分～2時間くらいかけて遊ぶゲームになりそうです。ゲーム自体はasobannというオンラインのボードゲームサービスを利用して遊ぶ予定です。

各プレイヤーは、開発チームのメンバーとして、自分のスキルを表す手札を持っています。ボード上にはタスクカードが並んでおり、自分のスキルでこなせるタスクを選び案件として実施すると、開発が進みます。開発を進めるとチームは3種類の報酬を得ます。

• Growth - プロダクトや会社の成長と売上増
• Impact - ユーザーや社会に対する貢献
• Productivity - プロセス改善やリファクタリングによる作業効率化

メンバーは一人ひとり異なった「勝利条件」を持っています。あるメンバーはひたすら成長にコミットしており、別のメンバーは自分のスキルにしか興味がなく、また別のメンバーはプロダクトがバランスよく成長しながら社会に貢献することをモチベーションにしている。自分の勝利条件に近づくようにタスクを選んで案件を実施ししましょう。

しかし1人でできる仕事は僅かです。スポンサーの要求はどんどん高まっていき、チームが協力して開発しなくてはクビになってしまいます。チームとして案件を成功させながら、いかにして個々人の勝利条件を追求するのか。チームとしてのコミュニケーション、作戦、そして駆け引きがこのゲームの醍醐味です(予定)。

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

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

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

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

プロダクト開発に向き合う組織を作る上でのポイントはなにか。

エンジニアとして新規事業立ち上げに参加した私が、職種をPdMに変えながら事業のグロースに試行錯誤しながら取り組むさまを、事業計画の立て方や、組織計画の立て方の側面に特に着目して話します。

新規事業を1から立ち上げ、現在グロースフェーズを迎えている経験を元に、失敗と成功を交えて経験を伝えられたらと思っております。

歴史を振り返る形でお話させていただき、その時々の判断軸や、不確実性に向き合うために必要な振り返るということについて、そのためのアジャイルの考え方の取り入れ方などお話させていただきたいです。

良いプロダクトを作るために、なんで良い組織を作らないといけないのかを再確認したいです。

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

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

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

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

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

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

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

続きはXP祭りで。

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

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

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

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

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

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

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

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

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

この春、約20年ぶりに転職したQAエンジニアです。

「最近は、QAエンジニアの求人増えたよね！」というお話も聞きますが、

実際のところ、QAエンジニアは転職しやすいのか？

私の転職の経緯を、モヤモヤ期　→　踏み出し期　→　面接期　→　内定ゲット後　→　転職後と、フェーズごとにご紹介します。

モヤモヤ期

この時期は、転職したいと思っているが、まだ覚悟ができていない時期です。
期間としては、約3年ほどです。
・どんな人と会って、何を教えてもらったか？
・どんな準備をしていたか？
・その準備を日々の業務に、どうつなげて、効率化していたか？
・手近な転職活動で心折れたこと

踏み出し期

・転職サイトに登録しますが、すぐには動けなかった訳
・思い切って、エージェントと話して教えてもらったこと
・何を準備したか？

面接期

・最初の２か月は、準備をして面接に挑んだものの、なかなか最終面接にすすめなかったこと
・２か月目には心が折れて、最終面接に進むことになっていた１社に決めようかと心が揺れていたこと
・年末年始（2か月目と3か月目の間）にインターバルができ、本当にやりたいこと、行きたいところを考え直したこと
・最後の最後（4か月目）で、迷ったけど、入社の決め手にしたこと
・書類審査突破、面接突破、内定獲得のリアルな割合

内定ゲット後の日々

転職後

・QAチーム立ち上げで、QMファンネルをつかったり
・開発チームとの期待値をQMファンネルで分析することで、すり合わせていく
・ふりかえって、あの時にこうしておけば良かったと思うこと

大日本印刷株式会社でアジャイル推進活動をしている6年目のインフラエンジニアがボードゲームが趣味と言うだけでアジャイル、スクラムをテーマにしたボードゲームを作ってみました。
なぜボードゲームを作ったのか、突然のニュースリリースからの反響、体験会。。。そこで何を感じ、何を学んだのかお話しようと思います。

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

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

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

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

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

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

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

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

現代においては

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

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

For XP祭り2022

本講演は2022年5月21日（土）に「スクラムフェス新潟」で初演されたものです。

「品質文化」というQA界隈で話題になっているトピックについて考察したものです。とても抽象的でシンドイ思考が必要であり、皆さんとも議論したいと思い、再演である（新作でない！）との謗りを承知でプロポーザルを提出します。

Kent Beckほか（2015）『エクストリームプログラミング』（オーム社）には、XPの原則のひとつに「品質」がうたわれています。XP実践者の皆さんの考え方にはすでに「品質」が根付いているということだと推察します。また、なんとなくですが一般的に日本で・日本語で考えられている「品質」と、XPで原則とされる「品質」の間には、意味に差があるかもしれない……という気もしています。

ぼくが「品質文化」について一生懸命考えていることが、XP実践者の皆さんの目からどう見えているか、またより発展させていくためにはどうしたらいいか、一緒に考えてくださるとうれしいです。

以下、初演時の概要説明を記載します。

▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽▲▽

『品質文化試論』というQiitaの記事を2021年12月に公開しました。JaSST東海'21に合わせて公開したわけですが、ありがたいことに、様々なコメントを界隈で貰うことができました。

コメントを眺めていると、一人ひとりの問題意識とか立ち位置（ポジション）によって『品質文化試論』の受け取られ方は異なっているのではないかと思うようになってきました。そこで今回は、改めてMark（ぼく）が何を考えてあの文章を書くに至ったのかをプレゼンしようと思います。

『品質文化試論』で語ったことは、端的に表現すれば「品質文化は組織戦略に逆らったものにはならない」でした。その結論に至るまで、大きく2つの議論をしています。

ひとつめは、縦の階層構造です。「品質文化は組織文化に従う（逆は難しい）」のではないかと提示しています。

もうひとつは、横並びの構造と捉えて「戦略と文化は組織の両輪」と考えました。

「品質文化」というものを真正面から考えるのはシンドイのでこういう手法を取ったわけですが、結果的には「品質戦略」という言葉を引き出すに至りました。魅惑的な言葉が増えてしまって、正直なところ頭を抱えています。ただ、こうした構造を表現したことで、特に「1人目のQAエンジニア」へのメッセージを発することになったかなと思っています。

さてさて、こういうちょっと変わった角度から「品質文化」を考えるに至った源泉はなんでしょうか。これも大きく2つあると思っています。

まずはMBA（経営学修士）で学んだ知識があります。特にヒト系科目と呼ばれる「人材マネジメント」や戦略系科目「経営戦略」あたりで学んだことがベースになっています。エンジニアでMBAに通う人はまだまだごく少なく、特にQAエンジニアでいえば、国内では会ったことがありません。その意味では、少々レアな経験を積んでいると思います。

もうひとつ、5年前から海外カンファレンスや洋書を通じた学びを続けており、現在は『LEADING QUALITY』という本を翻訳しています。この本はCレベルのエグゼクティブ（たとえばCEO）が品質を重要な経営課題と認識して取り組むことの価値と、いかに推進するか、その事例が書かれています。どちらかというと技術書っぽくない、経営陣向けの「ビジネス書」に近い感覚の独特な本ですが、品質エンジニア目線で経営陣をどう説得するかを学びたい方にもおすすめできる著作です（翻訳されたら買ってください、ぜひ）。

ところで、品質関係の書籍というとどんなものを想像するでしょうか。「品質とは何か」「品質をいかに測るか」を説明した書籍や規格類が、やはり多いかなとぼくは思います。その一方で「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説した信頼できる情報源は、ほぼ皆無だとも。「品質文化」という言葉はいかようにも解釈できる危険な言葉で、避ける人もいますが、それが危険なまま放置され続けてきたこともまた、注目に値するのではないでしょうか。人類の進化に火が多大な貢献をもたらしたことを考え合わせてもいいかもしれません（プロジェクトを炎上させたくないぼくたちに火の話題はタブーかもしれませんけど）。

国内では比較的レアな品質 x MBAというコラボレーション、そして『LEADING QUALITY』をはじめ、海外から学んだ知見があって『品質文化試論』につながっているのです。

そして『品質文化試論』は「試論」にすぎません。ぼくはこれを『品質文化論』に進化させたいと考えています。たぶん、数年かけて。

今回の登壇はその長い道のりの第2歩になるかもしれません。

参加者の皆さんとの対話の中で（決して保証はできませんが）広く共有できる「なにか」があればいいなと思っています。楽しいセッションにいたしましょう。長い旅路の第2歩目を、ぜひご一緒しませんか。

某エンタープライズ企業におけるスクラムマスター育成の取り組みを紹介します。スクラムマスター育成の事例は多々あると思いますが、今回は新人のエンジニアがスクラムマスターとして活躍するまで３ヶ月を追ったレポートです。スクラムマスターの人選や育成で悩んている方にとって有益な情報となることを願っております。

“チームに張り付いてサポートのできるスクラムマスター欲しい”

そんな課題がきっかけでこの取り組みが始まりました。

アジャイル開発においてトップクラスの有識者がスクラムコーチ兼スクラムマスターとしてチームを支援し、アジャイル開発のプロセスやエンジニアリングは定着していました。しかし多忙のためチームにずっと寄り添うことは難しい状況でした。

アジャイル開発の基本はできているので、それを維持向上するために、チームに張り付いて細いサポートができるスクラムマスターが欲しい。。しかし開発チームは開発に拘りのあるメンバーばかりで、誰もスクラムマスターをやりたがらない、、。そこで候補に挙がったのはテスト打鍵とプロダクトオーナーのお手伝いしか経験のない新人のエンジニアでした。スクラムの経験も開発チームに劣ります。

“新人でもスクラムマスターが務まるのか？”

スクラムマスターの業務は様々ですが、役割りはチームを支え、守り、パフォーマンスを発揮できる状態を保つことだと私たちは考えました。そして、チームのサポート業務に特化したスクラムマスターを育成する３ヶ月の取り組みがスタートしました。

セッションにはスクラムマスター本人にも登壇して頂く予定です。

本取り組みは株式会社テクノロジックアートの長瀬 嘉秀 氏に監修いただいております。その他、関係者の方々に御礼申し上げます。

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

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

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

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

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

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

例えば‥

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

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

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

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

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

社内のagileコミュニティ事例を仲間とともにご紹介します。

「創作活動がもっと楽しくなる場所を創る」という理念のもとピクシブ株式会社では55のスモールチーム共同で、イラスト、小説、3Dアバター、ECなど16におよぶ様々な分野の事業を開発・運営しています。

社内では30ほどの技術コミュニティがあり、Slack上でtプレフィックスをつけて活動しています。その一角に、高アジリティな活動知見を交換することをテーマとする「#t-agile」があり、隔週ペースでミートアップを開催しています。

このセッションでは、このコミュニティの立ち上がり、ミートアップでのおもしろ話題、活動から見出したアジリティの高いチームで共通的にある文化について紹介します。

みなさんの会社での社内コミュニティつくりの一助になればと思います。