書籍「Tidy First?」読書会を始めます

　大事なことと宣伝は先に言っておけ、と教わったので実践。
掲題の通り、書籍「Tidy First? ―個人で実践する経験主義的ソフトウェア設計」の読書会を始めます。ぜひご参加ください。

• 書籍『Tidy First?』読書会 第0回 - connpass
• 書籍『Tidy First?』読書会 第1回 - connpass

connpassグループも新しく立ち上げましたので、良かったらご参加宜しくお願いします。

tdd-reading.connpass.com

Tidy First? ―個人で実践する経験主義的ソフトウェア設計

　さて、ここからは蛇足で、読書会開催に至った背景説明です。参加申込していただけたなら読む必要はないのでご自由にどうぞ。

　長らく取り組んできた、書籍「テスト駆動開発 (オーム社／ケント・ベック著／和田卓人訳)」モブ写経読書会が今年に入ってすぐの回でついに完走しました。

takigawa401.hatenablog.com

テスト駆動開発

　オンラインでモブプログラミングで写経を行う、という手前味噌ながら中々チャレンジな企画でした。
開催直後は20人程度ご参加いただいていたものの、徐々に人数が減って、常連さんが3～4名という状況に落ち着きました。
「テスト駆動開発」という書籍は大雑把に言うと、前半が実践で後半が解説、という構成に分けられるのですが、たまに新しい方が参加されると「やはりコードを書いているところを体験してほしい・見てほしい」ということで、敢えて書籍の第1章に戻って読み直し・写経し直しをやったりもしました。第1章だけで10回以上読んだんじゃないかしら？
　そんなこんなで、ずいぶんと遠回りも寄り道もしましたが、開始して隔週ペースで2年で完走できたというのは感慨もひとしおです。

　さて、「テスト駆動開発」も読み終わって次何しようか？と運営メンバーや常連さん含め議論になったのですが、まぁなかなか決まりませんでした。

　元々この活動は「テスト駆動飲み会」の派生イベントでして、ゆるやかに自分たちも楽しむことを主題におきつつ、テスト駆動開発を知ってもらう・上手になっていくことを目指していました。

takigawa401.hatenablog.com

　やがて我々運営メンバー自身のマンネリ化を避けるために始めたのが読書会でして、せっかく読むのならちゃんと写経しようと、オンラインでモブでTDDを、というスタイルでスタート当初から走り出しました。途中ツールを変えたりと多少の紆余曲折はあったものの、概ね上手く進めることができたんじゃないかなと思います。
　なので今までのスタイルや大義……というと大袈裟ですけど目標と言うか目指すものは同じにしたいなぁという思いがありました。明文化すると

• もっと上手にコードを書けるようになりたい
• テスト駆動開発をもっと上手くできるようになりたい
• 読書会だけどコードは書きたい

みたいなところでしょうか。なので次に読む本もこの辺を引き続き踏襲できる本がいいなぁ、と思っていました。が「テスト駆動開発」ほどみんなの思い入れが一致する本が見当たらず、本選定に難航しちゃったんですね。いくつか候補は出たんですが、どれも決定打がないというか。
　そんな最中、「Tidy First?」が発売されました。元々発売前から話題になっていたこと、「テスト駆動開発」と同じケント・ベックが著者であること、コードの書き方そのものに言及していること、あとは薄くて章の区切りが短いから「読書会向けで深く議論するのに向いてるかも」「毎回参加できない人でも章が短いから区切り良く参加できるかも」というような話になり、「コードは書けない(写経できるところはない)けど、次のモブ写経読書会までのつなぎ的な読書会ならやれるか」となった次第でして、なんというか中継ぎピッチャーみたいな位置づけで「Tidy First?」に登板してもらうことになったわけです。

　今のところ、半年くらいで読み切れるといいなぁとかボンヤリ思っています。その間に次の「コードが写経出来てコードを書くことが上達できる本」を探せればなお良いですね。

　読書会の進め方ですが、次回2/21(金)の第0回は「どうやって読書会を進めていくか」を試していく時間にしたいと考えています。その回のフィードバックを以て満を持して3/07(金)の第1回に臨みたいです。なので、読書会の作り方から見てみたい方は次回2/21(金)の第0回から、純粋に本を深く理解したい方は3/07(金)の第1回からご参加いただければと思っております。それ以降は当面は毎月第一・第三金曜日に開催予定です。運営の都合が合わない場合には別日程での開催やそもそも不開催にする場合もあるのでどうぞご了承ください。

　蛇足のさらに余談ですが、今までの「テスト駆動開発」のモブ写経読書会はテスト駆動飲み会と同じconnnpassグループでイベントを立てていましたが、今回の「Tidy First?」の読書会では新たにconnpassグループを作りました。どうもconnpassの運営元が手動で検索設定や優先表示を変えているという噂があり、オレらのイベントがconnpassのTOPや一覧に出てこないみたいなんですよねぇ。まぁ飲み会だからしょうがないか、と思ってたんですが、読書会は極めてまじめにやっている (ホントか？) ので多くの方に参加いただきたいですし、そのためには！と新しいconnpassグループを作るに至った次第です。

　ちょっとだけ頑張ったから沢山の人に参加して貰えると嬉しいなぁ。ついでに定着してもらって本の最後まで一緒に完走出来たらもっと嬉しいです。

Management3.0のワークショップ「Moving Motivators」用カードアセットの公開

　この記事はManagement 3.0＆人にやさしい組織マネジメント勉強会 Advent Calendar 2024 - Adventarの9日目です。

　Management3.0には「Moving Motivators」というワークショップがあります。自身の内発的動機付けを探り、その過程を言語化して他人とディスカッションすることで、自分にとって何が大事か、他人は何を大事にしているかを知ることができる、というワークショップになっています。
　詳細は以下の記事をご参照ください。

nuworks.jp

