掲示板のリニューアル

これまで長い間スパムの温床になっていた「ノブりんの掲示板」をリニューアルしました。以前使っていた「メッセージボード」は廃止になるのだそうです。ただ、新しい掲示板は投稿承認機能がないので、またスパムの温床になる可能性があります。そうなった場合は、削除する予定です。

なお、オプション設定の契約をしていないので書き込まれたことは90日で削除されます。

オプション設定の中に、投稿承認機能があれば良いのですが・・・無さそうです。なので、契約はしません。禁止IPなんてスパムにとってはほとんど意味の無い機能だと思います。旧メッセージボードには投稿承認機能があったのに、どうして継承されないんでしょう？ まさか、スパマーが困るからじゃないでしょうね(笑)。

パッケージ開発

パッケージ開発とはパッケージソフトを開発することではなく、パッケージソフトを担いで開発することを指す。簡単に言えば、顧客が要望するシステムに必要な機能を開発する（プログラムを作る）代わりに、市販のパッケージソフトが持つ機能を利用してシステムを作り上げることになる。しかし「パッケージソフトを担ぐ」とは、そんな生易しいものではない。

たとえば、顧客にC言語で100KLのスクラッチ開発に相当するシステムを要望されたが、求められている機能の90%は市販のパッケージソフトが持っているものであり、それに10KL程度のコードを追加すれば、顧客が求めているシステムが出来上がるとする。その場合、顧客が想定する開発費用はパッケージソフト代と10KLの開発費で済むことになる。仮にC言語による1ラインあたりの開発費を2000円として計算すると2億円になるが、パッケージソフトを使用した場合は、パッケージソフト代＋2000万円ということになる。ではパッケージソフト代はいくらになるのか？・・・しかし誰がどう考えたって、パッケージソフトに1億8000万円かかるとは思わないだろう。そして、顧客の金勘定にはパッケージソフトの代金は入っていても、システム全体の顧客要求仕様をまとめ上げる費用や、追加コードを開発するためにパッケージソフトが最低限どのような仕組みで動いているのかを調査する費用や、パッケージソフトの機能がホントに顧客の要求通りに動作するかどうかを検証する費用などは、ほとんど含まれていない。

世間一般の人がすぐに思い浮かべるパッケージソフトといえば、Windowsのようなオペレーティングシステムとか、Officeのような統合ソフトウェアだろう。これらであればせいぜい高くても10万円程度で購入出来る。当たり前の話だが、それらのソフトウェアを10万円そこそこで開発出来るわけではなく、価格設定は単価×予測販売数+αということになる。したがって、その計算方法は上記のパッケージソフト代にもそのまま当てはまる。WEBを検索してみれば分かるが、エンタープライズ系ソリューションパッケージソフトの値段を晒しているページなんてものはどこにもない。値段はすべて応談である。また、ソフトウェア会社がそのパッケージソフトを使って新たなソリューションを開発し販売する場合は、パッケージソフト会社との間にいろいろと複雑な契約が必要になる。

つまりパッケージソフトと言えども、しょせんは人間が汗水垂らして作ったものであり、多額の費用がかかっているということだ。だからパッケージソフトを開発する会社は、それを担いでソリューションを開発し販売するというソフトウェア会社から、そのパッケージソフトの開発にかかった費用を出来るだけ回収しようとするだろう。契約にもよるが、ソフトウェア会社のソリューションに要する機能が、仮にそのパッケージソフトの機能全体の半分であったとしても、パッケージソフトの開発会社はソフトウェア会社に対して全機能分の価格を要求することになる。「パッケージソフトを担ぐ」とはそういうことなのだ。

顧客の側にしても「パッケージソフトを使って、スクラッチ＆ビルドよりも安価にシステム化します」と聞いた途端、妙なパッケージソフトを買わされるんじゃないかと警戒する。高額なパッケージソフトであればなおさらだ。普通の顧客なら、そのパッケージソフトが持つ機能の何%の機能を使用するのか聞いてくるだろう。そして、パッケージソフト会社から個別にパッケージソフトの見積りを取った上で、ソフトウェア会社のソリューションがそのパッケージソフトの機能を100%使うのでない限り、そのパッケージソフトの代金を丸々払おうとはしないだろう。そうなると使われない機能の代金は、すべてソフトウェア会社の持ち出しになる。最悪の場合、ソフトウェア会社は、パッケージソフトの開発にかかった費用と、その後の維持管理費用を全部負わされることになりかねない。当然、その過程で多くの狡猾な駆け引きも展開される。

