プロフィールの通り、流通系、システム系、ソフトウェア系、保守系技術者をやっている。実際に保守を直接担当しているわけではなく、保守担当だけで解決できない不具合対応や、操作ミスのリカバリなどの後方支援や、保守担当への技術研修の提供、メーカへの保守上の問題点解決の提言などを担当している。
それで思うのが、システム屋にとってアプリのロジックを理解しても、ようやく必要な知識の２割程度だということだ。システムを構成する要素は技術だけでも「クライアント」「サーバ」「ネットワーク」「ＤＢ」「ＯＳ」「ＷＥＢ」「仮想化技術」「クラウド」「ＨＡ技術」等があり、技術以外なら「ビジネスロジック」「運用」「法律」等がある。もし採用されている技術要素の一か所でも問題を起こせば、システムは完全には動作しない。
問題が発生した場合に、それを脳内逆トレースして原因を推測するためには、ビジネスロジックが抽象化された「アプリのロジック」を知っていることが重要だ。しかし基本的にアプリのロジックだけで解決できるような問題はそれほど大きな問題ではない。なぜならアプリのロジックの問題が及ぼす影響はそれほど広くないからだ*1。
しかし、たとえばＤＢに問題があるような場合、その影響は極めて広いため問題は大きくなる。だから保守担当者はアプリのロジックを知るのと同等に、採用されている技術要素について、学ぶ必要がある。
問題は技術要素の選択肢が非常に多くなっていることである。少なくともわが社の保守技術者が、一つのシステムだけしか担当しないようなことは少ない。複数のシステムを担当した場合に、採用されている技術要素が異なっていると、覚える範囲が多くなってしまい、ただでさえ余裕が無い状態の担当者に非常に負荷をかけてしまう。
だから、私の担当しているシステムだけでDBにOracle、SQLServer、MySQLを採用、WEBサーバにApache、IISを採用、WEBアプリにaspx、php、jsp(tomcat）、wasを採用、OSにLinux、Windowsを採用、仮想化技術にvmware、Hyper-Vを採用、HA技術としてMSFC、XXXX(書けない)を採用している状態はTCOという観点から異常である*2。いやむりだろ。要求されるのはスーパーマンであって、スーパーマンを要求する時点で保守屋としては間違っている。*3
ということで、現在当社ではこの問題をどう解決するのか検討中。落とし所としては「技術要素専門の部署をつくる」ということになると予想しているが、どうだろうか。
まあそうなったとして、大切なのは「技術要素専門の部署がアプリのロジックも知る」ことだ。なぜなら我々はシステム屋だ。
