プログラマーは、もう時代遅れなのか
1990年代半ば、私は DB2 を中心とする IBM のリレーショナル・データベース製品の開発部門と緊密に連絡し合いながら仕事をしていた。アジア太平洋地区のプロダクトマネージャとして、シリコンバレー南部のサンタテレサ研究所には頻繁に出かけていた。
ヤニタ・マーさんという中国系女性で、DB2 の開発のキーパーソンのひとりがいた。サンタ・テレサ研究所勤務だった。IBM のメインフレーム MVS 上で稼働するRDBMS の DB2 は、何百人もの開発エンジニアではなく、数の限られた、たいへんに能力のある人たちによって開発されていた。ヤニタは、特にRDBの心臓部にあたる部分の 責任を持っていた。セカンド・レベル・マネージャといい、複数のファースト・ライン・マネージャを束ねていた。日本なら、部長レベルといっていい、と思 う。
大学は、UC バークレー校を卒業。MBAはサンタ・クララ大学で取っている。新しいスタッフが必要なときは、自分で UC バークレー校に行き、自分で面接して採用してきた。UC バークレーは1990年代まで、RDB などの研究でトップクラスだった。そこから、これはと思える学生（多くは博士課程）を直接ハンティングしてくるのだが、ヤニタが言うには、採用できるレベ ルの人は、年にひとり、いるかいないか、だったそうだ。
彼女自身が、極めて優秀なエンジニアで、PDA 用 OS の Palm OS 上に DB2 を移植するのに、彼女ひとりで、数ヶ月で作ってしまったぐらいだ。
IBM では、1960・1970年代から「チーフ・プログラマー・チーム」というシステム/アプリケーション開発手法があった。日本ではまったく広まらなかった手法なの で、詳細は省くが、基本はチーフ・プログラマーが、「神様・天才」であり、デザイン、ロジック、文書化、テストなどすべてをひとりで行う。シニア・プログ ラマーやジュニア・プログラマーが補佐し、必要な追加プログラムは彼らが書く。
別の方法論では、チーフ・プログラマーがやはりほとんどのコードを書き、バックアップ・プログラマーがやはり補佐をする。ツールスミス （Toolsmith）はチーフが必要とするツールを作成し、アドミニストレータがプログラミング以外の資源管理（お金、人、ものなど）を管理する。
そういった意味で、ヤニタが DB2 for Palm OS を開発したときは、彼女がチーフ・プログラマーだったのだ。彼女との会話の中で特徴的だったのは、彼女は、
「私は、エンジニアと呼ばれるより、プログラマーと呼ばれたい」
と言っていたことだ。いまだと、プログラマーより、エンジニアより、アーキテクトとかコンサルタントと呼ばれたいと思うだろう。1970年代から1980年代からにかけて、米国、特に IBM 内ではプログラマーというのは、たいへん尊敬される存在だった。
■■■
実はヤニタに会うずいぶん前、IBMの滋賀県野洲工場で情報開発部門にいるときに、私はこの「チーフ・プログラマー・チーム」方法を使って開発を行ったこ
とがある。あらゆるコンピュータ部品のための「部品表システム」である。メイン・ロジックのバッチプログラム38,000
行と、周辺の補助バッチジョブは私が書いた。オンライン側を、同じ課で私の一年下の後輩、J子さんに任せた。
そんなに小さなシステムではないが、要件定義を先輩が実施した後、ふたりで半年で部品表システムを造った。製造業の方は知っていると思うが、部品表システ ムはそんなに簡単ではないのである。しかも、コンピュータの部品の部品数は膨大である。通常なら、数十人体制かも知れない。
数十人もの人たちがプロジェクトに参加すると、コミュニケーションや情報をやり取りする労力に大変時間を費やされるが、チーフ・プログラマー・チームで は、その必要がない。ロジックのすみずみまで理解しているので、バグが少ない。要件と機能がピッタリ合う、などの利点がある。
欠点はリスクが大きい事だ。もしチーフ・プログラマーに能力がなければ、やる気がなければ、自己統制力がなければ、絶対成功しない。ほとんどの IT 部門のマネージメントは、そういった「リスク」を負うことをしない。そして、人数を集めて安心し、コミュニケーション不足となり、プログラマーへのなり手 不足の為にプログラムはオフショアに外注し、費用がかさみ、動かないシステムを作ってしまうのだ。
■■■
現在、この「チーフ・プログラマー・チーム」の対局の方法論がある。それが「オープン・ソース」だ。究極のオープン・ソースは、委員会のようなデザイン策
定の中心チームがあり、そのアウトプットを基に、コミッターとかコントリビュータと呼ばれる人がコードを書き、テストを行う。Apache
などが良い例だろう。Apache
には「メンバー」と呼ばれる中心人物と「コミッター」と呼ばれる貢献者がいる。ちなみにサンからは「メンバー」が6人、「コミッター」は100人以上が
Apache に協力している。
ただし、こういった委員会型（ファウンデーション型？）のソフトウェア開発が必ずしも正解かどうかは、わからない。Apache の脆弱性は、もっとなんとかならんか、と思うのだが、こういった開発方法なら仕方がないのかもしれない。
一番良いのは、きっと両者の良い所取りかもしれない。MySQL やJava、その他の弊社のソフトウェアのように、中心人物がいてコア部分はその人が作り、周辺をコントリビュータが開発するモデルだ。多くの能力ある人 たちの参加を得て、レベルを高くし、しかも、中心人物がいるので、製品がぶれない。いまのところ、これが良いのではないか、と思っている。
ひるがえって日本の現状だが、どちらの方向にも向かっていないように思える。「チーフ・プログラマー・チーム」も「オープン・ソース」も、当然、リスクを 負う必要があるので、どちらの開発方法もとっていない。どうも（なんか、以前も書いたが）、日本はリスクは回避するもの、と思っているフシがある。
いずれにせよ、日本ではプログラマーの存在価値、必然性が薄れてきているようだ。プログラミングの外注をやめて内製に切り替えることはすでに困難になってい るだろう。それは、なんか寂しい気がする。言語は、Java でも Ruby でも、Pythonでもいいけど、Webサービスなんかは、この「チーフ・プログラマー・チーム」で造ってみたら、面白いかもしれない。
チーフ・プログラマー・チームは、日本に浸透していないので、日本語の資料がない。Googleなどで、各自検索してみてください（英語ですが）。