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バテるので、運営として参加したいという人もウェルカムです。一緒にやれるかどうかはすり合わせが必要ですが、基本は一緒にやれる人が増えたらいいなぁと思っています。

終わりに

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

「ふりかえり」で日本一有名な人のチームはどんな働き方をしているか？

見返り美人図 - 東京国立博物館にて筆者撮影

はじめに

　本記事は「Management 3.0 Advent Calendar 2022」の12日目です。12日目ですがなぜかジングルベルが鳴っている気がしますがきっと気のせいでしょう。うんうんそうだきっと気のせいだ。個人的にはこのアドベントカレンダーと苛烈な記事を交互に書いているような気がしますが、めげずに元気出していきたいと思います。

adventar.org

　全然どうでもいい話ですが、冒頭の写真は今月18日まで東京：上野の東京国立博物館で開催されている(た)東京国立博物館創立150年記念 特別展「国宝 東京国立博物館のすべて」に展示されていた、菱川師宣の代表作「見返り美人図」を撮影してきたものです。国宝展に展示されていましたが「見返り美人図」は重要文化財らしいですね。これと金剛力士像だけ撮影Freeだったので遠慮なく撮ってきました。現在修理プロジェクトで寄付を募っている最中ですので、文化財保護の観点からもぜひご協力をお願いします。オレは掛け軸を買いました。文化財の為だからしょうがない！

www.tnm.jp

本題

　さて本題。

　オレは元々はn次請SIer出身でバリバリの叩き上げの業務系システムエンジニアです。フリーランスに転身して4年目になりますが、現在は、とある大手企業のSaaS製品の代理店販売ビジネスの支援をしています。掲題にもありますが、アジャイルな主要なプラクティスのひとつである「レトロスペクティブ」いわゆる「ふりかえり」に関しては、この日の本において彼の右に出る者はいない、という人物がいまして……おっそうそう！なんかあの黄色い人！最近蛙型宇宙人と知り合いになったとか不思議なこと言ってる人です！そのふりかえり日本一な彼にお誘い頂いて、現在のチームでは今年の2月から働き始めました。

業務内容

主な業務内容はこんな感じ。

• 顧客連絡・調整
• 外販打ち合わせ
• 提案資料作成
• マーケティングリサーチ
• ソリューション提案
• 顧客向けセキュリティチェックシート記入
• 取扱プロダクトに関する技術調査
• 取扱プロダクトのプラグイン開発
• etc…

　後半は一般的なシステムエンジニアの仕事ですが、前半はいわゆる「営業マン」の仕事ですね。現在支援しているチームは代理店販売が主業務なので、当然メンバー個々においても「営業」が主業務です。

チーム構成

　このSaaS代理店販売チームの構成メンバーは7人です。社員は2名で、他5名はオレ含め外注です。

1. 社員。チームリーダー。例のふりかえりの人
2. 社員。他業務と兼任。ふりかえりの人のパートナー的な人
3. 派遣 & 技術SE契約。若手男子。大食らい & 大酒飲み
4. 派遣。マーケと法務、事業計画が得意。すぐ賄賂(高級ウイスキー)を渡したがる
5. 派遣。紅一点。着物の着付けと占いが副業でその筋では超有名らしい
6. 派遣。若手男子。スヌーピーのぬいぐるみを壁にぶら下げている
7. 協業会社。叩き上げのSE。つまりオレ

　この企業は超大手企業に該当し、まぁ有体に言えば資金面で非常に強く社会的な信頼も厚いため受注を獲得しやすいというメリットがありますが、一方でレガシー体質で社内プロセスとかが煩雑だったり、そもそも新しいものを一切受け付けないような風土があったりします。とてもじゃないけど外注メンバーがその辺りに太刀打ちできないので、必然的に社内に対する手続だったり確認だったりは社員2名の役割になります。

　このチームは営業のチームなんですが、一応SaaSを取り扱っているんでITの知識はそれなりに必要です。が、必須ではないし、事実ITに詳しいのは社員の2人とオレだけ、直近で手を動かして開発をやったことあるのはオレだけ、という状態です。なので必然的にIT系の知識が求められる作業はオレが担当することが多くなります。

　メンバーの1人はマーケティングリサーチや事業計画が得意なので、新規事業を考えるときは概ね彼が起点になったり、あるいは中心になったりします。新規事業系は社内フローとの戦いが切り離せないので、前述の通り社員メンバーも必ずここに加わることになります。

