最近よく読んでいるまとめサイト「IT速報」で管理人さんが文系をバカにした記事とコメントをたびたびまとめているのを読むのだけど、さすがにちょっと文系に敵愾心を持ちすぎだと思いつつもよく分かるなあとうなずいてしまう。そこで、自分がいわゆるIT土方（システムインテグレーション）の仕事をしていてよく感じる文系的な「なんちゃってエンジニアリング」についてまとめてみたいと思う。
意志決定する上で一番大きい根拠がこの「過去の実績」だと思う。過去に同じことをやったのだから今回も大丈夫だろう、という考え方は一見確実なように思えるけれど、本当に同じなのかどうかろくに考慮していないことが多い。重要なのは、「同じっぽい」ことではなくて、ちゃんと筋道が立っていることなのに、文系エンジニアはよく分かっていないのでろくに考えずにこれで通してしまう。最悪なのは、より正しい方法があるにも関わらず、過去に実績がないからという理由で一顧だにしないことさえある。そりゃあヘタなことをして失敗したら目も当てられないのは分かるけれど、それよりも何も考えずに前回と同じことをやるほうがもっと危ない。
こんなアホなことがまかりとおっている一番の理由はおそらく、責任者が責任を回避するためだと思う。責任者という立場の人は、現場の担当者ほど状況を知らない。いちいち細かいことまで見ていられないからある程度は仕方がない。だから、本来であれば現場を疑ってツッコミをいれつつも最終的には信じて、もし失敗したときはその責任を取らなければならない。なのに、その責任を回避するために一見分かりやすい「過去の実績」にすがり、それで失敗したときは自分のせいじゃないと責任逃れをする。
根本的な問題として、よく分かっていない文系エンジニアほど責任ある立場に上がっていってしまう。そして、分かっていない人間に対して説得するための手練手管が積みあがってしまったのだろう。
本来設計書は正確であることが第一であり、次に簡潔であることが重要なのだけど、これらを無視してとにかく分かりやすく書けとよく言われる。分かりにくい設計書は口頭で説明するなり補足資料を作るなりすればいい。分かりやすくするために、論理的整合性がなくなったり、文章が冗長になって同じことを違う場所で何回も説明したりするのはまったくの無駄である。
実際にあった例なのだけど、ファイルを保存しておく場所を変えようということになり、設計書に書かれてあるパス（ファイルの場所をあらわす文字列）を一個一個修正することになったのだが、いくつかの設計書の複数の箇所に一つ一つパスが書かれてあって、それをいちいち修正することになった。そんなものはファイル一覧みたいな資料に一か所書いてあればいいだけのことなのに、分かりにくいからという理由なのかあっちこっちに書かれている。さらにはテスト項目書を作るときに、何も知らない人がテストを実施できるようにやはりパスを書けと言われる。文系エンジニアは分かりやすいのが第一だと思っているから、とにかくなんでも書いておけばいいと考える。「〇〇ファイルを置いておく場所」という抽象的な概念が理解できないのではないかと思う。
文系エンジニアは数学が出来ないので方程式が理解できず、xと置いておくことが出来ないので、いちいち算数の式を書いてやらないと理解できないのだろう。
情報システムの開発では古典的な方法としてよくウォーターフォールモデルと呼ばれるやりかたを取る。その特徴として、水の流れが不可逆なように、一つ一つ段階を踏んで開発を進めていくことからきている。
たとえばいきなり大きなシステムを一気に作り上げるのは不可能なので、システムを一つ一つの機能に分けて、その機能もさらに一つ一つの処理に分けて作る。それらを個別にテストしてから組み上げていき、組み上げたものをさらにテストする。最終的に、出来上がったシステムが本当に業務に使えるのかどうかまで確認する。
じゃあ具体的に文系エンジニアがどう勘違いするのかというと、まずテストデータをなるべく本番に近い形にしたがる。ん？それのどこが悪いの？と思うかもしれない。本番に近いデータを用意してテストをしても、そんなものはただなんとなく動くだけの保証しか出来ない。ちゃんと動くシステムというのは、本番でどのようなデータを処理するのかきっちり設計してある。その設計さえ間違っていなければ本番でも動くことが理屈で説明できる。だから、設計どおりに作られているかどうかを確認するために、本番とはかけ離れた極端なデータを使用してテストを行う。ただしもちろん最終的に設計が間違っていないかどうかはシステムテストとして確認しなければならないため、そのときに本番に近いデータが必要になる。
テストは段階を踏むものなのに、あとの工程で問題が発覚したら影響が大きいからと、なんでも前倒しで確認したがる。そんなことを言い始めたら、確認しなければならないことを全部一度にやらなければならなくなる。なんのために順番に確認しようとしているのか分からない。ロボットの指先から作っているのに、あとで体のバランスがおかしかったら困るからと、組み上げてから行うべきテストを先にやったってしょうがない。
もっとも、ウォーターフォールモデルは古いと、アジャイルだのスパイラル開発だのと仮組みしながら徐々に全体を作り上げていく開発手法も徐々に浸透してきている。それぞれ長所と短所があるのでどの手法が優れているとは言い難いが、一度決めたらそれぞれの手法に則って開発を進めなければ無駄が増える。
*
もっと文系エンジニアそのものについても書きたかったけれど、あまり話が散漫になっても困るので、ひとまずこのおかしなエンジニアリングについてだけ今回は取り上げておく。