「小さく賭けろ!」という本を読みました

この本は、以前「失敗の科学」という本の感想を書きましたが、その本に紹介されていた本です。

いや、いい本です。

失敗の科学にだいぶ内容が似ていますが、要は成功するためには、

「ちょこっとずつやって、ちょこっとずつ失敗することを積み重ねることが、成功のために大事」

ということです。

起業だけではなく、コメディアン、建築家、映画、戦争まで多岐な例にわたって、こういうことがいいんだよという話が紹介されています。

いくつか印象に残った話を書いておきます。

・事なかれ主義との決別

「時にはエラーを起こすのがクールだと教え込まないといけない。事なかれ主義の安全策を取ってはならないと覚えこませるのだ。」

「デザインとは複雑かつ把握困難な様相を呈する問題を解決に導くために、批判的かつ創造的な思考を適用してそれらの問題を理解し、視覚化し、描写するための方法論である。」

これ、どっかのスタートアップとかの話かな、と思うんですがアメリカ陸軍の話なんですよ。

意外ですよね。これも、数々の失敗を乗り越えてこのようなことを教えるに至ったそうです。

・失敗の心理的影響を克服する精神的強さと、当初はすばらしく見えたアイデアに固執せずに新しいアイデアを探る思い切りが必要

・「固定的マインドセット」対「成長志向のマインドセット」

固定的マインドセットというのは、例えば困難な仕事を与えられたときに

「この仕事をするのに能力があるから成功する or この仕事をするのに能力がないからから失敗する」

となる考え方ですね。

成長志向のマインドセットというのは

「この仕事をするのに自分はどんなことを学べるだろうか」

ということを考えるそうです。

固定的マインドセットの人は失敗したときはつまりその人に

「能力がない」

というレッテルを張られることなので、失敗を極度に恐れる、自分が失敗しそうなことはやらない、という傾向にあるそうです。

一方、成長志向のマインドセットの人は、失敗したときにもそれは自分の成長の機会ととらえられるので失敗を恐れない傾向にあるそうです。

まぁ~ この話はうなずけますよね。

周りにいる人も目に浮かぶというか。他人を批判しがちな人って失敗を極度に恐れますよね。

ちなみに、子供のうちからこういう傾向があるそうなのですが、

「能力をほめずに努力をほめる」

方がいいそうです。

子供が何か達成したときに

「あなたは頭がいいから○○なのね」

というと、失敗すると

「僕は頭が悪いと思われる」

と思って、失敗を避けるようになるそうです。

ですが、

「あなたはよく努力したね」

というと、次も努力すればいいので、失敗を避けるようにならないそうです。

 

・質問をする

人は6歳ぐらいから質問をしなくなる。なぜかというと、それは教育の問題で、学校に行くと自然と

「質問をして先生に面倒をかけるよりも、正しい答えを導く方が優秀な生徒」

という刷り込みが行われるからだそうです。

それね~。アメリカって日本と比べると人の考え方が自由なイメージありますが、それでもそうなんですね。

大人になって、いろいろなことを聞くと、

「こいつ、何も知らないアホなんか」

と思われたりするのが怖くて質問できないという人が多いと思います。

でも、質問をしないといろいろなことがわからないですよね。自分の思い込みでいろんなことを判断するのは危険すぎます。

 

というわけで、いろいろと得られるものの多い本でしたが、同じような話が、同じような人の実話で繰り返されるので退屈に感じる側面もありました💦

「失敗の科学」という本を読みました

これ、とってもいい本でおススメです!

読んだきっかけは、弊社に内定が決まった学生さんが

「この本を読んでアルバイトの改善をしました。」

というような話をしてくれたことです。

この本では航空業界と医療業界が取り上げられて比較されています。

飛行機の事故があると、どのようなことがあって事故にいたったのか、非常に細かく調べられます。

しかし、医療業界での医療事故があると、あまり調べられない。

医療ミスって皆さんが思うより頻繁に起きてるそうですね。

その結果、飛行機は事故率 0.0009%の非常に安全な乗り物になる一方、今日も医療事故で命を落とす人は多くいます。

