ここ1ヶ月くらいの私の不安を象徴するような出来事が今日起こった。ソースのバージョン管理方法を巡って、CVSとVSSで対立したのだ。私がCVSで、4人がVSS、2人が傍観であった（弱小ベンチャーなので外出者を除き社内全員）。私の不安は2つあって、1つはアピール下手でリーダーシップを発揮するのがまだまだな自分（それは重々承知で私の中長期目標なので話は飛ばす）。もう一つは、自分の会社の技術力は将来大丈夫?という不安だ。
誤解がないように書いておくが、うちの会社の技術力は世間一般的には高い方だと思う。実際に目にした日本の組織で、うちを超えるようなところには会ったことがない。しかし、ネットの世界と比べるとまだまだという意味だ。
ここ半年以上CVSを自分で触って覚え（というわけで私も大口を叩ける身分ではないが）、社内のみんなにも使ってもらおうと思った。しかし、既存のVSSに慣れた人（といってもここ半年ほどの話）にはなかなか理解されなかった。
自動パッチシステムであるCVSと自動ロックシステムであるVSSとは、見た目が同じでも思想は全く異なるので、どちらが優れているということは原理的に論じられないと思う。結局は、開発手法を含めたメタ議論や思想信条の問題になりがちだ。だからこの問題に正面からぶつかることは嫌だった。
ロックが必要な場合も理解できるので（でもそんな場合は開発手法から考え直した方がうまくいくと信じる）、利点欠点の議論なら良かったのだが、そうではない意見が主流だった。曰く、「VSSで満足しているのに新しいのは覚えたくない」「本なんか読みたくない」（いくら売り言葉に買い言葉とはいえ、私が一生口にすることはない言葉だ）。
私の理想としては、CVS導入に議論の余地などない、そんなご時世だと思う。優れた技術者がこれだけ採用しているのだから、少なくとも、どんなものか試してみようというものだ。
まあ、ここまでは予想の範囲だから我慢がまん。一番嫌だったのは、技術オタクが変わったこと言ってらぁという雰囲気を感じてしまったことかな。この日記の冒頭でも書いてある通り、私はビジネスプログラマが信条だ。すべては競争力をつけるために努力している（好きなことなので苦労しているとは思わないが）。その日々の鍛錬をオープンソースの技術オタクで片付けられると、嫌だね。
とはいっても、うちよりもビジネスセンスがあり、技術力もある組織を見たことないのが不思議だ。
感激しました。こんなに感銘を受けた本は、3年前学生時代最後の夏休みにGoFのデザインパターンを読んで以来です。最高級に属します。
ショックだったのはこの本が2000年5月に出版されていたこと（しかも翻訳）。私の技術力は周回遅れもいいとこです。
とっても恥ずかしいので書きたくないのですが、5ページの例をみて、私はどこが問題か分かりませんでした。綺麗なコードじゃないけれど、別に普通でしょと思いました。ハイ、私は大馬鹿者でした。
この本を読まないJava技術者がjavacした時は、コンパイラはwarningを出すべきです。絶対そうすべきです。
Ket Beckはほんとに凄い、偉い。気に入った言葉（うる覚え）「私は天才プログラマではない。天才的な習慣を身に付けたプログラマだ」
_ 今日の日記は濃いですね(笑)。まあ、あの本をゴールデンウィークに熟読したあとだけに、余計に今日の出来事が...。
がんばれ！！ゲイツ君を読んでいたら、Mozilla 1.0リリースを記念するMozilla dot Partryが、5月18日土曜日に御茶ノ水であるそうです。こういった技術者イベントは久しぶりなので、参加してみます。私はOpera使いなのですが(^^;。もし、私もいくという方はツッコミください。お会いしましょう。
# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
解説：broadcast addressにpingを投げると、受け取ったマシンが返答し、ping送信元は大量のパケットを処理しなければならない。その際、ping送信元IPを偽造することで、そのマシンにsmurf攻撃することが出来る。それを避けるためには、broadcastのpingを拒否するようにすればよい。それを決めるのが上記ファイルで、0が受諾、1が拒否。デフォルトは0なディストリビューションが多い。
# ifconfig eth0:0 xxx.xxx.xxx.xxx
ふぁいと。
おっ？んじゃ、１８日は二人別々のオフ会（？）に参加っつうことやね。ふふふ、いってらっしゃぁい。
公正を期すためにツッコんでおきます。<br><br>もちろんビジネスとして技術者を導いていくことを前提として述べます。まず今回の問題の総意としては，理解までの時間コスト，および操作の時間コストが随分かかるから拒否されたことは理解してますか？例えば「ここにCVSパッチがあります。これをお使いのVSSに充ててください。すると今まで使っていたVSSがCVSの機能を網羅するようになります」なんてものでもあれば議論にもならず，みんな喜んで導入したことでしょう。<br>＃性格が違いすぎるからそんなモノ作れないけど。<br><br>> 「VSSで満足しているのに新しいのは覚えたくない」「本なん<br>> か読みたくない」（いくら売り言葉に買い言葉とはいえ、私が<br>> 一生口にすることはない言葉だ）。<br><br>これも誤解でしょ？言葉の裏の真意を理解しなくちゃ。<br>「新しいのを覚える」「本を読む」コストはどこで捻出するんですか？ってことでしょ。まずVSSは覚える必要さえないほどインストールしてすぐ使えるというのは知ってますよね？チームの一人がデータ領域を定義するAdminになって最初だけそれをしたら（はんばあぐさんにやってもらったわけですが）後はほとんど野放しでもOK状態になり要するに管理コスト不要になります。<br><br>ご承知の通り，ビジネスとしての開発はタイムラインがあって，それぞれの機能別に個人を割り当てて工程管理するという業務が生まれ，客によってはこれが週一などにでも出てこないとダメということろもあります。どのソースの作成は誰，修正は誰というのも完全に決められて，ライブラリアンという一人の人間がロック管理していたんです。手法として単純なため，それをオートメーションしただけですからVSSは単純です。だからライブラリアンという人的リソースをまるっきり無くすことができたわけです。<br>で，CVSはもちろん「自由度が高い」ためこんな単純ロックよりも幅広いソース管理ができる・・・これは充分理解しています。<br>が，ライブラリアンは復活してしまうわけです。CVSは絶対に調停する人間を裂かないといけません。マージしたり，選択，棄却，再試験も行われなきゃいけない。１回で試験は終わっていたはずのものが数回必要になります。各プログラマに任せても結局管理業務が平たく分散されただけです。まず毎回「以前との差異を理解するために追う」作業が発生します。<br><br>オープンソースプロジェクトにコミットするのにCVSは必須ですし，使い慣れればCVSを使いつづけるでしょう。私自身も仕事ではなく個人でやっていることの範囲としては人のソースを修正して「こうするといいんじゃない？」って作者とやりとりしたり，その逆に拙作のソースに対して「ここはこうじゃないですか？」って修正したものがメールが来て自分が公開しているソースを最新に反映するなんてことがあります。こういった場合はやっぱりチームを組むんだったらCVSが向いているなぁと思います。<br>・１つのソースを多人数で触るケースが多い。<br>・１つのソースは１人が責任を持って担当する。<br>このどちらが「その時のケース」だったか。純粋な選択基準としては，そこにいきつくでしょう（＋その導入コスト）。企業内開発の場合，多くが後者のケースになります。だからケースが違うと言われただけのことです。<br>少なくとも<br>> 技術オタクが変わったこと言ってらぁという雰囲気<br>じゃないですって。<br>つーかすべからく社内全員が「技術オタク」じゃなきゃダメでしょう，うちの場合。貪欲に新しいソフトウェアの技術に興味を持てない技術オタクじゃない人には，勤まりません。<br>その「技術オタク」の興味がどういった技術に興味が行っているかの違いはあってもね。でも私が見つけた「痺れた技術」がはんばあぐさんにとって響かないことがあるのも事実でしょう。LinuxとJavaにリンクしていない技術ははんばあぐさんにとって興味の対象外になってるのは否めない事実でしょう？まあデファクトのCVSと比べるのは酷か。<br><br>「自由度が高い」ことと「開発効率が高い」ことが相反する場合が多々あります。そういった場合に，コストを考えたら企業として選択するべきは後者ですよ。コストが回収できるほどCVSが優れているとは思えないということが，はんばあぐさんのレクチャーの中から見出すことができなかった。ただそれだけのことでしょう。<br>「幾らでも出すから「究極に良いもの」をじっくり年月を重ねて作ってくれ」という案件は現実に存在しない。ただそれだけのことでしょう。<br><br>一般的なシステムで顧客が最も重要視するのはＵＩとデータです。あとはどんなアーキテクチャが採用されていようと２次的な要素です。なぜシステム化するかといえば「これまでと比べていかに効率よく業務が遂行できるか」が第一義目的でしょう。事細かいマニュアルが必要なシステムはオペレータの教育コストがかかるので，いかに分かりやすいＵＩにするかも設計の腕だったりします。その中には数値化できない人間が持つ感性に頼らせて理解を導くといった方法も多々あります。その集大成が現在のＧＵＩ文化でしょう。開発者サイドにも同じことが要求されます。１時間かけて戦力になるより１分で戦力になるほうが，優れた開発環境と言えるでしょう。<br><br>> とはいっても、うちよりもビジネスセンスがあり、技術力もあ<br>> る組織を見たことないのが不思議だ。<br><br>え？例えばＭＳという組織は見ているじゃないですか。<br>何が言いたいかわかります？組織でも個人でも現実世界に存在します。それを「ボランティア精神が強いかアピール心が強い個人」が多く見られるネット世界に浸って，それを尺度に物事を測るのはどうかなと思いますよってことね。あ，これは「ネット上には多いのに」という件りへのツッコミ。ネット上からそういったジャンルで探しているんだから優秀な内容が多く見えるのは当然でしょう。その数百倍は，全く技術に関連しないムダ情報もネット上にはあるわけで。技術に関して言えばあまり知らない人は内容が書けないわけで必然的に優秀でない内容はアップされないんじゃないかな。でも結局は世界人口からすれば「一部の優秀な人」なんですよ。その人が所属する企業の中でも一割方の優秀な人の中に埋もれているから，仕事上で付き合う人として出会うことも少ないんじゃないかな。優秀な人は皆独立しているわけじゃないし。逆にネット上でバンバン発言していない人でも優秀な人はいることははんばあぐさん自身充分理解しているでしょう。ダディとか。<br><br>で，結局CVSを試したけど「やっぱ手間だなぁ」という感想は変わらず。WinCVSでも手間。なまじVSS知っているからですが。機能が多くなればなるほどアプリケーションはいかにシンプルに操作ができるかを考えなくちゃならないんですよね。フィルタをかけて，裏方である程度オートマチックにして，必要に応じて小出しできるようにするのが優秀なアプリケーションだと思います。機能が全て前面に出ちゃうと使う方は混乱します。段階的に使用できるようにするのが望ましいです。例えばVSSはAdminはどんな領域をどこに確保したか，利用者は特に意識しなくていいわけじゃないですか。フィルタリングされていますよね。コンピューティングとはフィルタリングのことだとか，Linuxの格言かなんかでありましたが，使えば使うほど段階的に教育されていく，最初から一気に全てを語らない奥深さがあるといいなぁ。多くの優れた開発環境やフレームワークのようにね。<br><br>私がはんばあぐさんが浮いているなぁと思うのはコミニュケーション不足と，コミニュケーションから知識を得ようとしていないように見える点です。開発現場の伝統的手法を知らずして新しい手法の良さは響かないはず。ネット上の記事や本で得る知識は重要ですが，それ以上に現実の人間の経験談（まあピンキリですけど）から学ぶ手法もあります。<br>さっきのソース管理もなぜロックなのかといえば「人命に関わるシステムの開発」というのも世の中にはあるわけで厳重に管理しなきゃはじまりませんでした。そういったシステムを担当してきた技術者もいるわけです。あとUnixのCUIの世界でGUIものを開発しなければならなかった頃もあったり(Xなんてその商用特定メーカーもののLINUXマシンには無かった)，全くオープンでなかった各メーカー独自の技術しかなかった時代を知らないのもネックかな。伝送路（EarthNetより優れた機能を持っているものを知っています。結局クローズな世界で消えていったわけですが。）とかここで話しても誰にも伝わらない規格とかUnixマシンとか今でも名前と内容を言えますよ。メーカー関係者が見ると分かるので言いませんが。クローズソース全盛期の頃に技術でメシを喰わにゃならん頃もあったわけで。メーカーはそのマシンを売るのが使命だから，そのマシン専用のプロセス管理を行うミドルウェアなんてのもあったり帳票管理，画面管理などのミドルウェアもあったりして大変でした。独自だからその経験は生かされないところがまた辛い。<br><br>コンピュータシステムのトラブルが増えてきているように思いますが，これって枯れていない，流行り廃りの技術をどんどん導入していることも原因の一旦にあるのではないか。。。そんな一抹の不安も覚えている同僚より。