Blog
Research Blog上では初めまして。Professional and Support Serviceチームの西鳥羽です。
8/11のPFIセミナーでプロジェクトマネジメントの話をさせて頂きました。その時の様子はこちら前編後編です
何度か開発プロジェクトを経験してきて、初期のプロジェクトと比べるとPMとしても開発者としても上手く回せるようになったし、勘所も見えてくるようになってきたので一度まとめてみることにしました。PFIは製品開発や研究開発が中心で直接お客がいる開発を行っている人間が少ないことや、今サマーインターンをやっていてたくさん学生が来てくれていることもあってシステム開発の様子が珍しいのではないかと思いプロジェクトマネジメントの話にしました。
その時のスライドを公開します。
元々学生ベンチャーで開発プロジェクトの経験も無く、教えてくれる先輩もなく、当然何度かデスマーチを経験しました。「このままでは良くない」と開発手法について書籍にあたりました 。スライドの内容も書籍がベースになっているものが多いです。それらの参考文献は本来スライドに載せるべきではありますがそれでは参照しにくいのでblogに載せようと思います。
基本的な開発の流れは上記のサイトが大分参考になりました。開発者側からだと見えない営業やらフォローアップなど含めて流れをコンパクトに纏められています。
そしてプロジェクトマネジメントして一番参考になったのはアート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)です。ウォーターフォールとアジャイルの中間くらいのプロジェクトマネジメント手法で日本的な開発案件に使える部分が多いと思います。スライドの中身も「優れた見積りは信頼性の高い設計と要求が揃って初めて得られる」「動いている標的を狙う」などがベースになってますし、「優れた仕様書の記述」など他にも参考になる部分が多いです。
提案時の見積りが肝だと主張しましたが、そのためにソフトウェア見積り―人月の暗黙知を解き明かすの第一部「見積りの考え方」が参考になりました。
要件定義の段階で漏れや暗黙の思い違いなどをどれだけなくせるかというのについては要求仕様の探検学―設計に先立つ品質の作り込みが詳しいです。また、要件定義時に「何をコンピューターにやらせるか」を考えますが、これは「何を解くか」に通じていて、ライト、ついてますか―問題発見の人間学が面白かったです。
ウォーターフォール前提な話をしましたがもし可能ならアジャイルの方がいいと思っておりますし、質疑の際に「最近は書籍が増えてきた」と言いました。今までアジャイルに触れたこと無く、アジャイルの雰囲気を知るにはアジャイルサムライ−達人開発者への道−を読むのが良いと思います。分量も少なく、雰囲気を知ることができると思います。実際にやってみるのであればアート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミングが詳しく、さらにハマりどころも詳しく載っているらしく何人もの人から推薦されました。
ざっと開発プロジェクトの流れを説明しましたがいかがでしょうか。プロジェクトマネジメントはしっかりやろうとすると難しいと思いますが80/20の法則が当てはまる世界だと思うのでちょっと知るだけでも大分状況が変わってくると思います。社内であれ顧客のいる開発であれ、PMじゃない方でも開発に関わっている方は触れてみたらいがかでしょうか。
Tag