このように考えると、ソフトウェア会社にとってのパッケージ開発なんてものは儲かるような気がしないし、品質や性能が悪いパッケージソフトを担いでしまったら大変なことになる。社員1000人程度の会社なら、いとも簡単に吹き飛ぶだろう。

結局オブジェクト指向って何だったのか？

これはいまだによく分からない。もうかれこれ20年ほど開発に携わっていて、当初から注目すべき技術項目だとは思っているが、業務では一度もオブジェクト指向の言語でプログラムを作ったことが無いし、作りたいとも思わない。当然ながら、作ったことも作りたいとも思わないようなプログラミング言語で開発しろと言われても、管理不能だ。しかし、今後もずっと修得不可能かというと、決してそうは思わない。

とにかく、オブジェクト指向プログラミング言語の関連図書を斜め読みしていると、当たり前のことがいっぱい書いてある。オブジェクト指向以前と以後で何が違うのかと言えば、ほとんどは機能の部品化とその運用がスムーズに出来るかどうかといった点に集約されるだろう。そして、こんなものを作ってしまったためにソフトウェア業界は自滅の道を歩むことになってしまった(笑)。これはまさに原爆と同じである。しかもそれを作って、無料で配っている会社まである。

顧客サイドで考えてみれば・・・たとえば、C言語で100KLのプログラムをスクラッチ開発する場合、Javaで作れば20KLになるなんて話を前後の脈絡無しに聞いてしまったら、誰だって開発費用は1/5で済むと思うだろう。これをC言語で100KL作るのと同じ金額で見積り提示したって、相手にされないことは目に見えている。まして頭の硬いおエライさん方なら、ピュアJavaで、スクラッチで作って20KLなら、実質作るのはその半分も無いだろう？くらいのことを言いかねない。かくして、100KLのプログラムを今までの1/10の工数で開発する羽目になり、デスマーチプロジェクトが開始されるわけだ。

こんな開発をウォーターフォールで仕様検討からやっていたら、納期を過ぎても要求仕様すらフィックスしないだろう。つまり、コーディングするプログラムの量と、全体の開発工数が比例すると考えているような顧客なら、上記のようなことを真顔で言ってくる。そして、開発が途中でヤバくなってくると、頼んだ会社が悪かったと思うのだろう。

さすがに2007年の現時点に至っても、上記のようなことを言っている顧客は少ないのだろうが、それでも10年前に比べたら格段に高い生産性を要求されていることだけは間違いない。大手の製造メーカはこのような事態に対して、ソフトウェア開発だけで採算をとろうなんてことは考えなくなった。おそらく、ハードウェアや運用にかかる費用の中にソフトウェアの開発費を潜り込ませて回収しようとするのであろう。むかしあった1円入札はその極端な例だ。もう、ソフトウェア開発だけやって儲けようなんて考えている会社はほとんど無いような気がする。

まさに覆水盆に帰らず・・・こうなってしまった以上どうしようもないが、それでも受託開発だけで利益率10%を目標に掲げる会社もある。それを遂行するための秘策とはいったい何なのか。私には想像も出来ない(笑)。

出来ない理由を考えてもしょうがない！

これは技術者に対するかなり強力な殺し文句。こんな絶対服従を強要するような言葉が飛び出したらヤバイと思った方が良い。当然、こんなことを言われるとリスク分析をする気がなくなる。「やりゃ良いんでしょ？」という気分になるだけ。つまり「俺が全責任を負うからやれ！」というふうに解釈したくなる。でも実際に言った本人にそういう意識は無いことが多い(笑)。

もうイマドキの開発はリスクが大きいかどうかは問題では無い。解決不能なリスクは顧客と調整するしかないのだ。あとは個々のリスクに対する対処が生産性をどの程度スポイルするかで、快適な仕事になるか、憂鬱な仕事になるかが決まる。

そして妙な技術やスキルを持っている奴は、リスクの大きい作業に回されるのが常だ。なぜかというと、そういう奴を楽な作業に回すと遊んでばかりいて、持っている能力を仕事に対して発揮しないことが目に見えているからだ。逆に言えば、そうだからこそそういう妙な技術やスキルを持つに至ったのだと組織は考えている。

プログラマにとって技術は生きる糧だが、組織にとってはそうではない。業務遂行に不要な技術は邪魔になるだけ・・・気にしてもしょうがないような、解決の無い、余計なリスク項目が増えるだけ。そして、後で何か重篤な問題が発生すると、当初は聞く耳持たなかったにもかかわらず「どうしてそれを最初に言わなかった！」と責めてくる。ひょっとしたら、最近起きている食品業界の不祥事？は、こういった組織の傲慢が原因なのかもしれない。

