どうも、ぺやんぐ(@peyangu485)です。
この間、1か月で終わるプロジェクトのリーダーを任されたので、そのことについて書こうと思う。
初めてのリーダー
仕事内容はあまり詳しく話せないが、自分+新人3人でバッチプログラムの開発だった。
(ここでは明言していなかったが、プログラマとして働いている)
小規模ではあるが、初めての経験なのでちょうどいい難易度だと思った。 しかも、自分以外は新人だったし。
いよいよ、実装が始まるということで以下のことを実施した。
- 開発規約の周知をした(規約というほどガチガチではないが)
- 開発するバッチは複数あったが、だいたい流れが同じになるだろうと考えたので、どういった流れの実装をするのかを周知をした(各々でバラバラの実装になるのを防ぐため)
- 共通部分の洗い出し、新人が開発するときの参考にするために1つ目のバッチの開発をした
ざっと思い出せたのはこれぐらいかな。
あとは、適宜出てきた質問に回答、実装のフォローを行っていた。
その間で、共通部分の追加、修正やクラス構成の見直しをメンバー全員で実施していったって感じ。(みんな優秀だったので困りごとが起こることもなく……)
上記の3点について、少し詳しく書いてみる。
1点目について、
命名やクラス構成とその意図の説明を主に行っていたと思う。
人数的にも内容的にも文書として残す必要はなかったので、残してはいない。
2点目について、
()内にも書いているが、実装がバラバラになるのを防ぐために、分かりきった内容ではあったが、メンバー間で共有するようにした。
共有することによって、後半の実装スピードを上げることができるし、共通部分に抽出しやすい。
そのあたりを意識することをなんとなくでも分かってもらえれば彼らの今後にも役立つだろうし。(今後どっかで一緒に仕事するときに楽できるしｗ)
共通のゴールの設定という点でも共有して良かったと思っている。
3点目について、
これについては、初期段階で思いつく共通処理をさっさと抽出しておくことで、あとあとめんどくさいことになる確率を下げる。
バッチの開発については、「1つでもできていれば、あとはそれを真似るだけでだいたいの実装が完了する」という流れを作りたかったのと、「このプロジェクトではこんな感じで実装していくよ」っていう意思表示(?)をしておきたかったってところかな。(認識の共有)
まだ経験は浅いけど、いろんなところでコードを見てきて思ったのが、「共有」されているもののレベルの低さっていうのがあった。
コードにしてもそうだし、どういったシステムって部分や、どう使われていくのかって部分もあまり共有されていないように感じた。
コードに統一性がない感覚というか。
きっちりかっちり揃えろとまでは言わないけども、せめて思想は共有してそこに向かってほしいなと思った。
そのあたりを今回のプロジェクトで自分なりにできる範囲でやってみた。
その結果として、コードレビューは実施できなかったけど、ざっとコードを見てそれなりに共有できていたのかなという印象。
共有できていたのかなって思うエピソードとして、実装中に改善案とか提案が新人達から出てきたってのがある。
ただ、やみくもに実装していたら出にくいと思うんだよね。
ゴールが見えているからこそ出てきたのかなって好意的な解釈をしている。(こっちの考慮不足とか言わない)
プロジェクト的には、納期が1週間前倒しされるというハプニングが起こりつつも無事に終わった。
反省点としては、
- コードレビューが実施できなかった
- 時間がなかったとはいえ、コードに妥協した部分がある
- 1週間の前倒しを受けて、土曜日に出勤させた
- 共有の仕方(複雑なシステムになると今回のような方法では不足しそう)
などなど。
コードレビューの実施時間を取れなかったのは猛省。
ざっと見て、変やなぁと思った部分に関しては、直してもらったし、意図が分からなかった部分に関しては、質問する、ぐらいのことはしたけども。
でも、結局そのあたりの内容はみんなで共有できてないしね。
あとの3点は書いてるそのまんま。
次にリーダーするときはこのあたりを少しでも改善するように動きたい。
終わりに
てんやわんやした部分もあったけど、自分の好きなように進められるってのは楽しい。
今回は、実装、単体テストまでだったから、システム開発のキモの部分は関われなかったけど。
次は上流工程も含めたプロジェクトのリーダーをやりたいなぁと思うが、「実装だけしてたいや……」っていう思いも……。
まとめ
今回学んだことは、「認識の共有の大切さ」
