面白い本であった。
ヨーロッパにやアメリカについては、本を読んだことはあったがアジアにいてはなかったので良かった。
ローマの滅亡と同じくして、中国でも崩壊が始まって、それが気候変動によるものというのは面白いし、現代にも通じるものがある。
中国の民間と政府との分断も、いまに始まったことではなくて、昔からの伝統であるらしい。
これからはどうなるのだろうか。
IT企業の行く末が気になるところだ。
リーン開発の本質の一つ前の本にあたる。
良い本である。順番的にはリーン開発の本質を先に読んで正解だったかもしれない。
こちらの本のほうが具体的で細かいことが書いてあるので。
２２のツールについて話をしてくれている。しかし、本質的には
名著だと思う。
全編にわたって参考になることばかりが書いてあるので、繰り返し読んだほうがいいかもしれない。特別に抜粋すべきところがあるというよりは全体がすごく良い。
トヨタ生産方式とソフトウェアの関連がいまいちついていなかった面があったが、腑に落ちた。
だいぶ昔の本であるのに、日本にリーン開発が根付いていないのが非常に気になりはした。
原則1:ムダをなくす
原則2:品質を作り込む
原則3:知識を作り出す
原則4:決定を遅らせる
原則 5: 速く提供する
原則6:人を尊重する
原則7 : 全体を最適化する
が原則として挙げられており、それらについて細かく説明がされている。
基本的なコンセプトはサイクルタイムをいかにして短くしていくのかという点だ。
ムダをなくしていくのも、その手段となっている。
ムダには大きく７つがある
最近の本であるが、トヨタ生産方式にがどのように作られていったのかを追いかけた物となっている。
トヨタがどのようにして生まれていったのかの歴史的な部分と、後半は大野耐一とその後輩がトヨタ生産方式をどのように広めていったのかが書かれている。
手取り足取り教えるのではなく、現場に放り込んで自分で考えさせる。だめなところを指摘して鍛える。
という感じで全員が鍛えてもらった。みたいな物語になってはいる。
正直、中には耐えられなくて脱落した人もいたろうから、すごく良い教育方針とは言えないかもなとは思う。
特に使い捨てには出来ない新人をきつく叱るのは、いまは出来ないかもなと思う。
時代が、違うというのは、替えがきくから潰れるやつがいてもなんとかなった時代ということだと思う。人が変わるけではないから。
少々、そのへんが賛美的な表現がされているので、真似するのは良くないと思う。
アメリカでは、論理的に説明して説得したというが、それは今の日本もそんなに違いは無いかなと思う。
物語としては、面白かったけど、そんなに学びがあるかというとそうでもない本ではある。
なかなかの良い本であった。
世の中でLeanとかDevOpsとか言われているが、実際のところどうなのか？
みたいなところが、計測をもとに網羅的に紹介されている。
網羅的なのでチェックリストというか指針として使えるなと思う。
CI環境を整えるとか、継続にdeployし続けるとか、ある意味では当たり前のことが言われているわけだが、セキュリティチェックを開発プロセスに組み込んで、毎回やるほうが効率がいいことがわかったとかは、なかなかおもしろかった。
最後の方の結果に関しては、全体的にここにメモを載せておく
組織モデル。これはユニコーン企業の秘密にもあった構造だ。たぶんもう業界標準。
チーム、マネジメント、リーダーシップのそれぞれについて、高いパフォーマンスを生む行動とプラクティスの一覧
1. 本番環境のすべての成果物をバージョン管理システムで管理 GitHubやSubversionなどのバージョン管理を利用して、 アプリ ケーションのコードやコンフィギュレーション、システムのコン フィギュレーション、本番環境のビルドやコンフィギュレーショ ンを自動化するためのスクリプトなど、本番環境のすべての成果 物を管理するケイパビリティである。 第4章を参照。
2. デプロイメントプロセスの自動化 デプロイの完全自動化 (手 作業による介入が不要な状態) の実現の度合いである。 第4章を参 照。
3. 継続的インテグレーションの実装 継続的インテグレーショ ン (Continuous Integration: CI)は継続的デリバリの実現に向 けての第一歩である。CIとは 「コードに定期的にチェックインし、 チェックインのたびに重大な不具合を発見するための迅速なテス トがトリガーされ、不具合が見つかれば開発者が直ちに修正する」 という開発のプラクティスである。このプロセスによって正規化 されたビルドとパッケージを作成し、最終的にデプロイ､リリース する。 第4章を参照。
4. トランクベースの開発手法の実践 トランクベースの開発は、 ソフトウェアのデプロイとデリバリにおけるパフォーマンスの予 測要因となりうることが立証されている。 特徴は ｢コードリポジト リでアクティブなブランチの数は3つ未満」 「統合前のブランチと フォークの『寿命』は非常に短い(たとえば1日未満)」 「アプリケー ション担当チームが統合の際のコンフリクトやコードフリーズ、 スタビライゼーションのためにコードへのチェックインやプルリ クエストをストップする 『コードロック』の期間がほとんど(ある いはまったくない」などである。 第4章を参照。
5.テストの自動化 ソフトウェアのテストが開発プロセス全般に 「わたって継続的に (手作業ではなく) 自動的に行われる､というブ ラクティスである。 効果的なテストスイートは信頼性が高い。 本当 の不具合を探知し、リリース可能なコードだけをバスさせる。 留意 すべき点は「自動化テストスイートの作成と維持管理の主な責任 を負うのは開発者」ということである。 第4章を参照。
6. テストデータの管理 テストデータは慎重に維持管理しなけれ ばならず、テストの自動化においてはテストデータの管理の重要 性が増しつつある。 効果的なプラクティスとしては ｢使用している テストスイートに適したデータを入手する」 「必要なデータをオン デマンドで入手できる」「自組織のパイプラインでテストデータを 調整できる」「実施できるテストの量がデータによって制限されて しまわない」などが挙げられる。 ただし、 自動化テストを行うのに 必要なテストデータの量は常に極力少なくするべきである。 第4章 を参照。
7. 情報セキュリティのシフトレフト 情報セキュリティ関連の作 業を設計段階とテスト段階に組み込むことも、パフォーマンス向 上の重要なカギである。 具体的には 「アプリケーションの情報セ キュリティ関連のレビューを実施する｣ 「情報セキュリティ担当 チームをアプリケーションの設計段階からデモ段階までの全工程 に参画させる」「事前に承認された情報セキュリティ関連のライブ ラリとパッケージを使う」 「セキュリティ関連機能のテストも自動 化テストスイートの一部にする」といったプラクティスが挙げら れる。 第6章を参照。
8. 継続的デリバリ (CD) の実践 継続的デリバリとは ｢ソフトウェ アを、ライフサイクル全体にわたってデプロイ可能な状態で維持 する」という開発プラクティスのことで､チームはこのデプロイ可 能な状態の維持を、 新機能の追加よりも優先する。このプラクティ スを実践すれば、チームのメンバー全員がシステムの質とデプロ イ可能性に関するフィードバックを素早く入手できるので、デブ ロイ不能との報告を受ければ直ちに修正できる。 また、本番環境へ のデプロイやエンドユーザーへのデプロイも随時オンデマンドで 行える。 第4章を参照。
A.2 アーキテクチャ関連のケイパビリティ
9. 疎結合のアーキテクチャ ー チームがアプリケーションのテストやデプロイを、他部署との調整を要さまにオンデマンドで、どのよ 度実施できるかは、アーキテクチャの結合の度合いによって決 協力に頼らず独立した形で作業を進められ、 それによりチームの る。 アーキテクチャが疎結合であれば、チームは他チームの支援や 迅速な作業と組織への価値提供とが可能になる。 第5章を参照。
10. チームへのツール選択権限の付与 本研究では「ツールを選 ぶ権限を与えられているチームのほうが継続的デリバリの能力が 高く、それがソフトウェアの開発とデリバリのパフォーマンスを 高める」との結果が出ている。 チームの効率を上げるのに必要なも のは何かを一番よく知っているのは現場担当者である。 第5章を参 照製品管理の領域におけるチームの権限については第8章を参 照)。
A.3 製品 プロセス関連のケイパビリティ
11. 顧客フィードバックの収集と活用 本研究で「顧客に関するフィードバックの定期的な収集と、製品設計におけるその活用に 対して、組織が積極的であるか否かが、ソフトウェアデリバリのパ フォーマンスを大きく左右する」との結果が出ている。 第8章を参 照。
12. 全業務プロセスの作業フローの可視化 チームにとっては、製品の開発段階から顧客対応段階に至る全業務プロセスの作業フ ロー (ならびに製品や機能の現況) の可視化とその十分な理解が必 須である。本研究で、このケイパビリティがパフォーマンスを大き く左右することが立証されている。 第8章を参照。
13. 作業の細分化 — 作業は1週間未満で完成できるよう、細分化す る必要がある。コツは 「ブランチを使って複雑な機能を開発し低 頻度でリリースするのではなく、迅速な開発が可能な機能に細分 化する」というものである。この手法は機能レベルでも製品レベ ルでも応用できる(たとえば MVP [実用最小限の製品] を利用する のも1つの方法。 MVP とは製品自体とそのビジネスモデルの「検証 による学び」が可能な規模の機能だけから成るプロトタイプのこ とである)。 作業をこうして細分化して進めれば、 リードタイムも フィードバックループも短縮できる。 第8章を参照。
14. チームによる実験の奨励 実現 チームによる実験とは、 開発 者が開発プロセスにおいて、チーム外の人々の承認を得なくても 新たなアイデアを試したり、仕様を更新したりできる能力を指す。 このケイパビリティを強化すれば、 チームは革新を迅速に実現し、 価値を創出できる。 特に「作業を細分化して進める」 「顧客フィード バックを製品設計に盛り込む」 「作業フローを可視化する」 といっ た他のケイパビリティと並行して強化すると効果が高まる。 第8章 を参照 (このケイパビリティの技術面に関しては第4章を参照)。
A.4リーン思考に即した管理・監視に関わるケイパビリティ
15. 負担の軽い変更承認プロセス 本調査研究で「チーム外の変 更諮問委員会 (CAB:change advisory board) のレビューを義務 付けるより、 (ペアプログラミングやチーム内でのコードレビュー など) ピアレビューをベースにしたライトウェイトな変更承認プ ロセスを確立したほうが、パフォーマンスが高まる」 との結果が出 ている。 第7章を参照。
16. 事業上の意思決定における、アプリケーションとインフラの監視 結果の活用 事業や日常レベルの作業に関する意思決定で、 ア プリケーションとインフラのモニタリングツールから得たデータ を活かす能力。 プラクティスとしては ｢問題が発生したら担当者を 呼び出す」 というやり方よりも優れている。 第7章を参照。
17. システムの健全性のプロアクティブ (予防的)なチェック しきい値警告と変化率警告に基づいてシステムの健全性を監視し 問題の予防的な探知と軽減を図る能力。 第13章を参照。
18. WIP制限によるプロセス改善と作業管理 - 進行中の作業(WIP Work in Progress) を制限して作業フローを管理するというのは、 リーン思考の実践コミュニティではおなじみの手法であ る。 効果的に実践すれば、プロセスの改善、スループットの増大、シ ステムにおける制約の可視化が図れる。 第7章を参照。
19. 作業の可視化による、 品質の監視とチーム内コミュニケーショ ンの促進 ダッシュボードや内部Webサイトなどのビジュアル ディスプレイを品質やWIPの監視に活用すると､ ソフトウェアデ リバリのパフォーマンスが向上することが立証されている。 第7章 を参照。
A.5組織文化に関わるケイパビリティ
20. (Westrum 推奨の) 創造的な組織文化の育成 ―これは本研究 で採用した組織文化の測定基準であり、航空や保健医療などきわ めて複雑で高リスクな領域のシステムを専門に研究を重ねた社会 学者 Ron Westrumが提唱したモデルを下敷きにしている。そして 本調査研究では「この測定基準で、チームと組織全体のパフォーマ ンスを予測できるほか、燃え尽き症候群の軽減効果も予測できる 「こと」が判明している。 具体的にこの基準で測定できるのは、 情報 の流れ、 協働・ 信頼関係、 チーム間の仲介などのレベルである。 第3 章を参照。
21. 学びの奨励と支援 自組織は、継続的な進歩を遂げる上で、 「学 び」 を必須の要素と捉えているか｡ 学習を 「犠牲」と受け止めてい るか、それとも「投資」と考えているのか。 これが組織の「学び」の 文化を測る基準である。 第11章を参照。
22. チーム間の協働の支援と促進 従来、チーム同士は「縦割り」の関係にあったが、 それをどの程度脱却し、開発・運用・情報セキュ リティの領域で相互連携を果たせているのかについて、そのレベ ルを反映するケイパビリティである。 第3章および第5章を参照。
23. 有意義な仕事を可能にするツール等の資源の提供 職務満足 度の予測要因となりうるケイパビリティである。 強化のキモは 「各 構成員が困難でも有意義でやりがいのある仕事ができ、自身のス キルを活かし判断力を働かせる権限を与えられること」 「各構成員 が、 職務を全うするのに必要なツール等の資源を与えられること」 リソース である。 第10章を参照。
24 改善を推進するリーダーシップの実現や支援 改善を推進するリーダーシップとは、 DevOps の実践に不可欠な技術的作業とプ ロセス関連作業を支援・増強するもので、 次の5つの要素から成る 「ビジョン」 「知的刺激」 「心に響くコミュニケーション」 「支援 を重視するリーダーシップ」 「個人に対する評価」。 第11章
IT業界であればチャットなどは元々利用しているだろうし、zoomなどのテレビ会議システムも利用しているので、そんなに真新しい内容はない。
ただ、
分報、ザツダンはいいかもなとは思った。
自分がやっていることを一々書くのは良いかもしれない。
ザツダンは、コミュニケーションの機会を意図的に増やすのがいいらしい。
機会とチャネルを両方増やすのが良いというのは、そのとおりだと感じる。
また、言語化がいままで以上に求められており、言語化して不明瞭さをなくしたコミュニケーションが必須となる。
ただ、基本的には書いてる内容で、重要な部分はオンラインオフライン関係なく大事なことな気がする。
オンラインになることで、意図的に今までやっていたことを言語化して仕組み化する必要があるということだと思う。
基本的には、全てをマニュアル化することにより改善する余地が生まれてくるという旨を繰り返し言っている。
内容に説得力があり同意できる部分も多い。
マニュアルを現場からのアイディアを吸い上げつつ更新して行くことで生きたマニュアルになる。
この視点は大事だと感じる。
また、マニュアルのフォーマットして一例を上げると
「部下に注意をする」とは
何：部下のミスやトラブルを是正する行為
なぜ：部下にミスやトラブルの原因を認識させ、反省してもらうことで成長を促す
いつ：部下がミスやトラブルを起こしたとき
誰が：自分
のように作る。マニュアル化することで各個人の力量に依存していたものが見える化されて、担当者が変わっても同程度の結果を残すことが出来るようになる。
結構はっとさせられたのは、管理職に向いていないのは性格のせい。と言ってしまって思考停止に陥っては行けないということだ。
人を変えることで解決を図るのではなく、構造的な問題が何かを明らかにして、それに対処して管理職に向いていないと思える人でも成長を促すという点と
管理業務もマニュアル化することで、だれでもある程度の成果が出るようにしていくということだ。それが会社を強くしていくのだと思う。
あとは、問題がある部下の性格を変えようとするのではなく、行動を変えることで解決を図るとか。Dead lineを設けるとか。当たり前といえば当たり前のことが書いてある。
ソフトウェアの開発でもマニュアル化出来ることは沢山あると感じるので、マニュアル化しつつ、改善していきたいものだ。
良書ではある。
ファクトフルネスとLeanの内容が一個になったような感じ。
基本的には、よく考えて練りに練った案よりも、とにかく試して失敗してフィードバックを得て改善していったほうが良いものが生まれるということが書いてある。
その際に、問題になるのが
失敗を公にすることに対する心理的な抵抗をどのようにして組織的に排除して、失敗を共有するのか？
また、どのようにして失敗したことを計測して次に生かしていくのか？
ということが事実をもとにしながら書いてある。
とにかく計測して客観的な情報を集めないことには改善も進まないというよりは、何が失敗かを見直すことも出来ないというのがある。
なので、とにかく計測することが重要だ。
計測できるようになったら、失敗を公にすることに対するデメリットの排除をすることだ。
評価には使わないとか、積極的なレポートを逆に評価するとか。
そうやって集めた情報を分析して結果をレポートしてあげて、マニュアルにフィードバックしていくことで、堅牢な仕組みを作ることができる。
重要なのは、計測と高速のイテレーションであるなと感じた。
面白い本ではあったが、いろいろなマネージメントの本を読んだあとだと、個人の宣伝用の本かなと感じるところもある。
内容的には、以下に心理的安全性を高めることが重要か？という点にあるが、平常時のルーティーンワークを継続的に効率化するための方法であり、軍隊の非常時には向かないかもなとは思う。
内容は面白いが、なにか応用できる部分があるかというとそうでもないというのが感想となる。
会話形式で書かれていて、面白いが基本的なプロジェクトマネジメントの手法については抑えられていて、素早く基礎知識を得るには良かったおともう。
長期のプロジェクトでは複数のフェーズを分ける。フェーズごとにサイクルを回していく。
やっと読んだ。
読みつがれているというだけあって、名著に分類されると思う。
最初の方は、工場の立ち上げ等を例にとっているが、現代のソフトウェアの会社にも応用できる内容だと思う。
マナエージャーの仕事は、その担当組織のアウトプットを最大化することで、自分の組織や部下のアウトプットを最大化することに費やされているのか？ということが常に問われ続けるべきだということだ。
正直、耳が痛い面もある。自分の行動が常にそうだとも言えない気もする。
また、社内だけではなく業界にアンテナを張り続けているのか？
新しいアイディアを自ら試しているのか？
こういうのは基本だと思う。
例として、朝食工場を例にしており、これは製造業の工程管理に関して具体的なものであると思う。だが、ソフトウェアの現場でそのまま利用できるかと言うとそうでもないと思う。
レポートの作成の意味としては、作成者が厳密にレポートを作成をすることにより業務の確認処理が行われる効果もある。
情報収集は、マネージャーが自分で歩いて回って詰めたほうが効率的なことも多い。
情報収集は式決定のために必要なものであり、マネージャーが行うべき基礎。
また、自分の意見を伝えたり、意思決定の方法のアドバイスをしたりとかはナッジング(ツッツキ)という。
マネージャーが部下の進捗をモニタリングするのは当然の業務である。
ただ、頻度が重要になる。部下が初めてやる作業なら、高頻度でモニタリングが必要だし、なれているなら最終チェックだけで良いかもしれない。
担当者の習熟度によって変える必要がある。
ミーティングは、効果的に行われて行く必要がある。
プロセス中心ミーティング
定期的に行われて、情報交換や共有等が行われる必要がある。
1on1、スタッフミーティング、業務検討会
1on1
相互に教えたり、情報を交換することにある。
部下から、自分の専門ではない分野について教えてもらうのもよい。
頻度は、相手によって変えて良い。未熟なら週に一回。ベテランなら２，３週間に１回など。
部下に準備してもらい、部下のオフィスに出向いてやるのがよい。
スタッフミーティング
２人以上に関連する議論ならば何でも良いが、議題を決めて行うのがよい。
また、反対意見を持つ人間がいつほうが、問題が浮き彫りになりよい。
リーダーは、議題を起動に載せて、メンバーが課題の解決の担当になるように話をまとめて意思決定することだ。
出席者は、部下と上司でありお互いのことを知っている。
業務検討会
まり交流のない人どうしのための意見交換の場。
1on1も、スタッフミーティングも一緒にする機会のない人同士の、教育と学習を継続して行うことを目的とする。
主催するマネージャーは、発表者を助けるために、何を強調すべきか、何に触れるべきではないのか。などを助ける必要がある。
検討するマネージャーは積極的に質問するなどの盛り上げ役もやらねばならない。
使命中心のミーティング
特定の成果を上げるための会議。
司会者が招集する。何をする会議なのか？最終的な意思決定は何がなされていなければならないか？等が明確でない限りは招集すべきではない。
使命中心のミーティングが25%以上になったら、組織不全の兆候といえる。
意思決定の場
意思決定では、上司と部下とかが関係なく意見を言えるべきだ。
テクノロジー分野では、若い人ほど最新知識に精通している傾向があり、マネージャーの知識は陳腐化していることが多い。ミドルマネジャーは、その両方を繋ぐ役割も期待されている。
・どのような意思決定をする必要があるのか？
・それはいつ決めなければならないのか？
・誰が決めるのか？
・意思決定する前に相談する必要があるのはだれか？
・その意思決定を承認あるいは否認するのはだれか？
・その意思決定を知らせる必要がある人はだれか？
プランニング
環境の要求するもの。
現状は何が求められているのか？また１年後には何が求められるのか？その時の差分はなにか？
こういったことがわからないと計画が立てられない。
現状の把握
現在の仕掛りのプロジェクトと可能な作業の能力を把握する必要がある。
ギャップを埋める
ギャップを埋めるために何をする必要があるのかを明らかにする段階があり、その次に何ができるのかを明らかにする段階がある。出来ないことを求めても仕方がないしということだ。
最終的には、どんな影響をいつ与えられるのか？などの尺度で、実際に実施することを決める。
この決めた項目と、実際の行動がアウトプットになる。
組織
組織は、使命を中心として事業組織と機能を提供する機能組織のハイブリットなる。
ソフトウェアの場合でも、エンジニアは機能組織となると思う。
すべてを事業中心にすべきではない。
共通の知識を蓄えて、横展開したりなど、てこ作用を発揮しにくくなるからだ。
事業部のリソースの取り合いは発生するが、バランスを取りながら、両方を持つことが必要となる。
専門技能を提供する組織にも所属している人が事業部にも所属して、内部リソースの調整を行う。
ただ、具体的な調整の方法等は書かれていない。
意思決定の際にあった、いつ決めるとどれだけ効果があるのかなどが鍵になるのだろうか？それとも機能組織のポストのパワーだろうか。
２面組織などとも表現されてはいるが、結局は本務と横のつながりを作るための組織の２つに所属するということだ。
ただ、かなり高度なセルフマネジメントは必要になるので、実際に手を動かしているような人の場合は、不適切かも。
組織コントロール
この部分はちょっとソフトウェアの開発には不向きかも。
ゲームのように競争を煽るような指標を出すのもよいが、それが成果につながるかは、仕事の内容による。
習熟度によって関わり方は変える必要がある。
低：いつ、どこで、何を、どうするのか？などを明確に示す
中：お互いの判断力を信頼して、話しながら決める
高：目標の設定のみをして、モニタリングするだけ
日常ご有無ではモニタリングをすればいいだけの相手でも、緊急時にはすべてを細かく指示する必要にも迫られる。遠慮してはいけない。
考課
相手に率直に伝える必要がある。
思いつくものをすべて洗い出し、最後に重要でないもの。業績の向上に役に立ちそうもない。もしくは、優先度の低いものを消して伝えるようにする。
たくさんのことを伝えられると混乱するからだ。
２つまでに集中したほうがよい。
辞めようとしている人間を引き止めるのであれば、すべての予定をキャンセルして話を聞かなければならない。
相手に重要な問題だと認識しているときちんと伝えなければならない。
点数表
１００点で優れている
〈生産関係〉
■工程、組立て、試験生産というように自分の仕事の業務内容をはっきりさせる。 10点
■現在取りかかっているプロジェクトの中で制約的ステップとなっている困難な点を見つけ、それを中心にした仕事の流れを描く。 10点
■自分の仕事の中で受入れ検査、仕掛り検査、最終検査を行なうのに適切な場を規定し、かつ、これらの検査が処理段階をモニターするものなのか、遮断式のものなのかを決める。また、基準を緩めて可変的（弾力的）検査方式に移れる条件を明らかにする。 10点
■グループのアウトプットを測るための６つの新しいインディケーターを見出す。ただし、それらはアウトプットを量的にも質的にも測定できるものであること。 10点
■仕事の場でこのインディケーターを定例的に使ってチェックする習慣をつける。また、スタッフ・ミーティングでもこの検討を定期的に行なう。 20点
■いま一番力を入れている最重要の戦略（行動計画）は何か。それを必要とした環境からの要請と、現在の状況や、事態の動きはどうか。もしこの戦略を成功裡に実施できたなら、あなたや会社にとって満足すべき状態が結果として現われてくると思うか。 20点
〈テコ作用〉
■一番退屈で時間のかかる仕事の簡素化を実施する。全関連作業手順の少なくとも３割を省略する。 10点
■自分のアウトプットを明確化する。つまり自分が管理し、また影響力を及ぼしている組織のアウトプットの構成要素は何か。重要度順にリスト・アップする。 10点
■情報や知識を収集する方法を分析する。〝見出し〟〝新聞記事〟〝報道週刊誌〟のバランスはどうか。重複しているか。 10点
■〝旅〟に出てみる。その後、旅の途中で出会った人々との交流や取引を列挙する。 10点 ■１カ月に一度は〝口実〟を見つけて旅に出るようにする。 10点 ■部下に次に任せようとしている仕事はどのようにしてモニターするつもりかを書き出す。何をいかにして見ているか、また、どの程度の頻度か。 10点
■ゆとりが生じたときにこなせるプロジェクトの一覧表をつくり出す。 10点
■部下の一人ひとりとワン・オン・ワン・ミーティングをスケジュールを決めて行なう。（ワン・オン・ワン・ミーティングとはどういうものであるかを事前に説明し、準備させる） 20点
■カレンダーで先週のところを見る。活動を、重要性（テコ作用）の低いもの、中程度のもの、最重要のものに分類する。最重要に入るものをもっと多くするための行動計画を作成する。（どの活動を減らすことにするか） 10点
■次週の時間面での困難さを予測してみる。どのくらいの時間がミーティングに取られると思うか。どれがプロセス中心ミーティングで、どれが使命中心のミーティングか。もしも後者が自分の時間の25パーセント以上を占めているなら、それを減らすにはどうしたらよいか。 10点
■向こう３カ月間、組織にとって最も重要な目標は何かを明確化する。キー・リザルトが出るようにそれを推進する。20点
■前記の事柄を部下とも充分討議した後に同様にやらせる。 20点
■自分の責任範囲だが未処理になっている決定がいくつあるかをリスト・アップする。そのうち３つを選び、６つの質問法を用いて意思決定の仕方の筋道を立てる。 10点
〈業績達成〉
■マズローの欲求段階説に従って自分の動機の状態を評価してみる。ついで部下のやる気についても同様に行なう。 10点
■部下に競争のルールを説明し導入する。つまり業績達成基準を示すための一連のインディケーターを決める。 20点
■部下に、タスク関連のフィードバックを与える場合、 どういうやり方があるか、その様々なやり方をリスト・アップする。 そのフィードバックを基にどのくらい進歩したかをどれだけうまく把握できるか。10点
■部下一人ひとりのタスク習熟度を低い、中位、高いに分類する。それぞれにふさわしいマネジメント・スタイルを評価す る。今、自分の用いているマネジメント・スタイルをあるべきスタイルと比較する。10点
■一番最近に上司から受け取った考課と、部下に与えたタスク関連のフィードバックとしての一番新しい考課を評価する。 それは業績を向上するのにどのくらい役立ったか。それを行なうときのコミュニケーションのやり方は、どんな状態のも のであったか。20点
■こうした考課を理想的な形でやり直してみる 10点
製造業に従事している人には非常に参考になる内容だと思った。
製造業ではなくても、トヨタ自動屋には豊田自動織機の蓄積があったからこその自動車だったのだなとわかり、やはり繋がりはあるものなのだなと。
トヨタが創業当時から、基礎材料の研究に重きをおいていたというのもすごいし、やはり事業の中で重量なところの技術には基礎研究のレベルから取り組む必要があるということだろう。
カイゼンやカンバンは有名であるが、Just in timeの思想を具体化するために生まれたものであり、一朝一夕ではなく数年かけて広く普及させていたのが印象的である。
また、高度経済成長期においても大量生産の流行に流されることなく、自分たちが重要と思うことに邁進することの重要性が説かれていると思う。
現代のAIやBigDataの流行に乗って、それらに手を出したところで、それが事業の成長のために必要だから行っているのではなく、流行に乗っているだけだとしたら、AIやBigDataに投資したものや人がゆくゆくは無駄になり、経営の足かせになりそうだなと感じる。
トヨタ生産方式
トヨタ生産方式を分解すると、はじめに 「トヨタ式のつくり方」 がある。 生産現場 に流れをつくることである。 従来のは旋盤、フライスはフライスとかためて 置くのではなく、旋盤、フライス盤、ボール盤といったように工程順に一台一台並 べて配置する。 それにそって従来の一人一台持ちから「多数台持ち」、正確には「多 工程持ち」 へ移行し生産性を向上させた。 もう一つは「トヨタ式のつくり方」にのっ とった「ジャスト・イン・タイム」 生産をするための運用手段としての「かんばん」 方式である。 必要な品物を、必要なときに、必要な量だけ手に入れるために、 「かん ばん」は品物の「引き取り情報」または「 運指示情報」として、また生産工程に おける「作業指示情報」として有効に機能する。
ジャスト・イン・タイム
必要な品物を、必要なときに、必要な量だけ手に入れることができれば、生産現場 のムダ・ムラ・ムリをなくし、生産効率を向上させることができる。 これを発想した 本家本元はトヨタ自工の創業者・豊田喜一郎であり、その発想を後継者たちが展開さ せ、 生産システムにまとめ上げた。単なるイン・タイムではなく、ジャスト・イン・タイムであることが重要なポイントである。 「ジャスト・イン・タイム」は、つぎの 「自働化」の思想とともに、トヨタ生産方式の二大支柱をなす。
自働化
トヨタ生産方式にあっては、あくまでニンペンの付いた「自痴」でなければなら ない。 「自動化」とは機械に人間の知恵を付与することである。 「自動化」の発想は トヨタの社祖である豊田佐吉の自動から生まれた｡ 豊田式は、糸がき れたり横糸がなくなったりすると、機械は直ちに停止する仕組になっている。すなわ 機械に良し悪しの判断をさせる装置がビルトインされているのである。 トヨタで はこの考えを機械だけでなく作業者のいるラインにも拡大している。すなわち、 異常 が発生したら、作業者がラインをストップさせることを徹底している。 「自動」に よって、不良品の発生を防止し､つくり過ぎを押えることができ､また生産現場の 常を自動的にチェックできるメリットがある。
目で見る管理
「自働化」には異常があったら、ラインまたは機械を止める意味がある。この考え 方の基本は、何が正常で何が異常かを明確にすることにある。 品質でいえば不良を表面化させ、量でいえば計画に対して、進んでいるのが、目で見てすぐわかるようにす る。 機械やラインだけでなく、ものの置き方・手持ち量・「かんばん」のまわし方・ 人の作業のやり方、すべての点に当てはまる考え方である。 トヨタ生産方式を導入し た生産現場においては、「目で見る管理」が徹底している。
アンドン
「目で見る管理」の代表はアンドンである。これは生産現場にかかげられた 「ライ ン・ストップ表示板」である。 異常表示灯について説明すると、運転中は緑色を点灯 する。作業者がたとえばラインの遅れを調整しようと助けを呼ぶときには黄色を点灯 する。異常を直すためにライン・ストップが必要であれば、赤色を点灯する。 異常を 徹底的に排除するためには、ラインがとまることを恐れてはならない。
かんばん
「かんばん」とはトヨタ生産方式の第一の柱をなす「ジャスト・イン・タイム」を実 現するための管理の道具である。 四角のビニール袋の中に小さな紙切れを入れたもの が多く使われている。その紙切れには、「なにをどれだけ引き取るか、また「な にをどのようにつくるか」が示されている｡ 後工程が前工程に必要な品物を、必要なときに、必要な量だけ引き取りに行き、 前工程はその引き取られた分だけつくっ て補充するのが「ジャスト・イン・タイム」 生産であるが、この場合、後工程が前工 に引き取りに行く、この間を「引き取り情報」または「運搬指示情報」としてつな ぐのが、 引き取りかんばん」、または「運搬かんばん」という。 「かんばん」の重要な 役割の一つである。 もう一つ、いまの前工程が引き取られた分だけつくるために、生 産を指示する 工程内かんばん」がある。この二つの「かんばん」が表裏一体となっ て、トヨタ自工の工場内の各工程間、トヨタ自工と協力企業との間、またそれぞれの 協力企業内の各工程間･･････こういった具合に、 「かんばん」が回っている。ほかにや むをえずロット生産しなければならない、たとえばブレス部品の生産に使われる 信 号かんばん」がある。 「かんばん」は人間の意思が込められた、いわば「情報」である。
五Wを自らに問え!
問題点を発見するには、「なぜ」を五回反復してみよ。 これこそトヨタの科学的ア プローチの基本態度である。すなわちトヨタ生産方式においては、五Wは五つのWH である。「なぜ」を五回くり返せば、本当の要因がわかり、どうすればよいか (how)もわかってくる。
「原因」より「真田｣
「原因」の向こうに真」がかくれている。いつの場合も、「なぜ」「なぜ」と 原因を掘り下げ、真をつかんで対策しないと､有効なアクションに移ることがで
「省力化「省人化」→「少人化」
高性能の大型機械を導入すると、人間力を省く、つまり「省力化」は実現できる。 しかし、より重要なのは、その機械によって人を減らし、必要な部署に回してやるこ とである。 「力化」して工数がたとえば九人分っても意味がない。一人が ってはじめて原価に結びつくので、「人」を達成しなければならない。ホコ さらに新しい目標が設定された。「人」である。「人」を目ざして 「自動化」を進めてきたが、になったとき、生産量の減った分に比例して人を抜 けない。これは「自働化」が定員制になっているからである。 低成長時代には、この定員制を打破して、何人でも生産できるラインをつくり上げる より、知恵をしぼる必要がある。これが「少人の狙いである。
「動き」 「働き」にする
いくらよく動いても、働いたことにはならない。「働く」とは工程が進み、仕事が でき上がることで、ムダが少なく効率の高いことである。 管理者は部下の「動き」 「働き」に変える努力をしなければならない。
ムダを認識し撲滅する
ムダを認識するには、具体的にムダの性格を分類しなければならない。 生産現場の ムダを分類すると、ゆっくり過ぎのムダ、②手持ちのムダ 運搬のムダ 加工を のもののムダ 在庫のムダ、動作のムダ 不良品をつくるムダ、以上のような ものがある。 たとえば「つくり過ぎのムダ」についていえば、 下の低成長時 代、それは企業にとってのロスというよりは、社会にとっての罪悪といっても言いす ぎではない。 ムダのは企業にとって至上命である。
バカヨケ
生産工程内で一〇〇パーセント良品をつくるためには、治工具・取付具にいろいろ 工夫して、不良品の発生を未然に防ぐ仕組みが必要である。 これを「バカヨケ」とい り。 「バカヨケ」にはたとえばつぎのような仕組みがある。 作業ミスがあれば、 品 物が治具に取り付かない仕組み。 ②品物に不具合があれば、機械加工を始めない仕組み作業があれば、機械が加工を始めない仕組み。 ④作業を、 動作ミスを 自然に修正して、加工を進める仕組み。 前工程の不具合を後工程で調べて、不良を m 止める仕組み作業忘れがあれば、つぎの工程が始まらない仕組みなどである。
標準作業の徹底
トヨタ生産方式では「ジャスト・イン・タイム」 生産をしているため、各工程の 準作業表は、簡潔に明確につくり上げられていなくてはならない。 標準作業の三要素 とは、 一台あるいは一個を、何分何秒でつくらなければならないかを示す「サイク ル・タイム」、②時間の流れとともに作業していく作業順序」、 3 作業を続けていく ために必要にして最少な工程内の仕掛品、つまり「標準手持ち」である。
「流れ作業」と「流し作業」
「流れ作業」は品物が流れている間に、各工程で加工され価値が付加されていくこ とである。コンベアを使って品物を運搬するだけならば、それは「流れ作業」でなく、 「流し作業」である。 トヨタ生産方式の基本条件として、生産現場に「流れをつく る」ことがあげられるが、 ちろんそれは「流れ作業」をつくり出すことである。
多工程持ち
たとえば、 機械加工の工程において、いまに平行して、フライス盤、ボール といったように、生産の流れにそって、おのおの五台ずつ並んでいたとする。 ここ で一人の作業者が五台を扱うことを「多数台持ち」という。フライス 五台、ボ 1ル五台を扱うのも同様である。 それとはべつに、一台の旋盤、 一台のフライス盤、 一台のボール盤といったふうに、一人の作業者が、多数の工程を担当することを 「多工程持ち」という。 トヨタ生産方式においては、生産の流れをつくることを重視 しているので、あくまで「多工程持ち」の実現に努めている。これは「少人化」に直 結する。生産現場の作業者にとっては、 「単能工」から「多能工」へと進むことになる
バトンタッチ・ゾーンをつくれ!
水泳におけるリレーでは、速い人も遅い人も一定距離を受け持つが、陸上のリレー では、バトンタッチ・ゾーンで速い人は遅い人をカバーすることができる。 ライン作 業においても、陸上のリレー方式が望ましい。 監督者はラインの能率向上のために、 バトンタッチ・ゾーンをつくっておくことが大切である。
離れ小島をつくらない
作業者がポツンポツンと配置されていては、お互い助け合うことができない。 仕事 の組合せを工夫して､助け合いができるような作業配分なり作業配置をすれば、 「少 人化」にも結びつけることができる。 生産現場に生きた流れをつくると、離れ小島生まれてこない。
生産の平準化
生産現場において、製品の流れ方がパラックほどムダは多くなる。 設備、人、在庫その他、生産に必要な諸要素が、 必ずピークに合わせて準備しなければならないから である。 後工程が時期と量についてばらついた形で引き取ると、そのバラツキの大き 前工程へさかのぼるほど広がっていく。 外部の協力企業をも含めて、すべての生 産ラインのバラツキを防止するためには最終の組立ライン上のバラツキをゼロにする。 努力をしなければならない。 トヨタ自工の各最終工程は同じものをかためて流さない。 一台一台、違った車をつくる前提で、平生産を行なっている。
ロットを小さく、段取り替えをすみやかに
生産の「平準化」のために、ロットはできるだけ小さくする。旧来の計画生産ではロットは「多々ますますかず」であった。 最終組立工程でいえば、できるだけ同じ種 類の車を流さないようにする。 最終の組立工程がロットを小さくしていくと、とうぜ ん、前工程のプレス部門もそれに応じていかなければならない。 プレスの型を変える、 つまり「段取り替え」をひんぱんに行なわなければならない。そのほか、すべての工 も同様である。 プレスは一つの型でできるだけたくさん打ち続けることがこれまで の常識であったが、トヨタ生産方式では、その常識が通用しない。 段取り替えをすみ やかに行なわなければならない。 段取り替えのスピードは訓練によって速まり、昭和 二十年代、 二~三時間であったのが、三十年代に一時間を割って一五分となり、現在では三分にまで短縮されている。
ライン・ストップを恐れるな!
止まらない生産ラインは、すばらしく完成されたラインか、それとも大きな問題を かかえているか、のどちらかである。 たくさんの人間がラインに配置されていれば、 流れは止まらず、問題も表面化してこない。 これはまったくダメなラインである。 肝 心なことは、必要に応じていつでも止められるラインにしておき、それによって不良 品を生み出すことを防止し、少ない人間で改善を重ねつつ、最後には止める必要のな い、体質の強いラインをつくり上げることである。 ライン・ストップを少しも恐れる必要はない。
必要数生産量
トヨタ生産方式において、生産量とはすなわち市場の必要数である。したがって、 必要数とは行きである。 市場ニーズが生産現場に直結しているので､生産現場で 手に生産数量を変えることができない。 能率向上も必要数を前提として行なわれなけ ればならない。これによって、つくり過ぎのムダを防止することができる。
稼働率と可動率
「稼働率」とは、その機械が一定時間内にフル操業したときの能力に対する、現時 点での生産実績である｡ 行きが悪くなればとうぜん下がる。 反対に注文が ふえると、残業や交代勤務によって二二〇パーセント稼働もありうる。この稼働率の 良し悪しは必要数に対する設備の選択の問題である。 トヨタ自工でいう「可動」とは、動かしたいときにいつでも動く状態をいう。 これは一〇〇パーセントが理想であ る。このためには、保全が確実に行なわれていなければならないし、また段取り替え 時間の短縮がはかられなければならない。
作業改善から設備改善へ
生産現場の改善案を大別すると、作業上のルールを決めたり、配分をやり直したり、 物の置場を明示したりする「作業改善」と、装置を導入したり、設備を自動化したり する「設備改善」とがある。 「設備改善」にはお金がかかり、しかもやり直しがきか ない。 トヨタ生産方式では、まず作業の手順化、標準化を徹底する。それによって大 半の問題点は改善できる。 「設備改善」が先行すると、生産現場は「作業改善」をし ないようになる。 「作業改善」が行なわれてから「設備改善」が行なわれるべきであ
もうけるⅠE
IEすなわちインダストリアル・エンジニアリングはアメリカから入ってきた生産 管理技術であり、経営管理技術である。その定義はさておいて、トヨタ生産方式では、 生産現場全体に及び、質・量・タイミングの調和のうえにコストの低減をはかる「製 造技術」であるとする。 たんに学者の世界で論じられるIEの手法(メソッド)では なく、原価低減に直結する「もうけるIE」こそ「トヨタ式IE」 のいちばんの特徴 である。
マンガ部分は少ないです。ほぼ文章。
タイトルで気軽に読めると思いましたが、実際は中身がちゃんとしてました。逆に良かったです。
①複雑性を理解する力「システム思考」
②共創的な対話を展開する力「メンタルモデル」と「チーム学習」
③志を育成する力「自己マスタリー」と「共有ビジョン」
これら統合的に伸ばしていくことで学習する組織となっていく。
システム思考のどの段階にあるか？
出来事に対して反応的に対処しているだけ：できごとのレベル
問題の発生パターンを認識して計画的な対策が出来始める：パターンのレベル
問題発生そのものを防ぐように、根本原因を明らかにして対処する：構造のレベル
関係者全員に当事者意識が芽生えて対応策が各所から出始める：メンタルモデルのレベル
システム思考で重要なことは、ステークホルダーの相互作用に注目すること。
具体的な演習として以下を行う
思っていたよりも内容が良かったです。
設計の話とか、要点がまとまっていてよかった。
基本的には、言いたいことはルールを決めて統一した形で運用し続けよう、何か決めるときにはチームで話し合いながら決めていこう。
といったところか。
当たり前とはいえ、出来てないことが多いことだと思う。
俺が考える最強の設計が、一つのアプリ内で複数存在するという最悪の事態を目の当たりにしたこともあるので、そういったことが発生しないようにするためのリーダーシップは必須だなと。
開発時の設計のクラス図の共有とか。
示唆に富んだのは、技術課題の改善に関して、アンケートを取って優先順位をつけてロードマップを示して勧めていく段取りについて書かれているのがとても良かった。
きちんとプロジェクト化することでやり期すことができる。
自分が作ったアプリのアーキテクチャの説明が多い部分もあるが、まあそれは仕方が無いことかなと思う。
概ね良い本だと思う。
面白い内容だった。
リアルタイムでニュース記事などは見ていたので、概要としては驚くものはなかったが、想像以上にずさんであったのがわかった。
単純に検査機器が出来ていなかったのに、契約を交わしたり投資家からお金を集めていたことが問題であったのだと思う。
そんな状況でも人から金を集めてしまうホームズの魅力は突出していたのだろう。
また、アメリカの告訴社会が問題を深刻化させた気がする。
投資家から集めたお金で、弁護士を雇、告発をしようとするに人を破産させると脅す。実際に、破産に陥りそうな人もいたようだし。
日本ではここまでの規模になる前に明るみになりそうではある。
かつて物理を学んだ身からすると現在の状況に悲しみも感じる内容となっている。
科学は実験により検証されて初めて理論が価値のあるものになるが、実験自体が難しかったり、高価だったりで、理論と実験の検証というイテレーションが高速に回せなくなった現代の高エネルギー物理学では、理論の評価がもっぱら専門家(同僚)からの承認になっていて、科学的な価値の追求をしているとは言い難い状況になっているようだ。
もともと、実験結果というものも人間のバイアスとは無関係ではなくて、すでに正しいらしいと考えられている値に寄せていってしまうところがある。実験がたくさんできれば、そういうところも是正されやすいのだろうけれども、高エネルギー物理学では難しい面もある。
また、現代では研究者は論文を出してコミュニティから認められる必要があるため、はやりのテーマに人が集まりやすく、テーマ自体に間違いがある可能性があっても、コミュニティ全体が間違った方向に進み続けているといった危険性もある。
そして、３０年近くほとんど目立った成果が無い状況となっている。
確かに、自分が学生の頃から超弦理論はあったと思うし、それについての実験も行われていたと思う。
それらが、科学者の妄想に過ぎない可能背もあるし、それを疑うのが科学的な姿勢といえると思う。
本書の中でも、火と水と土などを元素とした説明で自然が記述されている時代があり、もっともらしく信じられていたわけだが、現代の理論も未来から見れば、同じように馬鹿でたものである可能性もあるのだ。
面白い本だし、手軽に読めて良い。
ただ、内容的には昔ながらのマネージメントの本に書かれていることが書かれている感じがして、特別に新しいことがあるわけじゃない。
アジャイルの先に言っていると本の中では言っているが、昔からのソフトウェが企業のマネジメントかも。
心理的な安全性を確保する
ルールではなく判断基準で管理する
ミッションを与えて、チームに判断させる
など、
スクワッド、チャプター、ギルドなどの人のまとまりの単位は役に立つ考えだと思う。
ちょっと思うのは、そもそもうまく行っていない企業の場合は、ミッションが無い。目標がない。という状態で、そのために判断基準が作れなくて、タスクを食う機械になってしまうのだろうかと思わないでもない。
これは、読んだほうが良いやつだなと。
組織の立て直しの際には、中央銀行の総裁であっても自分で手を動かして、課題を解決していくものだし、その実務能力が必要でかつ、組織掌握なども必要ということだ。
学びが多い。人は好きでも信用はしすぎずに、保険をかけるなどしている。
また、とにかく調べ尽くしているなと思った。記述がとにかく詳細で、繰り返しの内容がほぼないし、内容が濃い。
とにかく現状を調べ尽くして、それは資料は当然として、人にあって目的意識を持って知りたいことを知りつくそうとしている。
その結果として、関係者の思惑が見えてきて、それに対する対処もできてくるという感じで、とにかく対話を通して人も含めた事象を知りつくそうとしているなと。
また、ルワンダの虐殺等についても記述してあり、wikipediaでは、簡単なことしか書いてないが、最終的に虐殺をした側が政権をとったのではなく、多数が殺害された側の民族が外国からの武器援助(虐殺前からあった)により実質的に軍事政権を作り最終的には独裁へと進んでいっているのがよく分かる。
当たり前であるが、単純なことではないというのがわかり、非常に興味深い。
本当に基本的な内容を繰り返し説明する内容となっている。
正直ちょっと物足りない。
クイズはあってもいいが、決算書についての詳細な解説をメインにしてくれるともっと面白かったと思う。
わかった気になるとは思うが、これを読んだところで特に応用が効くようになるわけではない。
すでに決算書を読める人の娯楽用かなという印象です。
良い本だともいます。
かなり丁寧にリファクタリングについて解説してくれています。
ただ、これ参考にすべてを手動でリファクタリングすることは少ないのではないかと思います。
最近のIDEはリファクタリングの機能もあるので、まずはIDEの機能やツールを調べてみるのが良いと感じます。
この本に書いてあることを参考にしつつ、それが実現できそうなツールを探す。
というのが現実の行動になるのではないかと思います。
なので、細部まで細かく読み込まなくても概要だけ掴んでIDEの機能を調べるほうが良いかもしれません。
内容が高度すぎた。
学生時代の数式をなんとなく覚えてはいるので、物理とディープラーニングが関係があることは理解できるが、これを読んだところで応用研究が始めれるわけではない。
ディープラーニングか物理を真剣に研究している人でないと読んでも意味がなさそう。
新しい出版社からだた本ですね。
Web系の企業にいるし、かつてはブラウザを作る会社にいたのにセキュリティのこと何もわかってなかったと思いました。
良書です。
網羅的にWebのセキュリティ全般について書かれているというよりはタイトルの通りブラウザだけに限定しています。
ただ、そのため内容が読みやすいです。
脆弱性についてもきちんと説明してありますし、それらに対してブラウザ自体はどのような対策や利便性を損なわないための迂回方法を提示しているのかなどがわかって良いです。
HTTPのヘッダーにdomainなどを入れることで安全にクロスオリジンでのやり取りを可能にする方法などが書かれているし、XSSを回避する方法など細かく書かれている。
アプリを作成する際には、基本的にはセキュリティの専門家に診断をお願いすることになるケースが多いと思うけど、知っていて損はないことが書いてあるし、なんとなくこんな脆弱性があったような。。。みたいな記憶があるだけでも違うと思う。
フロントエンドに携わらない人も一度読んだほうが良いのではないかと思います。
良い本だと思う。
戦略と目標は違うと教えてくれる。
戦略には条件がある。
文章がとっつきにくい。また、あとがきを読めばわかるが、日本の思想について書き下ろされたものではなく、雑誌に掲載された４つのテーマについてまとめたものとなっている。なので、日本の思想についての内容だけなら１章だけ読めばよい。自分は３，４章はあまり読む気になれなかった。内容が唐突に感じた。事前知識が必要すぎるのかもしれない。
日本の思想については面白い内容とは言える。
日本には、歴史的な思想の積み上げがないが、とはいえ過去からの影響もあるので、どのような影響を受けつつ、これからどうやって積み上げをしていくのか？
というテーマについて書かれている。外国からの思想を統合するというよりは、雑多に並べただけの状態から伝統を作って国をまとめるために国体という概念が導入されたが、國體自体が雑多なものだったので共通認識もないまま、雑多なまま現代にいたっている。専門分野同士もつながらずタコツボ化が起こっている。
タコツボ化は、まあしょうがないとしても、それれを統合した積み上げのある思想のようなものが日本に無いのは今も変わらないと思うし、積み上げ方も特に示されてはいない。
指摘したこと自体に価値があるのだろう。
日本の場合は、積み上げがないので論争がいつまでたっても似たようなことの繰り返しになるのであるとしている。
しかし、アメリカなども似たようなものではないかと思う。
面白い本だった。
物質主義とシャーマニズムからくる、種族を団結させるためには嘘も許容されるという韓国文化が、歴史的に敵対視している日本に向いたときに近代の反日的行動に結びついているという内容だった。
従軍慰安婦がうそであったという内容のみで話題になったけど、韓国の歴史と近代の関係について学問的調査を裏付けとした内容で読み応えがある。
慰安婦なども日本だだけでなく他にも似たような事例はあるが、日本だけを特別視して問題化しているのは種族主義ゆえよのうだ。
しかし、慰安婦は日本だけでなく、世界のすべての軍隊でいるのは当然で、理由は性病の管理と情報漏えいの防止にあったというのは、そう言われれば、世界中の軍隊にいて当然だよなと思う。当然であるから終戦直後は問題にならなかったようだ。
