ニックネーム募集中

考えたこととかいろいろ。

久しぶりにブログを書こうと思って音声入力でやってみたらメチャクチャラクだった話

特にオチも何もなく、ただだらだらと思ったことを書いてるだけです。笑

 

タイピングでブログを書こうとすると結構打ち直すのがめんどくさいので

構成を先に考えようとしてそれで手が進まなくなるっていうことが結構ありました。

音声だととりあえずしゃべって後で構成とか内容の手直しをすればいいやっていう

軽い気持ちで書き進めていくことができるので、書きなれてない人には特におすすめ。

音声入力で6割から8割ぐらい文章ぱーって書いちゃって

聞き取れてないところとか話し足りないところっていうのをその後に書き足す。

そんな軽い気持ちで始めたら、書き終わるまでのスピードが段違いで早かった。

 

Macの設定を変更してショートカットで音声入力をオンにできるようにすれば

書こうと思ってからすぐに音声入力ができるのでオススメです。

(windowsも同じようにあると思います)

 

support.apple.com

 

単純にタイピングが声に置き換わるということではないので、タイピングが速い人でも使い道があるなぁというのに思いました
後は話し言葉っぽいラフな文章も音声のほうが、実際に話してるので書きやすいです。

ただ、普通に話すペースで話すと結構な確率で入力ミスが起きるので

少しゆっくりめにマイクの近くで話すと、とても正確に入力をしてくれます。

あとはいい間違えたりしたときにそれも全部入力されてしまうのでそこが少しめんどくさいです。

文系からエンジニアになろうと思ったら最低限コードを書くとという経験をしてから面接を受けると良いと思う

はじめに

仕事でエンジニアとして働きつつ、面接などの採用業務にも関わり始めました。

今回書くことは個人的に面接を通じて感じた意見なので、

会社としてこのように考えているとかそんなことはないです。

自分も文系出身でエンジニアになったのですが、意外と周りにエンジニアの人がいないので、

ブログを通じて意見を共有できたら良いかなと思って書きました。

 

みんな共通してエンジニアになりたい理由は話してくれる

エンジニアにかかわらず、今までやったことないことをやろうとしてたら

だいたいなんでそれ始めるのー?ぐらいにはどこ行っても聞かれると思うので、

まずみんなこの話はちゃんとしてくれます。

正直理由はこういう理由なら採用でとか線引きはないのですが、

未経験で採用をした場合にどの程度頑張れるのか?ということを

採用する立場としては知りたいのです。そのための1つがこの質問という印象ですね。

 

エンジニアになりたい理由に対して今は何をやっているのか?

理由と合わせて「じゃあ今は何をやってるんですか?」

みたいなニュアンスのことは必ず聞いています。

個人的にはエンジニアになりたい理由はみんなちゃんと話してくれるので、

それよりもこちらを重視しています。

 

これに対して何もやってない人もいれば、少しだけやってる人とかいろんな人がいます。 

いくらエンジニアになりたい理由がはっきりとしていても、

それに対して行動がついてきていないと、面接をする立場としては、

「そこまでちゃんとした理由があるのに行動してないのか」

という印象になってしまい、理由に対する印象も変わってしまいます。

 

エンジニアとして伸び代があるということを相手に納得してもらうためにも、

こういう理由でエンジニアになりたいという思考の部分と、

そのために今はこれをやっていますという行動の2つの軸でアプローチができると、

聞く立場としてはとても納得感が出てきます。

あとはその思考と行動がどこまで良いものかというレベル感の見極めになってきます。

 

会社によっては今は行動してなくてもOKみたいなところもあると思いますが、

「どのように考えその行動をしたのか」という思考と行動の組み合わせは

仕事においても重要になってくるため、面接の段階から意識して話を聞いています。

 

さいごに

今はドットインストールとかプロゲートとか無料でも勉強できるものが揃っています。

最近このProgateがiOS版も出してました。

iPhoneの人は移動時間にもできるので、なおさらハードルが低いと思います。

 

dhate.hatenablog.com

 

検索すれば他にもたくさん出てくるものなので、

