チーム開発に関するオーバーヘッドの話

私は普段通常はデザインを除き一人で開発作業を行っています。

今回久しぶりにチーム開発をせざるを得なくなりました。結論非常に開発がかったるい。つらいです。この際だし何がかったるいのかということを言語化しておこうと思います。

一人開発しているときのスタンス

早く出す

基本的に一人開発を行うときは私はフロントエンドなどのエンドユーザが触れる点以外に関しては、ある程度の設計思想が固まっていたらそのままリリース作業を行います。

実際にリリース作業をして、ビジネスサイドが発展するとドメインが自動的に踏み固められていきます。ソースコードのリファクタリングや最適化などの作業はその際に行えばいいと考えています。

あとは大前提として早く提供していく方がビジネス的な価値が高いからです。特に私はスタートアップで0から立ち上げを行うことが多いのでなおさら。

またその際の匙加減は我ながら結構うまくなっていると自負しております。

一般的に適当な実装を早期に出してしまうことで負の資産を抱えながら進むことになりキャパシティが爆発することもありますが、そうならない程度に適切に設計実装して拡張性のあるように実装できていると思います。

相手の意見はそのまま聞かない

これは現場が恵まれていることもありますが、基本的に相手の意見をそのまま聞きいれることはしません。ちなみにバックエンドとか相手に見えないところはこの話から除きます、そちら側はそもそも相手から意見されることもない領域なので。

例えばいつまでにこれができるとか、いま現状はこうなっているけど将来的には変わるとか。自分が思っていることは、きちんと説明して理解してもらいます。

でもそれに対して別に意固地になっているとかそういうことではなくて、相手が達成したい目的を理解して、それに対して自分なりに最短ルートで達成できる方法を実現しようとしているだけなのです。

だから相手も結局理解してくれる事が多いです。というかこれが理解してくれなくなるとそもそも仕事をするのが辛くなってくるかな。

要するに主体性を持って作業することが好きなのだ私は。対してチーム開発ではどうかというと

チーム開発で望まれるもの

PullRequestは基本的に将来的にリファクタされることを想定していない

何を言っているんだ当たり前ではないか。と思われるかもしれませんが、正直長い間一人で作業をしていた私にとっては、あ、そういえばそうだったなという感覚でした。

例えばある列挙子を定義する際に、私の中では「今はそうなっているけどやっているうちに新しい概念が出てくるからそのときに追記するよ」くらいのメッセージ性を持って実装していたのですが、当然レビューアからすると「いや、それ今全部洗い出して列挙しておいてよ」という感じになりますよね。だってそのための要件に対するPullRequestになっているはずですし。

なので自然と本質とは離れた細かい指摘が多くなります。これが非常にストレス。

基本的に思考を言語化する必要がある

これまた当たり前ですよね。例えばコードレビューでやり取りする際に「あ、将来的に追記するつもりだけど、今はそうなっているよ」っていうのを言語化しないと相手に伝わらない。実態だけ見るとただの不十分な実装なわけですね。

これを全員と認識が一致するまでやり続けるわけです。そのうちやり取りコストが面倒くさくなり「将来的に追記する」から「言語化するの面倒だから今追記しとくか」みたいな、感じになってきます。ソースコードレビューの目的が「意思疎通を図って洗礼されたいいものを作る」から、「相手に承認をもらう」になってしまうのですね。

やはりとにかくチーム開発になるとオーバーヘッドがでかすぎる。開発するものにもよりますが、高いSLAが求められるものでなかったり規模が小さかったりするものはチーム開発のオーバーヘッドは単純にストレスでしかなくなるでしょう。

ちょっと新しい現場を探そうと思ってしまった今日このごろ。