2020年のまとめと2021年の抱負

年末年始は主に RiJ の配信を見ていました。ファイナルソードの "西が出ちゃいましたね" が最高でした。

仕事

2019 年 11 月から 2020 年 4 月ごろまではスタディサプリの中学生向け個別指導コースを担当するチームに所属していました。
入社直後は新規事業のチームに所属していたので、既存のスタディサプリのチームに所属するのはこれが初でした。とはいえ仕事の多くは限定的なドメインの問題を解決する Web アプリケーションをゼロから書くもので、実質新規事業のような雰囲気でした。Go で API サーバーを書いたり React (TypeScript) でフロントエンドを書いたりと、これまで仕事では触れてこなかった技術を扱う必要があり良い機会でした（Go はあんまりコミットできなかったな…）。唯一雰囲気が違った仕事は既存のサービスに大きな機能追加をするプロジェクトで、自分はそのプロジェクトの開発のリードを任せてもらったのですが、甘い見積もりに基づく意思決定とメンバーへの信頼を欠いたマイクロマネジメント等をし、結果としてやや火が見えるプロジェクトとなったのでした…。なかなか苦い思いをしましたが、次に繋がる良い経験だったと今では捉えています。おそらく就職してから最も働いた期間でしたが、自分が長時間仕事をすることよりも自分の意思決定によってメンバーが長時間仕事をしているのを見続けるのがなかなかに堪えました…。

2020 年 4 月中旬ごろから現在までは入社後最初に所属したチームとは別の新規事業のチームに所属しています。
就職後所属したチームの中でもおそらく最大の開発チームで、大人数でのチーム開発の難しさを日々感じています。技術的にも色々とチャレンジをしていて、クライアント-バックエンド間・バックエンドの各サービス間の通信全てのインタフェースを GraphQL にして Schema Driven な開発を試みたり、社内のサービス全て（多分）が入っている monorepo から外れてチーム専用の新 monorepo を作って開発を進めていたり、サービスのキーコンポーネントの1つとして VSCode の Extension を作ったりしています。コードはフロントエンドに限らず TypeScript が過半数。入社当時は Quipper といえば Ruby の会社というイメージでしたが、現チームの外を見ても Go を書く人が増えていたり Elixir を書いている人たちがいたりと、Ruby を多用しつつも拘らずに要求に合う言語を選択して学習・実践する人が多い組織だなと今では思っています。
自分はこのチームの中で Embedded SRE 寄りの Web Developer のようなポジションにあり、SRE チームと連携しつつ K8s cluster 上で Web アプリケーションやバッチジョブが動くように環境を整備したり CI/CD のパイプラインを整備したりするのを主な担当領域としつつ、必要に応じてフロントエンド・バックエンドのコードも書くという感じで活動しています。コードを書くにあたっては TypeScript の型付けについての知識の無さがしばしばネックになっていて、最近は『プログラミングTypeScript』を読んだり TypeScript exercises をやったりしていました。

仕事は 2020 年 2 月末ごろからずっと家でしています。机はこんな感じ。

作業机の様子

元々作業環境はそれなりに整えていたので、追加で導入したのは電動スタンディングデスク（FLEXISPOT E6）くらいでした。ただ作業部屋に空調機が無いために夏冬が厳しく、妻もリモートワークとなったものの人間2人が仕事をするには手狭な部屋だったため、意を決して引っ越しを敢行。今では作業部屋にも空調機が付き、部屋も全体的に広くなってグッと快適になりました。

仕事以外

基本的に引き籠もっています。

2019 年には毎週のように行っていた飲み会も 2020 年 3 月以降行ったのは去年から予約していた会 1 つだけでした。2021 年も妻以外の人と会って食事をするのは基本的に避けるつもりです。その影響もあってか、家でもお酒をあまり飲まなくなりました。以前は週にビール 2〜3 本程度は飲んでましたが、今では 2 週間に 1 本飲むか飲まないかといった程度に。飲むこと自体は今でも好きなのですが、質の悪い睡眠で体の調子が落ちることへの嫌悪感が強まり、頻度も量も自然と落ちました。親族から送られてきた日本酒はどうしようかしら…。