知りませんでしたで終わってしまうのはもったいないです。

決して難しいことをやらなければいけないという事はありませんが、

最低限エンジニアになるために今行動をしている状態にしておいて

・自分の意見を客観的に見たときに納得してもらえるようにする

・実際に自分でプログラミングをやってみてどう感じたのかを人に話せる

 

そんな状態で面接の場では話ができたら良いなと思っています。

【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略に参加してきました

Matzさんの若手エンジニア向けのお話を聞いてきました。

Matzさんはプログラミング言語rubyを作成したことで有名な方です。

 

聞いた内容をそのまま書くと長くなるので、聞いてみて重要だなと思ったポイントに

絞って自分なりの考えを踏まえてまとめていきたいと思います。

 

大前提

最初の方に大前提として、

死ななければ良いし人によって違うという話をされていました。

まあそりゃそうだよなと思いつつ、じゃあどうすれば良いのかということで、

パターン認識についての話をしていたのがなんだかんだ印象に残っています。

 

このパターン認識とはメタ戦略のことで、

1段抽象化させて物事を捉えることのようです。

アメリカのスタートアップで成功した人の多くは、

このパターン認識に特化しているという調査もあるそうです。

1段抽象化させて物事を捉えるというのは、

人によって違うというところにも関わってきますね。

 

例えばMatzさんがブログをおすすめしていたとして、じゃあ自分もブログを書こう!

とするのではなく、ブログを書くという行為を抽象化させて捉えることが重要。

つまり情報を発信するとかアウトプットするとか、そういったことが重要なんだなと

捉えられるかがこのパターン認識の話なんだろうと思って聞いていました。

 

Matzさんのアドバイス

ここに記載されている以外のアドバイスも結構ありましたが、

個人的に印象に残っているものを書きます。

先に思ったことを書いてしまうと、Matzさんのアドバイス

「人間の心理を知ること」に集約される気がします。

これを理解していれば、「やったほうが良い」or「やりたいこと」に

時間を使うことができるのではないかと思いました。

 

ちなみに「人間の心理を知ること」もMatzさんのアドバイスの1つです。


1. 自分を知る

これは自分が持っているスキルセットや強み、できないこととか興味があることなど。
自分の武器になりそうなことがあればそれを伸ばせば良いとのことでした。

一見ありきたりに聞こえるアドバイスではありますが、Matzさん自身が

プログラミング言語を作りたいという他の人には少ない欲求を追求したからこそ

今の立場にいるというお話を聞いてなるほどと。


単に強みを伸ばしましょうとかそういうんじゃないんすねと。

強み弱みは考える機会があったのですが、これからはニッチすぎる分野でも良いので

どんなところに強烈に興味をもてるのか考える必要がありそうです。

 

Q&Aで

「1万人いるうちの100番目に入るのと100人いるうちの1番になるのではどちらが良いか」

というものがあったのですが、やはり100人いるうちの1番との回答でした。

 

2. インプットとアウトプット

たくさんのインプットをするのも大事だけど、

それだけでは差別化要因にならないですよねって話です。

つまり他と差別化を取りたければアウトプットが必要ですと。

 

じゃあなんでアウトプットができないのか?というと心理的障壁が関わってくるそうです。
恥ずかしい、チャンスがない、、、
クオリティはとりあえず棚上げでまずはやってみる精神が大事。
人間の可塑性にかける、つまり人間は立場によって変わることはできるのだという言葉が印象的。

 

この話を聞いてこの記事を書いた次第です。

実はこんなところにも小さな差が生まれるのではないかと思いもくもくと書いてます。笑

 

3. 思い込みに自覚的になる

思い込みとはキャッシュのようなもの。

全てのことに理由を考えるとすごく時間がかかるから考えなくなる。

 

この思い込みって奴のせいでバグが起きるらしいです。
バグの95%は思い込みから生まれるとのことでした。

 

だからこの思い込みを取り除く必要があるそうです。

先ほどのアウトプットを躊躇するのもほとんどが思い込みだと思います。

