いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

現行踏襲でやればうまくいくはずなのになぜかうまくいかないのはどうしてかよく分からない人に伝えておきたい話

»

踏んで襲うと書いて踏襲

大手の仕事をやってると決まって聞く言葉が「現行踏襲」。今までこれで動いていたのだから、同じものを動かせば動くはずだ。確かに話しとしてはそうだ。今まで動かしていたものをそのままやればいい。簡単だろ?という理屈だが、簡単に済んだためしが無い。むしろ、現行踏襲しても炎上するときは激しく炎上する。

現行踏襲の何が良くないのか。ズバリ、字面が良くない。「踏む」に「襲う」と書いて「踏襲」。語源は何だか知らない。あえて調べる気も無い。ただ、踏んだり襲ったりと、帰りの夜道にやられたらかなり嫌だ。こんな字面の言葉を実践して、あまり成功できる気分にはならない。つまり気分の問題だ。

気分など適当なことを言うなとお叱りを受けるかもしれない。だが、実際は気分の問題だと思う。現行踏襲案件の傾向として「今まで通りやれば問題ないよねー♪」と気軽に考えられやすい。そんなお気軽プランで携わるので、現行踏襲案件は炎上しやすい。実際、現行踏襲のプロジェクトは要件の検討や資料の作成に抜け漏れが発生しやすい。

現行踏襲という要件が出ると、現場がすさまじく消極的になる。ドキュメントも前のプロジェクトの流用。コードもドキュメントも基本は置換しかしない。新たに書き足したり書き直したりしようとすると、神にでも背く気かとばかりに反対される。現行を気にしすぎて、極端に動きが遅くなる。

現行踏襲を成功させる秘訣

現行踏襲の何がいけないか。ズバリ、字面が良くない。冗談だと思うかもしれないが本当だ。要件に「現行踏襲」と出すから失敗する。同じ要件でも「今あるものを元に作り直せ」と言って、現行のドキュメントとソースを渡そう。「現行踏襲」よりもチャキチャキ動いてくれて、リファクタリングまでしてくれるはずだ。

「作り直せ」と言われて、目の前に元のソースコードがあったらどうするだろう。普通なら、元のソースコードに目を通して、流用できるところは流用する。結局、「現行踏襲」と言われた時と同じことをやる。ただし、ソースコードやドキュメントは「現行踏襲」と言った時より真面目に読んでくれるはずだ。

「現行踏襲」で要件を出すと現行が正と捉えられる。元々が正しいとされるものを誰が好んで弄ろうとするだろうか。中身が間違っていても、何らかこじつけて「正しい」ということにされる。そのくらい元のソースコードやドキュメントを変えることが嫌がられるようになる。変えるということが、ものすごいリスクのような扱いを受ける。

「作り直せ」だと元々あるものがグレーになる。何かしら変更箇所がある前提で動くので、間違いは間違いと認識され修正される。修正する際に心理的な抵抗がかかることはない。ちょっとした言葉だけで捉え方と動きが180度変わわる。それによって、結果も全く違ったものになる。

現行踏襲の落とし穴

目の前に90%完成の建物があったとしよう。これを完成させてくれと言われた時、「あと10%」と考える人は失敗する。どこができていて、どこができていないか調べるプロセスを見積もっていないからだ。そこを見積もって、30%くらいの労力を考える人。この人は苦戦をするがなんとかなる。

実際は、90%でストップしているのに何らか理由がある。その理由を知った人がベストな結果を納めることができる。現行踏襲でドキュメントを安易に流用すると、説明の効率が極端に落ちる。結果だけ知っていて経過を知らないからだ。現行踏襲でソースコードを安易に流用するとバグに対応できなくなる。人の書いたコードはそんな簡単に流用できない。

それでも、手元に完成品があるのだ。理屈だけでいけば現行踏襲以上の効率的な方法は存在しない。安易に流用して炎上したとしても、「これが一番効率の良い方法だ」という先入観があるので、本当の原因にたどり着くことができない。理屈で考えれば考えるほどはまる。むしろちゃんとした人の方が間違いやすい。

「作り直すのは時間が勿体ない」という気持ちが判断を鈍らせる。現行踏襲案件というのは、保守的になってしまうので迷う時間が長くなりやすい。現行がどんなにクソコードでも再利用が前提になるので、潜在的なリスクも高い。再利用が前提でも、ちゃんとコードやドキュメントを精査しておかないと思わぬ落とし穴にはまる。

現行踏襲で失うもの

元々動いているものを再利用するので、信頼性が高い。一から設計をする必要が無い。既存のものがあるので手間がかからない。このように、普通に考えると現行踏襲にはメリットしかない。だが、人の書いたコードを引き継いで改修するのは、難易度高めの事案だと思うのだがどうだろう。しかも、元々動いているものがボロかったら悲惨だ。

真面目にリファクタリングやブラッシュアップをするなら難易度高めだ。しかし、クソコードのまま強引に動かすことも可能だ。普通に考えれば、クソコードのままでも強引に動かした方が明らかに楽だ。なので、普通の人は迷わずクソコードのまま強引にうごかそうとする。これがメリットしかない方法だと判断される。

しかし、現行踏襲のデメリットは、プロジェクトの行く先より実行した人の思考に大きなダメージを与える。クソコードを全面的に肯定して導入することで、クソコードをクソコードと認識できなくなる。何が正しいか分からなくなるので、エンジニアとしてのスキルに大きなダメージを受けることになる。しかも自覚症状は無い。

現行踏襲案件で三回成功を納めたらエンジニアとして死ぬ。大げさに聞こえるかもしれないが、現行踏襲に頼り過ぎてコードやドキュメントが書けなくなったエンジニアを多く見てきた。結果主義が故に、安易な手段で成功を納めるようになり考えなくなる。そして、エンジニアとしての能力を喪失してプロジェクトを円滑に遂行できなくなる。シュールな話だ。

Comment(0)

コメント

コメントを投稿する