　もしくは、我々が運営・開催している「人にやさしい組織マネジメント勉強会」にご要望頂ければ、ワークショップの体験会を開催します。
長ったらしい名前で妙に胡散臭を感じるかもですが、人が働きやすい組織や会社のマネジメント手法を主に取り扱う勉強会ですんで、別に怪しくないよ！

https://management30.connpass.com/management30.connpass.com

　さて、この「Moving Motivators」というワークショップ、10種類のカードが必要でして、そのカードは以下サイトで無償配布しています。

management30.com

　ただ、カードのデザインが、なんというかイケてない……。
海外の方が作ったものなので日本人の感覚にフィットしないと言いましょうか……。
あと英語表記なんで日本人が使うのにパッとなじまない気がしまして。

　という訳で、自分で日本人向けに「Moving Motivators」のカードを作ってみました！

　以下からダウンロードできます。
https://drive.google.com/file/d/1x9rTEPPpmSN22fp6dcopKfw34i4qkUv2/view?usp=sharing

　こだわりポイントは、できるだけシンプルなデザインにしたこと、オリジナルのカードに掲載された文章だけだと恣意的すぎるので、辞書的な意味も掲載したことです。
　一番のお気に入りは「自由」のカード。ずいぶん前に見たこのツイートがずっと心に残っていて、それをそのまま表現しました。

ドラクエで、船とかゲットして行動範囲が一気に広がって、どこに行って何をしていいか全く分からなくなることあるよね？あれが、『自由』です。

— takaneet (@takaneet) 2010å¹´12月5æ—¥

　ぜひご活用ください。使用した際には、特にご連絡とかは頂かなくて大丈夫ですけど、由来とかを周知してもらえるとオレが喜びます。

人はHTTP STATUS CODEによってその存在を定義あるいは説明できるのか、またはその思考実験

初めに

　この記事はいくおの Advent Calendar 2024 - Adventarの8日目です。

　はじめまして、タキガワヨーイチといいます。今回あえて自称を「ヨウイチ」ではなく「ヨーイチ」としたところが今回の要素で、それゆえこの後すぐ出てきますがしかしながら試験にもこの後の貴方の人生にも一切出てきませんのでこの記事読み終わったら忘れていいです。加えて言付けしておくならタキガワヨーイチもタキガワヨウイチもその存在自体も忘れていいです。
　読んでいる貴方にとって大事なのは、貴方は「いくお」の縁に導かれてたまたまこの記事にたどり着いた、ただそれだけです。

　「いくお」を崇め奉り信じよ、さすれば救われん。

　さて、オレごときがかの著名且つ偉大であり、町田が誇る唯一無二で天上天下唯我独尊なSGEM*1であられる小田中育生さんを語る資格があるのか、と問われれば、おこがましくもそのような立場を望むことさえ許されないですしそのようなことを頭によぎった瞬間に今すぐ腹を斬って死ぬべきだと判断して腸をその場にぶち撒けるのが正しい所作だと世界の摂理に定められておりますが、これが「いくお」であればその限りではありません。なぜならばオレと「いくお」との間には僅かながら共通点が存在します。

　聡明な読者の方は既にお気づきですね？

　そう、語呂合わせです。

　「いくお」は「１ (い)」「９ (く)」「０ (オー)」と語呂合わせにできます。
同様に「ヨーイチ」も音で分解すれば「ヨオイチ」つまり「４ (ヨ)」「０ (オー)」「１ (イチ)」と語呂合わせにできます。
「０」を数字のゼロではなくアルファベットの「O (オー)」でこじつけるのも一緒です。

　また重要な点として、２つの語呂合わせが双方とも3桁の数字であることにも着目しましょう。パッと思いつく3桁の数値とは？ そう、HTTP STATUS CODEです！

　というわけで、本記事ではHTTP STATUS CODEというたった3文字の数値から「いくお」という存在を紐解いてみましょう。
(なお、本記事における主張や論法がやや強引だという意見は認めるが、本記事においては敢えて無視するものとする)

HTTP STATUS CODE とは？

　さて、3桁の数字でHTTP STATUS CODEに思い至るのがあくまで世界の摂理のように話を進めてきましたが、決してそんなことはないので知らない人のために簡単に説明していきます。
長ったらしくて読むのが面倒な人は引用箇所はすっ飛ばして大丈夫です。

HTTPステータスコード

HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードである。RFC 7231等によって定義され、IANAがHTTP Status Code Registryとして管理している。

引用元 : HTTPステータスコード - Wikipedia

Request for Comments (RFC)

IETF（Internet Engineering Task Force、インターネット技術特別調査委員会）による技術仕様の保存、公開形式である。内容には特に制限はないが、プロトコルやファイルフォーマットが主に扱われる。
RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。今日では、Internet Engineering Task Force (IETF)やインターネットアーキテクチャ委員会 (IAB)、およびコンピュータネットワーク研究者の世界的なコミュニティの公式発表の場となっている。

引用元 : Request for Comments - Wikipedia

Internet Assigned Numbers Authority (IANA)

Internet Assigned Numbers Authority（IANA、アイアナ、インターネット番号割当機関）とは、インターネットに関連する識別子を管理する機能である。IPアドレス・ドメイン名・トップレベルドメイン・ポート番号等の割り当て・管理などを行う。
アメリカの南カリフォルニア大学のISI所属のジョン・ポステルが中心となって始めた。当初は運営費用の一部がアメリカ政府により援助されていたが1998年にICANNが発足するなどインターネットの管理体制が変化し、2000年にその役割はICANNに引き継がれ、IANAはICANNにおける機能の名称となった。2016年からはICANNの子会社であるPublic Technical Identifiers (PTI) がその機能を担っている。

引用元 : Internet Assigned Numbers Authority - Wikipedia

　語源をいくつか引用しましたが、要は「インターネットで閲覧しようとしたサイト・サービスの状態を知るための3桁の数値」を指します。有名なのは「200 OK」とか「404 Not found」とかですね。