イギリスでの調査では、10人に1人は医療過誤によりなんらかの健康被害を受けているそうです。

それほどまでに医療過誤は多いのに、失敗を振り返って分析するということがあまりにも行われていません。

 

さて、つまり何が言いたいのかというと、

「失敗を分析して対策しないと繰り返す」

ということなんですよ。

当たり前じゃん と思うかもしれませんが、この当たり前のことができている組織ってどれぐらいあるでしょうか?

医療過誤は、分析されていないから減らないそうです。

また、本書では

「失敗を報告しても、その人の責任を追及しない」

ことも必要だといいます。失敗を叱責されるとわかっていると失敗を隠蔽する組織になるからです。

また、何かを記録することが必要ですね。それは、ビデオとか音声テープとか、書類とかそういうものがよさそうです。
人の認知というのは、事実を後でゆがめてしまうものだからです。

誰でも、失敗を認めたくない。

のですが、失敗することが成功への近道なんですよね。

「そんなバカな!成功するということは、完璧な計画があって、それにそって組み立てられるもの!」

というのがよくないらしいです。

計画というのは絵にかいた餅であって、大体その通りに進まないので、試してみることが必要だそうです。

「人々は複雑な現実を単純にとらえすぎている。」

わかる~。

成功するだろうといわれて投資家から巨額の投資を得たスタートアップ、マーケティング時点では成功しそうだった新製品、その中でどれだけが生き残ったでしょうか。

 

非難しない、ということも大切なことだそうです。

どうやら、人間は人を非難したい生き物らしい。悲しいサガですね(>_<)

組織の中の仕事やプロジェクトが失敗すると、

「○○さんが悪かった」

とかいう話になりがちですね。そういうストーリーが受け入れやすいかららしいです。
本当は、もっと細かく分析したり対策すれば、建設的に次の失敗を防げるかもしれないのに、それが阻まれてしまいます。

あるいは、まったくその裏返しで、失敗を分析しようとする過程で

「なぜ私が責められるんですか!私が悪いというのですか!!」

という感情的な展開になり、

「いやいや、〇〇さんは悪くないから…。…。(面倒なことになったな)。まぁ、この件に関してはタイミングが悪かったよね。」

というなぁなぁな展開になることもあります。

人を責めるというのがとにかくよくないし、責められたと感じてしまってキレたりするのもよくないですよね。

 

他にこの本に書かれていたことで印象的だったのが、

「プロジェクトの6段階

1.期待
2.幻滅
3.  パニック
4.  犯人捜し
5.  無実の人を処罰
6.無関係な人を称賛

というくだりです。

仕事ではもちろん、これ、趣味のサークル・部活・転職・友人・恋人関係などでもよく見かけませんか?

最初はいいところばかり見えていても、中に入ったり親しくなればイヤなところももちろんあって、それで
「悪いのはあの人」
となって、その人を糾弾し→無関係の人がよく見えてきて、その人間関係を離れていく…。

ということがよくありますよね。

安易な

「○○さんが悪い」

というのはやめた方がいいですね。

 

私なりにまとめると

1.失敗は成功のために欠かせないので恐れない

2.失敗は原因をしっかり分析して繰り返さないようにしよう 安易な原因の推測で終わらせない

3.  失敗を責めることは失敗の隠蔽につながるのでやめよう

というところでしょうか。

 

とにかくよい本だったので、おススメです!

インパール作戦

8月15日は終戦記念日でしたね。

最近入社したアルバイトの学生さんが

「今度、インパール作戦をするんですよ。」

って言うんです。

なんかというと、探検部という部活に所属しているそうなのですが、第二次世界大戦の「インパール作戦」を日本で実行してみるということで、岐阜ぐらいから金沢まで長野の山を越えて10日ぐらい徒歩で歩いたりするそうです。

ひえ~ 大変だ~

と思いますが、なかなか興味深い試みですね。

で、インパール作戦について読んでみました。

https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%91%E3%83%BC%E3%83%AB%E4%BD%9C%E6%88%A6

Wikipediaさんの要約によると

