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

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

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

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

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

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

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

続きはXP祭りで。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1999年，XPの初版が出版されていますが，同年に「リファクタリング」が出版され，双方の参考文献に双方が記述される，という相互依存関係にあります．コードの不吉な匂い，はリファクタリングにおいて提示された「よくないかもしれない気配」の言語化です．

また，2019年，「Team Topologies」が出版され，チームのアーキテクチャやモジュールについての文法化とパターン化がトライされました．

コードとチーム．両者を橋渡ししているのは，「コーンウェイの法則」（コードのアーキテクチャはチームのアーキテクチャに従う）です．ソフトウェア設計構造とソーシャル設計構造の一致．すなわち，コードとチームは相似関係にある，という経験的理論があるわけです．

では，コードの設計原則や不吉な匂いは，チームにも延長して適用できるでしょうか？

このショートセッションでは，「リファクタリング」や「オブジェクト指向原則」にみられる原則やアンチパターンと，チーム・組織構造のそれらの並行概念について，考えてみます．いくつかは確かにパラレルに援用できるが，いくつかはソーシャル構造の中では有効に機能するものも見当たります．

共通性があると思われるもの

• 継承でなく移譲
• Tell, don’t ask,（あれはどうなっているんだ）
• Singleton/Global variable（あの人の許可とったよね？）
• Stable Known Interface（複数チーム，モジュールの鍵）
• よい名前（ちゃくせき，てんけん）

コードでは良くないと思われているが，人系では実はキーになっていると思われるもの

• 仲介人
• 不適切な関係

アジャイルの特徴である持続可能なペースでリリースを続けるためには、テストオートメーションがより重要になってきます。

ところが、プログラマーがテストオートメーションの落とし穴を把握せずに進めると、テストによる旨味よりも辛みが増して、アジャイルな開発を支える要素というより、開発を邪魔する【障害物】になってしまいます。やがて、テストオートメーションを続けることを諦めてしまい、持続可能なペースでリリースを続けるが難しくなっていきます。

そこで、本日は、xUnit Test Patternsのテストの不吉な臭い（落とし穴）やゴールを中心に、参加者と共に学び直し、議論できればと思います。書籍はこちら。

https://www.amazon.co.jp/dp/B004X1D36K/

近年では、Googleが有名にしたFlaky Test（テストの実行結果に一貫性がなく成功したり失敗したりする事象）しばしば、話題に上がりますが、xUnit Test Patternsの Test Smellsでは [Erratic Test]に近しい内容です。アジャイルなプログラマーを悩ませるテストの不吉な臭いは、Flaky Test[Erratic Test]だけではありません。テストコードや失敗レポートを読んで内容が理解できない[Obscure Test]、ちょっとしたプロダクションコードやデータの修正で意図せず大量のテストが落ちてしまう[Fragile Test]、などなど。

xUnit Test Patternsは翻訳されていない本ですが、当日は、簡単な解説を行います。また、耳だけもOKなので気楽にご参加ください。

Help Me!!。

私は英語言語は得意ではありません。また、テスト（特にテストの不吉な臭いやゴール）にまつわる議論に参加してくれるを探しています。
直接お話がハードル高い場合は、Discordでワイワイ参加でも。よろしくお願いします！

XPとは何でしょうか？エクストリームプログラミング第2版によれば

エクストリームプログラミング（XP）はソーシャルチェンジである。

と、この本でケント・ベックはそうおっしゃるのです。

というように、真面目な話にそっとクスリとくるようなことを添えることを生業のようにしている者です。このセッションでは、どのようにしてこういったことを生み出しているのかについて話をします。

えっ？くすぴとも来ない？

そうです、こういったことを生み出す技術について、ご紹介します。

皆さんにも「あんな風になりたい！」と思える人がいると思います。自分がそんな人に近づいたいと思ったときには、最初にその人を観察していると思います。

なにか行動をする時には観察から始めると思います。そこで、私にも憧れる「エクストリームな人」がたくさんいます。自分が思う「この人のここがエクストリーム」ということを言語化してみようと思います。