ソフトウェア、データがなければタダの落書き

ハードウェア、ソフトがなければタダの箱。というのはよく言われることだが、ソフトウェアも実はデータがなければ何の役にも立たない。


20年前の、フロッピーからファイルリードしていた時代は、データ量なんてたかが知れていたし、ハードの性能が低かったから、いかに短いステップで要求される処理を実行するか、ひいてはいかにメモリを消費しないかが重要だったので、プログラマーのコーディングスキルが重要だった。


現在ではハード性能が20年前の千倍以上になっているので、ハードウェア性能はほとんど気にしなくてよくなった。ボトルネックになっているのはデータが大量集中するDBと、ネットワークアクセスの集中による帯域不足。


DBやネットワークの負荷分散はインフラ屋さんの領域なので、システム屋はあまり気にしてもしょうがないのだが、なんでもかんでも電子データ化されてやたらとデータ量が増えている現代では、大量データに対するアクセスのセンスがないと、良いシステムは作れない。




今の現場に、コーディングが並みのSEの倍ぐらい早いコーディング自慢のX氏が居て、この現場のNoドキュメントASAP主義と適性がマッチしているので、ものすごく気炎を上げているのだが、どうもX氏の作った画面の処理が遅い。


あまりにも遅いのでバグったか? と思うが、10秒ぐらいすると動く。
業界の暗黙の了解として、3秒ルールや8秒ルールがあり、画面の切り替えは3秒以内、データアクセスで砂時計になるのは8秒以内に押えないと、ユーザーのストレスになってクレームが出る。


イメージデータを溜めているテーブルにアクセスする処理だから、サクサクというわけにはいかないだろうけど、イメージデータにアクセスしている他の機能と比べても遅い。


しかし倍速コーディングが自慢のX氏には誰も突っ込めないし、元々出来の悪いシステムで、来年度には新規システムに切り替わってほぼ捨ててしまうシステムなので、遅くても本気で改善する計画はなさそうだ。




半年前に居た現場は、日々発生する仕入れや仕分けのデータが百万件単位だったので、SQLチューニングにはうるさかった。正直SQLレビュー担当のプロジェクトリーダーの言っていることは宇宙の言語だったが、データ量が増えていく一方の現代にあっては、必須の知識だったなと今になってしみじみと思う。


今の現場は本当になにもかもが行き当たりばったりで、開発なんだか保守なんだか作業区分が曖昧で、何かトラブると保守側作業に引きずられるので開発が遅延し、遅延した分はドキュメント作業を抜いたり、手の回転の速さでリカバーしようとするから品質が悪く、次のトラブルの種を仕込んでしまい、それが数ヶ月後に芽吹くから自分で自分の首を絞めるという悪循環。デスマパターンと言って良いだろう。


そういう文化だから、計画的なDBチューニングやSQL設計などあるわけがなく、コーディング作業の速さばかりがクローズアップされることになる。