　割と重要なのが契約形態で、派遣法について詳しい方ならご存知だと思いますが、依頼主である企業の社員が直接指示を出せるか、とか、3年以上契約する場合にはその派遣社員を自社で雇用しなければならない(んだけど、実際には雇用する企業は皆無なので、3年ごとに派遣側の人が職を危ぶむ事になるというロクでもない運用をされている)決まりがあったりします。
　その辺の兼ね合いなのか、派遣契約の人は社内システムにそこそこ(少なくとも業務に支障のないレベルでは)触れるんですが、協業会社契約になっているオレだけはろくに社内システムに触れない、という面倒な点もあります。これによりオレは通常の営業フローを他のメンバー同様には回せないので、やっぱり必然的に誰かに営業作業の一部を任せたり、あるいはかえって他者の負担が増えてしまうため営業タスク自体を避けざるを得ない傾向にあります。
　じゃあ契約形態見直せばいいじゃん、って話になると思うんですが、それはそれで死ぬほどめんどくさい話が内在しているのでここでは割愛。働き方の解説には関係ないしね。

　とまぁザザーッと書いてきましたが、全員営業マンというのが基本なんですが、契約形態や能力なんかでどうしても得意不得意が出てしまうのは当たり前の話ながら、当然このチームにも存在しますので、その辺を上手に活かして、得意領域を伸ばしてチームとしてパフォーマンスを最大化することを基本的なスタンスとしています。
　外注といえど当人たちが今後伸ばしていきたいスキルや分野があれば、チームとしてそこに投資をする(工数を割く)こともあります。

働き方

　業務は朝9時にスタートです。我々は東京都に3人、神奈川県に3人、そしてなぜか長野県のオレ、とそれぞれ全然別の場所に住んでいます。そのため業務の99.9%をリモートで実施しています。残りの0.1%は、PC受け取りや交換のようなどうしても物理的な品物の受け渡しがあるときに限られます。
　……そういや社員メンバーの1人がこないだインターン生の受け入れ業務で一週間ほど出社してましたが、あれはチームの業務の外なので除外します。(彼がインターン生の対応を行い易いようにチーム全員で彼のサポートを行ったりはしました)

　このチームでは業務時間中は全員が基本的に同じZoomにINすることが義務付けられています。ブレイクアウトルームを複数立てておき、基本的には業務時間のほとんどをブレイク1で作業します。チーム内で個別に相談事があったり、どうしても個人で集中して作業したい場合には、他のブレイクアウトルームに移動してそれぞれ作業をする形です。カメラは基本的にはONにするルールになっていますが、事情があればOFFでもOKとされています。事情は「朝寝坊してメイクを忘れた」とかでもOK。オレもよく8:58に目が覚めてそのまま寝巻きのままZoomにINした時なんかはカメラOFFで作業し、昼休憩時に身だしなみ整えて午後からカメラONにしたりもしてます。事情がないのにカメラONにしてないとリーダーからお小言を頂戴する羽目に遭います。
　Zoomのメインルームは顧客打ち合わせやチーム外の社内メンバーと打ち合わせをするときに用いられます。基本誰かしら顧客と打ち合わせをしているので、メインでのほほんとしている(ex: 昼休みにメインにINしたままごはん食べに行っちゃう)と平然と打ち合わせに巻き込まれます。逆にいうと、来客があるのにメンバーが誰も対応してないとすぐ気づけるので、顧客打ち合わせをすっぽかすことを極力防げる、という別のメリットもあったりします。(別のZoomで打ち合わせを設定しているとこの限りではない)

　月曜から木曜は通常業務を行います。

1. 9:00-9:30 営業案件ステータス確認
2. 9:30-10:00 ラーニングセッション
3. 10:00-17:00 営業業務
4. 17:00-18:00 残務処理

　営業案件はそれぞれ担当者が決まっていますが、風邪や家族トラブルなど不測の事態に備える意味で、全員でステータスチェックを行うようにしています。さすがに朝のわずかな時間で行う確認作業で他人の担当分まで完璧に把握はできませんが、なんとなく動いているかいないか位は把握できるようになります。繁忙期は30分では確認しきれず、10時までめいいっぱいステータスチェックに使ってしまうこともよくあります。

　朝のステータスチェックで時間が余ると、チームメンバー全員共通で学んでおくべき内容を取り扱って学習に充てるようにしています。主には取り扱うSaaS製品の新仕様だったり、社内プロセスを調べて明らかになったことだったり、あるいはマーケティングや会計の基礎だったり、がこれまで扱われてきました。特に取り扱うSaaS製品の新仕様把握は、業務を行う上で非常に重要なので、どんなに忙しくても週に1度は行うようにしています。

