プロジェクト反省文

Written on Sep 25, 2005. Posted in Java

まだ完全に離れるわけじゃないけど，やっぱり自分の周りからの使われ方は，1つのプロジェクトの初めから終わりまでベッタリというわけじゃないようになってきている。それはそれで「飽きっぽい」僕としては喜ばしいことなんだけど，同時に「責任を全うできてないのでは？」と感じてしまうのも事実だ。でも，仕方がない。仕事とは，そういうものだ。

というわけで，僕がいま携わっているプロジェクトはまだまだ終わらないけど，僕としての区切りがきたっぽいので，反省文でも書いてみようと思う。

まず，最初にプロジェクトに配属される直前に聞いていた役割は，「アーキテクト」だった。業務的な仕様検討とか，業務的な基本設計は他チームが行い，技術的なベースというか，実装のベース作りを行う役割って感じだ。なので，ベースが固まって実装が開始されれば，基本的にやることはなくなって，別のプロジェクトに移動になるかも，とも言われていた。

今思うと，その時点での「アーキテクト」という言葉の意味は，完全に勘違いしていたように思う。それこそ，フレームワーク的なものを作りさえすればいい，程度にしか思ってなかった。

結局は，ウォーターフォールで語られる「工程」で整理できるほどソフトウェア開発は簡単ではなく，「 EoDフレームワーク？」で書いたように，業務仕様を整理するための方法と，それを実装に落とし込むための方法を考え，ソフトウェア開発の実現性を確実なものにしていくことがアーキテクトの仕事なんだ，と今では理解している。僕は完全に勘違いしていた。

さて，時間が経つにつれて，プロマネやその他僕の雇い主がみんな口を揃えて言う言葉が，「実装は任せた！」だった。この言葉の意味も，最初は「丸投げかよ！」くらいにしか思ってなかったが，振り返ると「この世の終わりを思わせる言葉を言われていたなぁ」と思ってしまうような言葉だ。

プロマネやその他僕の雇い主が僕に期待していたこと，それは「実装に関する技術的なこと」だけでなく，「実装に関する管理」も合わせてのことだったんだと，ちょっと前にやっと気がついた。気がついたときには既に遅くて，実装作業も終盤になっていて，振り返ると僕がやってきたことは，

開発フレームワークの改良
機能の洗い出しと工数見積もり
機能の開発者への割り当てと，日々の進捗把握と組み替え
偉い人や顧客への進捗説明(言い訳とも言う)

というものだ。見てわかるとおり，プログラムに関する作業は，何とゼロ。業務がJavaで記述された実際のアプリケーションコードを目にすることはほとんどなかったのだ。

つまり，僕は「アーキテクト」だったのに，いつの間にか「開発リーダー」になってしまっていた。これは，「コモディティ化と人月への雑感」のコメントで議論になっているように，一般に見られる，まさに典型的なパターンに陥ってしまったことになる。

現場の開発者や，同じ立場で参加した別の(本物の)アーキテクトからは，全く違うことを求められていたはずで，それは僕も良くわかっていたけど，全くその期待に答えることはできなかった。現場は，記述されたコードが常に僕の目によって監視されることを期待し，それを安心感として持っていたかったはず。「これでいいんだ」という安心感を開発者に提供できなかったツケは，計り知れないものだと思う。きっと，そのツケは品質にモロに反映されている。

残念なことに，「20人以上の開発者を良く管理してくれた」と，偉い人からはお褒めの言葉を頂いている。僕のホントの使命は，開発者をまとめることがメインじゃなく，品質の高いソフトウェアを作り上げることだったんだ。それを「管理」という仕事に専念することで実質放棄してしまったことは，ホントに悔やんでも悔やみきれない「後悔」として残っている。開発の現場に同席した顧客や，PMを初めとする権力者の意見を優先せず，誰かに進捗管理を押し付けてでも，僕はフリーで動ける実装(監視)者になるべきだった。そうだったとしたら，今頃もっと良い品質だったのではないか，と思ってしまう。一番の反省点だ。

付け加えるとしたら，僕は「スーパーマン」じゃなかったってことになるのかな。もしスーパーマンなら，管理も実装も，一緒にうまくこなせたはずだから。

悪かったことばかり考えていても凹むだけなので，良かったことも考えてみたいのだが，やはり「上記のような反省ができたこと」が一番良かったことなんだと思う。これからのソフトウェア開発の手法の最適解に最も近いサンプルとしてこのプロジェクトを遂行できたはずで，何となくどこが悪かったかわからないまま納品を迎えた従来のやり方と違って，どこが良くてどこが悪かったのか，明確に言うことができる。開発フレームワークの反省点は詳細まで把握できてるし，プロジェクト全体の進め方や各人の役割分担，必要な人材と役職，そして開発者へのマインドコントロール(?)の仕方や実装方針の伝え方など，こと細かに良かった点と悪かった点を言うことができることは，今後の開発にどれも生かせるものばかりだ。しかも，その成果を反映すべくアクションを起こすことすら，始めようとできている。

今まで書いてきて，これを読んだ人は「品質の低いもの作っちゃったんだな」という印象を受けるかもしれないが，実際は逆で，他プロジェクトとの相対評価であれば，ダントツに品質は良い自信があるし，保守費用は従来よりもかなり抑えられているはずだ。ようは「理想的には，こうすれば良かったなぁ」という反省文として捉えて欲しい。

自分のプロジェクト内のポジションはどうあるべきか，それが社会人8年目にしてやっと見えてきている。次のプロジェクトはそれを踏まえて動いてみたい。また，ソフトウェア開発とはこういうものだ，という点も見えてきているし，それを業界に還元していけるかもしれないという「図々しい（ｗ」行動も起こせる環境ができつつある。つまり，仕事が今まで以上に楽しくなってきたってことだ。

まだ今のプロジェクトは終わっていないし，最後のスパイスもかけていない。仕上げ作業をきっちりとやって，みんなの満足を得たいと思う。