サイコロジー・オブ・マネーという本を読みました

サイコロジーって言葉、ちょっと怖くてキャッチーですよね。

日本語で言えば、心理学ってだけなんですが。

この本は、いい本です。( ˊᵕˋ )

お金持ちになる方法よりも、お金をめぐる考え方についての本、という意味でとっても面白かったです。

一瞬話はそれますが、ちょっと前まで言われていた

「若者のブランドもの離れ」

とか、最近あんまり当てはまらないなって感じてます。

今の20台前半ぐらいの若い人ってブランド結構好きって人増えてるよね。

なんの裏付けもありませんが、Youtuberとかがブランドものを一杯身に着けたりしているせいですかね。

で、この本曰く、

「ブランドものとかで身を固めている人はお金持ちではない」

という話です。

「お金を使っている人はお金持ちではない。」

ま、考えてみれば当たり前ですよね(笑)。

2000万円の時計を持っている人は、その人の現金の保有資産が2000万円減っているからです。

お金が減っているんです。

金持ちになるにはお金を使ってはいけないのです。

「は?そんな当たり前のことでしょ?そんなことを知るために、本を読みたくないよ!」

と思うかもしれません。

待ってください!

他にも、めっちゃいいことが書いてありますから~!!(By 波田陽区)

私なりに、読んでよかったなと思うところを抜粋しておきます。

 

①誰もが0.00000001%の世界で生きている

あなたの個人的な経験が、あなたのお金に対する考え方の8割を形成している。

冒頭の私の「最近の若者はブランドが好きだねぇ」という話も、私の周りの若者のサンプルによるものなので、これがまさにそうですね(笑)。

「人はお金を扱うときにおかしなことをするが、おかしな人は誰もいない。」らしいです。

②成功と失敗には運とリスクが強く影響している

優秀だから成功した、怠惰だから失敗した、というよりもこの世界は運要素が強いという話。

③この世界では、前例のないことが常に起きている

コロナとかもそうだったもんね…。日本では、地震・津波とかもありますし。

「歴史の終わり錯覚」というのがあるらしいです。

今の自分が、何十年後も変わらない価値観でいる、と思うことらしいです。

例えば、弁護士を夢見る10代の少年がいます。猛勉強して弁護士になります。

いざ弁護士になると、長時間労働に追われ、家族と一緒に過ごす暇もありません。そこで彼は、年収は低いが時間の融通が利く仕事に転職します。

だがその後、子どもを保育園に預けるには思った以上にお金がかかり、給料のほとんどが消えてしまうことに気づきます。

そこで彼は、配偶者の収入で生計を立て、自分は仕事を辞めて家で子育てに専念しようと決断します。

彼は「これでようやく正しい選択ができた」そう思います。

しかし70歳になったとき、働かなかったために、老後資金に余裕がないことに気づく…。みたいな話です。

結局、あんまり極端な選択は止めようね、という結論です。

④人間には知らないことを軽視し、知っていることばかりを注目してしまう癖がある

スタートアップ企業が成功するかどうかはその会社がどれぐらい努力するかと同じぐらい、競合他社の業績や市場の変化に左右される、らしいです。

⑤富を築くためには収入や投資リターンより、貯蓄が大事

傲慢にならないこと。富を築くために必要なのは自制心。

⑥お金よりも、人生を自分でコントロールしている人が幸せ

これねー。私、激しく同意します。

1000人の高齢者に聞いたアンケート結果では

・裕福になるために仕事を選ぶべきではない
・欲しい物を買うために仕事につくのはよくない

だそうです。

⑦うまくいかないことがあっても問題ないと考える

99%の事業で失敗しても、1%で成功すればよい。一つの成功のためにいくつもの失敗があるのです。

 

ところで、私はこういう洋書に出てくる小ネタが結構好きなんですよね。

日本のビジネス書って、あんまり小ネタが出てこないんですけど、洋書のビジネス本って小ネタの宝庫ですよね。

今回の小ネタで一番好きなのはナポレオンの名言

「天才とは、周りの者が正気を失っているときに普通のことができる者」

