2003年にXPに出会ったことをきっかけに、最も日本らしいIT企業グループの中でありながら、アジャイル開発に強い思い入れを持ち現場実践してきた私の経験をお話します。

DXの波が押し寄せ、ようやく日本でもアジャイル開発の重要性が認識され、先進的な企業のDX・アジャイル開発組織が注目を集めています。しかし、多くのITエンジニアが置かれた現実は、いまだにアジャイル開発の導入検討さえできていない現場のほうが多い。旧態依然とした日本型ITの壁は高く、"貴重な技術者"の成長の機会をも奪っています。

私がSIの受託開発に関わるようになったのは約20年前、そこで繰り広げられているソフトウェア開発？に大きな違和感を覚えました。SIで主流の開発のやり方はソフトウェアには合わない、役に立つソフトウェアにはもっと実験と試行錯誤、なにより元気なチームが必要なのに。自分自身このままでは何が面白くてコードを書いているのかわからないと思いました。そこで、技術者として・チームとしてモチベーションを維持してゆくには、新しい技術を積極的に取り入れやすいアジャイル開発が必要と考え、仲間と現場で実践することにこだわってきました。

この数年間で、SIの受託開発でもアジャイル案件が増えました。受託開発の枠組みの中でも、以前よりも挑戦的に生き生きと働くチームが増えてきたのは喜ばしいことです。一方で、誤った認識を元にアジャイル風にプロジェクトが進められたり、十分な訓練を受けていないことが原因で、解き放たれるどころか、さらに深く術中に嵌りより過酷な状況に追い込まれる仲間が出てきているのも事実です。このような背景から、全社的に正しい知識を広げるための活動や、SEの方々へ日本型受託アジャイルの秘訣を共有させていただいています。本セッションでは、17年前にXPに取り組み始めた経緯、数々の失敗と工夫、現在の全社的な普及活動やユニークなアジャイリストの育成についてお話します。

これからアジャイル開発に取り組む方々、とくに情シス部門やSIベンダーなどで、日本型ITの中で奮闘されているみなさんと、私の経験を共有できれば幸いです。

こんなことは有りませんか？

•  何度もコードレビューで指摘しているのに、できるようにならなくてうんざりだ
• プルリクに20個以上もコメントを付けている

この問題は、ペアプロをやることで素早く解決できるんです。

• どうしてペアプロが良いのか
• プラスで工夫すると良いこと

をお伝えします。

V字開発では、要件定義、設計、テスト、開発とフェーズが分かれており、後工程で仕様の間違いがあると大きく工程を後戻りしないといけなかったり、仕様 vs バグとの仁義なき戦いになることもあります。

そんな、開発プロセスを改善するためにモブ設計を取り入れた試みをお話しいたします。

アジャイルはチームスポーツであると言われます。が、サッカーやバスケットボールなどのようにチームが「チーム」として活動する方法は、ソフトウェア開発の世界ではあまり知られていません。

本セッションでは、オンラインホワイトボードツールである「miro」を使ってチームでの作業を体感し、Swarmingの理論と実践を学びます。

チームでの参加も可。おひとりさまでも、当日別の参加者とチームを組んでいただくので問題なくご参加いただけます。

参加者の方は、事前にmiroのユーザー登録を済ませておいてください。

https://miro.com/app/dashboard/

XP最初のプロジェクトは当時Chrysler社で行われたC3プロジェクトというレガシーシステムのリプレイスプロジェクトでした。この時の中心人物の一人がケントベック氏です。

彼がXPの着想を得たのはオレゴン大学在学中に出会ったアレグザンダー氏の提唱する「パタン・ランゲージ」だと言われています。

時は流れ、2020年の今、ナレッジシェアの視点や、プロジェクトの成功要因分析などの視点でパタン・ランゲージはにわかに再度盛り上がりを見せています。今回はXP祭りだからこそ、XPの起源とも言われているパタン・ランゲージをアレグザンダーとともに数々のプロジェクトで活動した中埜博先生の解説のもと、スクラムマスターの皆さんのお悩みを紐解く形で"パタン・ランゲージ/15の特性"を用いて解決します。

