実に16年の時が流れました。私がXP祭りで話をしてから、いや人前でまとまった話をするようになってからです。一見どうしようもないように見える状況でも、自分の踏み出す一歩でほのかにも変わり始める可能性がある。そんな熱に浮かされたような語りから、ソフトウェア開発、プロダクト開発から事業開発、そして組織変革へと、これまで活動を続けてきました。

この数年は、なぜ組織の営みが上手くいかないのか、という問いに向き合ってきています。何が組織の次へと向かう動きを阻んでいるのか。堅牢なはずの開発や最適化された事業、組織運営のどこにその要因があるのか。

問題は何か、その正体を捉えるためには深く深く掘り進めていく必要があります。それは、さながら「探検」のようです。組織という洞窟を降り進んでいった「底」に何があるのか。 “倒すべき問題” とは何だったのか？ もし、そこに倒すべき対象などなかったとき、一体どうするのか？

もし、私が20年前にXPに出会わず、その後アジャイルとともになければ、ここまで続けられなかっただろうと思います。目の前のソフトウェア開発をもうちょっとどうにかしたいと思い、会社がコミュニティのようであればと願い、わけもわからず動き回れたのは僅かに得られた手がかりと、それをともにしようとする同朋たちと出会えたからです。

長く続いた「探検」は大きく一周してここに帰ってきました。どれだけ「底」を掘り下げても、自分たちの「外」にのみ求めたとしても、迷い続けることになりかねない。道は、既に16年も前に見つけていました。1週間イテレーションで言えば832回。この時を経て、自分のジャーニーについてもう一度語ろうと思います。この道はきっとどこかで繋がっているはずだから。

世の中にイノベーションを起こす原動力の１つであるスタートアップ。スタートアップで効果的に機能するアジャイル、リーンスタートアップ、デザインシンキングなどのプラクティスに関する研究も盛んに行われ近年では数十の論文が出揃いました。

自分はスタートアップに身を置いてこなかったのもあり、論文からも勉強してみました。今回はこれらの論文をまとめて紹介します。

みなさん、Fearless Journeyというゲームをご存知ですか？
このゲームは、パターンを活用してチームの目標を達成する戦略ゲームです。
パターンは、書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」に記載のパターンを用います。

このゲームは、実際のチームが、実際の課題を解決するために使えるゲームです。
本ワークショップは、参加者同士でFearless Journeyを遊びつつ、ファシリテーションのノウハウを自社に持って帰ってもらうことを目的としたワークショップです。

ワークショップの流れとしては、Fearless Journeyをしてから、Fun! Done! Learn! でふりかえりをします。

このセッションでは「エンジニア（ソフトウェアエンジニア）がビジネスに越境するとこんな良いことがあるかもしれないよ、ワクワクするね」という投げかけをします。すべてのエンジニアがビジネスに越境するべき！なんて非現実的なことは言いませんが、一人でも多くのエンジニアがビジネスに興味・関心を持つことを目指します。

このところ「エンジニアももっとビジネスを知るべきだ」と耳にすることが増えてきました（よかったらTwitterで「ビジネス　エンジニア」で検索してみてください）。同じようなことを2020年ごろから課題感として考えてきた身としましては、そろそろプロポーザルを出して話題にしてもいいタイミングかなと思える社会的な潮目を感じます。

エンジニアとビジネス。しかも越境。このテーマだけでも、いくつも問いが浮かんできます。

まず、ビジネスとはなんでしょうか。どんな印象があるでしょうか。嫌いだけど最低限付き合い続けなければならない隣人のようだとか、自分たちには理解できない原理で構成されている得体の知れない仕組みだとか、マネジメントとかそういう領分の話でしょうとか、なんか騙されてお金を取られそうだ（！？）とか、なにもわかっていないやつらのことだとか、そもそも自分には関係ないものだから知る必要なんかないとか……。

エンジニアチームに対比する存在として「ビジネス側」という言葉を使う会社もあります。ビジネス側と呼ばれるのはどんなひとでしょうか。エンジニアリングを理解せず、リファクタリングの時間なんかもったいないから時間があったら1行でもコードを書いてプロダクトをリリースせよと圧迫する利害関係者でしょうか。現場を知らないのに人事評価を下すマネージャーでしょうか。それとも、エンジニアがもたらすユーザー価値を理解し、パフォーマンスを最大限発揮するためにあらゆる手段を講じる協力者でしょうか。