　朝の確認作業が終わると、メンバーそれぞれの作業に入ります。

　作業の内容は様々ですね。メールで顧客と調整したり、打ち合わせしたり、資料作ったり、ステータス管理したり。前述のような技術調査や資料作成、新規事業準備なんかも同様です。メンバーの一人は広報サイトのメンテナンスや新規コンテンツ作成を専任担当しているので、その辺の作業もこの時間で行います。昼休みはこの時間のどこかでメンバーそれぞれの裁量で1時間確保します。(忙しすぎて確保できていない人が稀にいます、よくないね)

　メンバー全員パラレルで作業しますが、Zoomで常時繋がっているので、困ったことがあったり分からないことがあればすぐに他のメンバーに聞けます。

　日本一ふりかえりで有名な人のチームだけあって、1時間に1回、毎時00分に各人ふりかえりを行います。ふりかえりと言ってもチャットの専用チャンネルにその時悩んでいることや困ってること、逆にうまく行ったことや嬉しかったこと、思ったことなんでも書いてOKです。忙しかったり打ち合わせが詰まっていたりすると毎時のふりかえりを忘れてたりするんですが、そうするとリーダーからお目玉を頂戴します。
　オレはこのチャンネルを分報のように使っていて、毎時00分に関わらずその時々の考えていることの整理に使っています。技術調査の進捗を書いたり、読んだ記事のURLを貼ったり、自分のタスクリストとその消化状況を貼っつけたり、様々です。別ブレイクにこもって作業している時なんかは、他の人から作業状況が見えるように普段より多めに記入するようにしていますね。こういう使い方をしているのはチームでオレだけですが、特に何も言われないのでそのままのスタンスでやってます。

　前述のようにこの会社はレガシー企業でツール導入に後ろ向きなので(SaaSの代理店販売やってるのにその姿勢はどうなんだ？)、CRMツールなどは導入されておらず、全てはメールとBTSで行います。せめてCRMとZen Desktop入れてくんねーかな……。

　毎週火曜の朝一はSaaS製品の製造元と打ち合わせが入っているので、案件ステータスチェックはできません。
　この対策として最近取り組んでいるのが、営業案件の担当が少ないオレが火曜午前中に全員分を確認してチャットに投稿しておく、というものです。水曜に動きのない案件の状況確認(顧客にメールや電話で問い合わせ)を行う傾向があるので、火曜にまとめたこの情報をもとに水曜午前中に状況確認作業をまとめて行うような形にしています。

　金曜は通常作業を全て止め、一週間分の作業のふりかえりに全て充てます。いわゆるスクラムのスプリントイベントに該当します。

1. 9:00-9:30 代理店販売ビジネス全般を統括する部長さんに一週間の成果の報告や相談
2. 9:30-10:00 メンバーそれぞれの一週間の成果発表 (セレブレーションパーティ)
3. 10:00-10:30 プラグイン開発をお願いしているチームとの進捗確認
4. 10:30-11:00 他チームの方にお願いして、一週間の成果物をレビューしてもらう(いわゆるスプリントレビュー)
5. 11:00-16:00 来週の作業タスクの確認と今後予定しているタスクの見直し (いわゆるバックログリファインメント)
6. 16:00-17:00 一週間のふりかえり (※ 月末だけは一ヶ月分のふりかえり)
7. 17:00-18:00 作業がある人は個別作業、無い人は早上がりしてOK

　金曜日は社外の方でも無料で見学可能ですので、興味がある方はオレかふりかえりの人に声かけてください。(解説するのがめんどくなったわけじゃないよ)

終わりに

　このやり方になっているのは、色々と効率の良い・やりやすい方法を模索し続けた結果の、現在のスナップショットです。来月同じ方法でやってるとは限りないですし、事実小さな変更は随時行なっています。我々は今このやり方が働きやすいと思ってこのやり方を取っていますが、それが万人に合うわけではないことは承知しています。

　Management3.0は良い働き方・働きやすい働き方を従業員自ら探すために、それぞれのモチベーションや考え方・スタンスを推測ったり確認したりするようなワークが多いです。ここで書いた内容はManagement3.0とは直接関係ないかもしれませんが、多様な働き方を知ることで個々人が興味がある・働きやすいと感じるやり方を模索する一助にはなるんじゃないかと思い書いてみました。
　働き方を選択するためには、色んな働き方を知ることが大事だと思います。色んなユースケースを集めて、知って、その中から自分達の最適解を探し続けていきたいですね。