b

人に頼む技術 [review]

この本は、他人と協働するすべての労働人、すべての生活人にとって示唆を受けうる内容が記されている。社会的動物である以上、どこかのタイミングで他人とコミュニケーションを取りながら数々のイシューに取り組むことがある。その際に、自分一人だけで課題を解決することが難しいが、人にアドバイスや知見を乞うことで解決に至ることができるシーンがある。ここで人に頼む技術が必要である。

もし、周りから必要なサポートを得られていないと感じるなら、それは自分の責任である。人は、自分が求めていることが、はっきり言葉にしなくても伝わっていると見なす傾向がある。心理学ではこれを透明性の錯覚とよぶ。自分が何を必要とし、どんな助けを求めているのか、他人には分からない。

他人への動機づけ

本書では、人を動かす力には大きく3種類あると述べている。それは仲間意識、自尊心、有効性の感覚である。

仲間意識

同じチームであるとか、同じ人種であるとか、何でもいいので共通項を見つけ出すことは一つのきっかけに過ぎないが、人に頼みごとをするうえで有意なフックとなることがある。

自尊心

人は、自分のことを善いとみなしたがる。誰かを助けることで自分は善いと感じることが出来そうであれば、動く

有効性

イーロンマスクが週に100時間働くのも、育児をする親が一日中子供の面倒を見るのも、それができるのは、自分の行動が現実の世界にとって有効なムーブであると信じるからである。

もし自分の行いが報われることがなく、現実に影響を及ぼすことがないと虚無感に苛まれることがあれば、有効性の感覚が失われ、酷い場合は抑うつ状態になる。

良い頼み方、悪い頼み方

悪い頼み方が以下。

  • やたら謝る...相手の同族意識帰属意識が薄れる
  • 言い訳をする...「こんなものあなたに頼むほどでもないのだけど」的な態度を表明するな。
  • 頼みごとが些細であることのアピール... じゃあ自分でやれ
  • 借りがあることを思い出させる... 「奢ったんやからやれよ」って言われたらムカつくよね

頼み方のコツは、仲間意識・自尊心・有効性の利用である。

集団への帰属意識の仕組みを理解し、いつどんなときに他社と同属であるか知ることが重要である。同属意識があるとその相手を助けようとする動機が生じる。同じチームにいる、同じ目標の実現を目指している、などの共通点の中から注目するべき事項を選択する。

自尊心をくすぐるこつは二つ。自分のものを与えることで、与えた物の価値が高まったような感覚を生じさせること。自分にしかできない、唯一無二のサポートであるという意識を高めさせること。「あなたにしかできないからこそお願いしたい」といったニュアンスをもたせることで心は動く。

有効性について。

自分が誰かを助けたことで変化を起こしたことに人は手ごたえを感じる。だから、頼みごとをするときにも有効性に訴えかける。

頼みごとによって何を得ようとしているかを伝えるようにし、感謝を伝え、助けてくれたことによる結果を知らせるようにする。

所感

ソフトウェアエンジニアにとっても有用な技術であると感じた。チーム内で知見を共有したり教えを乞う際に必要なことである。

この本を読む前から、自分自身で試行錯誤しながら会得していったことも多く感じる。自分が分からないこと・解決したいこと・実現したいことを相手に伝わるようにテキストでコミュニケーションをとる練習はアルバイトとしてキャリアを始めたころから徐々に行っていった。

エラーステートメントだけを貼り付けて「わかりません、どうすればいいですか」というのはまさにアンチパターン、透明性の錯覚である。

これまで自分がやってきたことの心理学的抽象化がなされているため、ジェネラルな技術でありあらゆる分野に転用可能であると感じた。

心理的安全性が少ないから人に頼むことができないという意見もたまにあるが、心理的安全性を担保するうえで上記で紹介した3つの要素を個々人が把握しておくことが重要であると感じる。

悩み

Atcoder伸びない

コンテストに出て、復習をしていない

今までに出たところをすべて復習をしてみて、自分の力で解けることを確認して、そのうえで過去問に取り組むというサイクルにチャレンジする。

ゴールデンウィーク序盤進捗2023

2023年のGWは有給は取らず、実家にも帰らず、部屋にいるかジムにいるかになりそう。

予定は某日に横浜スタジアムに行くくらいで、残りはコードを書いてTOEICにむけた勉強をするつもりをしている。Kindleに積んでるものも目を通していく

4/29~4/30

4/28の業務終了後、即就寝。2時ごろに起床し、以後横になるも眠れず、朝4時ごろから風呂に入りMLBを見ながらストレッチをして松屋へ行き朝ごはんを食べる。猛烈にトムヤムクンを欲しヤムヤムを買いにドン・キホーテに行くか迷うもめんどくさくてやめる。ご飯を食べたらジムへ直行。この時点で5時半くらい。ゆっくり準備運動をしてベンチプレスとデッドリフトを行う。7時くらいに終了し、マックでコーヒーを飲みに行くことを画策するも、開店直後にもかかわらず大行列ができていて?????となる。普段は人通りが少なめのおとなしい街で、平日ではほとんどない光景。GWの襲来を実感する。

