ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記

20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。

日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。

プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数年前のやっていたし、別に昨日今日始まった話ではない。

にも関わらず、未だにテストは自動化されていないし、デバッグも実に場当たり的な方法でなされているし、ソースコードを読むことの重要性の理解も深くはされていない。

学校を卒業して最初に入ったDECには、エンジニアリングコミュニティがあった。プログラマが共有すべき価値観があった。先輩エンジニアが新卒のエンジニアにそれを伝授することに躊躇がなかった。デバッグの仕方を教え、テストの重要性を説き、それを自動化することを求めた。そしてそのような共通の価値観によって成立しているのがエンジニアコミュニティだった。

ベストプラクティスは社内で共有されていた。

ソースコードはソースコード管理システムで共有されているし、テストはテスト管理システムで管理され、ソースコードに変更があれば、モジュール管理システムでビルドされ、そして自動的にテストが実行される。入社一年生のわたしは見よう見まねでmakeファイルを書き、テストプログラムを書き、自動的にビルドが出きることを確認し、テストを夜中に流すように設定をしていた。

われわれのプロジェクトは総勢３名という小さなものであったが、コンピュータの処理能力が貧弱なので、３人で同時にビルドを始めるとエディターのカーソルが動かなくなるので、テストは夜中にバッチでやるのが常で、毎朝、昨日の変更とテスト結果を見るというリズムだった。チェックインしたコードの差分をメールで送付するので、他のメンバーがどのような変更をしたのかは毎日確認できた。

このようなリズムは、われわれのような小さなプロジェクトでも、数100人からなるVMSのような大きなプロジェクトでもほぼ同じようなものだった。

毎日のリグレッションテストが開発のリズムを作っていた。

そして、このような開発方法論はOracleでも同じであった。それぞれのプログラマは、Sunのワークステーション上に開発環境を構築し、日々の作業は、中央のリポジトリから当該コードをチェックアウトして、変更し、テストをして、問題がなければチェックインをする。テストを書いたり、自分のコードをレビューしてもらったり、時にはユーザドキュメントに変更を加えたりしながら、それを繰り返すのが日常の風景だ。

そしてそれが開発のAgility（速さ）を高めている。昨今言われるアジャイル開発のベストプラクティスの一つだ。当時そのような言葉はなかったが、テスト駆動開発的な方法論である。

コードを書いたらテストを書く。テストを書いて、コードを書く。テストをしていないコードは同僚からレビューのOKを貰えない。テストのないコードは特別な事情がない限りチェックインできない。そのような原理原則は皆が共同で大規模なソフトウェアを製作するために必要なものだという価値観を共有している。

もちろん経験の浅いプログラマが、チームに入ってきて、そのようなコミュニティの価値観を知らないで、テストもなしにチェックインすることがある。

そして、ビルドを出来なくして、多大な迷惑をチームの人たちに与え、同僚から叱責され、学んで行く。

先輩エンジニアは、新米エンジニアになぜチェックインをする前にテストを流すのか、新しいコードを書いたらテストを書かなくていけないかをわかりやすく説明する。それがルールとかそのように決まっているから四の五の言わずに守れというような説明の仕方ではなく、なぜ、それを守ることが皆のためになるのかを説明する。

共通の価値観を持つことがコミュニティの必要条件だとすると、そこにはプログラマのコミュニティがある。

素人はその価値観を知らないから素人なのである。プロフェッショナルはそれを理解し自分のものにし、日々意識することなく行動できる。

新米エンジニアが頭では理解できても（もちろんバカではない）、この1行の追加くらいならテストなしでもチェックインしてしまえ、などと思い、テストなしでチェックインしたりするので、先輩から叱責されるのである。知っていても実践できない。

チームには鬼軍曹みたいな人がいて、そーゆー人が新米を鍛え上げるのであるが、コミュニティには新米を訓練して一人前にする役割というか機能がある。

オープンソースはそれが地球規模で行われている例である。世界中のベストプラクティスが緩い形で共有されている。

コードを書いたらテストを書いて実行するという、あまりに単純な原理原則ですら実行するのは難しい。理屈で分かっていること、知っていることと出きることには雲泥の差があることをプロフェッショナルは理解している。新米にそれを伝えることがプロフェッショナルの仕事である。

ロートルはロートルとして伝えなければいけない原理原則がまだまだあるなあと思う。

しつこく出きるまで訓練する。トレーニングを重ねる。そーゆーことを一つ一つ積み重ね、一人一人がプロフェッショナルになるような環境を提供する。やるべきことはまだまだある。

会社にそのようなコミュニティを作るのがわたしの仕事だと最近思っている。