システム開発から属人性を排除しようとして失敗する

ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。

大手SIerは独自の重量級の開発プロセスを持つ。
それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。

その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。
その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。
つまり、属人性を排除しようとする。

だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。

彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。

現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い。
その間隔は短ければ1週間単位。
開発者からすると、永遠のベータバージョンのシステムを作っている感覚だ。
丁度、mixiやGoogleが生み出すサービスに似ている。

そんなビジネスでは、開発のスピードが最重要。
だから、重厚長大なドキュメントや運用ルールで開発者を縛るよりも、ある程度の規律の下では開発者の自由に任せることが多いだろう。
現場でも、プログラマに要求されるスキルは高くなっていると感じる。

実際、昔のように、部品単位でモジュールを作るスタイルではない。
水平なレイヤー単位の開発スタイルではなく、機能単位に垂直に開発するスタイル。
システムは、機能単位に漸進的にリリースしていく。
つまり、細かな機能単位でバージョンアップしていく。

一機能を作るための全てのモジュールを、プログラマが責任を持ってプログラミングする。
だから、プログラマは、DB層からコントローラー、Viewまでのプログラミング、そしてAjaxなど、多様な技術力が要求される。

だからこそ、開発者が力を発揮しやすいように、アーキテクチャの部分は全ての開発者が設計思想を共有するがそれ以外の部分は、全て任せることが多い。
そして、設計者やプロジェクトマネージャは、顧客と開発者のインターフェイスに当たる作業に徹する事が多い。
彼らは、要求を収集し、論理的整合性を計り、開発者へ仕様を渡す所までに徹する。

それは、XPに似た開発スタイルと言える。
最低限のコーディング規約は守るが、スピード感のある開発スタイルを守る。
そのために、コードの共同所有、常時結合できるビルド環境、イテレーション単位の機能リリースなどを行っている。

そして、そんな開発プロセスは、プログラマの技術力に大きく依存する。
属人性を排除するのとは逆なやり方。
だからこそ、プログラマが生き生きと働ける環境にするのが大事。

大手SIerのやり方は多分、時代にマッチしなくなっている。