知の更新頻度の危うさと知の価値の目減りをソーシャルネットワークで回避する
一昨日から昨日に掛けてのツイッターを主に介したやりとりは、とても理想の形でコミュニケーションが取れたのではないか、と思っている。
私素人なんですが、私の知っていることとだいぶ違うような気がします。勉強不足でしょうか。 / “PMBOKでのアジャイルの位置付け｜ウォーターフォールだけじゃない | PM NOTES” https://t.co/OaRxxqjXme
— ふみさん (@finayama) August 15, 2018
発端は引用しているブログだが、ネタふりをしたのは自分である。ただ、誰か特定の人（この場合はプログ執筆された方）にというつもりはなく、広くエンジニアが元のブログ記事を読みどのように捉えたか、その感じ取った感想やお持ち合わせの意見があれば聞きたいという意図があったかどうか…今となっては後付けになるのでアレだし、そんな勝手に思っている期待はこれまでのエントリに書いてきたように言語化していないので伝わらないのは自分が一番よく知っているのである。
はじめまして。記事を書いた者です…突然のコメント失礼します！
— やすぽん＠起業したいPM (@yaspontax) August 16, 2018
個人見解や経験則で書いている部分はありますが、基本的に事実に即して書くように努めておりますが、誤りがあれば、修正しますので、ご指摘頂けるとありがたいです！
やすぽん＠起業したいPM さん（以後やすぽんさんと記す）から通知をいただく。ご本人の書かれた記事の根拠、背景を示しつつ、おじさんの意見を聞きたいという好青年感を感じる内容である。
話がそれるが、おじさんになると若い方から率直な意見を求められたり、考えられているご意見や考え方をストレートにぶつけて貰える機会はがっくりと減ってしまう。仕事上であるだろうと思われるかもしれないが、それはあくまでも仕事上のスコープが限られた中での意見であって、ご自分の経験知や形式知をやり取りする議論の範囲を制限せずに交わせるのはとても貴重なのである。
幸い、自分はコミュニティに属していることもあり、自分より若手（と言っても40代、30代が多いがそれでも10歳くらい違ったりする）ばかりな上に、メンバ一人ひとりがスペシャルな技術力を持たれているので刺激を受けている。そういう意味においては、若い方の考えを聴き、どうマージして活かすか（聴いた意見の方が良ければ即差し替えるか）を繰り返ししているので場馴れの機会をもらっている。
話を戻して、今回のツイッターの通知も自然とその流れで受け止められた。まあ、これもこちらが勝手に思っていることなので、通知のリプを返ってくるまでやすぽんさんは気が気でなかったかもしれない。
ツイッターも（何かしらやりとりした関係が作れていれば）穏やかなコミュニケーションを取れる関係もあれば、バカみたいにマウントを取ろうとしたり、disり、批判することに全力を投下している方もおられるのを見る度、ご苦労を忍ばずにはいられない（意訳）。
そういうこともあって、昨日のエントリでPMBOK警察をするつもりがないと書いたのは、そういうつもりは毛頭ないよ、と意思表明したのである。
さて、自分の専門がプロジェクトマネジメント であるから、クラスタ的にもその界隈になる。そうした自分のクラスタに自分から出向いているとしてもメンバが固定していれば話題が次第に固着してくることは否定できないだろう。そうなると知識の更新頻度が下がってしまう。これが拙いし危機感を感じざるを得ない。
エンジニアが自分の専門性を研鑽し続ける手段としてのコミュニティがあったとしても、自ら登壇するなり、LTをするなり、意見なり考え方を言語化しないとただ溜め込むだけで、知の価値に利息が増えないどころか価値が減っていく。
上述の2つの危うさ、知識の更新頻度に対する危機感と知の価値の目減りについてをいかに回避するか。これはもう、ポジぺを示して、ご意見をいただくしかないのである。
エンジニアが気軽に、御相手を自分と同じエンジニアとして意見交換するためにソーシャルネットワークを使うのはなかなか理想的ではないかと思う。
社内のポジションが変わりプロダクトマネジメントに携わるようになりました。その界隈の方（僕がお会いした方だけかも）と会うとPMBOKに対してウォーターフォールにしか適用できないと捉えている方が多く、苦労してPMPを取得した身からすると、自らの理解を深めながら発信したいという思いでした。
— やすぽん＠起業したいPM (@yaspontax) August 17, 2018
まあ、後付けの理屈であるが、今回のツイでの意見交換はとても良いものであった。プロダクトマネジメント に関わられ、お悩みも多々あるのであろう。PMPも取られていていて知識を持たれているからお仕事上で感じることも多いのだろう。
都内であれば一度飲むと楽しい会話ができそうである。
![ワイルドターキー アメリカンハニー リキュール 35.5度 1000ml ■成分由来のオリあり [並行輸入品]](https://images-fe.ssl-images-amazon.com/images/I/319rAd%2BkAxL._SL160_.jpg "ワイルドターキー アメリカンハニー リキュール 35.5度 1000ml ■成分由来のオリあり [並行輸入品]")
ツイートへのアンサー、若しくは、PMBOKのお勉強
昨日、こんなことを呟いた。そうしたらリプをいただいた。
はじめまして。記事を書いた者です…突然のコメント失礼します！
— やすぽん＠起業したいPM (@yaspontax) August 16, 2018
個人見解や経験則で書いている部分はありますが、基本的に事実に即して書くように努めておりますが、誤りがあれば、修正しますので、ご指摘頂けるとありがたいです！
『知っていることとだいぶ違う』あたりに反応いただいだのだろうか。
すこぶる、恐縮である。
最初にお断りをしておきたいことに、正しいとか誤っているとかを述べてはいない。自分とは違う見識をお持ちなので、そう言った違いを知ることは、ついつい、一つの視点からしか見ないことが多い中で、違う視点を知ることは勉強になるのである。
（多分）私よりお若い方だと思われる（想像）が、お若い方の考えは気づかされることが多いという自分の経験知もある。
以下については、そうしたことを踏まえ、では一緒にPMBOKあたりのことを勉強しなおしてみるのも良いのではないかと思い至ったのでそれで進める。
重ねて申し上げるがPMBOK警察をするつもりはないので。
実は、PMBOKはウォーターフォール型に限ったものではないのです。
従来からウォーターフォール型のみを対象としていた訳ではなく、プロジェクトマネジメントが建設業や製造業において開発されてきたことに由来して、プロジェクト規模も期間も非常に大きく、基本的に後戻りが許されない為、単純にウォーターフォール型のプロジェクトマネジメント手法がマッチしていたと言えます。
この段落を要約すると『PMBOKはウォーターフォール型のプロジェクトマネジメント手法がマッチしていた』 にできるかと思う。
昨日のエントリに引用したがPMBOK 6rh edition及び５th editionを読む限り、記憶でいえば初版本の1996年版、2000年版、2004年版も含めてとなるが、ウォーターフォール型のプロジェクトマネジメントという考え方は記載されていない。
PMBOK 6th editionをご覧になっていただくとわかるが、ウォーターフォール≠PMBOKであることがわかり易く図式になっているので見ていただきたい。
プロジェクトライフサイクルがシステム開発であれば、システム開発手法に当たる。自分が、この図を見て理解し納得しているのは、PMBOKはプロセス群を介してシステム開発のプロジェクトライフサイクルをモニタリングし、コントロールしているだけに過ぎないことも昨日書いた。
引用 PMBOK 6th edition
以上から、概念としてプロジェクトマネジメントとシステム開発手法は同じレベルにはないというのが自分の考え方である。ウォーターフォール型のプロジェクトマネジメントという捉え方とは、少し違いがあることがわかった。
しかし、インターネットが普及し、ビジネスにおけるIT活用が当たり前の時代に突入し、システム開発のニーズが高まり、案件数が爆発的に増えてきたことで、IT業界にプロジェクトマネジメントが入ってきて、従来の建設業や製造業でのプロジェクトマネジメント手法であるウォーターフォール型の手法をそのまま適用することになったのだと思います。
引用 同上
ところでPMIの設立はいつだろうかと調べると1969年なのだそうだ。もう少しあとかと思った。
PMIは1969年に設立された。PMBOKなどのプロジェクトマネジメントの標準の策定、PMPなどの資格認定などを行っている。
日本には、PMIの日本国内唯一の支部である「一般社団法人 PMI日本支部」(PMIJ)がある。1998年1月に「PMI東京支部」として設立されたが、2009年1月1日に現在の名称に変更した。
プロジェクトマネジメント協会 - Wikipedia
PMBOKは96年版が第1版である。こちらも調べてみるとそれより前にホワイトペパーが出ていたのだそうだ。
PMBOKガイドは、最初、1987年に米国PM学会によってホワイトペーパーとして出版された。その目的は、広く適用できるプロジェクトマネジメントの情報や実践方法の、文書化と標準化であった[2]。
ホワイトペパーから第1版が出るまで10年かかっている。それはPMBOKが建設業、プラント、テレコム、製薬開発など多くの業界のプラクティスを集め、汎用的に使えるようにするためにはそのくらいの時間がかかってもおかしくない。
なにぶん、当時は今のようなインターネットが存在しない（ダイヤルアップくらいか？）。
参考までに建設とエンジニアリング会社のプロジェクトマネジメント例を引用する。
話を戻して、引用したブログを読みながら前に調べたウォーターフォールの起源を思い出した。『DoD-‐2167A』で検索すると少し勉強になる。というか、なった。自分は。あと、参考になる論文があるのでこちらも見ていただきたい。
自分としては、IT業界がウォーターフォール型の『システム開発手法』を取り入れたのは、HWを米国から輸入してた経緯もあり、SW開発手法も同時に輸入した際に、『DoD-‐2167A』をベースに開発していた手法を持ち込んだのではないかと思っている。この辺りも元のブログの記事とは理解の違いがある。
元ブログの先もまだあるが、上述した2点の違いを感じたので先のツイートとなっている。ご理解いただければ幸いである。
![フロリダ・プロジェクト 真夏の魔法 デラックス版 [Blu-ray]](https://images-fe.ssl-images-amazon.com/images/I/61pEUGek3uL._SL160_.jpg "フロリダ・プロジェクト 真夏の魔法 デラックス版 [Blu-ray]")
フロリダ・プロジェクト 真夏の魔法 デラックス版 [Blu-ray]
- 出版社/メーカー: TCエンタテインメント
- 発売日: 2018/10/03
- メディア: Blu-ray
- この商品を含むブログを見る
PMBOK＝ウォーターフォールだなんてPMBOKのどこにも書いていない
私、素人なんですが私の知っていることとだいぶ違うので勉強不足かと自分を疑っている。
ということで、少しPMBOKをお復習いしよう。自分の不勉強さを気づかせて復習することを促してくれるのは割とマジでありがたい。思い込みというバイアスがあるためだ。
PMBOK６th edition (JPN)が手元にあるので『ウォーターフォール』で検索する。
検索結果は見てのとおり、6件しか出てこない。
それでは比較として『アジャイル』で検索を行う。
『アジャイル』というキーワードは75件もヒットする。実は過去のエントリでPMBOK 6thではアジャイルのあと扱いが大きいと書いた（記憶がある）。確か5th editionの10倍もないくらいたっだはずだ。
＃参考までにPMBOK 5thでのウォーターフォールは1件しか検索がヒットしない。アジャイルだと10件である。
引用 PMBOK 6th edition JPN P135
PMBOKはプロジェクトマネジメントの手法であって、システム開発手法などとは違う。もともと、建設、プラント、製薬開発、テレコムなどの多業種のプロジェクトにおいて、経営にインパクトを与えるような状態になっているかどうかをモニタリングし、コントロールするマネジメント手法でしかない。
それゆえ、PMBOKでも『開発アプローチ』と言っているのだ。さらに、それを図示しているのを下図で確認できる。
引用 PMBOK 6th edition JPN P18
図では、PMBOKのプロセス群がプロジェクトのライフサイクルに対し、使用可能性（適用できるかもしれない）と紐づけているだけである。かもしれない＝テーラリングせよ、と解釈すれば良い。
プロジェクト・ライフサイクルをよく眺めてみるとウォーターフォールのウの字もないし、アジャイル開発のアの字もない。そこには採用する「開発アプローチ』をPMBOKをプロジェクトマネジメント として適用する者がいい感じに当てはめれば良い。
さてここから本題である。いつも言っていることだが、ウォーターフォールは開発アプローチでしかない。PMBOK＝ウォーターフォールやアジャイルではない。
そろそろ、エンジニアのみなさんにおいては、これをご理解いただけると手間が1つ省けるのでご協力いただきたい。
プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2018/01/01
- メディア: ペーパーバック
- この商品を含むブログを見る
紙の本はものすごく評判がよろしくないな。
エンジニアの悩みを99％解消する方法
エンジニアに限りませんが。これはプロジェクトマネジメントのリスクマネジメントを学んで『あ、そーか💡』と腹落ちしたというか目から鱗した。
そう言えば、リスクマネジメントのセミナーを竹橋あたりで受講したのはもう10年以上前のような気がする。もともと、PMBOKのリスクマネジメントでリスクマネジメントのセオリーを学んだつもりになっていたが、多分、今一つの理解だったのだろう。そのセミナーの資料の概要はPMBOKで知っていたことを概念的にはなぞっているように聞いていたが、自分自身が理解不足のところで『あ、そうか』と妙に納得したのだ。
前振りはこのくらいにしておこう。
エンジニアもプロジェクトマネージャもスクラムマスタもプロダクトオーナもマネージャもイライラしたり、不安になったり、疑心暗鬼になることがある。そういった心理状態になるのは、進捗の実績が思っているように上がってこなかったり、チームのコミュニケーションが悪化したり、メンバ間の隙間が広がって情報共有ができていなかったりすることで感じる。
問診
あなたがイライラしたり、不安を感じたり、メンバを疑ってしまうことはどういった事象が起きると感じるか。
診断
メンバや部下に対して問診で尋ねた感情を感じることがあれば、その原因はその感情を感じる相手にあるわけではない。その感情を感じる事象に対して、自分がコントロール出来ないことに対してイライラや不安を感じているのである。
キーワードは、事象に対してコントロール出来るか、コントロール出来ないか、である。
処方
自分でコントロール出来ない事象に対して、リソース（気を揉んだり、悩む時間）を使わない。
これではまだ、イライラすることや疑心暗鬼になってしまう場合は、次の対処を行う。
イライラ、不安、疑心暗鬼を感じるのはあなた自身である。それは、コントロールの効かない相手に対して『期待』をしている。それを理解すること。
期待を伝える
イライラを感じる相手はワザとイライラを感じることをやっているわけではない。相手のベストエフォートでやってくれている。ただ、あなたの期待を知らない。それはその期待を伝えていないあなたが説明しないと未来永劫解決しない。
次のプロシージャで進める。
- まず、感謝を伝える。相手がいなければその期待は実現しないのだから。
- 期待（期待する完成時の状態、期待する完成時期）を伝える。
- どのように進めるか、相手の段取り（進め方）を教えてもらう。
- 次にどのタイミングで教えてくれるかを尋ねる。
調達 【2枚セット】iPhone8 ガラスフィルム iPhone8 背面フィルム TALENANA
iPhone8用背面ガラス
安全なプロジェクトマネジメントの知見は広がらない
組織内において、話題になるのは危なっかしいプロジェクトか炎上しているデスマのプロジェクトである。なぜなら、経営にインパクトを与える可能性を持っているから、マネジメントが『なんとかしろ』と口を挟んでくるためだ。
そう口を出してくるのは、経営に云々もあるが、事業担当責任者としてはキャリアに傷がつくので立て直さなければならないし、プロジェクトで赤字が出れば予算達成が怪しくなるのでやっぱり立て直さなければならない。
で、うまくいっているプロジェクトから人を剥がすなり、元エースだったマネージャを投入する。
SIerは撤退を考えない（結婚するより離婚する方が体力も知力も必要なのと同じ理由）から後がどうなろうがやりきらせる。後ろを振り向けば焼け野原だけである。
うまくやっているプロジェクトは人を取られ、さらにデスマのプロジェクトで赤字で凹んだ予算の穴埋めにプロジェクト内で留保しているリスク対策予算を供出しろと強制され、泣く泣くコンテンジェンシの原資を奪われる。
上手くやっているプロジェクトは健気である。多少上に向かって文句の一つもいうかもしれないが、上手くやっているPMは余計なことをしない。自分のプロジェクトを自分の理想となるように運営するために集中しているからだ。
そして、ひたすら、リスクの予兆を見逃すまいとリスクの芽を潰す。
リスクは、課題管理の中で芽を出すし、日常の進捗の滞りの中でも芽を出す。顧客の不用意な発言からも芽を出すし、作業手順上の転記からでも芽を出す。
あちらこちらから、機を狙って芽を出そうとする。リスクはマイナスなリスクがほとんで、ごく稀にプラスのリスクの芽を出すこともあるがほとんど気付かれない。
いずれにしろ、上手くやっているPMはリスクの芽がないかを探すことに集中する。
結果、プロジェクトは安全に進捗する。デスマのプロジェクトに人を取られようが、予備の予算を削られようが、リスクの芽を摘むことに集中しているので安全が保たれる。
マネジメント層から見れば注意をするのはデスマのプロジェクトであるから、安全に進行しているプロジェクトは気に止まることはない。デスマをリリーフしたPMだけが印象に残り、デスマ対策だけがプロジェクトの知見としてまとめられ、遺構となる。
若しくは、ガチガチの管理で箸の上げ下げまで指示され、リスクを回避するオペレーションが要求される。まあ、なんてことはない。どれも似たような外郎のようなプロジェクトマネジメントと低粗利のプロジェクトが仕上がる。
さて、どこに安全なプロジェクトマネジメントが広がる余地があるのだろうか。マネジメントが評価しなければならないのは安全にプロジェクトをマネジメントしたPMなのだが。
矯正箸 正しいお箸の持ち方 しつけ箸 漆塗り 【男性用】男箸23.5ｃｍ（右手） お箸の持ち方 トレーニング 箸使い 三点支持箸
- 出版社/メーカー: 卯るし庵
- メディア: ホーム&キッチン
- 購入: 2人 クリック: 2回
- この商品を含むブログを見る
矯正箸 正しいお箸の持ち方 しつけ箸 漆塗り 箸使い お箸の練習【大人用】【女性箸】 (右手(利き手)/20.5cm) 三点支持箸 どや顔サミット 品格
- 出版社/メーカー: 卯るし庵
- メディア: ホーム&キッチン
- 購入: 1人 クリック: 1回
- この商品を含むブログを見る
