機雷がなんだ！ 全速前進！

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

*[本]「アジャイル開発の法務」: スクラムでの進め方・外部委託・偽装請負防止・ＩＰＡモデル契約とカスタマイズ

Agile Scrum 開発プロセス 契約 法務

Agile Studioさんから書籍「アジャイル開発と法務」をプレゼントしていただきました。

books.rakuten.co.jp

はじめに

アジャイル開発を実践する上で、契約は悩ましい問題のひとつだと思います。

本書はIPAモデル契約策定に携わった弁護士（梅本氏）が書かれた書籍で昨年2022年11月に発売されたものです。2023年1月30日(月)に開催されたAgile Studioさんのウェビナーに参加したら幸運にも献本いただけました。ありがとうございます🙇

 

本の構成

本の構成は、下記のような章立てになっています。

＜構成＞
■第１章　アジャイル開発の紹介（P.1~30：30頁）
第１　アジャイル開発の概要

第２　アジャイル開発とウォーターフォール開発との比較

第３　プロトタイピング開発、スパイラル開発との比較

第４　アジャイル開発（スクラム）の進め方

第５　アジャイル開発を成功させるためのポイント

 

■第２章　法務的観点から見たアジャイル開発（P.31~38：8頁）
第１　アジャイル開発に関係する法律

第２　アジャイル開発の外部委託

 

■第３章　アジャイル開発と契約（P.39~98：60頁）

第１　公表されているモデル契約

第２　アジャイル開発の外部委託契約において検討すべき問題

第３　アジャイル開発に関する裁判例

 

■第４章　アジャイル開発と偽装請負（P.99~130：32頁）

第１　いわゆる偽装請負とそのペナルティ

第２　厚生労働省の派遣・請負区分基準

第３　アジャイル開発向けの疑義応答集第３集

 

■第５章　IPAモデル契約（2020年３月公表）の活用（P.131~185：55頁）

第１　IPAモデル契約の活用方法

第２　IPAモデル契約をカスタマイズする際のの注意点

第３　IPAモデル契約の変更例

第４　IPAモデル契約の別紙のカスタマイズ

 

第３章（60頁）、第５章（55頁）の内容が厚くなっており本書が取り扱うメインテーマについて語られている。特に第３章「第３　アジャイル開発に関する裁判例」では、実際の裁判例が掲載されており個人的にはここが一番面白かった（※注：興味深い、という意味です。詳細は後述）です。また、第５章では、2020年版IPAアジャイル開発モデル契約を参考に、契約のカスタマイズ例や注意点について解説されており、今後の契約を見直す際の参考になりそうでした。

 

印象に残った点

一番印象に残ったのは（アジャイル開発に関する？）裁判例でした。裁判例を読みながら、裁判に至るまでPM含めたステークホルダーの人々は一体何をしていたのだろう、とか「いや、そうはならんやろ！」→「なっとるやろがい！」が頭の中でグルグルとループしました😅。文章化されない背景には、止むに止まれぬ事情（あんなことやこんなこと）があったのだとは思いますが、それを窺い知ることまではできませんでした。

第３章「第３　アジャイル開発に関する裁判例」

【裁判例１】東京地判平成24年5月30日ウエストロー・ジャパン2012WLJPCA05308009

ベンダが、アジャイル開発であるためドキュメントを作成していないと主張したのに対し、裁判所は、アジャイル開発であってもシステム保守のためには最低限のドキュメントの作成は必要なはずと判断した事例

【裁判例２】東京地判平成26年9月10日ウエストロー・ジャパン2014WLJPCA09108013

ベンダが、アジャイル開発であるためドキュメントは作成されないと主張したのに対し、裁判所は、アジャイル開発でもテスト結果を記録した書面やユーザ側の確認をとった記録はあるはずと判断した事例

【裁判例３】東京地判平成30年2月27日ウエストロー・ジャパン2018WLJPCA02278037

ベンダが成果報酬型収益配分モデルでアジャイル開発を行ったものの、開発が途中で頓挫したため、それまで稼働した分について報酬請求をしたが、裁判所は請求を認めなかった事例

【裁判例４】東京地判令和2年9月24日ウエストロー・ジャパン2020WLJPCA09248012

ベンダが期限までにシステム開発を完了しないまま報酬を請求し、完成義務を負っていたか否かが問題となったが、裁判所は契約に至る経緯と契約書の内容から準委任契約と認定し、報酬請求を認めた（また、ベンダの善管注意義務違反も認定し、ユーザによる損害賠償請求も同時に認めた）

【裁判例５】東京地判平成29年11月21日ウエストロー・ジャパン2017WLJPCA11218019

ベンダが完成すべき成果物の内容が争われたが、裁判所は、当初作成された設計書ではなく別途ユーザの指示する仕様に従って成果物を完成させることが合意されていたとのベンダの主張を認め、完成を認めた事例

【裁判例６】東京地判令和3年9月30日ウエストロー・ジャパン2021WLJPCA09308022

ベンダがウェブサイトへの機能追加を請け負ったが、既存のウェブサイトと異なる開発言語を使って開発を行ったことが債務不履行とされ損害賠償責任が認められた事例

【裁判例７】東京地判令和3年11月25日ウエストロー・ジャパン2021WLJPCA11258010

契約において業務対価が固定されている場合には、ユーザが希望する仕様をベンダに伝えたとしても、その指定がそのまま仕様として確定するわけではない理解を前提に、開発が頓挫した原因は、ユーザが（業務対価に応じた内容に）要求事項を絞り込まず仕様を確定させなかったことにあると判断された事例

 

おわりに

不幸にもアジャイル開発の間違った解釈（※但し、答えはひとつではない）のせいで生じた訴訟や裁判エピソードのおかげで、アジャイル開発自体が悪者になってしまっているとしたらとても悲しいことです。既に起きてしまったことにタラレバは無意味かもしれませんが、裁判例に記載されたような体たらくであることを考えると、開発手法には関係なく訴訟が起きていたんじゃなかろうか、と思ってしまいました。

但し、このような問題を他人事と考えてはいけないと思います。これまで出会したことがなかったとしても、この先、場合によっては自分が引き起こしたり、誰かに巻き込まれたり、誰かを巻き込んでしまったりすることも十分あり得ると考えるべきでしょう。そうならないよう普段から十二分に配慮しつつ、そうなった場合に対して備えておくことが重要だと思います。

 