エクストリーム・プログラミング（XP: eXtreme Programming）の具体的な実践のうち、「顧客の実践」である「ストーリーの作成」について、体験型のワークをオンラインで行います。

今回は、ユーザーストーリーマッピングで採用されているストーリーの作成の進め方について概説した後、ステップバイステップでストーリーを作成、および大きすぎるストーリーの分割を行います。ストーリーの作成ワークショップを通して、会話と議論、対話の違いも体験いただきます。

これからアジャイルやスクラム、XPを始められる方、プロダクトバックログの作成やユーザーストーリーの作成、分割に課題感をお持ちの方に、ご参加いただけたら嬉しいです。

■事前準備のお願い

本ワークでは、Zoomのブレイクアウトルーム機能およびMiroを使用したグループディスカッションを行います。参加環境としてヘッドセットや外付けマイクの使用を推奨します。事前に以下のそれぞれにアクセスいただき、表示可能かご確認いただきますようお願いいたします。

* Zoomのテストミーティング（ https://zoom.us/test/ ）
* Miro の接続確認用ボード（ https://miro.com/app/board/o9J_kp6_XFg=/ ）

息が止まるほど、熱い "モブ・リファクタリング" します!!

品川アジャイルでは、毎週水曜日に集まって勉強会をしています。
リモートモブでリファクタリング本の一章の写経を繰り返したり、
リファクタリングやテストツールをみんなで試したりしています。

今回は、その中で一番楽しい、リモートモブリファクタリングを
皆さんを交えて体験していきます。

TDDのワークショップと違い、機能の追加をせず、現状のコードを
「グリーンを維持したままで」手直ししていきます。
もしレッドになったら、息を止めてグリーンに戻します。
(「イキトメ」メソッド)

前半は、Codespaces を使ったモブプログラミング & リファクタリングの演舞。
後半は、飛び入り参加の方を交えて一緒に体験するワークショップとなります。

モブでやりますので、ドライバーは周りの指示を受けて入力するだけ。
プログラミングに自信がなくても、キーボードが打てればご参加可能です。
コードを継続的にメンテナンス可能にする、リファクタリングの世界へようこそ！

※VSCode と Live Share Extention Packコンポーネントを事前にインストールしておいていただけるとスムーズです。

「なんで？」「どうして？」というという問いは時に凶器になります。

「なんで（私が言った通りにやらないんだ）？」
「どうして（そんな風にしてしまったんだ）？」

そして時に問いという形で指示や命令をすることにもなります。

「こないだ説明しませんでしたっけ？（説明した通りにちゃんとやってくださいよ）」
「これでどうですか？（もう何回も直してるんで、そろそろOK出してくださいよ）」

問いと上手にお付き合いするためには、問いを立てる対象の観察が必要不可欠です。
同時に自分自身を観察する（ふりかえる）という必要もあるかもしれません。

ある一場面を観察したとき、いままで経験してきた物語が違う人たちの間で、その場面をどう捉えるか？
さまざまなコンテキストの違いによる物語の幅にフォーカスすることで、よりよいコミュニケーションや問題解決ができるかもしれません。

「観察」を体験し、「物語を捉える問い」を考えることで、よりよい未来を創るファシリテーションの入り口に立ってみましょう。

※テストエンジニア向け（WACATE2019冬）に実施したワークショップをベースに、XP祭り向けに改変して実施します。

目標を立てる場面は職場でもプライベートでもあると思います。

その立てた目標が

• 気が乗らなくて、立てただけになっている
• 何かが違うんだけど、立てたからやらなきゃ
• 目標のために何をすればいいのかわからない

なんて状況になることってありませんか？ 上司や先生や親に「立てろ」と言われたときは特にお座なりな目標を出すことが目的の目標になってしまいがちです。自分にとって大事なものにつながる目標でなければ、アクションを取るのは精神的に苦痛があります。まずはその目標を自分事にしてみましょう。自分事にな利用がないなら別の目標にしましょう。そのために目標を自分視点で精査するワークショップを行います。

準備するもの