だそうです。( ˊᵕˋ )

ThoughtWorksアンソロジーという本を読みました。

 

この本、中古でなんと5900円もしたんですが、買って会社に持っていったら

M君「え??この本また買ったんですか??」

と言われまして…。 なんと2冊目を買ってしまったらしい(笑)

まぁ、詳しく話すと私が処分しようとしていたところを勉強熱心なM君が自宅に引き取ってくれたのを忘れていたといういきさつでした。

まぁ、古い本なんですけれども。

まだ2023年に通じるところはいっぱいあります。

 

1章 ビジネスソフトウェアの「ラストマイル」を解決する

 

プログラマーの皆さんは感じたことがありませんか?プログラムが出来上がってからが…長いと…!!

正確に言うと、98%ぐらいできてからが、その先の2%ぐらいにめちゃ時間がかかるんですよ。

Windowsの検索みたいだねっ!!

これは、他のお仕事とはだいぶ違うところで、ソフトウェアを作らない方にはなかなかわからない部分だと思います。

なぜかというと、ある程度できてからしかわからないことが多すぎるからです。

それを、ここでは「ラストマイル」と表現しています。

本書からの抜粋ですが

「ラストマイルで実施されるテストでは、システムのレスポンスタイム、トランザクションのスループット、可用性、セキュリティという

非機能要求が満たされているかを確認することに、多くの時間が費やされます。そして、それをテストできるのはソフトウェアが完成した後なのです。」

そう。そうなんですよ。

アプローチとしては本書曰く

「『システムのレスポンスタイムは5秒以下にする』、という決め方だとソフトウェアが完成してからしかテストできないが、

『ディスクへのランダムアクセスを1秒間に2500回以下にする必要がある』という決め方ならソフトウェアの作成段階でテストできるし、カウンタ機能をつくれば自動テストに組み込むことができる」

という話です。確かに!!

5章 オブジェクト指向エクササイズ

 

ソフトウェア設計を改善するために次の9つのことをやってみよう!という話です。

1.1つのメソッドにつき、インデントは1段階までにする

2.  else句を使用しないこと

3.  すべてのプリミティブ型と文字列型をラップすること

int とかは何の意味も持たない。時間とかなら、時間型しか渡せないので、ずっと保守性が高まる。

4. 1行につき、ドットは1つまでにすること

5. 名前を省略しないこと

6.すべてのエンティティを小さくすること

50行を超えるクラス、10ファイルを超えるパッケージは作らないこと

7.1つのクラスにつきインスタンス変数は2つまでにすること

クラスには2つ種類があんねん!とアンミカさんが言いました。

それは1つのインスタンス変数の状態を管理するクラス、2つの独立した変数を調整するクラスです。

ほう。

そして、それを混ぜてはいけません。

なるほど。。。

8.ファーストクラスコレクションを使用すること

実はですね!この本の、この部分だけを読みたくて、この本を買いました!!!

最近仕事で、コレクションをどうクラス設計すればいいか悩むことが多くあったので、ファーストクラスコレクションについて、詳しく知りたかったからです。

実際のところ、12行しか書かれていませんでした(笑)

大事なことは

・他のメンバ変数を持たせないようにする

・フィルタとか作ってもいいかもね。

・2つのグループの結合やグループの各要素に対するルールの適用なども扱ってもいいかもね

・コレクションはただのプリミティブな型の一種に過ぎないので、独自のクラスにラップする意味はある

12行だけでしたが、きっと三蔵法師がインドで仏典を手に入れたときぐらい満足できました。⊂(^-^)⊃

9. Getter, Setter, プロパティを使用しないこと

エッ

「求めるな、命じよ」

だそうです。

「求めるな、命じよ」については、下記の解説がわかりやすかったので、こちらを見てみて下さい。

https://zenn.dev/miya_tech/articles/2289a177cdf2ff


 

<これらのルールを見て思ったこと>

オブジェクト指向的に考えるのが難しい理由って、プログラムを書く時の思考はどうしてもオブジェクト指向と反対から始まることが多いからじゃないかと思ってます。

