最近は、私も技術者としての経験値が増えてきたせいか、あるいは単に年を重ねたせいなのか、システム開発に関しては、どこか諦めのような感覚も強まってきていて、正義を振りかざすシステム開発論に、反応することが少なくなってきました。良いシステムを作ろうという思いは当然ありますが、良いものを作ることを目指すことよりも、システム開発を行うチームや、組織という主体を良くしよう、という考えに切り替わりつつあります。つまり思考が人間関係ファーストになりつつあります。システム開発は、それを使うエンドユーザーの為のものですが、同時にそれを作る私たちの為のものでもあります。
でも、以下のような記事はやっぱり技術者としての琴線に触れます。
私が作り逃げに対して、最も思うところは、表題にもある通り、同じ技術者として作り逃げを断罪する気にはなれない、というものです。作り逃げをする技術者、人、組織、会社ばかりに着目して、なぜ作り逃げが発生するかという仕組みに着目しないと、作り逃げを断罪している自分自身が、いつか必ず作り逃げをする側になりますよ。
これが、私が一番言いたいことです。
作り逃げが発生するのは新規開発と捉えて差し支えないですよね。システムの新規開発とシステムの引継ぎでは、どちらの方が難易度が高いかというと、それは新規開発なのは明確だと思います。求人でも、引継ぎ案件よりは、新規開発案件のほうがスペックを求められます。引継ぎをした人からは、新規開発をした人の当時の事情が見えないことが多い。それは当然です。新規開発の難易度のほうが高いのですから。新規開発をする技術者は、作り逃げを引き継いだ経験が既にあることが多いです。なぜなら、ひどいシステムであるほど技術者が定着しないので、引継ぎが何度も発生するからです。システムの作り逃げを断罪したくなるような、悶々とした状況を抱える機会のほうが、作り逃げが発生しかねない新規開発よりも、多い傾向にあります。良いシステムは技術者が定着してしまうので引継ぎが発生しないのです。
作り逃げが発生するのには、何かしら理由があります。思考停止したひどいコードがあったとき、それはより重要なことに思考を回すために、あえて思考停止せざるを得なかった結果かもしれません。コーディングの工程なのに、要件定義がフワフワしているのはよく見る光景です。ドキュメントがないのは、作ろうと努力したけれども、お客さんを説得させられず、予算が通らなかった結果かもしれません。安いものに飛びつきがちなのは、古今東西に共通するお客さんの性です。
中には、自己中心的で無責任な技術選択をする技術者がいないわけでもありません。しかし、自己中心的で、無責任に見えるような、技術選択でも、せざるを得なかった外的要因が、全くなかったとは言い切れません。
システム開発は本当に難しいです。システムがつつがなく出来上がり、運用できるかどうかは、ベンダーの問題もありますが、お客さんがお金を持っているかという問題に帰着することが多いです。私は、安定した開発プロジェクトに携わった経験がありますが、振り返ってみるとお客さんがお金を持っているという共通点があります。予算が豊富でもシステム開発は失敗する可能性はありますが、予算が不足して良いものは絶対に出来ないです。システム開発はほとんどの場合、それを使うお客さんの売り上げに影響しません。B to B の業務システムならなおさらです。システム開発は正のインセンティブ（売り上げがどれだけ上がるか）ではなく、負のインセンティブ（業務が正常に回るか）で動いています。システム開発がコストだと捉えられ、予算が逼迫するのは当然の結果でもあります。事実、システムは人件費というコストの王様とも言えるパイを切り崩してきたにすぎないのですから。そして、システム開発自体が人件費のかたまりです。
システム開発は作って終わりではないという点において、ほかのものつくりとは、一線を画しています。もはやシステム開発は製造業ではなく、サービス業と言っても過言ではありません。にも関わらず、システム開発における契約体系が一括請負であれば、構造的に納品は作り逃げになります。
システム開発の特徴は、
- 言うは易く行うは難し（大体の技術者はどうすべきかなんてことは分かっている。そのべき論を具体的な行動として実行できる人は少ない）
- 安かろう悪かろう（コストのほとんどが人件費である以上、安くても良いものを機械的に実現できない。それができるとしたら属人化というリスクが台頭してくる）
考えれば考えるほど、システムの「作り逃げ」を許すな、なんて断罪は恐ろしくてできない。私たちが注視しなくてはいけないのは、作り逃げ自体ではなく、作り逃げが生まれる仕組みについてですよ。