最近のCPUについて

私が今居る職場は客先で、ここではみんな割りと贅沢なPC環境を使っている。ほとんどの人は1台のPCに2台のモニタをつないでいるようだ。私はここの職場では他所者扱いなので、そんな贅沢なPCは使わせてもらえない。というか、昔からこの業界ではPCの使い方を知らない人ほど贅沢な環境を欲しがる傾向がある。私に貸与されているPCはペン4-2GHzの古いデスクトップPCで、液晶モニタは15インチくらいのXGAだ。他の人たちに比べると2世代くらい前のPCである。ただ、プログラムをガンガン作っている開発担当に「必要ならいくらでも性能の良いPCを与える」なんて言おうものなら、お金がいくらあっても足りなくなるので、誰もそんなことは言わない。

そう思っているところへ、数日前にCore 2 Duo搭載の新しいPCがドサッとたくさん納品されてきた。新品のモニタを2台注文した人も居るらしい。そういうPCを何に使うのかといえば、メールの読み書きとOfficeドキュメントの作成がメインである。大抵の人は片方のモニタにメーラ、他方のモニタにワードやエクセルのウインドウを大きく開いている。そんなことにCore 2 Duoやマルチモニタが必要なのかどうかはよく分からない。

まあ、そんなクダラナイ話は置いといて・・・本題に入る(笑)。

冗長構成の話の中で少し書いたが、すでに最近のPCアーキテクチャは破綻している。CPUはマルチコアでもハイパースレッディングでも何でも良いが、とにかくCPUの演算がいくら高速になっても、メモリやバスは旧態依然のままだ。この問題は何も今に始まったわけじゃなくて、SUNがSPARC搭載のワークステーションを出すたびに、性能の倍々ゲームをやっていた頃からある。それからもう10年以上も経っているのに、何ら画期的な方式が登場していない。

少なくとも、OSくらいはCPU上のキャッシュメモリにすべて読み込んで専用コアが実行する、その他のアプリケーションもメインに使用するものは、それぞれ専用コアとペアのキャシュメモリ上ですべて処理する・・・というくらいは既にやっていてもおかしくないのではないか。

要するに・・・そろそろコンピュータのアーキテクチャを根本的に見直した方が良いと思う。そして、既存のソフトウェアはすべて使用不可にする。そうすれば、またスクラッチ開発のオンパレードになって、ソフトウェア業界が潤うのだ。それにJavaみたいな発想でプログラムを作ろうとしてもロクなものは出来ないということを証明するような、画期的な方式が出てくればなお良い。

いずれにしてもマシンの特性を無視した開発が多過ぎる。WEBサーバだろうが通信サーバだろうが何でも同じ発想で作るから、どっかの通信会社みたいに大問題を引き起こす(笑)。結局、客がバカなら開発する方もバカにならざるを得ない・・・極端なことを言えば、通信ソフトにWEBページ制作と同レベルの生産性を求めようとするから問題になるのだが、最近ではもうそんなことは分かりきっていて、確信犯的にやっているケースがほとんどである。とくに通信会社は投資の回収において、長い目で見ると結局どっちが安いのか（ストーリー）で判断するのだ。

こういう状況では、きっと開発なんて仕事は面白くも何ともない。明らかに技術的なことよりもビジネス論理が優先している。毎日会社に行ってやることといったら、検討資料を書く、打ち合わせをする、議事録を書く、設計書を書く、プログラムを書く、プログラムを試験する・・・といったことを決められたスケジュールの中で他ごとを考える暇もなく機械的にやるだけ。給料は他の業界よりも多少高いかもしれないが、ベルトコンベアの横で流れてくる弁当箱にオカズを詰める作業とそれほど変わらない。自分のやっていることに何の疑問も抱くことはないし、そんな暇もない。時間が来たらすぐに退社させられる。何の夢もない業界になってしまった(笑)。

決めつけるな？

これまでインタネット上でメーリングリストに参加したり、こうやってSNSに登録したりして、多くのいろんな人と語り合ってきたが、なぜか決めつけるような言い方をすると嫌がる人が多い（これ自体も決めつけか・・・？）。誰かが自分の意に沿わない発言をすると「それはあくまで貴方の意見ですよね？」と聞き返しているのをよく見かけるが、それは当たり前じゃないだろうか？仮りに何かを読んで知り得た他人の知見であったとしても、それそのもの、あるいはそれに基づいて何かを言えば、それはその人自身の意見ないしは認識になる。何かを偉そうに語った後で「イヤ、これは実はこれこれの受け売りです」なんていうのは後出しジャンケンと一緒である。