「インパール作戦(インパールさくせん、日本側作戦名:ウ号作戦〈ウごうさくせん〉)とは、第二次世界大戦大東亜戦争)のビルマ戦線において、1944年昭和19年)3月[3]帝国陸軍により開始、7月初旬まで継続された、援蔣ルートの遮断を戦略目的として、イギリス領インド帝国北東部の都市であるインパール攻略を目指した作戦のことである。作戦に参加したほとんどの日本兵が死亡したため、現在では「史上最悪の作戦」と言われている。当作戦を始め、ビルマで命を落とした日本軍将兵の数は16万人におよぶ[4]

当初より軍内部でも慎重な意見があったものの、牟田口廉也中将の強硬な主張により作戦は決行された。兵站を無視し精神論を重視した杜撰な作戦によって多くの犠牲を出して歴史的敗北を喫したため、「無謀な作戦」「無為無策の戦術」の代名詞としてしばしば引用される。この記事は、コヒマの戦い英語版も併せて解説する。」。

ふむふむ。後ろのほうも読むとめちゃ長いのですが、興味深く読めました。

こういう失敗って、現代日本に通じるところがあると思うんですよね。

偉い人二人が話し合った時に、お互い責任を取りたくないから作戦中止のことを言い出せなかったとか。

日本だけじゃなく、人間の本質ってそんなに変わらないわけで、歴史に学ぶところって大いにありますよね。

 

私は第二次世界大戦の話を読んだり聞いたりするのが好きです。

以前も下記の投稿で書いたことがあります。(この投稿のタイトルが恥ずかしい~(*ノωノ))

https://summer-snow.onlineconsultant.jp/2014/08/21/%e6%a0%b9%e6%80%a7%e8%ab%96%e3%81%a0%e3%81%91%e3%81%98%e3%82%83%e3%82%84%e3%81%a3%e3%81%b1%e3%82%8a%e3%83%80%e3%83%a1%e3%82%88%e3%80%80%e3%83%80%e3%83%a1%e3%80%82%e3%80%80%e3%83%80%e3%83%a1%e3%83%80/

 

技術の軽視・制度変革に関する及び腰・問題の根本原因に対する軽視、とかがやがて大きな失敗になるわけで、少なくとも自分の会社ではそうならないように気を付けていきたいなと思います。

 

仕事における成長とは

私の個人的意見なんですけれども!!(ここは私のブログなので、当たり前ですが(笑))

 

仕事における「成長」とはなんだろうと考えました。

 

特にITの業界であれば、仕事=勉強なので、仕事をどんどんこなすことで、

「昨日できなかったことが今日できる」

ということで成長を感じられるし、満足感を得られるとは思います。

私も社員さんにできることが多くなってほしいですし、弊社では新入社員さんには勉強の時間を多く取って、知識を得てもらうようにしています。

とはいえ、こういう「昨日知らなかったことを今日知った」タイプの知識タイプの成長というのは世の人が思うほど「仕事」「会社」にとって価値がない気もします。

 

例えば、プログラマの仕事だと、転職サイトに書く場合もチェックボックスで並んでいて

「できる言語にチェックをつけてください
Java PHP Ruby C C# javascript Python Swift Kotlin」

にチェックをつけるんですよ。多いほうがよさそうな気がするじゃないですか。

でも、履歴書で一番見ないゾーンなんですよ。

 

こういう新しい言語が理解できる、新しい技術が使えるって時間さえあれば大体の人がWebとかで勉強を完結できる時代だし、お金を払ってスクールやセミナーに行っても身につくもんです。

つまり、時間orお金で得られるスキルですよね。

 

で、スクールやセミナーを否定するわけじゃなくってですね。

要はペン習字とか、英語とかと同じで、スキルは手段であって、目的じゃないんですよね。

こういうスキルがいくらあっても、画竜点睛を欠くというか。

仕事にとって、あっても困らないけど、なくてはならないものでもないんですよね。

仕事で身につけてほしい成長は、私にとってはお金や時間をかければできるようになるものではなくって、仕事の中で身につくもんだと思います。

 