プログラミングの入り口は

「あるデータがあって、それをAという場合はBに、Cという場合はDに」

みたいに始まることが多いんですよね。そしてそれが膨れ上がっていくのが大体のプロセスだと思います。

そうすると、上のルールを守ることはまったくできません。

オブジェクト指向的な発想は反対側からなんですよね。

「あるデータとは何なのか。どういう役割なのか。構造はどうなっているのか。」

を決めることから始めないとなんですよね。

最近、プログラミングとは概念を構造的に伝える手段なんじゃないかと思います。

 

ところで、この本を中古で買ったんですが、めっちゃ線が入っていて、この本を持っていた人は大変な勉強家だったんだな!と思います。

なんかそういう本っていいですよね( ˊᵕˋ )

 

 

PHPerKaigi2023に行ってきた

今日はPHPerKaigi2023を現地に行って聞いてきました!

いつも私はこういうブログは1週間ぐらい経ってからしか書かないんですが(笑)

今日はモチベが高いので、今日中に書きます!(`・ω・´) 眠いけど…。

さてさて、木曜日から会社で業務の合間にオンラインで見てました。

見たセッションと、その感想をちゃちゃっと書いておきます。


木曜日

技術負債とプロジェクトと私たち

 

発表者さんのWeddingParkでは技術的負債をなんとかするために

①テストコードの導入
②カバレッジの目標を設定
→目標達成に追われないカバレッジ値の設定が必要だった

されたそうです。

そう。テストを作らねば。
なんですが、テストを作るのが面倒 (´ω`)
最初のうちは、意識高くカバーしていても、切羽詰まってくると
「この辺、そのうちリファクタするかもしれんし」
という言い訳などで、テストコードを書かない部分が増えてくる。

これはマジの技術的負債ですね!
なんとか、これを防がないといけないな…。

発表をしていたWeddingParkさんでは、テストコードを書きやすいように環境を整えたり、コード自体を書き直しされたそうです。
弊社も、環境はあるんだけどね…。

PHPUnit 10 概論

PHPUnit10で新しくなることで、印象に残ったのは下記のことです。

・テストイベントが新しくなるらしい。
・テストの結果とテスト自体の問題を区別するようになった。
いくつかのテストの結果やテスト自体の問題では、発生してもテストを中止しなくなった。

DataProviderという機能が紹介されてたんですが、これについて私は知らなかったので、勉強になりました。( ˊᵕˋ )


金曜日

見たいセッションあったんですが、業務多忙につき、一個もみれなかった。(>_<)


土曜日

練馬に行きました!

計測できるレガシーさを捉え、コード改善に対処する

 

途中からしか見れなかった(>_<)。

「レガシーコードだねぇ、おじいさんや。」

「そうだねえ、おばあさんや。」

と言ってるだけじゃなくって、ツールを使ってそのレガシーさを測るべしという話(だと思った。)

とにかくたくさんのlintが紹介されてました。

知らなかったツール→phpmd、Rector、PHP CS Fixer

PHPの配列の内部実装について学びたくなった。

 

そうなんだ~!ということばっかりでした。スクショいっぱい撮った。

JavaだとArrayListとかLinketListとかHashMapとかあるけど、PHPは配列だもんね。

なので、詳しくは上記のリンクにあるスライドを見ていただくのが一番いいかも。

成瀬の挑戦状

 

このセッションの10分ぐらい前に「ドメイン駆動設計入門」という本を読みましたという投稿で紹介した本を書かれた成瀬 允宣さんに直接お会いできて、色々話せたので嬉しかったです!( ˊᵕˋ )

で、その時に挑戦状を頂きましたが、まったくわからず

「?」