食事はコロナ禍以前とあまり変化なく、朝は米、りんご、パンなどを適当に食べ、昼はインスタントのちょっといいカレーかちょっといいパスタ、夜はありがたいことに妻が作ってくれることが多いのでそれを食べる、という流れが多いです。途中 nosh を試すも高く感じて停止中。しかし健康的な食事が脳死で得られることを思うと安い気もしてきた。

運動については僕は元々運動不足だったのですが、より顕著になったように思います。平日は基本的に外出せず、運動と言える運動は仕事の集中力が切れたときに作業机の隣に置いている自転車に乗って 10~20 分ペダルを回す程度。体重は年初と比較して落ちているんですが、筋肉量が落ちた結果と思っています。

そんな運動不足な人間が部屋に籠もっているからなのか、自律神経失調のような状態になることが増えたような気がします。具体的にはすぐに立ちくらみをしたり、急にドキドキしたり、大したことをしていないのに消耗して無気力になってしまったり、起き抜けから不快感で頭がいっぱいになってしまったり。ひとまず今は湯船に浸かる頻度を増やしたり、日の光を浴びたり、休日含めてあまり生活時間帯を動かさないことを意識して過ごして様子を見ています。が、正直なところあまり元気でない日が少なくないです。妻にも心配を掛けてしまっているので何とか改善していきたい。

2021 年

去年に引き続き、楽しめる事柄を増やしたり楽しそうなチャンスを得られるように知識を付けたり実績を積んだり縁を広げたりしていきたいですね。あと漠然と興味を持ちつつも現実味を覚えず何も行動していない D 進について、進学へのイメージをカラフルにした上でする・しないのおおよその決定を今年はしてしまいたいなと思っています。解像度が低い状態でぼんやりと道が浮かび続けるのが気持ち悪い。

そんなところで、今年もどうぞよろしくお願いいたします。

Shopify/graphql-batch がどのように batching するのかを追う

この記事は GraphQL Advent Calendar 2020 4日目の記事です。

前回の記事は @qsona さんの 動的型付け言語での GraphQL Client でした。

---

題の通り、Shopify/graphql-batch がどのようにリクエストを batching するのかをコードを読みつつ追っていきます。

時間の都合で、この記事ではシンプルな単一の Query のみ（Mutation でない）を実行した場合を対象とします。また Loader については README に記載されている RecordLoader の実装をそのまま使います。

3行まとめ

• graphql-ruby の lazy-loading class として Promise を使う
• Loader.for(Klass).load(object.klass_id) が呼ばれるたびに Loader に Promise を登録する
• Query にある遅延評価しない field を全て解決した後、Promise を解決する

コードリーディングに使ったサンプルコード

require 'bundler/inline'
require 'logger'

gemfile do
  source 'https://rubygems.org'
  gem 'graphql'
  gem 'graphql-batch'
  gem 'activerecord', require: 'active_record'
  gem 'sqlite3'
  # gem 'pry-byebug'
end

ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
ActiveRecord::Base.logger = Logger.new(STDOUT)

ActiveRecord::Schema.define do
  create_table :courses, force: true do |t|
    t.references :textbook
  end

  create_table :textbooks, force: true do |t|
  end
end

class Course < ActiveRecord::Base
  belongs_to :textbook
end

class Textbook < ActiveRecord::Base
  has_many :courses
end

textbook1 = Textbook.create!
textbook2 = Textbook.create!
textbook3 = Textbook.create!
Course.create!(textbook: textbook1)
Course.create!(textbook: textbook2)
Course.create!(textbook: textbook3)

class RecordLoader < GraphQL::Batch::Loader
  def initialize(model)
    @model = model
  end

  def perform(ids)
    @model.where(id: ids).each { |record| fulfill(record.id, record) }
    ids.each { |id| fulfill(id, nil) unless fulfilled?(id) }
  end
