読者です 読者をやめる 読者になる 読者になる

Shut the fuck up and write some code

グダグダ言わずにコードを書きたいブログ

クソプロジェクト案件と向き合う

Programming 雑記

はじめに

今関わってる案件にかなり大きな問題があり、正直逃げ出そうと思ったが、この案件の状況を良くしていくことがスキルアップに繋がるとも考えられるので、少しずつ改善していくための考えをまとめて行きたい。コーディングのHACKを書くことも重要なのでしょうが、こうした人的な取り組みもHACKとしてやっていければと思う。

現状の問題点

チーム周り

チーム人数が少ない

現状3人ほどの開発体制。開発工数をまかなえる人数ではあるが、人数が少ないことによるチームビルディングの浸透性の無さが問題。一応担当分掌は別れているがリーダー自ら開発している。それほど密なコミュニケーションしていない。進捗報告など一切無し。他の担当の人が何を作ってるのか深く理解していない。

スケジュール管理がほぼなされていない

リーダーから短期でこなすタスクが上から降ってくるのでそれをこなしていく開発スタイル(自分は日雇い労働開発スタイルと呼んでいる)。ガントチャート的なものもなく中長期的な開発計画は口頭では説明されるが明示化はされてない。プログジェクトとして一体どのフェーズで進んでいるのかわからないし、リリースのための状況(α版を作っているのか?ベータ版を作っているのか?も良くわからない)も把握出来ない。突然今日から社内テストだと言われることもある。

コード周り

README、ドキュメントと言ったものがほぼ無い

特殊な用語なども多くコード一読しただけでは分からない。オリエンテーションはされているが、資料が存在しないので復習することもままならない。

コードに一切コメントが書かれていない

ドキュメントもなくコメントもないので、メソッド名から推測しながら処理内容を読もうとするが、メソッド名と実際の処理内容が異なる箇所もあるので、メソッド名通り受けようとすると間違える

対応

現状、チームで開発しようという体制になってないのでまず、第三者がジョインしてもスムーズに開発環境に入れる環境を作ることが最優先だと考えている。自分もその人間だが、今の状況はかなりストレスフルであり、まずは1次情報を見つけ出すことをで時間をとられコードを書くことに集中できない。自分のパフォーマンスを上げるための作業を最優先してみる。

コードを書くよりもドキュメントを書くことに集中する

まともなコードを書くことは状況的に難しいのでまずは情報収集した結果をとりまとめていく。git add README.mdするところから始める。

Readableなコードを書くことを最重要とする。

第三者が見てもすぐ理解出来るコードを書くことを最優先する。極端な話、実処理コードよりもコメントが多いソースにする。無駄な処理が多いとか言われてもパフォーマンス・チューニングのタイミングに入るまで指摘は無視する。

チームビルディング

スケジュールの明示化と進捗管理を最低限やるのは至極当たり前の話で、情報が別のところに集まっていれば各種ツールでガントチャートを作るなど自分でスケジュール管理などしてしまうのだが、如何せんすべての情報をリーダーが握っており、ヒアリングしても明快な回答ももらえないので、現状ではチームでスケジュールを管理するのが難しい。そもそも小さい会社なので上層部に訴えるなどの強権発動ことも出来ないし、個人を説得するしか方法が無い。

スケジュール管理は諦めて日雇い労働開発スタイルに勤しむしかない現状。いつ開発が終わるのか不明瞭だし、まともに休みも取れるのかわからない。旅行を行くのはかなり難しいと思ってる。

現時点では良い策がないので、先の個人開発環境周りの整備をやっていこうと思う。

最後に

今関わってる案件は、いつぞやのNode.jsの分裂みたいなことが起こってもおかしくないOSSコミュニティに近いものがあるかもしれない。個人の集まりではなくチーム/プロジェクトに寄り添う動き方が出来るようにならなければ、成功しないだろうな。と傭兵歴4年のおじさんは思うのであった。IT傭兵はクライアントのために動きますが、負けが見えてる戦争には加担したくないのです。

PDCA回しつつ、一ヶ月くらい経ったらまた続きを書きたい。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか