ミニマムな開発チームの立ち上げ
会社を作ったりサービスを思いついたり、いろんなタイミングでシステム開発が始まり、開発チームが立ち上がります。
初期構築の時はなるべくコストを抑えつつ早く成果を出していく必要があるので
チームの運用もスタートアップならではの雑さ潔さとスピード感が出てきます。
ぼっち開発からふたり、3人と人数が増えてきて、チームが5人になるまでに気を付けている事を書き出していこうと思います。
ドキュメントを残す
gitのホスティングのwikiでも良いしGoogleドライブでも良いですが
開発チーム全員が見られるところにドキュメントを残しておかなければなりません。
知識の共有は個の力をチームの力に押し上げる鍵です。
その一瞬を面倒くさがるかどうかが、これからのチームにとって個々の力が足し算になるか掛け算になるかの分岐点になると心得ましょう。
そして最初にやるべき事は「どこにドキュメントを残すか」という事を明示することです。
プログラムを管理する
今ではほぼ必ずと言っていいほどgitを使っています。
ホスティングされている事も重要ですが、過去のログが追える、ソースの共有が容易である事はとても重要です。
スピード重視で過去のログを重要視しない事も多々ありますが
過去のソースにはこれからのロスを無くす教訓が詰まっていると思った方が良いです。
開発環境を作る
決して同じサーバーを複数の開発者で共有したりしてはいけないですし
各開発者が同様の環境で開発が出来なければなりません。
つまり「再現性のある開発環境を共有する」という事がとても重要です。
多くの場合、開発者は開発をするためにプロジェクトに入ってきているはずで
開発環境を構築するために入ってくるわけではありません。
そして優秀な開発環境は本番環境における環境依存の問題を起こさない事にもつながります。
ソースレビューをする
ソースレビューにおける目的は複数上がりますが
特に立ち上げ期におけるソースレビューでは「共通認識を作る」という事が重要です。
つまりdebugやtest、あら探しというネガティブな意味合いでのソースレビューではなく
「このプロジェクトにおける最適なソースとはどういう形か」という事を
チームの開発者の中で共有するための作業です。
レビューの結果が実際のプログラムコードとして積みあがってくれば
あとは踏襲して新しいプログラムを書いていく事である程度の品質が担保出来ると思います。
逆に品質の低いコードを使い続ける事はチームの存続をも危うくさせるのでよくよく気を付けた方が良いでしょう。
運用ルールを決めて周知する
いよいよチームとしてきちんと動き始めた時に
開発の運用ルールについてドキュメントにし、キックオフのミーティングをし、開発ルーティンとして実践していく必要があります。
定められたルーティンに則って運用されているチームに合流する事は、何もルールの無い集団に混ざって成果を出さないといけない事に比べるとさほど難しくないです。
もちろん運用ルールについても常に良い状態を保てるように、アップデートし続ける必要があると思います。
アップデートの基準についてもルール化されれば良いチームとして成長し続ける可能性がぐっと広がると思います。
まとめ
開発者が増加していくフェーズで、新しく入ってきた開発者がなるべく短期間に成果を出すためには
本人のポテンシャルに頼るのではなく、成果を出すことに注力できる環境をいかに早く作り上げるかにかかってくると思います。
「開発者を増やす必要がある」という事は、事業として開発力の増強が必要だという判断によるところのはずです。
新しい仲間が増える事に甘んじることなく、新しい仲間と共により大きな成果を目指せる環境を作る事が
先にいた者の務めかなと思ったりします。
要件定義や設計の話になると色んな思想が混じってきそうなので
今回は「開発者が最速で開発者として振る舞うのに必要な環境を整える」という部分にフォーカスして書き出してみました。
まだ他にも色々あると思いますが思い出したら追記したりとかすると思います。