end

class TextbookType < GraphQL::Schema::Object
  field :id, ID, null: false
end

class CourseType < GraphQL::Schema::Object
  field :id, ID, null: false
  field :textbook, TextbookType, null: false
  def textbook
    RecordLoader.for(Textbook).load(object.textbook_id)
  end
end

class QueryType < GraphQL::Schema::Object
  field :courses, [CourseType], null: false
  def courses
    Course.all
  end
end

class MySchema < GraphQL::Schema
  query QueryType
  use GraphQL::Batch
end

result = MySchema.execute(<<~GQL)
  query Courses {
    courses {
      id
      textbook {
        id
      }
    }
  }
GQL

pp result.as_json

1. graphql-ruby の lazy-loading class として Promise を使う

• この辺り: https://github.com/Shopify/graphql-batch/blob/7c7e3016923f9aa346d0cd3b9be40f85bf61a3a1/lib/graphql/batch.rb#L18-L43
• Lazy Execution に関するドキュメントはこちら: GraphQL - Lazy Execution
• MySchema が参照されると GraphQL::Batch.use が実行される
  • この中で、GraphQL::Batch::SetupMultiplex を Multiplex instrumentation の instrumenter として登録し、また lazy-loading class として Promise (promise.rb) を、値を取得するメソッドとして :sync を登録する

2. Loader.for(Klass).load(object.klass_id) が呼ばれるたびに Loader に Promise を登録する

• この辺り: https://github.com/Shopify/graphql-batch/blob/7c7e3016923f9aa346d0cd3b9be40f85bf61a3a1/lib/graphql/batch/loader.rb#L47-L52
• textbook field を resolve した際の返り値としてはインスタンス変数 @source に RecordLoader のオブジェクトを持つ Promise のオブジェクト（文字で表すとややこしい）となる

3. Query にある遅延評価しない field を全て解決した後、Promise を解決する

• この辺り: https://github.com/rmosolgo/graphql-ruby/blob/ea571fd8db2b20f46299313c544ba0690869df28/lib/graphql/execution/multiplex.rb#L82-L87
• Promise オブジェクトを返す field は GraphQL::Execution::Lazy としてハンドリングされ、次実行対象の Query（複数あるときはそれらに含まれる全てっぽい）にある Lazy でない field を resolve するフェイズのあとに resolve される
• Loader に cache していた Promise の object を sync するのは multiplex.schema.query_execution_strategy.finish_multiplex(results, multiplex) から進んでいったここ: https://github.com/rmosolgo/graphql-ruby/blob/ea571fd8db2b20f46299313c544ba0690869df28/lib/graphql/schema.rb#L123
• promise.sync が実行されると GraphQL::Batch::Loader.resolve が実行され、 RecordLoader に実装していた perform が実行される

所感

思ったより理解に時間がかかり（そしてまだ十分に理解できていない）複雑度に対してだいぶラフなまとめになってしまったのですが、graphql-batch がどのように batching するか、また graphql-ruby についてもその実装の一部を理解することができ便利でした。

そしてコードリーディングってスコープを決めてやらないと一生終わらないですよね。楽しい。

『自分でやった方が早い病』を読んだ

タイトルと "孤独な成功者" というキーワードに思い当たるところがあり読んだ。

自分でやった方が早い病 (星海社新書)

僕は相手に頼み事をするのが苦手（年々改善されてはいるが）で、これは思いやりではなくエゴだよなーと思っているのだけど、本の中でも「要求を遠慮するのは信頼関係が無いから」ということが書かれていて、そうだよな、となった。
僕はこの問題を「今解決しようとしている問題は同僚にとっても解決すべき問題なはずなので僕の頼み事を渋ることがあればその人は仕事をする気がないと言えるのでは」のような責任転嫁によって改善しているフシがあり、根本的な解決に向かっていないので意識を改めようと思いました…

