かっこうのブログ

何かしら飲んでるエンジニア

読書が贅沢になりつつある

これはかなりアルコールが入った状態で書いています。 マノックモア美味しい🥃

読書が贅沢になりつつある

AIの台頭によって、あらゆるデータに簡単にアクセスできるようになった。

本の要約も、論文の整理も、以前よりずっと簡単になった。
そんな時代に、あえて本を読む意味について書いてみたい。

本、読んでますか?

論文に関しては、正直あまり読んでいない。

最近はNotebookLMに放り込んで、マインドマップを作らせるのが個人的な流行りだ。

要約というより、章立てや論点のつながりを見やすく構成してくれる。
そのため、全体感の把握から個別の要素の確認まで、かなり効率よくこなすことができる。

GEPAの論文でのマインドマップ on NotebookLM

正直、これがあれば全文を読む必要はほとんどない。

全体の要約はすでにされている。
要素の把握もできる。
自分が特に知りたい部分にも、すぐにたどり着ける。

それでも、僕は本を読む。

混ざる前に溢れていく

アイデアやひらめきとは、コップに知識という水を溜め込み、それが溢れたときに生じるものだと思っている。

ただし、溜め込めばいいというものでもない。
じっくりと混ざる時間が必要なのだ。

AIを使ったインプットは、とにかく速い。
必要な情報をすぐに取り出せるし、読むべき箇所も教えてくれる。

だが、その速さゆえに、知識が自分の中で混ざりきらない。

コップの中に、水とワインとウイスキーのように比重が異なるものが混ざっている。 そこにさらに注いでも、後から入れたものがただ溢れるだけになる。

今の自分のインプットは、少しそれに近い。

だから、コップの中の液体を混ぜる時間が必要になる。
それが読書なのだと思う。

瞑想という名の読書

文章を噛み、今ある自分の知識と合わせて咀嚼する。
すぐに答えへ飛ばず、行間で立ち止まる。
その時間の中で、ばらばらだった知識が少しずつ混ざっていく。

そしてようやく、アイデアやひらめきに昇華される。

以前は、本を読んでから瞑想することで、そうした整理をしていた。
だが、AIによってインプットの速度があまりに速くなりすぎた。

となれば、咀嚼するタイミングを変える必要がある。

僕にとって、それが読書に成り変わった。

もちろん、瞑想は続ける。
瞑想はさらに高い視座から、思考全体を整理するための時間だからだ。

けれど、AI時代における読書は、もはや単なる情報収集ではない。

読書は、知識を集めるための行為ではなくなりつつある。
知識を自分の中で混ぜるための、贅沢な時間になりつつある。

だいたい誰かがボールを拾わされている

こにふぁーさんの以下の記事が非常に良かったので僕も筆を取ってみようと思いました。 こにふぁーさんの記事では、間に落ちそうなボールを拾う人の葛藤や、その後どう振り返るべきかが書かれていました。

僕は「で、拾われなかったボールは最終的にどこへいくの?」について個人的な経験多めで書いていきます

konifar-zatsu.hatenadiary.jp

間に落ちるボールはどこへいく?

どこへいくんでしょうね。大体の場合、3だと思っています。

  1. 誰かが拾う
  2. 誰も拾わない
  3. 誰かが拾わされる

3だと何が問題なのか。

自部署のボールの場合

リーダーやその機能・プロダクトに詳しい人が指摘されて対応する形になるでしょう。

指摘されて対応するので、意外と緊急性が高まっていたり、純粋に急にタスクが増えるというストレスがあります。

他部署からのボールの場合

大体リーダー層にメンションが飛びます。 その後リーダーが対応するか、リーダーがメンバーにタスクをパスする事になることが経験上多いです。

個人的にこちらの方がリスクは高く、以下の2つがネックになります。

  1. エンジニアメンバーへの不信感が高まる
  2. リーダーの時間が取られる

他部署とキャッチボールをする

エンジニアメンバーへの不信感が高まることの課題は色々あります。

  • 会議において発言を通しにくい
  • 改善の要望が他部署から出てこない など、期待されないことに繋がってきます。

