天童も大人になったらフツウの人。それにはいくつか原因があるようです。
有能な新入社員や若手をスポイルする現場にもあてはまるようなので、書いておきます。年末なのでデムパ大行進ですぞよ。うひょひょ。
新人に、既存プロジェクトのソースを見せたら、次々と問題点を指摘します。どれも妥当なもので、べテラン開発者も舌を巻くほどです。
しかし、修正案はすべて却下です。それは
動いているものには手を入れるな
という鉄の掟があるからです。
修正が他の問題をおこなさい、つまり副作用がないことを確認できるのなら実施してもかまわない。
開発者、実装者が単体テストだけでなく、結合テストまでも担当するというジサクジエンが日本の現場ではまだデフォルトです。
しかしこれをグローバルスタンダードからの逸脱と短絡的に自嘲気味に騙る人はあまり世界が見えていないのかもしれません。
さすがヤパーニシュ！
単体の仕様書には書かれていない結合時の仕様まで推論・演繹して実装者みずからテストしてしまうなうんて！
つまり実装だけテストだけの単能工ではなく、複合作業ができるマイスターがデフォルトだと評価する人々もいるということです。
おっと、話が半マイルずれました。軌道修正です。
とにかく単体でのバグがあるならさっさと直して結合テストしてもらえば、結合時の問題のほとんどはあぶりだされます。さっさとその問題を解消すれば、全体最適化になります。
ところが、結合時に起こりそうな問題をあらかじめ列挙して、ウンウン唸って修正し、中途半端な結合テストモドキをやってから正式の結合テストを受けるということは単なるスケジュールの遅延工作でしかないと、何度言っても分かってもらえません。
分かってもらえないというか、前者を実施できない理由は明確で、実装レベル単体レベルのテストをおこなう専任の部隊がいないのです。結合もいません。単体実装者が結合結果まで評価する有様です。
おっとまた話が半リーグずれました。軌道修正です。
いわゆる専門職にもジェネラリストの能力を求めるということはつまり、尖った特殊能力をスポイルするための方便なのです。
それをわざとやってるわけです。
もちろん、能力者ならば、ジェネラリストの能力くらいは簡単に盗んでしまえるわけですが、それを無駄だと思う天才君も多いわけです。
本質的な問題を見つけたのに、それを直すには、やたら細かい過去の経緯や、部署間調整が必要で、しかも誰がリスクを負担するかを決めるのに２週間かかるなんてことを言っているうちに競合他社にやりこめられてしまうのは明白です。
そして失敗は許されないが、怠慢はゆるされるという官僚社会なのです。
若くて優秀は人はすぐにどこかえ去ってしまいますよ、そりゃ当然です。
しかしそうしてまたお山の大将はお山の平和を守っていくわけです。