また、なぜエンジニアがビジネスのことを知る必要があるのかという問いもありそうですね。逆に捉えて、エンジニアがビジネスのことを知らないことでどんな不都合があるでしょうか。他方で、エンジニアがビジネスを知らないことで得ている利益もあるかもしれませんね。それを言語化できるでしょうか。

そしてなにより、エンジニアがビジネスに越境することで何がうれしいのでしょうか。越境を経てどんな動き方・働き方が可能になり、どんな成果に結びつけられるようになるでしょうか。この問いがおそらくメインディッシュでしょう。

越境は決して簡単ではありません。境目が存在するのは、それなりの理由があってのことで、たやすく越えられるものではないはずです。それでも、どなたかが「ちょっと、越えてみようかな」と思ってもらえるようなお話ができたらと思います。

登壇者は10年以上の経験を持つエンジニアで、主要領域は品質保証（Quality Assurance）であり、アジャイル開発を含むいくつかの領域の知見を活用しています。2022年にMBA（いわゆる、経営学の専門職修士）を修得しました。本業ではスクラムチームのメンバーとして「最高のプロダクトづくりを導く」ための活動を行っているほか、副業で品質保証のエヴァンジェリストや記事の執筆・翻訳などに取り組んでいます。

本トークではMBAで学んだエッセンスや業務経験を織り混ぜながら、ビジネスへの越境というのがどんなものかを描き出してみたいと思います。

東京都庁でのアジャイル推進の事例を紹介いたします。

現在、東京都はDXに全力で取り組んでいます。

業務改善・業務改革、より良い行政サービスを実現するためにアジャイル開発は不可欠なものと考え実践を重ねているところです。

本セッションでは東京都デジタルサービス局が中心となりアジャイル開発の事例やパターンをまとめた「都庁アジャイルプレイブック」を紹介します。

• 従来と異なる手法であるアジャイル開発の始めかた

• 事業部門と開発チームとのコラボレーションの工夫

• 進める中での課題・改善の事例

などなど、公共分野ではない方々にも参考にしていただける内容です。

XP の創始者である Kent Beck が、建築家 Christopher Alexander の建築や都市の設計に関する「パタン言語」をソフトウェアに応用し、デザインパターンとし、さらに開発手法を XP として表現したと、いう説はよく知られています（XPとパターン：Ralph Johnsonの見解）。アレグザンダーは昨年他界しましたが、彼が博士論文として書いたのが『形の合成に関するノート』 "Notes on the Synthesis of Form" です。その中の付記IIでは、図形（ダイヤグラム）の数学的な扱いについて書いています。

デザインの中で、要求・適合必要条件など「ニーズ」とみなされるものと、それを満たすであろう「形」。両者の「アンサンブル」（両者の組み）にはどのような関係があるのでしょうか？以下の「人口600のインドの農村の構成」では、141の「ニーズ」を満足するデザインを、2階層12パーツの「形」に分割し、それを合成することで全体を設計する様子を示しています。

（出典：『形の合成に関するノート』より人口600のインドの農村の構成）

当然、ニーズの集合は、「こちらのニーズを満たせばあちらが満たせない」といった関係（リンク）を持っています。付記IIでは、ある条件を満足する点の集合を、どのようにサブシステム分割すれば、サブシステム間の情報伝達を最小にすることができるか、という問題を、数学的に定義し、それを考察しています。

この部分は特に数学的素養がないと難解ですが、その後のセミラティス構造（『都市はツリーではない』）にもつながる「機能の分割と合成による形の生成」の基礎になっています。

このセッションでは、パタンの成り立ちとも言える本論文を紹介し、特にその中の付記II 、すなわち数学的な扱いについてやさしく解説します。また、個人的には、将来 Conway's Law の応用である "Team Topology" についても数学的（位相幾何）な記述を試みたいと思っていて（すなわち、組織の構造とソフトウェアの構造は同相である、を数学的に導く）、その助走でもあります。

ソフトウェア開発のアジャイルプロジェクト自体は急速に増えてきました。そんな中、企業組織の中でアジャイルな活動がうまく根付かせ継続できていない、複数のアジャイルプロジェクトがうまく連携できていない、企業活動とアジャイルチームが噛み合っていない、アジャイルチームだけでなくそれを包含する組織自体も変わっていかなければいけない、そんな課題をお持ちではありませんか？