お互いのチームが全力でやっているということを常に対話を通して動けている組織であれば、 上記のような問題は出てこないかもしれません。 しかし、そのような環境でない場合は、いかに対話しやすい状態にできるかが重要になります。

そこには投げたボールを取ってくれるという信頼は絶対条件だと思っています。 もちろん「ただボールを拾ってやる」のではなく、意味を考えて対話することが前提です。

これらの信頼がないと以下のような損失につながります。

「エンジニアチームに言ってもしょうがないしなあ」 1. スプレッドシートで管理するか a. 自動化や知識かの阻害 2. この問い合わせはお礼で対応するか a. 不要なリソースの消費

よく分からないボールが、強い駒の動きを止める

突然ですが、僕はワールドトリガーの弱い駒の理論が好きです。

「弱い駒が強い駒の働きを止めてる」ってのが既に戦果として充分なんだ」

ワールドトリガー9巻より

今回でいえば、結局リーダーの時間が奪われるというのが大きな問題だと思っています。 間に落ちるボールで言うと

間に落ちるボールというよく分からない駒に、リーダーという強い駒の動き止められている

と言う状態なわけです。 もちろん、よく分からない駒なので、実は強い駒の可能性があります。 しかし、それを分析することができます。 本当に強い駒、自分が敵わない駒であればリーダーにヘルプを求めればいいのです。

なぜボールを拾うのか

エンジニア組織にもメリットがあり、個人の成長や立場が有利になりやすいからです。 後者は割と現金な理由です。

エンジニア組織のメリット

まず、知っている人が増えます。 すなわち属人化の防止につながります。

また、知らない→知るという過程の中での学びを社内Wiki、Claudeをお使いであればSkillやknowledgeにしておくことで 誰でも参照可能になります。

個人的に以下の部分が最大のメリットだと感じています。

知らない→知るという過程の中での学びを言語化する

個人のメリット

純粋に他のメンバーから信頼を得られます。 積み重ねていくと、気づいたら存在しない役割が与えられたりします。

「サブリーダーってかっこう君だよね?」

とか

「この分野ってかっこう君強いよね?これいける??」

のようなことが増えてきます。

こう言うことをやっていくと自分が会社でできることも増え、給料も増えやすくなるのでおすすめです。

ボールを落ちる前に拾うことの良さ

間に落ちるボールを拾うことは、ただの雑用ではありません。

もちろん、全部を拾い続ける必要はないし、一人が拾い続けている状態は健全ではありません。 それでも、ボールを拾うことで見える景色はあります。

どこに情報がないのか。 誰が困っているのか。 どこで信頼が途切れているのか。 何を言語化すれば次から楽になるのか。

そういうものを見つけて、WikiやSkillや仕組みにしていく。 そこまでやって初めて、拾わされたボールが組織の資産になるのだと思っています。

副業でバーを始めてました。準備から半年まで振り返り

週1モルトバー始めました

というわけで始めてから半年くらい経ったので振り返りです。

https://www.instagram.com/bar.casadh/

書いてあることの要約

  • 副業の利点
    • 節税や副業を始める時の注意ごと的なこと 副業を始めたい人はここだけさらっと読んでください
  • 生成AIと副業
    • 本業と違う業界で働く際の生成AIの強みについて、デザインの代行からマルチエージェントを含めた活動方針の委託がある程度できている

なんのお店?

ーズや限定ボトルが中心のモルトバー

小田原にバーは数あれど、意外とボトラーズがあるお店って少なかったりします。

加えて、僕が無駄に趣味でウイスキーエキスパートなど資格を持て余している+よくいくお店のマスターから促されたのが要因となります。

副業の利点

さて、それでは副業の利点についてさらっていきましょう。

基本的に副業の利点は節税にあります。開業届を出して副業を青色申告を行うことで家賃や電気代、各種デバイス代などを経費として計上し控除することができます。

この辺に関しては、節税に詳しいライオンの動画をご覧ください。

そのため、基本的に副業を行うのであればエンジニアは特に自宅できる開発をすべきです。

