ホ・オポノポノと引き寄せとの違い
ホ・オポノポノと引き寄せとの違い（？）について先日内田博史さんのブログでね、すばらしい解釈を読んだ。
確かその解釈をさらにオレが解釈してｗ説明すると、ホ・オポノポノは、なんとかになりたいとかこうしたいとかそういう「こびりついた」願望をクリーニングして手放してしまいなさいと。そういうふうに説く。
一方引き寄せ（の法則）ってのは、多くの人たちが誤解しているとおりで、強く願えば、それは実現する！と。
でもホ・オポノポノは願望をクリーニングしてしまえという。どっちが正しいんだムギー!!!!!! みたいなことになる。
ま、そもそもそんなことでいちゃもんつけるようなヤツってどうしようもないんだけど、まあそれはおいといて。
その問いに対して内田さんは、こうなりたいと強く思え、願え、願ったら実現するぜ？などと引き寄せ（の法則）は一切いっとらんぞ、と。
「（すでに）そうなった自分を強くイメージする」んだと。こうなりたいと願うこととこれとはまったく違うんだ、と。
「だってなりたいと願うってことはなってないってことだろ？」ってこと。なりたいと強く願うってことは、「なってない自分」を強く引き寄せてしまうから一生「そうなった自分」にはなれない、と。
だから、そんなの手放しちまえっていってるわけ。
内田さんの解釈でいちばん素晴らしいのは、「そうなった自分」を強くイメージするのってかなり難しいから、初心者はホ・オポノポノのほうがいいぞ、とすすめている点。はっきりこういうふうに言える人って少ないんじゃないかな。
。。ここまでが前段！（長すぎっ）
本題。。
「引き寄せ」ってのはね、とある「それ」が実現する過程なぞ気にすんなといっている。それはもはや神の領域だから、みたいな。
「そうなった自分」を強くイメージさえできればあとは「何か超越的なもの」が発動するから、あとは待てばいいのだ、と。
。。ここなんだよね。これがウサンクサいと感じるヒトもいると思うのね。
だってさ！仕事で、プロジェクトとか発足したらまず計画！計画！スケジュール！！タスク管理！！！だろ？
それがさ「引き寄せ」になると良い結果だけイメージしてあとは運を天にまかせよ、みたいな感じじゃない。これがSEだったらクビだわな（笑
ところが！だねえ。若干「引き寄せ」のほうを擁護？させていただくとだね、さっき書いたとおりで「引き寄せ」ってのは、達成された状態をね、ディテールまでイメージ「できるまでになれ」っていってるわけ。
でね、これは相当キツいことなんだよ。まずさ、ほとんど一点の曇りもなく信じ切らないとそこまで、ディテールまでイメージできないんだって。
なのである意味「バカ」にならないとダメなんだ。リーマンとかが、夜の居酒屋でなく昼間シラフで「バカになる」ってのも相当ハードル高いんだよね。（それができりゃ、出世するよ）
でこれをシステム構築とかのプロジェクトにひきつけるとだねえ、イメージすべきゴールは、たとえばアンタらのガッツポーズしてる画とかさ、祝勝会してる画とかお客さんが笑顔でシステム使ってる画とか。。
そんなんじゃないんだよ？イメージすべきは。
アンタらがイメージすべき「そうなりたい自分」は実はシステムそのものなんだよ。なぜならアンタらはシステムをリリースさせるのが使命だから。アンタが祝勝会で酒飲むのがゴールじゃないから。客の笑顔がゴールじゃないから。
システムがリリースされること、そのものだから。
これ。。できるかい？って話なんだよ。PMが！
PMが、「システム」の完成形をディーテールまでイメージできるかい？
いやね、プロジェクトメンバーのSEならできるかもしれない。でも、システムの全体像をイメージできる人間はPM補佐におくべきだね。
ふつう、SEは、自分が担当するパートについての完成形はイメージできるが、全体像を俯瞰することは難しいに違いない。
PMが、ゴールすなわちシステムの完成形そのものをイメージすることができれば、大丈夫なんだよね。つーかね、PMはそこまでしやがれ！って話なんだよ。死ぬ気で。
さっき、ウサンクサいと書いたけど、そこまでやれば「過程を気にしなくともよい」という状態になる。（うまくやればｗ）
なぜそうなるかわかる？（わかんねーってｗ！）
あー長くなってきたからいいかげん終ろう。あのね、PMあるいは補佐がそこまで、ディテールまでシステムの完成形をイメージできるということは。
それを、末端のプロジェクトメンバーまで齟齬なく伝達できるということ。
ま、ふつーやるわね。キックオフのときに。
そうすると、メンバーは自分のパートだけじゃなくて全体を俯瞰してみれるようになる。それも当然だわね。バカじゃないんだから。
まあ伝え方は大事だけど。。
そこまで、一体感？みたいなのが「醸成」されたならば。
その時点で「計画」は済んでいるんだよ。
脳内ではね。
わかるかな？
まずPMや補佐の脳内では、そのシステムの完成形を、とあるリリース日までに実現するにはどうしたらよいか？の計画は、もうできちゃうわけ。そのイメージが詳細であれば、ね。もし粗々であれば計画も粗々になるわな。当然。
計画もね、できているけど、イメージなの。文じゃないのよ。パワーポイントやエクセルでもないのよ。
だから、最初の作業がそれの落とし込みなんだわ。
プロジェクトメンバーにあますところなくシステムの完成形のイメージを伝播させることができたならば、計画の落とし込みなんてみんなでわーっとやれば、できるよ実際。
だからなんつーのかなあ、言い方変えると「計画というアウトプットを出したくてしょうがなくなる」って言う感じかな。自然とそうなるの。皆が皆、イメージを紙の上に具現化したくてしょうがなくなるわけ。
わかるかな？
システムの完成形をイメージできたならば、あとは過程は「神にまかす」んじゃなくてね。それは絶対に間違っていて、「あとは物事はかってに動き出す」ってのが、正解。
トップダウンでもボトムアップでもいいんだけど、ハイブリッドがいちばんいいんだろうけどね、それぞれのパートの計画をまとめてボトムアップしつつレビューしてトップダウンのマスタスケジュールをマージしていくって感じかな。
ここで、PM補佐みたいな役割の人がすっげえ大事なんだよ。キーマンなんだ、プロジェクトの。PMはその補佐の作業に対してびしっと！判断決断をしていく、と。
そうすりゃ「事」はごろごろっと動いていくよね。それがまるで、神がやっていると思えるようなことも、たまにあるよ。ホントは人間の寄せ集めが転がしてんだけどな。
完成形をイメージし、それをするためには「どうしたらよいか？」のアウトプットを出せたら成功は約束されたようなもんだよな。あとはどうしたらよいか？をやってけばいいんだから。
