開発系の案件だと思って話を聞きに行ったら、実は運営系の話だったって事がよくある。
それでも、話が”自分の担当ではありません”では話が終わってしまうので、最低限の知識を入れておく必要がある。

この最低限の知識という物が困り物で、経験有る物なら、”古い知識”ですがと枕詞を付ける事で、その場は切り抜ける事が出来る。問題は経験がない物だが、開発に絡む運営系の問題は概ね幾つかのパターンに分ける事が出来る。そのパターンを抑えておくことで、切り抜けられる事がおおい。

• パフォーマンスの問題

• セキュリティの問題
• ライセンスの問題

に分類される。

パフォーマンスが一番多いが、その場合の対応はいくつか決まった事の確認から始める事が出来る。何か、ソリューションを使っているとしたら、そのソリューション自体の問題がないか？パフォーマンス低下はどのタイミングで発生するのか？など定型文とも言える情報収集から始める。大抵この時点で問題点は出てこない。この程度の事はもう調べているし解っている場合が多い。しかし、確認するのは、おの調べているだろう事でもこっちにしたら初めて聞く事だという事を印象づける意味合いが強い。
その上で、幾つかの仮設を建てる。
ボトルネックになりそうなネタを探す。
アプリケーション系で遅くなる場合には、スレッドの使い方が大雑把だったり、DB接続が最適化されていなかったり、ネットワークを考えていなかったりする場合が多い。客の属性では、ソリューションに頼った作りをしている場合に多い。
次にWeb系のソリューションでパフォーマンスが問題になる場合には、同じくDB接続を一番最初に疑います。特に、DB接続を何かに頼っているような場合には疑います。次に、同じフォーム内に複数の属性が必要になっているような画面が存在しないかやWebサーバのパフォーマンスチェックを行います。
次に意外と見落としがちなのが、タスク管理がされているのかですが、これはシステム全体を見ないとなんとも言えない事も多い上に、面倒ですので、実際に調べる時に最初に行う事が多いです。
次に見落としがちなのが、ファイルシステムへのアクセスによるボトルネットです。DBだけで完結している倍でも、画像ファイルや設定などがファイルになっている場合が多く、それらのファイルに対するアクセスがボトルネックになっている場合も多く見かけます。レスポンスはいいんだけど、表示が遅いなどの場合に考える箇所です。

セキュリティの問題に関しては、もうシステムごとに望まれている事が違うが、話を聞いていれば、”気にしすぎ”か”無頓着すぎ”の両極端になってくる。それらの事は経験則でいくらでも話せるが、”大丈夫だろうか”と思っている客には、”殆どの場合は大丈夫ですが、狙われたら多分対策をしても無意味です”と答えてから、最低限の事だけはしておきましょうという事が多い。

開発者として、知っておくべき知識が”調べる”事で得る事ができます。
その場合には、調べた物をそのままにしておくよりは、自分の経験と結びつけておく事を推奨します。それだけでも、次に似たような話が来た時に”経験”として話が出来るようになります。