自分含めてなんですが、恥ずかしい以前に人に見てもらえんの?ってレベルの人も多いはず。

実際に自分は変な記事とかコメント見てもスルーするのと同じように

レベルの低いものを出しても大丈夫なんですよね。

 

最後に

他にも「理不尽を拒否しよう」とか

大多数の人のためになりそうなアドバイスもあったのですが

聞いていて自分は問題ないなと思ったのでこちらでは省略しました。笑

結構内容省いたので、参加した人からすると大事なところ抜けてんじゃんとか

あるかもしれないですが、参加したレポートではないので悪しからず。

 

勝手にMatzさんのアドバイス「人間の心理を知ること」と書きましたが、

理不尽を拒否できない、アウトプットに躊躇する、思い込みがあるといったことを

抽象化させる(パターン認識する)と、

人間の心理を理解しておくことが重要なのではないかと結論づけました。

 

 他の人が書いた記事まともだな。。まあこれはレポートではないのでこんな感じで。笑

スタートアップウィークエンドに参加して学んだこと

こんにちは!

以前スタートアップウィークエンドに参加してきました。

何回も参加している人もいれば、初参加の人も多くとても勉強になりました。

スタートアップウィークエンドについてあまり知らないよって人は下記をご覧ください。

 

nposw.org

“スタートアップウィークエンド(SW)”は、金曜夜から日曜夜まで54時間かけて開催される、「スタートアップ体験イベント」です。週末だけで参加者は、アイディアをカタチにするための方法論を学び、スタートアップをリアルに経験することができます。
わたしたちは、スタートアップが最初の一歩を踏み出すためのプラットフォームを目指しており、開発者やビジネスマネージャー、アントレプレナー、デザイナー、マーケター等、さまざまなスキルの人々を結びつけ、アイディアが現実になることを願ってます。

 

学びだけではなく、参加者同士のつながりもあり、

参加しようか迷っている人はぜひ参加して欲しいなと思っています。

そのため今回は実際に参加をしてみて、

どんなことが学べたのかまとめていきたいと思います。

 

1. アイデアよりも実行したかどうかに価値がある

スタートアップウィークエンドの良いところとしては、

イデアを出すだけで終わらないところです。

自分一人だと、こんなアイデアがあったらいいなって思っても、

それが実際にニーズがあるのかを検証したり

プロダクトを作ってみたりすることがあまりないと思います。

 

参加するまではアイデアを思いつくと、

いつでもやろうと思えばできそうだなという錯覚に陥っていました。

 

ただ、実際にスタートアップウィークエンドに参加をしてみて、

最初にいけると思ったアイデアがとことん壁にぶちあたる姿を見て

行動してみないとわからないということは痛感しました。

さらに自分たちもそうですし、他のチームもそうだったのですが、

競合の調査をすると想像以上に競合が多いこともわかります。

 

また、コーチングをしてもらう中でよく耳にしたのが、

そもそも競合がいないということはニーズがないのではないかということでした。

競合がないようなアイデアを思いついたとしても、

単純にニーズがないだけかもしれません。

 

結局アイデアだけ持っていても形にできなければ意味がありませんので、

やればできそうだなと考えているぐらいなら、早く本当にニーズがあるのか

検証をするための行動を起こすべきだと考えるようになりました。

2. 実際に人に会って聞いてみないとわからない

先ほどの実行のところに関係があるのですが、一番重要だと思ったのが

お互いディスカッションをすることでもなく、フレームワークに当てはめることでもなく、

ターゲットとなる人に直接話を聞くということでした。

 

電話で話を聞いたり、お店に突撃したりチームメンバーの知り合いに

直接会いに行ったりを分担して行いました。 

 

わかりやすい話、ディスカッションをして完璧だと思っても、

実際のユーザーとなる人が必要ないと言ってしまえば、

それはおそらくそのままの形ではうまくいきません。

もちろん必要だと言ったからといってうまくいくとも限りません。

 

実際にスタートアップウィークエンドで何人もの人にで話を聞いたのですが、

自分たちだけで話していただけではわからないような課題は多く発見できました。

 

