しかもその中で仕事の駄目出しを聞いた。連続ではないが、7時間程度聞かされ、疲れたんだよもん。
とはいえ、色々学んだし、まだALLできる体力があることもわかったから、これはこれで収穫か。
手なわけで駄目だしの内容を踏まえて、一人反省会。
現状
いい感じに炎上しているプロジェクトに参加。6月末に設計Exitして、開発を8月末まで、結合テストを10月末までやっているんだけど、品質がひどい。
もう、10月半ばになっても正常系が動かない処理がある。しかも、根幹系の処理。
どうしてこうなったか。
といっても、普通の話で、設計の時点でくすぶってて、詳細設計で炎上。
チームリーダで手に余る状態になったにもかかわらず、マネジメントは「がんばれ」の一言。
まぁ俺は主体は別プロジェクトなので、目の前のお客様を優先していたというのが正直なところ。
駄目なプロジェクトに対する個人的分析
現場の主軸メンバーもいて、管理者もいて、私は出がらしなので、という特殊なポジションを利用して観察。実験も兼ねて、放置を繰り返した結果、炎上した。多少は手伝ったけど。
なぜ、炎上になったか。
初期状態のときに、手を加えなかったのが原因かなと思う。
とりわけ、初期状態のときに増員を行わなかったのが痛い。加えて、管理系メンバーのスキル不足により、メンバーの生産性が低い状態で維持し続けている状態であったためと考える。
なぜ、マネージメントスキルが不足しているのか。
個人的には人手不足がトリガとなって、推進系のタスクがおざなりになったためかと。
- 整備不良により、ドキュメントのマスタがどこにあるのかわらない
- テスト環境を準備するメンバーがいない
- 新規構築なのに、フレームワークの設計部隊の設計が遅れ、開発本体の部隊に追いつかれる
- 新規構築なのに、先行開発、先行実装部隊がいない。そもそも計画されていない
やってみたが駄目だったこと。
いくつかやってみたが、軒並み駄目だったから、ご参考までに。- ドキュメントのマスタの置き場所については、プログラムと乖離していくリスクがあったため、せめて、DAO（データアクセスオブジェクトのUT用コードは設計書から自動生成できるようにマクロを作った。が、イマイチ受け入れられず。
- テスト環境や先行開発については指摘しかしていなかったが、イマイチ改善されず。というのは人が不足していて、目先の作業で手一杯だったため、そちらに力が注げず
- 人繰りについてPMと相談。自チームのメンバーをフォローに向かわせる打診を行ったが拒否される。なんだ、そのプライド。
- 人を追加したのが、結合テスト時期。来て1ヶ月で打鍵以外の何ができると？ しかも一人は新人。一人は生産性の低いと噂のミドル。
Barで指摘されたまだやっていないこと
- 使えない人間を切る。さすがに会議中寝る。朝来ないメンバーはいらんでしょう、との指摘。放っておくと、新人教育にならないし、下手したらつぶしかねない。そら、そうだわな。これはチーム内でも提言しようか。
- PMに言って駄目だったら、もっと上に言ってみる。これは、私はやっていないが、もっと上も「がんばれ」スタンスだから、さらに上を目指さないといけないようである。うーむ、レベル高いなぁ、でもやんなきゃいかんかったのかもしれんと思った。しかしながら、今回は自分が主メンバーではないところもあって、どこまでいったら炎上プロジェクトになるのか見てみたいところというところもあったので、放置してみている。本当に炎上したら、このプロジェクトが限界ポイントなんだろうと思う。
- リスケを考える。というか、提言する。
この経験を活かして思ったこと
今回の中で学んだことを、今後に活かすためにまとめる。先輩がリーダーだからといって、管理能力があるとは限らない。
また、過去、成功実績があるチームでも失敗することはある。気になるところは徹底的に確認すること。
今回の個人的な失敗は、もともと私の周りの先輩は管理能力に長けた人ばかりだったこと、参画したプロジェクトは安定と実績のチームと聞いていたことによる誤解である。炎上していても許容範囲内、あるいは教育を兼ねてぎりぎりで放置しているのかと思った。ところが、そうではなかった。今後は、先輩とか無視して、自分の考えと違っていたら提言とか、作業レベル詳細化とか、ガンガンかき回しておけばよかった。
- 新規プロジェクトには先行技術の検討チームが必須
- 新規プロジェクトには推進チーム（開発環境整備の開発推進、ドキュメント整備のPMO、運用・移行も必要に応じて）は必須。
- 会議は税金。極力、参加人数を少なくすること。また、全員揃って会話しなければいけないことに絞ること
とかとか。
ではまた。
