ASAHIネット(http://www.asahi-net.or.jp)のjouwa/salonからホットコーナー(http://www.asahi-net.or.jp/~ki4s-nkmr/ )に転載したものから。
---
　九大に行ったとき、講義のあと、荒木先生に連れられて福田先生のところに
行って、
http://cl.is.kyushu-u.ac.jp/qito/wiki.cgi?page=FrontPage　
社会情報システム工学コース
でやってることをいろいろ見せてもらったり、ミーティングに参加させていた
だいた。
　実際にプロジェクトをチームでやっていくPBL(Project Based Learning)を
やっているので、その場所にも行ってきた。
　その場所の本棚には、いろいろ本が置いてあったが、UML関係は、
http://www.amazon.co.jp/exec/obidos/ASIN/4798107956/showshotcorne-22/
マーチン・ファウラー著, 羽生田栄一訳「UML モデリングのエッセンス 第3版」
があった。
　どの本も同じものが５冊ずつあった。５チーム作れるようになってるから。
　荒木先生もおっしゃっていたが、この本のいいところは、薄いこと。
　UMLはいま仕様がどんどんでかくなってて、おれなんか、細かい話は、もう
どうでもいいもんね。＼(^O^)／
http://www.amazon.co.jp/exec/obidos/ASIN/4274066630/showshotcorne-22/
Object Management Group著, 西原裕善訳「UML2.0仕様書 2.1対応」
をみると、900ページくらいありますね。
　エッセンスだけ、まず知りたい人は、ファウラー本もいいでしょうね。羽生
田さんの訳だし。
　おれは昔、
http://www.amazon.co.jp/exec/obidos/ASIN/4798105600/showshotcorne-22/
オージス総研著「かんたんUML[増補改訂版]」
の旧版でざっと勉強したような気がする。
　講義でも話したが、UMLとか、あるいはソフトウェア工学で出てくるどの方
法論でもそうなんだが、もっというとソフトウェアの方法論だけじゃなくて、
人生訓だってなんだって、咀嚼してエッセンスを血肉にするのが大事で、そこ
をはずすと、形式だけ追っちゃって、形式地獄、方法論地獄に陥りやすいの。
未読だが、
http://www.amazon.co.jp/exec/obidos/ASIN/4774129372/showshotcorne-22/
荒井玲子著「UMLは手段」
のタイトルは、おっしゃるとおりですね。
　講義でも話したことだが、昔、ある仕事でExcelで全部仕様書を書けという
のがあって、しかも、クラスの仕様を１クラス１ファイル、１メソッド１シー
トにしろなどというバカ臭い話。そんなのに付き合って手作業でやってちゃ、
時間も労力もかかって利益が出ないから、Javaで書いたソースのJavaDocコメ
ントから仕様だけ抜いてExcelのファイルを生成するプログラムを書いて納品
するなんてことをやったわけ。
　向こうのプロマネ、SEやプログラマは仕事は遅いし、ロクでもないものしか
作れない、端的にいえばバカ。そういうのに限って、形式だけ整えようとする
のね。生産性が上がらないはずだよね。
　でも、あるニッチを営業が握っているので食えてるんですよ。なるほどなあ
と思いましたね。

　荒木先生は、ファウラーが偉いのは、冒頭で、UMLはスケッチとして使うべ
きだといってることだと。この一節を読んで、この本は信用できると思ったそ
うだ。おれも同感。所詮、UMLなんてそんなもんだと思ってるし。
　ただ、スケッチがそのまま最終コードまできれいにつながる方がいいか、そ
れとも最終コードは別途きちんと書くべきかという話では、おれと荒木先生と
意見が分かれた。福田先生も２ウェイ(UMLとコードの双方向可能)でそのまま
行けるなら行けるほうがいいよねというほうだったが、おれ自身は、２ウェイ
は理想だけど、実はUMLごときで最終コードまで素直につながる気はあまりせ
んのよ。＼(^O^)／
　いまのUMLツールは、２ウェイといっても、コードからUMLを生成する方向は、
実装のほんとの細部は省略だし。
　じゃ、なんでスケッチがそのまま最終コードにつながるほうがいいと思って
いるのかといえば、Paul Grahamがいうように、Lispならスケッチから最終コ
ードまで素直に行けるよねという話で、これには荒木先生も、ああ、なるほど
などという話になった。
　Lisp屋にとってUMLなんてきっとどうでもいいんだよね。さっきの話じゃな
いけど、最後にLispコードから生成すればいいやくらいのもんでね。^^;

　UMLのモデリングツールは何を使っているか聞いたら、JUDEを使っているそ
うだ。
http://jude.change-vision.com/jude-web/index.html
JUDE
http://www.amazon.co.jp/exec/obidos/ASIN/489627220X/showshotcorne-22/
永嶋浩著「UMLモデリングツールJude竹で覚えるゼロからはじめるUML超入門」
なんて本もありますね。
　おれは、以前はEclipseのUMLを使ったりしたけど、NetBeansもいいなと思っ
てる。NetBeansは重たいのが難点だけどね。

　JUDEなどUMLのモデリングツールを使うと、当たり前だが、すいすい図は描
けるの。だが、その図が示す設計が適切なものかどうかは別問題。このことは、
荒木先生が強調なさっていた。
　で、おれが話題にしたのが、ジャズのアドリブ、インプロヴィゼーションの
話。講義の前夜飲んでいたのが、山下洋輔さんたちも来るお店だったからとい
うものあるけどね。
　ボストンのバークリー音楽院が、昔、ジャズのアドリブを体系化した。世に
いうバークリーメソッド。それまではジャズのアドリブは天才たちが作ってき
た感覚の世界か職人芸の世界。それがバークリーメソッドによって体系化され
たことで、こういうコード進行にはこういうスケール(音階)を想定してなどと、
教えることが簡単になったし、平均的なミュージシャンでもアドリブができる
ようになったと。でも、それといい音楽ができるようになったかは全く別の問
題。平均的なものは作れてもいいものが作れるかという問題ね。
　芸術と違って、工学は、平均的な人間が平均的なものが作れれば、まずはよ
し。特にソフトウェアの場合は、おれも含めて平均的SEやらプログラマのレベ
ルが低すぎるので(爆)、こういうメソッドができて、平均的なものなら作れる
ようになるのは、底上げになってそのこと自体はいいんだけど、その先はどう
かという問題ね。
　革新的なものが出そうな雰囲気ないでしょ。^^;
　GoogleやらAmazonみたいな会社が、社会保険庁の天下りが多くて累計１兆円
以上もらっているといわれて癒着が問題視されているNTTデータやらが使うよ
うな手法で、平均的なSEやプログラマにちんたら作らせてるわけないよなと思
うもんね。
　ただ、ソフトウェアは、耳目を集める革新的なものだけ作ればいいわけじゃ
ないことは、一応指摘しておこうね。公的部門が使うような地味なものも必要
とされてるからね。

　それから、いい方法論があって、標準化、パターン化されたら、ほんとに、
それで人を育てるかといえば、そうはならないと思ってる。
　標準化された手法で、平均的なSEやプログラマが働いて平均以上の品質のソ
フトウェアを作って、世の中に貢献するのがソフトウェア工場なんて議論が昔
からあるけど、おれには嘘にしか思えない。
　効率を考えたら、経営的にも技術的にも、標準化、パターン化されたものが
あれば、フレームワークを作ったり、生成系を作ったり、人を使わない自動化
の方向に進むほうが自然だもん。いままでもずっとそういう流れだし、Ruby
on Railsなど、フレームワークの流行もそういうこと。
　究極的には、ソフトウェア工場たるプラットフォームやフレームワークを作
れる連中だけがいればいいわけで、凡百のSEやプログラマはクビだってこと。
ファストフードみたいに学生バイトや主婦パートに、プラットフォームやフレ
ームワークを使わせる話になると思うのね。
　まだそうなってないのは、方法論や技術が未熟だし、業界は変化が激しいし
(これは社会の変化の激しさの影響)、いいフレームワークが出ても、すぐ、陳
腐化が始まるし、　そうなってなくても、というか、そうなってないほうが
(笑)、食えるからでしょうね。
　天下りさえ受け入れれば１兆円も金が流れて来る社会保険庁とNTTデータの
癒着をみてもわかるように、日本のソフトウェア産業は、技術革新をやるより、
個々の能力関係なく、人月いくらで凡百の連中をまとめ売りする派遣のほうが、
経営的には楽な状態がずっと続いてきたってことでしょ。
　ただ、これだと、個々の技術者には技術は身につかないし、派遣先の言いな
りでしかない以上、革新性なんて求めようがないもの。派遣が日本のソフトウ
ェア産業が腐った最大の原因といわれて久しいけれど、日本は経済大国だし、
税金や年金は垂れ流しだし、派遣に都合がいい構造に社会ができてたからね。
こういう慣性がいまだにずっと続いているんだと思うよ。きっと日本の財政破
綻、凋落が現実になるまで続くんだろうね。
　よって、海外に製品やサービスを輸出しようなんて発想が出てこない。どこ
までもドメスティック。パッケージソフトの時代にジャストシステムが海外展
開しようとしたのなんか、例外的だもん。いま、サービスの時代になってもド
メスティック指向は変わらないし、世間的には代表的IT企業の楽天でさえ海外
進出してないしね。その証拠に、楽天に日本語以外のページないもん。ハング
ル、中国語、アラビア語はおろか、英語文化圏向けのページすらないもんね。
　我田引水だけど、その点、アンテナハウスが偉いのは、ニッチながらXSL
Formatterという世界的な製品を作って、世界各国に売れていること。専門家
も世界最高峰といってくれてるしね。でも、日本じゃ、なかなか売れないんで
すよ。^^;
　何度か書いたけど、売れ方をみると、海外に比べて日本は遅れているなと思
うこと多いんだよね。要求される水準も質問のレベルも違うしね。

http://www.antenna.co.jp/XSL-FO/
XSL Formatter

　話を戻すと、いいプラットフォームやフレームワークを作れる、できる連中
は、前述のNTTデータなどが使いそうな方法論なんかきっと使わないんだよ。
＼(^O^)／
　天啓を得て、簡単なスケッチからばりばり書いちゃう。
　Lisp屋のやり方なんてまさにそうだもんね。昔のゲーム屋もそうだし(いま
のゲーム屋は知らないけど)、こういう人たちって、発想がソフトウェアに縛
られているわけでもないから、気に入らなきゃ、ハードウェアだって、プロセ
ッサだって作っちゃうもんね。

　おれらの時代とはすっかり違うと痛感したのが、本棚に、マネジメントの本
がずらりとあったこと。中でも、
http://www.amazon.co.jp/gp/search?index=blended&keywords=MBA+%83_%83C%83
%84%83%82%83%93%83h%8E%D0&tag=showshotcorne-22&__mk_ja_JP=%83J%83%5E%83J
%83i
や
http://book.diamond.co.jp/cgi-bin/d3olp114cg?isbn=4-478-97044-0
ダイヤモンド社のMBAシリーズ
に並んでいる、ダイヤモンド社のMBAシリーズは全冊５セットあって、ダイヤ
モンド社、ウハウハですね。＼(^O^)／
　講義でもいったんだけど、アーキテクチャ、アルゴリズムやデータ構造など
コンピュータサイエンスの部分はプロになるなら知ってて当たり前。それとプ
ロジェクトが成功するかどうか、お金がちゃんと取れるかどうかは別問題。科
学や工学になりにくいマネジメントの部分や人との付き合い方や人間的な信用
といった部分が大きいから。
　ソフトウェア開発の現場からは、大学はコンピュータサイエンスやソフトウ
ェア工学の理論面ばかりを教えていて実践的じゃないという批判がずっとあっ
たが、MBAのマネジメントの本がずらりと並んでいるのをみて、その批判に応
えているんだなと。少なくとも、そういう態度はみえる。＼(^O^)／
　でもね、長く使えるのは、言語理論にしろ、アルゴリズム論にしろ、理論面
なんだよ。特に数学に近い世界はほんと長持ちする。
　逆に、マネジメントなんてその場その場の一期一会ですもん。あのプロジェ
クトで使えたからといって今度のプロジェクトで使えるようなものって、小学
校の朝礼で校長先生が話すような非常に基本的な話か抽象度が高い話かメタな
話だけ。早寝早起きして、規則正しい生活をしましょうとか、コミュニケーシ
ョンを上手にとりましょうとか、人をよく観察してその人にあった育て方をし
ましょうとか、孫子の兵法とか、論語とか、禅問答とか、そういう世界。
　だから、下手に特定ケースにしか通用しないようなマネジメント本を読むく
らいなら、文学を読んだり美術を楽しんだり、哲学書や思想書を読んだり、禅
寺に修行に行ったり、多摩川の土手で寝たり、関門海峡を行き交う船をぼーっ
と見てるほうがいい。＼(^O^)／
　要は人間力、ヒューマンスキルというか総合力ですから。

http://www.amazon.co.jp/exec/obidos/ASIN/4822283135/showshotcorne-22/
伊藤健太郎著「プロマネはなぜチームを壊すのか 知っておきたいプロジェク
トのヒューマンスキル」
は、あったかなあ。