仕事という大枠を見た際に必要なスキルって、毎日同じことをたとえしていたとしても、改善の余地はその中にいくらでもあるだろうし、それを見つけることだったり、変わり続ける時代環境に対応することだと思うんですよね。

そういうことを提案できる能力とか、問題を見つけることができる能力とか、世にある新しいものを自分の仕事に取り入れる能力とか。

あるいは、人と話し合って難しい問題を解決したり、利害が一致しない人とも折衝して落としどころを見つけることができる能力じゃないんですかね??

そして、

「〇〇さんの言うことなら取り入れるかねぇ」

と思わせる信頼獲得能力もそうだと思います。

 

信頼を獲得するって難しいことで、もう、日々の積み重ねなんですよ。

時間を守るとか、約束したことは守るとか、嘘をつかないとか、さぼらないとか、悪いことをした時は謝るとか、自分から行動するとかですね。

 

「そんなんもって生まれた性格じゃん!」

という人もいるかと思いますが、私はこういうことは努力だと思います。

「USJを劇的に変えた、たった1つの考え方」という本を読みました

「USJを劇的に変えた、たった1つの考え方 成功を引き寄せるマーケティング入門」

という森岡毅さんの本です。

しかし。

以前読んだ「マーケティングとは『組織革命』である」とほぼ内容がかぶっていて、あんまり新しい話はありませんでした…。

「マーケティングとは『組織革命』である」という本を読みました

マーケティングって本当に大事ですよね。

 

すごい秘密をお話します。

弊社では、

「配送会社のための『ODIN リアルタイム配送システム』」

と弊社製品を定義しています。

これねー、昔は『誰のための』を定義していなかったんですよ。

「こんな機能がありますから、ほしい人が選んで買ってください。」

というやり方でした。

全然売れていませんでした。

ある日、私はマーケティングということに本気で取り組みました。本を何冊も読んで勉強しました。

そこで言われていたのが

「誰のためのものかを定義しろ!!」

ということでした。

で、

運送・配送業のための『ODIN リアルタイム配送システム』」(当時はSmart動態管理という名前でした。)

と定義しました。

それまでは、いろんな業界に売っていたので、運送・配送業という業界に絞ることが、最初は怖かったです。

それ以外の業界の人に売れなくなるんじゃないかと思ったんです。

しかし、この定義づけをしてから、売れ出したんです。

お客様にわかりやすかったんです。

そして、開発する側も、開発すべき機能を絞り込むことができました。

 

なので、マーケティングは勉強する価値があることだと大実感しています。

 

さて、長くなっちゃいましたが💦、この本で私がこれは覚えておきたいなと思ったことは

①「顧客が本当に喜ぶもの」と「顧客が喜ぶだろうと作り手側が思っているもの」は必ずしも一緒ではない
作る側の間隔は、消費者から最も遠ざかることを意識する

②「技術力」だけじゃダメで「マーケティング力」と両方が必要

③最も重要な経営資源は人

ですね!

 

で、私は「マーケティングとは『組織革命』である」という本を先に読んでいたので、あまりインパクトを感じなかった部分もありますが、普通に見れば読みやすく、大変勉強になる本です。

マーケティングが仕事の人だけでなく、なにがしかの利益団体にいる人には参考になる情報があるかと思います。

オススメの本です!

【プログラマー向け】社内勉強会を行っております

Kくんの発案で、2月から、不定期に弊社の社内のプログラマーさん向けに勉強会を行っています。

講師は有志。

なんですが、弊社のデベロップメント課の皆さん(プログラマーのチーム)は大変意識が高いので(`・ω・´)

全員がやってくれました!⊂(^-^)⊃

なんとM君は2月~5月で2回もやってくれました。スバラC。

皆さん、やっぱりプログラマーになろうという人は勉強が好きなんですね( ˊᵕˋ )

学ぶことって楽しいですよね~。

私も、日々これ勉強ですし、何かを教えてもらえるってありがたいことです。感謝ですね!

勉強にプラス、社内の人たちが、

「あー、こんなこと考えてるんだ」

とか共有してくれるのは、なんか新鮮な驚きや発見があります。

 

今後も続けていきたいと思います。

弊社では、現在プログラマーと営業を募集しています!

採用情報はこちらからどうぞ!

「エリック・エヴァンスのドメイン駆動設計」を読みました

いやー、私が紹介するまでもなく、有名な名著だと思いますが。

ほんっといい本。

しかし、超読みにくい。

翻訳のせいもあるのかもしれない。

分厚いのもありますが、7月から読み始めて、なんと8か月もかかりました。(´ω`)

 