となってた私は本当にです。(´ω`)

クジラのこと、Dockerにつながってなくってw Twitterが落ちてる時に出てくるクジラかな?って思ってましたから(笑)

いやー、皆さん本当に頭がいいな~ それとも、競技プログラミングとか(?)こういうことに慣れてればすぐできるものなのかな。

シーザー暗号、とか初めて聞く言葉がいっぱいありまして、なんかいつも接していない分野のことが知れて面白かったです。

問題をもっと前に知っていればよかったな。

人生、宇宙、すべての答えは42らしい(笑)。成瀬さんの博学さに脱帽ですね!

プログラマーってSF好き多いですよね。

成瀬さんと!

PHPerチャレンジ解説セッション

 

こちらも、問題を解く系のセッションでした。最近ではカンファレンスでこういうのやるんだ~ ってなってました。

これも、事前に問題を知っていればもっと前のめりに聞けたかもしれないですが、問題を知らないので、ちょっとぼんやり聞いてました…。

しかし

「PHPのVMを書き換えてevalの動作を変えてしまう」

とか言っていて「マ?」って思ってました…。

「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」

って言葉を初めて知りました。


そして、懇親会!

懇親会が一番楽しかったです。( ˊᵕˋ ) 200人ぐらい参加されてたのかな?

元々、知らない人と話すのが好きなのですが、コロナからはそういう機会がめっちゃ減ってしまって、特にプログラマーさんと話す機会が減ってしまったので、久しぶりでした。

PHPだけじゃない、いろんな言語の話を聞いたり、他社さんの仕事の話を聞いたりするのは勉強になります。

ただ、私今回一人で行ったんですが、こういう飲み会の場で最初一人なののアウェイ感がつらい(笑)

(本当は弊社のK君が来るはずだったんだけど、急遽体調不良でオンライン視聴でした。弊社のほかの人もオンラインで見てたと思う。みんな横浜ずみだからね。)

 

現地に行く一番の収穫は、自分のモチベーションが上がるということだと思います。

PHPerKaigiって有料なんですよ。

会社から経費が出る方もいるかもしれませんが、自腹で来ている人もいるはずで、土曜日にお金出してこういうところに来る人って、意識がめちゃ高いですよね。

そういう人たちの勉強したい、プログラミングが好き、という純粋な気持ちが感じられて、自分の気持ちがアガるのが好きです。

また、すごいと思える人にいっぱい会えると自分が「井の中の蛙」だなって、まだまだがんばらないといけないなと思わせてくれます。( ˊᵕˋ )

 

ハイパワーマーケティングという本を読みました

この本は、私が好きなYoutuberのまこなり社長が紹介していたので読みました。

結果、読んでよかったです。

どうやったらお客様のためになるのか。

それをいつも考えているはずなのに、日々の業務に追われていると、時々忘れかけてしまいます。

お客様のためになることを考える。それが一番大切なことだと改めて気づかせてくれるのが本書の一番いいところですね。

各論でいいなという気づきは、次の点がありました。

 

①お客様が製品を試すときに、なんのリスクもないことを強調する。

→弊社も2週間お試し、というのをやってますが、確かにお客様からすると

「ん?何か契約させられるのでは?」

と思ってしまうかもしれませんね。

実際、なんのリスクもないです。これをもっとわかりやすくしないといけないですね。

弊社の販売しているODIN リアルタイム配送システムでは、申し込みなしでお試しができるんですよ。

これは、ビジネス用のソフトとしては非常に珍しいと思います。

他の会社さんは、まずは営業マンと話をしないとお試しができないのです。

私は、私がお客さんだったらまず試してみたい、と思いましたので、すぐに無料お試しができるシステムを用意しています。

競合他社さんがまずは営業マンと話さないとお試しができないようにしている理由もわかります。

まずは、お試しのシステムを作ることが面倒だし費用がかかる。

次に、競合の調査などで使われる可能性が高い、です。

弊社ではこのリスクを取ってます。

 

②会社の誰もがUSPを語れるようになる 

USPというのは端的に言うと「自社の強み」ということです。
USPを統一して発信する、特に営業部のメンバーが、これを全員語れるようにならないといけない、ということでした。
これは間違いなくやったほうがいいですね。(´ω`)
—————————————————————————————————————–
そのほか、私が印象的だったフレーズは

「レストランを始めるとしたら何がほしい?」

