この記事で伝えたいこと
既存のシステムの機能拡張の見積もりを行う際、その機能強化による影響の大きさを正しく把握する必要があります。
影響の大きさを把握する上で、もし新たなデータの状態が発生するような修正をするのであれば、その修正の影響は思ったよりも大きくなることがあるので、警戒する必要があります。
また、可能な限り、新たなデータの状態が発生しないような修正を行うのが望ましいです。
例を挙げての説明
例えば、セミナー予約用のWebシステムを考えてみます。
既存のフローは以下の通りであるとします。
- ①見込客がシステムのアカウントを取得する
- ②主催企業が見込客にDMを送信する
- ③見込客がDMに書かれた候補日時の中から一つを選び予約完了
それぞれの時点での見込客のデータの状態は以下の通りであるとします。
- ①DM送信済みフラグ＝偽、日時選択済みフラグ＝偽
- ②DM送信済みフラグ＝真、日時選択済みフラグ＝偽
- ③DM送信済みフラグ＝真、日時選択済みフラグ＝真
ここで、DMの内容を取り消しし①のフローに戻せるようにする、という機能拡張を行うとします。
この際、「DMの内容の取り消し」を「DM送信済みフラグを偽にする」と実装してしまうと
- DM送信済みフラグ＝偽、日時選択済みフラグ＝真
というこれまでになかった状態が発生する可能性が出てしまいます。
（③の状態でDMの内容を取り消しすると上記のような状態になる）
そして、既存のプログラムで「日時選択済みフラグが真の場合に③のフロー上にいると判断する」（DM送信済みフラグは見ていない）というロジックが存在する場合、それらのロジックは全て修正対象になってしまいますし、新たに発生したデータの状態を判定するためのロジックを既存のプログラムに追加しなくてはならなくなる可能性もあります。
このように、新たなデータの状態が発生するような修正は、見た目の規模と比べて影響が大きくなる恐れがあります。
影響を小さくしたいのであれば、これまでに存在していたデータの状態のみを使って機能拡張を実現できないか、を考えることが重要です。
今回の例では、対象のデータに対して「日時選択済みフラグを偽にする」という操作も行うか、対象のデータをコピーして新たなデータを作成した上で新たなデータを「DM送信済みフラグ＝偽、日時選択済みフラグ＝偽」にするか、のどちらかの対応を考えた方が良いです。
あとがき
システムは、リリースするまでの新規開発期間よりもその後の保守開発期間の方が長いぐらいであり、保守開発では今回の記事の例のような修正がつきものです。
その際に、プログラミングの知識があれば、内部ロジックに気を配って影響の大きさを推測できるようになります。
株式会社サイゼントでは、即戦力のJavaプログラマーを育てるための書籍「絶対にJavaプログラマーになりたい人へ」をKindleで販売しています。
同じく、Spring Frameworkについてきめ細かく解説した別冊も販売中です。
また、上記の書籍をテキストとして用いたプログラミングスクール「サイゼントアカデミー」も開校しています。
このスクールは、受託開発事業・SES事業である弊社が、新入社員向けの研修で培ったノウハウを詰め込んだものです。
ご興味がある方は、上記画像から個別ページにアクセスしてみてください！
コメント