ぜひ、プログラミング始めて3年目ぐらいの人たちに読んでほしい。

プログラミングというのは難しいな、と感じ始めた人たちに読んでほしいです。

特に、内容は自分がかかわらない分野の業務システムなどを作るプログラマーにとって必要な知識があります。
とはいえ、C向けのプログラムでも大切な内容も含まれています。

内容は豊富すぎるのですが、あえて私が注目したことをまとめておくと

①その業務分野のプロの話をよく聞くこと。

②言葉の定義をちゃんとする(ユビキタス言語)
〇〇さんの開発しているあの機能とか言わずに、ちゃんと名前にする
そして、共同作業するプログラマー全員がその言葉をちゃんと理解する

③モデルをちゃんと作る
モデルというのは概念。概念がちゃんとしていないと、よいプログラムにならない
ここで、①が重要になってくる。その業務分野のプロの話していることをちゃんと理解して、何が重要なのかをつかむことが大事。

④ソフトウェアを常に進化させ続けるために、しなやかな設計にする
作らないことにはわからないことが多すぎる。(本当に)
常に前進するのを恐れない。

 

特に、私が衝撃を受けたのは③ですね。

モデルとは概念なのだ!!

プログラミングとは、概念を読んでわかるようにすることなのだ!!

 

もうね、ヘレンケラーが

「Water!!!!」

と叫んだような衝撃ですよ。

そういわれればそうなんだけど、地球が大きすぎて見えないように、それに気づいてなかった。

私の今までやってきたプログラミングは小手先だったなと感じました。( ゚Д゚)

やりたいことをやるためにプログラムが存在し、将来の自分やチームメイトがわかりやすいようなコードを志してやってきてましたが、そうか、概念か。

 

逆に言うと、プログラミングをしていて、はっきりしてくる概念もあるわけです。

この体験を最近しまして、今弊社で「ODIN リアルタイム配送システム」にある機能をつけているのですが、そこで、なんか仕様がモヤモヤしているところがあるわけですよ。

コードを見ると、配列でいろいろif文を駆使してなんとかやっている。読むのが大変なやつです。

で、ドメイン駆動設計の考え方に基づいてクラス設計をやり直したら、驚くほどコードがすっきりしまして。

そしたら概念がクリアになったので、仕様がすっきりしました。

そしたら、弊社のソフトウェアが持つ特徴、他のソフトにはなく、うちがお客様に届けるべき価値も明らかになりました。

 

というわけで、杏寿郎、お前もドメイン駆動設計(DDD)をしてみないか。

おススメの本です。

「NO RULES」世界一「自由」な会社、NETFLIX という本を読みました

きっかけは中田敦彦さんの動画でこの本が紹介されていたことです。

Netfilixという会社の、経営に関する本ですね。

 

正直に言いますと、セクション1は面白かったです。

私自身、今は解約しちゃったけど、NETFLIXが好きだったんですよね。

「全裸監督」とか、地上波では今や絶対見れない作品で、ザ・エンタメという感じと挑戦があってよかったです。

そんなNETFLIXさんの経営にはかなり型破りなところがありまして

 

①スター以外にはやめてもらう

②業界で一番の給料を払う

③経費規定もないし、休暇規定もない。自由だ~!!

④お互いにフィードバックをしあう。悪いところも率直に指摘しあう

⑤凡庸な結果しか出さない人にはやめてもらう

 

というのが主なところです。

①の話は私には相当インパクトがありました。

NETFLIXが景気が悪くなったときに、リストラをしたそうです。そこで、

・仕事ができない人

・仕事ができるけど、嫌みなことを言う人

・仕事ができるけど、マイナスなことばかり言う人