また、如何にも一般的、普遍的な話であっても、それをその人が自分の考えであるかのように発言したのであれば、それは当然その人の意見であり、その人はその意見に準ずる考え方や認識を持っていると思ってよい。日本語は便利なもので「・・・のような気がする」とか「・・・かもしれない」という言い回しでオブラートに包むことが出来るが、その人は場の空気を考えて、軟らかい表現をしているだけで、考えていることが曖昧なわけでは無い。

なぜこんなことをくどくど言うかというと、コミュニケーションとは何らかの「決めつけ」から始まるからだ。「・・・かもしれない」とか「・・・のような気がする」と書かれていたら、それを読んだ人はその話の意図が何なのか理解出来なくても、「そうかもしれませんねえ」と言うことが出来る。逆に「AはBである」というように断定的な言い方をすると、それを読んだ人は「自分と同じ認識だ」と言う人とそうじゃない人にはっきり分かれるし、それに対して自分の認識を述べることが出来る。

別に何か決めつけるようなことを発言したからといって、一生そのような認識でいるとは限らないし、認識が変わったのであればそれを表明すれば良い。誰だって、今の時点でそう考えているだけなんだから。とにかく決めつけるように言い切ってくれないと、コメントのしようがないのだ(笑)。

社内SNSって？

最近はミクシィをはじめ、インタネット上のいろんなところでSNSが利用できるようになってきている。それならば、会社内でもSNSをやってみようじゃないか！という考えが出てきても、別に不思議では無い。自分が勤める会社でも2〜3ヵ月前から試行的にSNSが開設された。主な目的は開発技術／ノウハウなどの情報流通であり、社内で何か知りたいことや困っていることがあれば、お互いに助け合いましょう！という趣旨である。

結論を先に言うが、個人的にこういう形のSNSは上手く行かないと思っている。SNSとはコミュニケーション（遊び）の場であり、情報流通の場では無い。それにそもそも、数年前から本格的になった成果主義による評価と、社員同士の助け合いなんて、真向から矛盾するような気がする。隣席の社員と競争させておいて、でも「困っていたら助けてあげようね」なんて、口では何とでも言えるかもしれないが、ホントに心底困っている人のために何かしようと思えるものだろうか？・・・きっと困っている人のためというよりは、自分の成果のために情報提供するということになるのだろう。

上記は非常にネガティヴに思えるかもしれない。それは私がもともと職人的な職場に長く居たことによるものと思われる。職人の世界では自分の持っている技術を周囲に対して懇切丁寧に説明することはない。そう、技術とは習うものでは無く、盗むものと教えられている。これの意味は「お前は俺と全く同じようには出来ないはずだから、俺のやり方を見て自分なりにやってみろ」ということだと思っている。きっと非常に非合理的なやり方に見えるかもしれないが、職人とはそういう中で徐々に育っていく。

逆に最近の方法、とくにソフトウェア開発の世界では、技術的なことはすべて文書化されることになっている。これはある意味「職人的な」人を排除するかのような考え方だ。文書化出来ないようなものは（少なくとも組織にとって）管理すべき技術では無いということなのだろう。たとえば、ものすごくプログラムを作るのが得意で、生産性の高い、魔法使いのようなプログラマが居たとして、その人の技術レベルがホントに高いのであれば、そのノウハウを文書化して、周囲の人に横展開し、組織としてレベルアップすることが出来なければならない。そうなると、仮りにそれが出来なかった場合、その人が持っている技術や能力は全く評価されないことになる。組織のそういう方針が定着すると、社員は文書化出来ないような技術は誰も習得しなくなる。つまり技術や能力というのは管理するためにあるのであって、習得しなければならないという意識はどんどん無くなっていくであろう。

社内SNSに戻すと、上記のとおりノウハウというのは文書になっていなければならず、そうでなければSNS上で流通させることは出来ない。問題なのは組織の役に立つほどの技術なりノウハウなりを、忙しい業務中に書き込めるのか？という点だ。まるで一子相伝のような関係で仕事をしていても、なかなか伝わらないようなノウハウが、 SNSなどのツールを使えば上手く行くというのは、明らかにおかしい。組織としてはとりあえず目に見える対策をとらなければならないということでSNSをはじめたのであろう。それともうひとつは、メーリングリストなどと違って、SNS上ではノウハウの流通が行われているかどうかを観察することがかなり容易になるということなのだろう。

