「これは大変だ」はどうやって判断するのですか

仕事で隣に若い人がいます。

残念ながらまだ積極的に仕事にクチを出せる立場でも無い状態なので若干ぼんやり気味で様子を見てるけど、おもしろい質問が出てました。トラブルの調査で、不具合の元を探してほしいとの先輩の依頼。依頼の最後に「大変そうだと思ったら教えて」的な指示が出たのに対して…

「これは大変だ」というのはどうやって判断するのですか？

的な質問が……なるほど。そうか、わかんないか。わかんないんだろうなぁ。

大変な不具合である場合ってどんなとき？

自分が思う「大変だなぁ、これは…」というのはこんな場合です。

自分が作った部分で無いところに問題がある……人の作ったものを直す必要がある。
自分たちが作った部分で無いところに問題がある……自組織でない組織が作ったものを直す必要がある。
与えられた情報や環境などがすでに誤っており、自分たちだけでは手を出せない。
与えられた仕様や要件がそもそも間違っており、自分たちどころかお客さんですら手を出せないかもしれない。

もちろん、何かが起きてしまって、それが大損害をもたらすという「起きてしまったものの修復やフォロー」というジャンルはまた別にありますし、そちらは大変さが青天井になる（最悪、組織的に死に至るww 損害賠償や赤字作業で爆死する）場合もあるので除外しています。

まぁこんなところでしょう。要するに「自分だけでは手を出せない」「他人が関与する必要がある」場合がたいてい大変になると私は思ってます。過去の経験上。そして、他人度合いが強ければ強いほど「大変だなマジで…」となります。

平たく言えば行程を超えて手戻りする場合が大変

これって要するに「自分たちの作業フェイズでは無い」という場合がほとんどです。自分たちが使っている、共通処理を作った人（当然先に作ってるか、モックだけ作成して並行開発してる）という場合はぎりぎりフェイズは同じですが、違うチームです。細かく言えば行程は違います。

また、詳細設計レベルで参照するデータを書き間違え/考え間違えていた、なんて場合。これも1工程戻って手直しして、さらに、影響する箇所がほかにないか、といった調査が必要になります。設計を書いた人に意図も確認しなければなりません。

さらに行くと、基本設計やら要件定義やらで勘違いがあった場合。この場合だと、もうお客さんに「ゴメンナサイ」と言わずに先に進むことは不可能です。お客さんも、自分たちの上司や、実際に成果物を使う組織に「すみません、日程がずれます」と言わないといけないかも知れません。

要するに、行程を超えた手戻りが出ると、問題の影響範囲が広がるんですよね。1人で済む問題と比べものにならない人数、それも上層部の時間単価が高い人たちまでも含めて作業せざるを得なくなる。結局それは「開発費用」に影響して、赤字につながる。

そういうのが「やばい、これは大変だ」だと思います。

どうやって学ぶの…

結局のところ、これって失敗経験や、失敗を目の当たりにする（別チームがやってしまったのを傍から見てる…とか）で学ぶしか無いと思います。ぱっと見て、だいたいの問題の所在と責任範囲を特定して、修復に必要なメンバーや関係者、時間の概算（多いか、少ないか程度でOK）を見積もる。これができないといけません。ということは、物作りの時間見積もりもある程度はできないと規模感がつかめません。やはり、最初はわかんないものですね。こう思うと。

また、「大人が責任を持ってやってる仕事が何で間違えるんですか？」みたいなことを言う新人さんって実際居ます。が、間違えるんです。だから、「そんなことあり得ないでしょ」に対して「いやいや、あるんだよww」って言える/思えるようにならないと、やっぱり危険や被害の度合いを見積もるのって難しいんじゃないかな、って思います。

だから、若い人は失敗しても、それを経験として体験したと思えばいいんですよ。そして、その経験を何かに生かせるようになればいいんですよ。怖がらずにがんばってほしいものです。