の3種類の人にやめてもらったそうです。

そしたらどうなったかというと、めちゃくちゃ会社が仕事しやすくなり、よい会社になったそうです。

うへぇ。

いや~、これねぇ~ 正直なところ、そうだろうとは思いますよ。でも、それを実践して、本にまで書いてくれたことに拍手。なかなかできないことだと思いますから。

外国ではどうなのかは知りませんが、日本って、大体の人が仕事に文句ばっかり言ってますよね。

自分で選んだことなのに、不思議なのですが。

で、仕事に後ろ向きな人々が多いのでマヒしていますが、本来、やっぱり愚痴ばっかり言う人と仕事していて楽しいはずもないし、自分のモチベーションもそがれてしまいます。

そのマイナス効果の絶大なことがわかったわけです。

また、「仕事ができるけど嫌な人」っていますよね。誰もが

「はぁー、あの人いなくなってくれないかな…。」

と思いながらも、「仕事ができる」という理由で放置されている。そういう人も、いなくなったほうがいいんですって。チーム全体の生産性が上がるからです。

 

④お互いにフィードバックをしあう。悪いところも率直に指摘しあう

ですが、例えば「あなたのこういうところがよくない。」といつでも、どこでも率直に指摘することだそうです。

うへぇ。

これは、①によって、チーム内に「仕事ができる、いい人」しか残らなかったから成り立っていることだそうです。

 

元ヤクルトの監督だった野村さんの名言に

「一流のやつにしか怒らない」

というのがあります。

人の批判を受け入れることは、一流の人間にしかできないし、一流の人間はそれをもって飛躍するということです。

私も大いに同意します。

 

批判する側もスタープレーヤーなので、ただ単に人をバンバン批判したいだけの人はいないのがミソ。
人の悪いところを批判したいだけの人は、やめさせられるそうです。

 

しかしな~。

日本ではこれは無理じゃろ。

アメリカでも、難しそうな気がしますね。カミソリの刃の上を歩くようなバランスが問われるのではないでしょうか。

とはいえ、NETFLIXが大成功しているので、このやり方はアリなんでしょうか。

 

私は経営に関する本は、自分の会社に何か取り入れることができないかと思って読むのですが、結局のところ、NETFLIXのやり方で会社に取り入れたいと思えるものは次の二つぐらいでした。

・情報を開示する(財務情報など これはかなり前から取り組んでいます)

・上司を喜ばせるために仕事をしないように、部下に徹底させる

これ以外は、あまり私の作りたい会社とは違うなという視点で読んでました。

それで、後半はあまり読む気がしなかったのはあります。

稲盛和夫さんの「生き方」という本を読みました&登りたい山が違う話

正直、タイトルで

「ヒエッ 重い…」

ってひいちゃう人も多いかと思います。しかし、いい本です。

万人にお勧めするというよりは、「働く」ということに悩みがある方、管理職とかの方に読んでほしいかもしれません。

 

いや、私も正直多分、下記のきっかけがなかったら読まなかったと思います。

ある日、本屋で稲盛氏の本を立ち読みしました(またしてもすみません┌o ペコッ)

次のような話が書かれていました。


経営者のA氏がいました。A氏から、稲盛さんが相談を受けました。

A氏の知り合いの経営者のB氏は、

B氏『経営なんて、他の人に任せてればいいんだよ。一生懸命やらなくても。
僕なんて、仕事は全然しなくても、抜けてても、ズッコケ社長で部下に愛されてるし、ズッコケ社長ってことで、逆に部下ががんばってくれるし。』

(ここで出てくるズッコケ社長という言葉は原文そのままのはず)

と言ってくるので、真面目なA氏は、そうするべきなのか?「真剣に仕事をするのはマイナスなのか?」と悩んでいたそうなのです。

稲盛氏の回答は

「あなたとBさんは登りたい山が違うのです。Bさんの話なんて気にすることはない。」

ということでした。


私は

「うおおおおー!!これじゃー!!!(炎▽炎)

と叫びました。(心の中で)

 

そうなんですよ。ほんこれ。