また「仕事を任せることと仕事をふることは違う」の話は思い当たる具体的な失敗経験があり少し頭が痛くなった。半年前くらいに仕事でプロジェクトの開発側のリードをやったのだけど、今にして思うと失敗を過度に恐れるあまり不安要素ばかりに目を向け、チームメンバーを十分に信頼をせずに仕事をふることばかりをしていた。リードというポジションに気負いすぎていた気もする。

「してあげる幸せ」の話は『嫌われる勇気』でも「人は自分が役に立っていると実感できたときのみ自分の価値を実感できる」として書かれていた。これも僕は下手（自己肯定感を得づらい）なのだけど、これを書く中で、下手な原因は自己受容ができていなことにある気がしてきた。

以下は読書メモ。

---

• 小倉広 著
• ( ) で括られているアイテムは個人の感想

はじめに

• 自分がやったほうが早い病とは？
  • あるタスクについて「自分がやったほうが早いな」と思ってしまうこと
    • 自分のほうがよくできる
    • 相手に頼むのは悪い
• 自分がやったほうが早い病は新人リーダーに多い
• 自分がやったほうが早い病の個人・周辺への弊害
  • 個人に業務が集中する
    • 業務の停滞
    • バス因子化
    • 業務が奪われることによる周囲のモチベーションの低下
    • 健康を損なう
• 自分がやったほうが早い病を克服すると
  • 周囲・自身ともに成長できる
  • 心身が健康になる
  • 孤独な老後を過ごさずに済む
  • ...

第1章 病が進行すると「孤独な成功者」になる

• 「自分がやったほうが早い」の思考の本質は「自分1人でも成功すれば良い」「自分さえ何とかなればよい」
• 頼み事ができないのは周囲を信頼していない・周囲から信頼されていない証拠
  • 打ち上げもひとり家で缶ビールを開けることになるでしょう。 つらい
• 罹患者は仕事を抱え込むので体調を崩し仕事のクオリティが下がる
  • ランニングはいいぞ
• 罹患者は周囲に不満が募るのでストレスを抱えた状態が続く
  • ちゃんと仕事しない、評価してくれない、優秀な部下がつかない....
  • 筆者はリクルートにいたときこういう状態で鬱を患ってしまった
  • 自身を過大評価し、うまくいかない原因を他人に求め自身を肯定する
• 気づくと周りに人がいない
  • 周囲は自身が必要とされていないと感じるので離れていく
  • "仕事をふる" と "仕事を任せる" は違う
• 伸びてる会社の社長は「忙しい」と言わずいつも余裕がありニコニコしてる
  • 社長やリーダーが徹夜したり、休日出勤したりしてせかせかしているような会社はどこかに問題があると思って間違いないでしょう。 経験談？
• 「まわりは使えない」と思っている人ほど「使えない」と思われている
  • 上司が老害化するとズレたセンスの仕事を手伝わされる
• 今いるメンバーが現時点でのベストメンバー
  • 罹患者の典型的症状の1つが周囲の悪口を言うこと
  • 周囲のレベルは自分のレベル
    • 優秀な人が集まらないのはあなたが優秀なリーダー的存在でないから
• 罹患者は周囲との信頼関係が希薄
  • 同僚に厳しい要求ができないのは信頼関係が築けていないから
    • 「遠慮」はごまかし
• 年賀状が届かなくなるし葬式に誰も来ない
  • (既に親族と業者以外から年賀状届かないな…)

第2章 病を克服すると「幸せな成功者」になれる

• 脱バス因子
  • 組織の安定、業績の安定、メンバーの心の安定
• 会社経営の2つの車輪
  • 外部環境適応と内部組織統合
  • どちらについても個人が100の成果を出すより100人が1の成果を出していく体制の方がよく回る
• 病を克服すると全員が成長するので大きな仕事ができるようになる
  • 個人の能力には限界がある
• 友達もお金も増える！昇進、昇給できる！
  • ジャンプの裏表紙っぽい
  • 上司や部下に対する不満もなくなる、ストレスを溜め込むことはなくなります
    • アドラー心理学のアドラーも「人の悩みの9割は人間関係」って言ってる