　HTTP STATUS CODEには100番ごとに大きな区切りがあり、以下のように定義されています。100, 200, 300系が正常系で、400, 500系が異常系……つまりエラーであることを指します。

• 100ç³» : 情報 - リクエストに対して処理が続行されていることを示す
• 200ç³» : 成功 - リクエストが正常に処理されたことを示す
• 300ç³» : リダイレクション - 追加のアクションが必要であることを示す
• 400ç³» : クライアントエラー - リクエストに問題があり、処理できなかったことを示す
• 500ç³» : サーバーエラー - サーバーに問題があり、処理できなかったことを示す

　その3桁の数字が担うメッセージの役割が、100番ごとに大きく区分けされ、さらにその中で細かく定義されています。例えばオレの「401」ですが、以下のように定義されています。

401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field containing at least one challenge applicable to the target resource.
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

401（Unauthorized）ステータスコードは、対象リソースに対する有効な認証資格情報が不足しているために、リクエストが適用されていないことを示します。401レスポンスを生成するサーバーは、対象リソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダーフィールドを送信しなければなりません（MUST）。
リクエストに認証資格情報が含まれていた場合、401レスポンスはその資格情報による認可が拒否されたことを示します。ユーザーエージェントは、新しいまたは置き換えられたAuthorizationヘッダーフィールドを使用してリクエストを再送することができます（MAY）。401レスポンスが以前のレスポンスと同じチャレンジを含み、かつユーザーエージェントがすでに少なくとも一度認証を試みている場合、ユーザーエージェントは通常、診断情報を含む関連する表現をユーザーに提示するべきです（SHOULD）。

引用元 : RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication / 翻訳 : ChatGPT

　早い話が「(例えばID/PWなど、なんらかによる)認証が必要なのに、認証を行うための情報が無い (もしくは間違っている)よ」という意味です。端的に言うと「認証エラー」ですね。

　ちなみに、「HTTP STATUS CODE 401 Unauthorized」はRFC 7235で定義されました。RFC 7231にはまだ定義されてなかったんですが、その時点で401は抜け番となっていた模様。RFC 7235は認証に関する定義を行っているので、RFC 7231では掲載を見合わせてたのかもですね。この辺はもうちょっと調べてみたいところです。
　さらに加えて、よく同じ意味合いで混同されがちな「HTTP STATUS CODE 403 Forbidden」ですが、こちらは権限エラー、つまり閲覧したり実行する資格を持ってないので閲覧・実行できない状態のことを指します。
401が認証していない、403が認証はしたけど権限が無い、と理解しておけば大まかには良さそうです。
詳しくは以下の記事に説明があるので、興味がある人は読んでみてください。

www.freecodecamp.org

　HTTP STATUS CODEによると、つまりオレ(401)は以下のような存在であることが定義・説明できます。

• 異常系である
• クライアントエラーである ＝ 当人に問題がある
• 認証を行っていない存在である
• 権限を持っていないかどうかまでは定かではない (未認証のためその段階に至れていない) 存在である
• 当初はその定義がなされておらず、後追いで定義された ＝ アウトローな存在である

　これがどこまで正しいかについては、あくまで第三者の目から極めて冷静に検証・定義されるべきだと思いますので、ここではオレ自身からは言及を避けたいと思います。

本題：「190 (いくお)」をHTTP STATUS CODEから定義づける

　さて、本題の「190」です。が、実はRFCにはHTTP STATUS CODEって100～103までしか定義されてないんです。ΩΩΩ<ﾅ､ﾅﾝﾀﾞｯﾃｰ

• 100 Continue : 継続。クライアントはリクエストを継続できる。サーバがリクエストの最初の部分を受け取り、まだ拒否していないことを示す。
• 101 Switching Protocols : プロトコル切替。サーバはリクエストを理解し、遂行のためにプロトコルの切り替えを要求している。
• 102 Processing : 処理中。WebDAVの拡張ステータスコード。処理が継続されて行われていることを示す。
• 103 Early Hints : 早期のヒント。最終的なレスポンスヘッダが確定する前に、予想されるヘッダを伝達する。Linkレスポンスヘッダと組み合わせて、関連するリソースの先読み・プッシュ配信に利用することが想定されている。

引用元 : HTTPステータスコード - Wikipedia

　本当に無いのかと調べていたら、なんと見つかりました！MastercardのAPIが190を定義・利用していることが分かりました。
mc-paymentgatewayservice.my.site.com

　エラーの内容としては「キャプチャ方法が指定されておらず処理が継続できない」ことを指しています。が、RFCで定義されておらず他でも見当たらないので、Mastercardが独自に定義し利用しているものと判断できます。
　このドキュメントを見る限りではクライアント起因のエラーに見えるので本来なら400系を割り当てるのが適切な気がしますし、そもそもとしてこの190がHTTP STATUS CODEと断言できるような記述箇所は無いので、このAPI内独自のコードとして取り扱っているのかもですね。
　ただ、RFCに定義されていないからと言って、他者に迷惑をかけない範囲で身内で閉じてHTTP STATUS CODEの拡張として定義→使用する分にはそれほど問題ない気がします。

結論

　さて、ここまでのまとめです。

　HTTP STATUS CODEから「いくお (190)」を定義・説明しようとした場合、以下のような結論が得られます。

• 「いくお (190)」は正常 (100) ç³»
  • 「いくお (190)」は処理継続中であることを表す
• 「いくお (190)」はRFCでは定義されていない
  • RFCで定義されていないからと言って使っていけないわけではない
  • 他者の迷惑にならない範囲で定義・利用するのであれば問題はない

　言葉にまとめるのであれば以下のようになるでしょう。

「いくお (190)とは、正しい行いを行っている姿・様子・存在であり、それは現在も進行中であることが見て取れる。だがしかし世界の誰かに定義されるような存在ではなく、信望する者の心にのみその在り様が刻まれるものである」