おまけ

手前味噌ですが、以前（もうだいぶ前だな）若手SE向けに契約周りの基本の基(キホンノキ)をまとめたスライドを公開してたことを思い出したんで記事のリンク貼っときます。

SEのための契約知識【超】入門 - 機雷がなんだ！ 全速前進！

 

*[本]「アジャイルソフトウェア開発エコシステム」: Agile Software Development Ecosystem

Agile Scrum 読書 開発プロセス XP ASDE

2003年9月に発売された「アジャイルソフトウェア開発エコシステム」を読みました。

books.rakuten.co.jp

はじめに

今からおよそ20年前に発刊された書籍です。

"本書は、以下の3つの基本的な質問に回答する。

（１）アジャイルが最も得意とするのはどのような問題か。

（２）アジャイルとは何か。

（３）ASDE（アジャイルソフトウェア開発エコシステム）とは何か。"

ということで、アジャイル（開発）とASDEについて書かれた本です。

 

本の構成

本の構成は、下記のような章立てになっています。

＜構成＞
■パート１　問題と解決策

第１章　変化主導経済

第２章　IDXシステムズ社

第３章　アジャイル

 

■パート２　原則と人

第４章　Kent Beck（※補記：ケント・ベック）

第５章　有用なものの納品

第６章　Alistair Cockburn（※補記：アリスター・コーバーン）

第７章　人を信頼

第８章　Ken Schwaber（※補記：ケン・シュウェイバー）

第９章　

第１０章　Martin Fowler（※補記：マーチン・ファウラー）

第１１章　技術的な素晴らしさ

第１２章　Ward Cunningham（※補記：ウォード・カニンガム）

第１３章　最もシンプルなことを行う

第１４章　Jim Highsmith（※補記：ジム・ハイスミス）

第１５章　適応性

第１６章　Bob Charette（※補記：ボブ・シャレット）

 

■パート３　アジャイルソフトウェア開発エコシステム

第１７章　スクラム

第１８章　DSDM（※補記：Dynamic Systems Development Method）

第１９章　クリスタル方法論

第２０章　FDD（※補記：Feature Driven Development）

第２１章　LD（※補記：Lean Development）

第２２章　XP（※補記：Extreme Programming）

第２３章　ASD（※補記：Adaptive Software Development）

 

■パート４　ASDEの開発

第２４章　エコシステムの明確化

第２５章　独自のアジャイル方法論の設計

第２６章　アジャイルのメタモルフォーシス

 

昨今スクラムやXPばかりが取り上げられている気がしてなりませんが、パート３では、それらも含めた主なASDEについて簡単な経緯も含めて解説してくれているのが個人的にありがたかったです。

 

印象に残った点

印象に残ったフレーズ、以下にメモしておく。

アジャイルとは何か

"他の複雑な概念と同様に、アジャイルには多くの定義がある。しかし、筆者は以下の定義が最も明確だと思う。

アジャイルとは、激動するビジネス環境で利益を得るために、変化をもたらし、かつ変化に対応する能力のことである。"

 

ASDEとは何か

"アジャイルソフトウェア開発方法論についての本書を書き始めたが、「方法論」という語に常に不安を抱いていた。なぜなら、「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。さらに、「方法論」という語を使用すると、アジャイルのプラクティスは従来のソフトウェア開発方法論と比較され、そのため誤った比較の目安が使用される。したがって、ASDE（アジャイルソフトウェア開発エコシステム）という用語を使い、3つの絡み合う構成要素を含む全体的な環境を表現している。この3つの構成要素とは、カオーディック（chaordic：カオスと秩序）な観点、協調的な価値と原則、最小限な方法論である。ASDEの提唱者を表すアジャイリストという用語も、この全体的な環境に含まれる。

「アジャイル」が少ないプロセス、儀式、簡略な文書を意味すると考える人もいる。しかし、「アジャイル」にはもっと広い観点があり、そのため「方法論」という語ではなくエコシステムという用語を使用している。"

 

カオーディックな観点

"日々のプロジェクト作業で、カオーディックな観点は以下の2つの成果をもたらす。この成果は、厳密な方法論とは正反対である。

●製品目標は達成可能であるが、予測可能ではない。

●プロセスは一貫性を助長するが、再現可能ではない。

"

主なASDEとその開発者

スクラム（Scrum）

スクラムはラグビーのスクラムから命名された。最初はKen SchwaberとJeff Sutherlandが開発し、その後Mile Beedleと共同開発した。スクラムはプロジェクト管理フレームワークを提供する。このフレームワークはスプリントという30日間周期の開発に焦点を当てる。各スプリント内では特定のバックログ群というフィーチャ群を納品する。スクラムのコアプラクティスは、調整と統合のために、毎日15分間のチームミーティングを行うことである。スクラムは約10年間、幅広い製品の納品を成功させるために使用されてきた。Schwaber、Sutherland、Beedleはアジャイル開発宣言の作成に参加した。

DSDM（Dynamic Systems Development Method）

1990年代中頃にイギリスで開発された。これはRAD（Rapid Application Development ）のプラクティスの派生物かつ拡張である。少なくともヨーロッパでは、各ASDEの中で最も支持されるトレーニングおよび文書化を誇る。DSDMは、活発なユーザ参加、頻繁な納品、チームでの決定、プロジェクトのライフサイクルを通じての結合テスト、開発における可逆変化などの9原則を含む。BennekumはDSDMコンソーシアム役員会のメンバで、アジャイル開発宣言の作成に参加した。

クリスタル方法論（Crystal Methodologies）

Alistair Cockburnは人中心の「クリスタル」ファミリーの作成者である。Cockburnは「方法論考古学者」で、世界中の多くのプロジェクトチームにインタビューし、機能することと、人が機能するということとを分離することに努めた。Cockburnとクリスタルは、協調、帰属意識、協力といった開発における人の側面に注目した。Cockburnはプロジェクトの規模、重要度、目的を使用し、適切に設定したプラクティスをクリスタルファミリーの各方法論（クリア、イエロー、オレンジ、レッド）のために作成する。Cockburnもアジャイル開発宣言の作成に参加した。

FDD（Feature Driven Development）

