Programmers Office

一気に読みました～ 前編では、三次元CADと光造型システムによる自動化がインクス流の本質かと思ったのですが、本質は、それを金型について行ったことでした。作るもののデザインと金型のデザインは別物で、金型のデザインから作成を自動化できないと大量生産につながらないというわけです。しかも、金型を高速で作ることで1分1金型を実現することが目標と言っています。すなわち、1分に1品種です。 モノを買う時に価格を考慮しない位に価格を下げるとブランドのような文化に価値を見いだすことになる。一方、瞬時に意思の伝達ができるようになったら、例えば画面をデザインしているはしからバックグラウンドで設計が自動的にできるようになったら、消費者も製品開発に関与できるようになる。BTOというレベルではありません。インクスはそういう世界を目指しているようです。 もっとも、消費者はiPod nanoは生み出せないと思います。それを生み出すということが設計者として私のやりたいことです。そのための時間を生み出すために、生産時間を短縮したいわけです。 ところで、こうなるとルーチンワークをする人は不要になり、その場合に彼らはより想像的な仕事ができるようになるということが言われます。この本の中にもありました。本当にそうかというと、ちょっとどうかなという気はします。はじき出されないように、常に準備は必要なのだろうと思います。 本当に熱い本でした。頑張らねば！！

今日の朝日新聞のbe on Saturdayで「インクス流」の著者、山田眞次郎さんが紹介されています。 ちょうど昨日まで読んでいた本を読み終わったので、「旬に遅れないように」積んであった中から順番を変えて、今日から「インクス流」を読むことにしました。 山田さんが三井金属時代にデトロイトで仕事をしている際、日米の時差を生かして交代24時間制を敷き、通常4日ほどかかる設計変更を金曜夕方の打ち合わせ後月曜朝に完成させるようなことをしていたというようなエピソードから始まっていきます。これは私も時々思います。昼開発して夜テストにすれば時間の無駄がないのにな、と・・・。 金型で大量生産するような製品の開発は、設計者が図面を描き、図面から試作職人が試作品を作り、金型職人が金型を作るそうです。このくだりでは、「設計の描いたいいかげんな紙の図面をもとに（設計者の方は誰でもこのことを自覚しているはずである）、試作や金型を作ってくれる世界一の職人さんが・・・」とあります。そしてこれを24ヶ月で20回行ったそうですが、これはXP祭りのEXPの話にあった試作工程でのXPを思わせます。とにかくフィードバックを繰り返してレベルアップさせていかないと本当に納得のいく製品はできないのだろうなと思います。で、紙の図面は所詮内部の意思連携のためのものだから力の入れ加減には相応の差があるのだろうなと思いました。結局紙の図面を不要にすることがインクス流になっていくわけですし。 さて、山田さんは最初三井金属で三次元CADを立ち上げたときは1年かかったそうですが、クライスラーではそれを3ヶ月で行ったそうです。その違いの一つとして設計者の役割の違いを挙げています。アメリカでは、設計者と、図面を書くドラフトマンは別で、ドラフトマンは必要とされる図面をかけなければ職を失うので、三次元に切り替えると言われたら必死でそれを習得しなければなりません。それに対して、日本の設計者は構想も練り、技術計算もし、打ち合わせも行い、図面も描くので、面倒くさい新技術を習得するよりもやり慣れた図面で仕事をしようとしてしまう、ということです。なるほど、そういう面はあるかもしれませんし、外部の契機というのは必要かもしれません。ただ、なおさら思うのはオープンソース等で自分の意思で改革をしようとする人たちがいるというのはすごいことだなと。 今日読んだ中では最後ですが、モノの売れ方の変化について書かれています。携帯にしろ、プレステにしろ、今年だったらiPodでしょうけど、モノが売れていないわけではなくて、ただ、商品のライフサイクルが短くなっている、携帯も車も半年たったら売れなくなってしまうという世界になっているということです。 すなわち「旬の瞬間、人がまだ持っていないモノ」でないといけないということです。 で、自分の仕事について。 例えば、今、超短納期、と言っても1ヶ月ですが、グループウェアのカスタマイズをしています。しかし、私の気持ちの中では、本当は3日でやりたい仕事だなと思います。というのはそれはあまり本質的な仕事ではないから。そういう仕事はパッと終わらせて、「旬」を突いていきたいわけです。 例えば、ブログを商売にできているか、というと全然できていない。流行語に選ばれたらあとは沈静化していくだけだと思いますが、1年前にもっといろいろできたのにと思うと歯がゆいです。 本の中で、しばしばITは産業ではなくエンジンだ、という話が出てきますが、そのとおりで、一部例外を除いて多くのITシステム構築は他社の産業を推進するエンジンを作っているわけです。本当に推進できる仕事をしていきたいと思います。 インクス流!―驚異のプロセス・テクノロジーのすべて 山田 真次郎 おすすめ平均 ビジネスマンに薦める一冊 ”ものつくり”における新たな指針を示した良書 ”ものつくり”のまったく新しい指針を見出した良書 すごい本だ！ これこそ、日本のエクセレントカンパニー Amazonで詳しく見るby G-Tools

