useEffect 覚え書き
useEffect
について理解な曖昧な部分があったので改めて調べた。
TL;DR
useEffect
はレンダリング後に処理(副作用)するときに使う- 第2引数に依存値を設定する。
[]
と空にすると初回レンダー時のみ、第2引数自体を設定しないと毎レンダリング後に実行される - DOMの画面反映前に処理を実行したい場合は
useLayoutEffect
を使う useEffect
の返り値にはクリーンアップ関数を指定できる- クリーンアップ関数はReact17で仕様が変更され、常に次のレンダリング後のDOM状態が画面反映された後に実行されるようになった
useEffect
の基本
useEffect
は、ReactのHooksの一つで、レンダリング後に何かの処理(公式ドキュメントでは副作用と呼ばれてる)をしたいときに使う。
useEffect(() => { // 処理 }, [ hoge(依存値) ]);
レンダリング後に呼び出されるため、useEffect
が実行される際は、DOMは正しく更新されていることが保証されてる。
毎レンダリングで呼び出される必要がない場合は、第2引数に依存する値(変更があったらuseEffect
を処理したい値)を設定できる。初回レンダリング後のみで呼び出したいときは、空配列[]
を設定。
useEffect
はレンダリング後に非同期で実行されるので UX 観点では良い傾向がある。
ただ、時には同期的に処理をしたい(useEffect
を実行した後に画面に反映したい)ときがある。その時は似たHooksの useLayoutEffect
を使える。ただ、もちろんその分画面反映が遅れるのでご利用時は注意が必要。
クリーンアップ関数について
useEffect
は必須ではないが戻り値としてクリーンアップ関数を設定できる。クリーンアップ関数は自分は未だにあまり使ったことがないが、後始末的な位置付けで必要な処理のよう。
公式ドキュメントの受け売りだが、例えば、外部APIの購読に対して、クリーンアップ関数は解除をする処理を書くなど(ときには後始末をしないことでメモリリーク等が起こる可能性があり、それを防止するためにクリーンアップする)。
hooks
がない時代は、Reactのライフサイクル毎(例えば componentDidMount
と componentWillUnmount
)に書く必要があり、関連性の高いコードが分散したり、記述し忘れによるバグ発生が頻発してたらしい。
ちなみに公式ドキュメントを拝借するがコード例。
useEffect(() => { function handleStatusChange(status) { setIsOnline(status.isOnline); } ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange); // Specify how to clean up after this effect: return function cleanup() { ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange); }; });
そして、このクリーンアップ関数が、最近React17によって破壊的変更があったらしい。 詳しくは下記の記事に分かりやすくまとまっている。
要はReact17では常に次のレンダリング後のDOM状態でクリーンアップ関数が実行されるようになったとのこと。ちなみにReact16までは、アンマウント時なのか再レンダリング時なのかでDOMの状態が異なっていた。なので統一感が出て改良されたが、破壊的変更なので気をつけないとねということ。
useEffect の使い方
useEffect
は処理のタイミングを依存値によって制御することがよくあり、正しく使わないと思わぬバグや不要なレンダリングを行いパフォーマンスを損ねるケースがよくあるので注意が必要。
下記の記事が参考になった。
個人的にまとめると、
useEffect
内でしか使わない処理は関数化するにしてもuseEffect
内に入れてしまう(関数がuseEffect
の第2引数の値以外にから影響を受けないことを保証できる)- 複数の
useEffect
でpropsやstateに依存する関数を共通で呼び出す必要がある場合は、useCallback
を利用して関数を定義し、複数のuseEffect
で使うと良さそう - そもそもpropsやstateに依存しない関数はコンポーネントの外部に書く(内部に書いてもいいが副作用処理になることがほとんどなので、結局
useEffect
で依存配列を[]
に設定する感じになるので、外だしした方が無駄な処理も減り、可読性も上がる)
2020年の振り返り
明けましておめでとうございます。 2020年もあっという間に明けたわけなので、遅ればせながら2020年の振り返りをまとめてみる。
各目標の振り返り
Webエンジニアのスキル
2019年の後半からアラサーながらエンジニアとしてのキャリアを歩み始めたので、2020年はエンジニアとして満一年を過ごす初めての年だった。
とりあえず下記に参考になりそうなロードマップがあったので参考にすることに。 roadmap.sh
- 基礎教養
- フロントエンド
- バックエンド
- インフラ
各領域に分けて項目をスコア化しつつ、年初に現スコアを整理し、各項目に目標スコアを設定した。 独自のスコアリングなので、一般的な感覚とはずれている可能性が高いが、とりあえず自分用と指標になればと思い行った。
定性目標はかなりざっくりなのであまり参考にならないが実際は各項目のスコア化した定量目標を設定していた。 各領域の定性目標を挙げると、
- 基礎教養:Webエンジニアの最低限の基礎教養習得
- フロントエンド:現在所属している企業のチームの特定の人と同じレベル位のスキルに
- バックエンド:基礎部分を理解
- インフラ:最低限の知識
結果として、どの領域も思い描いていたレベルには成長できなかった感覚。
バックエンドとインフラは現在業務でも触れる機会が全然ないし、学習の機会も確保できなかったので全然分かっていない状態。
フロントエンドは一応自分の専門領域ではあるが、目標にしていた人のレベルには達していない(もちろんキャリアがある程度あるエンジニアに一年で追いつけるはずもないかもだが)
まあそれでも主にReactを中心とした開発に関しては、それほど遠くないレベルにはなってきた気もする。ただ他の部分は全然まだまだ。
アウトプット面
アウトプット量に対しても目標を持っていたが、こちらも蓋を開ければ全くの未達成。 個人開発、読書、ブログ等のアウトプット量が全然足りていない。
一方で、アウトプット大全を読んだり、Twitter等の界隈を覗くようになって、アウトプットに対する価値観は変わり、ますます重要性を感じるようになった。もっと積極的にアウトプットしていきたい。
英語
これは昔からやろうやろうと全然できてないが、エンジニアになって英語ソースを毎日見かけるようになったので重要性は自分の中でもかなり高まっている。
ただこちらも思ったように学習できず終い。TOEICも受けたことがないが、試しに夏頃にYouTubeでやってた模試TOEICみたいなものを受けてみたら、430点位で、こんなに低いのか...と衝撃だった。
一応英語ソースも翻訳しつつ読むこともあるが、独力の英語力は崩壊していたらしい...
とりあえず来年は手堅く600点位を目指してみる。英語力はエンジニアである以上非常に大事なので頑張る。
お金
思ったより貯金できなかった。 そして、何よりお金の勉強をして資産運用を始める(前からやってなくは無いが)予定だったがこちらも全然だったので来年。
その他
会ったこと無い人に会う、行ったこと無いところに行く、やったこと無いことをやる、 のようなNEWに出会う目標も立てたが、こちらも大幅に目標に至らなかった。
正直今年はコロナもあってやりにくかったが、その気になれば手段はあったはずなので反省。
総括
総括すると目標は全く達成できていなく「何してんねん自分」という感じ。
原因を考えるとすると、
- 学習量が足りない
- 自分は遅くエンジニアになっているので、もっと過去を取り返すかのごとく学習する必要がある
- プライベートでももっとシビアに時間を作る必要がある
- 業務では思ったより開発に時間をかけれてない、これは自分のやり方が悪い
- 学習効率が悪い
- エンジニアに囲まれて過ごしていて、かなり多くのナレッジに取り巻かれているけど、上手くキャッチアップできてない
- 明確に目的を持って学習してないから、やることが目的になって吸収できてない
- 目標を立てたものの、それを達成するためのアクションプランに落とせてない
- 時間をコントロールできてない
- 業務中に開発に割く時間を上手く作れてない
- プライベートでの学習がマストだが、もっとシビアに時間を作る必要がある
- 継続ができていない
- 継続しようと思っている学習項目を継続できてない
- これもやることが目的になっているので、何をどこまでにやるのか、何のために取り組んでるのか日々問う必要がありそう
とにかく、2020年は全然だめ!!! 頭はクールに、ガムシャラにならないと。
2021年頑張りましょう
【書評】ひとりビジネスの教科書 | 自分のビジネスの第一歩を踏み出す参考に
たまたま本屋で見かけて気になった本を読んだので自分なりにまとめておきます。
読む目的
本書に期待する目的。
- ひとりビジネスをスモールスタートで始めるためのヒントを得る
- そのためにまずは何をするかのTodoを得る
序章
- 「〇〇したらやろう」は絶対やらない
- 行動ファーストであるべき。これはここ1年位でやっと実感して大事にし始めていることなので、このマインドは忘れず続ける
第1章 テーマ編
- 本書曰くのひとりビジネスのフェーズ
- フェーズ1:迷い
- フェーズ2:テーマを決める
- フェーズ3:コンテンツを作る
- フェーズ4:集客・販売
- フェーズ5:自動化
- コアメッセージを考えるべし「誰に x 何を x どのようにして」
- 自分のできることと人のニーズが合致する部分が狙い所
- 綺麗事ではなく、誰かの悩みを解決することに「ワクワク」できればビジネスとして続けていける可能性が高い
- 色々迷うことはあるが、結局直感を信じることは大事、そのためにも自分にも相手にも嘘なく正直に誠実に
第2章 コンテンツ編
- 最初はオリジナルにこだわらない、要はニーズがあるものを売ればいいので、そのために仕入れするのもあり
- 軌道に乗ってきたら商品開発する感じでOK
- 自分ならなにをできるのか考えてみる
- ちょっと語弊があるけど良く田舎でヤンキーが知らぬ間に親方とか社長になっているのもこうゆうモデルが多い(大体は人を売るビジネスだけど)
- 4つのポイントで商品を増やしていく
- 「制作者」「形態」「販売場所」「販売方法」
- 他人 x モノ x ネット x 自分 の組み合わせがまずはお金をかけず起業する方法
- 要は転売とかもこの形
- 意外に他人のモノを売るという観点は忘れがち
- 重要なのはニーズがあることなので、人のモノであろうが、ニーズを見極めて必要あれば仕入れて売るということは良さそう
- そこに何らかの付加価値や差別化を図れれば立派な商品になっているはず
- 「商品化できないか?」を常に意識。これ割とできるのあるっぽい
- 文字、音声、動画は売りやすい
- まさにnoteとかzennは取り組みやすいのでやってみる
- 商品充実の方法
- 組み合わせ、分割、深堀り
- 高額商品を必ず作る
- これは自分のお金に対するリミッターを外すことが目的
- これができないといつまで経っても今の自分の範囲内でのお金の動かし方しかできない
- ビジネスの設計図を作る
- 松竹梅で商品を設計する
第3章
- 情報発信はストック&フローで
- Twitterやブログ読者を増やすには、自分からフォロー・コメントすること
- この辺は何でもそうで自分から何かしないとはじまらない
- とにかく発信でもGive&Giveの精神で。確かに有名だったり発言力ある人はみんな決まってこれをやっている
- あとはとにかく継続
第4章
- 最強の集客は「紹介」
- 最たる例は口コミで、ひとりビジネスではこの口コミが発生するシステムを作るのが重要
- こくちーずの利用はおすすめ www.kokuchpro.com
- 1回1回の繋がりを大切に。Give&Giveの精神で真摯に対応
- 他の人に紹介してもらいやすいように、紹介用の紹介文などを共有して置くのもおすすめ
- 紹介文はやってみる。あとは名刺とホームページも作る
- 「アクティブなメアドを2万件持っていれば黙っていても食っていける」らしい
- メアドは大事に
第5章
- 広告は投資するほど売上は伸びる
- 成功のコツは事業を「自動化」すること
- 今日は何件売れたかなという状況を作ることは一つの目標
第6章
- ひとりビジネスとはコミュニティを作るビジネス
- ひとりでやろうとしない
- 良い仲間を作る
- 関係を補い合える良いチームを構築する
- 3 x 3 のマスの自分を中央のマスにおいて、他の8マスの機能と当てはまる仲間を埋めることでチームができる
第7章
- ミッションとビジョンを問う
- ミッションは使命、ビジョンは意思
- この2つが軸になる
- ミッションを問う
- 何を求められているか
- 自分を本当に求めているのは誰でどこにいるか
- その人のために自分に出来ることは何か
- ビジョンを問う
- 何の制約も無ければどんな風に暮らしたいのか
- 何の制約も無ければどんなことをしたいのか
- 何度もブラッシュアップして、すっと出てくるように
- 本当にしっくりくるものを見つける
- 本書全てをひっくるめて、とりあえず未完成でいいからアウトプットすることが重要
- 結局「行動ファースト」「アウトプットファースト」
まとめ
正直、そこまで自分にとっては学びの大きい内容ではなかった。何というか、言っていることに反論があるわけではないけど、具体的なネクストステップが見えなかった。
今の自分の状況と本の内容との相性があまり良くなかったのかもしれない。
特に学んだことを整理
- とにかくアウトプットファーストでどんどん行動するべし(色んなところで重要視されていることだけど再認識)
- ひとりビジネスの内容は「自分がポジティブに提供できる価値 × 世のニーズの掛け合わせ」を考える
- 商品は以外に仕入れる形でもOK、まずは人の真似をして、その後カスタマイズしてオリジナリティを出す感じで
- とにかく今の時代は情報発信するべし(SNS、ホームページ、動画)
- ひとりビジネスは口コミが大事、既存の顧客や繋がりを大事にして、誠心誠意対応することを心掛ける
- 仲間を見つけてチームで動くようになると良い
2021年に向けてアクションに移すこと
- アウトプット量を増やす
- 個人事業に関して自己分析
- 自分の提供できる価値の整理
- 世のニーズの整理
- 他者事例の調査
- 自分と似た領域で実際に個人事業をしている人をピックアップし、実際にどうゆう活動をしているかを調査して自分の動き方のヒントを得る
- ホームページを作る
- 名刺を作る
- 紹介用テンプレを作る(口コミが大事なので即座に誰かが誰かに紹介してくれるような体裁の自己紹介)
けどこうしてまとめてみると結構アクションプランできたので良かったのかも。
Week 40
2020/09/27 - 10/4 の振り返り。
やったこと
個人事業でのWebサイト制作を進めた位。今週は全然作業できなかった。
わかったこと
今週は平日にカフェに行けない日もあって、そうゆう日の進捗は悪い。夜家でやろうとしても進まない。どんなに意気込んでも当てにするべきではない。
ゲームが発売して、そちらをプレイしてて大幅に時間を使っている。やはり相当な時間泥棒...。 自分にとっては大きな楽しみなのでやるのは良いが、やることをやってからはもちろん、就寝時間も遅くなりがちなので時間を区切らないと(子供みたいなことを...)
次にやること
先週と同じ、継続。
- 平日はカフェに行く時間を確保(継続2週目)
- 作業時は動画を BGM 代わりにしない(継続2週目)
- ルーチンは「隙間時間」or「決まったタイミング」で行う(継続2週目)
- 重要度の高い目標を、週次 / 日次 で設定して自分が重要と思う方向に進捗するようにコントロール(継続2週目)
- 情報(気付き・後回し・トライ)をストック・運用するフローを作成(継続2週目)
ヒトコト
次週はプライベートで丸3日は潰れるのでそれ前提に計画。
Week 39
2020/09/21 - 09/26 の振り返り。YWTでまとめ。
やったこと
主には、個人事業でのWebサイト制作を進めたのと、今話題のZennで初記事を書いた。
わかったこと
先週の振り返りとして、タスクが多くある中で目的を見失わないように、
重要度の高い目標を、週次 / 日次 で設定
を改善方法としてトライしてみたけど、結構良さそう。日々の運用の中でも週の中でもこの指針を思い出すので、一日のタスクの計画の際に優先的に実行する意識が働く(ただし目標は未達成だった..)
あとは平日にカフェに行くことはやはり大事。迷いがないのでカフェ行こうかなーという無駄な時間も生まれないし、逆算して時間を捻出するようになる。結局人は時間を切らないと時間を使えない。
Zennの記事作成に時間をかなり使ってしまったが、結果的にアウトプットできたのは良かった。
Zenn に初記事出せたので昨日は満足。人の目に触れるとこに出すとなると変なこと書けないしすごい調べるから勉強になる。腐るほど言い古された言葉だけど、アウトプットで一番勉強になるのは本当に自分かも。
— 窮奇 (@quki_0910) 2020年9月28日
先週の振り返りをして今週の計画サクッとやろう。#とりあえず続ける
今後もどんどん続けていきたい。
次にやること
先週と同じ。とりあえず1ヶ月位継続すれば習慣化されるので継続。
- 平日はカフェに行く時間を確保(継続2週目)
- 作業時は動画を BGM 代わりにしない(継続2週目)
- ルーチンは「隙間時間」or「決まったタイミング」で行う(継続2週目)
- 重要度の高い目標を、週次 / 日次 で設定して自分が重要と思う方向に進捗するようにコントロール(継続2週目)
- 情報(気付き・後回し・トライ)をストック・運用するフローを作成(継続2週目)
【React】カスタムフックをハンズオンで試して理解する
React のカスタムフックについて理解して現状業務でのコードをリファクタしたいと思って調べてたら良い記事を発見したので、今回は記事に沿ってハンズオンで手を動かしながら理解を深めてみる。
少し横道にそれるが記事内で使われていた「CodeSandbox」というサービスすごい。今どきの環境(一瞬で React x TypeScript 環境が動いた)をサクッと準備して試せる。かなり使えそうなので今後ハンズオン系で積極的に使ってみよう。という発見もあった。
ハンズオン
それでは本題。記事に沿って実装していく。ページネーションの UI パーツを題材にしている。 本記事では上記の記事を進めていった過程での気付きや感想、少し横道に逸れて基本的な概念をほぼ自分用に書いているので、途中のコードは本記事上では割愛しているので元記事を参考にどうぞ。
最終的なコード(下記のv6)は下記。
v1
各ボタンのonClick
に直接処理を記述。
ページネーションのロジックでhistory
の配列を作って、currentPage
は配列の最後の値を参照するというロジックは自分の中では新鮮だった。history
扱う系だとメジャーなロジックなのかな?
v2
先程Page
コンポーネントのonClick
に直接書いていたロジックをカスタムフックをして抜き出した。
Page
ではfirstPage
とlastPage
のみを定義し、カスタムフックの引数にしてcurrentPage
や各ボタンのonClick
時の処理を受け取る。
この時点でPage
コンポーネントは、View関連の実装のみになって読みやすくなっている。ローカル state は呼び出し元の Page コンポーネントに所属している。
ただこのPage
コンポーネントの状態だとuseLocalHistory
を利用する前提の構成になっているから結局依存している気もする。コードの見通しはViewとロジックが分離されて良くなった印象はある。
v3
onClick
で実行する各関数を一つのオブジェクトに集約しつつインターフェースを定義。結果、明確に操作系のロジックを集約し、型チェックが行われるようになった。集約したことによりコンポーネントへの引渡しが容易にもなった。
インターフェースは TypeScript の機能。イマイチどうゆう役割なのかきちんと理解してないので軽く調べてみた。 インターフェースを使う最大のメリットは、「必須のメンバがーが含まれることやメンバーの型を保証してくれる点」と言えそう。また、関数の引数がオブジェクトの際に型を定義するときに使うのは書式的に便利。これは実際よく使っている。
v4
各onClick
での操作で共通のロジックがあるので、この部分を更にカスタムフックとして切り出す。カスタムフックは多段構成(入れ子)が可能のようでどんどん共通化できるみたい。
今回カスタムフックとして抜いたロジックは、一般的には「スタック」と呼ばれる最も基本的なデータ構造の一つらしい。流石に何となく知っているけど説明しろと言われるとおどおどするレベルのクズエンジニアなので一応復習。
スタックはLIFO(last-in-first-out)、最後に入れたものを最初に取り出すデータ構造。本を積み上げたときと同じなのでstack(積み重ねる)と呼ぶらしい。 ちなみに「データ構造」とは、データを一定の形式に格納したものを指す。
話を戻して今回はこのスタックを useStack というカスタムフックに抽出しているが何が嬉しいのか。元記事には下記記述が。
これによりuseLocalHistoryがStackの実装詳細を意識せず、画面遷移の制御だけをロジックとして持つようになりました。
useLocalHistory
は画面遷移の制御、useStack
はスタックのデータ構造ということか。
言葉で表現することすら難しさを感じるが、画面遷移の制御とスタックの操作は密結合というかどちらもあって初めて成立する印象があり分離したメリットをあまり感じられてない。多分これは自分の抽象化やプログラミング設計のスキルが低いことが要因な気がする。
もう少し強引にこじつけてみると、画面遷移では「トップページの場合は移動しない」「ラストページより先に進めない」等のページ制御ならではの特有のロジックがある。また、随所にスタックのPush
という同じロジックを使ったりしている。
この当たりがスタックとして分離する意味なのかな?あとはスタックを全く別の部分で使うときにも再利用できるとか?
今の自分にはこの位の解釈が限界。
また別の点で、useStack
の中でuseState
使ってローカルステートを定義してるが、分離したスタックのロジックを利用するだけで、ローカルstateを利用できている。今までuseState
使うときは React 特有の Hooks のsetState
を意識的に使っていたけど、普通にPop
とかPush
とか自分で定義したロジックを使えるのは良いのかな?あと使い方が明確になっていいる点は良さそうな気がする。
あとコードで結構でてくるT
は何だっけとなったので復習。T
は TypeScript の Generics(ジェネリックス)という機能の文脈で使う仮引数。下記の記事がわかりやすかった。まだ理解が追いついてないので追々調べていこう。
Genericsは抽象的な型引数を使用して、実際に利用されるまで型が確定しないクラス・関数・インターフェイスを実現する為に使用されます。
v5
useStack
は v4 でuseState
を使用しているのを v5 ではuseReducer
を利用して書き換える。
reducer は Redux 等の文脈でよく聞くが、Hooks での useReducer に関しては、役割自体は Redux のものと似ているが完全に同じではなく、Hooks ではよりカジュアルにに使える印象。
useStack 関数は、v4ではstackの前の状態を利用した手続き的なコードでしたが、v5では ACTIONS_POP のように、前の状態を知らずにイベントを発火させるだけでよくなりました。またreducerも手続き的なコードを書く必要はなく、新たな状態を返すだけで目的を達成することができるようになります。
記事にはこのようにあるがあまり腑に落ちてない。むしろ少し複雑になってる気がする。この辺も一旦時が解決すると信じて一旦今回はスルー。
v6
Container と Presentational にコンポーネントを分離。
Presentational は view にのみ責務を持ち、Container はロジックを持つようにする。
一つのファイル内に書いているし、Page
は export してないことから他で使う前提になっていないけどココまでする意味は何なんだろう。
よく理解できてない部分は多いけど、ようやくハンズオンが終了。
まとめ
そしてこの記事が本当に参考になるなあと感じたのは下記の点。ここまでで「何でここはこうなるんだろう」と感じた部分はきっと下記のような原則を学ぶことで解消される日がくるのでしょう。
コンポーネントからロジックが分離 (Presentation Domain Separation)
一般的なデータ構造をロジックから分離 委譲(delegation)
history履歴がPageコンポーネントには渡らない 情報隠蔽(カプセル化)
インターフェースの定義 開放閉鎖原則(OCP)
Pageコンポーネントの関数化 副作用を内部で取得せず引数として受け取る
各モジュールの設計意図が明確化 単一責任の原則(SRP)
PDS、委譲、カプセル化、SOLID原則(OCP, SRP)などのとおり、今まで培われてきたオブジェクト指向設計と何も変わらない普遍的な設計能力が必要とされます。 React Hooks特有の設計能力が求められるものではありません。
現状の自分のレベルだと不明確な点等が多くあるけど、いつかすんなりと理解できる日がくると信じて今回はここまで。
Week 38
2020/09/14 - 09/20 の振り返り。YWTなるフレームワークでまとめてみる。
やったこと
ルーチンを整備して出来る限り毎日実践。個人事業でWebサイト制作を進めた。知人とやっているプロジェクトの企画部分をまとめた。
わかったこと
まず上手く時間が使えていない感がある。平日も24時頃から作業を開始することが多い。在宅でフルタイムで業務をしていることもあり、業務の終わりが曖昧になっているので、ダラダラと業務を続けていることがある。またついつい夜中の作業は BGM 代わりに動画を垂れ流しながらとかも良くない。結局目を奪われてるし生産性落ちてる。
次にやりたいことが多くあることもあり、様々な作業に時間が分散している。各進捗が低くなり、結果何の結果もでない可能性も高まるので良くないことだと思う。色々チャレンジしたいことがあることやすぐさま実行してみるマインドは良いと思うので、それなりにやり方を考える必要がある。
毎日様々な情報に触れたり、気付きがあったりやってみようと思うこと、後でちゃんと調べようと思うことも多くあるが、その情報が流れていく傾向があるので、取捨選択してストックできるような仕組みを作る必要がありそう。
次にやること
- 平日でもカフェに行く時間を確保する(言語道断で家は時間を奪う要素が多い)
- 作業時は動画を BGM 代わりにしない(当たり前)
- ルーチンは「隙間時間」or「決まったタイミング」で行う(他の作業の時間を侵害しないように)
- 重要度の高い目標を、週次 / 日次 で設定して自分が重要と思う方向に進捗するようにコントロールする
- 情報(気付き・後回し・トライ)をストック・運用するフローを作成
独り言
今週は自分にとって節目の週なので、ここから気持ちを入れ替えて継続していきたい。週次の振り返りは何となく今までもやってたこともあるけど、こうやってブログにまとめてみると、頭が整理された感覚もあり体験が良いかも。