どうしても部屋にこもって議論をしてしまいがちですが、

うまくいっていると思えるときこそユーザーに話を聞く。

うまくいかない時にこそユーザーに話を聞く。

 

そうして進めていかないと、自己満足のプロダクトや

無意味なディスカッションしか生まれないと感じました。

 

私たちの場合はもうダメだと思った時にユーザーに話を聞けたことによって、

新しい方向性を見つけることができました。

 

3. 原体験に基づいた課題解決の重要性

儲かりそうだからやるのか、自分や周りの人が実際に困っているからやるのか。

この違いはかなり大きいなと思いました。

 

スタートアップウィークエンドあるあるらしいのですが、

2日目のコーチングの時間にボロクソにされ、

2日目の最後に一番落ち込むタイミングが来るそうです。

 

コーチングとは、コーチとして参加してくださっている人達に

自分たちのアイデアを話して、アドバイスをもらう時間のことです。

もちろん優秀な方々がきているため、私たちが1日ぐらいで考えた内容では、

もうやめてくれと言わんばかりに指摘されます。笑

 

私たちのチームも例外なく、コーチングの後にこのままではダメだと思い、

1から考え直した方が良いのではないかと思うタイミングがありました。

 

その時におそらくお金を稼ぐために事業をやろうと考えていたら

そこでやめてしまっていたと思います。

 

ただ、私たちのチームは自分たちの原体験に基づく課題や、

その思いに共感している人が集まっていました。

初日にみんなで飲みに行って打ち解けあえたのも大きかったかもしれません。

 

そのためすぐに方向転換をすることなくできることはすべてやってみよう!

という方針で踏ん張れたので、最終的にはうまくいったのではないかと思います。

プレゼンの結果が良かったわけではありませんが。笑

 

その後VCの人に聞いた話によると、やはり金儲けをしようと思って成功している人は

強烈なバイタリティを持っているような特殊な人が多いそうです。

 

事業自体は常にうまくいく状態ではもちろんないので、

強烈なバイタリティを持っていないような人が金儲けをしようとしてやっても、

事業がうまくいかない時にやめてしまったりすることが多いとのことでした。

ただ、自分の原体験に基づいている人が起業をすると、

うまくいかない時にでも耐えられるため、うまくいくケースが多いそうです。

 

まさにこの話の通り、起業家が通るであろう道の一部を

週末に体験できたのではないかと思いました。

さいごに

初めての参加でしたが多くのことを学ぶことができました。

また、その学びも本を読んだような知識だけのことではなく、

実際の行動とセットの学びでした。

 

学べること自体は本にも書いてある内容で、

決して特殊なことが学べるわけではありません。

ただ、行動とセットになった、自分の実体験に基づいた学びを

週末に得られるということはとても良い体験です。

 

参加者や運営者とも仲良くなれますし、思いとどまっている人は

ぜひ参加をしてみて欲しいイベントの1つです。 

NewsPicksって意識高い系の集まりだと思われてるけど、使い方を気をつければかなり良いツールだと思う

こんにちは〜

ニュースアプリとかって何使ってますかね?最近NewsPicksにはまっているのですが。

でもこのNewsPicksって意識高い系の集まりだとか批判されることも多いんですよね。

 

「NewsPicks 意識高い」とかでググると面白そうなタイトルが出てきます。

もちろんもともといる意識高い人が嫌いなユーザーも多いとは思いますし、

使い方によっては意識高い系を生み出してしまうサイトではあると思います。

 

使っていて良いところもここ気をつけないと意識高い系になってしまう

ポイントもわかってきたので、紹介したいと思います。

NewsPicksとは

 調べてみると経済情報に特化したニュース共有サービスだそうです。

略してNPとか描かれることが多いです。

経済情報以外にもスポーツとか教育とかの記事も多いので、

経済情報に特化しているということは忘れてしまう…。

 

newspicks.com


特徴としてはニュースに対してコメントができて、お互いのコメントが読めることです。

大学の教授や弁護士、有名どころだとホリエモンなんかが記事に対して