本セッションでは、企業組織やコミュニティ組織がどんな状態になってほしくてアジャイルをやっているんだろうか、という問いに対し、IPA独立行政法人情報処理推進機構アジャイルワーキンググループの活動の一環として、組織的にアジャイル導入を検討するリーダーのために、組織が幸せであるとはどういう状態かを言語化し、ゴールやそこに至るまでのギャップやアクションを整理・洗練させた「組織を幸せにする組織アジャイル5つの原則（略称：ソシアジャ五良核）」について概説します。

１．同じ方向性を向いて働けている
２．お互いに協働できている
３．お互いに敬意を持っている
４．組織も個人も成長できている
５．ビジネスが持続的に回せている

組織的なアジャイル導入にこれから取り組みたい、複数のアジャイルチームを連携させたい、開発 以外の組織にアジャイル的なマインドを広げていきたい、等々で今まさに苦労している方々のお役に立てれば幸いです。

もともとソフトウェア開発から始まったアジャイルという言葉は、今やプロダクト開発にとどまらずビジネス全般のアプローチとして定着しつつあります。にもかかわらず、アジャイルを導入してみたけれども期待していた効果が得られない、経営者の理解が得られない、続けられない、といった声が後を絶ちません。その背景には、アジャイルに対する理解不足や、用語やツールだけが一人歩きしたことから生じた誤解などさまざまな要因があります。でも私は「アジャイルをやってみようと思った人が、そんな理由でアジャイルを諦めてしまうのはもったいない」という思うのです。

私は2008年にアジャイルに出会って以来、15年に渡って最初はアジャイル開発受託者（POやSM）として、後にアジャイルコーチやアジャイルコンサルタントとして約50案件以上の現場経験を経験してきました。その現場から得た「理論」や「理想」だけではない、実際に実践したからこそ見えてきた「現実」に役立ったヒントを144にまとめて書籍「現場で見つけた144のヒント　アジャイルに困った時に読む本（ダイヤモンド社）」としてこの度出版させていただきました。特に、私のバックボーンである「マネジメント視点でのアジャイル」という要素を多く取り入れています。その中から本日は４つのヒントを厳選しお伝えしたいと思います。まったく同じ状況は存在しないかもしれませんが、少しでもこれらのヒントを使ってアジャイルで働く楽しさを感じて欲しいと願っています。

システム思考で現場を見ていますか？
開発者、プロダクトオーナー、スクラムマスター、アジャイルコーチ。自身がどういう立場であるにせよ、チームの力を最大限発揮するには、システム思考でものごとを見ることが重要だと考えています。

システム思考とは、人や環境、ものごとがお互いにどう影響し合っているかを理解するための考え方です。個別最適化ではなく、全体最適化を図るためのアプローチとして使います。
システム思考は、複雑な問題を扱うとき、本質的な問題解決をするのに効果があります。なので、スクラムにおいて重要な考え方だと思っています。

1950年代にマサチューセッツ工科大学（MIT）のシステム・ダイナミクスという学問から端を発しています。『学習する組織』で著名なピーター・センゲがその実践を広めていきました。

「木を見て森を見ず」ということわざがあるように、人は近視眼的な思考になりがちです。チーム全体、仕事全体の視点を得るためにシステム思考は役に立ちます。

ただ、現場で実践するとなると、なかなか難しい。

「システム思考に興味はあるものの、現場で使うイメージが持てなくて…」
「そもそも、システム思考のイメージもついていないし…」
「メンバーに説明することも難しい」

こうした声は多いのではないかと思います。

本セッションでは、チーム全員がシステム思考に習熟していなくても、すぐにでも現場で使える3つのやりかたを紹介します。

ひとつは、サクセスファクター。
人と組織のシステムを描くことにより、チームの目標を合わせるツールです。

ふたつめは、現状マッピング。
チームの過去・現在・未来を可視化し、チームのボトルネックを特定するツールです。

みっつめは、みなさんもすでに使ったことがあるであろうツール。
「図を描く」ことについて説明をします。

どれも、実際に僕がアジャイルコーチ・スクラムマスターとして関わっている現場で使っているものです。
本セッションを通じ、システム思考を身近に感じ、現場の改善に役立てていただけると嬉しいです。

XPのサークルオブライフ（『Clean Agile』によると12のプラクティス）には、ビジネス・チーム・テクニカルで4つずつのプラクティスがあります。
本ワークショップでは、このうちのテクニカルプラクティス（特にテスト駆動開発とリファクタリング）にフォーカスします。
ハンズオンとぶつかり稽古を通して、テクニカルプラクティスを見つめ直してみませんか？

