仕事復帰後にちょくちょく「現行踏襲」という言葉を聞く機会がありました。
きちんとした答えがあるわけでないが、「現行踏襲」について考えることが多くなってました。
自分の考えを一旦整理しておきたいので、ここに記録しておくことにします。
用語：現行踏襲とは
現行踏襲とは、「現行システムの仕様を踏襲する」という意味で使われています。
どんな時に使われるか、と言えば、現行システムをリプレースする時に使われることが多いでしょう。
想像ですが、きっとこんな感じ。
お客様：「今のシステムを刷新したいんだよね。だから、見積もりをお願いしたいんだ。」
開発会社：「承知しました。どのようなシステムを考えられていますか」
お客様：「現行システムと比較して、新たにXXをXXXするようなシステムにしたい。ただ、ベースは現行踏襲で」
開発会社：「...はい。（現行しらねーよ）」
お客様：「現行踏襲だから、費用も抑えられるっしょ？」
開発会社：「......。（現行システムの規模を知らないから、安くなるかなんて言えないよ）」
そもそも、用語として登録されているかは怪しいのですが、ある程度年数を積んだSIerの方なら大体の人が知っている用語だと思われます。そして、同時に悩まされた用語でもあるのではないかな、と。
考えるきっかけ：
先日のブログで軽く触れたのですが、「自分が育児休業に入る前に関わっていたシステムのリプレース開発費の見積もり依頼を受けた」、ことに起因しています。
詳しくは書けないですが、ポイントだけピックアップすると以下の通り。
- 数年前、SESの常駐先で某システムのリプレース開発を実施。以降、育児休業するまでずっと面倒を見ていた
- 昨年、育児休業に入るため、常駐先から離脱。その際に、常駐先には引き継ぐ要員を確保できず。紆余曲折の末に、私の所属会社がそのシステムの保守を引き受けることに。私は所属会社の人に引き継ぎをして、育児休業へ。
- 一年後、私が復帰。時を同じくして、前述の某システムのリプレース時期が重なる。
- 私が引き継ぎした人が会社を辞めており、所属会社内で見積もりできる人間がいない。*1そのため、復帰早々の私に見積もり作業の依頼がくる。
- リプレースの話をヒアリングしていると、予算の確保がまだできていない。しかし、なるべく予算は抑えたいために、「現行踏襲」や「移植」で見積もり額を抑えられないか、などの話が持ち上がる。
引き継いだ人が居なくなったからといって、その引き継ぎ元に頼るのはどうなの？（その人が辞める前に引き継ぎ先を用意していなさいよ）というモヤモヤは感じたものです。とはいえ、安定していたシステムの保守を引き取ったとしたら、積極的にシステムの仕様を確認しようとも思わないのも仕方ないでしょう。*2
...まぁ、それは一旦脇に置いといて。
リプレースするシステムの見積もりをする上で「現行踏襲」がセットで付いてきたので、モヤモヤしながら見積もりをしていました。その中で、いくつか疑問が出てきたので、ちょっとまとめてみようと思ったのがきっかけです。
現行踏襲に対するモヤモヤ
ここからが本題。
現行踏襲をベースにした見積もりを行ったことで、以下のことを考えることが増えました。
- 現行踏襲とはそもそも何なのか
- 現行踏襲をすると費用は下がるのか
- 現行踏襲をすることは何を得て何を失うのか
1つずつ整理してみます。
現行踏襲とはそもそも何なのか
用語の意味ではありません。
この場合の「何なのか」とは、なぜ「現行踏襲」という言葉が出るか、です。
仕様として、「現行踏襲」自体を否定するものではありません。現行システムの仕様を再確認して、リプレースするシステムでも同じ内容で問題が無いのであれば、その仕様を表す言葉で依頼してくれれば良いのです。
しかし、顧客側から「現行踏襲」でという言葉出てくる事が示すことは、「依頼側が仕様の言語化を諦めている」ことだと考えています。
SIで実施しているので、仕様を整理するのも仕事と考えることはできるでしょう。しかし、それをすれば当然費用が発生します。
また、なぜそのような仕様になったのか、などは用意されているドキュメントからは書かれていない／読み取れないことが多いです。
一方で、明確なメリットもあります。
現行踏襲は、現行システムで採用されている仕様を適用することで、仕様の不確実性が排除されている状態になっています。
依頼側も開発車側も、「これが正しい動き（仕様）である」を得られている、という事です。
システム開発においては、依頼側も開発側も「何が正しいのか」は手探り状態にあります。その手探り状態を短いスパンで正解に近づけられるように短期間でリリースを繰り返すアジャイル式の開発があったりします。
しかし、現行踏襲であれば、正解はわかっているから相互に検討する必要もなく、"正しい"（と言える）ものを作る事ができます。
リプレース案件の目的が何なのかにもよりますが、単に"現行システムの焼き直し"感が強い場合においては、非常に魅力的に聞こえる言葉なのかもしれません。
加えて、現行システムの仕様をよく知る開発者がいれば、その人物を通じて開発をより効率的に進められる可能性があります。
現行踏襲をすると費用は下がるのか
上でも少し触れていますが、現行踏襲をすることは、仕様の言語化をしていない事になります。
仕様の言語化作業を開発会社に依頼するのですから、本来は費用が上がるはずです。
しかし、開発会社側はその費用を上乗せしすぎると金額が大きくなることを知っています。そして、大きくなりすぎると、開発の依頼がされない／減額要求をされる事が多いため、費用を抑える動きをしようとします。
言い方は悪いですが、案件を取って開発して納品すれば、あとは保守期間で別途費用をとって改修作業などができるようになります。
その結果、「現在のドキュメントの内容をそのまま流用する」などにつながっていきます。
新しくドキュメントを作るのか、現在あるドキュメントをそのまま利用してもらうのか。
どちらにせよ、体裁を整える以外はドキュメントの中身を精査せずにそのまま使うことで、発生する作業工数を削減しようとするでしょう。
また、現行踏襲しようとしている機能に問題が見つかっても、よほどの事がない限りは改修対象にはなりません。
だって、改修するなら費用が発生しますから。でも、その改修に費やせる費用はないので、伝え方は様々でしょうが「現行の仕様はそのままなので、改修は行いません」となるでしょう。
もちろん、お客様のためになるなら、無償（もしくは割りに合わない）でも改修してくれる開発会社はあるでしょう。ですが、それも頻度次第でしょう。一度、もしくは二、三度ならサービスとして対応してくれるでしょうが、回数が多くなって工数が掛かれば「何のために現行踏襲にして費用落としたんだっけ？」という話にもなっていきます。
現行踏襲をすることは何を得て何を失うのか
これまでの中で、現行踏襲によって「費用」、「期間」、および「"正しい"仕様」についてのメリット／デメリットがあるように考えられました。
それ以外にも何かあるかなと考えてみたところ、「検討の余地のない開発は、一部の開発者を除いて面白みのないもの」になるよな、と思えました。まぁ、これは自分が既に関わっていたから、新しく得るものが特になさそうだな、という印象を持ったことに起因してはおりますが。
得られるもの：
- 依頼者側：仕様の言語化を実施しないことによる検討／作業時間にかかる時間の削減
- 開発者側：新たに仕様検討／試行錯誤をしないことによる作業時間の削減
- 開発者側：不確実性を（極力）排除された仕様と、仕様に不備があったときの免罪符
- 依頼者／開発者の両方：仕様検討に費やす質疑応答の時間
失うもの：
- 依頼者側：現行の仕様よりも、より良い最適な仕様が出てくる可能性
- 開発者側：より良い機能／サービスを提供する機会、およびより工数削減につながる機能開発の機会
- 開発者側：開発担当者のモチベーション（改善の余地がないため）
結局のところ、すごく簡単にまとめると、「短期的に見ればメリットがある」けれども「長期的に見ればデメリットの方が大きい（可能性がある）」という事でしょうか。
ただ、プロジェクトによっては「短期的なメリットも得られない」プロジェクトがあったりするのが、システム開発の難しい部分でもあるのですが...
まとめ
「現行踏襲」のメリット／デメリットについては、以前からいろんな方が語られています。
自分もその方々の記事を読んだ上で、あえて自分の言葉で自分の中で抱えていたモヤモヤを整理してみました。
自分としては、「現行踏襲」自体が悪いとまでは考えません。
しかし、これを使う事で思考停止になったり費用を下げる言い訳*3に使われるのには、違和感を持たざるを得ませんでした。