• 他の参加者に見られても良い、自分の目標 *他者のものは今回のワークの役に立ちません。
• テキストエディタ ※参加者の人数によってはMuralなどのオンラインツールに切り換える場合があります。
• 大事だと思ってた目標がどうでも良かったと発覚しても発狂しない覚悟。

毎年1月の某イベントのOSTでやってるヤツです。

2020年9月9日刊行予定のSCRUMMASTER THE BOOK。この本を、コミュニティメンバー9名ほどで翻訳してきました。基本的にリモートでのモブ作業（3名以上集まるタイミングで作業を進めていく）スタイルで、2019年4月から1年以上かけて翻訳を進めてきました。

お互いに知り合いではあるが一緒に仕事をしたことはほとんどない、コミュニティベースのゆるくつながった関係の中で、モブ作業をどう進めてきたかの実践例をみなさんにお届けします。

偉大な人が「Do n't just Do Agile、Be Agile」と言いました。

その言葉を胸に
テスターは、なかなか変われないチームで、いくつかのプラクティスを密かに実践しました。

実践したモノは厳密にはプラクティスではないのかもしれませんが、

テスターが現場にあわせてどのようにプラクティスを実践したかをお話いたします。

また、本や人から学んだプラクティスをどう実践するか、「思考の整理学」の醗酵法をヒントに考えた「忍ぶアジャイル」というよくわからないものを説明します。

※アジャイルQAのような話はしません。モブやペア、探索的テストをした話になります。

この物語のはじまりは 2001年 アメリカ ユタ州 ソルトレイクシティ

ではなく、1996年 クライスラー社の給与計算プロジェクト

でもなく、1986年 ハーバードビジネスレビュー誌に掲載されたある論文

でもありません。

今回の物語のはじまりは 1776年のイギリス バーミンガム。その後の世界を一変させることとなったある発明に遡ります。

本講演では、産業革命から生産性革命、マネジメント革命を経て現在に至る近現代の歴史を紐解き、「アジャイル」が生まれてきた必然について検証します。

「どうしよう、メンバーが心を開いてくれないー」。
　
　スクラムの3本柱のひとつに据えられている「透明性」。
　完成の定義を明確にしたり、プロセスをカンバンで見える化したり、デイリースクラムで課題を共有したり。透明性を担保するためにチームは様々な取り組みを行います。
　しかし、現実を現実のまま受け止め、あまつさえそれを他人に共有する行為には「うまくいっていないことも伝えてよいのだ」という心理的安全性が場に形成されている必要があります。私の現場でも、透明性を高めていくことに抵抗を感じるメンバーが少なからずいました。
　このセッションでは、いかにしてチームの心理的安全性を高め、結果としてチームの透明性を高めていくのかを実体験を交えてお伝えします。

◆ふりかえりカードとは

ふりかえりカード（https://booth.pm/ja/items/2119371）は、ふりかえりを手助けしてくれる「問い」を集めたカードです。
ふりかえりカードを使って、「ふりかえりを拡張する体験」をワークショップ形式でお届けいたします。

こんな人にお薦めです。

• ふりかえりの進行に悩んでいる方
• ふりかえりで、メンバから情報を引き出すための「問い」に苦手意識を感じている方
• より深い思考をチーム内で醸成したい方
• 問いを深めたり、ふりかえりの「なぜ」に立ち返りたい方

◆対象者

• ふりかえりの進行に悩んでいる方
• ふりかえりで、メンバから情報を引き出すための「問い」に苦手意識を感じている方
• より深い思考をチーム内で醸成したい方 ・問いを深めたり、ふりかえりの「なぜ」に立ち返りたい方

◆イベントの進行

• ふりかえりBoost・ふりかえりカードの説明
• アイスブレイク
• ふりかえりカードを使ってみよう
  • 自分のプロジェクトについてふりかえり
  • 自分自身についてふりかえり
• ふりかえりの共有
• 学びの共有・ダイアログ・フィードバックタイム
  • いつものふりかえりとの違いは？
  • どの問いを持って帰って使いたいですか？
  • 自分で問いをつくるなら、どんな問いを作りますか？

 ◆ふりかえりBoostとは

