m-namikiの日記

おもしろき こともなき世を おもしろく

仕事納め

今年は今日で仕事納め。

5月に本社へ戻り、そこから始まったプロジェクトが昨日無事結合試験まで完了。年明けから要望対応やデータ移行、運用試験等があるが、本日納品でひと段落。プロジェクトリーダーという立場を任されたが、果たして十分にその役割を果たせたのだろうか。せっかくなのでKPT法で一人ふりかえり会をやってみる。

Keep

  • 技術的に新しいことへの挑戦 ⇒ MavenSAStrutsの採用
  • 工数管理表の記入
  • 毎朝15分の朝会

今回のプロジェクトは受託案件だったので、フレームワーク等々の選別を自分で行うことが出来たために、独断でSAStrutsを採用した。結果、開発メンバーにはかなり好評だったようで一安心。Mavenも個人的には以前から利用していたが、プロジェクト単位で利用するのは初めてだったので、メンバーにマッチするか不安だったが概ね好評だったので良かった。

工数管理表については、以前から似たようなことはやっていたが、PM、PLの見積り工数や実担当者の見積り工数も記載するようなフォーマットだったため、現在の状態が一目で把握出来るのが便利だった。これを続けていけば見積り精度も向上するはず?

Problem

  • 開発後半、スケジュール管理、工数管理がおざなりになってしまった
  • 顧客との仕様打ち合わせ不足
  • 基本設計、詳細設計時に全体レビューの時間を取るべきだった
  • 見積り精度が低い
  • SAStrutsでServiceの作成単位が不明確だった

スケジュール管理、工数管理がおざなりになってしまったのは大いなる反省点。実担当者チックな作業に追われてしまったため、というのは単なる言い訳だ。自分のすべきことの優先順位をしっかり付けなければならない。

仕様打ち合わせ不足に関しては、今回のシステムがExcelマクロからの移行だったので、「現行仕様と同じ」で一括りにされてしまったために、製造工程で「この仕様で本当に良いのか?」というのが何回か発生してしまった。結果的には現行仕様通りなのだが、設計の段階で現行仕様がどういうものかをもっと明確にしておく必要があった。

設計レビューに関しては、全体の整合性が取れていなかったために、製造工程にそのシワ寄せが行ってしまった。

見積り精度に関しては、予定工数・担当見積工数と実工数の乖離が目立った。最終的にはプラマイゼロに収まったが。担当者ベースでバッファを大きく取ってしまっていたことが原因だが、今後はこの実績をベースに次に繋げていかなければいけない。

Serviceに関しては、エンティティ単位で作成していく方針だったが、このプロジェクトでは実際の業務と照らし合わせるとクラスが肥大化してしまうために、現在は機能単位とエンティティ単位のServiceが両立してしまっている。ここは今後どうやっていくのがベストなのか、しっかりと議論していく必要がある。

Try

  • 顧客への質問事項やバグ管理をExcel管理からBTS管理へ変更
  • Wikiによる情報共有
  • テストの自動化(Continuum、Selenium
  • GTDによるタスク管理

BTS導入については技術的に新しいことへの挑戦の一つだが、Excelによる管理ではいつか限界がくるのも事実なので、もっとシステム的に処理出来るような仕組みにしたい。

Wikiは以前の現場で導入していたが、ちょっとした気づきを残しておけるし、開発者同士の打ち合わせ結果を残しておくのにも便利なので是非導入したい。

テストの自動化については、今回のプロジェクトではjUnitを利用したが、それをさらに推し進めてContinuumやSeleniumを導入したい。



うーん、ふりかえってみるとプロジェクトリーダーという役割を十分に果たせたとは言い難いなぁ。年末年始休暇でプロジェクトリーダーはどうあるべきかを色々考えてみよう。