先のどのブログの、トヨタと富士通の違いについて、
まず、カイゼンについての意識あわせ。
ここに出ている、トヨタ式のカイゼンの説明を基準に考える。
（このサイトにした理由について、別に深い意味はない。目に付いたから）
それは、こんなかんじ
・個々の仕事の中身を誰もが分かるように「標準化」した上で
・問題点のチェックと改善を繰り返し
・仕事の質の向上をはかる
・この手法で業務の無駄を徹底して排除する
→このムダを、トヨタは、７つあげている（ってとこまでの説明はないが）。
ふつう、カイゼンっていうと、こんな感じの説明で、いいと思う。
で、ここで問題なのは、トヨタは、車を作っている会社だってこと。
■■ 車を作ってる会社の場合
一般的に、車をつくるために、どういう作業が必要か、っていうのは、わかるんだとおもいます。工程間に矛盾はないんじゃあないでしょうか？だから社員が考えれば、今やっている作業が必要かどうかはわかる。＝標準化が可能な段階にきている。
■■ ソフト開発のばあい、
ソフトを開発するのに、どういう作業が必要かっていうことに、矛盾がきてしまっているのよ。
＝まだ標準化が可能な段階ではない。標準を決めるための戦略を考える段階。
その１つが、Ｏ／Ｒマッピングなんだけど、それを、単に、Ｏ／Ｒマッピングツールを使えば解決しますよ。っていうことに、「しちゃってるのよ！」
ソフト業界っていうのは、そういう業界なのね。ＣＲＭを行うにはＣＲＭソフトを導入すればできるのよ。ＥＲＰをするには、ＥＲＰソフトを導入すれば。。テストの品質を上げるにはJunitで、生産性をあげるにはXPやアジャイルなんでしょう。きっと。
で、そのソフトを導入すると、どう変わるのよ。。。？
Ｏ／Ｒマッピングの問題点は、なんで、ツールを導入すると、どうして解決しちゃうわけ？
まさか、クラスになって、オブジェクト指向にあうから・・とかいったら目からビーム！
オブジェクト指向とＤＯＡ的に行うＲＤＢ開発のどこにミスマッチ（インピーダンス）を生じて、それは、なぜ、このツールで解決するのかを説明しなきゃダメでしょ。
じつは、そうすると、ツール導入しても、これだけでは、解決しないはずなのよ。
で、それについては、長くなるので、今回は省略（気が向いたら、今度書く）
なんで、現実的にいうと、ある作業を行うことが、適切かどうか、その作業を積み重ねれば、本当にソフトができるかどうかは、わからない。
現在は、ある考えでいくと、システムを全部読みきった人が出てきて、その考えに従ってやるか、もしくは、だらだらーと開発して、だらだらーと時間をすごし、だらだらーの品質で、だらだらーっと終わるというかんじ（読みきってない場合、これでいい！という点が分からないので、こうなる）
なんで、今の段階では、適切な標準化の考え方が見出せない。
その証拠に、このブログのヒット数がある。テストのときの内容を示したとき、ものすごいヒット数だったんだけど、それは、テスト項目の出し方の標準化がないから、みんな、興味あってみてるんでしょ。もし、標準化できているものなら、そんなの、誰も見ないもん。
さらにもうひとつ。「仕事の中身を誰もが分かるように」というのは、そんだけ、仕様書を書き込まないといけない。
昔の仕様書は、こうだったんだけどね。
今の仕様書は、やる人によって違いが出る。というか、リファクタリングという名のもと、違うことをみとめている。
つまり、トヨタのカイゼン方式がいいのなら、
「仕事の中身を誰もが分かるように」標準化しないといけない。
しかし、今のＸＰなどの開発方法論を採用すると
できたものをリファクタリングする。
つまり、いろいろ手を加える余地はある。
一通りに標準化できない
っていうことになる。
はい！トヨタファンの、ＸＰ派のあなたが、ここでツッコミを入れるのが目に見えるので、先回りして言ってあげましょう。じゃあ、あなたのやりかたで、上司の人が、「ここのコーディング●●分」と、ぎりぎりの時間を指摘してきたとします。リファクタリングできますか。時間ないんですよ。
無駄を省くというのは、そこまでいっちゃいます。
動く、ぎりぎりのライン、かつ１通りの方法をやれる時間しかくれません。それがムダのカットです。その場合、リファクタリングの余地はないです。１通りの時間しかくれてませんから。
つまり、今の開発論っていうのは、ぎりぎりの時間でやることを想定していない。
むしろ、人生にゆとりをもっちゃってる。まちがっても、コーディングしてる隣で、ストップウォッチ片手に、時間を計ってるやつはいない（時間の目標や区切り、管理はあるよ。でも、ストップウォッチを持った人はいないでしょ）。
でも、カイゼンをかけると、ぎりぎりの時間でやることを求められる。ここで、問題が起こる（カンバン方式にも絡んでくるんで、この問題を、ちゃんと説明するのは難しかったりするので、今日は省略）。
さらに、誰にも分かるほど説明するとなると、膨大な仕様書を作成することになる。
その作成手順を下手間違うと（手作業でやったりすると）、死ぬほど大変になる。
今は、その項目抽出、仕様書作成、テストドライバ作成、テストデータ作成、ソースコード作成までの結構多くの部分が、自動生成されたり、何も考えずに機械的に作業できる（というのを、元請けは知らないかもしれんが）。
ただ、この手始めに行う雛形づくりは、結構試行錯誤だったりして、意外と標準化されない
（というより、標準時間を求められない。雛形をつくって、あ、このタグが必要ジャン！っていうことで、ソースに追加していく形なので）
これを全部手作業に置き換えれば、確かに標準化されるが、今度は、莫大な作業になる。
さらに、その機械化する手順をしらないと、品質も落ちる。
つーもんだいが、じつはあるのよ。。。
Ｐ．Ｓ そのうちさあ、自動生成も、自「働」生成（ニンベンのついた自働化）とか、書くようになるのかねえ（＾＾）ｖ
アクセス
トータル
ランキング