僕の場合は、生涯で飲みきれない酒を減らすことであったり、ボトラーズというオフィシャルとは違うウイスキーの楽しさを広めることを目的にしています。

副業の準備

開業と青色申告申請

これらはマネーフォワードの開業申請のサービスが非常に簡単です。

というのも、これを使うことで開業届と青色申告申請の2つを意識せずにセットで行うことができます。

税理士の方とも話しましたが、手動で行うと以下のようなミスをやらかして節税できず逆に辛い思いをする方もいるとのことで、セットでやってくれるというのは非常に心強いです。

手動でやると開業届だけして青色申告申請を忘れてて一番出費のある1年目に特別控除が受けられない人が時折いる

衛生管理責任者になる

飲食店を経営するにあたって、必須になるのが衛生管理責任者の資格です。

これは1店舗に一人は必要なので、基本的に店長がとることになります。

昔は1日かけて講座を受ける必要がありましたが、現在はオンラインで自分のできる時間に受講することができるため、仕事終わりに1時間をこつこつやるだけで資格を得ることをできるのでオンラインがおすすめです。

ロゴデザイン

お店を持つにあたって楽しく難しいところの1つが、店名とアイコンだと思います。

正直ここがネックで今まで開業しようと思っていなかったところがありますが、現在は生成AIのおかげで自分のイメージに合わせてアイコンを作ることが可能になりました。

当時はChatGPTがメインでしたが、現在はGeminiの🍌など色々な選択肢がありますね。

また、名刺や店舗カードの作成もイラストレーター完全初心者でも、一週間の無料期間内で作成できるレベルなのでAIの下駄の高さを再認識しました。

場所を確保する

副業の中でも飲食店の難易度が高い理由はここだと思います。

現在はシェアキッチンなども増えてきていますが、僕の場合は幸運にもよくいくバーを貸していただけることになりました(もちろんお金は払っています)。

オープン前のクラウドファンディングの支援もしていたこともあってか、非常に良くしてくださっているので感謝しかありません。

運営する

さてここからはどうやってマネタイズをしていくかです。

なんせ間借りで週1なので、認知を得る方法やインスタの運用など様々なところを考える必要があります。

これに関してはautogenを使うことで、初心者でも様々な施策を打つことができました。

役職を適当に設定し動かすことで、以下のように今後の動き方やブランディングをどう作るかのテンプレ的な動きがわかります。

## 各エキスパートからの最終アドバイス

### 🎯 マーケターより

「Instagram運用の鍵は**継続性**です。完璧を目指さず、まずは週3回のストーリーズとフィード投稿を習慣化してください。リール動画は最初は質より量で構いません。3ヶ月続ければ必ず結果が出ます」

### 📍 地域活性化コンサルタントより

「小田原という地域で長く愛されるバーになるためには、**地域コミュニティとの信頼関係**が重要です。間借りのマスターとの良好な関係、商店街との連携を大切にしてください。3ヶ月後には『地域に根ざしたバー』として認知されるはずです」

### 💰 ファイナンシャルアドバイザーより

「黒字化達成後も、**経費計上の最適化**を継続してください。青色申告特別控除65万円を活用すれば、年間の節税効果はさらに大きくなります。副業として健全な財務状態を維持することが長期継続の鍵です」

### 🎨 クリエイティブディレクターより

「SNSは『情報発信』だけでなく、**ストーリーを語る場**です。『なぜあなたがこのバーをやっているのか』『なぜボトラーズなのか』という想いを、写真や動画を通じて伝えてください。共感した人が必ず来店してくれます」

### 💼 ビジネスストラテジストより

「この3ヶ月は**基盤構築の期間**です。焦らず、一つ一つの施策を丁寧に実行してください。週次で振り返り、効果のある施策に資源を集中する。このPDCAサイクルを回せば、必ず目標は達成できます」

上記だけでなくSNS投稿のテンプレなど、

「まぁ妥当だろうな」という結果が出てくるので非常に面白いです。

売上は?

当たり前のように現在は赤字です。

これに関してはおおよそ想定通りです。

幸いにも、身内以外のリピート率は高く小田原の本格的なモルトバーの需要はありそうでした。

これからはボトルの購入頻度を抑えて、新規をどれだけ増やすかというAutoGenの結果の通りの動きをしていく形です。

最後に

小田原にきた際にはぜひお越しください。 日曜日以外は小田原で唯一のフルーツカクテルが楽めるお店なので、ぜひ

従業員効率を高めていくエンジニアを考える

なんの記事か

従業員満足度(以下、EX)に対してエンジニアが寄与する意義と、どのようなモチベーションで何を行うのかということ。

簡単にまとめると、書籍「みんなでアジャイル」の理想的な状態になるような組織に、エンジニアマターで進めていくこともできるんじゃない?という個人的な推論です。

冒頭

そもそもEXとは以下の定義とされていることが多いです。

仕事内容・職場環境・人間関係・給与待遇・福利厚生・ワークライフバランスなど、従業員が「仕事と職場に関してどれくらい満足しているのか」を示す指標

こう見るとかなりHR領域に近いのですが、

この中でも「仕事と職場に関してどれくらい満足しているのか」の「仕事に関してどれくらい満足しているのか」の部分を解決することでEXを高めて行こーという話になります。

EXを高め従業員が円滑に動くことでCS・利益や利益につながる各部署、会社全体のPDCAの速度を高めることが目的になっていきます。

何がいいのか

上述のことを踏まえると、当記事におけるEXの定義は「仕事に関してどれくらい早くこなせるか・PDCAを回せているか」と言ってもいいでしょう。

私たちの会社のメンバー行っていることを自動化、または無くしていくことで、たとえばマーケティングなら施策のテストサイクルを早くする、CSならば対象とするユーザーの絞り込みや、どの層を対象とするかをより分析することが理想となります。

何をするか

個人的には以下を順にやっています。

  1. 他のチーム・部署が行なっていることの把握
  2. 作業の中のボトルネック無駄に見えるチャットの把握
  3. 「こうなればいいのになー」を拾い上げる・引き出す

上から順にやっていくことで、信頼を得て課題や理想を話してくれるようになります。

ただ、最終的な目標は組織全体のPDCAを早くすることであり、目の前の人の持つ課題を解決することではないことは意識すべきです。

1,2はよくある話ですが「無駄に見えるチャットの把握」は注意が必要です。

自動化を行う時のデメリットとして、自動化することで今まで確認していたことが確認できなくなるということがあります。

これは壮子の羽鶴瓶の逸話からも汲み取れますが、自動化することで確認できず静かに状態が悪化していくことがあります。そのため、自動化すべきなのか・自動化すべきではないのか・自動化しても通知などの工夫が必要なのかなどチャットの前後作業を把握する必要があります。

また、「こうなればいいのになー」とぼやいているところに「なんでそう思うんですか!?」と積極的に話しかけにいくのは根本的な課題を探るだけでなく、後々「これできないですか?」という相談を受けるキッカケにもなるのでとても重要です。

これができると、勝手に課題が回ってくるようになるので非常に簡単になってきます。

最後に

この方法は比較的ベンチャー向けだと思っています。大きい企業では、縦割りも大きく他の部署は独立して最適解やKPIを設定することが多いためです。

一方でベンチャーでは、部署ごとにKPIがあったとしても企業としての成長が最重要な事項になります。そのために、企業全体のPDCAを早く回す必要があり、エンジニアは他の部署に比べ「広い視点・長い視点」を持っており、そう言った環境づくりに対して最適だと考えています。

ベンチャー初期であれば機能優先になるかもしれませんが、ある程度軌道に乗ってくれば他のチームのサポートをするのもありな選択ではないかと考えています。

「クリーンアーキテクチャ」選択を残して開発をするための設計

adventar.org

気づいたら時は流れ、アドカレ16日と+X日になっていた...

というわけで最近また話題になっていたクリーンアーキテクチャについてです。

このツイート、私も実際にクリーンアーキテクチャを読了して「わかる!!!」となったので、その辺りを話せればなと思います。