B氏みたいなことを言ってくる人が、経営者の集まり界隈には、めちゃくちゃいっぱいいるんですよ。

 

まぁ、考えると、昔からクラスに必ずいますよね。

「なんでそんなに頑張ってるの?」

ってせせら笑いと一緒に言ってくる人。

「登りたい山が違う」

そうなんですよ。長年の疑問を、スパッ と解決されまして、「やっぱり稲盛さんはすごいな…」ってなってました。

 

んで、めちゃくちゃ前置き長いんですが、この立ち読みしてた本を読みたいと思っても、もうタイトル忘れちゃったんですよ~。。ρ(。・_・、)

(知ってる人がいたら教えてください…。文庫本でした…。)

なので、アマゾーンで、稲盛氏の一番売れていた本を買いました。自粛期間中に読むのにちょうどよかったです。

 

稲盛さんはエンジニア出身の社長さんなんですね。だからかもしれませんが、私も共感できるところがいっぱいありました。

 

いくつか、線を引いたところがありまして書いておきます。

 

  • 成果は能力と熱意と考え方の掛け算。能力がいくら高くても、考え方が邪道だと、よくない成果しか生まない

→わかるー

  • 楽観的に構想し、悲観的に計画し、楽観的に実行する

→新型コロナでいろいろ大変な今こそ、これを胸にがんばっていきたいですね。(`・ω・´)

  • 目標がいくら高くても、現実には来る日も来る日も地味で単純な仕事をこなすので精一杯」

→京セラ、KDDIなど大企業を築いた方でも、そうやって日々を過ごされてるのか…。となんか勇気づけられました。

  • 本田宗一郎さんの勉強会に温泉宿に行った時に『経営の勉強に来たらしいが、そんな暇があったら一刻も早く会社へ帰って仕事をしなさい。温泉に入って、飲み食いしながら経営が学べるわけがない』と言われた話

→なるほど。本田宗一郎さんの話も本とかあれば読んでみたいです。

  • 長期の経営計画を立てたことがない

→意外ッ!しかし、理由を聞けば納得。日々一生懸命やることが大事、ということだそうです。

プログラミングの勉強法 ふわふわのところに何も積みあがらない

最近は、新人さんへの教育は私も時々しております。

弊社では、教育はとにかく大事という考えでやってます。

人って、自分が教えられたように人に教えるので、最初に教えられたことって、さざ波のように後年に影響があるんですよね。

 

さて、私もまだまだ勉強中ですし、すごいプログラマーというわけではないですが、プログラミングの勉強法ということで紹介したところ、弊社内でも

「わかるー」

と結構賛同を得られた話なので、紹介します。

私の持論なんですが、「ふわふわ理論」と名付けています。

図で、わかっていることは四角です。

わからないことで、ふわふわしているのは雲のような形になっています。

四角の上には、四角が積み上げられますが、ふわふわのものに積み上げたものは、結局ふわふわしてしまう、という論です。

プログラミングの話だけでなくて、他の勉強にも応用できると思います。
暗記ものは該当しないでしょうが、数学・物理・化学などもこういう感じだと思いますね。

これって、本当に最初のころのことじゃなくって、初級から中級に行くときの話なんですよ。

初級の時は、とにかく「やってみる」ことが大切な時もあります。

初級で満足しちゃうとか初級から中級に行かない人ってやっぱりコレが壁だと思うんですよね。

この分かれ道の勉強って本当に大事だと思います。

 

弊社では、わからないことがあったら聞いてね、というのに合わせて、なるべく声をかけるようにしています。

 

余談ですが、私、高校の3年生の時に、とにかく数学が苦手だったんですよ。

全然わかんなくって。

それで、ある時気づいて、自分がわかるレベルへ下がろう…と思って、教科書を見返したんですよ。

自分がわかるレベルって、中学2年生の数学だったんですw

なので、中学2年生の教科書から読み返しました。

周りの人が積分とか微分とかやってましたけど、私は勝手に因数分解とかをやってました。

んで、中学2年生の教科書→中学3年生の教科書→高校1年… と進めていきました。

その結果、数学のテストでもいい点が取れるようになりました。