やる気がストロングZERO

やる気のストロングスタイル

新規開発計画アンチパターン:画面毎担当(期限付き)

エンジニア職ではない人が新規システム開発の計画をすると、必要な画面一覧を洗い出して画面毎に期限を設定した計画を作成される場合がある。

この計画をそのまま受け入れて進めてしまう事自体がアンチパターンだけど、
力関係など様々な原因で通ってしまう場合もある。

なぜアンチパターン

同じ機能の別実装が多数作成される

画面毎に期限が指定されているので、その画面を動かすことが最優先事項になり、共通化に時間が使われなくなる。
綺麗に共通化したモジュール作成に時間を使っても画面が動いていないと進捗会議で出せるものがなくなる為、共通化への動機が薄くなる。

さらに、エンジニアレベルにもよるけど、同じ機能が画面毎に、画面に密結合した形で実装されがちになる。
※同じデータのデータ取得でさえ画面毎に実装され、データ構造も画面毎に実装されている例を見た事がある。

結果、
同じ機能の別実装(画面に密結合)が多数存在することになる。
仕様変更などで機能に修正が入る際、全ての機能実装に対して修正を入れないといけない。
全ての実装が微妙にずれた状態になったりする。どれが真かわからなくなる。

中途半端に実装された画面が多数作成され、進捗が不明になる。

画面には多数の機能が含まれている。(検索機能、編集機能、新規登録機能、入力サポート機能などなど)

例えば、この画面はまだ「新規登録機能」しか実装されていないが、別の画面の作成に「新規登録機能」が必要である場合に、とりあえずこの状態でマージされたりする。

こういったことが繰り返され、どの画面がどこまで実装されているのかわからなくなっていき、残作業が見えなくなっていく。

何がどこまで出来ているのか不明になると、コードを読み解いて状態を認識する作業が発生し、無限に時間が飲み込まれていく。

どうすべきか

画面に注目せず機能に注目して計画を立てる。

必要な機能を洗い出し、依存関係を整理して機能毎に実装を進める。
同じ機能の複数実装を許さない。
画面の実装は後回し。 動作テストなどで必要なら簡易に実装しておく。