Jeff De LucaとPeter CoadはFDDを共同開発した。FDDは最小限の5ステップのプロセスで構成される。このプロセスは、総合的な「形状」オブジェクトモデルを開発し、フィーチャ一覧、およびフィーチャによる計画、イテレーティブなフィーチャによる設計、フィーチャによる構築の各ステップを順々に行う。FDDのプロセスは簡潔で（各プロセスは1ページで記述される）、FDDにおける2つの重要なロールはチーフアーキテクトとチーフプログラマである。FDDがXPと異なる点は、「軽い」事前のアーキテクチャモデリングである。オーストラリア人のDe Lucaは50人以上の（アジャイル開発としては）大規模なプロジェクトの事例を2つ提供した。John KernはCoadの会社であるTogetherSoft社のプロジェクト開発責任者で、アジャイル開発宣言の作成に参加した。

LD（Lean Development）

最も戦略的思考のASDEは知名度が一番低い。Bob CharetteのLDはリーン生産方式に由来する。リーン生産方式とは1980年代に日本の自動車製造業界で再構築された方式である。変化に対する従来の方法論的観点は、制限的な管理プラクティスで制御すべき損失のリスクであった。しかし、CharetteはLDでこれを拡張し、変化を、「リスク起業家精神」を使用して実行する「機会」の生産とした。LDはヨーロッパの大規模電気通信プロジェクトで多く使用され、成功した。

XP（Extreme Programming）

Kent Beck、Ward Cunningham、Ron Jeffriesが開発した。XPはコミュニケーション、シンプル、フィードバック、勇気の価値を説く。XPの重要な側面は、変化に対するコストの見方を変えるのに貢献したこと、およびリファクタリングとテストファースト開発によって技術的長所を強調したことである。XPは全体的な単位としての完全性が証明された動的プラクティスの体系を提供する。XPはアジャイル開発の中で最も関心を集めている。Beck、Cunningham、Jeffries、Fowlerは、アジャイル開発宣言の作成に参加した。

ASD（Adaptive Software Development）

アジャイル運動に対する筆者（Jim Highsmith）の貢献である。ASDはアジャイル方法論の哲学的な背景を提供し、ソフトウェア開発組織が、変化を避けるのではなく利用することで、返上のビジネス環境の激動に対応する方法を示す。ASDはイテレーティブな開発、フィーチャベースの計画、ユーザフォーカスグループレビューといったプラクティスと、リーダーシップ協調管理と呼ばれる「アジャイルな」管理哲学を含む。Highsmithもアジャイル開発宣言の作成に参加した。

 

その他、気になった点のメモ

ASDEとRSMの違い

ASDEとRSMの違いは、拡張的な文書化や、文書化がないのではなく、理解を伝達するための文書化と協調の混合である。アジャイルの実践者は、相互作用に傾倒する。厳密な方法論は、文書化に傾倒する。

BrownとDuguid2000

BrownとDuguidは、Xerox社のコピー機修理エンジニアの間での知識共有の研究について述べる。形式手な文書があるにも関わらず、難しい問題は、エンジニアが呼び出される前の朝食時の会話で解決されることが多いとわかった。

プロセスへの過剰な期待

すべてのツール、技術、好みのプロセスを配置せよ。しかし、最終的には成功と失敗の最大の違いは人である。プロセスのアイデアを作り出すためにどんなに一生懸命作業しても、期待できる最良のことは、プロジェクトにおける二次的な効果であるとわかった。したがって、一次的な人の要因を最大化することが重要である。

 

プロセスは、人が共同作業するのを支援する。共通のフレームワーク、共通の言語、問題を理解するのに役立つチェックポイントを提供することができる。しかし、コンピタンスや協調の問題を補うことはできない。

Bollesの指摘

手法がXPやCMMに関わらず、プロセスはスキルの代用物ではないということである。プロセスが重量でも軽量でも、アジャイルでも厳密でも、プロセスに従うだけでは優れたコード（または優れたテストケースなど）を作成できない。スキルが優れたコードを作成する。

プラクティス（または技法）

プラクティス（または技法）は方法論の活力源である。ペアプログラミング、スクラムのミーティング、ユーザフォーカスグループ、自動テストのいずれであっても、ASDEのプラクティスは才能とスキルがある個人によって実行され、成果を生む。

計画について

計画とはテストされる仮説であり、実現される予測ではない。

それぞれの中心主義者

プロセス中心主義者は人を後回しにする。プラクティス中心主義者は人を最優先する。プロセス中心主義者は（記述された）形式知を重視する。プラクティス中心主義者は（内部の）暗黙知を重視する。

ソフトサイエンス

人間工学、コミュニケーション、協調は「ソフトサイエンス」として知られているが、習得するのは難しい。

→soft science：科学そのものではなく、科学の利用の仕方を扱う科学を指すらしい

「方法論」という語はアジャイル開発の焦点（人、関係、不確定性）に適さない

「方法論」という語はアジャイル開発の焦点である「人、関係、不確定性」に適さないからである。…（中略）…方法論（methodology）という用語は、アクティビティ、プロセス、ツールといった物事のビジョンを連想させる。

アジャイル宣言について今思うこと

Agile ポエム 開発プロセス XP Scrum

2012年に書籍「アジャイルサムライ」と出会ってから今年で10年が経ちました。この10年間で、自身の現場で試行錯誤しつつ、本を読み、勉強会やコミュニティ活動へも参加させてもらって本当に色々な経験をさせてもらいました。今思い出してもビフォア・アジャイル時代と比べて、ソフトウェアやITシステムの開発のことを考えることが楽しく、そして好きになりました。かつて私は開発の仕事に嫌気が差して非IT系へと職を変えたこともありましたが、今こうして開発の仕事を楽しめるようになったのは、アジャイルとの出会いがあったからこそだと思います。その出会いに感謝しつつ10年目という節目に改めてアジャイル宣言を読み返して気付いたことを書き留めておこうと思います。

宣言の内容

宣言の内容は下記のとおりとなっています。

（英）https://agilemanifesto.org/

（日）https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