と著者さんが聞いたところ

「いいシェフ」とか「きれいなレストラン」「立地」

と答える人はいたそうですが、

「私はおなかをすかせた人がほしい」

というのが著者の答えだったそうです。

マーケティングの真髄ですよね。

 

ちょっと日本語訳が読みづらいところもありましたが、おススメです!

 

配送計画が新しくなりました!

弊社のODIN 配送計画が新しくなりました!

とはいっても、今回はプレスリリースを出すわけでもないし、この機能がすごい!とかっていう感じではなく、地味かもしれません。

しかし、日々使っている方や、本気でこれからご利用を検討されている方にはとても使い勝手が向上するリニューアルになりました。

詳細な内容については、下記↓をご覧ください。

配送計画大型リニューアルのお知らせ

私的ハイライト☆彡をご紹介します。

【配送指示の導入】

・配送指示の項目はカスタマイズ可能。各会社さんで自由な項目を割り当てられる。

→これは結構大きいと思います!
配送の会社さんって、各社さん設定したい項目が違うんですよね。
何かのコードを入れたいとか、配送に紐づく項目を入れたいとかあると思います。
それが、自由に入れられるようになりました!

♪配送計画 is フリーダム~ ♪

【小口配送の導入】

小口配送とは下記のように集荷場所が1か所、配送が複数個所の配送のことを指しています。

このタイプの配送計画が設定しやすくなりました。

・会社の場所や営業所の場所を集荷先として選択可能になりました!

【集荷配送(集荷と配送が1対1)の設定がExcelインポートで可能に】

・以前はドラッグアンドドロップで集荷配送を設定できましたが、配送先が多いとやりづらいというご指摘を多く受けていました。
そのため、Excelを使って一括でインポートできるようになりました。

【集荷配送の設定がより柔軟に】

以前は、集荷と配送を同時に同じ場所で行うなどができませんでしたが、できるようになりました。
例)クリーニング業などで、配送先で汚れたリネン類の集荷ときれいなリネン類の配送を同時に行うなどの設定が可能に。

【その他】

・一つのルートで同じ配送先に行けるようになりました!
これも変な制約だったんですが、治りました。


ここからはウラ話です。

いやー、これですね…。

実は8月から取り組んでまして。

最初は「案件」というものを配車表だけでなく配送計画部分にも取り入れようということからスタートしたのですが、プログラムの「ある部分」がどうしてもネックでした。

その「ある部分」は今までもネックだったし、元はと言えば「ある部分」は違う「ある部分」のネックのせいでネックになっていたという感じでした。

ここを小手先でいろいろ直しても別にできたかもしれません。

ただ、そうするとまたもやほかの部分のネックになる問題が増えることが目に見えてました。

なので、根っこの問題を改善するという大改造に踏み切ったという感じです。

そして、今度発表するほかの大型機能もこれと連動しているので、こっちができないとそっちもリリースできない状況になってしまっていました(泣)

そっちを早く発表したいという時間的制約があって、これを早く仕上げないといけませんでした。

そしてこの大改造が思っていたよりエグい大改造で、チームの皆さんには本当に負担をかけたと思います。

が、弊社の秀逸、M君とS君が本当によくやってくれました(>_<)

二人とも素晴らしいプログラマーで、実装が本当に早いです。

ありがとう!!( ˊᵕˋ )

 

まぁね~ プログラミングをやったことがない人には

「最初っからちゃんと作ればそういうことにならないんではない?」

と思うかもしれませんが、どうしてもソフトウェアというのは複雑なもので、ちょい改造を重ねていると、いつの間にか複雑に絡み合った問題構造が生まれているものなんですよ。

エントロピー増大の法則、ということなんでしょうかね。

 

私も今回は後半から開発に加わってやってました。

今回はPHPを書くことが多かったです。

やらなければならないことが多すぎて、ガチで久しぶりにプログラミングばっかりやってました。

弊社の定時は10時~19時なんですが、没頭していると、昼ご飯を食べた後、時計を見るといつの間にか20時半ぐらいになってるんですよ。

