名もなき未知

エンジニアリングとか、日常とかそういうのをまとめる場所。アクセス解析のためGAを利用、Googleに情報を送信しています。商品紹介のためAmazonアフィリエイトを利用、Amazonに情報を送信しています。記事に関しては私が書いていない引用文を除いて自由にご利用ください。

「セルフトーク・マネジメントのすすめ」を読んだ

概要

少し自分と向き合う時間、分析方法を知っておきたいなと思ったので読んでみました。

自分が買ったタイミングでは Kindle のセールが開催されていたので、安く買えて手に取ってみましたが、これまであまり向き合ってこなかった分野だけに値段やページ数以上に学ぶところは多かったです。

本のリンク

自分の学びポイント

この本では『セルフトークを感情、欲求、思考、行動の引き金として自分の中に生まれる「言葉」』として話がなされています(狭い領域での独り言、ではある解釈です)。

セルフトークにも 2 種類あり、感情的であるセルフトーク A(ネガティブ、automatic)と、理性的であるセルフトーク B(ポジティブ、自発的、bear)に分類できる話を中心に構成されています。セルフトーク A を減らすことで自分自身を精神的・肉体的にコントロールすることで、生産性や集中力を上げられると語られています。

これに関しては思い当たるところがあります。 仕事が忙しい時期など精神的に安定していない時期はセルフトーク A が増えがちであり、オープンな場で何か話すのがつらいと感じる状況が私にもありました。 Twitter など SNS 系統での発言が減りつつあったのは、その影響は若干あります(その間も Slack や Discord では元気にしてました)。

また、セルフトーク A を減らし、セルフトーク B に変えることにより論理的な戦略による生産活動の上昇、集中力の強化、ゾーンに入るなどのメリットが享受できる、とあります(Part2 くらい)。

これも感情的になり手につかないことや、集中できないことは割と経験としてあるので、わかりやすかったです。 直近でも技術書典の原稿とかもっと書きたかったのですが、疲れ切っていて手につかなかった事が上がります。 それも 1 つの感情的な面でブロックされていることによる集中力の低下と捉えられます。

Part5 ではセルフトークを減らす方法について紹介されています。いくつか紹介されていますが、自分の中で目を引いたのはルーチンを作る、未完了を減らすの 2 つです。

ルーチンについては、必ず成功するような動きを取り入れるのが良さそうだと感じています。イチロー選手の例が挙げられていますが、ヒットを打つのはせいぜい 4 割以下の確率であり、成功確率は決して高いものではなく、不安定なものです。 しかしバッターボックスに入る一連の動作は失敗することがないので、そこで集中力を上げ、雑念を払い切り替えることができているのだと思います。

未完了を減らすについては、小さく残っているものが蓄積しストレスになるものと考えられるため、減らすに越したことはありません。 自分自身、タスクコントロールが下手なので、どこまでが適度か、また日々に置ける今日やれることの完了度合いは? みたいなものをウォッチすることをやらないとなと思ってます。 たまに日報的なメモを書いたりすることもあるのですが、たまにやるじゃなくてもう少し積極的に蓄積していきたいなと思いました(小さく長い期間で変化していくもののウォッチにも使えそうなので)。

残りについてはまだ至りつけていないので、そういうものもあるんだーと思いながら一旦全体を読みました。

展望

この本を読んだ認識していなかったセルフトーク A を認識できるようになったのは、大きな学びであったと言えます。

調子が悪いときの兆候を自分自身で客観視して修正できるようにこれからはしていきたいですね…。

最近は少しづつ落ち着いてきたので、余裕があるのですが、まだセルフトーク A に分類されるものが多少あるなと感じています。余裕があるうちに、もう少し周りを見てみたり、日常を整える(急に眠れなくなったりすることも無くはないので…)ことをやっていきたいと思います。

ルーティンについては早急にやりたいなとおもっていて、昔から入眠なり仕事から気持ちを切り替えて休むことがへたくそだなと自分でも感じているので、節目で切り替えるための儀式というか、そういったものを用意してあげたほうがいいかもしれないです。

まあ、何にしようかなというのは悩ましいですが…。

まとめ

自分の中で渦巻く独り言がどういった影響を精神/身体に与えているのかを客観的に捉えられるようになれそう、と思いました。 (何となく認識していることと、言葉にして定義できるものを認識しているのでは、意識や理解のレベルが違う。。。)