今発売中のpen12/15号は「公共のデザイン」特集です。 以前書いたオランダのダッチデザインも爆発しています。 北欧系の紹介が多いのですが、そういう土地柄なのでしょうか。 買ってきてまだ読んでいないので、軽くご紹介でした。

ザ・ゴールを読んでTOCに惹かれ、ザ・ゴール２、チェンジ・ザ・ルール！と読んできたわけですが、 ザ・ゴール ― 企業の究極の目的とは何か エリヤフ ゴールドラット 三本木 亮 by G-Tools <p> ぜひ、実践編を読みたいと思い、「制約理論(TOC)のインプリメンテーション」を読みました。 </p> <table border="0" cellpadding="5"> <tr> <td colspan="2"> <a href="http://www.amazon.co.jp/exec/obidos/ASIN/494762745X/konnokiyotaka-22/ref=nosim/" target="_blank">制約理論(TOC)のインプリメンテーション</a> </td> </tr> <tr> <td valign="top"> <a href="http://www.amazon.co.jp/exec/obidos/ASIN/494762745X/konnokiyotaka-22/ref=nosim/" target="_blank"><img src="https://i0.wp.com/images-jp.amazon.com/images/P/494762745X.09.MZZZZZZZ.jpg" border="0" alt="494762745X" data-recalc-dims="1" /></a> </td> <td valign="top"> <font size="-1">マーク・J. ウォッペル Mark J. Woeppel 小林 英三</p> <p> ラッセル社 2001-09<br /> 売り上げランキング : 258,886 </p> <p> </font><font size="-1"></font><font size="-1"><a href="http://www.

CruiseControl.NET 1.0 Final がリリースされています。 http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET RC2ではVSSのlogファイル参照に失敗するようなエラーが頻発していたのですが、それがなくなっているような気がします。

楽しみ～（謎）

先日のNUnitとJUnitの件の続きです。 Visual Studioで正規表現を使った置換ができるのはヘルプを見れば分かるのですが、慣れていないとなかなか使えないですね。 http://www.microsoft.com/japan/msdn/library/default.asp?url=https://jqinglong.github.io/programmers-office/japan/msdn/library/ja/vsintro7/html/vxgrfregularexpressionss.asp 例えば、次のような置換をしたい場合、 assertEquals(“3”, emp.getDeptno(), dept.getDeptno()); ↓ Assert.AreEqual(emp.getDeptno(), dept.getDeptno(), “3”); タグ付き正規表現を使います。 検索する文字列： assertEquals({&#8221;[1-9]&#8221;}, {.*}); 置換後の文字列： Assert.AreEqual(\2, \1); 「条件」をチェックして正規表現を選択して置換すると、見事にやってくれます。 やった！ {}で囲むと、そこにはタグが付いたことになり、\1～9で使うことができるという仕組みです。

http://www.ezaki-glico.net/officeglico/index.html こんなものがあるそうで。 お菓子にお悩みの方、いかが？？

出典を忘れてしまい、本当に申し訳ないのですが、ちょっと前に「分離したら結合する必要がある」という言葉に触れ、当たり前のようで実は深いなと感銘を受けていました。 さて、LINQです。 http://msdn.microsoft.com/netframework/future/linq/ http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp#linqprojec_topic2 を見れば一発だと思いますが、クエリがプログラム言語に統合されているというわけです。 9月のPDC2005（http://www.microsoft.com/japan/msdn/pdc/default.aspx）で紹介されたそうですが、それを伝え聞いて衝撃を受けました。これで文字列結合との戦いが終わるのかと。 しかし、今日ふと思ったのですが、SQLが何故ここまで使われているか、それは水平切り口でのドメイン特化言語だったからであり、プログラム言語とは分離していたからではないか、と。 おそらく、プログラミング作業の中で、業務ロジックを書いている時とSQLを書いている時では微妙に違う帽子をかぶっています。だから階層も分けます。しかし、それは結合される必要があり、多くの場合、業務ロジックを書くのもSQLを書くのも結合するのも同じ人がやるのではないかと思います。その結合方法が、実行するまでシンタックスが正しいかどうかすら分からない「文字列」ではあまりにも悲しいので、LINQに対する期待が起こるわけですが、これは言い方を変えると、業務ロジックに対する関心と、データ操作に対する関心が分離していたところを結合してくれる人が現れたことに対する喜びなのかと思うわけです。 ところが、この方法は割と強固な結合だと思います。 http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp#linqprojec_topic5 強固に結合するためにはこの程度のシンタックスしか定義できず、従来方式との併用になるのではないかと思われます。しかしそれは・・・と思ってしまいました。 まあ、登場はもう少し先の話なので、これから色々盛り上がるとよいなと思います。 （ちなみに、現時点ではやはりS2.DAOのSQLコメント方式が最高ではないかなと。）

高橋書店のリシェル３というのを買いました。 http://www.takahashishoten.co.jp/index.php?submit=note_det&goods_id=78 あまり手帳使うのは得意ではないのですが、バーティカルというのはよさそうです。 （というのは和田さんの日記で知りました） この手の手帳って、あまりカラーバリエーションないものですね。その中では緑のこれはよかったです。