波動の次元

■ 「合わない」

→ 器が合わない

→ 波動が違う

→ 認知的不協和

 

■ 波動が違う

→ いずれ決別する

 

■ 協和するには

→ 自分が波動を合わせる or 同じ波動を持つ環境へ移動

 

■ 同じ波動

→ 話しててワクワクする

 

■ 引き寄せ

→ 意識を波動の外に出す

→ 「このままなら俺は波動の法則で外に弾き出る。

     俺を弾き出すならもっと苦労するだろうし、

     どうするのか高みの見物」という感覚。

→ 察知して環境側が波動を上げようとすれば、

     協和に近づく。

     結果、引き寄せ、ということになる。

時代を読める人間

このご時世、

「時代」は若い子の方がよく読めている。

 

老人は成功体験に縛られ、

時代を読む感覚を失っている。

 

自分の違和感を殺して老人に従った挙句、

失敗体験を積んでしまえば、

若い子が、

若いなりに自分の感覚で何かをしたい、

という感覚は当然である。

 

もうこの時代は、人の上に立つ人は、

嘘でも、若い感覚を持てる人間でなければ成り立たない。

 

自分の身の振りを考える瞬間である。

 

また辞めるんだって

異動先の部署で、

また人が辞めるんだって。転職だって。

 

見送る側から見送られる側になり、

また見送る側になった。

 

もうダメかもしれない、この会社は。

どうしたものかね。

 

超優秀で、元気な人だった。

 

前の部署よりは良いけど、

やっぱりマネジメント層に問題があって、

それが不満だったのかなと思う。

 

どうしたものかね。

炎上プロジェクトいろは

残念ながら、また外れくじに当選してしまったので。

逃げ方のまとめ。

 

■ 要約

① 頑張って成功しないプロジェクトを頑張らない

② 余裕ない感だけ出しながら、実は余裕のある見積もりをして、自分のタスクだけは確実にこなしておく

③ 自分のタスクが終わりそうにない & 自分だけが終わりそうにない、なら、ギブアップ宣言して投げる

④ プロジェクトの炎上はPMのせい。

大炎上するようなプロジェクトのPMはそもそも無能なので、進言したところで正しく受け取られない。そんなPMなら炎上していない。

貴方がPMに取って代わる以外、このプロジェクトに道はない。でもそんな風に上司の顔を潰したら、何されるか分かったことではない。

⇒ プロジェクトのことではなく、自分のことだけ考えよう。「私は言われたことはやってました」状態にして、責任は仕事を投げてきた人に転嫁しよう。

 

■ 特徴 ＝ 頑張るだけ損

・ タスクを消せば信頼が上がる

・ 信頼は上がるが他の人の仕事も降ってくる

・ 消すだけ仕事が増える

・ そのくせ、終わらなければ自分の責任

・ どれだけ人より消したかは評価されない

 

■ いつも通りやらない

プロジェクトが炎上したら、

仕事の捌き方を全く別方向に切る。

普段はバリバリ、炎上したら防御に全振り。

 

■ 進むのか、逃げるのか

もちろん、頑張るという選択肢もある。

⇒ プロジェクト全体の命運をコントロールできる【立場】にあるか、だけ考える

 

自分が頑張ってプロジェクトが成り立つならやればいい。

たとえばPMで、そこそこ人事権があるなら、

人のやりくりでどうにかなるかもしれない。

 

でも自分がただのプレーヤーで、

PL、PMがどうしようもないなら、これはもう無理。

 

どう見てもこれは頓挫すると察知しても、

聞く耳持てない上司が上に付いたら、

やることは「保身に回る」ことしかない。

 

潰されないように仕事から逃げて、

失敗の責任は上に投げ返す。

 

 

■ 逃げ方

① まず形だけ残業しとく

物理的なキャパを減らす。

残業してない⇒残業してくれる？

は常套手段なので。

炎上プロジェクトを引いたら、もう残業は覚悟するしかない。

でも一生懸命やる必要はない。

 

② 遅れ気味、感を常に出す

1番早く終わっている人に次の仕事が回る。

自分のタスクで精一杯、

まわりを助ける余裕ないっす、

本当に申し訳ない感を全力で出す。

 

③ チキンレースに勝て

これが1番難しい。

やばい雰囲気出始めると、みんな①②になる。

一生懸命頑張って周りを助けようとしてくれる人は、本当にいい人。

大体は、みんな周りから飛び出ないように、

進捗スピードが揃っていく。

 

理想は、実は自分のタスクはやっておいて、

終わってないフリをする。

 

周りが終わり始めた頃合いを見て、

「終わりました」のカードを切る。

 

けど、本当に終わりそうもない時の立ち回りが難しい。

次の④か⑤か見極めて動く。

④か⑤かの判断は、

「自分だけ間に合わなさそうか」、

「みんな間に合わなさそうか」。

前者なら④でリスクヘッジ、

後者なら⑤でみんなで赤信号を渡る。

 

④ ギブアップ宣言

頃合いはマイルストーンの2週間前くらい。

残りのタスクと工数見積もりを積み上げて、

頑張ってはきましたが、

多分、無理です宣言する。

 

宣言が早いと、

「いや方法を考えて何とかしろ」で一蹴される。

 

どう見てもこれは無理やな、

というタイミングでギブアップ。

 

「挽回策としてこうさせて欲しい」