このよく見るあの図だが、本書では1度しか登場していません。 また、文脈としてもヘキサゴナルアーキテクチャやDCIアーキテクチャ、BCEなど様々なアーキテクチャの特性を統合したものとしている。

よく見るあの図

すなわち、「クリーンアーキテクチャ」というアーキテクチャというものはそもそも存在していません。では、本書が語っているクリーンアーキテクチャとは何なのか、なぜ行うのからに触れながら個人的に気になったところを書いていこうと思います。

なぜ設計を考える必要があるのか

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

様々な設計に関する本で語られている様に、この書籍でも技術的負債を溜め込まずリリースごとに労力が増えるといった状態になるのを回避することを考えている。

変更の難易度は、変更の形状ではなく、変更のスコープに比例しなければいけない。

これは非常によくある悪い状況の見方だなと感じる。

例えば画面に表示する1文を変更する要望があったとする。コードを見てみると、その文字列を別のところでも使っていてそっちの修正も必要になってきて、あれDBにも保存している?という厄介な問題になることがある。

これは変更の形状に対して、難易度が圧倒的に高い。よく設計が出来ていればスコープを文字程度簡単に修正し、ビジネスロジックの大きな変更など大変だと思われるものに、その通りの難易度が伴う形になる。

関心事の分離と依存関係のコントロール

個人的にこの書籍で最も語りたいところがこの部分だと感じる。

よく見るアーキテクチャもこの部分の影響を強く表しているという風に感じますね。

関心事をドメインなのか・技術なのかに分離し、ドメインが技術に依存しない様にコントロールする。これをするために、オブジェクト指向の様々な手法を使うことが記載されているのが本書になります。

この様に関心事を分離し、依存関係のコントールをすることで"ドメインに関してはフレームワークも含め、全てから独立させるべき"ということが実現します。

さてこれができると何がいいのか、ドメインフレームワークやライブラリなどが依存している場合、それらの影響を受けることになります。それがバージョンアップならばまだ良いですが、放棄でもされた時には溜まったものではありませんからね。

また、ドメインを独立させるためにフレームワークの選定にも注意を促しています。

フレームワークの作者にとって、自分の作った基底クラスを大勢のユーザーが継承することほど、自尊心が満たされることはない。

少しマサカリのようだが、この様な記載がある。一旦モヤモヤを取り払い、性善説的に「大勢が基底クラスを継承することで新たな価値を提供しやすくなるために基底クラスを継承させたがっている」とでも解釈しておこう。

フレームワークドメインに依存させない方法は簡単で、Entitiesなど内側に入れないこと、円の外側に対してのみ使用する。

関心事の分離と選択肢

この書籍はソースコードレベルの話ではなく、DBや提供する方法も含め"変更を容易にする設計をどの様にするか"という話になっています。

その中でデプロイという話も入っており、昨今のマイクロサービスの話が脳裏をよぎった。さて、ここでマイクロサービスでサービスを作った時、いざリリースの時に起動のタイミングなどが重要になったりする。

関心事を適切に分離することで、DBや提供方法といった"プロダクトの価値以外の選択肢を残すことができる"ことも利点となります。

クリーン・アーキテクチャで作りましたと言えなくなるについて

私個人の感想ですが、「作りました」と言っている時点でクリーンアーキテクチャではないと言えるのでは?と感じました。

なぜならばクリーンアーキテクチャとは、選択肢を常に残すことでプロダクトの提供方法といったビジネス的な決定や、技術選定を遅らせたり、移行のしやすさを保っているソフトウェアだからです。

なので、クリーンアーキテクチャかどうかは実際に運用に乗せ様々な課題を軽く往なせるかというところで判断するしかないのだと私は思っています。

「失敗から学ぶRDBの正しい歩き方」いつの間にか辛いを避ける歩き方

adventar.org

アドカレ15日目

プロダクトコードの負債より、DBの負債の方が大変だと感じています。DBの負債を変える場合、プロダクトコードにあるDBの読み込み・更新まで全て変更する必要がありますからね。