今この宣言を読んで思うことは、題名が「アジャイル宣言」ではなく「アジャイルソフトウェア開発宣言（原文：Manifesto for Agile Software Development）」だったんだと言うことです。この宣言を常に意識している人からすると何を今更という当たり前の話かもしれませんが、この気付きは私にとって大きなものでした。昨今、アジャイルという言葉は、開発だけにとどまらず、組織や教育あるいはビジネスなど実に様々なシーンで用いられるようになっています。そんな流れもあってか、最近では「開発」だけアジャイルにしても部分最適でしかなく、ビジネスそのものをアジャイルにしないと意味がないという至極最もな意見も増えてきており、その結果「アジャイル開発」ではなく単に「アジャイル」と表現することの方が多くなってきたように感じています。

原則の内容

原則の内容（日本語訳）は下記のとおりとなっています。

（英）https://agilemanifesto.org/principles.html

（日）https://agilemanifesto.org/iso/ja/principles.html

アジャイル宣言の背後にある原則

私たちは以下の原則に従う:

顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

ここでは宣言のことを「アジャイル宣言（原文：Agile Manifesto）」と略して（？）呼んでいます。略して呼ぶことで、前段の「宣言の内容」で述べたように、開発だけに閉じないようなニュアンスにも聞こえますが、やっぱりソフトウェアの開発を大前提とした原則について書かれています。これは上位に位置する宣言の中で「ソフトウェア開発の実践、あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。」と記載されているため、至極当然と言えます。また、先月発売された書籍「アジャイルメトリクス 」では、原則の文章をワードクラウドで可視化する例が紹介されています。面白そうだったので私も試してみました。（下図がその結果です）

この結果からもソフトウェアの開発を前提にしていることがはっきりと読み取れます。

一旦整理する

ここまでの私の理解を一旦整理しておきます。

  • 正式な題名は「アジャイルソフトウェア開発宣言（原文：Manifesto for Agile Software Development）」
  • 題名は「アジャイル宣言（原文：Agile Manifesto）」と略されることがある
  • この宣言はそもそも「ソフトウェアの開発」を大前提としてまとめられている

これらを踏まえて、今思うことについて以下に述べたいと思います。

いま思うこと

アジャイルな開発を目指す試行錯誤の中で「迷った時はアジャイル宣言に立ち返れ！」ということを、これまで何度も耳にし、また、目にしてきました。自身の取り組みの中でも、自分達が今やっていること、やろうとしていることが、果たして正しいのだろうかと迷った時、それに助けられたりもしました。今年ご縁あって本「ぼくのアジャイル100本ノック：親方Project」の一部を執筆をさせてもらう機会がありましたが、何名かの著者の方がそれに近い文脈でアジャイル宣言について触れておられました。確かにソフトウェアの開発を中心に考えれば、今もってそこに違和感はありません。

しかし、前述したとおり、昨今ではアジャイルはソフトウェア開発についてのみならず、もっと広い文脈（アジャイル組織、アジャイル経営、etc.）で使われるようになっていると感じています。例えばアジャイルを実践する手段としてスクラムがありますが、非ITの現場で活用された事例なども目にするようになってきました。そのことは2020年に改定されたスクラムガイドの文面からも読み取れます。（「スクラムガイド（2020年11月）」の「スクラムガイドの目的」から抜粋）

成⻑を続ける複雑な世界において、スクラムの利⽤は増加しており、我々はそれを⾒守っている。スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。そうした状況を⾒ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専⾨家もスクラムを利⽤するようになった。スクラムでは「開発者」という⾔葉を使っているが、開発者以外を排除しているのではなく、単純化のために使⽤しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。

スクラムの起源が1986年に発表された論文「The New New Product Development Game」（野中郁次郎　竹中弘高）であり、当時世界のモノづくりの中心を担っていた日本の製造業の新製品開発の手法を参考にしたものであることを考えると、特別不思議なことではないように思えます。

重要なのはビジネスアジリティを高めることであり、ソフトウェアをアジャイルに開発することは、その要素に過ぎないと思います。そう考えた時、ビジネスアジリティを高める際に、迷った時の拠り所となるものが「アジャイルソフトウェア開発宣言（アジャイル宣言）」で本当に良いのだろうか？という疑問を感じてしまいました。これは決して宣言の内容が悪いとか古くなったと言っている訳ではありません。宣言誕生から20年以上の時を経て「アジャイル」という言葉が表現する領域が想像以上に大きくなってしまった結果なのだと思います。（※ソフトウェア開発の文脈においては、アジャイル宣言は引き続き重要であり続けると思います）

おわりに

もともと「アジャイルソフトウェア開発宣言（アジャイル宣言）」は、2001年に様々なソフトウェア開発手法の提唱者達17名が米国ユタ州のソルトレイクシティの郊外に集まって当時のソフトウェア開発手法やカルチャーに対するアンチテーゼとして「アジャイル」と言う名前を付けて発表しました。それから20年以上の時が過ぎたにも拘わらず、ソフトウェア開発の文脈において、今尚ソフトウェア開発を生業する私たち開発者の心の拠り所となっていることについては本当に感謝と尊敬の念しかありません。

しかし、アジャイル開発を実践する具体的な手段であるスクラム、SAFeなど様々なフレームワークや方法論がビジネス状況の変化と共に今も見直され続けている一方で、アジャイル宣言においてはその機会が無いまま今日に至っているものと思われます。

非ITのビジネスアジリティを考える場合においても「アジャイル」という言葉が使われる昨今のビジネスシーンにおいて、ソフトウェアの開発を前提としない新しいアジャイルの拠り所があると嬉しいなと思う反面、安易に「迷った時はアジャイル宣言に立ち返れ！」と言い放つことがないよう十分気を付けて生きていきたいと思います😅

*[本]「ソフトウェアアーキテクチャの基礎」: エンジニアリングに基づく体系的アプローチ

DevOps Agile 開発プロセス Scrum ソフトウェアアーキテクチャ

話題の近著「ソフトウェアアーキテクチャの基礎（エンジニアリングに基づく体系的アプローチ）」を読んだ感想などを中心に書き留めておきます。

www.oreilly.co.jp

はじめに

ソフトウェアアーキテクチャ、アーキテクトについての基礎や定義を網羅的に解説してくれています。ソフトウェアを中心としたシステム開発を生業にしている人にとって、ソフトウェアアーキテクチャは、身近なものだと思いますが、その定義について立ち止まって考える機会は意外と少ないのではないでしょうか？少なくとも私には、これまであまりその機会はありませんでした。この本は、過去からの経緯と昨今の時代の変化を踏まえて、ソフトウェアアーキテクチャやアーキテクトというもののあり方についての認識を考えさせられる一冊だと思います。

 