　納得感しかないですね。HTTP STATUS CODEからも十分に「いくお」という存在を定義・説明できることが確認できました。

提案

　誰もが頷く結論を導き出すことができたのでオレ個人としては満足しており、ここで筆を置くこともやぶさかではなかったのですが、しかして提言者としてこのまま放言して省みないのも無責任かなと思いました。最後に「190 (いくお)」についてさらに踏み込んでみたいと思います。

　結論で示した通り、「いくお (190)」とは正常系であり処理継続中であり、誰かの定義の枠にはまることなく、己が道を行く存在として独自にその姿勢を示すことができる、そんな存在であることは既に誰も疑うことができない事実であります。
　ですが、「処理継続中」とはなんでしょう？「190」とはどのような状態を継続している様子を指すステータスコードなのでしょうか？

　そんな最中、我が探検隊はネットの奥地でこの世の真理に重要な影響を及ぼす証拠を発見したのであった！

発見現場 : https://x.com/dora_e_m/status/1832027593362858481/

すなわち！「いくお (190)」とは！「ビールを飲んでいる状態 (継続中)」を指すものだったのだ！！

用例：

• 「おっ！花金*2の夜にさっそく190ってますね」
• 「あーごめん、今ステータスコードが190だから車で迎えに行けないわ」

　今後はビールを飲んでいる様子を表す際は「190」を使用されるのが宜しいかと思います。

終わりに

オレからの調査報告は以上です。
明日からも継続される更なる「いくお」に関する調査報告に、一研究者として期待し、座して待ちたいと思います。

※本記事の内容はすべてギャグです。真に受けないように。

*1:スーパーグレードエンジニアリングマネージャー、元ネタが分からない人はキャプテン翼を読め

*2:死語。なお同義語の「プレミアムフライデー」も既に死語となっている

çµ„ç¹”ãƒžãƒã‚¸ãƒ¡ãƒ³ãƒˆã«é–¢ã™ã‚‹æœ¬ã«çµžã£ãŸãƒ“ãƒ–ãƒªã‚ªãƒãƒˆãƒ«ã§ç™»å ´ã—ãŸæ›¸ç±ã‚’ä¸€æŒ™ç´¹ä»‹

はじめに

management30.connpass.com

　先日こんなイベントを開催しました。
　宣伝が足らんかったのか、そもそも興味を引く内容になっていなかったのか分かりませんが、残念ながら運営メンバー含めても参加者が4名しかいないという残念な状況だったんですが、少ないながらもイベント自体は大いに盛り上がり、参加者みんなで良い議論が出来たと思っています。

　せっかく良い内容だったのに4人しか知らないのも勿体ないなぁと思い、せめて紹介された本だけでもシェアしてみようと思います。気になった本があればチェックしてみてください。

ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた

ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた

中原さんの紹介。ソフトウェアを作っているのは人なので、人に起因する泥臭い失敗が赤裸々に語られているから、とのこと。
ちなみにこの書籍については、次回の「人にやさしい組織マネジメント勉強会」のイベントで著者の方にご登壇頂きます。
management30.connpass.com

転生したらスライムだった件

転生したらスライムだった件 21 (GCノベルズ)

てらひでくんの紹介。多様性、権限移譲、エンパワーメント、リーダーシップ、これらのことが書かれている、とのこと。
完全に余談ですが、アニメ化している結構有名な作品なのにオレは未視聴です。主人公、あの水色の髪の少年ですよね？スライムじゃないじゃん！っていつも思うんですよね。てらひでに説明してもらったけど納得いってなくて、今後も多分見ない。

職場にコンパッションを目覚めさせる

職場にコンパッションを目覚めさせる

ちのさんのご紹介。コンパッション (compassion) とは、自分や相手を理解し、思いやりを持って接すること、あるいはその感情を指します。ちのさんは最近管理職に就かれてその仕事の仕方に悩んで色々勉強しているうちにこの本にたどり着き、感銘を受けたとのこと。

岡田メソッド――自立する選手、自律する組織をつくる16歳までのサッカー指導体系

岡田メソッド――自立する選手、自律する組織をつくる16歳までのサッカー指導体系

オレが紹介した本です。言わずとしてた元サッカー男子日本代表監督で、現在はJ3 FC今治のオーナーである岡田武史さんの書かれた本です。おそらくは最もこの世で最も重圧のかかる仕事のひとつであろう日本代表監督という立場でいかにチームを作り上げるか、そのポリシーとフィロソフィーが書かれています。本自体はサッカーの本なので、サッカーの具体的な技術や戦術にが大半であり、組織マネジメントだけ学びたい人には蛇足に思えますが、言語化やパタン化といった観点ではそういったサッカーについて書かれた部分も参考になるかと思います。

夜明けまで１マイル　somebody loves you

夜明けまで１マイル　somebody loves you (集英社文庫)

てらひでくん2周目。「村山由佳の本を紹介したかった」(本人談)。本当は「天使の卵」を紹介したかったんだけど、圧倒的に自分のやりたいことをやりたくなる衝動があってそれはだれにも止められない みたいな話で、これだと人にやさしくないなーと考え直して、 バンドとメジャーデビューと嫉妬の中で揺れ動くリーダーの感情の話をしたいと思ってこの本を紹介した、とのことでした。なんだかもう良く分からんがとにかく面白いらしい。

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書 2362)

中原さん2周目。生産方式よりも価値がある（売れる）製品をいかに開発するか、について書かれた本です。人のコラボや役割の重要性も含めて語られている、とのこと。今回のビブリオバトルでは栄えあるチャンプ本となりました。

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

中原さん3周目。UMLの形式的な活用よりも、コミュニケーションや関係者間の共通理解を得る方法としての活用方法が語られているから紹介した、とのこと。ちなみに現在は絶版のようです。