コメントをしているので、ただニュースをみるよりも面白くなっています。

 

私はグノシーとかでニュースをみるよりも、NPでコメントも含めてみるのが好きなのですが、

ネットでは意識高い2chとか書かれたりしてますね。笑

個人的には使い方を気をつければとても良いアプリだと思うので、

意識高い系もただの2ch好きにも使って見てほしいです。

  

何が良いのかって話

基本的には先ほどの「コメント」が他のアプリとの違うところだと思っています。

あとは有料アカウントにすると、オリジナルの記事が読めたりするところでしょうか。

 

コメントができるのはわかったと思われそうなので、

そもそもなぜコメントをするのかが良いのかというと、

インプットとアウトプットを一連の流れで行えるところかなと思っています。

普通ニュースとか情報をインプットする時って、受け身になりがちですよね。

 

いざコメントしようと思っても、結論この記事何言ってたんだっけ?

とかなるのは私がバカだからでしょうか。

以外とさらっと流し読みしてて、対して頭に入ってなかったってことがあったり。 

 

コメントの質なんかどうでもいいですが、インプットした内容に対して自分の頭で考えて、

それを発信するということが手軽にできることがNPを使用していると自然とできます。

 

あとは他のコメントを見れるのも面白いですよね。

記事の中に出てくる人がコメントしていたり、

記事以上に情報がコメントに詰まっていることもあります。

例えばホリエモンが出てくる記事に対して

ホリエモンがコメントしていたりするのは、NPならではだと思います。

 

気をつけたほうが良い使い方の話

いい面も多いのですが、気をつけないと痛い意識高い系になる可能性も秘めているので

その注意点について書いてみます。

 

1. コメント欄は一歩引いてみる

コメントできるところがいいところでもあるのですが、

このコメント欄にNPらしさが詰まっています。笑

コメント蘭を見てそれが世間の声なのだと思わず、

あくまでNPないの意見はこうなんだなと、一歩引いてみることが重要です。

 

コメント欄には世間一般的に見たら変わった人たちが多く集まります。

私もコメントをしているので、みんながみんな変わっている人ではないですし、

様々な職種の社会人や学生、中には高校生もいました。

 

当たり前だろとツッコミを受けそうですが、一般人100人集めた場合と

NPのコメント欄で100人集めた場合だとかなりの違いがあります。

経歴も違えばもちろん意識の高さも違います。 

 

初めのうちはみんな経歴すげーなとか思ったりしていても、そのうち慣れてきます。

そうするとこのニュースに対するみんなの意見はこうなんだ!

みたいな錯覚に陥るのですが、それはあくまでNP内の話です。

それが世間一般的な意見ではないということは忘れないようにしましょう。

NPやっていない人からすると、マイナーな意見かもしれませんし、

NPのコミュニティの特徴で盛り上がっているだけかもしれません。

 

特にNP特有のコメント欄の盛り上がり方もあります。

NPのコメント欄ではこういった傾向の人が褒められやすいぞということが

わかっている状態が望ましいです。 

コメント欄の意見をたくさん読んでいるとその価値観が刷り込まれ、

自分の意見がNPの盛り上がりに左右されてしまう可能性もあります。

結果NPの人たちと同じような意見を持っているのに、

実力だけが変わらずにいわゆる意識高い系になってしまう人は多いような気がします。

コメント欄は一歩引いてみる心がけを忘れずにしましょう。

 

2. コメントだけひたすら読む

これは自分でコメントをしないで他の人のコメントをひたすら読むような場合や、

そもそも記事を読まないでコメントだけを読むということを続ける場合です。

 

時間がないときはそれでも良いと思いますし、

もちろんですが多くの人のコメントを読むことは勉強になります。

ただ、他の人の考えの前にそもそも自分がどう考えたのか?

を持っていないと、先ほど書いたようにNPないの価値観が

どんどん刷り込まれていくという状況になってしまうと思います。

 

自分でちゃんと考えて、他の人の意見も参考にするのはいいんですけどね。 

やはり自分の頭で考えた後に、他の人はどう考えているのか?