帰宅し、BOSとCLEの試合を見ながら、2日分のTODOリストを作り始める。

  • React/Redux/TypeScript/Redux-Sagaを用いて、APIサーバから受け取った値を表示するアプリケーションを作る
    • containerでprops受け渡し失敗してるところでとまってるのでそれを直す
  • GoでRestfulAPIを作ってCloudRunにデプロイする
    • とりあえずhello worldから入り、アプリケーションのデプロイができることを確認する
    • APIサーバ自体は今後も継続してつくる
  • TOEIC
    • 金フレ
    • 文法特急
  • kindle
    • コンサル本(メン獄、3年間、1年目)
    • ロジカル本(ロジカルシンキング、問題解決プロ)
    • 人に頼む技術
    • system design interview
  • AWS SAA本
  • C問題解く。過去100回くらいのABCから

本については全部読むわけではない。唾つける程度のものもあれば、通し読むものもある

これ書いてる時点でCloudRunと人に頼む技術を進めた。

野球見てしまってる。つらい。これから外出しないといけない。

Mechanism of improving listening ability in foreign languages

私見かつ仮説検証中。TOEICの公式問題集のリスニングパート、特にpart3/4を題材に扱っている。TOEICの問題に限らず、このフローは流用可能な感触がある。

  1. 通しで問題を解く。回答はメモ用紙に記入
  2. 再度何も見ずに聞き直す。一回目で聞き取れなかった箇所をチェックする。また、聞いたうえで一回目の回答と異なると思った場合は横に別の回答を書いておく。
  3. 何も考えずに採点だけする
  4. 間違えた箇所を優先的に何も見ずに聞き直す。
  5. 間違えた箇所のスクリプトを見る。音声を聞きつつスクリプトを音読する(オーバーラッピング)。そのあとは音声を聞かずに音読だけを行う。納得いくまでオーバーラッピング、音読を行う。シャドーイングはやってもやらなくてもという感じ。できるに越したことはない
  6. 正解した箇所も一通り音読する。
  7. 時間を置き、会話文の音声だけ聞く。脳内でスクリプトがある程度浮かべば次に進む。無理なら聞き直す。

一番重要なのは5だと思う。聞き取れない理由は発せないからだなと思う。聞き取れるということは自分で発することができることが多い。

I'll be accompanying you this week to help you get used to your route.は何回聞き直してもなんて言ってるか分からなかったのでスクリプトを音読してみたら全然流ちょうに言えなかった。

help you get used toってめっちゃ言いにくくない...?ってなってから何回も聞いて発音してしみ込ませた。

ちなみに日本語訳はほとんど目に入ってない。英語自体はそんなに難しくないので、難易度的にはちょうどいい気がする。英語をきいて日本語を介さずに直接脳内で情景がイメージできる状態を目指す。

あとは量やるだけだなと思う。

Statcastを知り用語を調べるフェーズ

2022年の後半くらいからMLBを見るようになりました。2000年代・小学生の頃、NHKイチロー選手城島選手が所属するマリナーズや松井選手が所属するヤンキース、松坂選手が所属するレッドソックスが放映されていれば必ず見ていました。専門雑誌を購入するなどしていたので選手の名前もある程度覚えていました。

10年くらい野球を熱心に見ていなかったのですが万年Bクラスの地元オリックスの台頭もあり野球を見るようになり、その流れでMLB中継を見るようになりました。

ここまで来ればbaseball referenceやsavantの存在を知るようになります。OPSやWHIPといった指標は理解していますが、savantで選手を検索したときに表示される指標の意味を完全に理解できていないので、和訳しておこうと思います。

余談ですがbaseballsavant.mlb.comのWebアプリケーションはReact/Reduxで構成されていますね。ReactDevToolでもコンポーネントやstateと実行されるActionのログが表示できて楽しい。仕事でやりたい。

Statcastとは

野球のデータの分析と収集を可能にするツールです。バッティングであれば打球角度・打球の初速、ピッチングであればボールのスピンレートや変化球ごとの投球箇所のホットゾーンを定量的に表現することができます。

MLBにおいてStatcastは2014年に一部の球場で試験運用を行った後、2015年に全30球場に導入されました。高性能カメラとホークアイという軍事用レーダーの技術を用いてボールの回転やスピードを検出する装置により計測が行われています。

計測対象

  • 投球(速度、スピンレートと方向、動き)
  • 打撃(打球速度、打球の打ち出し角度、飛距離)
  • 走塁(最高速度、塁間タイム)
  • 守備(アームストレングス、捕球確率、キャッチャーのポップタイム)

用語