本の構成

本の構成は、下記のような章立てになっています。

＜構成＞
１章　イントロダクション

■第Ⅰ部　基礎
２章　アーキテクチャ思考
３章　モジュール性
４章　アーキテクチャ特性
５章　アーキテクチャ特性を明らかにする
６章　アーキテクチャ特性の計測と統制
７章　アーキテクチャ特性のスコープ
８章　コンポーネントベース思考


■第Ⅱ部　アーキテクチャスタイル
　９章　基礎
１０章　レイヤードアーキテクチャ
１１章　パイプラインアーキテクチャ
１２章　マイクロカーネルアーキテクチャ
１３章　サービスベースアーキテクチャ
１４章　イベント駆動アーキテクチャ
１５章　スペースベースアーキテクチャ
１６章　オーケストレーション駆動サービス指向アーキテクチャ
１７章　マイクロサービスアーキテクチャ
１８章　適切なアーキテクチャスタイルを選ぶ

■第Ⅲ部　テクニックとソフトスキル
１９章　アーキテクチャ決定
２０章　アーキテクチャ上のリスクを分析する
２１章　アーキテクチャの図解やプレゼンテーション
２２章　効果的なチームにする
２３章　交渉とリーダーシップのスキル
２４章　キャリアパスを開く

 

詳細な目次は、前述したO'Reillyさんの書籍ページもしくは実際の書籍をご覧ください。この目次だけでなんとなく伝わるかもしれませんが、ソフトウェアアーキテクチャについて現代的な視点も踏まえて網羅的に記載されているため、かなりボリューム（約400ページ）があります。読み方は人それぞれですが、個人的には最初から最後まで同じ密度で読むというよりは、「第Ⅰ部」の基礎編を読んだら「第Ⅱ部」はざっと目を通しつつ気になる所を読むくらいが良いかなと思いました。「第Ⅲ部」は、アーキテクトに求められる要素（しかも必須の）としてチーミングやリーダーシップなどのソフトスキルについて記載されており、そこまで求めてくるか…ぐぬぬ…、と少し驚かされました。

 

印象に残った点

印象に残った点、思ったこと、感じたことを以下に列挙しておきます。

１章　イントロダクション

１．２　アーキテクトへの期待

与えられた役割や肩書き、職務に関係なく、ソフトウェアアーキテクチャには主に次の８つが期待される。

  • アーキテクチャ決定を下す
  • アーキテクチャを継続的に分析する
  • 最新のトレンドを把握し続ける
  • 決定の順守を徹底する
  • 多様なものに触れ、経験している
  • 事業ドメインの知識を持っている
  • 対人スキルを持っている
  • 政治を理解し、かじ取りする

→最後の２つについて言及しているのは個人的に新鮮でした。特に「アーキテクトには、チームワークやファシリテーション、リーダーシップなど、卓越した対人スキルを持ち合わせていることが期待されている。」は、期待値高過ぎない？とも思いました。

１．３　アーキテクチャと交わるもの

未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解していて、より早く未知の未知に対処するようになっている。（著者のひとりMarkの言葉を引用）

→アーキテクチャを考えるうえで、アジャイルのようなイテレーティブ（というか適応的な？）なプロセスの方がより適しているのは、かつてのソフトウェアとは違い変化を前提とした昨今の状況を鑑みた結果なのかな、と感じました。

１．４　ソフトウェアアーキテクチャの法則
第一法則：ソフトウェアアーキテクチャはトレードオフがすべてだ。
第二法則：「どうやって」よりも「なぜ」の方がずっと重要だ。

→シレっと記載されていますが、特に第一法則は、この本全体を通した（強めの）メッセージングだと感じました。

４章　アーキテクチャ特性

４．２　トレードオフと少なくとも最悪でないアーキテクチャ

決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないアーキテクチャを狙おう。

→文脈を加味して読めば、言わんとすることに対して、あまり違和感や矛盾はないと思うのですが、文脈なしでこの言葉がひとり歩きすると、アジャイルマニフェストに記載された12の原則に記載されている「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」を読んだ人が混乱しそうだな、とは思いました。

５章　アーキテクチャ特性を明らかにする

５．１　アーキテクチャ特性をドメインの関心事から捉える
事例：ヴァーサ号（の悲劇）

→トレードオフを無視して言われたまま仕様を全部のせしようとした結果、処女航海で沈没するという、このメタファ好きです。

６章　アーキテクチャ特性の計測と統制

Simian Armyの起源

→Netflixが生み出した有名な（？）カオスエンジニアリングのエピソード好きです。

９～１８章　第Ⅱ部　アーキテクチャスタイル

以下のアーキテクチャスタイルとそのアーキテクチャ特性について解説されています。

  • レイヤードアーキテクチャ
  • パイプラインアーキテクチャ
  • マイクロカーネルアーキテクチャ
  • サービスベースアーキテクチャ
  • イベント駆動アーキテクチャ
  • スペースベースアーキテクチャ
  • オーケストレーション駆動サービス指向アーキテクチャ
  • マイクロサービスアーキテクチャ

それぞれのアーキテクチャ特性をざっと比較するには一覧表があると便利そうだったので作成してみました。Githubに置いておくので参考までにご覧ください。

アーキテクチャスタイルのアーキテクチャ特性比較

１９～２４章　第Ⅲ部　テクニックとソフトスキル

１９章　アーキテクチャ決定

１９．１　アーキテクチャ決定に関するアンチパターン
１９．１．１　資産防御アンチパターン

重要なアーキテクチャ決定を下すのを、最終責任時点まで先延ばしすることだ。これは、正当であると検証するのに十分な情報が得られるまで、決定を先延ばしすることを意味している。ただし、開発チームを待たせたり、分析麻痺アンチパターンに陥ったりするほど長くは決定を先延ばししてはならない。

→言っていることは分かるが、現実問題として最終責任時点のタイミングの見極めが相当難しいのでは？本人としては、アーキテクト本人が最終責任時点だと思っていても、まだ早かったり、もう遅かったりということが多々ありそうな気がする。

１９．３　アーキテクチャデシジョンレコード

アーキテクチャ決定を文書化する最も効果的な方法の１つに、アーキテクチャデシジョンレコード（Architecture Decision Records、ADR）ある。