という視点でコメントとは付き合っていく必要があると思います。

 

3. いいねを意識したコメントをする

これもNPあるあるな気がします。

誰でも自分がコメントした内容にいいねが来ると嬉しいですよね。

でも、いいねがくるようなコメントとはどんなものか考えてコメントをしてはいけません。

 

コメントを書くことの目的としては、

自分の考えを自分の頭で考えて発信することにあると思います。

結局はいいねがくるようなコメントを考えてしまった時点で、

純粋な自分の考えではなくなってしまいます。

 

そうするとNPユーザーに受けるコメントを目指すようになり、

意識高い系の出来上がりです。それでも実力が伴っていればいいんですけど。

 

 

他のニュースのサイトやアプリと比べても、

かなり有益な情報が多いのは間違いありません。ぜひ使ってみてください。

次は有料会員の良さにでも書いてみようかな〜。

 

KPTで振り返りを始めるときに、起こりがちな問題とその対処法 8選

KPTという振り返り手法はご存知でしょうか?

KPTとは振り返りを行う時の手法の一つです。

 

KPTを導入しているチームも多いのですが、個人的に毎週KPTで振り返りを行っています。

自分の周りでもKPTで振り返りを行っている人が多いのですが、

見ているとだいたい同じような問題にぶつかるものですね。

KPTについてもう少し詳しく

KPTやったことある人は飛ばしちゃって大丈夫です。

先ほど振り返りの手法の一つと行ったのですが、KPTとは

Keep,Problem,Tryの頭文字を合わせたものです。

 

振り返りを行ってみて

良かった点をkeepにまとめ、

改善点をproblemにまとめ、

problemを解消するための次のアクションをTryにまとめていきます。

 

例えば今日のことを振り返ってみて、

keep→英語の勉強ができた

problem→早起きができなかった

try→12時までには寝る

 

みたいな感じでやっていきます。

 チームでやる場合には付箋に書いて、ホワイトボードにまとめたりすることも多いです。

個人的にはTrelloというツールがオススメで、trello上にkeep,proble,tryのボードを作成して行っています。

 

trello.com

 

今回初めてKPTを行って振り返りをしていくと、どんな問題が起きるのかをまとめました。 

早めにどんな問題が起きて、それに対して

どんなことを意識すれば良いのかわかるだけで、振り返りの質は変わります。

さっそく書いていくので、振り返りを行う際の参考にしてみてください。

 

1. 何が問題か把握できない

初回のKPTでよく起こる問題です。

いきなりKPTやろう!と思っても最初はあまり出てこないかもしれません。

それは普段から意識していないと、その時は問題だと思っても忘れてしまうからです。

 

対応としては、問題を把握できないという問題を抱えているので、problemに追加することです。

対処方法は人によって変わってくると思うので、

まずいきなりどんなtryをしたら良いのか考える練習になります。

 

個人的には慣れるまでは振り返りの頻度を多くして忘れないようにするとか、

メモに残しておくということを実践しました。

2. problemに対応したtryが出ない

どんなproblemがあるか意識はできてわかったけれど、

それをどうtryに繋げたら良いかわからない状態です。

 

振り返りの習慣がついていないとよく起こります。

 

わからないことはしょうがないので、

他の人に意見を求めるか検索をするというのが手っ取り早いです。

ただ、なぜそのproblemが発生しているのかということを理解しておかないと、

根本的な解決ができない可能性があります。

3. 具体性や期日、頻度などがない

problemに対応するtryがかけるようになっても、最初は抽象的な表現が多くなりがちです。

「〇〇を意識する」とか「〇〇を確認するようにする」みたいなイメージです。

これだと何を持って意識したと言えるのか?がわからないので、

できたかどうかが判断しにくいです。

 

できた状態とできなかった状態の境目がわからないような表現だったら一度見直す必要があります。

もちろん、 抽象的にしかかけない部分やあえてそう書いているのであれば問題ありません。

 

これの対処は

・できた状態とできなかった状態の境目は何か?

・それをいつまでにできた状態にするのか?

まずはこちらの2つに答えられる状態にしてみてください。

 