• 働くこと自体が幸せなことと思えるようになる
  • 日本理化学工業という会社は障害者雇用率が70%
  • お坊さんが大山隆久社長に教えた人間の4つの幸せ
    • 愛されること、褒められること、役に立つこと、必要とされること
    • 自分でやった方が早い病の人はこの4つが自身と顧客の間でしか成立しない
      • 克服すると同僚に広がり幸せが倍増する
      • 「してあげる幸せ」
    • (嫌われる勇気でも人は自身が役に立っていると実感したときにのみ自身の価値を実感できると書かれていた)
  • 障害者を真に幸せにするのは寄付ではなく人の役に立ち、人に褒められ、必要とされる機会を作ること
• 著者の経験として、自分が褒められることを目的に仕事をしたら自尊心はくすぐられたが幸せにはならなかった
  • 損得勘定をし、褒められるのに必要なスコープでのみ仕事をしていた
  • そうでなく、相手への貢献をスコープの基準にして本来の担当領域をもやや超えて仕事をしたところ、心の充足を得られた
    • (この辺業務の成果について触れられていないので自己満足ではとも読めてしまうな（成果について良かったから書いてるんだとは思うけど）)

第3章 病の根本にある「自分さえよければ」という考え方

• 「自己主義」が根本にある
  • 「任せたいと思いつつ自分でやる」は利他主義ではない
  • 老子「飢えている人に魚をとってあげれば1日は食べられるが、魚のとり方を教えれば一生食べられる」
    • 魚をあげるのは利他的に見えて利己的
      • 自身がいなければその人は食べていけない。つまり自身が必要とされる機会を作っている
    • とり方を教えるのが利他的
• 「情けは人の為ならず」
  • 情けを人にかけておけば、巡り巡って自分によい報いが来るということ (大辞林 第三版)
    • https://kotobank.jp/word/情けは人の為ならず-588620
  • 著者は「自分に戻ってくるかどうかに関係なく、人に優しくしたら、その瞬間に自分の心の満足が得られる」と解釈している
  • 心の充足を得るには自己的で自己完結な振る舞いをするのではなく、自分の利益は置いておき相手が求めていること行う
• 人間の3つの幸せ by 鍵山秀三郎（イエローハット創業者）
  • してもらう幸せ、自分でできる幸せ、してあげる幸せ
  • 成長する段階として次第に右へ進む。幸せの大きさも右に行くほど大きくなる
  • 「自分でやった方が早い」の思考は「自分でできる幸せ」の段階
  • 「してもらう幸せと」「自分でできる幸せ」は利己的だが、「してあげる幸せ」は利他的
    • 利己的な行動は他社と幸せを奪い合うが、利他的な行動は全体が自分を含めた全体が幸せになる
    • 「孤独な成功者」は「自分でできる幸せ」しか知らない
• 利他主義な仕事の任せ方
  • 例：部下の苦手（= 伸ばしたい）分野の業務を任せ成長を促す
    • 自分だったら折れそう。相手のタフネスを見て得意だったりやりたい分野の業務も織り交ぜないと駄目では
  • 人に動いてもらったり人を育てるのは辛くて時間がかかるので辛抱強く相手を信じてやっていく他ない
    • 1度や2度任せて成果で判断、は早計
• プレイヤーとして目先の成果をあげることからリーダーとして仲間を成長させることへのシフト
  • 短期的な成果から長期的な成果に価値をずらすということ
• 長期的な視点がない人は周囲に対して妙に優しくなる
  • 相手のことを考えているようで、仲間との衝突をただ避けたい利己主義なことが多い
  • 相手のためにはときには厳しいことを言う必要がある。そのためには信頼関係が必要
• 「小善は大悪に似たり 大善は非情に似たり」by 稲盛和夫（京セラ創業者）
  • 目先のことだけを考え相手を気持ちよくさせることは悪いことであり、長い目で見て人を育てることは厳しくすること
  • 人を育てるには非情にならざるを得ない
    • (僕はそうは思わないけど)
