プログラマの思索

「開発抽象化レイヤー」という記事があった。
興味深いので感想を書いてみる。

※「Joel on Software」という本で翻訳されている。

【1】開発抽象化レイヤとは何か？

ビジネス用のプログラムを書くと言う仕事は、単に技術力があればOKというものではない。

「プログラマの作業しているレベル(たとえばEmacsの上)というのは、ビジネスを支えるためにはあまりに抽象化されている」というフレーズがあり興味を引いた。

つまり、開発者のコードを製品へと変えるプロセスが必要なのだ、と。
Joelは歌手の仕事を喩えに用いている。
いわく、ドリー・パートンは「素敵な歌を歌う」レイヤで仕事しているが、彼女も膨大な実装レイヤを必要としている。レコードの制作、コンサートホールの予約、チケット販売、オーディオ装置の設置、レコードのプロモーション、ロイヤリティの回収。

プログラマの日々の活動(設計し、コードを書き、コードをチェックインし、デバッグし、といったこと)がソフトウェア製品を作り、マーケットへと届けるのに必要なすべてだという幻想を作り出すことにある、と。

プログラマの活動を支えるプロセスとは、

・静かなオフィス環境や無制限のお菓子と清涼飲料水を揃える管理人
・ネットワークとサーバー、ソース管理とビルド環境を当たり前のように使わせてくれるシステム管理者
・プログラマが見つけられないバグを見つけてくれるテスタ
・画面をカッコよい見栄えにしてくれるグラフィックデザイナ
・人々が製品を欲しくさせるマーケティングチーム
・人々が製品を確かに手に入れられるようにするセールスのチーム
・顧客が製品を使えるように助け、プログラマにはサポートへの電話の原因となっている問題を伝える忍耐強い聖者のようなテクニカルサポート

などが必要なのだ、と。
プログラマ1人に付き、7人ものサポート担当者が必要なのだ、と。

つまり、プログラミングをビジネスにする時、開発部隊と営業部隊だけでなく、運用保守部隊やデザイナ部隊、コンサル部隊などが必要で、それらがループになるようなプロセスになっていることが大事だ、と。

人月ビジネスの小さな会社では、このループ構造やプログラマをサポートする体制がそもそもない。
会社のネットワーク管理者はコストセンターだし、オフィスの環境を整えてくれる経理の女性もコストセンター。
そういう所までお金を回す余裕が無い。
だから、いつまで経っても、人材派遣ビジネスから脱出できない。

【2】ソフトウェアチームのプロジェクトリーダーの優先度第一の仕事は、開発抽象化レイヤを構築すること

プロジェクトリーダーの仕事は、プログラマの管理と思われているが、それだけではない。
むしろ、プログラマの生産性を高めるような環境作りが大切なのだ、と最近経験している。

「ソフトウェア企業の競争戦略」では、MSは、プログラマとテスターをペアで開発を進めている。
その利点は、プログラマがプログラミングそのものに注力できる環境にするために、テスターが品質チェックしたり、プログラマがやらない諸々の作業をサポートする点にある。

XPで初めてペアプロの概念が現れたが、その思想の原点はこういう所にあるのだと思う。

プロジェクトリーダーは小さな開発チームではビルド担当者になっていることが多い。
なぜなら、彼がシステムの品質の最終責任者だから、ビルドしたモジュールを自身で管理することが多くなる。
すると、彼の最優先の作業は、ソース管理とビルド環境の構築と運用ルールを決めることになる。

更に彼は、顧客と仕様を納期までに間に合うように調整したり、バグやトラブル対応も受け持つようになるだろう。

そのような役割をプロジェクトリーダーが受け持つようになると、プロジェクトリーダーが仕様を決める人、プログラマがその仕様に従って開発する人、という風に自然に役割分担できるようになる。

ソフトウェアビジネスでは、優れたプログラマを支える環境作りがモノを言う。