4. tryが山積みになる

慣れてくるとtryの量が増えていきます。

あれもこれも問題だから、あれもこれもやらなきゃってなりがちですね。

もちろん使える時間は限られているので、できないtryが出てくるようになります。 

 

こうなってきた場合は一度なぜtryが山積みになっているのかを考えてみてください。

単純にたくさん問題があるから多くなっているのか

それとも以前書いたtryが実施できていないのかで変わってきます。 

 

5. 未実施のtryがでてくる

先ほどの続きですが、tryが増えていくとキャパオーバーになることがあります。

それによってやらないtryが出てきます。 

tryの量が多くなっている場合には、一度優先順位を考えましょう。

重要なもの、すぐに終わるものから実施していくのが良いと思います。

 

また、キャパオーバーとは別にtryの難易度が高かったり、

具体的な行動ではない場合に、tryに書いたものができないということも起こりえます。

例えば何かしらの理由で朝の3時に起きるというtryがあったとしましょう。

この場合難易度は高いですし、起きると行って起きれるもんじゃないので

実施できない可能性が高いです。

 

tryの難易度を下げるということも手としてはあるのですが、

tryができない原因は何か?を考えそれに対して改善をするtryを

繰り返していくことでできるようになります。

 

朝の3時に起きられないのはなぜか?

→睡眠時間が足りない→なんで足りないのか?

→寝る時間が遅い→これをproblemに追加→早く寝るためのtryを考える

 

このようにtryが実施できない原因を考え、それをtryに置き換えてみると良いと思います。

6. いきなりtryを書いてしまう

これはたまにあるのですが、やったほうが良いなって思って

いきなりtryに書いてしまうパターンです。

 

もちろんやったほうが良いことをやるのは良いのですが、

それはどんな問題を解決するためにやるのか?を考えてみてください。

なんとなくやったほうが良いなというレベルであればやる必要はありません。

それよりも自分の行動を振り返って出てきたproblemに対するtryをやったほうが効果的です。

 

ちゃんとやったほうが良い理由があれば、それをproblemに追加しておくことで、

実際にそのproblemが解消されたのかどうかがわかると思います。

 

7. keepができなくなる

problem,tryに目が行きがちでkeepをおろそかにしてしまうこともしばしば…。

tryができるようになりkeepに移した場合、

まだ習慣化されていないためすぐにやらなくなってしまうこともあります。

 

この傾向に気がついたら、本当にkeepできているのか見直したほうが良いです。

keepができていない場合にはもう一度problem,tryに追加しましょう。

8. tryをしたけど結果が出ない

tryを実践してもprobleが解決できないことも出てきます。

あくまでKPTで考えたtryはprobolemを解決する手段でしかありません。

目的はproblemを解決することです。

 

tryを実践しても解決できない時には、選んだ手段が悪かったと割り切り他のtryを実施しましょう。

またproblemがなぜ発生しているか?をもう一度考え直す必要があります。 

さいごに

当たり前ですが、いきなりすべてを解決することは難しいでしょう。

慣れてくると徐々に発生してくる問題もあるので、

徐々にステップアップさせていく必要があります。

 

また、KPTを行う際には合わせて目標設定の仕方についても勉強をすると、より質が高まります。

最初の方に紹介したtrelloを使うと、自分なりにカスタマイズしやすいです。

ぜひ参考にしてみてください。

 

社会人の勉強はいくらインプットしたかではなく、いくらアウトプットしたかで決まる

ゴールデンウィークも終わったので、そろそろ今年入社された方も配属され始めた頃ではないでしょうか。

自分も新入社員の頃はこの時期に配属され、死ぬ気で勉強していました。

 

でも今思うと社会人になりたて頃の勉強の仕方ってあんまりいけてないなと思う事もしばしば。

これを読んでこんな考えもあるんだなと思ってもらえたら良いなと思います。

 

とにかくインプットしようとしていた

この時期にどんな風に勉強していたかなーと思うと、

・オススメされた本を読む

・本の内容を実際に少しやってみる

