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

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

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

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

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

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

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

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

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

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

AI時代の大学と社会

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

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

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

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

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

 面白い本であった。

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

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

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

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

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

沈黙のパレード

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

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

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

リーンソフトウェア開発

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

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

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

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

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

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

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

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

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

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

２．学習効果を高める

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

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

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

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

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

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

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

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

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

決めないことではない。

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

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

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

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

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

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

６．統一性をつくりこむ

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

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

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

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

７．全体をみる

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

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

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

リーン開発の本質

 名著だと思う。

全編にわたって参考になることばかりが書いてあるので、繰り返し読んだほうがいいかもしれない。特別に抜粋すべきところがあるというよりは全体がすごく良い。

トヨタ生産方式とソフトウェアの関連がいまいちついていなかった面があったが、腑に落ちた。

だいぶ昔の本であるのに、日本にリーン開発が根付いていないのが非常に気になりはした。

原則1:ムダをなくす

原則2:品質を作り込む

原則3:知識を作り出す

原則4:決定を遅らせる

原則 5: 速く提供する

原則6:人を尊重する

原則7 : 全体を最適化する

が原則として挙げられており、それらについて細かく説明がされている。

基本的なコンセプトはサイクルタイムをいかにして短くしていくのかという点だ。

ムダをなくしていくのも、その手段となっている。

ムダには大きく７つがある

• 未完成の作業のムダ
• 余分な機能のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ

バリューストリームマップの作成をしてムダを排除していく。

スピードを上げるために、可能な限り作業を詰め込むのではなく、少し余裕をもたせることで、スループットがあがり、最終的なスピードがあがる。

あまり詰め込みすぎると渋滞が起きるのと同じ。

チームを作っていくために、命令して作業を割り振るというよりは、話し合いながら何をすべきかを全員で決めていくことだ。

ただ、何かをきちんと決めるリーダーは絶対に必要。

集合ベース設計では、３パターンくらいの設計案を考えて、最適なものを選んでいく。時間的な成約に間に合わせるために、確実に間に合うもの、間に合わないだろうけど最高なものなど。

リファクタリングは必要なもので、最初から最適なものを作れなかったから行われるのではない。変更を受け入れやすくして、コードの寿命を伸ばすためのものだ。

リファクタリングは必須であり、プロセスにいれて最初から時間を確保すべき。

リファクタリングのためには、自動テストの強力な取り組みが必要となるので、それが血管の混入を防ぐなどの効果もたらす。

自動テストで重要なのは、製造有形で言うところの、ラインストップに相当する効果を狙ったものだ。

出荷前に不具合を検出して、完成品の検証という時間をなくすことでサイクルタイムを短くするのだ。

ここでは、リーン開発を実践するための、 21 ステップのプログラムを提案 する。各ステップでは、何を行うか、手短な説明だけをする。詳細は、本書 の各所ですでに紹介してきたはずだ。 これらは、 提案として受け止めてほし い。 私たちの提案を試してみて、自分の組織で求めている成果が得られるか どうか、確認してほしい。

■全体を最適化する

1. バリューストリーム全体、製品全体を通してリーン手法を実践する。 バ リューストリームのリーダー(あるいはリーダーとなるチーム)を任命 して、顧客に始まり顧客に終わる、バリューストリーム全体の責任を負 わせる。 ソフトウエアだけではなく、 製品全体を重視する。 バリュース トリームマップを描き、 流れに中断がないか、やり直しや揺れ動きがないか、流れの中で必要なときに利用できなかったり、必要な成果を出せ ていない個所がないか、チェックする。 プロセスのほころびを直し、シ ステムに欠けている機能を補足する。

2. 計測基準を作り直す。 バリューストリーム内で、部分的な計測を行って いる可能性が非常に高い。また同様に、そのような計測によって部分最 適化や、さらに悪ければ、機能不全につながっていることも非常に多い。 部分的な計測を行うのをやめて、 代わりにバリューストリームでの計測 を行おう。