キーワードは「小さい」です。
達人のテスト駆動開発やリファクタリングは小さいステップをたくさん実行します。
『Clean Craftsmanship』や『The Art of Agile Development, 2nd Edition』で知って私は「自分のやり方クソデカすぎたじゃん...　今までやっていたものはなんだったんだ...」と愕然とするとともに、真似てみたらそれまでよりもTDDやリファクタリングがやりやすくなりました。
小ささはXPの価値（特にフィードバック）と関わるように私は感じており、この視点をワークショップで共有でき、実践者を増やす機会となったらこんなにも嬉しいことはありません。
小さいは正義、なんだよ！ 小さいTDDや小さいリファクタリングを一緒に体験しましょう〜

日本初のスクラム本が発売されてから今年でちょうど20年。その節目に、翻訳者のひとりである今野睦さんにBeyond The Timeということで、当時のことをエピソードなどを交えて、いろいろと質問しちゃおうという企画です。セッションはいくつか用意した質問をインタビュー形式で話をお伺いする予定です。当日の流れ次第では話が脱線してあらぬ方向へ行くかもしれませんがそれも含めてゆるくお楽しみいただければと思います（笑）

＜本の情報＞

名称：アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

作者：ケンシュエイバー,マイクビードル,テクノロジックアート,Ken Schwaber,Mike Beedle,

長瀬嘉秀,今野睦,スクラムエバンジェリストグループ 

出版社/メーカー：ピアソンエデュケーション

発売日：2003/09

https://books.rakuten.co.jp/rb/1593751/

あまり知らない相手に話しかける、これ自体とても勇気がいることです。
ましてや違う会社・違う部署の人に話しかけ、協力を求めることって大変ですよね。
相手は相手で仕事を抱えている、なんか忙しそう、そーいや過去、自分と相手、自分の部署と相手の部署ってぎくしゃくしたこともあったよな、そんな中時間をさいて新たな仕事の協力をお願いしていかないといけない。。
想像するだけでも、不安となり、難しく感じるのではないでしょうか。

小さい頃から緊張しがちで気の小さい自分は特にそうでした。
とはいえ、何か新しいことをやっていくためには、他者への協力を求めること、必ず通る道です。

ここでは、ぎくしゃくしそうな、見知らぬ、忙しそうな相手の協力を求める、その求めかたについて、一緒に学んでいきたいと思います。

特に事前準備などはいらないとは思いますが、過去とても辛い経験をされたことがある方はご無理せずにした方がよいかも。

人やチームの関係性について学び始めると待ち受けている罠 (https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18305/2023-saga-of-the-psychology-the-evil)の各テーマの最後のスライドで表示していた引用について語ります。本編では9割以上触れることはありませんでした。今回は逆に本編には触れず引用への想いだけを語ります。なぜこの引用なのか気になった方や引用元について想いがある方は覗きに来て下さい。

改善が停滞しているチームというのは、現状のままでも特に問題ないと思い込んでいるが周りから見れば課題がある、言い換えると『負の成功体験』が課題発見を阻害している、という特徴を持っています。

本セッションでは、改善が停滞しているチームに対して、『負の成功体験』を脱却させるための強いエネルギーをどうやって外から作用させ、改善を再開させるかについて、概説します。

自分たちだけでの改善が行き詰っているチームに、何らかの良いヒントとなれたら嬉しいです。

文章を書くという行為は、すなわち世界を変える第一歩です。このセッションでは、自分の想いを引き出し文章を書きたくなる方法をワークショップ形式で実践します。

本橋さん、高柳さん（ガオリューさん）とのコラボレーションワークショップです。

アジャイル開発をはじめるには、基本的な語彙やプラクティスをチームにいる全員が知ることが必要になります。また、アジャイル開発を実践していく上ではスクラムのみならず、XP（エクストリームプログラミング）や他の手法からもプラクティスをピックアップして「自分たちのやり方」を作っていくことになります。その際にも様々なプラクティスについて、定義だけでなく、実践する意味、できた歴史的背景、トリビアが知りたくなるでしょう。

私たちはアジャイル開発をはじめたい人向けに、重要な語彙を整理したアジャイルプラクティスマップを作成しました。このセッションでは、その一部である「XP中央線」から3つの駅を選んでぶらり途中下車していきます。

以下のプラクティスを取りあげます。

• ペアリング・モブプログラミング
• ユーザーストーリー
• メタファー

ご紹介するプラクティスに関する質問にもお答えしていきたいと思います。

