今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン

なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。

それらのフェーズを前期、中期、後期、運営期で考えみる。

初期段階

おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる)

選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。

使う予定のフレームワークにパッチを当てたり、GUI なら1,2画面作ったりする頃。活発にOSS活動がみられるのもこの初期段階の終わりの方だと思う。

開発中期

人が増えたり、現実的な問題に直面するたびに、多かれ少なかれ最初の設計が歪みだす。初期の思想が貫徹できないことを歯がゆく感じだす。理想が理想通りにならなかったり、試行錯誤している段階なので、この時期はアウトプットが減る。書かれるコードは業務ドメインに集中する。

テストフレームワークやアプローチが変更される可能性があるならこの時期で、(とはいってもデファクトがある言語も多いが)、初期よりもテスト周辺のアウトプットが増える印象がある。

このフェーズ以降は個別の技術というより、プロジェクトマネジメント的な概念が重要になるのだけど、初期設計がどれぐらいモジュラリティがあるかで、同時にいくつ並行作業できるか響いてくる。役割が交差しているとコンフリクトが多発して進捗に影響が出る。

技術的な挑戦ができるとしたらこの時期までで、これ以降は「何を残すか」っていう引き算になる。

開発後期

バグを生み出すカオスとの戦いになる。デッドラインが明示され、当初の仕様が幾分オミットされ、バグをトリアージし続ける。複雑さが加速し、プログラマはTwitterで叫びだす。

この時期、アウトプットというかそもそも体力や時間的な余裕がなかったりする。僕はもう職業柄こうなるのは諦めていて、年に2回ぐらいはヤマがやってくる覚悟はしている。もちろんできるだけ短く、ないならない方がいいけど。

この時期に会社やめるとめっちゃ恨まれるので気をつけた方がいい。

運営期

でかい会社のでかいプロジェクトだと、ここで知見を使ってカンファレンス開いてポストモーテムしたりする。 小さいのだと「〜を現場で使ってみた感想」から「〜(タイトル)の開発の知見」みたいなやつ。Web業界だと各種言語系のカンファレンスや大手主催の勉強会、ゲーム業界だとGDCやCEDECだったりするんだろうか。

スライドの形をとってることが多く、ちゃんと読むととても価値が高い資料が多いんだけど、ともすると観念的な話になったり、とらえどころがないのでスピーカーにも難しさがなんなのか表現できてなかったり、「なんとなくわかるんだけど実感はわかない」みたいな話が多い。

その裏で、「あいつあんな事言ってるけど現場は大変なんだよクソが！なんだこの糞コード」みたいな現場の感情もある。現場が摩耗しやすい。技術志向っぽい人は開発終わったこの時期に次のプロジェクトに移れずおもりを任されると転職するのよく見る。

メディアアート系や、売り切りコンシューマゲームとかだと、運営というフェーズは存在しない。ギリギリまで糞化したコードと致命的なバグがないギリギリの部分を攻めるのでヤマとしては大きい。

一段落ついたあと、時間があれば中核がミドルウェアとして切りだされて、次のプロジェクトで使うためのOSSになることもある。

何が言いたいか

今、ほとんどソロ作業の開発中期なんだけど、一人でやっても初期の思想を貫徹できなくて設計歪むのやっぱり仕方ないと思ったし、終わったらプロジェクトのポストモーテム(振り返り)はちゃんとした方がいい。そして良かったものは良いということと、戦場で生き残れなかった事物をアウトプットしてシェアしてほしい。

開発初期のアウトプットも助かるんだけど、末期の泥臭いが洗練された情報をもっと食べたいという話でした。