目次
終始上手く行かなかったプロジェクトでした
終わったプロジェクトに対してあとから何かいうのも行儀が悪いかなとは思うのですが、前向きに反省し今後のキャリアに生かすためにも自分へのダメ出しも含めて客観的に見るのは必要かなと。プロジェクトが上手く行かなかった原因について支障がない範囲で箇条書きにするとこんな感じ。- エンドクライアントのプロジェクト計画が未熟
- 機能要求を現場が解るレベルでとりまとめることが出来ない
- 計画の見通しすら立ってないのに開発チームを招集
- 開発環境の整備もソースの準備も出来てないのにプロジェクトスタート
- 中間のマネジメント会社の存在感が希薄っていうか透明
- 開発チームからの質問をエンドクライアントに投げ、回答をフィードバックするだけの存在（途中でバイパスするようになった）
- チケットステータスの確認と進捗計画を作り直すことだけ一生懸命やる
- プロジェクトマネージャが未熟
- メンバーのスキルを正しく見積もれずチーム編成に失敗
- 一応元技術者のはずだがエンドクライアントとの会議とWBS作成に忙しくてプロダクトを一切見ていない
- 動作環境を作らずソースコードを読まずstagingも触らないので受けた報告を理解出来ない。ゆえにタスクが遅延しているメンバーに突っ込めないしフォローも出来ない
まあ、こんなんあるんだっていうぐらい全部がダメでした。
じゃあどうマネジメントする？
エンドクライアントのことだとか中間のマネジメント会社のことだとか書きましたけど自分はその立場ではないので、ストレスに感じたところでダメなモノは仕方ない。出来るとすればプロジェクトマネージャ（PM）に代わってチームを仕切ることぐらいで、もしそうなったとしたらどうしたら良かった？ということを考えたいと思います。その方が建設的だし。考えつくことはこんな所かな。
- メンバーのスキルが解らないうちにチームを分けて対処するのはリスクが高い
- メンバーのスキル差がはっきりした時点でスキルの高いものに低いものの監督をさせて、クオリティを下げないようにする
- 毎日の定例ミーティングは行わない代わりに、スクラム開発の中のプランニングとレビューを採用する
- プランニングでは期日と作業量を明確にする
- レビューでは「何をしたか」の報告ではなく、自分が開発した部分の解説を行ってチーム内で知識を共有することを主目的とする
- 「何をしたか」の報告はSlack上で報告があれば十分
1. メンバーのスキルが解らないうちにチームを分けて対処するのはリスクが高い
個人的に失敗の始まりはここだったと思っています。開発したサービスは主にお客様が触る「Webサイト」と主にスタッフが触る「管理サイト」の2つに分かれていました。またエンドクライアントが新規に開発するAPIを利用してデータを取得することが決まっていました。そこでPMはチームを2つに分けてAチームを「APIチーム」、Bチームを「管理サイトチーム」として二正面作戦で行くことにしました（僕はBチーム所属）。
そこで何が起きたか？
メンバーのほとんどが仕様がわからないまま「開発」を行う
サービスの仕様を決めているのはどこか？それを把握しやすいのはどこか？というとそれは管理サイトです。例えばブログ記事があったとするなら、そこにどんな要素があるか、どんな機能（予約投稿とか外部データの読み込みとかテンプレートの選択とか）があるか、どうまとめられてどう表示されるか。そうしたことが管理サイトで決定されるわけで、管理サイトを見ることは（ソースコードを読むことの次に）サービスの仕様を把握するのに役立ちます。管理サイトはチーム全員が触らなければならない場所でした。
ところがチームの半分はAPIチームに割り振られました。APIチームはのちに「Webサイトチーム」に改称され進捗が思わしくないからとBチームから人員を移動して増員させました。結果チームの2/3のメンバーがサービスの仕様がよく解らないまま表面的なデータのやり取りや表示に手を入れることになり、不具合で動かないとか、動かし方がわからないとか、データ構造が解らないとか、そういった問題が頻発しました（そしてその多くはよく解らないまま改変したことによるエンバグでした）。
仕様に関する質問は全て僕に
その尻拭いを誰がするのか？仕様が解らないのを解決するのは誰なのか？結局それに応えられるのは、Laravelをよく知っていて管理サイトとともに仕様を把握しつつソースコードををくまなく調べた僕しかいないわけで、全部の質問を僕が捌くことになるわけです。お前ら仕組みぐらい自分で見ろよ。Aチームのメンバーは最後までデータ構造が解らないまま手探りで開発を続け、稼働最終週になっても根本的な質問を僕に投げてきたり、そんなことしたら全体止まるだろっていうような基本的なメソッドを書き換えようとし、PMもなぜそんなことになっているのか理解出来ていないようでした。
もちろんメンバー個人のスキルや性格の問題もあったでしょうが、チーム割りがそもそも間違っていたと僕は思います。スキルが不明なメンバーが寄り集まったチームな訳ですから、手を動かしながら全員で仕様を把握して共有するところから始めるべきだったし、チームを分けるのはスキルがわかっからでよかった。
2. メンバーのスキル差がはっきりした時点でスキルの高いものに低いものの監督をさせて、クオリティを下げないようにする
プロジェクトが本格的に走り始めて解ったことは、メンバー間のスキル差が著しいということでした。驚くべきことにチーム内で最も知識があるのは僕で、中にはLaravelやVuejsや酷いときにはPHPを「ちょっと触ったことがある」という程度で引っかかって入って来たメンバーもおり、当然成果物にもかなりの差がありました。僕の次にスキルがあったのは一番若手の男性で、彼と僕は同じBチームで組んでいました。一方、Aチームはなかなかにすごいメンバーで、共通ID基盤の設計をしていた男性はAjaxを知らずにJavaScriptを書こうとしていました。APIにリクエストを投げるライブラリ（APIチームではAPI Gatewayと呼称していた）を設計・実装していた男性は、PHPDocを知らず、エラーハンドリングを知らず、都合の良いデータを通す行為をテストと呼称していて、彼の成果物によって既存のシステムが止まり、毎日多くのバグが出ていました。そしてその2人がタッグを組んでいたわけです。
Bチームの我々が普通に開発している横でAチームから「今日は認証回りについて調べていてどうやらAjaxというものを使わなければならないようです」「今日はバグを直していました」という進捗報告が繰り返される様は、彼らのスキルが不足していることよりもむしろPMのマネジメント力が著しく低いことを示しており、Ajaxを知らない彼はそのタスクから外さなければならないし、バグ生成器の彼はもっとスキルのある人間と組ませて監視しつつ軽いタスクから与えて様子を見なければならないし、そのどちらもしないまま「どれぐらい時間掛かりますか」「わかりました」「頑張ってください」としか言えないPMはちょっとうん。ダメでしょ。
もっと早く見切ってプランBを出すべきでした。
スキルのある人ばかりが集まるわけではないのは解る
フリーランスを集めて臨時のチームを作っているわけなので、スキルにばらつきが出るのは仕方が無いです。進捗を考えるとスキルが低いことを理由に外すのも難しいし、報酬を考えると教育するのも割に合わない。非常に苦しい状況なのは解るのですが、成果物がダメだったら本当にダメなわけです。そこは手当てしないといけない。そう考えると、例えばバグだらけな彼は僕と組んでレビューでダメ出しされまくる最初の1ヶ月とか過ごすべきだったし、Ajaxを知らない彼は若手の彼と一緒に今どきのフロントエンドをキャッチアップしながら若手の彼をサポートするぐらいの立場から始めるべきでした。なんでその2人がチームを？皆目わからん。
ちなみにもう1人ベテランで恐らくキャリアも長い僕と同じくプロジェクトリーダーをしていた男性（ただしLaravelやDockerの経験はほとんどない）もいたのですが、なぜか彼はコーディングにはほとんど参加せず、PMの代わりにエンドクライアントと打ち合わせしたり仕様をまとめたり資料を作成したりする作業に専念しており、Aチームであるにもかかわらずバグ生成器を止めることもせず放置していて、いやあ、大事な仕事をしてもらってるのはそうなんだけど、最低限のレビューぐらいはして欲しいと思いながら見てました。
プロジェクト初期にはかなりの頻度でバグ生成器の男性とハドルを繰り返していたので、もしかするとどこかの段階で諦めたのかも知れません。
長くなり過ぎたので明日に続きます。