• 厳しい要求をするほどバックアップは大変になる
  • 部下に厳しくすると自分も厳しくなる
• 子供の教育に必要なたった3つのこと by 森信三
  • 朝挨拶をさせること、靴を揃えて椅子を入れること（親が）、親が呼んだ時に "はい" と返事をさせること
  • 上司が模範を背中で示すことが最上級のリーダーシップ
• トータルパワー一定の法則
  • 会議で上司が99％しゃべったら部下はしゃべれない
  • 引きこもりの子供に対しては親のパワーバランスを下げて、余白を徐々に子供に埋めさせる
• 部下を育てるというマネージャーの喜びは経験してみないと分かりづらい
  • だから新人マネージャーは自分でやった方が早い病になる
  • マネージャーになり部下を育てることで得られる「してあげる幸せ」はエースピッチャーとして得られる「自分でできる幸せ」よりも遥かに大きい
• 「任せる」についての3つの勘違いしやすいポイント
  • 任せることは失敗が前提
  • 丸投げではない
    • 担当させるが途中経過はちゃんと見るしすぐに助けられる体制は整えておく
  • 他人に任せても楽にはならない
    • 仕事を任せても最初は必ず仕事量が増える
    • 「してあげる幸せ」を感じつつ、辛抱強くやっていく
• 罹患者は「自分大好き人間」
  • 自分に依存する人とばかり付き合う人
    • 承認欲求を満たしたいだけの利己主義者
  • 利他主義で生きることが最も自分を満たす方法
    • 自分の幸せと他人の幸せを別々に考えること自体が間違っている
    • 顧客満足度と従業員満足度の話
      • 後者なくして前者はない
• 無知の知（ソクラテス）
  • 自身が物を知らないということを知らないと無根拠に自信家な人になり自分がやったほうが早い病になる

第4章 「自分でやった方が早い病」への処方箋

• 一度徹底的に利己的になり痛い目にあう
  • 悩みの量と気付きの量はイコール
    • (確かに鬱になって1日中考え事をしていた頃が一番成長した気がする)
  • 道具を持たずに災害地支援ボランティアに参加する学生の話
• 上司のジレンマと戦う覚悟を決める
  • 短期的な成果と長期的な成果の両方を追い求めるということ
  • 上司は部下よりも仕事が多いということを受け入れる
  • 成果が求められたら自分が頑張る、そうでないときは部下に仕事を任せる、を振り子のようにやっていく
• 「任せる」とは「失敗させる権利を与えること」
  • 吐くくらいのプレッシャー、胃が痛くなるくらいのプレッシャーの中で実践を積むからこそ、部下は成長するのです。
    • (気軽にやると人が死にそう)
  • 部下一人でやらせて、何度も失敗を繰り返さなければ、成長にはつながらないのです。
    • (これはわかる)
  • 失敗しないために、自分の頭で考えた工夫を試行錯誤します。それが部下の血となり肉となっていくのです。
    • (失敗したら答えを出した上でどうしたらその答えにたどり着けるかを更に教えたり考えさせたりするのが良いと思っている派)
• まわりの人をヒーローにする
  • (読んでいてどこか腑に落ちない)
    • (「リーダーとはそういうことではない、自分で考えろ」は投げやりすぎでは)
  • (優秀なメンバーが他のメンバーの成長にコミットするとチーム生産性が上がる、というのは良い話だと思う)
• 「任せる」は「仕事をふる」ではない
  • 仕事をふる：ディレクションは自分がやって作業の一部をお願いする
  • 任せる：仕事と責任をセットで任せる
• できないうちにやらせるとできるようになる
• 日々の仕事を 120% でこなすことで初めて責任感は認めてもらえる
• 任せた仕事にどうしても口出ししたいときは「これは独り言だけど…」のように「つぶやき戦術」をとる
  • (これは普通に口出ししてるのと変わらないでしょ…)