ふりかえりをより楽しいものにしたい、マンネリの壁を破りたいという人のための、ふりかえりを加速（Boost）するための会です。 みなさんのふりかえりを以下のように拡張します。

• ふりかえりをより楽しめる
• ふりかえりをより深く知れる
• ふりかえりを自身で追及できるようになる(守破離の守→破)

私たちは、個人とチーム、そして組織や顧客のニーズを満たすためにアジャイル開発をしています。
しかし現実には、口には出さなくとも、各自のニーズが衝突することは少なくありません。

• 同僚のコードが酷い!
• QAエンジニアの指摘が細かすぎる!
• 部長はアジャイル開発を何も分かっていない!
• なんて不勉強なプロダクトオーナーだ!
• 顧客のスケジュールが厳しすぎる!
  
  

『エクストリームプログラミング』の参考文献に、NVCという、相互を尊重し、お互いのニーズを満たすためのコミュニケーション技法があります。

今回は、NVCの説明や簡単なワークを通して、個人、チーム、組織、顧客との対立を解消し、より良い関係を結ぶために私たちができることを一緒に考えたいと思います。

　溶けるんです。粒度が小さいからです。水と油では無いからこそ、小さく持続可能なペースで始めるからこそ色々な環境に、チームに溶け込むのではないでしょうか。

要件定義からC/Oまで４年。生粋のWFプロジェクト(海外開発)において、XPを少しずつ注いでいった結果・・私にできた…チームの感動ストーリーをお話しします。

そして気付いた従来の価値を認めながらも、重きを置きたい4つの価値。

また、インセプションデッキ、デイリーミーティング、計画ゲーム、受入基準とやらないことリスト、Fail Fast、ニコニコカレンダー、WBS-kanban、1on1ふりかえり、そしてユーザーファーストを取り入れ、ピラミッド構造を分解していったステップが、どんな場所でも適応できると信じています。

2020/9/20 updated slide link
https://www.slideshare.net/TakuHasegawa4/sp-xp2020

最近、アジャイルを一言で表すならば、”群れる”だと思います。

アジャイルではSwarmingという用語で語られており、何かに群がっている様を示しています。アジャイルの文脈では、特定粒度のプロダクトなり機能を群がって改善を進める様子を示す。モブプロなどもその一種だと思います。

“群れる”の本質は、何かの対象に対して集団が相互作用（協力）しながらも自然と同じ方向を向いて、前に進んでいるということであり、個々がそのメリットを体系的に理解していることが大事です。本能的に「ひとりで進むよりも皆と協力して”群れ"ながら進んだ方が死なない」と判断できることである。

生物学的に見ても、強い敵が目の前に現れたとき単独で行動するよりも、統一された集団行動によって、1対1では敵わない敵に勝てるかもしれないということを本能的に知っているのと同じです。 アジャイル周辺のプラクティスの多くは、群れて作ることでうまく開発できることを体系的に知らせる仕組みが多くあると思います。 それは昨今のリモートの時代でも変わらない。 逆にリモートになってチームの状況が微塵も変わらないのであれば、それはアジャイル開発をしていない。もしくはチームメンバーが見えていない。

物理的な距離によるコミュニケーションの差異はどこかしらででていると思います。 今回は、そもそもの"群れる"という観点でアジャイルを見てみるのと、リモートチーム時代にどうやって変化し対応していったかを事例を交えてお話できればと思います。

5年前の XP Day Vietnam 2015 で、"Is XP still extreme?" という講演を行いました。
XPが生まれて20年経過し、XPが生まれた頃のエクストリームさはどうなった？という講演でした。
それからさらに5年経ちました。XPは今でもExtremeでしょうか？

開発メンバーのときは、目の前のストーリーに注目して、1人で開発をリードしていた私が、スクラムマスターをやり始めてチームがポジティブに仕事に取り組んでくれるようになったり、チームの意見を引き出したりすることができるようになった話を事例と考え方を交えて掛け合い形式でお伝えします。

近年、DevOpsの原則を機械学習 (ML) システムの運用にも適用した、MLOpsが注目されています。
 