またセルフトークを使うことや減らすことは、コーチングでも活用ができます。気が付くと社会人歴も現職での所属年数もそれなりになってきたこともあり、そういうのも経験・度胸・勘だけでなく、知識も組み合わせてより良い方法を模索できるようになりたいですね。

コーチング、経験不足で未だによくわからないですが)

というところで、集中するためにも心を落ち着けるようにセルフコントロールしていきたいと思います。

ファクトフルネスを読んだ

7月あたりに割と仕事が忙しくなって、8月はのんびり過ごしており、外向けのアウトプットも完全にお休みしていたのですが、久々に書くことにします。

ファクトフルネスをようやく読みました。実際のデータを見てどう判断して行動していくのか、というのはバックエンドを支えるデータに向き合うことが多いエンジニアにとって、学びのある1冊だったと感じています。

本のリンク

丸1年、積み本になっていたらしい。

学びがあったところ

まあ、思い出したくなったら「ファクトフルネスの大まかなルール」というページが非常によくまとまっているので、そこを見ることとして…

全部で10個のルールのうち、面白いなと思ったのは、次の3つです。

  • 悪いニュースのほうが広まりやすい(2. ネガティブ本能を抑える)
  • ゆっくりとした変化でも、変化していることを心にとめる(7. 宿命本能を抑えるためには)
  • ひとつの知識が全てに応用できないことを覚えておこう(8. 単純化本能を抑えるには) 

残りについては実際に本を手に取って読んでみるのがおすすめです(全部おすすめしたいですが)。

悪いニュースが広まりやすい話、これはわかりやすいですね。ミスとかトラブルの話は広まりがちな気がします。安定運営できてます、とか実際すごいことであるはずなのですが、特に大きく取り立たされる機会などはあまり聞かない気がします(しいて言えば、カンファレンスとかで聞く程度か?)。 ここは何とか(任意の言葉)に関する批判とかをインターネットで見ている限りでもそうですが、実際の数値を見ると、そんなに悪くなかったり、シェアが高かったりということもあるので、実際のデータを見てバイアスをかけないように分析することが大事かと思います。

次にゆっくりとした変化でも、変化していることを心にとめる、ですが、これはもう少しこれからやっていきたいなと思ったことでもあります。というのも、日々生活をしていく中で学んでいることが自分自身あるはずなのですが、結構それを無視してしまって結果長いスパンで見た時に何をしていたんだっけ?できるようになったこととは?みたいな現象を多く経験してきているように思います。 そういう意味で、日々何をしたのか、学んだのか、みたいなログはちゃんとつけて積み上げて自分が成長していることを感じたいです(要は忙しくなりすぎて自尊心が失われていた気分になっていた時期があり、そういうときこそ自分が積み上げてきたものをちゃんと見て、安定した精神状況に戻れるようにするのが大事なのかなと思います)。

最後に、ひとつの知識が全てに応用できないこと、これはうーん、まあ反省もあります。実際にある程度社会人経験を積んでいく中で、年下の人から聞かれたことに対して、確証のある回答が常にできていたわけでもないですし、データを見ずに印象で語ってしまっていることも多々あります。これも今後改善していきたいことで、データを見て現実から物事を語ることや、データを見てないときは知らない!と言い切ってしまう勇気も時には出していかないといけないな、と思いました。

全編通してですが、人が抱いているイメージは往々にしてその分野を知らないイメージのままであるか、何年か前の事実をアップデートしていないことで、今起こっていることとの乖離が起きがちだという現実が指摘されているように思えます。この本を読むまで、実際、世界の格差問題について多く誤解をしていました。今は10年前に比べてずっと良い世界になっているという認識を改めるとともに、最新のデータから何が起きているのかを分析し、本質的なことを発見することの大事さに気づかされたと感じています。

まとめ

また数年後に改めて読みたい本です。忙しい方は「ファクトフルネスの大まかなルール」や、各章の最後だけでも読んでみるだけでも感じるものがあると思っています。

Reactのguide to main conceptsを読み始める人~その3~

継続力ですよ。

概要

この辺を読みます。今回はマジで新しく読む。てか長かったので 1 章分だけにする。

State and Lifecycle

