この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
ベンチャー企業に入社して早4年になろうとしています。新卒で入ったので他の会社の事は分かりませんが我が社では突然スキルアップの為の「チャンス」が頂けることがあります。
新規プロジェクトで初めてリーダーとして入ったことがありました。
それまでの私は上司の不満なところにばかり目が行く部下だったのだと実感しました。
突然初めてのリーダーをやることで「あの時○○さんはどうやっていたんだろう」と初めて上司の見えないすごい部分をなんでちゃんと見ておかなかったんだろうと後悔しました。
社長から「○○様(お客様)がいい対応してくれてるって褒めてたよ」と言われることもあったので、お客様向けの対応はそれなりにうまく行っていたようですが、チームのメンバーの私への不満はいっぱいあったと思います。
いままでの上司の良かった点、悪かったと思う点などを思いつく限りピックアップしてみたりもしましたが知識が全然追いついていないので「PMBOK」について学ぼうと思いました。
今回私が読んだのは「プロジェクトマネジメント標準 PMBOK入門」
読んで理解したのは上記でも触れたプロジェクトは失敗だったということ。
それをここから説明しようと思います。
※PMBOK自体はWEBに限った話ではないのですが、私の仕事がWEB系のため話が偏ってしまっております
PMBOKによるとプロジェクトの「成功」とはスコープ・スケジュール・予算がすべて達成しているということ。
スコープとはお客様の求めているものおよびその作業の事を指します。
お客様の求めているものをうまく聞き出し、それを仕様書に書き起こし、確認を行ってそれ通りの物を納品する。
簡単かつ当たり前のようですがお客様が「これはあって当たり前」と思っていたり漠然としたイメージしか持っていない場合などは大変な作業となります。
続いてスケジュールとは文字通り期間のことです。
お客様が○日までにサイトをオープンしたいといった場合は最大でもその日までが期間となります。
最後に予算とは、これも文字通りプロジェクトにかけられるコストのことです。
WEBサイト構築で言うと材料はほとんどないので主に人材になります。
その人の単価(スキル・経験のある人だと高くなる)やその人を拘束する期間で使用したコスト算出します。
私のやった案件の失敗は主にスケジュールでした。
言い訳をするならばお客様の仕様の確定が遅かった、デザイン会社がデザインをなかなか納品してくれなかった、直前になって「あの機能がないと困る」と仕様の変更があったなど色々あるのですが、失敗は失敗。
そしてスケジュールが失敗した=期間が延びたのでその間メンバーや私の拘束期間も伸び、結果として予算も失敗となりました。
仕様の確定が遅かったのならばもっと小まめにお客様とコミュニケーションをとって確定するのに何が引っかかっているのかを聞き出すべきだった。
デザインももっとデザイン会社と連携をとって進捗を把握し、遅れ初めているようなら急いで貰うようにもっと働きかけるべきだった。
直前に「あの機能がないと困る」と言われないようにもっと詳細にヒアリングを行い、叩いても埃がでないくらいまで仕様を詰めておくべきだった。
つまりなんで失敗したのか、私の「言い訳」から「原因」が分かります。
経験は知識に勝るものはないとよくいいますが、この本を読んで知識を得るまで漠然と「理由があったし、仕方がなかった、次は頑張ろう」と思っている部分がありました。
知識がなければ経験を生かすことができないのだな、と反省しています。
しかし知識だけあっても振り返るものも試せるものもなければ持ち腐れ。
2つが揃って初めて発揮できるものなのだと思います。
初めにもいった通り、弊社ではいつ「チャンス」を頂けるか分かりません。
案件があり、その人に出来そうだと思われれば未経験でもチャレンジさせて頂けることの出来る会社だと思います。
だからこそ「こんな仕事があるんだけどやってみるか?」と言われたときに、活かせる知識をためておくことが必要だと思います。
最後に「PMBOKって何?」というお話を(本当は最初に書くべきだったのでしょうけど失敗しました)
PMBOKとはProject Management Body Of Knowledgeの略です。
プロジェクトマネジメント団体のPMIがプロジェクトマネジメントの知識をまとめたものです。
私が今回説明できた部分は入り口でしかなく、今回読んだ本にもマネージャーとしての心のあり方から、適材適所を配置する必要性、プロジェクトの運用の仕方(今回説明したスコープ・スケジュール・コストのやり方)など色々載っていました。
初めてみる単語も多く、一度読んだだけでは全然覚えられなかったのでこれからもう一回読んで見たいと思います。
今回この記事をここまで読んで頂いて読んでみようかなと思った方にお勧めの読み方は、
やはり上記で私がやっているように実際自分の経験したプロジェクトと照らし合わせながら、これはこういうことかな?と自分なりの解釈をつけることかなと思っています。
そうしないとせっかく読んでもなかなか中身が入ってこず、実感もわかないので意味があまりないような気がします。
自分がやったことなくても上司で当てはめたり、聞いたことのある他の人のプロジェクトでもいいし、全然検討がつかなかったらそれこそ学生時代の学園祭やクラス劇に当てはめてもいいと思います。
それではここまで読んで頂いてありがとうございました。
奥が深いPMBOKを一個のブログ記事に書くのは難しいので、また別の機会に書きたいと思います。
