期間2週間とAgileに(?)撮影された超低予算傑作映画になぞらえて
WFHでNetflixが仕事が捗る今日この頃ですがいかがお過ごしでしょうか。
本を読む時間も取れるようになり、ソフトウェアの名著と呼ばれる分厚めの本も読めますね。
これらの名著の著者はどこかで聞いたことある名前だなと思って調べますと、20年ほど前に定義されたアジャイルソフトウェア開発宣言の宣言者17名に含まれるものも多く、この17名が一体どんな方々なのかを深堀りしてみます!
(若造ですので知らないことも多くミスなどありましたらご指摘いただけると幸いです! )
下記、アジャイルソフトウェア開発宣言です。 参考URL(ググると大量にでました)
絵では8人しかいないのが気になりますね。
アジャイルチームは基本10名以下で組織されるということなので、2チームに別れて残りの9名はジャン負けして写り損なったのでしょうか。真偽のほどは不明です。
前置きはこの程度にしまして深掘りしていきます!
Kent Beck (ケント・ベック)
言わずと知れたテスト駆動開発(TDD)、**エクストリームプログラミング(XP)**の方ですね。
見た目は割と厳しそうです、、テストコード書かないと頭突きでも食らいそうです
本を読まれてない方はぜひこの機会にお読みになって、テストコードを先に書いて開発していくスタイルを試されてみてもいいのではないでしょうか。
-
テスト駆動開発 | Kent Beck, 和田 卓人 |本 | 通販 | Amazon
-
エクストリームプログラミング | ベック, ケント, アンドレス, シンシア, Beck, Kent, Andres, Cynthia, 征典, 角 |本 | 通販 | Amazon
wikipediaによると
ケント・ベック (Kent Beck) はエクストリーム・プログラミング (XP) の考案者でアジャイルマニフェスト (Agile Manifesto) の起草者の一人。彼はデザインパターン、テスト駆動開発、Smalltalkに関する本を書いた。ベックはウォード・カニンガムと一緒にCRCカードを普及させた。SmalltalkのユニットテストのフレームワークであるSUnitを開発した。さらにエーリヒ・ガンマと共同でJavaのユニットテストのフレームワークJUnitを開発した。ケント・ベックはオレゴン大学のコンピュータサイエンスの修士号を取得している。
JUnitの生みの祖であり、この世にテストコードを普及させる大きな役割を果たされた方なのだなと感じます。
感謝の念とともにIntelliJでCtrl+Shift+R
します!
James Grenning (ジェームス・グレニング)
こちらもTDDの(特に組み込み系に強い)方のようです。見積もりに使うプランニングポーカーを開発されたそうでこちらもお世話になってます。
ちなみにオンラインのプランニングポーカーですと古いですが Hatjitsu がシンプルで使いやすくて良いですね。
- テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計 | James W. Grenning, 蛸島 昭之, 笹井 崇司 |本 | 通販 | Amazon
その当時、私は XP について取り組み始めたばかりでした。Bob Martin や Martin Fowler [12] といった XP の指導者達からプラクティスを教えてもらえることができて非常に幸運でした。 そして、ミーティングでは非常に面白い話ができ、発見に満ちていました。
驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。
と語っており、プロセスを重視するよりも、開発者(人)を重視せよとあります。
たしかに「対面」をアジャイル宣言では重視してますが、コロナの現状ではそれも難しいですよね。KPTなどを通じてプロセスを我々の現状にあったものにする必要性を感じました。
なお、現在も割とtweetしている模様です。tweetによるとScrumよりXP押しのようですね。
Robert C. Martin (ロバート・C・マーティン)
通称Uncle Bob。**SOLID原則**の提唱者の方ですね。 書籍 Clean Architecture
にSOLID原則について書かれております。オブジェクトの役割を考える際の良い指針となります。CLEAN CODEも良著でした。
-
Clean Architecture 達人に学ぶソフトウェアの構造と設計 | Robert C.Martin, 角 征典, 高木 正弘 |本 | 通販 | Amazon
-
Clean Code アジャイルソフトウェア達人の技 | Robert C.Martin, 花井 志生 |本 | 通販 | Amazon
ちなみに個人的に本の各章表紙の絵がユーモラスで好きですね。シリアル飽きたぜ的な顔でしょうか。
また、彼による他の十七名の紹介動画がyoutubeに上がっておりました!
https://youtu.be/4JihsBOBbdI
Mike Beedle (マイク・ビードル)
wikipediaによりますと、理論物理学者で Jeff SutherlandやKen Schwaberの後に、**スクラム開発(Scrum)**を広められた方のようです。
悲しいことにシカゴで強盗事件らしいもので2018年3月に他界されたそうです。(アメリカを感じます。。)
現在のScurmにそのスピリットは引き継がれているでしょう。
Jim Highsmith (ジム・ハイスミス)
いわゆる「アジャイル」ができる前から、Adaptive Software Developmentという名前でアジャイルな開発をされていた方。
今なお現役の模様で、EDGEVALUE-DRIVEN DIGITAL TRANSFORMATIONというDXの書物も出版されております。
Jim Highsmith, executive consultant at ThoughtWorks, Inc, has 40-plus years’ experience as a manager, consultant, developer, and storyteller.
40年以上も現役とはすごいですね!
Steve Mellor (スティーブ・メラー)
Shlaer–Mellor法(別名:Object-Oriented Analysis) と Executable UMLを作られた方。
Executable UMLとは何ぞと思って調べると、モデルから実行可能なソースコードを生成する取り組みの模様。
ソースコードからUMLを生成することはIntelliJなどでできた気がしますが、逆もできると確かに良さそうですね。
設計の大事さが伝わってきます。
参考: Executable UML MDAモデル駆動型アーキテクチャの基礎
Arie van Bennekum (アリー・ファン・ベネクム)
宣言者の中で唯一のヨーロッパ人。
インタビュー記事によると日頃から規律に従うことが必ずしも正しいとは思っておらず、兵役の際にそれを経験として知った模様です。
「確立されたシステムにしたがって行動することが必ずしも成功につながるわけでは無い。」という理念をお持ちということです。
ゆでガエルの話もありますが、なかなか染み付いた既存のシステムを疑うのは難しいものです。。振り返りのイベントなどの際に疑う癖(たとえばKPTのTではそもそものPを解消するTryを出すなど)を付けようかと思います。
彼はアジャイルはIT業界のみならず他の領域にも適用できると同じ記事で語っております。
確かに自分自身の経験と照らし合わせても、ロボコンをメカ屋として昔やっていたのですが、ペアプロ ならぬペア設計(ポンチ絵、CAD)すると品質/教育の面など良さそうだなと感じました。
Andrew Hunt (アンドリュー・ハント)
名著「達人プログラマー」の著書ですね。20回も改訂されているそうです
- 新装版 達人プログラマー 職人から名匠への道 | Andrew Hunt, David Thomas, 村上雅章 |本 | 通販 | Amazon
「恥ずかしがりなコード」「曳光弾」など面白いフレーズでプログラマとはどうあるべきか解説してくれてます。
ソフトウェア開発は「ビルの建設」に例えられるが実際は「ガーデニング」の方が近いというのも納得です。(一度作ったら終わりにはならない。ITゼネコンというのもやはり無理がある気がしますね。ITアグリカルチャーのほうがフィットしそう?)
章末に問題があり理解度の確認ができたり、最後にフレーズのまとめがあり言いたいことがまとまっているのも良かったです。
wikipediaによると、トランペットやホルン、キーボードなど楽器も演奏できるとのこと。多才ですね。。
Ken Schwaber (ケン・シュヴァーバー)
Jeff SutherlandとともにScrumの提唱者。Scrum.org (incではなくorg)を創業されてます。
現在もブログ執筆中でスクラムについて継続的に発信されてます。
Scrum Guideに彼の伝えたいことはまとまってそうです。
Alistair Cockburn (アリスター・コーバーン)
DDDの文脈などで登場するヘキサゴナルアーキテクチャの提唱者。
Heart of Agileというコミュニティを運営されているそうです。
Tweetを見る限り陽気なおじさんの模様ですね^^
https://twitter.com/TotherAlistair/status/1282338829014376448?s=20
Ron Jeffries (ロン・ジェフリーズ)
Kent BeckおよびWard Cunninghamとともに、1996年頃のXPソフトウェア開発方法論の3人の創設者の1人。
彼の名で検索すると最初にヒットするのが、Ron Jeffriesが、開発者は"Agile"を捨てるべきと発言という衝撃の記事ですが、内容はアジャイルの根底にある思想を理解せずにプロセスのみを採用するから"ニセアジャイル"や"ダークアジャイル"になってしまいそれなら捨ててしまった方が良いということでした。この辺りは指摘はプロセスを重視しすぎないことを指摘したJames Grenningと似てますね。
記事の中で重要なこととして下記3点が挙げられてます。
- 完了すべき作業を選ぶこと。動くソフトウェアの小さな部品を、2週間毎などにデリバーできるような方法で。
- 期待を下げること。他の人がやっているように、自分のデリバリー能力を理解しなければならない。
- イテレーション毎にデリバーされる小さなインクリメントの最上位にある会話を利用すること。
期待を下げること
とありますが、なかなか難しいですよね ^^;
特に経験があまりないとやるべき作業を過小評価してしまい、できないこともできるといってしまいがちなので気を付けねばと感じる次第でした。。
Jeff Sutherland (ジェフ・サザーランド)
Scrum Inc. の創業者ですね。彼のScrum人生は著書「Scrum」を読んで知りました。
- スクラム 仕事が4倍速くなる“世界標準”のチーム戦術 | ジェフ・サザーランド, 石垣賀子 |本 | 通販 | Amazon
本、およびwikipediaによると彼はもともと軍人でかなり屈強な方ということが窺い知れます。
孫正義の病気した話然り、人間は一度死ぬ思いをするとかなりタフになりそうですね。
ベトナム戦争から無事帰ってきた後、統計学の修士号さらには生物統計学の博士号を取り、その研究力で過去の成功プロジェクトと失敗プロジェクトを分析しスクラムを生み出したそうです。
こちらにJeffの一問一答集の和訳が掲載されており(ありがとうございます!)
拝見しましたがScrumマスタの役割やScrumチームをScaleするときにはアーキチームがあったほうがよいなど参考になることも多かったです!
Ward Cunningham (ウォード・カニンガム)
Wikiを開発し、デザインパターン、XP のパイオニアで、CRCカード、Fit、そして技術的負債といった様々な生み出した物凄い人のようです。
参考: 君はWard Cunninghamを知っているか?(前篇)
無知故初めて存在を知りましたが、ソフトウェアの世界を前進させた非常に重要な人物ですね!
Jon Kern (ジョン・カーン)
Javaの本を執筆されていたり、Technical Debt(技術的負債)というブログも書かれております。ブログ名にするほど技術的負債を解消することにこだわりがあるのが伝わってきます。
TwitterやGithubのアカウトもあり、リポジトリを見たところ、Rubyが好きなようですね。
Dave Thomas (デイブトーマス)
Andy Huntとともに達人プログラマを執筆された方です。
twitterの自己紹介の部分にProgrammer turned publisher (but mostly programmer)
と書かれるほどアジャイルコーチというよりプログラマを感じます。
実際に「プログラミングElixir」 「プログラミングRuby」といった様々なプログラミング言語の本も執筆されております。
Agile is Dead という彼の講演をタイトルが気になってチラッと見たのですが、その中でスクラムはプロセスが重視されがちであり、それをいかに各チームに取り入れ発展させるかが忘れ去られがちのがよくないとおっしゃってます。プロセスに従うだけでは意味がなく、その背後にある価値観を理解し、各々の置かれた状況に適応させていくことが重要と言うことで、他の方が警告している内容と似てます。
Martin Fowler (マーティン・ファウラー)
絵ではホワイトボードに立っている人かと思われます。
マイクロサービスの提唱者であり、名著「リファクタリング」の執筆者ですね。XPやUMLの本も執筆されております。
- リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES) | Fowler, Martin, 公信, 児玉, 晶夫, 友野, 章, 平澤, 真史, 梅澤 |本 | 通販 | Amazon
「リファクタリング」は第1版はJavaで、第2版はJavascriptでリファクタリングの方法を具体的なコードを通じて示してくれます。(たとえばEnumはFactoryでのみ使って、安直にifやswitchを使わずにポリモーフィズムで表現しよう、などなど。)
この本のおかげで私のコードもいくらか臭みが減ったように思いますので名著の中でもおすすめです!
Brian Marick (ブライアン・マリック)
Twitterのプロフィールによると Programmer → tester → test consultant → agile consultant → programmer
という一周してプログラマ になった方のようです。
Common Lispを現在のコンピュータアーキテクチャに移植するプロジェクトののTechLeadになったことでプログラミング言語のマニアになったそうで、関数型プログラミングの本やRubyの本を執筆されてます。
Lispといえばロボットの授業で習ったEusLispが懐かしいですね... やたらとカッコ((()))つけたがりな言語のイメージです ^^;
当時はプログラミングもよく分かっていなかった(今も分かってないですが^^;)ので初心者にも分かり易いpythonに逃げてた気がします。
以上、十七人のアジャれる男でした!
一口にアジャイルと言ってもそれぞれScrumやXPなど流派が存在しているみたいで勉強になりました。やはり同じ流派の人々の方が本を共同執筆されてたり仲が良さそうですね。
17人に共通して言えるのは、アジャイルは「する」(形式だけを取り入れる)ものではなく、マインドセット的なものということでしょうか。 Don't Do Agile. Be Agile
そのため20年たった今でもアジャイルマニフェストはそのマインドを形成するためのものとして有用そうですね。
ぜひマニフェストや彼らの本をお読みになってコロナに負けない快適なアジャイル生活をお送りください!