・ネットで新人向けに書かれた記事を読む

・研修でやった内容を復習する

みたいなことを一通りやっていました。

 

今思うと勉強はしていたのですが、かなり受け身の内容が多いんですよね。

他の人に比べて知識が足りないという自覚があったので、それを埋めるために

たくさん情報をインプットしよう!みたいな感じでインプット量を増やそうとしていました。

 

それを繰り返していくともちろん少しずつ知識はついてきたのですが、それと同時に

この本or記事読んだな。でも内容あんまり覚えてないけど…。みたいなことも増えてきました。

 

覚えてないからもう一回読んで見ようとしたり、

でもまた同じことするのもどうかなとか考えているうちに

勉強した割には知識がついていないことに気がついてきました。

それから勉強方法変えなきゃいけないなと夏頃には考えるようになりました。

 

アウトプットを意識してないインプットの質は低い

きっかけは先輩に、この本を読みます〜という話をした際に、

読み終わったら内容説明してね!って言われたことでした。

本を読むという行為の後に人に話すという行為が事前にあるとわかると

読んでいる間にここら辺について話をすればわかってもらえそうだな、

この章を要約するとこんなことを言っているな、

といったように徐々にアウトプットをする準備をしつつ進めることができます。 

 

その意識がないと読んで入るけど頭に入ってこないなんてこともしばしば。

ひどい時では、朝あまり目が覚めていない時にとりあえず本を読んでいて

何も頭に入ってこないということもありました。たぶん経験ある人は多いはず…。

 

また、私もよく起きてしまうのですが、意識していないと

わかった気になってそこで思考を止めてしまうということもありました。

これを防ぐには、実際にわかっているのか確かめるために

アウトプットしてみるしかありません。 

アウトプットしようとするとその何倍ものインプットが必要

例えば「セパタクローについて説明を受ける」のと

セパタクローについて説明をする」のではどちらがインプットの量が必要でしょうか?

セパタクローについて説明を受けただけで説明できるようになる人は、

変わらないと思うのですが、そうでない人が多いはずです。

 

説明した内容をそのまま他の人に説明をするということはできると思いますが、

自分の言葉で説明をするためには、 ただ説明を受けるよりも多くの時間を要します。

 

セパタクローについての説明というアウトプットをするのであれば

・どんなスポーツなのか?

・どんな面白さがあるのか?

・日本ではどれくらいの人がやっているのか?

など芋づる式にインプットを自然と行うことになりますし、

一度インプットをしても覚えられない場合には、説明をするために何回も

内容を見直したりするなど、結果としてインプットの量も多くなります。

 アウトプットを前提にした勉強をすることで、質・量ともに上がる

今までの内容をまとめると、インプットするときは

最終的に何かしらの形でアウトプットさせることで質・量ともによくなります。

 

私はエンジニアでしたので、

Qiitaという「プログラミングに関する知識を記録・共有するためのサービス」に

勉強した内容や、仕事で学んだこと・つまったことなどをまとめていました。

 

qiita.com

 

ブログでもいいですし、自分のメモ帳にまとめるのでも良いと思いますが、

できれば人の目につくものをお勧めします。

Qiitaを書いていて、まとめた内容になんども指摘をしてくれる人もいました。

その認識間違ってるよとか、間違ってはいないけどこっちの方がシンプルにできるとか。

 

人に見える形でアウトプットを行うと、インプットの質・量が増えるだけでなく

実際にそのアウトウプットに対しての評価も得られることができます。

特に営業の人は、本を読んだら、先輩などに練習相手になってもらうのは良いと思います。

 

また、インプットする前にこの本を読んだら内容を伝えるとか

ブログにまとめるとか宣言してしまうとなお良いです。

内容がわからなかったらやらなくても良いやっていう逃げ道を作らないためです。

 

人に伝えることで、自分では気がつかない点に対してFBをもらえることは多々ありますし、

宣言してしまえばインプットをする際に必ず切羽詰まるはず。 

これだけで自分の勉強の質をあげられるので、

自分で自分の勉強のマネジメントは欠かさず行ってください。