3. 境界越えのコストを減らす。 バリューストリームに大きな遅れがある場 合、おそらくそれは、部署や企業の境界で起きているはずだ。 そのよう な境界を注意深く調べて、 そこで実際にどれだけのコストがかかってい るのかを評価する。 そのような境界で、価値の流れのスピードアップに つながることなら、 ほぼ確実に、境界越えのコスト削減にもなるはずだ。

■ 人を尊重する

4. チームリーダーや監督者を訓練する。 プロセスリーダーを重視する代わ りに、現場のチームリーダーを訓練し、指導し、 配備して、彼らの持ち 場でリーン手法を実践するための時間を与える。

5. 責任や意思決定をできるだけ下のレベルに委譲する。 リーン活動は、価 値を生み出している作業チーム自身により、今いるリーダーの指導の下 で実践されるべきである。 作業チームには、新プロセスをうまく機能さ せるために必要なものを要求させる。

6. 技術へのプライドを育てる。 技術へのプライドは、いろいろなもので崩 される。チームへではなく個人への報酬、散らかった職場やぞんざいな 作業プラクティス、守れるはずのない締め切り、きちんとしたテストや リファクタリングを行う時間の欠如、プロセスの押し付け、ロボットが やるような繰り返しの作業など、 すべてがプライドを崩すもとになる。 このようなプラクティスは根絶し、廃止しなくてはならない。チームメンバー間で報奨をめぐっていさかいが起こらないようにし、 繰り返しの タスクは自動化し、作業をする本人にいちばん適切な作業方法を決めて もらう。また、締め切りに間に合わせるために、作業をいい加減に行わ せるような指示は、絶対に出してはならない。 熱意を持って約束をし、 最高の品質を備えた成果を期待しよう。 そのほうが、個人に対して報奨 やボーナスを与えるよりも、より継続可能であり、はるかに大きな効果 もあるはずだ。

■速く提供する

7. 小さなバッチで作業を進める。 プロジェクトサイズを縮小する。 リリー スサイクルを短縮し、安定させる。 そして、繰り返す。 すべてのリスト や待ち行列の掃除をして、規模が大きくならないよう積極的に制限する。

8. 作業を許容量までに制限する。 繰り返し可能なリズムでチームに作業を させて、許容量を確定する。 実証済みの速度(ベロシティ) に基づいて、 チームに作業を待ち行列からプルさせ、その作業を完全に終わらせてか ら、次の作業に手をつけさせる。 待ち行列の長さを制限し、 その待ち行 列に空きができるまでは、作業を受け付けない。

9. 利用率ではなく、 サイクルタイムを重視する。 リソースの利用率に気を 揉むのはやめて、製品化までの時間や、 顧客への応答時間の計測に切り 替える。

■決定を遅らせる

10. 完全に仕様を決定してから開発に着手するのがよい方法である、という 考えは捨てる。 コンカレント開発を行うということは､開発プロセスか ら仕様を浮かび上がらせるということだ。 コンカレント開発によって、 コストも時間も節約でき、 最高の成果が生み出せ、 最も新しいデータに 基づいて決定を下せるようになる。 コンカレント開発を嫌う理由などな い。 それなら、開発に着手する前に、 完全な仕様ができあがっているべ きだという考えに、どうして執着する必要があるだろう? その答えが、 資金調達が事前に行われるためなのであれば、徐々に資金調達を行うように変更しよう。 もし、固定価格での契約によるものなら、別の契約モ デルに移行しよう。

11. 依存性を断ち切る。 依存性を気にかける代わりに、どのような機能も、 どのような順序ででも追加できるように、 依存性を断ち切るあらゆる努 力をする。 分割可能なシステムアーキテクチャは必須である。 依存性を とことん疑いできるかぎりなくしていく。

12.選択肢を持ち続ける。 撤回のできない決定には、かならず､ 複数の選択 肢を設け、 最終責任時点まで、絶対に選択肢を切り捨てない。 重要な設 計上の決定は、トレードオフである。 最善の選択を行うのに必要なデー タと確信を手に入れるため、それぞれの選択肢が持つ影響力を十分に理 解するための投資をする。 それ以外のすべての決定に関しては、変更を 受け入れやすいコードを作り、クリーンかつシンプルに保ち、変更をた めらってはならない。

