旅に出たい

ここ2カ月くらい残業が半端ない
昨日とおとといは午前様ｗ

無茶ぶりスケジュールでカットオーバー間際

Sierはどこでも工期短縮でし烈なしのぎを削っている
一つ一つの工程は100％にして次のステップに進むのが原則だけど、それは大義名分で、どの工程も複雑で不確定要素満載で変化の速い技術やあいまいな顧客要件にもみくちゃにされていて、どの工程も完璧なプロ不在のせいで90〜95％の品質で次の工程に引き渡している。
しかし、顧客に最後に納品する成果物は、明文化されているといないとにかかわらず、「完璧」であることが必要であるはずである。

契約で明文化されているような「完璧」なものやサービスを事実ベースでは求められている。

すると、上流工程から脈々と受け継がれてきている「90〜95％」の品質の下地は、最後には「100％」である必要がある（建前上は）

そうすると、途中工程から最終工程までの担当者の「だれか」が必ず前工程のしりぬぐいを強いられる。そして経験上、このしりぬぐいは「責任先送り」の風潮が徹底された大企業の「現場」では、ある特定の工程に「濃縮」されて顕在化する

オイラはインフラエンジニアだけど、たとえば受注（プロパー）、要件定義（プロパー）、設計（外注業者）、構築・実装（外注業者）、納品（プロパー）となっていたら、
これらのプロパーの行う工程は、長年の「伝統的な」責任回避ノウハウが成熟していて、前工程のしりぬぐいは華麗に先送りするノウハウが吟醸されている。つまり、プロパーの工程には先述のような「濃縮されて蓄積されたミス」をほどいて解決することはしない。
「濃縮されて蓄積されたミス」をほどいて解決するのは、途中の外注業者の工程となる。

具体的には、無茶な工期で受注したらいきなりプロダクトを発注してしまい、設計工程では、定性的でおおざっぱな要件（そもそも顧客とは定量的な要件がつめられてない）と納品されたプロダクトのリストをにらみながら、基本設計、詳細設計、構築・実装をする。
このようにおおざっぱな要件と信じられない速度で納品されたプロダクトの「山」の中でプロダクトひとつひとつにふくまれるマニュアルに書かれているプロダクトの性能を最大限引き出す方式や設定を「探し出して」これを設計書に落とし込んで実際に構築・実装する。
前も経験したことがあるのだが、プロパーはなぜか質問には受け答えしてくれない。
他の「無茶ぶり案件」も見てるからなのか時間が無くて忙しいらしい

ここ１か月の間で、このような業務のやり方で表出した前工程のミスをたぶん10個以上おいらひとりで発見して解決している。ここまでは「どの職場でも見られるいままでもずっとやってきたこと」でもう慣れてきたwが、ここ2週間で発見した前行程の「バグ」は超ド級だった。
Oracle DBの致命的な設定間違いを野放しにしようとしていた。
もしこの設定のまま納品されていたら、十分な性能が出ない、バックアップデータをリストアできないなどの結果を引き起こし、本番運用後に条件次第ではニュースに乗るような不祥事につながり「日本の恥」を世界に晒す可能性も「少なからず」あったかもしれない。

大きな声では言えないが

ていうか旅に出たい