「人を当てて欲しい」とかは、

【一切言う必要がない】。

 

これを言うと、じゃあそうするから何とかしてね、で責任は減らない。

 

「無理です。私にはどうにもなりません」

「というかどうする気もありません」

「何とかしろと怒鳴られてもどつかれても、今以上に頑張る気もさらさらありません」

「叩いても私からは何も出ません」

オーラを出して、「無理です」を言い続ける。

 

当然、評価と信頼は落ちますが、

これで【じゃあどうしよう、の責任範囲が、上に移る】。

 

cannot だけ伝えて、【Howは丸投げする】。

（というか、上司とは本来そういう仕事）

責任はHowを考えた人に常に降りかかるので、

それに従えばよい。

 

この世は、常に「折れて、譲歩を言い出した側」が弱い。

cannot → no！ → cannot → no！

→ cannot → ok… → じゃ、そゆことで

で、交渉は回る。

 

⑤ 納期延期待ちチキンレース

④の結果、納期延期、となることもありますが、

ここでは、自分からギブアップしないで、

環境が変わることに賭けることをさす。

 

みんな、間に合わないこと分かっていながら、

矢面に立ちたくないから、

周りの様子を見ている感じ。

 

もはやギブアップするまでもなく、

どうせこのプロジェクトが立ち行くはずないから、

もう諦めて傍観者に回ってる感じ。

 

こんな雰囲気なら、波に乗っていいかもしれない。

 

 

■ ④か⑤かの囚人のジレンマ

ここの見極めがとにかく難しい。

 

⑤と思っていたら、みんなパタパタとギブアップして、1人危機的状況になることもある。

周りが余裕そうに見せて、こちらの④を誘っている場合もある。

 

⇒ 解決策:

    隠密コミュニケーション

 

上司抜きでこっそり話して、

【間に合わせる気がまだあるのか】

【もう諦めムードなのか】聞いとけ。

 

ギブアップするタイミング合わせて、

みんなで言えたら1番いいよね。

 

 

■ 責任は、仕事を投げてきた人に返す

真面目な人は、仕事ができないのは自分のせい、と考えがち。

それはすごく良い。

 

けど、炎上プロジェクトでは、

その考え方は搾取される。

 

炎上したら、その考え方やめよう。

 

仕事を振ったら、振った側にも責任がある。

新人にバカスカ仕事を振って、失敗したらそれは振った側が悪い。

 

うまくいかなかったら、

「振る相手」「振る量」を見極められなかった、

という意味でその人にも落ち度はある。

 

だから、そこを攻めよう。

「期待に応える」必要はない。

それは、振った側の、本来外れた読みも、正当化してしまう。

 

外れるべき読みは、外していい。

逆に言えば、振った側の読みを、当たりにするか外れにするか、は【こちらが握っている】。

 

やらん、と言えば、問答無用で外れにできる。

やりたくないことはやらないと決めれば、

振る側の期待値は次第にそこに収束する。

 

期待に応え続ければ、

次第に期待値は自分が無理をした状態になってしまう。

 

自分がちょうど良いところに、

向こうの期待値を教え込むのが正しい。

 

 

 

 

 

 

 

 

粒度

■ オブジェクト指向

いまだによく分からん。

 

概念は分かる。

あるべき姿も分かる。

ルールズも分かる。

 

が、具体的な正解をいつも示してくれないから、

結局、書くときに困る。

 

やれ、一行メソッドが理想だの、

やれ、犬だの、花子さんだの。

 

そんなことは知っている。

こっちが困っているのは、

レビュアーによって美しさの定義が違うこと。

あの人たち、オノレの美学持ちすぎ。

 

こちとら、誰の目にもそこそこに映る、

「まあオブジェクト指向」的なコードが書ければそれで良い。

 

 

突き詰めたコードにすればするほど、

アンチから攻撃受けるから、

ほどほどで、そこそこ万人受けするコードが書きたい。

 

そういう実学的な教科書が全然ない。

「美しさナンバーワン女優は有村架純だ！」

的な、「んなもん人それぞれだろ」的な内容を、

さも「これがソフトだ！これ以外はコードじゃねえ！」みたいな

論調で振りかざす記事ばかりでどれも参考にならない。

 

 

■ とりあえずたどり着いた答え

⇒ テストやれ

⇒ 1週間後に見て単体テスト書けるようなコードにしとけ

 

ソフトは何かを実現するものであって、

アートではないので、

「確実に動くこと」が正義。

二の次的に、メンテしやすければ、なお正義。

そして、他人が見て読めれば、もうそれで良い。

 

目玉焼きに醤油かソースかみたいな議論は、

どっかの掲示板でやってもらって、

「確実に動く」を突き詰めれば、

それはテストが動いてるってこと。

 

自分がこれのテスト書かなきゃいけないって思ったら、

何百行のメソッドなんて、普通書かない。

テストコード書かないからそういうコードが書ける。

 

後でなるべく簡単にテスト書けるように、

って考えたら、

自然とテストしたくなる所で関数分けして、

複雑なところには結局何ができれば良いのかコメントでメモ書きを残して、

ほどほどにやる。

 

で、テストきちっと書けるコードで、

テストも書き終わってるコード見せられたら、

誰でも、とりあえずは「うん」って言うよ。

 

あとは「欲を言えば」の議論なので。

 

だからテストだけ意識しとけば良い。