随筆（2020/11/14）:書いたり、人に話したりすることは、自分と世界の間を耕して開拓する行為

1.書きながら、書くべきことが、顕（あら）われて来る

自分で何か

「だって、思いついたから」

ということがあり、思い付きを書くこと、あるじゃないですか。

＊＊＊

そのうち、

「あれ、これはつまり、こういうことなのでは？」

とか、

「これだとよく考えたらつじつまが合わないな。どうすれば話が通るんだ？」

とか、書きながらどんどん加筆修正していく。ということも、あるじゃないですか。

＊＊＊

これは会話でも、喋っているうちに新しい論点が増えていくことがしばしばあります。

（話に付き合ってくれている人たちには、具体的には母や弟君には、感謝しなくちゃいけないな）

2.何かするときは、自分でも何やってるつもりなのか、分かってないことが多い

最初に計画を立ててやって、成果の良し悪しが並んでから後で直す、古典的な品質管理モデルとして、PDCAサイクルがあります。

また、要件を洗い出し切ってから設計、設計し切ってから実装（プログラム作成）の工程に入る、古典的なソフトウェア開発モデルとして、ウォーターフローモデルというものもあります。

＊＊＊

これらを呼吸のように採用していると、大きな問題に直面します。

実は、しばしば、何かするときは、自分でも何やってるつもりなのか、分かってないことが多い。

だから、最初に計画を作りこみ、

「ここまでとする」

と、後で

「そんなつもりじゃなかった」

とか

「これをやらねばならないことが判明した」

とか、そういうのが頻出するのです。

これはウォーターフローモデルと相性が悪い。PDCAサイクルのP（計画）の段階とも相性が悪い。さて困った。

3.ウォーターフローモデルやPDCAサイクルには一定の意義があるし、それらは貫徹を目指すことに意味があるが、実際には貫徹出来ないことは織り込み済みでなければならない

「やるべきことを防ぎ切るために、要件等を洗い出して計画を立てるんだよ」？

そうですね。確かにその心意気でやらないと、

「最初からいい加減な計画でよい」

というナメた姿勢になり、結局メチャクチャになる。心意気は大事だ。

が、その姿勢で、要件等が洗い出せて計画が立てられるの、まあ6～7割くらいじゃないんですか。

3～4割に比べたらマシと言うべきだが、ある程度大きいプロジェクトだと、10割となることはまずない。

＊＊＊

逆に、

「そんなことを最初から要求している訳ではない。そんなことは不可能だ」

という姿勢で、ウォーターフローモデルを丸ごと採用するのもよくない。

ウォーターフローモデルは、そういうつもりでやっている限り、大した効果は期待出来ないものだからだ。

＊＊＊

そもそも、ウォーターフローモデルを採用している理由は、進捗管理の単純化と、前工程までの品質の確保と、手戻りの最小化だ。

じゃあ、前工程までの品質は、出来得る限り確保されねばならない。

先ほども書いたように、10割のつもりで作って6～7割しか出来ないの、よくあることだ。

じゃあ、10割でなくてもよいつもりで作ったら？　3～4割しか出来ない。ということになりがちだ。

手戻りを認めるスパイラルモデルだと、この手の問題がしょっちゅう起きるし、これでは最終的にプロジェクトが爆発四散する羽目になる。

そのために費やされた金や物や人手のリソースは、サルベージ不可能なゴミに化ける。

4.不適切なプロジェクトマネジメントは、関係者の心身を壊して、自死に追いやる

そういう爆発四散して残骸と化したプロジェクト、何度も巻き込まれてきた。

この道はいつか来た道。ああ、そうだよ。赤い血の花が咲いてる。

やめてくれ。俺はもう巻き込まれたくないんだ。

＊＊＊

自分の吐き出したリソースが、ある時点からほぼ疑いなくゴミに化けることが分かってて、それでもやる仕事、ある。

これ、神経や内臓をストレスでメチャクチャ壊すんですよ。

