システム開発の確認は、納品後に行われるのがほとんどな件

これまでたくさんのシステム開発を行ってきたんだけど、プログラミングや設計などの開発を行うことは楽しいのだが、作り終わった後で不具合が出た時が最もつらい。 不具合というのは、プログラムのバグの場合もあれば、設計が行き届いていない想定外のケースの場合もある。 想定外の中でもサーバーやブラウザ、端末などに依存して発生するクリティカルエラーなどは再現確認なども含めて非常に苦しめられることが多い。 これらの不具合というのは、アジャイルだろうがウォーターフォールだろうが、不具合が発生しないシステムはその中に存在しないと言ってもいいぐらい当たり前に発生する。 そこで重要なのが、検証テストと言われる、いわゆるデバッグやら、チェック作業が大事だということ。 これを軽視する場合もあるし、クライアントから「そこまでガチガチに検証しなくても良いよ」と言われることが多い。 何故なら、本気で検証する場合、大体の場合において、開発工程と同じとまでは行かないにしても、相当の工数と労力が掛かるため、「とりあえず動いていればいい」という思考の人は少なくない。 そんなシステムを作ってしまった顛末などをブログに書いてみたいと思います。

安易な検証は見えるところしかやらない

クライアントから、「作って」と言われて作ったものは、入念な打ち合わせをして内容をしっかりと把握してから作らないと、とんでもない別物が出来上がることがあります。 とんでもない別物が出来上がった場合、「言った言わない騒動」に突入してしまうんですが、それを防ぐために、ITに詳しい側がしっかりとしたヒアリングをするという工程は重要です。 これは大体において、開発が完了するまでずっと続くので、最初だけとかではないんですよね。 そして、とりあえずベータバージョン的なものができ上がった時に、言ったとおりに作ってくれたと安心したクライアントは、見えるところしか触ってくれません。 この状態で「できた！」と判断されてしまうんですね。

本番化した時に想定外の動作が行われ始める

検証が行き届いていないシステムが本番化した場合に、一人の人（または開発時に打ち合わせをしていた数人）しか使わない場合はさほど問題になりにくいのですが、 たくさんの人が使う（会社や、公開型など）場合において、おそらく何かしらの想定外不具合などが起き始めます。 この場合、前向きなクライアントは、不具合に対して前向きに打ち合わせをして解消まで進めようとしてくれますが、 アプリケーションは作ったらそこで開発が終わりと考えているクライアントの場合は、五月雨に不具合のみをチャットやメールで送信して、原因追求や使い方レクチャーを進めようとしてくれません。 そもそも、想定外の不具合というのは、設計思考が足りていなかったレベルから、そんな端末で使うなんて聞いていない（やらないって言ったじゃん）的なものまでたくさんあるので、それらをちゃんと精査するというのも重要です。 もちろん、システムを作るというのは、こうした正常動作を保証する作業でもあるので、ヒアリングしきれなかった（想定外を思考してやらない判断の時の判断材料として提示しなかった）という、エンジニアミスもあります。 でも、十分なテストを行わせてくれない会社の場合に、本番でデバッグ作業を行うという横暴なケースは意外と少なくないんですよね。

想定外は想定しようがあるのか？

これ、検証思考で重要なポイントなんですが、 システム検証は、技術スキルが高い人が行う必要があります。 世の中にたくさんある検証会社って、かなり優秀なエンジニアがズラッと揃えられている会社でもあるんですよ（知ってます？）。 では、想定外の不具合をなるべく出さないために、どうすればいいかというと、コレはシステム開発経験が非常に大きく必要になります。 過去の経験で、「こうした場合にこういう不具合が出やすい」という知見があれば、設計時にある程度の想定外を想定できてしまいます。 でも、そうではないエンジニアの場合は、経験も踏まえて前向きなバグとして捉えてあげる以外に納得のしようがありません。 長い目でエンジニアを育てるというのも、システム開発の時や、会社の開発部門においては必要な思考なのかもしれませんね。

あとがき

今回のブログはこれまでシステム開発をやってきた熟練エンジニアであるユゲタが、今でもよく発生するクライアントの体質を今更ながら考えた事と、システム開発って改めて正攻法が少ないんだな〜って考えたので、文章にしてみました。 それでも、システム開発を行い続けて、世の中のアナログをデジタルに変えていきたいという想いは沸々と湧き上がってきます。 ちなみに、本番化で不具合を無くしたい場合、ベータ版を作った後のメタクソいじくるというのが重要なのではないかと考えました。 この「メタクソいじる」というのは、そのシステムを壊すつもりで想定できる事を何でもやってみる事が重要で、本番化した後などはとうていできない事ですからね。 できるタイミングでできることをやる これこそが、システムの安定感を増すことができる理想のデバッグなのかもしれないと考えてしまいました。 クライアントのテストなんて期待しちゃ駄目なんですよね本当は。 ひたすら想定外をおい続けるというのも、エンジニアとしては悪くない思考なのかもしれないです。 それは誰にもわからないですけどね。