PMBOKなんかやってるから仕事できねーんだ
■自分で通じないと言ったのでキチンとコラムで書いてみた
別にコメント欄に恨みがある訳ではないが、同じネタを引っ張ってみた。多分、前のコラムでもそうだと思うが、WBSを書くような立場の人にとってはあまりいい気分のするものではなかっただろう。自分が良しとして書いているものを批判されたら、いい気分はしないだろう。
そんな気分良くなかったであろう人から以下のようなコメントを頂いた。
ちゃんとPMBOK勉強したら？スタティックおじさん見たい。
私の書いたコラムにまでスタティックおじさんをアピールする程のファンのようだ。で、彼に対しての返答として、
このコラムのWBSをPMBOKに置き換えても意味は通じます。
と私は返してみた。そんなことで、本当に置き換えて書いてみた。似たようなネタをもう一発、引きずってみようと思う。
■PMBOKではどうやっても解決できないこと
PMBOKを活用することでプロジェクトが円滑に運用できる。とはよく言うが、それ以前に根本的なスキルが不足していては、事を成し得ることは不可能だ。どんなに理論的な人でも、理論だけで実力不足を覆せない。理論だけで対応できる範囲には必ず限界がある。
つまり、どんなに綿密に計画を立てようと、できないものはできないのだ。理論的思考で、できない → 課題を整理する → 目標を明確にする → 問題が解決する。という論法をよく見る。ここでよくある大きな誤解は、課題を整理したり、目標を明確にした時に、「できません」という結論も出るというこ とだ。
「仕事だからできないじゃ困るんだ！」という人もいると思うが、そういう人は諦めて欲しい。困っただけで不可能が可能になるなら、誰も苦労なんて しない。見直すなら、計画よりも積み重ねてきた技術的な負債だ。ここを素直に認めない限り、永遠にプロジェクトの炎上は阻止できないだろう。
■PMBOKで想定外は対処できない
PMBOKで「プロジェクト自体が実現可能か？」という IF を想定して考えるだろうか？プロジェクトは必ず実現できるという前提でPMBOKを使っているように思う。それはそうだろう。会議や、お客様に対して、できない事を前提にした説明なんてできるはずがない。なので、無理くりにでも理論を通して説明するしかない。
このように無茶な理論づけをするので、想定外が起きやすくなる。理論的にごちょごちょ考えるのも結構だが、根本的な認識が間違えていれば 正しい結果は出ない。どんなに理論的に考えても、その人のキャパシティーを超えた答えは出せないのだ。つまり、頭の固い人がどんなに理論的に考えても正解は出ないということだ。
■PMBOKをどう使っているか
そもそも、計画と達成できる限界を混同していないだろうか。よく、無茶なゴールを設定して計画と宣う人がいるが、あれはただの希望的観測だ。もし計画だとするなら、キチンと不利な要素も受け止めよう。不利な事象に対しての考察が抜けているなら、それは計画としては片手落ちだ。
現実と理想を認識した上で運用されているプロジェクトをあまり見ることがない。理想を実現したいと思うなら、理屈より前にエンジニアやマネージャーを育成しろと言いたい。最近は安直な思考の人が多いので、理屈さえ通せば達成できると思い込んでいる節がある。しかし、実際は根本的な能力が不足しているので、必ず途中でトラブルに巻き込まれる。
結論として、PMBOK自体は何も悪くはない。使う人のレベルが低いのだろう。ものすごくシンプルな話で、そんな人がPMBOKを使っても役に立たない。むしろ、そんな仕事をしているから炎上するんだと。
--まぁ、そんなことで--
結局、私が何を言いたいのか。WBSやらPMBOKとか何でもいいのだが、思索が抜けているということだ。考える力が無いのに、知識ばっかり肥え太らせても意味が無い。たとえ、孫氏の兵法とか、成功するなんちゃらの法則を持ちだしても同じ事だ。
的確な結果を得るには、知識に対して裏付けの経験が噛み合っている必要がある。ここが抜けたら、いくら知識が正確でも意味が無い。専門書まる一冊暗記するだけでコードを書けるようになるだろうか？それと同じだ。
ぶっちゃけ、PMBOKなんぞ知らん。WBSと同じように、知識だけ詰め込んで使えるつもりになているのなら、結果は大差ないだろう。
知識があっても知恵が無いなら事は成し得ない
それに尽きる。
コメント
ksiroi
全く以て同感なのだけど、このへんの「知恵」はどこかに転がってないモノかなぁ
適材適所と現地全能みたいな話はよく聞くけど、なかなか実践できんで困る。
名前のないSE
WBS・PMBOKとかこの手のマネジメント手法の是非は本当にむつかしい。
こんな面倒くさいもの作りたくない。
計画を立てようが、計画とおりに行くわけじゃない。
そもそも計画というか、適切な時間の見積もりも誰にもわからない。
実際のところ、だいたいなんとなく3か月くらいでできるというような
経験則もあなどれない。
システム開発・構築は「職人技」だ。そして、企業や資本主義は職人を嫌う。
誰がやっても同じような品質になり、誰がやっても同じ工数で正しく人件費を
見積もることができ、標準化された手法で納品まで持っていきたい。
でも、システムは工業製品ではあるが「一品物の開発」であり「工場での製造」ではない。
ここが味噌で、多くの会社で「一品物の開発ではなく工場のような製造だ」と
言えるようにみんなこの手のマネジメント手法を持ち込もうとしている。
でも、実際にはシステム開発は職人芸であって、やはり、門外の人がマネジ
メントなどと言ってしゃしゃり出てきても余計な仕事が増えるし、
スケジュールとおりに進まない場合も多いし、何のためにこんなものを
作るのかと思いながら、みんないやいや作っている。
そして、システム開発やプログラム開発をやったことがない人が見積もる
スケジュールはエンジニアを困らせる嫌な未来予想図だなと思います。
Anubis
>ksiroi さん
コメントありがとうございます。
知恵はたくさん落ちているけど、拾うには立ち止まる必要がある。
個人的にはそう思っています。
仕事をしててよくありませんか？
もっと落ち着いて取り組めばもっと良いものができたのに。とか。
今の時代って何かとせわしいので、
一つの仕組みを納得いくまでいじり倒す時間が取れない。
多くの情報を得られる分、深さが伴わなくなってしまっていると思います。
名前のないSE
参道に続いて、こちらのコラムニストにもちょっと突っ込み。
＞知識があっても知恵が無いなら事は成し得ない
anubis氏のコラムではよくこのような文言を用いられていることが印象深い。
いろいろ複数の方が異なった方針で議論している際、「知識より知恵がないと成果は期待できない」というようなフレーズをよく用いている。
短文にまとめるのはむつかしいが、この手のフレーズは魔法のフレーズだと思われる。恐らく相手を言いくるめたかのような印象を持ってしまうのではないだろうか。
実際に人間が何かを考えるときに「学歴より経験だ」「知識ばかりで頭でっかちになるより心の豊さが重要だ」というように使われる。この手のフレーズを多用すると議論の結末がよくわからなくなる。しかし、世の中の新聞記事を含めた多くの文章はこのようなフレーズで締められることが多い。
一番簡単な例として「あの人は美人だけど心の豊かさが足りない」といったたぐいの指摘。本当にその美人は、性格に難があるのかは確認されないが、多くの人の偏見、あるいは関係者の期待を背負い、その美人は「性格が悪い」と言う前提を基にしたフレーズが放たれ、多くの人が安心し、そして議論は結末を迎える。
何が言いたいかと言うと、「○○より××」だというようなフレーズを多くの人が用いるのは、「結末はよくわからないが安心を得るため」「なんとなく言い負かした」という心のカタルシスのためなのかもしれない。
決して、PMBOKやWBSを作っている人が「知識ばかり詰め込んで知恵のない愚か者」かどうかの確認はなされずに「知識より大切なのは知恵だ」と印籠をつきつけてやっつけるわけです。
多くの人はこの手の議論を見ると安心するのかもしれませんが、自分は細かい性格のせいか、「物質の豊さより心の豊さが重要だ」と言った某新聞のコラムのような文章を読み終えるとそわそわと落ち着かなくなります。
このコラムニストの文章にもその表現がよく見受けられます。
まあ、苦言とまでいかないちょっとした思いです。コラムの趣旨事態は賛同します。
Anubis
>名前のないSE さん
コメントありがとうございます。
> でも、システムは工業製品ではあるが「一品物の開発」であり「工場での製造」ではない。
ここに共感を得ます。私とは違う角度から見るとこう見えるのか。と、非常に興味深いご意見です。
ちなみに、私は工場で働いた事もありますが、新製品への対応とか工程の効率化とか、IT業界に劣らぬ程にシステマティックな部分があります。
> はり、門外の人がマネジ
メントなどと言ってしゃしゃり出てきても余計な仕事が増えるし、
スケジュールとおりに進まない場合も多いし、何のためにこんなものを
作るのかと思いながら、みんないやいや作っている
やはりこれに尽きると思います。工場や建設の現場では、門外の人がしゃしゃり出ることはほぼ無かったです。あと、IT業界はものすごく誤魔化しが多い。これが炎上の原因だと思います。
Anubis
> 名前のないSE さん
コメントありがとうございます。
> 何が言いたいかと言うと、「○○より××」だというようなフレーズを多くの人が用いるのは、「結末はよくわからないが安心を得るため」「なんとなく言い負かした」という心のカタルシスのためなのかもしれない。
正にその通りなんですよね。
> 決して、PMBOKやWBSを作っている人が「知識ばかり詰め込んで知恵のない愚か者」かどうかの確認はなされずに「知識より大切なのは知恵だ」と印籠をつきつけてやっつけるわけです。
ここに関しては、指摘があれば次回のコラムで活かせばいいと、
開き直って書いています。PMBOKやWBSを上手く使いこなしている人であれば、
意味は通じるだろうと決め打ちで書いてます。
上手く使いこなしているであろう人からコメントが付けば、
逆に教えを乞いたいところです。
コラムのような書物だと、読む人に対して言葉を選べない。
なかなか大変ですが、チェスや将棋に似た言葉の手筋みたいなのがあって、
書いていて面白いです。
深く読んで頂いているようで、ありがたいです。
lav
pmやったことないけど、システムはできてナンボかなと。
とにかく、pmには柔軟性が求められると思ってる
公チキ
システムが動くのは、プログラムによって動くのであり、マネジメントやドキュメントによって動くわけではないというのが私の考えですが、
マネジメントやドキュメントによってシステムが動くかのようなことを言う人がいるのは、非常に残念に思っています。
というのも、私が新人だったころを思い出すからです。
新入社員研修が終わって初めて配属されたプロジェクトで、びっちり計画とドキュメントが作られていたのですが、プログラマが新人の私だけ。
しかも開発言語は、私が使ったことがないC++で、部内にもC++を使える人がいない。なぜ新人だった私がアサインされたかというと、学生時代にCとJavaをかじったことがあったため、とのこと。
分からないことがあると、常駐先の他社開発者さんに聞いてみたり、技術掲示板で質問をしたりしながら進めましたが、当然のようにプロジェクトは炎上、不具合多発。
炎上・不具合多発の直接的原因はプログラマであった私の技術不足なのは間違いないですが、プロジェクト総括ですべての原因は私にあるみたいなことを言われて、非常に悔しい思いをしました。
PMBOK、WBSも結構ですが、それを書いた人が自分でやってみろ、と言いたい。
昔のことを思い出したもので、失礼しました。
harikofu
真剣にPMBOKを勉強したことがありますが、それこそ、スキルレベル、人間同士の対立、想定外の事態へのフォローにまで踏み込んでいて、単純な理想論とは一線を画す内容に仕上がっているとは思いました。
ただ、確かにあれは銀の弾丸では無いですね。
PMBOK自体には、それを実務に落とし込む具体的な方法が無いので、プロジェクトの状態に合わせて作りこむ必要があって、作りこむためには膨大な知識と経験が必要で、そんな能力を持った人は稀で・・・
上手く使いこなせれば、とても良い考えだとは思いますけどね。
hage
WBS、PMBOKは非常に有用なツールですね。
プロジェクトを進める上でよく参考にしています。
ただ、納品物だから作らなくてはいけないとか、必要だから勉強しろと見聞きしますけど、そんな理由で使うから時間を無駄にするし、だから仕事できねーんだよ。
弊社によく作業漏れて問題を起こすSEが居るのですが、漏れがないか確認したいからWBSを勧めたら、あれはただの納品物で無駄だから書かないと。
なんでも良いんだけど、作業漏らすなよ！と言いたくて禿げそう。
通りすがりのPMコンサル
その通り！
PMBOKなど真に受けて愚直にEVMSなんで実践している企業の現場は，疲弊しています。
一番の問題はPMBOKは基本的にシングルプロジェクトしか扱っていないからです。
複数プロジェクト掛持ち，訳のわからないワーキンググループと会議，リリース済みの案件への緊急対応，上司への無駄な報告
このような複数掛持ち仕事の現場に対する解はPMBOKにはありません。
一つの仕事（例えば宇宙開発，兵器開発）だけに専念できるのであれば，まだ使えます。
一般の産業界では理想論に終わります。