→今までは使ったことない。アーキテクチャ決定したWhyの記録（ソフトウェアアーキテクチャの第二法則）として効果的なのであれば、今後のアーキテクチャ決定時に試してみたい。

２１章　アーキテクチャの図解やプレゼンテーション

新米アーキテクトがよく口にすることに、アーキテクトになったのは技術的な知識や経験があったからだというのに、アーキテクトの仕事がそれだけでなく、非常に多岐にわたっていることに驚いた、（中略）。アーキテクトがどんなに素晴らしい技術的なアイデアを持っていたとしても、マネージャーに資金を出してもらい、開発者に作ってもらえなければ、その素晴らしさは決して実現しないからだ。

→うーん、確かに仰る通り。でも、そこまでやれる人がどこまでいるだろうか、、、

２２章　効果的なチームにする

２２．１　チーム境界

アーキテクトが作る制約があまりにも緩いと（もしくはまったく制約を作らないと）、重要なアーキテクチャ決定をすべて開発チームに任せてしまうことになる。これは制約が厳しい場合と同じくらい悪い。

→この点は個人的に反省する点が多い。複数のスクラムチームで比較的大きなソフトウェアを開発する場合、スクラムの文脈を考えると、全てを自己組織化したチームに委ねてしまいたくなる。というより、むしろ委ねないといけない気すらしてしまうのだが、成熟してないチームだと当然カオス気味になる。スクラムにはアーキテクトというロールはないので、有識者が居たとして、どこまでスクラムチームに干渉（最初から制約を突きつけたり、積極的に助けてあげたり）するかは、特に初めてのシチュエーションではなかなか判断が難しいと思う。とはいえ、過去の反省を踏まえた今ならば絶対必要だと思うし、体制面としても明確にしておくべきだと思う。

２２．２　アーキテクトのパーソナリティ

プロジェクトの複雑さやチームのスキルレベルによっては、アーキテクトがコントロールフリークの役割を果たす必要がある場合もある。しかし、ほとんどの場合は、コントロールフリークアーキテクトは、開発チームを混乱させ、適切なレベルのガイダンスを提供せず、邪魔となり、チームを率いてアーキテクチャを実装することに関して効果を発揮しない。

→このあたりのバランスはとても難しそう。経験値が大きく問われそう。

２２．３　エラスティックリーダーシップ

効果的なソフトウェアアーキテクトは、開発チームをどの程度コントロールするかをわかっている。この考え方は、エラスティックリーダーシップとして知られており、Roy Osheroveによって広く提唱されている。（中略）。主に５つの要因がある。

  • チームの親しさ
  • チームサイズ
  • 全体的な経験
  • プロジェクトの複雑さ
  • プロジェクトの期間

→確かに状況によって柔軟にコントロールするレベルを変えないと効果的でないのは理解できる。上記の要因や指標があっても尚難しそうだが、さじ加減を考える上での参考にはなりそう。

２２．５　チェックリストの活用

万策尽きた場合には、ホーソン効果を活用しよう。ホーソン効果とは、自分が観察されたり監視されたりしていることを知っていると、人は行動を変え、概して正しいことをするようになるというものだ。

→チェックリストの作成まではよくやる。すべてのチェックリストを検証することは現実的には難しいと思うけど、ロット検査のようにランダムサンプリングによる抜き取り検査ならできそう。それによるホーソン効果も期待できそう。（もちろんそんなことしたくはないが、、、イザとなったらロット検査するよ！と伝えるだけでも良いかも）

２３章　交渉とリーダーシップのスキル

２３．２　リーダーとしてのソフトウェアアーキテクト

ソフトウェアアーキテクトはリーダーでもある。アーキテクトはアーキテクチャの実装を通して開発チームをガイドする。私たちは、効果的なソフトウェアアーキテクトであることの50%は、優れたピープルスキル、ファシリテーションスキル、そしてリーダーシップスキルを持っていることだと考えている。

→このあたりのバランス感覚まで兼ね備えてしまうと、もはやアーキテクトの能力を持った有能なスクラムマスターという感じ。もはや君子

２４章　キャリアパスを開く

２４．１　２０分ルール

このテクニックは、アーキテクトとしてのキャリアのために新しいことを学んだり、特定のトピックを深く掘り下げたりするのに、１日に少なくとも２０分は費やすというものだ。（中略）多くのアーキテクトはこの考え方に従って、昼休みや仕事が終わった後の夕方に２０分ほどかけてこの作業をしようとする。しかし、経験上、これがうまくいくことはほとんどない。ランチタイムはどんどん短くなり、休憩や食事の時間というよりも、仕事の追い込み時間になってしまう。夜はもっとひどい。状況が変わったり、予定が入ったり、家族との時間が重要になったりして、２０分ルールが実現しなくなってしまう。私たちが強く勧めるのは、一日の始まりである朝一番に２０分ルールを活用する方法だ。しかし、このアドバイスにも注意点がある。（中略）そのため、私たちは、朝一番のコーヒーや紅茶を飲んだ後は、メールをチェックする前に、２０分ルールを発動することを強くお勧めしている。少し早めに出勤する。これをすることで、アーキテクトの技術的な幅が広がり、効果的なソフトウェアアーキテクトになるのに必要な知識を身につけられる。

→めちゃワカル。メール見ないようにしてても、私信で来たチャットとかを、つい見ちゃうとそこで試合終了なんですよね。分かっちゃいるけどついやってしまう。キヲツケねば。

２４．４　別れの挨拶

アーキテクチャには正解も間違いもない。ただトレードオフがあるだけだ。（著者のひとりNealの言葉を引用）

→ソフトウェアアーキテクチャの第一法則と同じ内容を言葉を変え最後に語っている。著者（ら）がこの本を通して伝えたかった重要なメッセージングなのだと思う。

 

おわりに

ソフトウェアアーキテクチャには、絶対的な正解が存在しない。すべてはトレードオフなのだ、というこの本の強いメッセージに少し気後れはありますが、だからこそ追い求める価値があるものなのだという、冒険の旅のようなワクワク感もあります。そういえば、最近出版された「O'Reilly Japan - ソフトウェアアーキテクチャ・ハードパーツ」は、今回の「O'Reilly Japan - ソフトウェアアーキテクチャの基礎」の続編のようなタテツケで、長編の英雄譚（サーガ、Saga）の体で書かれているんだとか。ソフトウェアアーキテクチャを学び、追い求めることはまさに冒険なんですね。積読が滞留しているのですぐ手を出せませんが、少し時間を置いてから、そちらの本も読んでみたいと思います。

 