• 仕事を任せるとき、PDCA の PCA はサポートする
  • 罹患者は D をやってしまいその他をやらない
• 著者の経験として、面談は会議室よりコーヒーショップの方が部下からよく意見が出る
  • (良いかもしれない（相手がコーヒー好きなら）)
• あえて70点のマニュアルを作る
  • 30点分、作業者が考える余地を残す
  • (そこで挑戦させる？という気もする)

第5章 「自分でやった方が早い病」が再発しないために

• 我慢することでは治らない。自分が変わる必要がある
• 仕事とプライベートは不可分であり、仕事において良きリーダーとなるためには良き人にならねばならない
  • 社内では酷い上司と見られているがお客様には尽くします、はすぐバレる
    • (店内で新人を酷く叱るラーメン屋っぽい)
• 他人を変えるのではなく自分が変わる
  • 過去と他人は変えることができません。
  • 私の体験上、人が心の中から変わるためには、10年はかかります。
    • 渡しの場合は10年かかりましたが、もっと早い人もいるでしょう。ただ、すぐには変われないということは断言できます。
• 心と行動の両面から変えていく
  • 悲しいから泣くのではなく、泣くから悲しいーー。
  • 気持ちが落ち込んでいるときは上を向く、苦しいときは無理してでも笑顔を作る
    • （心理学的な裏付けが欲しい。論文ありそう）
• 心を変えれば行動が変わる
  • うつ病の治療法「認知行動療法」
    • 考え方を変える認知療法と行動を変える行動療法を合わせた総称
  • 認識を変える: リフレーミング
  • 自分でやった方が早い、という認識をリフレーミングする
• 行動を変えれば心が変わる
  • 部下に任せるだけじゃなく自分が変わる
  • 柔道家の多くは意味が分からず礼をしているが、1万回2万回と行うと意味がわかってくるという話
• 鉢植えに水をやると我欲がなくなる
  • 鉢植えに水をやるという利他行動に対して、自身の食事という我欲を優先させてしまう
    • 水やりに意味をもたせることで自身の人としての成長を促す行為に変えた
  • 親に呼ばれたら "はい" と返事をするのと同じ
    • 面倒くささを捨てて相手を受け止めるということ
• 自身が変わるためには師を見つけるのが良い
  • (「あの人ならどう考えるか」という視点を持つことはしばしばある。これは師か)
  • 師の師、師を師とする人を辿ると多くの師が見つかる
• 森信三先生は「学問の中で生き方につながらない学問は一切無駄であるといったことをおっしゃっています。
  • (僅かにでも生き方につながらない学問は存在するのだろうか？つながる・つながらないは主観評価するものなのだとしたら、数学はつながらないので一切無駄とする人が多くいそう)
• 身近にいると、その人の嫌な部分しか目に入らないですし、その人のすごい部分に気づかないのです。
  • (嫌な部分も目に入るというのはそうだけど、すごい部分にも近いほうが気づくのでは？富士のように遠くから見える凄さはなんとなくそう見える、というだけでは）
• 師が見つけられないのはこちら側に問題がある
  • 自身が人として幼いと相手の嫌な部分を見るとがっかりする
  • 自分にも欠点がいっぱいある、自分にも至らないことがたくさんあると気づいたら、他人の欠点や至らなさも許せるようになるのです。
    • 自分の欠点や至らなさに気づいていないのが罹患者の特徴
  • 我以外、みな師なり
• 陰徳を積むことで人として成長する
  • 言いふらしてする施しである陽徳と陰でこっそり行う施しである陰徳
  • 陰徳はエネルギーを得られ、陽徳はエネルギーが失われる
    • アウトプットするとはてブで心無いコメントが付き消耗する（陽徳）
    • 陰徳を積む（インプットする）と自信がつき余裕が持てる
  • リーダーの仕事は陽徳なので陰徳を積んで人間的に成長しなければならない

おわりに

• 自分でやった方が早い病はあらゆる人間関係について言える病
  • 夫婦関係・恋愛関係