ステートとライフサイクルについて、なのですごく大事そうな予感がする。詳細はここ React.Component – React

とりあえず前回作った 1 秒ごとに更新される時計をもう少しやっていくらしい。

function Clock(props) {
  return (
    <div>
      <h1>おはようございました~</h1>
      <h2>今は{props.date.toLocaleTimeString()}です~</h2>
    </div>
  );
}

function tick() {
  ReactDOM.render(
    <Clock date={new Date()} />,
    document.getElementById('kiryu')
  );
}

setInterval(tick, 1000);

まあどう考えてもレンダリングは1回にしたいし、そのためには Clock をレンダリング対象にする必要がある。それをステートを使って表現していく。

Function から Class に変更する。

class Clock extends React.Component {
    render() {
        return (
            <div>
                <h1>おはようございました~</h1>
                <h2>今は{this.props.date.toLocaleTimeString()}です~</h2>
            </div>
        );
    }
}

続く文章はあんまり理解できてはないんだけど、Class として定義することによって、Clock がインスタンスとして扱えるようになる。 これによってローカルでステートを持ったり、ライフサイクルメソッドを使ったりできる(この文は重要っぽい)

で、それに従ってコンストラクタの定義や state を登録していったらこういう形になった(すごく直感的でよい)

class Clock extends React.Component {
    constructor(props) {
        super(props);
        this.state = {date: new Date()};
    }

    render() {
        return (
            <div>
                <h1>おはようございました~</h1>
                <h2>今は{this.state.date.toLocaleTimeString()}です~</h2>
            </div>
        );
    }
}

function tick() {
    ReactDOM.render(
        <Clock />,
        document.getElementById('kiryu')
    );
}

親クラスのコンストラクタを呼びつつ、state に日付情報を持つような形。

この状態でさらに、ライフサイクルメソッドである componentDidMount, componentWillUnmount を刺してみる。

this.props は React 自身が用意し、this.state は特別な意味があるので、このように使える。自分で使いたいものは自分で定義してくださいと。

なのでここでは timer を登録/削除を行ってる。そして timer を通して state を変更することで、時間の更新を実現している。

class Clock extends React.Component {
    constructor(props) {
        super(props);
        this.state = { date: new Date() };
    }

    // ClockがDOMに挿入されるときに呼ばれる
    componentDidMount() {
        // 1234 とか不真面目にするとたまに1秒飛んで表示される
        this.timerID = setInterval(
            () => this.tick(),
            1000
        );
    }

    // ClockがDOMから削除されるときに呼ばれる
    componentWillUnmount() {
        clearInterval(this.timerID);
    }

    tick() {
        this.setState({
            date: new Date()
        });
    }

    render() {
        return (
            <div>
                <h1>おはようございました~</h1>
                <h2>今は{this.state.date.toLocaleTimeString()}です~</h2>
            </div>
        );
    }
}

ReactDOM.render(
    <Clock />,
    document.getElementById('kiryu')
);

State についての注意点は

  • setState() を使って更新し、直接更新しない
  • this.propsthis.state は非同期に更新なので、直参照すべきではない。使うのであれば、function でラップして受け付ける。
    • カウンターとかで関連するかも
  • setState() では結果がマージされるので、別々の箇所で update していたとしても、入れたものは取り出すことができる
    • 同じ名前の要素が色々な場所で更新される場合は要注意かも
  • データは下のものに伝わる(おそらく子のほうに流れるって意味だと思ってる)
    • state はローカル定義なので、カプセル化されている。子のコンポーネントには当然渡すことができる。
    • ただ子のコンポーネント的には、それがどのようなデータなのかはわからない(props, state, または手打ちなのかの判断ができない)

おまけ

知らなかった単語を並べる。

  • crucial: 決定的な、非常に重大な

まとめ

いきなりクラスっぽくなって、再利用可能な UI を作るためのノウハウを叩き込まれたような気がします。

またデータフローに関しても割とカプセル化されていつつも、state っていう特殊なやつがよし何やってくれそうなので、利便性は高そうです。

(でも何でもかんでも state に突っ込まれるみたいなパターンもあって、重複するようなキーを更新してバグるとかあると、大変なんだろうなぁ…)

あとは直接編集しないとかも大事ですね。state に関しての注意点は実際に書いてみると忘れそうなので、また見直してみようと思います。