■知識を作り出す

13. 設計・構築チームを作る。 製品を論理モジュールに分割して、 バリュー ストリームの各フェーズをそれぞれ代表するメンバーからなる部署の壁 を越えたチームを作り、そのチームでモジュールを担当できるようなシ ステムアーキテクチャを作り上げる。 各チームに適切なリーダーシップ やインセンティブを与え、積極的取り組みや透明性、集中的なフィード バックが維持できるようにする。 チームに対しては、情報を早期かつ頻 繁に共有し、 速く失敗し、絶えず学習し続けることを推奨しなくてはな らない。

14. 継続的な改善を行う文化を守る。 各チームや各部署で、継続的にプロセ スを見直し、改善し、仮説をテストするように求め、また、そのための 時間を作る。 チーム間あるいは部署間でミーティングを開いて、 バ リューストリームの流れに内在する制約や、制約への適応手段を見出 し、全体的な成果を改善させるプラクティスや方針に置き換える。

15. 問題解決手法を教える。 PDCAサイクルや科学的方法など、何らかの問 題解決手法を教える。 チームが仮説を立て、 すばやく数多くの実験を行 い、簡潔に文書化し、検討済みの変更を実行するように促す。

■品質を作り込む

16. 同期する。 未完成の作業を積極的に減らす。 テストを最初に書く。でき るだけ早くコードをテストする。欠陥はリストに付け足していかずに、 見つかった瞬間に作業を止め、直すようにする。 コードをできるかぎ り、継続的に、広範囲にわたって統合する。より大規模で複雑なシステ ムの統合には、同期を入れ子にする。

17. 自動化する。 人間は間違うものだという事実を受け止めて、 自動化によ りポカヨケを施す。 できるだけ早く、 自動化できるプロセスすべてを自 動化する。 テスト、 ビルド、インストールなど、 繰り返し行う作業はす べて自動化する。 ただし、 人を支援して、どうすればもっとうまくでき るか、人に考えさせ続けるような自動化でなくてはならない。

18. リファクタリングする。 コードベースをクリーンかつシンプルに保ち、 重複を目にしたらただちに、コードやテスト、ドキュメントをリファク タリングして、複雑さを最小にとどめる。

■ ムダを排除する

19. マーケティングと技術の両方を理解しているリーダーを任命する。顧客 が何に価値を見出すのか、また、それと密接に関連して、 技術側が何を 提供できるのか、両方を深く理解する責任があることを明確にする。 チームが正しいものを確実に作れるようにする。

20. 価値のみを生み出す。 すべてのプロセスのすべてのステップにおいて、 できるかぎり、価値を生み出す活動と価値の提供能力向上が重視されて いることを確認する。 プロセスサイクルの効率を計測し、改善し続け る。

21. コードをできるだけ書かない。 システムの機能を積極的に制限し、価値 を付加するために絶対必要な機能のみを作る。 組織をあげて、 複雑さに 抵抗する姿勢を作り上げる。

トヨタ物語

最近の本であるが、トヨタ生産方式にがどのように作られていったのかを追いかけた物となっている。

トヨタがどのようにして生まれていったのかの歴史的な部分と、後半は大野耐一とその後輩がトヨタ生産方式をどのように広めていったのかが書かれている。

手取り足取り教えるのではなく、現場に放り込んで自分で考えさせる。だめなところを指摘して鍛える。

という感じで全員が鍛えてもらった。みたいな物語になってはいる。

正直、中には耐えられなくて脱落した人もいたろうから、すごく良い教育方針とは言えないかもなとは思う。

特に使い捨てには出来ない新人をきつく叱るのは、いまは出来ないかもなと思う。

時代が、違うというのは、替えがきくから潰れるやつがいてもなんとかなった時代ということだと思う。人が変わるけではないから。

少々、そのへんが賛美的な表現がされているので、真似するのは良くないと思う。

アメリカでは、論理的に説明して説得したというが、それは今の日本もそんなに違いは無いかなと思う。

物語としては、面白かったけど、そんなに学びがあるかというとそうでもない本ではある。