ブログへのアップが遅れてすみません。 2009年1月9日のサロンについて、以前の建築サロンでもレポートにご協力いただいた 内田 有映さんに再びレポートをしていただきました。ありがとうございました！ (JTPAイベントスタッフより)


1月9日に、UCバークレーにてプロジェクトマネジメント（以下、PM）を専攻していた藤本賢治さんにお話をして頂きました。
■講師プロフィール
大阪の中堅SIerで約7年、生産管理システムの開発やプロジェクトリーダーなどを経験した後、今後の自分のキャリアを新たに展開する為、 2006年にカナダにてワーキングホリデーを使って、バンクーバーのソフトウェア会社で働いていたということです。また刺激をうけた本として、 『ピープルウエア』や『シリコンバレー精神』などを挙げていました。１月から、音楽情報を提供する会社でインターンをする予定になっているそうです。
■ERPプロジェクト概要
実際に2005年に携わっていたERPのプロジェクトの内容で話をしていただきました。ちなみに、ERPとは、Enterprise Resource Planningの略で業務を円滑に管理するためのソフトウェアパッケージでSAPなどがその代表にあたります。
概要としては、製造業向け業務システムで、期間１年、メンバー10-15名、5000万円という内容のプロジェクトでした。大きな流れとしては、「営業支援->基本設計->詳細・製造・試験->運用保守」と、いう流れでプロジェクトを進めます。基本設計の際には、Logic Diagramなどを使ってタスク毎のフローを明確にする必要があり、これをプロジェクトメンバーで共通認識させます。また議論の中で、製品の特性によってケースが違うとのこと。請負で開発するような製品は、スタートからゴールまでのCritical Pathはある程度、明確にたてられるが、新しい技術を取りいれていくようなパッケージ製品は、スタートとゴールだけ見えていることが多く、間がブラックボックス化しているのでスケジュールも予算も立てるのが難しいみたいです。
■プロジェクト
契約を結ぶ前にどれだけスコープ（仕様）を詰められるかが重要で、それをもとにプロジェクトコストを算出し、この段階ではじめて価格交渉をして行きます。コストの算出として、「人月」「工数時簡単価」をもとに適正や市場価格を考慮して決めます。ただ実際のプロジェクトの時は、「客都合」によってプログラムの工数の約半分ぐらいに抑えられてしまったとのことです。ただ、プログラムは何行でいくらなど定める事が出来ないので、適正値をだすのはとても難しいみたいです。 保守は年間で別料金をとり、これは大きな収入源になるみたいです。ただ、保守管理をする場合、バージョン管理まで行う保守のか基本的に維持で何かあった時だけの保守は定めておかなければならないそうです。
バークレーでは、Scope definition範囲外の「やらないこと」も契約の際にリストアップして、やらない項目をやる必要が出た場合は、改めて別料金で交渉をするそうです。ただ、これは日本では非常に難しいのではという声もありました。また議論の中で、遅延や遅れなどが有る場合、アメリカではPMは気配を察して辞めてしまうケースもあるそうです。デスマーチが起きたときには、なにも知らない人が次のＰＭになるということもアメリカではあるそうです。
アメリカの場合、ヒエラルキーとしてはPMが力を持っている場合もあるが、権力やお金はエンジニアの方があるというケースがかなりある。また、神様クラスのエンジニアは、部門を持たずに個人でエグゼクティブの下に配置するという場合もある。一方、日本では、SEが数年経つとPMになったりするが、いいSEがいいPMになれるわけでもない。そのため、日本では偉くなると、駄目上司になってしまうことがある。しかしながら、PMはある程度、SEの技術を評価できないといけないので、PMだけをやっている専門の部署が入ってプロジェクトをうまくまわせるかというとそういうものでもない。
次に、Quality Managementに関しては、TDD(Test driven development)などテストコードを先に作って開発を進める方法がある。これは、エンジン等のアルゴリズムには使えるが、ユーザとのインターフェイス等では用いる事ができない。ユニットコードを作る場合には使えるが、人工知能と同じ様な問題に行き着くとのことです。
■プロジェクトの標準規格
ISO 9000とは、プロジェクトマネジメントの標準規格で、プロセスが文章化されているか評価するものである。ヨーロッパではISOは絶大な力をもっているが、アメリカではそれほどでもないという意見も多かった。いい企業という評価にはならないが、最低限の基準を満たしている企業であるという評価にはなる可能性が高い。全て、文章化されていて開発文書が残っているということがとても重要である。ただ、これは原理主義的に働く社員にとっても縛られる要素になってしまう。製造事業所毎にISOを導入するようにして、全社的には無理をして導入しない等など工夫をしている企業もあるそうです。
また、ソフトウェア会社ではCMM（capability maturity model）というモデルがあるみたいです。インドの会社が大好きで、これがあると体力がある会社であろうという証明にはなるとのこと。ISOにしても CMMにしても、認定会社がたまに訪問して規格通りにやっているかなど従業員のチェックに来るそうです。
■ハードウェアとソフトウェアの違い
ハードウェアだとプロセスがしっかり定まるのでプロジェクト管理がしやすい。また、直すことも簡単に出来ないため、かなりデバッグやバグ修正の作業は慎重になるとのことです。
その一方で、ソフトウェアだと管理をしないことの方が当たり前とのことです。ソフトウェアはバグのトラッキングできるし、それが当たり前になってしまっている。さらにネットワーク越しにアップデートすることが出来る様になったため、開発の管理がルーズになってきている傾向があるとのことです。
一言にプロジェクトマネジメントと言っても、日本とアメリカでは全く異なり、建設業界とIT業界と比較するとそこでも異なり、ITの中でも請負開発なのかパッケージ製品なのか、ソフトウェアなのかハードウェアなのか、大企業かベンチャーなのか、によっても全く管理の仕方は異なるみたいです。今回は、参加者に色々な業種の方がいて管理の仕方が違うため、「私たちの会社は～」という議論が炸裂していて異なるプロジェクトマネジメントを沢山、聞く事ができました。