実践ソフトウェアアーキテクチャ

実践ソフトウェアアーキテクチャ

中原さん4周目。アーキテクトっていう具体的に何をやるか、どうやるかわからない役割に対して、具体的に何をやるのかを解説している、とのこと。言語化と伝え方の話ですかね。やっぱり現在は絶版のようです。

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標

中原さん5周目。アジャイルを組織に導入する時の説得材料として、人系も含めて参考になるネタが多い、とのことでした。アジャイル関連本としては名著で有名ですね。

おわりに

　栄えあるチャンプ本は中原さんの紹介してくれた「トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業」になりました。ビブリオバトルはやってみると分かるけど、本の面白さや表装の魅力も大事なんですが、それ以上に発表の上手さや魅力が肝になりそうだなという印象を得ました。たまにこういうのやると面白いですね。
　本来ビブリオバトルは1人1冊なのですが、今回は参加者数も少なかったのもあり、時間の許す限り何冊でも紹介していいルールにしています。最終的に投票するのは「発表者」ではなく「本」なのは公式ルールと一緒でしたけどね。
　ちなみに中原さんは5冊も紹介してくれましたが「まだまだ紹介したい本がいっぱいある」とのこと。あのまま放っておけば一人ビブリオバトルができそうだったんで、「ご自身のキャリアと読んだ本を照らし合わせた発表を考えてみたらどうですか？」とオレから提案したところ、案外乗り気だったっポイです。そのうちそういう発表を中原さんがしてくれるかもしれませんね。期待して待ちましょう。

TOCfEのクラウド(対立解消図)を実践的なプロセスで使ってみる - 車を買い替えるなら？

tocfebc.doorkeeper.jp

　先週日曜に以前運営に参加していたTOCfE Bootcampのイベントがありました。たまたま近くにいたのでフラッと寄ったんですが、久々に真剣にTOCfEに取り組んでいる人たちの様子をとても興味深く見させてもらいました。

　で、参加者からの質問を聞いていると、以前から知ってる人間からするとやっぱりというか案の定というか、この日のテーマの「クラウド」……「対立解消図」とも呼びますし、オレ個人は「クラウド」と命名された経緯があまりに意味不明なので「対立解消図」の呼称の方をよく使いますが……の使い勝手がイマイチ分からない様子が伝わってきまして。

• 二項対立なら使えるけど実際には三項対立もあるのでは？そんな時どうやって使うの？
• 目標がフワッとし過ぎててイメージできない
• 対立する2つの行動に対して同じ目標が出てこなかったらどうするの？
• etc...

　その解決の手助けになるかどうかは分からないですが、現時点でオレがどんなふうに「クラウド(対立解消図)」を使っているか、そのプロセスをほぼノンカットで書いてみようかなと思います。