・同じプロダクトを2つのチームで別々に作成し、ステークホルダーとして指摘しあった事例を基に、チームの成長をもたらしたきっかけを説明します。意図的に複数の視点で考えさせる環境を作ることで、コンフォートゾーンからの抜け出す(越境する経験を増やす)機会を増やし、チーム成長に重要な越境の視点をどのように身につけたかを説明します。

・開発者がどのように越境マインドを身につけるかの参考にいただければと考えています。

１．背景について

・我々の組織は実験的な組織であったため、ローコード開発やアジャイル開発のケイパビリティ取得が重要なテーマでした。その前提の中でどのようなプロダクトを誰向けに作っていったのか？どういう体制・スケジュールで作っていったのか？といった概要を説明します。

２．　２チーム運営について

・２チームで同じプロダクトを作るという特殊な運営を実施した背景や目的について説明します。

３．スプリントでの『越境』エピソード

・スプリントの中で今回のテーマの「越境」をどのように起こしたのか？２チームで同じプロダクトを作るという効果がどういったところにあったのか？を説明します。
　具体的には、ステークホルダーになりきる事、運用/改善についても考える事、デザイナーやプロダクトオーナーに向き合う事について、複数の委託会社での混成チームで進める事に対して、どのような問題がありどう乗り越えていったかを説明します。

４．まとめと考察

・最後に2チーム制で良かった事のまとめやメンバーの感想と今後について報告します。

※実際の講演では、実際に開発者として対応した複数の会社のメンバーの生の意見も聞きながら進めていこうと考えています。

2016年1月10日Ryuzeeさんにより日本語訳された「スクラムマスターを雇うときに聞いてみるとよい38個の質問」が公開されて以降、熟練スクラムマスターが回答したBlog記事がたくさん公開されました。
（原文：「Hiring: 38 Scrum Master Interview Questions To Avoid Imposters」）

しかし、スクラムマスターを目指している人が回答した記事や内容は、あまり見かけないのではないのでしょうか。

本セッションでは、スクラムマスターを目指す私による回答を題材として使用し、参加者の皆さんが熟練スクラムマスターの関と一緒になってフィードバックをしていきます。

フィードバックを通じて、皆さん自身がスクラムマスターとして正しく振舞えているか、質問する側の期待に沿った回答ができているかを確認し、日々の振舞いを改善するきっかけとしていただければ嬉しいです。

■ 参加型セッションの進め方

・チャット（Discord）に「スクラムマスターを雇うときに聞いてみるとよい38個の質問」に対する私の回答を流します。

・気になった回答内容に、本セッション参加者からフィードバックを返信コメントでコメントいただきます。

・本セッション参加者からいただいたフィードバックを元に、熟練スクラムマスターによる良いフィードバックのポイントを概説します。

こんにちは！私たちはパタン・ランゲージに興味を持ったソフトウェアエンジニアの3人です。このセッションでは、「パタン・ランゲージをまちづくりに取り入れた街『川越』」に私たちが実際に行って体験したこと、またそれを通した気づきについて語ります。

私たちは、良い雰囲気のチームに再現性を持たせるためには「チームのパタン・ランゲージ」を作ればよいのではないかと考えました。それこそ、アレグザンダーが町並みに現れる「名付け得ぬ質」に再現性を持たせるためにパタン・ランゲージを提唱したように！

川越には『まちづくり規範』というパタン・ランゲージを文書化したものがあります。私たちはそれを手に川越の街を散策しました。最初は何となく風情や雰囲気が良いと感じるだけでしたが、パタン・ランゲージのレンズを通して街を見るとその魅力的な要素がより明確に浮かび上がってきました。

本セッションは以下のような構成を予定しています。

• そもそも、パタン・ランゲージって何？
• なんで川越なの？
• 川越に行ってどうだった？
• 3人が得たものとは。そこから導いたチーム開発における仮説
• 仮説をもとに試してみた！結果はいかに...

また、本セッションを聴いてくださった方には以下のようなアウトカムが得られることを期待しています。

• 「パタン・ランゲージって何それ美味しいの？」って人には...
  • パタン・ランゲージについてもっと知りたいと思う気持ちを。
• 「パタン・ランゲージは聞いたことがあるけど、そんな言うほど活用したことないなぁ」って人には...
  • 良いチームに再現性をもたらすための思考・取り組みを。
• 「もうパタン・ランゲージを活用しているよ！結構いろんなことを知ってるんだ！」って人には...
  • パタン・ランゲージを「体験」した3人の話から得られる新しい視点を。