MLシステムでは、従来のソフトウェア開発でも管理が必要なアプリケーションコードに加え、データとモデルも合わせて管理する必要があります。システムの構成要素が多く、通常のソフトウェア開発に加えて特有の難しさがあり、技術的負債が蓄積しやすいことが知られています。
 
ストックマークでは新製品のMLシステム部分のプロトタイプ・商用化・運用を1人のMLエンジニアで回していましたが、技術的負債の蓄積により、アジリティが保てなくなってしまっていました。
 
本セッションでは、SREの自分が、どのようにMLエンジニアと協力して、MLOpsの実現に向けて奮闘したか、実際に向き合った課題、解決策、失敗例などを交えて紹介します。
 
MLOpsで取り組むべき課題は各組織や製品により千差万別ですが、本セッションで紹介する内容がご自身のシステム運用の参考になれば幸いです。

ローンチからマザーズへ上場し、HRTechをリードするまでになった7年は、カオナビにとってカイゼンの歴史でもありました。

外注開発から、内製化へ。
職能型組織から、マトリクス型組織へ。
レガシーな技術から、モダンな技術へ。
従来型の開発プロセスから、アジャイルな開発へ。

開発組織がない状態から、直面した様々な課題をどう乗り越えていったのか、
そしてその先の未来を見据えた取り組みについてもお話します。

討論リーダらは、DX時代のオープンイノベーションに役立つデザイン思考やビジネス・価値デザインからアジャイル開発、さらには堅実なソフトウェア製品・サービスの開発・保守の方法論までを系統立てた枠組みとしてSE4BS（Software Engineering for Business and Society）の構築を進めています [1][2]。SE4BSは、新しい時代がより良いものとなるよう社会やビジネスをデザインし、ソフトウェアシステムとして構築するための新たなエンジニアリング体系を目指しているため、製品やサービスに対して「人が感じる魅力」という人の感性領域にまでデザインしていきます。つまり「魅力創造から継続的構築までの一連の体系」を実現するものなのです。 

本セッションでは、SE4BSの全体的な説明に加えて、DX時代のアジャイル開発における活用や有用性の解説、ならびに、価値デザインや価値分析のワークショップを通じてSE4BSに基づく魅力的なモノ・コト創造を体験いただきます。

[1] DX時代の新たなソフトウェア工学（Software Engineering for Business and Society: SE4BS）に向けた枠組みと価値駆動プロセスの提案 https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=203488&item_no=1&page_id=13&block_id=8

[2] セミナー: 社会やビジネスに新たな価値を生み出すソフトウェア工学（SE4BS）https://bpstudy.connpass.com/event/178517/presentation/

[3] XP祭り2019：ビジネスと社会のためのソフトウェア工学に向けて – 未来のソフトウェアエンジニアリングを探るワークショップ – http://xpjug.com/xp2019-session-f6/

■討論リーダ

鷲崎弘宜 (早稲田大学 / 国立情報学研究所 / システム情報 / エクスモーション)、萩本順三 (匠BusinessPlace)、谷口真也（セイコーエプソン）、関満徳 (グロース・アーキテクチャ＆チームス)、濱井和夫（NTTコムウェア／IIBA日本支部）

お祭りと聞くと、ふつふつと血が騒ぎます。お祭りといえばモブです！モブでパターンを書きましょう！！ 緊急事態宣言になり、SNSやコミュニティにも顔を出したところ、パターンやパターンランゲージで盛り上がっていました。 みなさんと一緒に モブでパターンやパターンランゲージとして、Online Communication Patternsを書いています。 今回のセッションでも、モブでパターンやパターンランゲージを書いたり、修正したりします。 パターンの書き方からその思想、さらには、これからの社会からお笑いまで、楽しく雑談しながら、パターンを書きませんか？

scrapbox上で行いますので、パターンを書くためには、Scrapboxへのアカウント登録が必要です。編集できるURLをお渡しします。参観するだけでしたら、アカウント登録は必要ありません。

アジャイルの近接領域であるUXデザインにおける、利用状況の把握や分析に焦点をあてます。SCAT（Steps for Coding and Theorization）という質的データ分析法をベースとして、利用者の声をどのように分析しているかを明示することにより、ソフトウェア開発の分析・設計に有用であると考えられる、言葉の分析スキルの向上をねらいます。

