概要

　私はSlerで受託開発とパッケージ開発の双方を体験したことをもとに、アンチパターンとして残したいと思います
誰が悪いとかではなく、私も含めて製品開発を理解していなかったゆえに起こる事象になります
なので、あくまでも私が体験した環境のみの話であって、業界を代表したものではありません
なお、これらの体験には何年か前の話も含まれているので、現状とは異なる場合もあります

前提条件

下記の「製品開発」はパッケージ製品およびWebサービスの双方を指しています

アンチパターン

人がいなくなる

開発が終わった途端、メンバーが他のプロジェクトに放出される
その理由は売り上げがないから人員を維持できないとか・・・
そもそも継続的に製品を改善していこうという姿勢ではない

対策

• 製品開発のライフサイクルを理解すること
• 長期的なロードマップを立てる

安易な機能実装

要望に対して安易な機能実装を行うことで、顧客によっては無駄な機能だったり、使いづらかったりする
また、持続的に保守をしなければないため、場合によっては運用負担が大きくになる
実装が悪かったり、仕様がわるかったりすると後の機能拡張にも影響を及ぼす

対策

• 特定の顧客のニーズに捉われず、製品全体にとって有意義な実装を目指す
• 製品ビジョンにあった機能実装

安易なカスタマイズ

売り方や契約によりけりですが、顧客別にカスタマイズを行うことでそれらをすべて保守していかなければならない
製品バージョンアップ時にそれらがバージョンアップできるかの保証もしなければならないので、運用コストが大きくなる

対策

• カスタマイズをしない
• CI環境を整え、運用コストを抑える
• 製品と切り離した売り方や契約にする

ニーズをすべて実装しようとする

顧客に言われるがままに機能実装する（使われもしない機能も含めて）
それと同じ感覚でニーズと思われる機能をすべて実装しようとする

対策

• 製品のビジョンを立てる
• スモールバッチで実装（仮説検証も含めて）

ビジョンなし

機能的な要素でしか、製品を捉えていない
製品に目的がなく、「〇〇ができる製品です」としか言えない

対策

• 製品の目的を明確にすること（会社の将来像や経営方針と合わせて考えるのがいいかもしれない）

儀式

製品のバージョンアップをしたい時に、都度バージョンアップするためのプロジェクトを作らなければならない
プロジェクト開始レビューこそはないが、リリース前にリリースレビューを都度役員にしなければならない
こうした儀式をしているだけで精神がすり減っていくし、スピードも遅くなる
場合によっては頓珍漢な意見を言ってくる・・・

対策

• 儀式を無せる（軽減できる）ように、事前にネゴる
• 製品のライフサイクルをプロダクトマネージャーに一任してもらう
• 都度見に来てもらえる、意見交換できる環境を整える

作ったらおしまい

受託開発の契約によりけりですが、作っておしまいという雰囲気になる
一度作ったのであとは売れるのを待つというスタンス

対策

• 製品のロードマップを立てる
• ニーズや製品のビジョンに合わせて、製品をアップデートし続けていく

プロダクトオーナー不在

プロダクトオーナーという役割を担う人がいない
なので、みんなが好き勝手に意見を言い、それらをひっくるめた製品や機能になる

対策

• プロダクトオーナーを明確にする
• 意見を交わすのはいいが、だれが責任をもって最終決定をするのかを明確にする

掛け持ち

受託開発のプロジェクトと製品開発のプロジェクトの双方を掛け持ちしている状況
結果として受託優先にされるのが落ち目

対策

• どっちかにしてもらうｗ