これを書いてるまさに今、中継されているBOS-MILの試合におけるMILのスターターWadeMileyのstatsを見ます。

PlayerAppsの欄には選手の経歴やビデオが掲載されています。PitchDistributionは投球割合の正規分布曲線が描かれている。そしてPercentileRankingsが一番わかりやすそうな見た目をしている。用語の意味が以下。

  • Avg Exit Velocity...平均球速。
  • HardHit%..ハードヒット率。95マイル以上の出力を一回のハードヒットと定義。
  • xERA/xwOBA...期待防御率/期待出塁率
  • xBA..期待打率
  • xSLG..期待長打率
  • Barrel %...バレル率。打者が打球をバットの芯で捉え、かつその打球の飛距離が十分にあるとされるハードヒットのうち、さらに三塁打以上となる打球の割合を表す指標
  • K%..三振率
  • BB%.. フォアボール率
  • Whiff%...空振り率
  • ChaseRate...打者がストライクゾーン外の球をどれだけ追って空振りするかを示す
  • Extension...ピッチャーのリリースポイントと地面がどれくらい離れてるかを示す。
  • Fastball Velocity/Spin...直球の速さとスピン

BBが90%ってことなのですが、そんなに多いのかな。'17に最多四球を記録しているみたいですが以降は改善傾向にあるっぽいですし今日の試合見てても悪くなかったと思います。まあ、シーズン入ったばかりなのでデータに偏りが出てるということですかね

バッターの例も見てみます。Alex Verdugo。

三振は少ない、出塁が期待できるという感じですかね。

間違ってたらコメントで教えてください。

というかこれ書き終わるころにはBOSが負けておりました。正尚さんは4の2でした

それは気分の問題

夜は9時くらいに寝る。(計画的にはできない。落ちるように寝ないと寝られない。)

そうすると朝5時くらいに起きられる。結局私は8時間寝ないとダメな人間だということがとてもわかる。

10時くらいに寝たら6時に起きられるだろうと思ってやってみると気づいたら8時半とか9時になってたりするので自分の体がとても難しい。全くコントロールできていない。

でも朝5時とか6時に起きられる日は7時か8時にジムに行ってBP/DL/SQのどれか2つをやって1時間くらい経ったらマックでコーヒーを飲みながらTOEICの対策をしたりMLBの試合をチェックするなどして英語に触れて、家に帰って仕事を始める。

帰ってくるととてもいい感じのコンディションになっている。

金曜日は気付けば深夜2時くらいまで起きていて土曜も同じ、日曜は早く寝ようと思っても寝られなくて、こうしてリズムが崩れていく。

またやり直し。落ちるように寝られるまで。

大谷翔平のように自分の体をコントロールして、結果を出せる人間になりたい。

Redux-sagaで非同期処理を行う

サーバサイドをやることが多くviewを用意するにしてもテンプレートエンジンを使って書く程度しかなかったので仕事で久しぶりにReactとReduxとSagaを使ってみて思い出すのに苦心をした。これを機に設計をして簡単なアプリケーションを作ろうと思う。題材は野球にしようかな

一旦やったことを箇条書きでポイントを書いておこう

要件

アプリケーションURLに特定のxx_idというパラメータが付されたとき、外部APIに対してリクエストを送り(foo.com/bar?xx_id=100)、レスポンス結果に含まれる画像を画面に表示する

やること

sagaを使う

パラメータを読み取って画像を表示させるまでの処理はすべてredux-sagaを使って非同期処理として扱う。

対象のcomponent・containerを確認する

redux.js.org

対象のコンテナを確認したら、sagaで書いた処理を実行するためにReducerとActionを定義して、mapStateToPropsでstoreにActionをdispatchする処理を書く。

storeには新たにxxUrlLoadingというプロパティをboolean型で追加し、APIのレスポンスが返ってくるまでLoadingコンポーネントを表示する。

覚書

パラメータをどう取得するか

Google検索するとReactRouter使おうって初めに出てくると思うのですが、this.props.document.location.searchみたいにpropsでlocationの情報を渡して取得しました

saga

takeLatestは並べた関数の順に最新の情報を更新していくのか。

call

sagaでAPI呼び出しをするときはcallファンクションを使う。

const apiResponse = yield call(Api)

パラメータをpayloadで取得して、payloadの一部だけパラメータに使いたいとき

const xx_id = payload.xx_id
const apiResponse = yield call(fooApi, { xx_id })

(fooApiはmodel層で定義して、引数はオブジェクト形式で定義していると想定してください)

これでxx_id=xx_idというパラメータがAPIに渡せる

関数をgeneratorで定義するわけ

developer.mozilla.org

JavaScriptはシングルスレッドで実行されるので複数のタスクを同時に並列に行うということが難しい。

async/awaitだと処理キャンセルができないけど, generatorだとyieldを使って関数の実行を一時的に停止できて、必要なときに戻ってきて返り値を利用することができる。

github.com