ヤフーの1on1―――部下を成長させるコミュニケーションの技法

 1on1について解説している本。

人事の人が読んだりするような本かなと思う。

基本的にはコーチングをするのがよい。

といった内容なので、具体的に1on1のやり方を知りたい人はコーチングの本を読んだほうが良いと思う。

1on1もコーチングも知らないという人が、とりあえず、1on1ってどんなものかを知るための本。

といった感じ。

なので、実際のマネージャーが何度も読み返す本ではないかな。

マンガでわかる! トヨタ式資料作成術

 エッセンスが盛り込まれていて、良い本だと思った。

わかりやすいし。

トヨタのやり方が7つのステップに分かれるとか8つのステップに分かれるなどの話はあるし、ネットにいくらでもある。

演習をする機会というのはないので、漫画で使い方をなぞれるのはよい。

特に提案資料のA3というのは、みたことなかったので良かった。

結局はA3くらいにまとまっているくらいストーリーが上手く出来ていないと、物事がうまく進まないということなのだろうとは思う。

正直、トヨタの問題解決は

https://happymakeproject.com/24725/#toc16

がよくまとまっているので、これを見るのが良い気もする。

一下級将校の見た帝国陸軍

日本が持っている組織の問題を浮き彫りにしていると思う。

現代の日本的な製造業企業にも同様の特著が見られるとは思う。

大きな単位の軍隊がある。ただし第○軍は欠。といった具合で、表現だけの帳尻を合わせて実態が伴っていなかったり、員数と言って数の帳尻さえあっていれば実態はよいなどなど。

実態と報告書が乖離している。

若い将校が自分の地位を勘違いして、ズボンのチャックまで部下に降ろさせるようなことまであったらしいから恐ろしいが、そのような状況は現代日本でもいくらか残っている気がする。

誰が命令を出したのか、本当に出したのか疑心暗鬼になって信用ができないなどは、流石にないにしても、命令系統がはっきりせずに、誰が決定権を持っているのか全くわからないというのは、現代の日本の会社においても往々にしてあると思う。

計画や評価の仕組みを整えずに、現場に任せてしまっている状態で報告自体も信用できなくなり、当然仕組みを作ることなどできずに全体が崩壊していくというのもである。

本書に書かれていることは比較的に、日本の組織全体に言えることなのではないかという気がしてくる。

古き良き日本企業というのに務めているのであれば一読の価値はあると思う。

AI時代の大学と社会

アメリカで仕事したこともないし、暮らしたこともないので、アメリカの実態がわからない私のような人間が読むと得るものがあるかもしれない。

アメリカの格差社会具体は広く知られているとは思うが、上位２０％下位２０％が再生産されていて、貧富の差が固定化されていっているというのは、改めて見ると怖い話だ。

著者の日本で暮らしていつつも、日本の組織に対する恨み節が至るとことにあり、日本で職を得て生活してそれなりに成功しているにも関わらず、これだけの不満が出るということに日本のアカデミアの硬直性というか進歩性のなさに不安を覚える。

アメリカのやり方や文化を手放しで褒めちぎっているわけではないが、日本の良いところや伸ばすべきところなどについて言及がなかったのが残念ではある。

世界史とつなげて学ぶ中国全史

 面白い本であった。

ヨーロッパにやアメリカについては、本を読んだことはあったがアジアにいてはなかったので良かった。

ローマの滅亡と同じくして、中国でも崩壊が始まって、それが気候変動によるものというのは面白いし、現代にも通じるものがある。

中国の民間と政府との分断も、いまに始まったことではなくて、昔からの伝統であるらしい。

これからはどうなるのだろうか。

IT企業の行く末が気になるところだ。

沈黙のパレード

 つまらないわけではないが、ちょっと拍子抜けという感じであった。

容疑者Xの献身と比べると、登場人物の切実さにかける行動が目立つ。

トリックありきで、人間模様には薄さを感じた。

リーンソフトウェア開発

 リーン開発の本質の一つ前の本にあたる。

良い本である。順番的にはリーン開発の本質を先に読んで正解だったかもしれない。

こちらの本のほうが具体的で細かいことが書いてあるので。

２２のツールについて話をしてくれている。しかし、本質的には

1. ムダを排除する
2. 学習効果を高める
3. 決定をできるだけ遅らせる
4. できるだけ速く提供する
5. チームに権限を与える
6. 統一性を作りこむ
7. 全体を見る

について書かれている。いわゆる７つの原則であるが、リーン開発の本質に書いてあることと少し違う。リーン開発の本質のほうが後で書かれた本みたいなので、そっちを見たほうがいいかも。

１．ムダを排除するについて

ここだけでもかなり良い内容だと思う。

バリューストリームマップを作成して、とにかくムダを排除すること。

待ち行列が無駄になるので、余裕をもたせて渋滞が発生しないようにすることなどが書かれている。

２．学習効果を高める

品質の作り込みと決定を遅らせるということに関連している。

最初から完璧なものを一発で提供することを目指すのではなく、可能な限り初期の頃から品質チェックを行うということだ。最後の工程で品質チェックをして差し戻されるとムダが多いからである。

ユニットテストも自動化のうちの一つだと言える。可能な限り自動化することで品質の作り込みが前倒しできる。

また、開発の方針決定であるが、いきなり決めるのではなく、広く調べるべきで、段々と選択肢を狭めていく方向が良いと言える。

いきなり決めて、後戻りをせざるを得なくなると無駄になるので、できるだけ広く調べて少しづつ選択肢を狭めていったほうが良い。

ちょっと指摘が足りないと思ったところは２つある。

セキュリティについてだ。セキュリティチェックも可能な限り早期にかつ繰り返し行うほうが良い。

また、いつまで広く調べるべきだろうか？という点については言及がなかった。ただ、スケジュール感覚に優れた人の意見を聞いて決断していくべきだということが書いてあったと思う。

３，決定をできるだけ遅らせる

決めないことではない。

コンカレント開発は、仕様が固まりきらない段階から開発をはじめて、それぞれの工程での制限をフィードバックすることで、無理のない仕様や設計にして製品を作っていくということ。制限を伝えるというのが味噌。

できるだけ決定を送らあせたほうが、情報が揃っているので、良いわけだが、ただ決めずに遅らせるのは良くない。決めるべきタイミングではきちんと責任のある人間が決めて前進させる必要がある。

４．できるだけ早く提供する

早く作れるならギリギリまで決定を遅らせることが出来るから。フィードバックを与えられるから。当然メリットは多い。

５．チームに権限をあたえる

命令して動かすのではなくて、ボランティアの集団を動かすようにマネージメントするのが良い。

６．統一性をつくりこむ

ちょっと次の本では消えた要素では？とか思ってしまう。

リファクタリングは、やり直しではないし、設計コンセプトを保つための方法になるので、最初から工数に積んでおかないとだめだ。

そうしないと全体での統一性が取れなくなる。

実際に、そうなっているプロダクトを見ているので、まったくそのとおりだと思う。

７．全体をみる

局所最適しないように全体を見たほうがよい。

ここでは、リーン開発と協力会社との契約に関して記述されていて、非常に興味深い。

リーン開発の本質と微妙に違う構成になってはいあるが、非常に良い本であったし２２のツールは見直していきたい。