「開発設計仕様書」を持ち出したのはプロジェクトを続けるための言いがかりなんだろうねぇ
はてぶが700越えですごいなーと思いましたが、それは棚に上げておいてシステムエンジニアのみなさんもかなり関心が高いことが伺えます。
ちょっと判決文を読みたいな、と思って探してみたけれどどこにあるのだろう。見つけられねー。
本来なら判決文を読んで所見をいいたところだけど今は元記事のブログで。ブログに記載されているとおり、
・原告 最大20対20の大人数のリアルタイムバトルができるという特徴を有する本件ゲームを開発しようとしていた会社
・被告 従業員
なんですね。従業員と会社で争っている。普通は、会社間で争うことが多いのにね。契約不履行とかで。で、今回は会社と従業員なわけです。
ブログの引用であったとおり、訴えることになった「開発設計仕様書」ですが、そんなのプロジェクトで決めますよね。作る作らないを。で、プロジェクトマネージャ、もしくはスクラムマスターは会社の標準に準じるかプロジェクトの制約事項（QCD）で準じないかを判断するわけです。
それでプロジェクト的には問題ないです。プロジェクトのキックオフをするタイミングでプロエクトオーナーの了承をもらっているなら。
そう、ここが気になるんですよ。POである上司はそれを承認したのかどうかが。
多分、そこは明示的に残っていないのでしょうね。さらに会社の組織としての成熟度があまり高くないのかもしれません。あくまでも憶測ですが。
＃間違っていたらごめんね
これも憶測の域から出ませんが、被告の二人が辞める際になってから後出しジャンケンで作れって言ったのでしょうね。つまり、訴えられた二人の頭の中にしかコンセプトやノウハウが残っていないということなんでしょう。
そうするとプロジェクトは頓挫です。いくら人を集めてもコアになるコンテンツが抜けてしまうから。
話を上司の承認に戻して、なんで上司の承認を持ち出したかというと、作業は労務管理者の指示でされるものですから、その労務管理者が作業指示していなければ作業のしようがない、と考えるからです。
残業にしたって上司である労務管理者の許可が必要ですからね。あれこれして、というのは上司なんですよ。そういうロールですから。
その指示が客観的なエビデンスとして残っていなかったのでしょう。もしあったらあったで、じゃあ、上司は指示した後に「開発設計仕様書」を作っていることを確認しなければならないし、それを確認したら指導しなければならないもの。
一方。被告の、というかプロジェクトチームは「開発設計仕様書」を作るスケジュールに変えないといけないわけだ。
その観点から、素人ながらも妥当な判決かな、と思うわけです。