参考

*[本]「ゾンビスクラムサバイバルガイド」: 健全なスクラムへの道

Agile Scrum 読書 開発プロセス

翻訳者の たくぼん さん、 たかＳ さん、水野 さん から献本いただきました。ありがとうございます。

ゾンビスクラムサバイバルガイド: 健全なスクラムへの道 | 木村 卓央, 高江洲 睦, 水野 正隆, Christiaan Verwijs, Johannes Schartau, Barry Overeem |本 | 通販 | Amazon

本を読んだ感想などを中心に書き留めておこうと思います。

概要

何となくスクラムを始めたがうまくいかない、
型通りにやっているけど何かが違う気がする、
スクラムを取り入れたがメリットを感じない、
etc.
：
など、既にスクラムに取り組んでいる人や組織で発生（発症？）しがちな形骸化やその他さまざまな問題を、ウォーキング・デッド（いや、もしかしてバタリアン？）のゾンビに例えて、ゾンビウィルスに打ち勝つ対策について事例を交えて解説してくれます。

内容

本の構成は、下記のような章立てになっています。

＜構成＞
第１章　はじめに
第２章　応急処置キット

■第１部　（ゾンビ）スクラム
第３章　ゾンビスクラム入門
第４章　スクラムの目的

■第２部　ステークホルダーが求めるものを作る
第５章　症状と原因
第６章　実験

■第３部　速く出荷する
第７章　症状と原因
第８章　実験

■第４部　継続的に改善する
第９章　症状と原因
第１０章　実験

■第５部　自己組織化する
第１１章　症状と原因
第１２章　実験
第１３章　回復への道

 

各部のテーマに対して「症状と原因」の章で問題や課題を取り上げ、次章の「実験」で具体的な処方箋について手順も交えて説明するという流れになっているので、テンポよく読めます。これが理解しやすさに繋がっている気がしました。（※但し、理解しやすいから実践しやすい、という訳ではないので注意ください）

翻訳本はモノによって読みにくい文章になっていることもありますが、この本の文章は非常に読みやすくて良かったです。翻訳の表現があまりに不自然だと、どう理解すべきか考え込んで疲れてしまい、読むのが辛くてやめてしまったりしたこともあったので、その点については個人的にポイントが高かったです。

この本の中には、例として様々なゾンビスクラムの症状が出てきます。

「なんか見たことある！」とか「まさに今そうなってる！」など、各読者ごとに様々な思いが浮かんでくるんじゃないかと思います。症状が進行しすぎて既に何も感じなくなってしまったりしていると、最初の小さな一歩を踏み出すのも難しい場合があるかもしれません。そんな時は、本の中でも紹介されている「助けてくれる人を探す（応急処置キット）」を意識して、社内外の協力者をうまく頼って地道に実践していくのがゾンビスクラムで生き残る道なのではないでしょうか。

おわりに

個人的に最小の労力（スキル：★ or ★★）で最高のリターン（効果：★★★★★）が得られるコスパ良い処方箋をパッと知りたいと思ったので、Excelで「ゾンビスクラムと戦うためにチームでできる実験」のチート資料つくってみました。

こんな感じのやつ【↓】

ゾンビスクラムと戦うためにチームでできる実験（のチートシート）

これで楽して成果を得られるぜ！って、、、ん？

よく見てみると確かにスキル要らないのもあるけど、あくまでも著者のコンテキストや目線ですよね。世の中そんなに甘くない、ということですね（デスヨネー、笑）。とは言え、考える上での目安にはなると思いますので、参考までに チートシート を添付しておきます。このシートは、困った時に本のどこを見れば良いかすぐ分かるので、ちょっと便利なインデックスとしても使えるんじゃないかと思います。（※もし内容に問題あればすぐ更新 or 削除します）

 

参考

AWS 認定ソリューションアーキテクト – プロフェッショナル（SAP）を【再】取得しました

AWS

AWS 認定ソリューションアーキテクト – プロフェッショナル （SAP-C01）を【再】取得（9/23）しました。

合格するまでの勉強方法などのメモです。誰かの何かの役に立てば幸いです。

AWS認定について

AWS認定の情報はググれば死ぬほど出てくるので、敢えてここで詳細を語る必要もないかと思います。AWS認定の詳細は以下の公式ページに記載されています。詳細はこちらをご覧ください。

aws.amazon.com

ちなみに今年の8/10でSAP認定がEXPIREしてしまっていたので今回は更新（再認定）ではなく再取得でした。EXPIREした理由は主に２つで、更新（再認定）のメリットをあまり感じなかったのと、新規取得の時と比べてモチベーションが湧かなかった点でした。ちなみに一度失効するとセットの下位資格（今回はSAA）の認定バッジは無くなりますので撃墜マークとして認定バッジ数を気にされる方はご注意ください。

再認定について

再認定の詳細は以下の公式ページに記載されています。詳細はこちらをご覧ください。

aws.amazon.com

なぜこのタイミングなのか？

そんな中、なぜこのタイミングでSAPを再取得したかと言うと、ちゃんと理由があります。それは、今年の11/15[火]から試験がバージョンアップ（SAP-C01→SAP-C02）されてしまうからです。既に次バージョンの試験ガイドやサンプル問題が公開されてはいますが、新しいバージョンの試験対策において試行錯誤するファクターが増えそうです。新しいバージョンの試験についての詳細は以下の公式ページに記載されています。

aws.amazon.com

AWSも「現在の AWS Certified Solutions Architect - Professional 試験の準備をしている方、または再認定が必要な方は、2022 年 11 月 14 日 までに現在の試験を受けることをお勧めします。」と言っており、これが今回の一番のモチベーションになりました。

現行バージョンの試験の終了時期が割と間近に迫っていることも考慮して、少しリスクをとって学習レベルがギリギリ合格ラインに達したくらいで一旦1回目を受験することにしました。これは、もし不合格だった場合、再試験、再々試験くらいまでを視野に入れるとすると、試験の間隔を2週間以上空けないといけないからです。

