実装リーダーという存在
ソフトウェア開発という作業は，（ウォーターフォールやイテレーションなどの単位は抜きにして）設計から実装という流れに沿って行われる。業務的な設計から，最終的にはコンピュータ語に翻訳し，ソフトウェアという成果物を作り出すための「プログラミング」という作業が必ず存在する。 近年，プログラミングを軽視している組織やプロジェクトが非常に目に付くようになった。 プログラミングという作業は，日々の経験と，それによって蓄積されるパターンをどれだけ多く持っているか，が鍵だ。「○○ということをしたければ，△△という記述をすれば良い」という成功パターンを多く持っていれば持っているほど，プログラミングは面白く，しかもスムーズになる。選択肢を多く持っていれば，適切かつ最短なコードを書ける確率が高くなる。最短なコードになればなるほど，その品質やバグの混入率は低くなる。 仕事や比較的規模の大きなOSS開発には，チーム開発がつきものである。チーム内のプログラマのスキルが，そのまま成果物の品質に直結するということは，至極当たり前の話だ。これは，どのようなプログラマでチームが構成されているかによって，実装工程以前に成果物の品質は決定してしまう，ということを意味している。 そう，作り出す前にはもう，プロジェクトの結果は見えているのだ。 ならば，スキルの高いプログラマでチームを構成することが，プロジェクト成功への近道であると言うことができるだろう。しかし多くの現場では，若いプログラマやオフショアなど単価の安いプログラマで構成されてしまう。 プログラミングは，まだまだ職人技の世界。全くもって簡単ではない。 もちろん若い人はプログラミングという修業を長い時間経験する必要がある。そして，そういった若いプログラマを牽引し，細かなレベルでプログラミングの旗振りを継続的にすることができる開発者が2，3人いるだけでも，最終的な品質は劇的に変化する。そう，実装リーダーが現場には絶対に必要なのだ。 実装リーダーが自ら大量のコードを記述する必要はなく，多くのプログラマの先頭に立って，常にサンプル的なコードを示したり，適用できるアルゴリズムを決定したりして，プログラマの迷いを解決する。そして，単体テストを継続的に指示することで，ボトムアップで品質を担保することをプログラマに植え付ける。さらには，合理的なコードとは何かを常に考え，恐れることなくリファクタリングを繰り返し指示していく。当然どのようなコードを書けば良いかは業務を知らなければ判断できないため，業務的な知識と理解を率先して蓄積し，プログラマに伝授していく。 このような実装リーダーの資質を持った開発者は，今日のソフトウェア業界では非常に限られるのではないだろうか。なぜなら，上記のような資質を持った人間が日本の企業で役割を変えることなく評価され続けることは少なく，多くの場合は対価アップのために実装を捨てて別の道を選ばざるを得なくなる。つまり，上流工程の設計者であったり，プロマネなどの管理者の道を歩くことになる。アーキテクトとしての道が開けることは稀であり，優秀な実装者はプログラミングという実力を最も発揮できる職を剥奪される。 これは，ソフトウェア技術者をプログラマ，設計者，マネージャ，テスターといった分類に分け，個人の実力を無視した分類に対する単価付け，すなわち人月というくくりで評価をすることに問題がある。そうなると，組織は優秀な技術者を高い人月で売り込むために，単価の高い分類に所属させたがるようになる。結局は初心者プログラマの集団ができあがり，品質を求めることはもはや不可能になってしまう。 プログラミングの現場は，アーキテクトでもなく，テスターでもなく，設計者でもなく，マネージャでもない，プログラミングという領域で実力を発揮することができる実装リーダーを求めているのだ。（あ，同じこと2回言ってしまった。。） XPの目的の一つに「プログラマの復権」というものがある。プログラマのみでプロジェクトを進めていくことを期待しているわけではない。しかし，高いスキルを持ったプログラマを数多く育てて，そして棟梁となり現場を仕切る，さらに棟梁を目指してプログラマが育ち・・・という好循環が今のソフトウェア業界には欠けている（Javaが 搭乗登場する以前はそんな循環がしっかり存在していたはず）。 人月文化を捨てて，ソフトウェア開発の重要なアクターを今一度見直して，正しい対価を定め直して，各人が最も実力を発揮できる場を提供する。そんな環境を手に入れるためには，まずは実装リーダーというポジションが当たり前のように組織に備わるようにならなければいけない。そして，このことを主張し続けていける人間も限られるはずなので，「あ，俺のことだ」と思った方は，自分の周りからでも啓蒙活動を開始して欲しい。 ・・・と，ANAの機内で考えてみた。
