概要

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

もう少し詳しい概要

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

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

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

インスパイアされた本

宮本常一『民俗学の旅』

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続きはXP祭りで。

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

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

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

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

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

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

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

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

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

現代においては

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

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

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

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

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

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

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

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

例えば‥

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このセッションでは、とにかくたくさんの「ふりかえりのやり方」を紹介します。

目安は1手法1分。「こんな手法もあるのか！」「こんなやり方でもOKなのか！」「これもふりかえりなの！？」という新たな発見や気づきにつながるかもしれません。

少なくとも、既存のふりかえりの枠組みを破壊するきっかけになることでしょう。

ここ2年ほど、私たちのチーム「オキザリス」では、毎週異なる手法で、かつその場で適当に生み出した手法を使いながら、100回以上ふりかえりを行なってきました。スプリントは3400回を超え、その都度小さなふりかえりをしています。

そんなエクストリームなチームが普段から行なっているふりかえりの内容を赤裸々に公開します。

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

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

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

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