概要

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

もう少し詳しい概要

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

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

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

インスパイアされた本

宮本常一『民俗学の旅』

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

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

遠くから見るとスクラムのようでも、近くで見るとそれとは程遠い、やる気を失わせる残念なスクラムを「ゾンビスクラム」と呼びます。スクラムイベントを型どおりになぞってはいても、期待した効果が得られていない――そんな状態です。ゾンビスクラムにかかると「ステークホルダーのニーズを知らない」「速く出荷しない」「継続的に改善しない」「自己組織化しない」の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に対して内心持っていた期待や不満が自分に返ってきてプレッシャーになっていますが、チームのみんなに支えられながら何とかやっています。となりのチームや営業の人たちとの摩擦もあったりしてなかなか簡単じゃないですが、いろいろ工夫したりカイゼンしたりしていることを紹介します。

現代においては

• 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/

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

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

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

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

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

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

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

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

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

出入り自由です。

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

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

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

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

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

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

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

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

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