* 途中参加は可能ですが、ワークショップへの参加ではなく見学のみになる可能性があります。
* 人数制限はありませんが、ツールの都合上人数を把握したいのでDiscordの #ワークショップ受付チャンネル で受付をお願いします

このセッションはプロダクトマネジメントのエッセンスを学ぶオンラインワークショップです。

プロダクトマネジメントの目標は「独占」を作ることだと私は考えます。この独占とは、あまりに効果的に顧客の悩みを解決するために、顧客に選ばれて独走状態になった状態を指します。

みなさんがよく知る独走状態となった大ヒットプロダクトをふりかえりながら、ステップバイステップで自分のプロダクトの強みを明らかにしていこうとおもいます。「良い商品なのに売れない、強みがあるのにお客様に喜んでもらえない」 という悩みを持った方に効果的です。

チームで仕事をするうえで必ず起きるのが価値観や意見の相違。また自分にとっては当たり前でも相手にとって違い、逆も然りです。また伝えたつもりが伝わっていなかったり、、現場では気づかずうちにも様々なすれ違いが生じています。そういったすれ違いによってアウトプットにズレが生じたり、ストレスになることも起きます。 今回は1on1を外部から行い、チームをサポートするわたしの視点で、現場でどのようなすれ違いが起こっているかの具体例を挙げたうえで、どのように現場の人と解消していったかをご紹介します。

ウォーターフォールの開発から、アジャイル開発に切り替えてみたものの課題が多く発生している、また、チームの自己組織化もなかなか進まない。

そのような悩みを抱えている方も多いのではないでしょうか？

本セミナーでは、そんな悩みを少しでも改善すべく、実際に私たちが試行錯誤してビュッフェできた事例を基に、

スクラムにおけるチームビルディングはどうしていったらよいかについてご紹介いたします。

「ふりかえり」を実施したことのない現場はないのではないか、というくらい「ふりかえり」という言葉は浸透してきました。
一方で、効果的にふりかえりができていると自信を持っていえる現場はそれほど多くないのではないでしょうか。
やることになっているから、スクラムガイドに書いてあったから…そのWhyを考えずに漫然と「ふりかえり」を行っている。結果として思ったような成果が得られない…。
そういった状況を打破するには、ふりかえりのWhyを理解し、効果的な実施方法(How)を学ぶ必要があります。
2020年度、ナビタイムジャパンでは新入社員向けに丸一日かけて「ふりかえり」の研修を行いました。これは、キャリアのスタート地点から「なぜふりかえりか」「どうふりかえるか」を身に着けてほしかったからです。
まっさらな状態の新人にふりかえりをインストールするため、どのような工夫を行ったのか紹介します。みなさんがふりかえり文化を組織に根付かせるためのヒントになれば幸いです。

月に1回のペースで開催している読書会をXP祭りで行います。書籍を読みながら、読んだことをネタにしておしゃべりします。気軽にのぞきに来てください。

毎年恒例となりつつある「ビブリオバトル」今年も開催します。

例年XPと直接関係のなさそうな本がチャンプ本に選出されています。

きっと、今まで知らなかった本との出会いがあります。

バトラー（発表者）も募集中です。https://xpjug.connpass.com/event/182774/ からお申し込みください。

弊社では以前より私たちを含めたいくつかのチームでスクラム開発を取り入れていますが、
正しくスクラムを実践していない「なんちゃってスクラム」状態となっていることが問題視されていました。
この状況から脱却すべく、スクラムへの理解と推進力を高めるための活動として、
今年度よりチーム内で1人ずつ認定スクラムマスター(CSM)と認定スクラムデベロッパー(CSD)の認定資格を受講する取り組みを始めました。
今回の発表では、最初の1チーム目として選ばれた私たちの体験記を、
受講後に感じた個人・組織の変化や得た学び、今後の目標などを交えてご報告します。

うまくスクラムが実践できずに悩んでいらっしゃる方や、
ご自身の組織にスクラムを広めたいと検討している方のヒントの一つになれば嬉しいです！