最近ハマっている読書術について
佐藤優さんの読書の技法を読んで、読書術について学んだので実践している。
また、同時に最強の読み方についても読んだ。
書かれている通りのことをそのままはできていないが、ある程度意識して取り組むだけでも結構効率が上がったように感じるのでまとめてみる。
今回取り上げる読書術の目的と課題設定
結婚し、これから子供が生まれてくる状態になったので、これまでのように、インプット作業に大量の時間を使うことができなくなった。
社内における自分の強みとして、書籍や勉強会などで自習で知識を仕入れてきて、まだ社内に実践者がいないようなことに取り組むような動きが得意というのがあると考えている。
これは、新しいことのキャッチアップに比較的に自信があり、継続的にアンテナを張ってインプットし、かつとりあえずやってみようと思えるメンタリティを持っていること、そして社内である程度信頼が得られていることに支えられていたように感じる。
一方で、ライフスタイルの変化によって、使える時間に変化が生じ、その結果として新しいことのキャッチアップスピードの低下やアンテナ感度の低下が現実的に見えてきた。 これからの時間の使い方は、これまでとは異なり、家族での時間を大切にするような方向にシフトしていくと思う。
そんな中で、自分の強みを保つためには、短い時間のなかで新しいことをキャッチアップできるようになることが必要になると感じている。
本書はまさに、限られた時間の中でいかに読書してインプットしていくか？という課題意識を持っており、問題設定にぴったりだった。
実践している読書術と実践できていないこと
本書では、本を以下の3つに分類する。
- 超速読対象
- 速読対象
- 熟読対象
本から必要十分な情報を拾い出すための戦略を練るような理解で、既知の内容が多い場合は読で未知の内容だけをピックアップする。 未知の内容が多いものは、しっかりと熟読し、基礎力をつける。基礎力がつくと、別の本を読む際に、既知が増えるので、読書スピードが上がっていく。
この本で薦められている内容とは少し異なるが、個人的に試している手法としては、
- まず超速読で本のなかで読むべき場所に当たりを付けつつ、熟読対象か速読対象かを決める。
- 速読対象であれば、30分を目安に飛ばし読みし、気になるところの端を折っておく。
- 2週目で端を折っておいた分だけしっかりと読み、Evernoteにまとめる。
- 熟読対象であれば、本書の指示通りに2度読んでEvernoteにまとめて、3度目を読む。
この方法で読むと、1日に数冊読むことができ、積んでいた大量の本から効率的に知識が得られていると感じる。
最強の読み方を読んで思ったこと
自分の専門領域における世界の進歩発展はクソほど早い。 これをキャッチアップし続けるのはかなり時間がかかる作業だと思うが、現状は手が打てていない。 この本では、新聞が良くキュレーションされた情報源として、社会の全体像を知る手段として提示されている。
同じような物が自分の専門領域にもあれば良いが。。。と考えた結果、一番近いのはarXivsなんだろうなと思った。 例えば定期的にAbstだけ見て大体どんな方向に業界が進んでるのか？を掴めるようにする努力は必要なんだろうなと思う。
ただ、これを短時間で済ませるためには、前提知識・基礎知識が必要になると読書の技法では述べられている。 読書時間を短くするのは、テクニックではなく、その分野における基礎知識であるという考え方で、納得感がある。
まだまだ専門領域に対する理解は浅いし、基礎知識の鍛錬を続け、短時間でキャッチアップしていける自力を付けたいと思った。
「ドメイン駆動設計 モデリング/実装ガイド」を読んだ
技術書展が中止になり、オンラインで開催された技術書応援展で購入して積んでいた「ドメイン駆動設計 モデリング/実装ガイド」を読了した。
読む前に期待していたこと
元々数年前に、DDDを導入したプロジェクトに参画していたことがあり、その際にエリック・エヴァンスのドメイン駆動設計を初めて読んだ。 当時は経験も浅かったし、DDDやらScalaやらAWSやらAngularやらと、これまで触れてこなかった技術のオンパレードで、大混乱している中で、初めてエリック・エヴァンスのドメイン駆動設計と触れ合った。
洋書技術書特有の、謎の筆者のエピソードが挟まれながら解説される謎の書きっぷりにより、全く理解できず頭がパンクしたことは今となっては懐かしい思い出になっている。 当時は一緒に働いていたメンバーに超強い人がいたこともあり、常に焦りと不安がある中で、全く理解が進まなかったので、DDDについては若干のアレルギーだけが残る結果となっていた。
それから数年が経ち、いくつかの経験を積む中で、当時の超強い人が言っていたことがなんとなく体験を持って理解できるようになり、DDD再入門してみようと思うようになっていたところで、ちょうどこの本に出会った。
紹介ページに書かれている「迷子になる」とか「非常に重厚かつ難解」といった記載を見て、
それな！！！
と感じた僕は、当時の僕の悩みを理解しているこの書籍であればDDDに再入門できるのではないか？ということで、購入して、積んでいた。
読んだ感想
なにこれすげぇ分かりやすい。というのが率直な感想だった。
実際に入るプロジェクトでこれをすぐさま応用できるか？はわからないが、少なくとも理解できたと感じることができたのはとても大きな収穫だった。 だってドメイン駆動設計本は理解がまずできなかったのだから。
ページ数も多すぎず、6ポモドーロサイクル(つまり3時間)で読了することができた。
目的ありきで方法論を丁寧に解説してくれるので、まさに迷子にならない設計だった。
次にやること
ただ、一度読んだきりで実践できるとは到底思えないので、継続学習が必要だと思う。 ちょうどよく筆者の人がオンラインで勉強会を開いているようで、しかも動画で後から見れるようなので、ありがたく拝見することにしよう。
ここで得られた知識を持って、ドメイン駆動設計本にもいつかチャレンジしてみよう。
社外で初めてモブプロやってみたら辛かったのですごく学びになった話
モブプロやったことないので、流行りに乗って体験しようとしたら、想像以上に辛かったというお話です。
TL;DR;
目の前のプログラムで解くべき問題に全く集中できなかった辛い。
モブプロとブレストは似て非なるもの。マインドを変えないとできないかも。
よい学びだった。
前提
自分はモブプロ初参加。 チームに参加する人たちとはほぼ初対面。
なんかフワフワ機能を作ってたけど、出来上がったコードくそだったよ辛いなんでや
まずはサクッとFizzBuzzでもやりますかーと始めました。
モブプロ未経験者が多かったので、と、とりあえず始めましょっかーってことでプログラムを書き始めたわけです。
進めるときにずっとおもってました。
なんかこう、普段の何倍もの時間をかけて進み、かつクソコードになっていく。。。って。。。
なんでや。
辛かったこと
口頭で伝えるのむずい
コード書けたら早いんですけどね。 うまく説明できませんでした。
事前に設計するなりして認識が揃っていると違うのかも。
今回は事前設計なんてなかったので、説明が難しかった。
人間系の問題に配慮するあまり、プログラミングで解くべき問題に集中できない感覚
初対面な人たちの集まりなわけで、お互いのことは全く知りません。 その中でチーム作業をするので、結構お互いに気を使って進んでいきました。
せっかく参加しているわけですし、どうしたらみんながやりやすいかな？というのが気になってしまって、コーディングに全然集中できなかった感覚が残りました。
これって生産性あがってるのか？
TDDで難しいことが、より大きな問題として影響してきた気がする
うちのチームはTDDで進めました。
TDDってテストのstepをどう刻むかって結構難しいというか感覚が大事な気がします。
TDDでのstepは、自分の感覚で、自分が自信をもって進められる幅で進めていこうということだったはずなので。
モブに当てはめると、モブが自信をもって進められる幅ってことなんだろうけど、他の人たちの力量もわからなかったので、なんか数倍難しい気がします。
その結果、細かくしすぎて必要以上にテスト書くような形になった気がしたし、時間が無駄にかかった感覚を受けました。
なんかちがうなーこれ。。と。
あと、リファクタへの意識が低かったので、ひたすらアドホックに機能を継ぎ足してコード書くような状況になってしまったのもよくなかったです。
TDDはテスト先に書いたらTDDなわけじゃなくて、Red=>Green=>Refactorといサイクルを回すものなのですが、そこが意識できなかった。
テスト通ったらみんなで逐一拍手してたんですが、テストじゃなくてRefactorが終わったら拍手するサイクルのほうがいいのかも。
拍手したらリズム止まって、じゃあ次何テストしようかってなるので。
いやいやなんか設計おかしいぞこれ。。。と思っている人も結構いたと思うけど。。。
メンバーの一人が、そもそも設計これ見直しましょうよって流れぶったぎって言ってくれるまで、変な方向にひたすら進んでいた気がします。
なんか設計変だなー変な方向に行っちゃってるなーという感じがあったのですが、強く言い出せず。
会話のなかで方針転換するにはどんな発言をすればいいんだろう。。ということをずっと考えていたので、疲れました。
考えたこと
解くべき問題によってはモブプロはそもそも合わない説
2セッション目はちょっと挑戦であまりみんなが触ったことのない言語を選択しました。
するとコンパイルがそもそも通らないよーどうやったら通るんだーという状態に。
コンパイルを通すための方法って一意に決まるわけで、そのタイプの問題を解くためにはモブプロはあまり合わないのでは？と感じました。
というのも、各々が平行して調べて、各々の環境で試して、うまくいったらその人の方法を採用すれば事足りるわけです。答えは1つなので。
これに対してモブで進めていくことに利点があるとは思えませんでした。
使ったことないライブラリーの理解とか、そんなのもモブでやるよりは各々で試すほうが良いのではないかな？どうなんだろう。
逆に、実現方法はいくらでもあって、その中からどれを選択するか？といった課題であれば向いているのかもしれません。
1セッション目にチャレンジしたFizzBuzzもそういう意味ではみんな頭の中に大体実装あるでしょうし、向いていなかったのかも。
ブレストとモブプロは似てるけど正反対のものなんじゃないか説
ブレストは意見が出やすいように、人の意見を否定するの禁止というグランドルールで行われることが多いですよね。
僕はブレストいっぱいやってきているので、そっちで育ってきたわけです。
モブプロはそれでいいのだろうか？という疑問が。
意見をぶつけ合うなかで良いものにしていくのが必要なのかもと感じました。
ブレストみたいに、その意見もいいねーいいねーだとうまくいかないです。 コードがカオスになる。
そもそもブレストでは、発言しにくくならないようにという配慮で、意見の否定は禁止していたりします。
ですが、モブプロでは意見の対立を認めないといけないのかも。 そのうえで、対立があっても発言し続けないと、モブの人はバリューが出せません。
このためには、あくまでコードの否定であり人格否定ではないんだようという、1段階成熟したメンタルモデルが各々に必要になると思いました。
全員初対面でこれをやるのはちょっとつらいわ。。。
というか、普段会社のメンバーでじゃあそれできるの？と言われると、すぐには自信ないです。。
リーダー的な役割必要なのかも？
意思決定が難しかったので、リーダー的な役割はあってもいいのかもと思いました。
なんかお互いに遠慮しあってしまう雰囲気があり、なかなか物事決まらなかったんですよねーなんか。
どうします？うーーん。。。どう思います？的なやりとりが結構多くなってしまった印象でした。
エディタとインタフェース
各自の端末でできるようにしたほうが絶対良い。これは間違いない。
今後の展望
テーマをもうちょっと考えて、普段一緒に働いているメンバーでモブやってみたいなと思いました。
あと、できたらモブが成功しているチームに見学とか行きたい。 現状では上手くいくイメージがなかなかできていない。
おわり。
2019アーバンデータチャレンジ京都 in NDL関西に参加した話
地域課題解決を目的としたオープンデータの利活用を目的として、自治体が企画するコンテストであるアーバンデータチャレンジ2019への応募を目指したイベントである、アーバンデータチャレンジ京都に参加してきた。
2019/11/9に1日かかりでアイディアソンを実施し、2019/12/7にハッカソンが実施されるスケジュール。 アイディアソン終了後のハッカソン開催日までの1カ月間は好きに開発すすめてくださいねーという感じのイベントだった。
ハッカソンでは各チームが色々と事前準備をしてきていたので、最終的なアウトプットはどのチームもすごかった。
アイディアソンの様子。 2019アーバンデータチャレンジ京都 in 関西館 | NDLラボ
うちのチームのピッチ。 https://lab.ndl.go.jp/dataset/UDC2019/ideathon1_MyPlace.pdf
うちのチームはWebアプリを作った。 リポジトリはこちら。 https://github.com/masamasah/my_place
参加した経緯
今期の個人的な目標として、なんしかモノとしてアウトプットするところまでもっていきたいというものがあり、取り組むテーマを探していたところ、たまたま見つけた。 でもなんか一人で参加するのいややなーと思っていたので誰か誘ってみようと思った。
普段から仲の良い同僚から勉強したいけど何作ったらいいかわからず手が止まってしまうという相談を受けていたこともあり、ちょうどいいかもということで誘って3人で参加した。
アイディアソン
まずは自治体が提供しているオープンデータの説明があった。 いろんな種類があって正直すべてを覚えてはいないけど、国会図書館ということもあってかなり興味深いデータがあることがわかった。
これらのデータを活用してどんな地域課題が解決できるか？をブレストしてアイディアだしし、出てきたアイディアをクラスタリングして、各クラスタに興味のある人たちがあつまってチームを形成した。
チームに分かれてからはチームごとにアイディアをブラッシュアップして、ハッカソンで作るべきものの青写真を作った。
ハッカソンまでの過ごし方
もともと開発の勉強がしたいというモチベーションで集まった3人なので、ハッカソン当日までに集まって開発をすすめた。
普段の業務では一人チームで開発しているので、チーム開発ができたことが個人的には凄く楽しかった。
全体的な足回り(インフラ系とか開発環境とか)の整備とPythonでのWebAPI提供を主担当し、Angularでの画面開発なんかも行った。
チーム3人で開発の勉強がしたいということで合意できていたので、成果物を追い求めるというよりは、技術的な解説や不明点の深堀など、知識習得に重きを置いて進めることができた。
ハッカソン当日
学び
ペアプロするうえでは大きいモニタが必須。13インチのMacbook airでは限界がある。
説明することで学びが深まるので、良い機会だった。 普段の業務でもチーム開発がしたくなった。
今回は開発を学びたいという目的でチームが合意できていたが、ペアプロを進めるうえでは方向性を合意しておくことは大事かもしれない。 細かいことは置いといて開発進めようぜ！ってならなくて良かった。 ここの認識があっていないとチームがギスギスしたりするのかな？と思った。
課題
学びが目的であったが、それでも最後のほうはモノとして整えるために急ぐことになった。 もうすこし余裕をもって進められたよかったなぁと反省。 これによって最後のほうは全員が全員理解して進める構造にならないケースがあった気がする。
他のチームのアイディアや実装はかなりユニークなものもあり、もっともっと発想を飛ばせるといいなぁと思った。
目標達成系の本何冊か
最近個人プロジェクトの進捗があまり出せていない。 モチベーションが若干下がってしまっている気がする。
ので、目標達成とかそういう系統の本をまとめて3冊ほど読んでみた。
テーマを固めて一気読みするのはかなり良いかもしれない。
読んだのはこちら。
3冊の関係性
【成し遂げる力】では、行動を3つに分類している。 無意識に実施しているような行動を「自動行動」、衝動的にやってしまうような行動を「衝動行動」、その他を「一般行動」が3つ。 【9つの習慣】は衝動行動と一般行動を対象としたイメージで、【成し遂げる力】は3つそれぞれを対象としている。
【時間術大全】は他の二冊と比べると日々の実務よりで、tips集に近い。
3冊はそれぞれ根本にあるのは似たような考え方に感じる。 【成し遂げる力】より【9つの習慣】の方が圧倒的に読みやすくはあるので、【9つの習慣】を読んで実践しつつ、日々の行動のサポートとして【時間術大全】を使うようなイメージが良いと思う。
成し遂げる力と9つの習慣
【成し遂げる力】の方がより広い領域を扱っている印象を持った。 実例が豊富なので、実例を得たいならおすすめ。個人的にはちょっと実例が多すぎた。
どちらも目標を具体的にすることの大切さを説いている。 曖昧な目標ではなく具体的にすることが大事。 【9つの習慣】ではあまり理由づけがなかったが、【成し遂げる力】を読むとリンクする部分が多く納得感が得られるかもしれない。 目標を具体的にしておくことで、実現可能な「十分に小さい」タスクに切り分けることができる。
トップダウンでタスクを小さくしておくことでロードマップが引かれるので、実施に際して簡単な状態（実施時に複雑なことを考えなくてもタスクを倒せばいい）にできるのが大きな効果。 これによって成し遂げられる確率が高まる。
具体的な目標に落としていく際に注意が必要なのが「人はどんなサイズの目標に対しても3〜10個のtodoしか思いつけない」ということ。 目標を具体化する際には【成し遂げる力】の梯子モデルを取り入れてタスク化していくことが大事だと思った。
【9つの習慣】ではif-thenプランニングが紹介されているが、これも【成し遂げる力】で「簡単な状態を保つことが成し遂げるために役立つ」という点とリンクするだろう。 ルーチン化された行動は継続が簡単になるし、if-thenの形で行動をあらかじめ決めておいて自動で実行できるような仕組みが目標達成には好ましいんだと思う。
意志力を使った方法はどちらの本でも否定されている。 意志力を使わなくても実現できるようにしておくことが継続のためには重要。
達成するためにはその対象を「魅力的」に感じていることも大切。 重要なことであり価値があることだと信じることができると良い。 この具体的な方法は【9つの習慣】にはないので【成し遂げる力】を参考にすると良いのかもしれない。
脳の可塑性周りの話はどちらでも出てきた。 固定化された知性ではなく、知性は大人になってからも変わるというマインドセットをもって、成長することを大事なことと捉えるのが大切な習慣なのかも。
時間術大全
ここまでで作ったタスクをその日の「ハイライト」として日々倒していく。 なんの戦略もなく日々を過ごすと、せっかく作ったタスクを進める時間が取れない。 これを防ぐために【時間術大全】を参考に、時間を作る。
意志力に頼って集中しようとするのは難しい。物事は簡単な方が良い。 なので気を散らすものはそもそも消してしまおうといったことで、「レーザー」の章が参考になる。
体調が悪い中で意志力に頼って集中しようとしても難しい。 なので集中できる体調を保つために「チャージ」の章も参考になる。 ここで言われていることは【最高の体調】という本で言われていることとも繋がっている。 人の進化の過程に生活を合わせ直そうというような趣旨。 ここに興味があれば【最高の体調】を読むことをお勧めします。
最後の「チューニング」の章は自身へのフィードバックについてのお話。 時間術としていろんな取り組みを実験して、その結果を振り返って次の実験内容を考えるようなものになっている。
このフィードバックのタイミングで【9つの習慣】で述べられていた「目標との距離をフィードバックする」を取り入れても良いのかもしれない。
ある程度テーマを固めた上で何冊か読んでみる取り組みは結構色々考えるきっかけにもなるし良いかもしれないなぁ。
おわり。
自分の小さな箱から脱出する方法の読書メモ
自分の小さな箱から脱出する方法を読んだ。
- 作者: アービンジャーインスティチュート,金森重樹,冨永星
- 出版社/メーカー: 大和書房
- 発売日: 2006/10/19
- メディア: 単行本（ソフトカバー）
- 購入: 156人 クリック: 3,495回
- この商品を含むブログ (418件) を見る
ビジネス書図鑑で紹介されていた書籍で、特に他人を責めがちな考え方に毒されている自分がいるなぁと思っていた問題意識に刺さりそうだな？と感じたので読んでみた。
いい意味で自己啓発的な本だった。 この本を読むという体験を通して「他責思考」から抜け出すためのヒントが得られるし、（詳細は後述するが）抜け出すためのきっかけの一つになる。
一言で？
「こうしたほうが相手のためになる」という自分の考えを裏切ったことで、それを正当化する思考が働き、世界を見る目が曇る。この状態を「箱に入った状態」と呼ぶ。相手も自分もこの状態になっていると、それぞれが自己正当化の目線で相手を見るので、人間関係がドツボにハマる。これがチーム単位になり、会社単位になってくると、チームや会社の目標達成の大きな阻害要因になる。 箱から出るには、箱から出られている状態の時に、自己反省をして、相手を自分と同じく尊重すべき存在であると認識し直す。箱から出た状態を維持するためには、相手のためにするべきだと思ったことは素直に実践し、自分の考えを裏切らないように留意する。
詳細
箱に入るメカニズム
「相手のために〇〇してあげなくちゃ」と思った際に、それを裏切ると、それをしなかったことへの正当化が自分の中で起きる。
相手の欠点を考え始めて、「だから別に〇〇してあげる必要なんてないんだ！」と考えるようになる。 さらに、相手の欠点を深掘りし、「むしろこっちが被害者だわ。。」と考えるようになる。 さらにさらに、自分の良いところを過剰に評価して、自分を正当化しまくる。
このとき作成された箱は別の状況下でも持ち出されるようになる。
箱が強化されるメカニズム
相手が箱に入って自己防衛してくると、こちらも自己防衛のために箱に入るようになる。
箱の中は自分が正当化される心地よい空間である。
相手が自己防衛のための攻撃をしてくると、それを受けてさらに自己正当化がおこなわれ、心地よい箱の中がより心地よい空間として強固なものになる。一種の共犯関係みたいなもの。
つまり箱は原理的に強化されやすいっぽい。
箱から出るためには？外に居続けるには？
箱に入ってる状態ではぶっちゃけ何しても基本ダメ。 どんな人でも常に箱に入っている状態ではないので、箱から出ている状況の時に、自身を見つめ直し、自己反省することが大事。それによって相手を「自分と同様に尊重されるべき個なんだ」と思えるようになると箱から出られる。
箱から出たら外に居続けるためには相手のためにするべきかなーと思った自分の考えを裏切らないことが大切。
感想
「箱」について物語形式で進んでいく。通常の知識本とは異なり、整理されて書かれているというよりは、登場人物の学びを通して理解していくようなスタイルであり、本書の内容的にはそれがしっくりくると感じた。 また、箱から出るための方法として「箱から出た状態にある時に自己反省をする」というものがあげられているが、本書を通じてこの体験ができるように物語形式にしていると感じた。
普段の人間関係の中で、しがらみがある中で、箱から出た状態を意識的に作り、その際に自己反省をするというのは至難の技であると感じる。
まず箱から出た状態の人間関係にいる際に、そうではない相手のことを考えたりすることはあまりないし、考えたとしても自己反省をするという発想にまずならない。 箱から出た状態の人間関係にいる際に、その相手から、そうではない相手のことを考えて自己反省するように促されれば別だが、あいにくそんなことをしてくれる知り合いもいないし、正しく理解させてくれないとその相手に対しても箱に入ってしまいそうだ。
その点本書はわかりやすく解説してくれているし、最悪本を閉じればその後の人間関係に影響はない。 本書に対して箱の外にいることができるなら、箱の外にいる状態で自己反省をするということが果たされるわけで、とても得難い機会になると思った。
余談だが、免疫マップの考え方とも近しいものを感じた。 箱を強化したい・自己正当化したいという裏目的を達成するために、相手をより攻撃的にしてしまうなどはまさにそれ。
本書は自己反省を経て相手を尊重すべきだという考えてこれを解消することを主張しているわけだが、これも裏目的の先入観を解消することで解決する免疫マップの考え方に近いと感じた。
なぜ人と組織は変われないのか読了メモ
冬休みを活用して「なぜ人と組織は変われれないのか」を読んだ。
免疫マップについて解説している本として有名(?)な本。
年末年始は扁桃炎で瀕死で実家に帰れなかったので、自宅にて冬休みの3日間をかけて読みました。
一言で
目標達成できないことを、意志力の欠如や能力不足や努力不足などと捉えずに、対立する別の目標を達成するための合理的な手段であると主張している。
このうえで目標を達成するためには、別の目標を支える固定観念を明らかにして、それを検証して必要に応じて修正していく必要がある。この作業を行うためのものが免疫マップである。
これを作る作業によって目標達成のみならず、主体的に捉えていた固定観念を客体的に捉えることができるようになるので、知性の発達のきっかけが得られる。
感想
400ページを超える大作で読み切れるか不安だったが、読み始めたら問題提起が面白くて、一気に読み進めてしまった。
目標達成できなかった時の無能感というか失敗感は誰でも味わったことがあると思うが、この本は目標達成できなかったことを合理的なこととして捉え、これを乗り越えるためにどうしたら良いか？を豊富な事例とともに説明してくれる。
若干、事例がしつこい感はあった。 「うん、わかった。じゃあどうしたらいいの？どうやったらその免疫マップ作れるの？」と思いながら読み進める展開は、ヒキはあったけど、分量がかなり多いのでちょっと。。。
チーム内で免疫マップを実践することで最大の効果が得られるような感じではあるが、自分の周りでこれを実践できるかどうかはちょっと自身がない。
免疫マップを作る取り組みはかなりのレベルで自己開示が要求される。
これを抵抗なく実施できる状況に自分はないなぁと感じた。
なので、チームでの実践は見おくりつつ、個人的な目標達成について考える際には免疫マップを作ってみようと思う。
免疫マップが向いている目標と向いていない目標というのもあり、資格取得しようといったような目標とは親和性が低いと感じる。どちらかといえば習慣的な目標達成についてどうしてもうまくいかない場合に免疫マップを作ってみると良いかもしれない。
自分の場合は筋トレを継続することがなかなかできていないので、筋トレ継続について免疫マップを作り、免疫を克服するように頑張ることでこの効果を実感できるかもしれないと思った。
読書しながらマインドマップを作った。
