要件定義・受託開発

違和感があれば、直接当事者に問いただすべきであって、他所であーだこーだと持論を述べるのは正しいやり方ではない、と考える一方、ちょっとこれは変じゃない?という小さな声が集積して、ある日、閾値を超え、世の中を一変させる可能性も信ずるに足る世の中になっていると思います。

長年、システム開発の仕事に携わってきて、ほとんど成功らしい成功を体験したことがないのですが、様々な失敗パターンは見てきました。技術や予算的な制約が理由として後付けされることが多いですが、結局のところ、あらゆる原因は人と人とのコミュニケーションの問題に終始します。

発注側は、プロジェクトの本質をいつまでも理解しない実装側に苛立ち、実装側は、ころころと要件を変えて要望してくる発注側を疎ましく思う。段々と会議で発言をするメンバーが減っていき、期限や構成の見直しを提案が出来る空気は無くなり、良いアイデアも出なくなる。来るべき破綻の日になるべく自分のダメージを減らすポジション取り合戦が始まり…。

発注側は、プログラミングやコンピュータに関して素人だし、実装側は、逆にシステムが実現しようとするビジネスロジックに関して素人です。お互い相手の領域が分かってないからこそ、パートナーとしてタッグを組む価値があります。このベクトルが正しく向いていれば、最初は途方もなく思えた課題でも意外に難なくクリアすることができます。