お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

プロジェクトマネージメントアプローチ?

2008/10/04 12:03
  • このエントリーをはてなブックマークに追加

プロフィール

山田ひさのり

私がプロジェクトマネジメントを実践したり学習したりしていく中で、ためになった考え方やノウハウを紹介していこうと始めましたが、その後ケータイ/ソーシャルビジネスを中心の情報発信に変化しました。暫くの間更新が滞っていましたが、私の転職をきっかけにグロースハック/ハッカーの情報を発信するグログとして投稿を再開しました。
ブログ管理

最近のエントリー

一定の成果を残しつつも「銀の弾丸」となりえなかったXP、私はこの現実を受け入れるしかありませんでした。今考えるとそんなことがあるはずも無いのですが、XP導入当初は活気的なプロジェクト方法論を導入すれば従来の問題だらけの労働環境から開放され、まるでバラ色の未来が待っているかのような幻想を抱いていました。今振り返ってみればXPのプラクティスの部分的な導入ができただけでも一定の成果であったにも関わらず、私はこの成果に満足することはできませんでした。

そこで私は新たなプロジェクト方法論を模索しようとしました、、と言いたいことろですが、XPを部分的にでも導入することができた私の中にはある感情が芽生えていました。それは「プラクティスの洗練」でした。ここで言うプラクティスとはXPの構成要素(=実践手法)で、1つ1つのプラクティスを突き詰めていくだけでもプロジェクトにとってかなりのメリットを生み出せるのではないかと考えたのです。

今思うとプロジェクト方法論にもボトムアップ・アプローチとトップダウン・アプローチがあるようです。世の中のプロジェクト方法論にはPMBOKのように具体的な手法はほとんど定義されておらずその精神のみをうたっているものと、XPのように具体的なプラクティスが定義されているものがあり、またそれらの折衷アプローチで成り立っているものなどがあるようです。おそらく トップダウン・アプローチ → ボトムアップ・アプローチ で方法論とプラクティスが形成されていくのが理想的だと思いますが、当時の私にはそんなことはわかりませんでした。

実際にXPの導入では「短期リリース」と「継続ビルド、テスト駆動型開発」の導入にによってプロジェクトの問題を回避したり、プロジェクトの効率をUPさせるような結果を残すことができました。私はこの "局所的な問題解決" を繰り返すことでプロジェクト運営をより良いものにできるのではないかと考え始めました。
おそらくほとんどのPMと呼ばれている人は自身の数々の失敗からこの「ボトムアップ・アプローチ」を工夫、改良することで自分独自のツールを生み出し、(経験的に)そのツールを生み出すノウハウを自身のスキルとしていると思います。世の中の多くのプロジェクト管理本は自身の経験に基づいたプロジェクト管理ノウハウを紹介しているに留まっているためこのカテゴリに入ると思います。しかしプロジェクト管理に必要なのはそのようなスキルだけでは不十分で、そこに精神性や統合された戦略性が存在し、それらが体系化されていることが重要だと私は考えています。私はこれまで職責上多くのプロジェクトマネージャ候補を面接してきましたが、多くの人が経験に基づいたスキルを語るばかりで、体系化された知識を有している人はほとんどいませんでした。その原因はいくつかあると考えています。

  1. 私の会社のレベルがそのそもそのような知識を有している人物が入りたいと思うレベルに達していない
  2. 世の中一般に、プロジェクト管理においてそのような知識が必要だと考えられていない(不必要だという主張)
  3. Webサイトの開発においてはそのような知識はほとんど必要ないと判断されている

最近ではプロジェクト管理の重要性が認知され、ソフトウェアの世界でも管理された工業化を進める機運が高まっていますが、未だにプロマネは経験ベースの知識でやれる職業と捉えられているようです。もちろん経験ベースの知識は非常に大事で私も「現場を軽視する人間は必ずしっぺ返しを食らう」と考えています。しかしプログラマやアーキテクトなどの専門職は経験ベースだけでなく体系的な勉強も必要で「常に勉強」という意識が根付いているのに対してプロマネは少々違う意識で捉えられていることが私には納得いきません。なのでたまにプロジェクト方法論に明るい人が面接に来ると、そのような話で大いに盛り上がり、楽しい一時を過ごしたりします。

そこで私はプロジェクトで問題となっている項目を洗し、洗練させたい事柄をピックアップすることを始めました。以下がその結果です。

  • 見積の精度を洗練させること
  • 要件定義と仕様の明確化を推進するがビジネスのスピードは損なわないことこ
  • メンバの時間管理を厳密にし、追加開発や次のプロジェクトの参考値とすること
  • メンバー間がコミュニケーションを取りやすい環境を整えること
  • メンバーが労働過多にならないように配慮すること

他にも細かいものはいろいろありましたが主だったものは上記の5つでした。今思うとXPにかなり影響されている感じもしますが、当時私の無い頭でひねり出した「ボトムアップすべき項目(以後『ボトムアップ・アイテム』と呼称)」がこれとなりました。私はこの1つ1つを今より高みに持っていくことでプロジェクトメンバーが幸せになれると考えました。これから暫くは私が上記のボトムアップ・アイテムをどのように実現したかについて書こうと思います。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー