他社と一つのシステム開発プロジェクトを共同で行う場合、
他社の開発標準にのっとって開発を行うことが多いです。
自社の開発標準がほぼ無いような状態のため、
消去法的にそうなっているのでしょうが。
今回は、開発標準も無いって、そんな会社ってどうなの？
という話ではありません。
開発標準って、
工程の考え方、各工程での成果物を定義してますよね。
アウトプットを有限の期間で効率良くこなすために、
プロジェクトの体制を形づくるわけです。
が、
基盤チーム、業務チーム、開発支援チーム・・・
とチーム編成し、各チームで成果物をきれいに分割して・・・
それだけではシステム開発がスムーズにまわらないですよね。
チームとチーム間には必ず仕事が落ちるものです。
いわゆる、ポテンヒットってやつですね。
色々な原因でポテンヒットが発生するわけですが、
ポテンヒットを事前に察知し解消する方法があります。
その方法とは、
他社の開発標準を読み込む
というものです。
特に、自社の開発標準と工程・成果物の違い、
チーム編成とチームの責任範囲をすり合わせてみることが有益かと。
開発標準を読むことで、「基盤チーム」と一概に言っても、
業務共通的な役割を大いに期待するような開発標準もあれば、
明らかに業務チームと役割を分けるべき、というものもあるでしょう。
つまり、開発標準に則って開発を行う経験を通じて、
開発標準の内容が各社員の常識になっている可能性は高く、
その常識のズレがポテンヒットを生む可能性の一つとなるというわけです。
開発標準のすり合わせ、是非実施してみて下さい。
意外と「当社の常識が非常識だった」ということがあるかもしれません。