トヨタの強さの秘密って本を読んで昔を思い出す
本を読むのが好きなのでいろんな本を読むんだけど、
最近はアウトしていないので、
ブログはじめました。
自分の備忘録の為に、気ままに書こうと思います。
なので、散文ですし、構成もめちゃくちゃです。
あしからず。
と、自分の文才のなさを言い訳しておきます。
今回はこの本。
ちなみに、僕はずっとトヨタ車です。
たまたまですが。
この本を読んだら昔のことをたくさん思い出しました。
では、ざっくりこんな感じで書いてみよう。
・本の内容について
・S/Wで考えるとどうなの？
・この本を読んで何を思ったの？
まずは本の内容について。
ネタばれしない程度に。
「だから潰れるんだ」
的な。
特に日本の企業や大学の先生に対しては、
というようなことを言ってます。
ちょっと誇張してますが。
さらに 大学教授に対しては、
「お前ら分かってないくせに、中途半端に伝えるからみんながおかしくなってるんだ！」
ぐらいな勢いです。
まるで、私の大師匠にお説教をくらっている、
もとい、、、お説教をして頂いているような感じが。。。
本質的なところで言うと、
「TPSばっか注目してるけど大事なのTPDだぜ」
って言ってます。
TPSはもうけの５％にしか貢献していないとのこと。
95%はTPDとのこと。
つまり、生産方式ではなくて、どのように製品開発を行うかが大部分を占めています。
設計情報をどのようにして作るか、です。
まぁそりゃそうですね。
生産方式で改善できるのは生産効率なので。
売れないものを高品質、高効率で作ってもねぇ。。。
売れるものを作るためには、現地現物を含む、膨大な事実データの分析が必要。
いろんな観点で分析したあらゆる結果と、各分野の技術的な実現性を見渡し、それらを綜合して１つの車を作るとのこと。
つまり、TPDではビジネス領域の検討段階からを「設計」活動といい、設計活動の早い段階で製品の値段が決まります。
製品の値段が早くに決まるので、その後の設計活動で利益率を上げるためには、いかに低コスト、高品質に作るかがキモなのです。
３つの資産なんて話が出てきます。
設計情報とプロセスと人の頭脳です。
で、製品の開発は最初から最後までずっと1人の人が担当するとのこと。
ここでいう製品とは、自動車のことです。
なので、製品名が決まる前は、「中原さんの車」なんて風に呼ばれるようです。
その人は、いろんな分野（ボデーとかエンジンとか電送とか、、、）の深い知見を持った1人のスーパーマン（主査）です。
その人が、スーパー優秀な子分たちを引き連れて、車の開発の全体を取り仕切るらしです。
彼らは、常にお客さんに価値があるかどうかが判断の軸で、社内の政治とか上司がどうとか、そんなことは関係ないとのこと。
「売れないものを作るのは犯罪です」
スーパーマンが、プロセスも含めて全部決めるんだって。
すごい人ですねぇ〜〜。
きっと、めっちゃ貰えるんやろうなぁ。
うらやまぁです。
ちなみに、情熱と才能に溢れて、かつ、将来はトヨタの役員になるぐらい超優秀な"人" らしいです。
つまり、最後は "人"
じゃー次に、S/W開発で考えるとどうなのでしょうかね。
S/Wも同じですね。
売れるモノを作っていなきゃだめですね。
そして、モノを作るエンジニアが優秀でなきゃだめですね。
TPDでは初めの方に価格が決まるから、いかに低コスト・高品質に作るかってのが重要になります。
これって、S/Wで言うとS/Wアーキの設計に当たるのかも。
（この話し、昔に記事に書いた記憶があるけど、どこだったかなぁ。。。）
ビジネス設計からS/Wまでをトレースできるようにする？
やばい。。。
がっつりそっちよりになってきたw
いわゆる、開発工程の「設計」フェーズと言うスコープだけではなく、
プロダクトが儲かる仕組みまでを含めた設計(TPDで言う設計)を、
設計情報としてモデルで表現することを手助けする仕組みがあれば嬉しいなぁ。
TPDで言う設計情報を作ることを、設計情報のライフサイクル全般にわたってサポートできると嬉しぃ。
先も言った通り、この本によると売れる製品の設計情報は、現地現物を含む膨大な事実データをいろんな観点で分析し、あらゆる検討結果を綜合して、１つの車を作るとのこと。
スーパーマンじゃないと、綜合できないのですよ。
そんな、何でもかんでも知らんし。
なので、凡人でもお手軽にスーパーマンライクな仕事ができるようになると良いなぁと思うわけです。
結局、SPLのPLアーキとかコアアセットの話しになるのかなぁ。。。
設計モデルを書くと、現在の開発能力に応じて実装工数が出るとかw
わけがわからなくなってきたw
今の僕には、まだ良い案は出ないですねぇ。
なんて考えていると、astahに品質スイートって機能セットを組み込んだ時のことを思い出しました。
ビジネス要求とS/W設計の話ではないですけどね。
astahに品質スイートを組み込んだ時は、モデルをもっと手軽に、かつ有益に使ってほしいって思いがあったのです。
豆蔵やChangeVisionで学んだ、ソフトウェアエンジニアリングと人間系。
一見、両極端なんですが、両方の良い部分を取り出せないかなぁと思ったのです。
お手軽でいて、かつ、工学的な技を活用できる、みたいな。
それで、最も効果がわかりやすい「設計モデルとテストケース」というモデルの使い方を表現しました。
ん〜〜、なつかしぃなぁ。
では、長くなってきたので、この本を読んで思ったことをまとめると。。。
２つあります。
１つ目。
ビジネスはビジネスでちゃんと考えろ！
アジャイルって言葉のスコープを広げて何でも開発のせいにするな！
一緒に儲けようぜ！
ってことが言いたいことです。
この話はこの本を読んだから思ったことっていうよりも、改めて気づいた感じです。
ここ2,3年ぐらいずっと思っています。
なので、また近いうちにちゃんと書こうと思います。
状況が把握できるから、いろんなことをタイムリーに判断し、対応できる。
間違っても手戻りが少なくて済むしね。
どうせ間違うし。
これは、TPS的なもの。
S/Wが設計として解決すべき課題に対する解決策は、提供していない。
売れる製品を作るためには、ビジネスの仮説検証が必要。
TPDの始まり。
膨大なデータや現地現物による徹底的なビジネス戦略の仮説立案と検証。
Lean StartupとかDesing Thinkingの領域。
先の通り、これはScrumをやったからって達成できるもんじゃない。
特に新規事業の領域では、ビジネスの仮説検証を行うサイクル（構築 - 測定 - 学び）と、短周期で成果物を出し、かつ、状況を把握できるScrum(透明性 - 検証 - 適応 )みたいなやり方がマッチしたのでしょう。
TPD + TPS。
なので、たまにアジャイルって言葉の中にLean startupとかDesing Thinkingも含めて語る人がいますが、違うよって思います。
ビジネスの責任を開発に押し付けちゃダメだよ。
ビジネスはビジネスで、ちゃんと考えないとダメだよ。
トヨタの主査制度みたいに、Product Ownerに数億円規模のビジネス目標の全権を委任しているのかい？
Product Ownerはその情報を元に、やることの優先順位なんかを決めてるんじゃないの？
だから、ビジネスサイドの人もPOも開発Teamも関係者みんな（いわゆるステークホルダーってやつ）で、一緒に価値の仮説と成長の仮説を立案して、検証しようよ。
その中で、それぞれの役割に応じた仕事をしようよ。
と、いうのが言いたいことの１つ目。
TPDの初めの方に関係することを言いました。
次に２つ目。
エンジニアリング側から必殺ワザを持ち込みたいわぁ。
ダメなやつにも最低ラインは守らせたいわぁ。
ツールとして設計品質を上げるサポートってできないかなぁ。
さっきの話の続き。
では、そのビジネスの設計に対して利益を最大限に引き上げるためにはどうすれば良い？
かんばんを使えば良いの？
それだけじゃないと思うのです。
それだけじゃ5%です。
(S/W開発の場合は、きっともっと貢献していると思う)
顧客が対価を支払ってくれるもの（顧客価値のあるもの）を、いかに低コスト、高品質に作り上げるかがエンジニアの腕の見せ所でしょう。
つまり、先の通り、システムやS/Wの設計です。
この設計ってのが曲者です。
できるやつはできるし、ダメなやつはとことんダメ。
ただ、間違いなく言えるのは、できるやつは "圧倒的な努力" をしています。
めちゃくちゃ勉強しているし、得た理論や知識を実践している。
その上で、本や論文には書いていない、活きた学びを得ている。
ダメなやつは勉強をしていないから、何もない。
なので、差が出て当然。
あ、誤解を招くといけないので一応付け加えておくと、
やる前に勉強しろ/考えろ、と言いたいのではなく、とにかく何か行動しろよって言いたいのです。
成功でも失敗でもいいから、結果から学べよって言いたい。
例えば、よくいるダメな人。
「アジャイルやりたいわ〜。Scrumやりたいわ〜」
とか、わけのわからんことを言いつつも、
すごく偉い人はそもそも実現手段に興味がないので仕方ないとしても、
現場レベルでこれは無しだと思うなぁ。
時間は有限なので、知らないこはたくさんあります。
けど、やりたいことに対して、知ろうとしないことが罪ですね。
けどね、そういう人にも仕事をしてもらわないといけない時があるわけです。
日本の経済を立て直すために。
（話し、でかし！）
そのためには、ある程度の工学的な技が必要だと思うんです。
こういう考え方が、重厚長大なプロセスを作り上げる危険は重々承知しています。
なので、"ある程度"ってことと、プロセスじゃなくて "プラクティス化"ってのが大事なのかと思います。
XPなんかで言ってるペアプロとかは、ある程度工学的だと思う。
テストファーストやCI/CDもですね。
DDDなんかの手法も、１つでしょうね。
システムズエンジニアリングなんかも、どんどん進化しているみたいだし。
(次は井上さんに教えてもらったこれに関する本の所感にしよ。
英語の論文は、頑張って読んだけど難しすぎて理解追いつかずですw)
ソフトウェアエンジニアリングで培われた工学的な必殺技を使おうぜ！
ってのが言いたいことです。
で、ダメな人でも最低ラインをクリアできるように、
ツールでサポートできないかなぁってのが、言いたいのです。
先のモデルによる設計サーポートなんかのことを言っています。
あ、あと追加でもう一個。
この本にも書いていて、他の多くの企業ではきっとなされていないこと。
失敗しても、失敗から学ぶことができれば、成果として判断すること。
失敗のパターンを学ぶ。
失敗学。
失敗を責めちゃダメだよ。
チャレンジしにくいよ。
これができるから、きっとトヨタは開発を「止めれる」んだと思う。
だからチャレンジし続けられるんだと思う。
本に書いてあったけど、多くの企業は止めないから潰れちゃう。
「売れないものを作ることは犯罪」
最後に。
TPSはわかった。
みんなできるし、きっと出来ているだろう。
そろそろ本丸を攻めようぜ！
って感じですかね。
「分かってるし、みんなやってるよ！！この勉強不足が！！」
って声が聞こえてきそうですw
そういう場合は、そっと教えてください。
打たれ弱いので。
「この本とこの論文を読むと良いよ」
ってな感じで。
そもそも、ブログを書くことがほぼ初めてなので、
この記事を誰かが読んでくれるのかもわからないけどw
この本を読んで、色々昔のことを思い出しました。
本当に懐かしくなって、こんな長文になってしまいましたw
トヨタの技術本館やテストコース、駐車場、地名など、景色が思い浮かぶだけに、とても懐かしく感じました。
ちなみに、かんばんについては最近出たこの本を読みました。
たまに日本語が難しかったのですが、良い感じでしたよ。
特に、入門編の方にはとっつきやすいかも。
ぜひぜひ。
