バッチはshellの設計書がなぜかなかったのと、運用ツール(JP1)の設計書がどれが正しい最新かわからないって引き継ぎで言われてBPさんがいなくなったので動いている資産から仕様を起こした気がする。マネジメント関連は契約、調達以外のことは結構自分がやっていた気がする。終わった時やリリースするときに「なぜ次工程に進む(リリースする)ことができるのか?」を説明する会があって、これがあまり好きじゃなかった。記憶ではほぼ一回で通ってたと思う。資料を作るのにかなり時間がかかる。データを集めるのも大変。普段から集めとけよっては思うけど。好きじゃなかった一番の理由はこれじゃない。理由は「なんかもっと他にあるだろう」って言われることだった。私の報告はいつだって「当たり前のことを当たり前にやって当たり前に品質確保できてます。リスクや課題はあっるけど対処してます」という感じだった。すると聞く側(承認する側)は「いや、他に何かないの?」ってくる。「この部分(細かい正直どうでもいいところ)は?」ってくる。聞く側は何も言わないで「よしわかった、いいんじゃない」とは言えないのだ。これが出ると「条件付き完了」みたいなステータスになって宿題がでてやらないといけなくなる。経験も少なく、もっと広い視点でリスクを考えてみろって意味もあったとは思う。いい細かいところを指摘して多大な工数をかけてやり直したり調べたりさせるのはやめて欲しかった。こっちだって暇ではない。「当たり前のことを当たり前に」と書いておいてなんだが、それができなかったことがある。この頃は「プロジェクト」には書いていない別のシステムも保守しており、自分が開発を担当できない状況だった。軽微な変更をお任せしたかったので、バッチとオンラインと帳票とDBとができて(今考えると大したことないな。)って人を探していた。ところが大人の事情でとある会社に発注することが決まってしまった。スキルシート的なものや経験を見るとかなり不安が残る感じ。引き継ぎをしても全然わかっていない。請負契約だったので会社に是正してもらうように掛け合うもあまり改善せずに、どこかの工程で大きなミスをやらかして赤字覚悟で+2名を追加するもそれでも改善せず。(+2名はおじさんで、会社では偉い人で、開発者ではなかった)そうこうしているうちに、最初からいた人が長残業しすぎて体調を崩してフェードアウト。これ、どう解決したかあんまり覚えてないけど確か自分が稼働をあげて開発に入って全部やり直した気がする。それで最後にここの人に言われたのが「こんな扱いを(こんな若造に)されたのは初めてだ」だった。