世の中便利になったもので、ITシステムで何かを実現したいと思ったら、それをスクラッチから設計・開発することはほぼ無くなった。
いま僕はとある依頼で作成中のデータベースシステムがあるが、RoR（Ruby on Rails）を使って簡単にプロトタイピングができている。ほんと便利だ。
しかしどのようなシステムにおいても、汎用化によって犠牲になるものがある。
それはシステムの効率的なリソース活用だったり、バグ混入の可能性だったり、セキュリティリスクの増大だったりと色々あるのだが、システムの設計構築において重要なのは、気軽に使おうとしてしまうモジュールやライブラリが一体システムにどのようにアクセスしてリソースをどのように消費するものなのかということを理解することだ。
動作が理解できていないシステムを売るというほど無責任なものはない。
チーム（会社）の全員がそれを理解している必要はないが、売る以上は、売るものの性能や制約を技術的にきちんと噛み砕いて理解しておくことが、顧客に対する誠実さではなかろうか。
どんな味のバナナか知らなければ、バナナに値段はつけられない。
→どのような機能をもったソフトウェアか知らなければ、ソフトウェアに値段はつけられない。
市場優位性だけで価格をつけるべきではないと僕は強く思う。
その製品がもたらす機能が一体どのようにして、どの程度顧客のビジネスにインパクトを与えるのか。
それは、バナナの味を知るだけでは浅はかで、バナナが健康など目に見えない、感じられない部分に与える効果も知っているのがプロというものではないか。
あなたはこのソフトウェアがどの程度顧客のビジネスにクリティカルなのか、理解しているか？
ソフトウェアの構造がもし脆弱であれば、機能要件が満たされていても顧客のビジネス継続性が犠牲になる可能性があることがどの程度わかっているか？
ソフトウェアの良し悪しとは、機能だけはないし、バグの少なさでもない。
どのようなアルゴリズムでどのようなシステムリソースにどうアプローチしているのか。
たとえばデータベースへのアクセスひとつを見ても、データベースの信頼性はどう確保していて、どのようにデータ保護を考えているのか。データ構造はどうなのか。データベースアクセスのためのモジュールの思想はどうなっているのか。もしそれらがフレームワークによって提供されている機能なのだとしたら、そのフレームワークの動作はきちんと理解できているのか。パラメータはどのように保持されて、どこで使われているのか。
セキュリティはどう担保されているのか。
こうしたことにあまりにも無頓着で、すべて開発チーム任せにしている組織、もっと言えば、プログラマ任せにしている設計者が多くいる。
どのように安全性と性能を両立しているかわからない自動車に顧客を乗せるのか？
このあたり、IT業界は目に見えにくい製品作りなので、なんとなく看過されているところが多い。
ブラックボックス化されるのはいいが、動作原理くらいは理解しておくべきだ。
ソースコードが読めないならば、開発者に挙動を聞けばいい。
コメント