俺はたぶん一生残る持病になっちゃったし、これで前職（プログラマ）もやめちゃった。

もし運が悪かったら、そこで死んでいてもおかしくなかったはずだ。

本当に、今でこそ冗談めかしてこんなこと書いてるけど、当時は俺はこの世の地獄を味わっていたんだからな…

こんな地獄、スナック感覚でもたらされちゃいけないんですよ。

＊＊＊

しかもこれは、他の誰かが振り回した、品質管理モデルやソフトウェア開発モデルの不適切な運用のせいで、こんなことになった訳だ。

プロジェクトマネージャーは、自分の不手際で、関係者が心身ぶっ壊して死ぬのだ。ということを、まあある程度は覚悟決めて仕事してますよね。

だったら、せめてそこは、プロジェクトの破綻に向かうようなデタラメなプロジェクトマネジメントを、最初から極力避けて欲しいんですよ。

そういうの一番きらい。

5.他の代替的な品質管理モデルやソフトウェア開発モデルの話（をしたい訳ではない）

とはいえ、たくさんある代替的な品質管理モデルやソフトウェア開発モデルが、どれほど

「人間にもプロジェクトにも馴染んでいきやすい、素晴らしいもの」

であるかというと、それも何とも言えない。

（ついでに言っておくと、この記事全体は、古典的なモデルのよくある批判記事を意図している訳では全くない）

＊＊＊

例えば、観察・状況判断・意思決定・行動のOODAループというものもある。

これだと、状況判断や意思決定次第では、観察のやり直しは当たり前に行ってよいとされている。

明らかにこちらの方が状況とのすり合わせがやりやすい。

＊＊＊

が、実際にはこれをやると、観察・状況判断・意思決定に留まり、永遠に行動に行けないこともある。

永遠に行動に行けないプロジェクト、実践の手段として、おおよそ論外であろう。

もちろん、これはこれで解決されねばならない問題だ。

（実際には対策はいろいろ立てられているはずだが、今回の話の重点はそこにはない）

＊＊＊

そもそもやらない方がいいタイプのプロジェクトを、行動に移さないのは、もちろんデスマーチ爆殺四散プロジェクトを避けるためには大事な話だ。

とはいえ、それが多くのプロジェクトを、「めんどくさい」とか「びびった」とかの理由で、スナック感覚でホイホイとやめる言い訳にされているようでは、話にならない。

＊＊＊

やらなきゃ結果や成果は出ない。何にもならない。問題も解決されない。困ったままだ。それに耐えるの、嫌だ。ということはよくある。

そういう時は、問題は解決に近づかなければならないし、結果も出さなきゃならないし、それが成果につながらなきゃならない。

そういうことをするのなら、腹は決めねばならない。

＊＊＊

めんどくさくてびびると、立ち枯れを起こして苦悶の中で衰弱死していくしかない。

それを黙認する？　そんな無責任な。

生きる。そしてやっていく。休み休みにでも。それしかないだろう。

6.自分と世界の間を耕して開拓する行為は、どこにでもついて回る。やっていきましょう

適切な品質管理モデルや、ソフトウェア開発モデルの話は、さておくにせよ。

いずれにせよ、洗い出しはしなければならないし、それはありとあらゆる工程で避けられない。

洗い出すということは、顕（あら）われて来る、ということだ。

見えなかったが、やっていく以上は考慮せねばならない、様々なことが、自分と世界の間の見えない大地に埋まっている。と考えて下さい。

自分と世界が関わり合いになっていくことで、自分と世界の間の大地は耕されていくし、地下茎は顕（あら）われて洗い出されていく。

まずは、それを、収穫していこう。

そして、一定間隔で植え直して、土と水をかけるんだ。計画とはそういうことでもある。

それらがいずれ大きく芽吹いて、またたくさんのジャガイモをもたらしてくれるだろう。

来年の、再来年の収穫を、楽しみにしましょう。

＊＊＊

そんな訳で、自分と世界の間を耕して開拓する行為は、どこにでもついて回る。

やっていきましょう。