※ちなみに、SAAは今年の8月末から既に新しいバージョンの試験（SAA-C03）に移行しており、旧バージョン（SAA-C02）で受験することはもうできません。

SAP試験対策について

以上の理由から、今回の試験対策は短期決戦を意識して準備を進めました。今回の対策で使用した教材は下記のとおりです。

  • 参考書：AWS認定ソリューションアーキテクト - アソシエイト
    • こちらの物理本を買いました。本は頭から順番に読まず、中の問題をまずは一周解いてみて、自分の弱点を炙り出しました。その際、間違えた問題、解答に自信がない問題（と解説）の再検索を容易にするためインデクシング（赤ペンでチェックを付けて、ページの角をドッグイヤー）しておきました。インデクシングした問題は、解説を読んで納得できればそれでOKです。納得できない場合は、ググって調べて、自分なりにある程度納得できる状態にしておきました。

      books.rakuten.co.jp

    • 前回の時と違って、今はSAPの試験対策本や問題集があるので短期決戦の準備をするにあたりその点はとても助かりました。
  • 模擬試験：AWS Skill Builder（※無料）
    • AWS認定の模擬試験（20問）をオンラインで受けることができます。本試験と同じような画面レイアウト（時間制限なども本番に近い）で体験できるので、やっておくと良いと思います。以前の有償（¥4000）だった頃と違い、試験後に模擬試験の問題を見返して復習することもできます。残念ながら日本語の問題は現在は下記の1コースのみしかないようです。こちらはSAPの公式ページにある「公式練習問題集」リンクから辿れます。
    • 模擬試験の受け方については、下記の情報を参考にさせてもらいました。

      blog.serverworks.co.jp

  • サンプル問題：AWS Certified Solutions Architect - Professional（※無償）
  • Udemy：AWS 認定ソリューションアーキテクト プロフェッショナル模擬試験問題集（※有償：¥2440）
    • 375問（75×5set）のAWS認定SAPテスト問題集（解説付き）です。こちらは前述の3つの教材をひと通りやり終えてから、試験当日までの短期強化対策として取り組みました。1set解くのに約180分を要し、間違えた問題の解説を読み、更に分からない点はググって調べる、とかなり時間がかかりました。今回は試験当日までに300問（4/5set）を実施しました。

      www.udemy.com

    • 【注意】ちなみに、この問題集は本試験と比べてもかなり難しいと思います。今回の準備期間である程度学習してから解きましたが軒並み5割くらいでした。なので、この問題集のスコアはあまり気にし過ぎず、前述の教材でカバーし切れない領域の知識を補強してくれる教材という程度に受け止めておけば良いと思います。
  • その他
    • 地味に大事なのが受験会場ですね。受験会場によってだいぶ当日のストレスや疲労に差が出ると思います。過去の実績から歌舞伎座テストセンターを選択したかったのですが、2021年頃からAWS認定試験の対応を辞めてしまったのか、今回は選択することができませんでした。そんな訳で、今回は自宅から近い 町田ITテストセンター（ピアソンVUE）で受験したのですが、そんなに悪くなかったです。近いし、次回もここで受験しようかな。
    • 試験会場では、感染症対策の観点からマスクをした状態で受験することになります。花粉症などの対策でマスクに慣れてる人は良いですが、慣れてない人にとっては長時間マスクした状態で試験し続けるのは、頭がボーっとして地味にしんどかったです。ので、もしキニナル人は自宅で模擬試験やる時、1回くらいシミュレーションしとくとよいかもです。

 

以上の対策を実施した結果、今回は運良く1回でパスすることができました。

お疲れ様でした。ギリギリで恥ずかしいのでスコアは秘密ですw

来年はDOPの更新が待ってます。取得時期ズラしといてホント良かった、、、

 

※補足※

ちなみに来年からPSIでの受験はできなくなるそうです。

AWS Certification のよくある質問

[2022/9/11(日)］技術書典13@池袋オフライン へ参加してきました

読書 Agile 技術書典

2020年前半から新型コロナウイルスによる自粛生活が始まってからオフライン形式のイベントに最後に参加したのがいつだったかもはや思い出せませんが、超久しぶりにオフラインのイベントに参加してきました。今回参加したのは技術書典13です。

技術書典は、その名のとおり技術書に関するイベントで、技術書を中心に数多くの作品（技術同人誌）が出展されており、新しい技術に出会える素敵なイベントです。2020年以降コロナの影響で暫くオンラインで開催していたようですが、約3年ぶりにオフラインでイベントが開催できたようです。（※ちなみにオンラインイベントは只今絶賛開催中9/10[土]-25[日]です！）

#技術書典 #技術書典13

今回、ご縁あって、こちらのイベントに出展される本「ぼくのアジャイル100本ノック：親方Project」の一部執筆をさせていただく機会があったので、折角なのでオフラインイベントに参加してみようということで初参加してきました。当初は一般参加するつもりだったのですが、売り子が足りないということで、急遽スタッフとして参加することになりました（笑）そんな訳で初参加ながらいきなり貴重な経験をさせてもらいました。開場前の販売ブースの様子はこんな感じで文字通り本が山のように積まれています。

大変嬉しいことに、こちらの450ページの超分厚い本（※ネタで鈍器と呼ぶ人も居ましたが）を多くの方に買っていただけました。一部ではありますが、自分が執筆した本が目の前で買ってもらえるというのは不思議で貴重な体験でした。とても嬉しかったです。

 

せっかく来たので私も会場をまわって興味のある技術書を買い漁っていたら思ったより沢山になりまして、帰り道とっても重かったです。物理本をこんなに纏めて買ったのはいつぶりだろう（いや、初めてかw）。やはりオフラインのイベントだと、わざわざ足を運んでいる、せっかく来たからには、という気持ちがオンラインより圧倒的に強くなるので、購買意欲もマシマシになりますね。是非来年も参加したいです。

執筆機会をいただけた、あじゃてくことAgileTechEXPOさんありがとうございました。本の編集や校正そして熱意あるフォローやリマインドなど親方Projectの親方さんには大変お世話になりました。オフラインイベント当日も含めていろいろと勉強になりました。

 

＜補記＞

折角なので今回の本「ぼくのアジャイル100本ノック」は会社の本棚へ献本させてもらいました😊

本の厚さはこのとおり…私はよくタウンページくらいと表現していたのですが、これが鈍器と謂われる所以ですw