そんで、その次は20時半から22時半ぐらいになるのが一瞬です(笑)

誰か共感してくれる人いないかな、コレ。

仕事してる時の20時~23時が一瞬ですぎる話。

「仕事ばっかりやっててかわいそう…」

と思われるかもしれません。

が、時間を忘れるぐらい没頭できる仕事ってある意味幸せかもしれないです(笑)

 

性格と価値観がプログラミングという仕事にあっているというか。

プログラミングにはパズルみたいな面があります。

何か複雑な問題があって、それに正解はないんですが、自分なりの最適解を見つけられて、それがハマっていく感覚がたまらないんですよね。

ドーパミンってやつなんでしょうか。

 

とは言っても、今回は私的にもキツかったですけどね(笑)

 

というわけで、使い勝手が大幅に向上したODIN 配送計画

お問い合わせはコチラからお気軽にどうぞ!!

 

業界初!ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』をリリース

すすす すごい機能ができました!!!(/・ω・)/

本日下記のプレスリリースを行いました。

業界初!ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』をリリース

 

ドライバーが徒歩、駆け足、運転中か確認できる『行動確認機能』

 

この機能にそんなに説明はいらないかもしれないんですが、要はスマホを持っている人が

・歩いているのか

・じっとしているのか

・走っているのか

・乗車中か

が管理者側でわかる、という機能なのです。

業界初です。(弊社調べ)

 

どんな時に役立つかというと、例えば急にドライバーさんに連絡したいと思っても

「車に乗っているときは避けたいな…。」

と思いますよね?それを解消してくれます。

また、配送の業界やチラシ配布などの業界では、「小走り」を義務付けられている場合もありますね。

でも本当に「小走り」状態なのかはわかりませんよね。

それが、これからは把握できるということです。

 

経緯としては実は別の目的で始まった開発でした。
プログラム的な用語でいえば、行動認識というものにあたると思うんですが、それをスマホアプリに実装しようと思ってたんですけど、

「ん?この情報って管理側で見れたら便利では?」

ということになって、急遽できた機能です。

なので、別の目的でこれを実装しようと思っていたほんの初期は、実は私自信がスマホアプリの開発をしてました。

開発の際は会社の周りの廊下を走ったり、歩いたり、走ったりしてました(笑)

いい運動になりました( ˊᵕˋ )

 

実際の実装は開発部の柱、M君が実装してくれました!

ありがとうー!⊂(^-^)⊃

 

この機能はなかなか面白いと思います。

お客様のほうで使えるシチュエーションがいっぱいありそうです。

お問い合わせはお気軽にコチラからどうぞ!

 

「俺か、俺以外か。」ローランドという生き方 という本を読みました

旦那氏がローランドさんを大好きで、家にあったので読んだ本です。


面白かったですね!

私もローランドさんの動画を時々見たりしますが、この人は本当に言葉のセンスが抜群なんですよ。

複雑なことをズバっと端的に言ったり、わかりやすいたとえ話でたとえたりするのは相当頭がいい方なんだろうなと思います。

本の中に繰り返し出てくる言葉に

「俺は俺が大好き」

という話がありますが、非常にいい話ですよね。

「は?」

って思われるかもしれませんが、自分に自信があるというのはすごいことだと思います。

世の中、幸福度を決めるのは人間関係だ、という話を時々しておりますが、自信というのは人間関係の底の方で大事なんじゃないかと最近思います。

なんというか、日本社会では

「自信満々なイヤな奴」

という言葉がよくつかわれますが、なさすぎるのも問題だなと思います。

自信があまりにない人は、人間関係でよくトラブルを起こしているなというのが体感だからです。

多分、誰かの言ったことを悪い方向にとらえることが多いんだと思います。

自分を自分で否定するのは、ほどほどにしたほうがよいかなと思ってます。

 

 

 

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

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

いや、いい本です。

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

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

ということです。

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

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

・事なかれ主義との決別

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

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

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

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

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

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

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

「この仕事をするのに能力があるから成功する 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/

 

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