そういった点でも、いつの間にか沼地に迷い込んでいたということが起きないような道標になる良本です。

MySQLはjoinでNLJしか対応していない

Nested Loop Joinの略で参照される行数分だけループが行われるというもの。

dev.mysql.com

JOINの対象となるカラムにINDEXを貼ると速くなるのは参照去れる行数が減ることだったらしい。逆にFORCE INDEXで安定して早くなる理由も納得がいった。こういうのはやはり実装などをみておかないといけないなーと感じたところ。

Ruby on Railsなどは外部キーを作ると自動でインデックスも貼ってくれて、本当に意識せずに全部やってくれるなぁと感心する。

Viewテーブルかサマリーテーブルか

複雑なSelectクエリの発効が余儀なくされる場合の選択肢として、個人的にはViewを使うことが多いです。理由としてはやはり変更に強いこと。

サマリーテーブルはトリガーのタイミングなどを含め、実装が非常に複雑になる場合が多かったり、いざ即時のデータが欲しくなると時間がかかったりと痛い目を見たことが多いというのもあります。

Viewテーブルも参照時にクエリが走るなど辛くなってくる段階があるので、「そもそももっと使いやすい形にできないか」を考えてDB設計を考える必要がありますね。この辺はカーディナリティなどの話でも出てきますがデータの偏りなどを予想する必要が多いので「どのような特性のデータか」というところは十分に理解してからDBを設計する必要があるし、腕の見せ所だよなーとなるところ

クラウドやツールの大切さ

バックアップからログ、DBのモニタリングまで本当にクラウドの恩恵を受けていたのだなと感じるクラウド世代でした。

特にDBのチューニングなどは監視ツールを入れることで、スロークエリの順位なども見れるので立ち向かい方が変わってきます。特に、1ユーザーだけ特殊のデータの偏りをしていてインデックスが効いていないなど面白いことが見つかりますし、コンクションプーリングができていないなどの早期発見にもつながります。

本当に監視ツールは偉大。また、どこを監視するかについては監視入門などの書籍に譲ろうと思います。

また、クラウドの利点として「強制的にバージョンを上げさせられる」というものもありますね。19章の塩漬けのバージョンの対策にもなります。強制的にバージョンをあげるので、単なる利点とも言えませんが怠惰を重んじるエンジニアにとって、こういう強制性は重要になってきますね。

フレームワークと実行計画

ここで筆者のツイッターを見てみましょう。

そう。ORMの作るクエリは人類には厳しすぎるんです。Ruby on Railsの作るクエリなどをみていると「え、何このクエリ。え、でも実行計画はいい感じだな」となることがあります。これは正しく外部キー制約が貼られているおかげでもありますね。

ただ、フレームワークのORMに依存しすぎて、実際のクエリをみない人がそこそこいるのも悲しいことです。どのようなクエリが作られ、どのような実行計画になるのかは常に確認するようにしようね!!!

状態を管理する

アンチパターンの1つだがとても見る。ユーザーテーブルにある権限のカラム、受注テーブルにある受注状況のカラムなど様々な状態を管理するカラムを見てきたし戦ってきた。

特定の状態毎にテーブルを作るのが良いのは本書を読めばよくわかるが、なぜそれをしないのか・思いつかないのかを考えていく。状態ごとによって持つ情報が変わること知らない知識の不足もあるし、単純に実装の容易さもあるだろう。また、論理削除と同様に考えるというのもありそう。何より状態が増えるたびにテーブルが増えるということも問題となるのだと思う。

人間の記憶の特性として、7つ以上のものは記憶や理解が辛くなってくる。そのため、状態毎のテーブルやそれに関係するテーブルが自身の理解できる範囲内に収めようという思考が働くように感じる。命名などで群として捉え易くするなど、人間が情報処理しやすい命名や設計も重要になりそうだ。

他にも

ロックなどいろいろなことが書かれているので是非

MySQLのギャップロックなど、DBによる特殊な挙動など専門書を読むとより詳しく書かれているのでそちらを読むと良さそうです

「問いのデザイン」数多の角度から問題を見るための本