　TOCfEの「クラウド(対立解消図)」というツールは上の図のようなシンプルなものです。
　ここまで「TOCfE」もその源流である「TOC」についても一切説明してきていませんが、以前オレが自身で書いた記事があったのでそちらを参照してください。
　(今見ると「何恥ずかしいこと書いてんだオレは！？」って赤面しますね //// )

takigawa401.hatenablog.com

　さて本題。
　オレが最近悩んでいたのは「車の買い替え」についてでした。その悩んでいたプロセスを「クラウド(対立解消図)」を使ってざっくり紹介します。

　「車を乗り換える」か「乗り続けるか」で悩んでいた、というところからスタートします。
　時系列でいうと、「車を買うか買わないか」みたいな判断もありましたし、もっと言うなら「故郷に帰るか帰らないか」みたいな判断もさらに前にあったわけですが、ここで決定事項を掘り返すのは時間の無駄なのでやめておきます。

　割と近年、生まれ故郷の信州伊那谷に戻ってきたんですが、そのタイミングで中古で車を購入しました。田舎なので車が無いと生きていけない……とまでは言わないがそれなりに不便なので、車を買うのは決めていたんですが、20年以上ペーパードライバーだったのでどうせ散々ぶつけるだろうとクッソ安い中古の車を探したところ、母が懇意にしていたディーラーさんから2003年のスズキパレットが35万円で出てきまして、即決で購入した次第です。ボコボコに乗り潰して1年くらいで新しい車に乗り換えようと思ってたんですが、思ったよりちゃんと走ってくれるし乗っていて楽しくはあるし、何より自由に移動できる足があるのは便利ってなことでなんのかんのと4年も乗っていました。まだ元気に走ってくれていますが、さすがにそろそろ年式的に不安にもなりますし、そこそこぶつけて(だいたい立体駐車場や都会の小さいコインパーキングでやらかす)ところどころ痛んでるし、まぁそろそろ限界かな、と。今年の一月で車検も切れるので、このタイミングで廃車にして新しく車を購入しようと決意したわけです。

　　　　　　　　↓

　　　　　　　　↓

　で、それぞれについて考えるわけですが、新しく乗りたい車があるわけじゃないけど、そもそも今の車に漠然とした不安を持っていてそれが解消できないので、安全に車に乗り続けることができるようにするには新しい車に替えた方が良さそうだ、という判断をオレはしました。
　もしオレが車にもうちょっと詳しかったり車の運転・所有経験がもっとあったら別の決断になったかもしれませんね。

　車を買い替えることは決めました。では次に「買うならどういう車にするか」を決める必要があります。
　色んな基準があると思いますが、車に詳しくないオレに判断材料は少ないので、まずは「今と同じような車にするか」「別の車にするか」で考えることにしました。

　　　　　　　　↓

　まず「今と同じような車にするか」について考えるわけですが、そもそも今の車自体に不満があるわけではなく、古くなってしまったことによる漠然とした不安が原因で買い換えを決意したので、同じ車でもまいっかな、とは思う訳です。とはいえ、全く不満がないわけでもない。でもそれが別のタイプの車に変更する決め手にもならない。なんともまぁハッキリしないわけです。　

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　　　　　　　　↓

　続いて、他のタイプの車を検討してみます。
　沢山荷物を載せられる車はどうだ、とか、沢山人を載せられる車はどうだ、とか、いっそ走ることだけを目的とした車にしてみるか、とか無難オブ無難にしてみるか、とかとか。
　でも想像していくと、ピンポイントで役立つシーンは思いつくんですけど、自分の今の生活の中で乗り続ける時にマッチしなかったり不便だったりとイマイチ自分の中でしっくりこない。

　そのうち「車のタイプを決めたら次は新車にするか中古車にするかで悩む羽目になるだろ」とか余計な先回りの悩み(対立)も出てくるわけです。
　冷静に考えればこれは車のタイプを今の車から変えようが変えまいが必ず発生する悩み(対立)なんですが、この時点ではオレは気づいていない訳です。
　で、車のタイプ選びが暗礁に乗り上げてしまう、と。

　車のタイプが決められないのはある意味では当たり前で、どれも最初のモチベーションである「車が古くなったから買い替えなきゃ」から乖離しているわけです。極端言えば乗れればいいけど、より良い体験がしたくてでもその選択肢がいっぱいあって困ってる。

　で、ここで突然目先を変えるんですねオレは。「そういやお袋が『アンタが新しい車買うなら私に新車を買ってくれ。そしたら私の今の車をあげるから』みたいなことを以前言ってたな」と思い出すわけです。この時のオレは「長らく地元を離れていたし、別にそんな交換条件なくても車くらい買ってあげるべきだろうな」くらいのことを考えてたように記憶しているんですが、いざ自分の車を買い替えるというタイミングで思い出すと「それも悪くないか」と思いました。

　で、ここまでの検討事項は一旦捨てて、「自分の車を買い替えるか」「母の車を買い替えて古い車を譲ってもらうか」で対立構造を作り直して再検討します。

　　　　　　　　↓

　　　　　　　　↓

　まずは「母の車を買い替えて古い車を譲ってもらうか」から検討していくんですが、まぁとりあえず問題なさそうだし、なにより親孝行という大義名分ができるので行動しやすい。

　　　　　　　　↓

　つづいて「自分の車を買い替えるか」を検討するんですが、ここまでで散々検討してきているのでもうウンザリしてるんですよね。またおんなじプロセスを踏むことになるし、自分の中で車に対する意欲というか動機が少なく要望が小さいので、誰かに半強制的にでも決めてもらいたい気持ちになっちゃってるわけです。

　「え、でも、お母さんの車を選ぶのでも新車か中古車かで悩まなくちゃいけないのは同じでしょ？」と思うかもですが、実はここには裏事情がありまして。母には車を買う時の条件が明確に決まっているんですね。

• ミニもしくはハイルーフミニ
• ターボもしくはスーパーチャージャーが付いていること
• 色が青系統
• 新車であること

　これが母が車の所有・運転を始めてから数十年、一貫して決まっているので一切悩まなくていいわけです。メーカーと車の種類に希望は無いので、廃車予定のオレの車の車検までに納品できるもので、上記条件をクリアできればOK。

　というわけで、最終的に「母の車を買い替えて古い車を譲ってもらうか」に決まりました。自分で決めきれなくて他人に運命を委ねた感は若干否めなく、多少情けなくもありますが、この際方針が決まればOK！
　今現在、懇意にしているディーラーさんに車を探してもらっていて、ほぼ年内に納車ができそうというところまで話を進めることが出来ました。めでたしめでたし！

　……と、車を買い替えてめでたし！ではこの記事としては終わることができませんね。元々「クラウド(対立解消図)」をどう使うかを紹介するのがこの記事の目的でした。

　ご覧いただいたら分かったかもしれませんが、割と仮説がガンガン上重ねされますし、そもそも対立するものが変わります。行動の元となる要望が曖昧で書き直すこともありますし(今回のケースではなかったけど)、目的も対立構造を成立させるのにイマイチだと書き直します。ドンドン書き重ねて行って最終的に悩みを解決できればOKです。

　で、オレは今回の車の買い替えを検討したとき、わざわざこの「クラウド(対立解消図)」を紙に書き出していません。全部頭の中だけでやっています。頭の中だけでやってるから、お作法的に読み上げチェックとかもあるんですが、そういうのは全部省略しています。(なので、初心者向けに教える内容として伝えると有識者に怒られる)
　TOCfEのツールは思考の非常にベーシックな部分を担うので、ロジカルシンキングツールとしては適用できるシチュエーションが非常に多いんですが、一方でデタラメにコスパが悪いんですよね。書き出して共有してまた書き直して、をやってるととても労力がかかる。他者と協議したり、書き出さないと把握しきれないほど複雑な問題の場合には仕方ないにしても、そうでなければ基本的に自分の頭の中だけで完結できるのが理想かなと思っています。慣れるまではお作法に則ってちゃんと書いて読み上げた方が良いですが、慣れたら読み上げなくてもいいし書かなくてもいい。イチイチ書いてたら日常使いできないですもんね。

　一方で、頭の中だけでこれらのツールを使えるようになるにはそれなりに訓練が要ります。オレも数年間しっかりやりました。ある程度納得感を以てこれらのツールを使えるようになったら、別のロジカルシンキングツールと併用してもいいと思いますし、型にハマらないで自由に使うべきだとオレは思います。

　あくまで今回はTOCfEの「クラウド(対立解消図)」の使い方の一例として紹介してみました。もっと別の使い方もあるでしょうし、同じ問題でも人やタイミングが変わると結論も変わります。そもそもお作法に完全に則った手順ではなく省略・省力化して使っていますが、フットワークよくテンポよくどんどん考えていくツールとして使っていくのがいいのかな、とオレは思っています。

TDDを「テイスティング駆動開発」にしないかというご提案

序文

　このブログもすっかり放置が過ぎて、なんと1年以上更新してませんでした。まぁ今回のように書きたいことがあったら時々書くようにします。文章書くのもそれなりにパワーがいるんですよね。

「テスト駆動開発モブ写経読書会」のご紹介

　掲題の件ですが、そもそもとしてオレの意見ではなく、我々が運営・開催している「テスト駆動開発モブ写経読書会」から出た意見ですので、まずは発端となった「テスト駆動開発モブ写経読書会」から紹介させてください。

tddrinking.connpass.com

テスト駆動開発

　「テスト駆動開発モブ写経読書会」は「テスト駆動飲み会」から派生したIT勉強会で、ケント・ベック著 / 和田卓人(@t_wada)さん訳の名著「テスト駆動開発」(オーム社出版) を、モブプログラミングで参加者全員で読みながらコードを写経しながら理解を深めていく、という会です。活動を開始したのが2023å¹´1月なので、1年半ほど継続しており、毎月第一・第三金曜日に開催していますので、何のかんのと40回以上開催してきておりますが、新しい参加者がいらしたりすると第一章に戻ったりと何度も同じところを読み直したりしてるので、まだ読み終わる様子はありません。初心者の方にも優しくモブプログラミングとテスト駆動開発を体験いただけるように取り組んでおりますので、ぜひ気軽にご参加ください。

本題

　前回の「テスト駆動開発モブ写経読書会」では「テスト駆動開発」の中から和田卓人さんが寄稿された「付録C 訳者解説：テスト駆動開発の現在」の章を輪読していたんですが、その際に「そもそも『テスト駆動開発』の『テスト』という単語のチョイスが日本人には適切ではないのではないか？」という議論になりました。
　日本人が「テスト」という単語から想起するのは、おそらく多くの人は学校の試験……中間テストや期末テストであり、その次に工業製品等の品質テストなんじゃいかなと思います。ソフトウェア開発における「テスト」が持つ語感もほぼ同じで、バグや不具合が無い、仕様通りに動作する、そんなことを確認するための工程を「テスト」と呼んでいると思います。
　もっと言ってしまえば、「テスト」という言葉に対してネガティブな印象を持っている人が多いように感じています。学校のテストにせよ工業製品等の品質テストにせよ、面倒で、準備にも実施にも手間がかかって、成績が悪ければペナルティがある。テストが好きな人がいれば会って話を聞いて正気を問い正したい(※言い過ぎ)。

　実際のところ「テスト駆動開発 (TDD)」に取り組むことでその過程で単体テストコードが書かれ、動作がそれらによって担保されますし、結果としてバグや不具合が少なかったり品質が安定する面はあるかと思います。ですが、「テスト駆動開発」の本質は「設計」にこそあります。実コードを書くためにそのコードのテストを先に書き、テストコードを先んじて書くためにToDoにやるべきことを洗い出す。動作する実コードが書けたらリファクタリングを行いその後の実装や変更を行いやすく整え、リファクタリングが終わったらToDoの再確認とブラッシュアップを行ってまたテストコードから書き始める。この過程はまさに「設計」の工程であり、プログラマが安心感と自信を持って開発を進めるための手法が「テスト駆動開発」です。

　ところが「テスト駆動開発」の実態を鑑みると、「テスト駆動開発」をフワッと理解している人々から「TDDやってれば品質上がるんでしょ？」とか「TDDやってるんならテストは要らないよね」とかいう意見を往々にして言われがちである、ということがあるようです。前述のように「テスト」にはネガティブが印象があるので、みんな可能であればやりたくないし全力で避けたい。「テスト駆動開発」がテストを肩代わりしてくれるなら渡りに船くらいに考えるのもまぁ分からんでもないです。
　確かに「テスト駆動開発」に取り組むことで結果として品質が上がる側面はありますが、設計のためにテストコードを書いている＝品質チェックを目的としてはいない ので、品質テストは品質テストでキチンと実施すべきです。TDDやってるからテストやらなくていい、なんて言われてしまうのは本意ではない訳ですよね。

　じゃあなんでこんなこと言われちゃうのか、というと前述のように「テスト」という単語に対する日本人の認識が誤解を招くのではないか、という意見が我々の議論で出ました。やはり前述の「学校の試験」ですが、英語では「test」ではなく「examination」もしくは「exam」を用いるようです。そもそも用いる単語からして違うみたいですね。工業製品等の品質テストは「quallity test」なのでこちらは「test」で同じなんですが、いづれにせよ日本人が学生の頃から「テスト」という単語に持っているイメージと、ケント・ベックら欧米人が「テスト」という単語に持っているイメージに、若干なれど差異がありそうです。さらに、日本人特有の要素として「テスト」という単語にネガティブな印象を持っているのだとすれば、何か……この場合はその対象が「テスト駆動開発」になるわけですが……に押し付けたくなるのも頷けます。
　であるならば、「Test Driven Development」を日本語訳するときに意図的に超約する……つまり「テスト」に別の単語を用いることで誤解をある程度防げないか、という議論になりました。
　そこそこ現実的なものから荒唐無稽なものまでさまざまな案が出たのですが、一番収まりが良さそうだな、とまとまったのが掲題の「テイスティング」でした。要は「味見」という単語ですが、ワインやウイスキーの熟成具合を確かめるために樽から直接汲んで味を確認する作業も「テイスティング」と呼ぶんだそうです。酒の熟成の過程をテイスティングでチェックする、なんとなく「テスト駆動開発」の開発の過程を上手く表現できている気がしませんか？ たまたまですが「testing」と「tasting」で一字しか違いませんし、略称も「TDD」のままですし。また、自分で作ったものを自ら評価することを「ドッグフーディング」なんて呼ぶこともありますが、これも要は「味見」ですよね (ドッグフーディングは「毒見」の意味合いも強いかもですが)。そういう文脈からも乖離していないので、TDDの最初の「T」を「テイスティング」の「T」に変えるのはそれほど違和感が無いのかな、と思いました。

　……あ、ちなみに、「付録C 訳者解説：テスト駆動開発の現在」では「testing」と「checking」の違いについても説明されています。本文だけでなくぜひ付録も読んでみてください。

終わりに

　議論と言いつつ言葉遊びの戯れ合いなのですが、「テスト駆動開発モブ写経読書会」では「テスト駆動開発」をより深く知るための議論やモブプログラミングを行っています。常連参加者の殆どが40歳以上なのでどうしても懐古厨的な会話になりがちですが、若い人もウェルカムですので、ぜひお気軽にご参加ください。

　余談ですが、今までモブプログラミングには「Replit」を使っていたのですが、先日仕様変更により人数の制約が新たに加わってしまい、今後も使い続けるのが難しくなってしまいました。新しいツールを探さなきゃなぁと頭を抱えていたんですが、そのツールの評価を勉強会の参加者の方が率先して行ってくれていて、運営としては非常に助かっています。確立出来たらきっとどこかでノウハウを公表してくれるんじゃないですかね。

「テスト駆動開発」読書会 å‚åŠ è€…å‹Ÿé›†ã®ãŠçŸ¥ã‚‰ã›

ご挨拶

　新年あけましておめでとうございます。本年もタキガワと(全然更新してませんが)当ブログをどうぞ宜しくお願い申し上げます。

「テスト駆動飲み会」の新しい活動のご案内

　「テスト駆動飲み会」は2018年から活動を開始して、今年でなんと5年目になります。まさかこんなに長く続くとは！
　2019年にコロナ禍に突入してからはオンラインに移行して、そこから3年はオンライン限定で活動をしていますが、変わらず常連の方に愛していただいて、たまに新しい人が来てくれて、見学でなんとなく見に来てくれる人がいて、と細く長くユルく続けてこれています。

　とはいえ、これだけ長く続けていると運営もそれなりにマンネリ化してきまして、そろそろ新しい何かをやりたいね、という話になりました。

　そんな中で運営で話し合っていくつか考えた新しい活動のひとつが、以前から募集しております「プライベートでテスト駆動飲み会」です。開催はまだ1社のみですが、オンラインですと特にコストもかかりませんので、ちょっと試してみたいなと思ったらぜひお気軽にお声がけください。

takigawa401.hatenablog.com

　そして、2023年からの新しい活動として、TDDのバイブルであるケント・ベック氏著、和田卓人氏翻訳の「テスト駆動開発」の読書会を開催します。

テスト駆動開発

コンセプト

　テスト駆動飲み会で開催するにあたって「すべてのプログラムコードはモブプログラミングで書く」は絶対にやりたい、という話を運営でしました。その辺は現行のテスト駆動飲み会と同じコンセプトを踏襲したいと思っています。

書籍の購入

　「テスト駆動開発」の書籍は購入必須です。買っていない方は参加いただくことができません。ご購入いただくのは紙の本でも電子書籍でもどちらでも構いません。

※2023/01/10 追記
参加条件となる書籍の所有は ケント・ベック氏 著 / 和田 卓人氏 訳の「テスト駆動開発」(出版社：オーム社) です。
旧版である ケント・ベック氏 著 / 長瀬 嘉秀氏 訳の「テスト駆動開発入門」(出版社：ピアソンエデュケーション社)のみお持ちの場合はご参加いただけません。

　今回は読書会開催に際して@yattomさんからオーム社に許可を取っていただきました。そのため、オーム社版以外を取り扱うことはできません。
　

日時・頻度

　隔週金曜の19:00-21:00で開催します。
　これまでのテスト駆動飲み会は隔月開催だったので、それと比べると4〜5倍の頻度で開催します。当然これだけの頻度だと、毎回参加は厳しい(それは運営側も含めて)ので、たまに休んでも大丈夫な仕組みを用意しています。詳細は後述

場所

　オンライン(Zoom + Miro)で開催します。

進め方

　基本的には全てモブワークで行います。参加者が多い場合には数グループに分けてZoomのブレイクアウトルームで行います。ドライバー(読み手・書き手)とナビゲーター(聞き手)を交代しながら書籍を読み進めます。気になるところがあればMiroでコメントしていき、コードがあればrepl.itで実際にコードを書いていきます。

　書籍の読み進め方は様々です。初回からグループできるようなら、頭から読み始めるグループ、ランダムに章を選んで読み進めるグループ、と読み出す場所を変えるようにしたいと考えています。ランダムに読む組を作ることで、隔週開催という高頻度で毎回参加できない人でも気兼ねなく参加できるようにしたいと思っています。

お酒は？

　イベント中は飲みません！
　……という話をしたらテスト駆動飲み会の常連の方から「イベント中は無くてもいいので、懇親会で飲む機会は絶対作ってください！」と懇願されたので、オレが運営として参加できる回については懇親会は毎回開催しようかなと思います。(オレが参加できない回はその限りではありません、どうぞご了承ください)

参加方法

　connpassでイベントページを用意します。こちらからお申し込みください。

tddrinking.connpass.com

ターゲット

　どなたでも参加いただけますが、書籍を通しで読んだ人・TDDに慣れている人はもしかしたら良い体験ができない可能性があります。書籍未経験の人・TDDに不慣れな人、いわゆる「初心者」な人ほどウェルカムです。
　一方で、隔週開催という高頻度ゆえに現行の運営メンバーの3人だと多分回らないorバテるので、運営として参加したいという人もウェルカムです。一緒にやれるかどうかはすり合わせが必要ですが、基本は一緒にやれる人が増えたらいいなぁと思っています。

終わりに

　というわけで、新しいテスト駆動飲み会にお付き合いいただけると嬉しいです。
　今年もどうぞ宜しくお願いします。