概要

自らを「忘れられた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に対して内心持っていた期待や不満が自分に返ってきてプレッシャーになっていますが、チームのみんなに支えられながら何とかやっています。となりのチームや営業の人たちとの摩擦もあったりしてなかなか簡単じゃないですが、いろいろ工夫したりカイゼンしたりしていることを紹介します。

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歩目を、ぜひご一緒しませんか。

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/

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

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

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

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

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

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

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

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

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

出入り自由です。