こういうような考え方は、技術やノウハウというものが職人にとって生きるための糧であるということを無視した、安易なやり方に思えてならないし、誰にでも実行可能なノウハウなんて気持ち悪くて仕方がない。きっと、そういうノウハウは誰も習得する気がしないし、すぐに忘れ去られる。誰だって文書化されているものを記憶したり習得したりしたいとは思わないだろう。

久しぶりのプログラム

今日はもうファイル転送処理のプログラムを作り終わってしまったので、ドキュメントを修正したり、試験項目を作成したりしていた。これはネムイ作業だ(笑)。ところが試験項目を作るために、処理条件のマトリックスを作っていたらバグを1件見つけてしまった・・・

会社でemacs-22.0.95.tar.gzをダウンロードしようとしているのだが、途中でエラーになってしまってなかなか出来ない。22.0.94までは月1回のペースだったのに、22.0.95は半月くらいで出てきた。22.0.94にバグが多かったからだろうか？機能的には何も変わらないと思うので、22.0.94でも何も問題ないのだが・・・逆に、自宅ではすでに22.0.95になっているがほとんど使わない。

会社のPCも出来れば、Windows＋Linuxの環境にしたいのだが、Linuxをインストールしてもオンラインによるアップデートやパッケージの追加が出来ない。そういうことがLinuxの普及を阻害しているように思える。アップデート先をring serverにすれば良いのかもしれないが・・・会社のLinuxマシンというと、購入媒体からインストールした、ものすごく古いRHELしかなくて、あんまり面白くない。まあCygwinを入れればLinuxの勉強くらいにはなると思っている人も多い。また会社でLinuxを普及させるにはインストール方法や、標準的な設定方法などをイヤというほど資料化しなければならない。当然使い方も考えないといけない。使い方なんて、使う本人が考えれば良いと思われるかもしれないが、会社とはそういうところだ。そういうのはすべて言い出しっぺの負担になるので、誰もそんなことをみんなの前では言わない(笑)。これはむかし会社にMacを普及させようとしたときもそうだった。

いつも思うのだが、ターゲットシステムのOSくらい、日頃から使用して慣れ親しんでいないと、いざと言うときに困るような気がする。皮肉なもので、日頃からイヤというほど使っているWindows上の開発というのはあんまりやったことが無い。それに毎日使っているからといって理解できているわけでもないのだ。実際にWindowsのシステムを開発しろと言われても分からないことだらけだ。

やっぱり、使って楽しい、作って楽しいというのはEmacsだけか(笑)。

結論の出ない打ち合わせ？

誰でも結論の出ない打ち合わせはイヤなものだ。2時間くらい打ち合わせして、何も結論が出ないとみんなイライラするし、時間の無駄だと思うのだろう。なんでそうなるのかというと、結論を持ち寄って打ち合わせに臨まないからだ(笑)。

たとえば何か問題があって、それの対処を審議するとしよう。その打ち合わせには、当然打ち合わせメンバが検討した対処案が出てこなければならない。そして、打ち合わせのポイントは、その対処を導き出すのに前提とすべき事項、前提と対処案に矛盾が無いことの2点である。それを議論出来ないようなら最初から打ち合わせを行なう意味は無いし、無理矢理やっても話が発散するだけだ。

しかし・・・こんな当たり前のことで悩んでしまうマネージャっていったい何？って思ってしまう(笑)。

Bashでファイル転送処理─その2

昨日懸念していた、大量コマンドの処理は上手くいくようだ。たとえば以下のような処理である。実験ではdirコマンドを100回実行してみた、

ftp -n XXX.XXX.XXX.XXX << EOF
user username passwd
passive
dir
dir
dir
dir
dir
dir
dir
dir
dir
dir
......
bye
EOF

ftpを連続で何度も起動するとおかしくなる(コネクションを拒否される)というのは、どうやらxinetdのinstances値によるものらしい。まあ以下のように書いて実行すればすぐに分かることだ。

function ftptest () {
ftp -n XXX.XXX.XXX.XXX << EOF
user username passwd
passive
dir
bye
EOF
}

while true; do ftptest; done

他に今回いろいろ試してみて、たとえば以下のようなやりかたは上手くいかないことが分かった。これは意外に誰でもやりそうな気がする。

AWK="awk '{ print $2 }'"

ls -l | $AWK

これは以下のように書くのと結果が違ってくる。まあ、こういったことは-xオプションを付けて実行すれば何が問題なのか分かるはずだ。

ls -l | awk '{ print $2 }'

試行錯誤の結果、スクリプトは完成した。まあ、きっとしばらくすると忘れて同じ間違いを繰り返しそうな気がする(笑)。