以下の記事を読んで感銘を受けた。
これまでこの記事で書いていたことは、読んだ内容をそのまま書いているだけだった...と気づいた。
書けば覚えるといったような形でそのまま書いているだけだった。
自分の考えがまるでない。これじゃ、そこらへんにあるアフィリエイト記事と同じ..いや、それ以下だ。 こんなの何の意味もなかった。
このブログを始めた目的も言語化をできるようにするためだった。 なのに、俺がやっていたことは言語化とは程遠い転写だ。
読んだ本にせよ、学んだ技術にせよ、 そこから色んなコンテキストを組み合わせることで、このブログが面白いものになる。 こんなことに、この記事を読むまで気づかなかった。恥ずかしい。
経験をアウトプットできるのは自分だけ
俺は、俺が思ったこと、作ったものをアウトプットすることに意味がある。 時間をかけ、たくさん経験して、自分だけのブログにするのだ。
それがみんなの役に立ったら万々歳というスタンスでいく。 ここからが始まりだ。
本の基本情報について紹介する。
7人の億万長者、239人の起業家、13人のオリンピック選手、29人のオールAの学生にインタビューして成功者共通の「生産性向上の習慣」を書いた書籍だ。
読んでから３ヶ月継続して実践しているが、時間の使い方が上手くなっていると目に見えて感じる。
成功者の時間術ですが難しいことではなく、普通の一般人である自分でも読んですぐ実行できた。 当たり前のことだと感じものも多くあるが、できていないのでハッとさせられることがある。
読者が自分にとってのベストプラクティスを選ぶような形で実践するのが良いと思う。
以下は本書の目次です。
上の中でも自分が実践しているものを抜粋する。
この本ではMIT(Most Important Task)を見極めることの大切さを書いている。
研究によると「日々のMITを明確にすることは、生産だけでなく幸福感および気力の向上にもつながる」
目標はどんな分野でもいいが、具体的に、評価できるようにようにせよ。 もしMITに取り組まない週があったとしたら、その一週間は無駄だったということになる。
これは結構衝撃的だった。
ToDoリスト = 消えることのないウィッシュリスト
どういうことかというと、ToDoリストにはいつになったら全部終わるのかという具体的な計画がないので、ずっと無くなることがないことが起こる。
他にも以下のようなデメリットがある。
では、どうするのか？
スケジュールに基づいて動くのだ！！
本当にやり遂げたいことがあるなら、きちんと予定を立てなくてはならない。
アート・オブ・チャーム共同創業者によれば、スケジュールは15分単位で1日の予定を組むのが効率が良いらしい。 電話やメール、運動もこの方法で管理する。 自分もこの本を読んでからiPhoneのカレンダー(Googleカレンダーも同期させている)を使って管理している。
- 重要なことは全て、やる時間を決め、スケジュール表に入れておく
- 重要な項目には1日のうちできるだけ早い時間帯を割り当てる
- 目標は取り下げない
- 「タイムブロッキング」した予定は、診察の予約だと思って対処する
常にノートを持ち歩き、何でも書き留める。アイデア、新しい人に出会ったらその人の情報、得た知識、面白いこと、とにかく何でも書き留めるのだ。 書き留めなければ忘れる。
また筆者は以下のような記号を使ってわかりやすく管理している
人は何度も同じことを繰り返す。数分でできることは後でやろうと考えずに今やるのだ。
メールなどの事務作業、掃除もそうだ。これは後でやろうとかが多いので出来ることはすぐやるべきだ。
1日のうち同じ1時間でもその時の精神状態によって生産性は大いに変わる。
そのニーズに自分の能力をうまく適合させるために！
また、集中するためには休憩も大切だ。
自分はポモドーロテクニック(25分集中してやって５分休憩を繰り返す)を実践している。 長時間だらだらやるより、短時間集中するのを小出しにする方が生産性が上がるのだ。
自分のエネルギーを最大化させることの大事さをこの章では言っている。
上記のような当たり前だけ出来ていないことなど様々なポイントを実例を交えながら書いている。
目次17以降は成功者の一日(1440分)の使い方や習慣について書かれている。
1~16同様に自分に合いそうなものを選択してやってみるのが良いのだろう。
是非読んでみて実践してほしい。
こんにちは管理人のue_shoです。下記、「プライバシーポリシー」に関して記載致しましたので、ご一読願います。
当サイトでは、第三者配信の広告サービス (A8.net 、Amazonアソシエイト) を利用しています。
このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 『Cookie』(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。
当サイトでは、スパム・荒らしへの対応として、コメントの際に使用されたIPアドレスを記録しています。
これはブログの標準機能としてサポートされている機能で、スパム・荒らしへの対応以外にこのIPアドレスを使用することはありません。
また、メールアドレスとURLの入力に関しては、任意となっております。 全てのコメントは管理人であるredoが事前にその内容を確認し、承認した上での掲載となりますことをあらかじめご了承下さい。
加えて、次の各号に掲げる内容を含むコメントは管理人の裁量によって承認せず、削除する事があります。
当サイトで掲載している画像の著作権・肖像権等は各権利所有者に帰属致します。権利を侵害する目的ではございません。記事の内容や掲載画像等に問題がございましたら、各権利所有者様本人が直接メールでご連絡下さい。確認後、対応させて頂きます。
当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。
当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。
当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。
当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。
運営者：ue_sho
最近「アウトルック活用術セミナー」というものを受けてみた。
というのも自分の会社は日常的にOutlookを使用しており、もしこのまま会社にいるとすれば今学んだことは一生使える物なのでは..? と思ったからである。
結果的に受けたのは大正解であった。
何よりもOutlook以外にもショートカットを活用していこうモチベーションが上がったのが良かった。
概要を簡単に押さえておく。
結論をいうと、「ショートカットを駆使しろ！」ということである。
平均的な会社員は 業務時間の約35% をメール業務に費やしているらしい。 一年に換算すると 500時間 使っているらしい。
これを聞いたとき目を疑った。自分は長くても1日1時間程度である。(自分からメールを出す機会があまり無いので..)
周りの社会人はそんなにメール業務をして無駄すぎるだろと感じた。
その無駄をショートカットを駆使すること可能な限り削減できるという内容だった。 自分のやっていた方法とは違い、かなり参考になったので皆さんにも「アウトルック活用術セミナー」オススメする。
主催者の書籍「アウトルック最速仕事術 年間100時間の時短を実現した32のテクニック」も有用だろう （自分は買ってないので分からないが、講座と同じ内容だと思われる）
さて、本題に戻そう。
上の講座ではたった10個のコマンドを覚えるだけで、かなりの時間を節約できた。 会社でも家でも使えてすでに講座で教わった2時間以上の節約ができている実感がある。
自分はソフトウェアエンジニアだ。 一日中パソコンを触るので、ショートカットを覚えるだけで多くの時間が節約できる。
Google Chromeであったり、VSCodeと呼ばれるプログラミングのエディタであったり、PowerPoint, Excel... 自分の業務で使うものは積極的にショートカットを覚えるべきだ。
自分の業務で使うものであれば、日常的に使うのでコマンドも覚えやすいだろう。
アプリケーションだけでなく、Windows, MacといったOSにもショートカットがあるので、そちらも余力があるなら覚えた方がいいだろう。
ショートカットによる時間節約を甘くみてはいけない
「これからの人生の中で、今が一番若い」
今覚えればこれからの人生に習得にかかった時間以上の時間が生まれる。
本の基本情報について紹介する。
著者である細谷功さんの本「具体と抽象」を読んだことがあったので、別の本を手に取ってみた。それがこの本だ。
「前例主義」「マニュアル人間」「ダラダラした会議」…仕事にはびこる思考停止のワナを「Why型思考」と「What型思考」を元に解説している本だ。
この本はこのWhy型思考の身に付け方およびビジネスでの活用法を説く。 自分は完全に「What型」思考で思い当たる節が多く、何も考えられていなかったんだなと痛感した。
Why型思考を身につけたいと思うなら是非読んでみて欲しい。
以下は本書の目次です。
適当に自分が感じた部分のみピックアップしていく。
What型思考は、今ある規則やルールは律儀にそれを遵守することを常に優先で考える つまり、「マニュアル人間」である。
いやーーーこれは自分です。でも、悪いことだとは全然思ってません。 むしろ良いことだと思います。
ただ、なぜそれをやるのか考える必要があるということですね。 これはわかったつもりになってやってないことが多い。
他にも、色々なWhyなきWhat病の例が出てきます。 例えば、 * 聞かれた質問に対して、「何々に書いていました」と回答する * 前例に固執してしまうこと。実績はあるのか？やそれ前にやったことあるのか？など * 成功体験をそのまま使おうとする。なぜ成功したのかは考えない。 * 顧客を忘れて技術力に走ってしまう「作り手視点」のみの商品 * メッセージなきドキュメント
かなり自分に当てはまっており耳が痛い。自分はWhat思考で固まってしまったことに気づいた。
単なる「コピー&ペースト」だけして「そのまま使って」いたのでは、そのこと自体に価値がないことに加えて、とんでもない誤解をしたり情報の誤用をしたりすることになるかもしれない。
今までの定型業務でも「なぜこれをやるのか？」を追求していくなど、本来の目的にしたがってそれを加工していく思考力が大事だ。 (大企業はWhat型が蔓延しているので、こういったことは煙たがられるので周りの人との関係も注意する必要がある）
「今あるもの」や「目に見えるもの」から発想するのではなく、そもそもどういう理由で何をやらねければならないのかという、目に見えない将来を見越した本質の議論が求められている。
目に見えないもの(正解はないもの)を考えることがWhy型思考
「なぜ？」を問うことで表面だけ見えているものの裏の世界を見ることができる。 しかし、一回だけの「なぜ？」はWhat型思考と同じである。深く掘ることで裏の世界が見えるようになる。
自分は「なぜ？」をしたときは一度で止まっていたので、本質をみれていなかった。 本質を見極めるためにも、習慣として「なぜ？」を考えるようにすることが大切だと感じた。
Whyと Whatを切り分けることでどのような考えになるかを具体例を元に書いてある。
Whatの部分が一人歩きして、それを守ることが目的になっている
上記のように「一人歩き」の話の中であった食事マナーの例から、ルールだからやっているというものは数多くあり印象に残った。
これはWhatだな、これはWhayだなと切り分けができるようになると物事を考えるときに役立ちそうだ。
Ｗｈｙという「ものの考え方」や「実際に起きていることの原因や背景」に目を向けている上司とＷｈａｔという実際に現場で起こっている事象そのものに目を向けている部下とでは会話がかみ合わなくなるのは当然のことでしょう。
上司がWhy型思考で、部下がWhat型思考だとギャップが生まれる。逆も然り。(かなりの場面で起こっている)
上司から、クライアントから頼まれたら、なぜそれが必要なのか一歩進んで考える、確認する、聞くことで成果物の品質や部下のせいちょうスピードが変わっていくだろう。
What型 - 「育てられる」（他動詞） Why型 - 「育つ」（自動詞）
What型教育。つまり、学校教育のような教えてもらうことは、時間に比例して成長していく。 しかし、爆発的に型破りな成長をする可能性も少なくなる。
Why型教育とは、師弟関係のように教えずに見て学べ！のようなもの。 教えてもらえず雑用が多いので「自ら技を盗む」ことを考えるので、爆発成長をすることがある。 （うまくいかない場合ももちろんあり）
「Ｗｈａｔ型教育は一方向でもよいが、Ｗｈｙ型教育は双方向でなければならない」ということもあるでしょう。Ｗｈａｔ型教育では最悪教える側が一方的にしゃべりまくれば一定の目的は達せられたことになりますから、そこでたとえ質問がなくても問題はないわけですが、Ｗｈｙ型教育というのは双方向ですから、質問がないという状態が放置されることはないはずです。Ｗｈｙ型／Ｗｈａｔ型の観点から見ると、これら二つの要因が日本人が質問下手になっていることに大きな影響を及ぼしていると結論づけられるでしょう
自分も会議では全然会話に参加できず、時間を無作為に過ごしていることが多い。なぜを問うような質問をすることで自分の理解を深めたい。（無闇矢鱈になぜ？と問うのも問題な気がするが...適度にしていく）
Ｗｈｙ型の勉強は純粋に自発的なものでなければならないというのが肝に銘じておくべき特徴です。「いやいや勉強する」というのはＷｈａｔ型にはあってもＷｈｙ型にはありえないのです。
反復練習をして同じような問題を何問も解いてパターンを暗記することにあまり意味はありません（それはＷｈａｔ型のトレーニングになってしまうからです）。多数の問題を解くとすれば、それはなるべく違う解き方で解くような「バリエーション」を追求することが重要です。
問題を解きまくってパターンを暗記する、身に覚えがありすぎる... 自分は競技プログラミングをしていたのですが、いつもパターンだけ覚えて実際にどういったアルゴリズムなのか、なぜこのアルゴリズムを使うと良いのか考えられていなかったなーと痛感している。 実際に結果にも現れていて、あまり伸び代がなかったように思う。(AtCoder 緑)
ただし、反復練習をして体に染み込ませることも大事なので、そこら辺も自分で考える必要がある。
読書にしたって小手先のテクニックを覚えるより、まずはじっくりと考えてその理由や背景などに思いを巡らすとともに、自分の思考力を鍛えて読書後も含め新しい発想を生み出すのがWhy型の読書法。
したがって、必ずしも量とスピードは重視せず、途中で立ち止まって考えたり、何度も読み返すこともあるでしょう。この場合に適した本はいわゆる「古典」と呼ばれるような、読み継がれてきた名作が一般的には適当。
プログラミングにしたって何故この技術が流行っているのか？となぜ？を問い続けていくことが自分のスキルにつながる。
「Ｗｈｙ型の人にはＷｈａｔ型とＷｈｙ型の区別がつくが、Ｗｈａｔ型の人にはその区別がつかない」ということです。つまり、あなたが周りの人やその考え方を見て、「隣の課の新入社員の発言や仕事のやり方はいつもＷｈａｔ型だ」とか「今度来た○○課長はいつもＷｈｙ型のコメントを返してくる」といったことの「区別」がつくようになれば、それはあなた自身の思考回路がＷｈｙ型になってきたことを意味しています。逆の言い方をするとこれがわからないうちは自分自身の思考回路がＷｈａｔ型である可能性が非常に強いと考えてください。
まだまだ判断がついていないので、意識して観察し良い点は取り入れられるようにする。
Ｗｈｙ型思考になるために意外に重要な事項として普段から心がけておくべきこととして「答えがない状態に耐える」、あるいは「慣れる」ということが挙げられるかと思います。
自分は学生時代から答えがないものが嫌いだったので、国語みたいな教科が苦手でした。考えを改めていき、答えがない状態を楽しめるようになっていきたい。
他の章ではWhy型思考の「使用上の注意」を書いてあり、必ずしもWhy型思考が正しいわけではないことも知っておかなけらばならない。
ただ、必ずWhy型思考は自分を成長させる。私はWhy型思考を持って生きていきたい。
最近のWeb開発ではフロントエンドの技術が必須です。とはいえ、HTMLに追加される新しい要素や属性、増えていくCSSプロパティやルール、年々アップデートされるJavaScriptなど、複雑かつ膨大な情報を整理するだけでも大変です。本書は、初級者向けにフロントエンド開発支援ツールの選び方や使いこなし方、効率的に開発をするための基礎知識が身につく入門書です。複数の支援ツールから「なぜそれを使うのか」選択する基準がわかります。
以下は本書の目次です。
まずは自分のレベルを教える。
仕事がC言語ということもあり(言い訳)、Web開発のフローや使っている技術は聞いたことあるけど全然わかってないで使っている状況だ
以下のような単語が出てくる
自分の最初の知識と用語の簡単な説明だけ書いておく
単語見て分からないなら購入してみることをお勧めします
Javascriptの仕様を定めている
Ecma Internationalという団体によって標準化されている仕様
以前の認識: 聞いたことない
非同期型のイベント駆動モデルを採用したサーバーサイド向けのJavaScript
libuvという非同期I/OをサポートするC言語のライブラリなどから構成されており、バイナリ化されて配信されている
以前の認識: JavaScriptのサーバーサイド版ってイメージ
Node.jsに付随するJavaScript用のパッケージマネージャー
似たパッケージマネージャーである Yarn は Facebook が開発した
以前の認識: 名前の通りパッケージ管理しているのかな
新しいJavaScriptの構文を環境に合わせてダウンコンパイルしてくれる
以前の認識: コードで使っていることは知っていたが、何をしているかは知らない
ファイル間のモジュール解決を行い、１ファイルに連結させる機能を提供するモジュールハンドラー
別ファイルの関数などをブラウザが紐付けてくれるとは限らないので必要となる
以前の認識: 知らない
自分はVue.jsをやっていたので、VuexがFluxライクで作られていることで腑に落ちた
以前の認識: 聞いたこともなかった
SassやBEM形式についてはすでに学んでいたため、復習になった
コードスタイルのフォーマット
以前の認識: VSCodeで使っていた
ルールを設定することで、ルールから違反したコードを検知することができる
ルールは100以上あり、バグの芽を摘み取ることができる
以前の認識: 名前しか分からない
Mocha, Jest, Karma についてそれぞれ説明があった
以前の認識: Jestでテストを書いていたが、結局テストを書かなくなっている状況
ここからが本題だ
まずサンプルコードがどこにあるか分からず焦った... 同じような人もいると思うので、リンクを貼っておく
フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装｜サポート｜秀和システム
Reactに移行する流れを順を追って説明してくれているので、躓かずに進めることができた しかし、この本だけではReactは理解できないのでそこだけは注意が必要
JSXやFlux/Reduxについても説明があり概要は理解したが、実際に使えるようになったかと言われると微妙だ （ここは実践編にないためコード上で理解できていない） なので、Reactを使うときにこの書籍を持って一緒に進めるのが良いのだろう。
ESLint, Prettier, Babelなど単語しか知らなかったが、使えるようになった ここが一番実務や個人開発で反映しやすそう、自分もここを個人開発ですぐに設定した。
珍しく(?)技術だけでなく、パフォーマンスについても詳しくかいてあり自分のようなWeb開発初心者には大変助かった。
上で書いたのは本の一部だけである。他にも解析の方法やチーム開発のことであったり色んなことが書かれている。
この書籍はWebを触ったことない人には難しいので、対象者は少し開発をした人だろうと思う。
フロントエンジニアだけでなく、フロントエンド技術に少し興味がある人、お金をケチって買おうか悩んでいる人は買うのをオススメする。
この書籍に限らず技術書はどんどん買おう！！！！！！！
本の基本情報について紹介する。
この本はコンサルだけではなく全業種に通ずる普遍的でかつ重要な考え方が書いてある本だった。 考え方なので忘れることなければ一生使うことのできる役立つ考え方だ。
フレームワークなどの技術ではなく、クライアントに価値を提供するための「期待値を超え続ける」などの思想に近いことが多く書かれていた。
以下は本書の目次です。
30個のスキルが記載されているが、その中でも自分に生かせる物だけをピックアップする。
PREPという型を使ってみると良い
簡単そうに見えて意外と難しい。普段話す時、質問に答える時、頭を整理する時など繰り返し数をこなして質を高めていく。
加えて論理（ロジック）と数字を使って話すと具体的で相手もわかりやすい 新人は話に筋が通っていなければ、話自体を聞いてもらえない。
期待値を超え続けるには、まず期待値を把握しなければならない。 相手が何を期待しているのかを正確に把握する。
上司からの指示内容を明確に把握する（質問によって推し量る コミュニケーションが必要） - その仕事の背景や目的 - 具体的な仕事の成果イメージ - クオリティ - 最優先順位、緊急度
求められていないことに時間を使っても、クライアントからも上司からも評価はされない。 求められている中身がわかったら、そのレベルにおいて何がなんでも相手の期待値以上の成果を出す。 おまけを付けて取り繕っても重要な部分で足りていなければ失敗。
自分のリソースをはるかに超えるものに対しては、相手の期待値を下げる、期待値のマネジメントも必要な場面もある
「アプローチ」「考え方」「段取り」の部分を最初に考える。 つまり仮説思考。最初に欲しいアウトプットを考える。 そうすることで効率的にリサーチできる。つまり最速で成果を出せる。
⇨ロジックツリーも上手く使うのも手 (イシューから始めよを読もう)
はどの本でも大体書かれている。
情報を集めて満足する人が多い。自分もその一人。 『すごいなぁ、なるほどな』で終わってしまっている。
情報量を増やしたからと言ってスキルが上がるわけではない。 考えること、手を動かすことをしなければ何も意味ない。
情報に接するときには、必ず自分の意見を持って接する (開く前にタイトルをみて何故だろうと自分なりの考えを出すなどする)
間違っていても全然良い。正解にこだわらず考え続けることが大事。
情報を集めただけでは考えたことにはならない。 その先にある「本質」を提示することができて初めて価値は生まれる。
ズレているかもしれないが、自分の友達も以下のようなことを言っていた。情報の中に隠されていることを読み取れるの大事だ。
結果を見て結果を理解しようとするんじゃなくて、結果を見てそこに至るまでの過程(制約、ifパターン、判断軸)を感じるんや。ほんで、その人がその判断軸を作り得た源流の知識と経験を自分も取りにいく(聞けるなら本人に聞く)。と自分のケースでの特化解が作れる。特化解を汎化させるから再構築できる。
詳しくは書かないが、これは自分にできていないこと。 そして、多くの人ができていないと感じる部分だ。 自分は仕事中に毎週進捗報告会が存在するので、そこで実践しくつもりだ。
重点思考 ＝ 余計なことをやらない
20対80の法則をご存知ですか？ 例えば「売り上げの80%は20%の顧客がもたらしている」など全体の80％は20%のことで占めているというものだ。 多くの物事に当てはめることができる（もちろん例外もたくさんある）
この重要な20%にフォーカスしてディープに掘り下げる。それ以外のことは切り捨てる。 切り捨てることも大事なのだ。
自分がやりたいことではなく、相手が求めていることをやる。
自分のやりたいことをやるのも、とても大事だと思う。 しかし、結果を出すことが目的なら、自分のやりたいことをやるべきではない。
クライアントが「価値がある」と思わなければ、あなたがどれだけ頑張ってもそれは単なる自己満足。
これは自分にとってはかなり痛いことを言われた気分だ。 先ほど進捗報告会を行っていると言った。ここで自分は発言を全くしていない。 自分の番になったら話すだけなのだ。
正直、進捗報告会で発言を強制する必要はないが、他の会議では「会議で発言しない人の価値はゼロ」これを心に刻んでいきたい。
テレビでやっている22人23脚のようなみんなが同じことをすることはチームワークではない。 それぞれの担当分野で全員が価値を生み出すこと(分業)がチームワークである。 簡単なことで良い。今の自分の能力でチームに貢献できる分野を考える
自分的にはかなり面白い本でしたし、読んですぐ会社で実践できそうなので良かったです。
アウトプットするまでが読書なので、習慣化できるところはしていきたいます。
皆さんも買ってみてはいかがだろう。
