かの「がんばれゲイツ君」によるとＮＥＣでさえ、社内ではプログラムを作らないということになったそうです。では、ＮＥＣはハード専業メーカーになったのでしょうか。そんなことはないですよね。コンピュータネタ、目次へ
ということは、多分プログラムを外注に出しているんですよねえ。ＮＥＣにベンダーとしての役割を期待する人は、多分ＮＥＣだからということで信頼しているのでしょうが、実際にプログラミングをしてくれるのが、下請けのさらに下請けということを聞くといくらかは違和感を感じそうです。え、全然かまわない？なんかあってもＮＥＣが責任をとってくれるから？
で、ＮＥＣは下請けに文句を言い、そのさらに下請けが文句を言われ、、、いたたまれないでしょうなあ。実際にコードを書いているのは自分なのに、鞘は抜かれるのに文句だけは直結。まともな神経の持ち主だったら骨身を削ってまで品質を上げようとはしないでしょう。前にも申しましたようにこの業界、仕事以上の料金を請求するところはあっても、料金以上の仕事をするところはないそうですから。ただしうちの会社でも他の会社のことは言えません。全社がそうというわけではありませんが、私は仕事ではプログラミングをさせてもらっておりません。ツールを作れば簡単なのに、、、と思うことは多々ありますし、そのくらいなら書いてもいいよと思うプログラムも結構ありますが、そういう制度がないのです。多分組織としてサポートできないからでしょう。（そんなアクロバティックなプログラムを書いているわけではないのですが。OLEで350個のMS-Excelワークシートを連続して開き集計する程度です。Windows for MS-DOSだとだいたい100ファイル強で止まります。）
こんな風潮に風穴を開けるべく動いたことはあります。部の各人に貸与されているパソコンのハードディスクのプログラムファイル、スクリーンセーバー、壁紙用ビットマップを管理したいからと、リストアップ作業をするように言われたときです。
制定の手順では、Windowsのスタートメニューから検索を選んで、*.exe/*.scr/*.bmpを探させて、結果の画面キャプチャーをとりMS-Excelファイルに打ち込んでゆくというもの。これを数百人にやらせる。
とてもたまらんということで、簡単な検索プログラムを書き、社内掲示板に「ＯＬＥを使ったプログラミングの例」とかいうタイトルでさりげなくアップしました。案の定、社内ハードディスク内、特定拡張子ファイル管理担当者は食いついてくださり、検索手順を書き換えて私のプログラムを使うことになりました。しかし一つ計算違いがあったのですね。私には何の連絡もなく、部内に配布したのです。連絡があれば公式に自作ツールの作成と使用を認めていただけるなと期待していたのですが。その代わり、管理担当者が処理しやすいようにプログラムを書き換えるくらいのことはやらせていただくつもりでしたし、処理プログラムを書いてもいい。
しかし、それがなかったのです。ですから私は何一つ提出するよう要請されていません。つまり管理担当者の手元には、プログラムソースも仕様書も何もなし。私のハードディスクがクラッシュしたらどうするんだろうねえ。まあいずれにせよ担当者が二代も変われば、このプログラムが何なのか誰にも分からなくなることでしょう。改めて聞かれたら「ああ、フロッピー間違ってフォーマットしちゃいました」と答えても文句は言われないだろうなあ。末端のプログラマを軽く扱うとこんなことになるんだ。まあ飼ってもらってますから、ソースちょうだいと言われれば偉そうに渡してあげますが。（十分会社を稼がせているという自信はありますが。）同じ会社ですらこうだから、いじめられている下請けの実態は容易に想像できます。外注管理が重いので、正式には作ってますと申告していないが、実はツールでコチョコチョとやっている。でも、もちろんそんなものは納品しない。それともシステム構築の補助に社内ツールを使った場合に、そのツールも納品するようにという契約はありですか？
それは通常の運用では問題がおこらないでしょうが、なにかの拍子にシステムを再構築しなければならないとき、どうしようもならなくなる。決してあり得ない話ではないと思うのですが。でも、まあ百歩譲ってプログラムが動くんだからいいとしましょう。でもね、ＮＥＣのようなしっかりした組織にソフトウェアベンダーとして期待することは別にあるということは分かっておいていただきたい。つまり「Linuxは太らせて食え」でも書いたように組織でなければできないレベルのソフトウェアはあるということ。
換言すれば組織が持っているソフトウェア技術と個人のノウハウの集合体は次元が違うものということ。そしてこれがベンダーの存在意義だということ。Linuxのサポートに安心感を与えるために組織があるのではなく、Linuxでは実現不可能な機能を提供できるのが組織というものだということ。
ある間抜けなソフトベンダーと仕事をしたことがあって、例の懸案事項はどうなったと聞くと「社内掲示板で照会している」というお答え。その部署での私は応援という立場だったので黙っていたが、そうじゃないよと、個人ノウハウを流通させる場が会社組織ではないよと怒鳴るべきだったかな。
こことは、モデムによる通信機能を持ったアプリケーションを作っていた。海外との接続が多いのでこれがよく落ちる。こういう問題があったときでもベンダーが個人ノウハウの集合体しか持っていないとすると、こんな会話しかなりたたない。
この姿勢で安定通信が実現できたとしても、それは偶然である。
- 「通信がよく落ちるんだが」→「モデムの初期化コマンドをこう変えたら？」
- 「まだ落ちるんだけど」→「じゃあ初期化コマンドをこう変えてみて？」
私が聞きたいのは「LAPMを止めて（プロトコルを固定化して）、MNP4（ないしMNP10）で確実につなぐ方法」なのだ。その為の設定を教えてくれ、と言っているのである。それでも落ちたら回線事情の方がどうしようもないと判断してかまわないだろう。そういうレベルまで持ってゆきたいのだ。これが個人ノウハウの蓄積で問題を解決することと、組織的に問題を解決することとの違いなのだ。
何でも外注に出していると、このへんの問題解決の手法が分からなくなるよ、ということ。将来的に頼りにできなくなるよ、ということ。いい人材を集めてくるのに気を遣っている会社は多いだろう。
でも、大事なのは予め想定される問題解決の手法を体系的にまとめておくことだろう。そういえば変なもの作ったなあ。理路整然と問題を解決し、かつ解決策を上司に承認させるためのワークシート。冗談のつもりだったが、わりと機能する。この調子で「組織的ノウハウ蓄積ワークシート」でも作るかな。