adventar.org

アドカレ14日目〜

改めてエンジニアの本というのは問題をどのようにみるかがよく語られているなーと、様々な本の1節を思い出す本でした。

その分、エンジニアは問題を様々な角度から見る力が非常に重要でそのサポータとしていかに振る舞うかという話にもなっています。

前提についての問い

問いについて考える前に、問いの前提を問い直さなければならない。問いが必要な硬直した場面では、少々強引に視点や視座を変える必要がある。そのために、前提を問い直す必要がある。

この辺りの話はエンジニアリング組織論への招待でも近いことがいわれている。

・「愛のパズル」なので、(感情的に固執していて)解けない・「パズルを抱いて」いるので、(客観視できずに)解けない・「解けないパズル」なので、(前提を変えない)と解けない

前提について考え直すために必要なアクションが対話となる。異なる前提の人と対話することで、自分の前提をリフレーミングすることができる。異なる前提の人とはビジネスメンバーやCSメンバーのように知識が違うメンバー、技術的なことならば別プロジェクトのエンジニアメンバーに聞いてみるのもありだろう。

また、仲間も重要になる。前提を考える問いというのは、これまでやってきたを捨てる可能性が常に出てくる。これはアジャイルでは重要とされるものの、強い精神負荷がかかる。また、前提を変えるともなれば捨てる量も多く、デザイン思考のカオスな状態とも言える。

そのため、仲間と共に、変化の序盤にある痛みを乗り越える必要がある。

認識の固定化の病

自身の認識を固定化させようとする動き。現状維持バイアスの一種のような気がする。これがあると課題の再認識が難しくなる。

一方で、当事者からすれば「わかった(と思っている)こと」を実はわかっていなかったとなるので負担も大きいし、ある程度固定化した上で課題を深掘りするフェーズもあるため、認識の固定化が毒か薬かは結果論に近いと感じている。ただ、認識の固定化という存在を意識できるだけでも十分変わるだろう

ファシリテートは、メンバーがより深く核心へ導くのを深めるのが仕事

ファシリテートの役目は単に司会だけでなく多岐にわたる。書籍には以下が書かれている。

普段とは異なる視点から発想する。対話による学びと創造の方法 故に、非日常性・共同・民主性・実験性が重要になる

そのため、話しやすい場作りやアイスブレイク・話しやすい問いの設定がファシリテートの大切な仕事になってくる。また、成功体験の演出も重要で、先に制約条件をつけて議論をした後、制約条件を外させることでアイデアを広げるなどマッチポンプ的だが「自分たちで考えた・閃いた」という体験がさらに進めようという気持ちにつながってくる。

非日常性はこの書籍では空間デザインとして省かれてはいるが、個人的にはとても重要だと思っている。非日常性とは、普段とは違う場所や違う状態でMTGを行うことを指す。

例えばオフラインならば普段は使わないMTGルームを使う、席の形を変えてみるなどだ。お菓子を準備するのもいいとされているが、日本人の性なのかお菓子に手をつけようとしない人も多いのでジュースなどがいいだろう(本来お菓子を使うのは、食べる=口を動かすで会話をしやすくするという意図がある)。

一方で、オンラインとなると環境を変えることができないので少し大変になる。使うツールを変えてみると使い勝手に手こずったりもする。そのため、音楽を流す・(顔出しが文化の会社なら)エフェクトを使うといったところから普段とは異なるフレームワークを使うというのもある。フレームワークに関しては、使うことでメンバーにバイアスをかけることにもつながるので何を目的とするかによって慎重に考える必要はある。

最後に:みんなで読むことの勧め

ファシリテートにあたって必要なスキル(説明力・観察力・即興力など)や場のコントロール方法などが語られている。特にスキルやコントロール方法は人によって違うので強みを活かしていくといい。

ありたがたいことに前職で仲のいい人と読んでいたが「〇〇はこのタイプだよねー」という自分でも無意識にしていた振る舞いで自身のファシリの特性に気づくことができた。

5,6章だけでもファシリテートをするメンバーが集まって読むと面白いかもしれない