社内開発
大手企業でも中小企業でも、基幹システムはパッケージを使用するよりも内製品にした方がいいと思います。
企業により、受注〜請求までの流れも違えば、支払方法まで変わります。パッケージに合わせようとしても、どこかかゆいところが手が届かなくなります。そこで、パッケージをカスタマイズする話がでてきてしまえば、パッケージの良さが失われてしまいます。
開発スキルがない情シスは外注を使用して開発することになりますが、その時最低限外注の成果物を確認できるようなスキルを身につけておくことや、契約上も開発ソースも含めて、納品してもらえる契約にしておくことをお勧めます。ソース上の作りが悪いと今後の追加開発に影響します。相手ベンダー的には、その都度の受注を行いますので、ソースの作りよりも早く作り上げることを優先します。仮に作りが悪くても次回の追加開発時に、作りが難しいからという理由で、金額を上乗せしてきます。結果として、どんどん作りが悪いソースに出来上がり、最終的には追加開発もままならなくなります。
内製化を進めるにしても、成果物を確認できる力が社内SEには求められます。
社内SEのヘルプディスク
パソコンが起動しない、インターネットが使用出来ないなど、パソコン絡みでトラブルが発生すると、情報システム部員がトラブルの解決にあたります。
主な原因と解決策は、『パソコンを再起動する』といったことで8割方解決してしまいます。パソコンをよくわかってる方なら、とりあえず再起動してみますが、一般のか方はまだまだ再起動に抵抗があるようです。再起動しても治らなかったものは原因調査に入ります。と言っても、現象に合わせて簡単なチェックリストを流して、解決するか試みます。ハード障害ならば、壊れた箇所によってはパソコン自体の買い替えを勧めて、メモリやハードディスクの交換ぐらいならば、行います。ここまでで全体の95%は解決します。チェックリストを流しても解決しない場合は、時間ばかりかけても仕方がないので、ある程度原因がわからなかったら、リカバリを行なって治します。それでも治らない場合は、買い替えを提案します。
こう考えると、チャックリストさえ作成してしまえば、そんなにスキルが高くない人員でもできてしまいます。社内SEとして必要価値を高めるには、『チャックリストを作成する立場になる』か、作業員をまとめる立場を目指さないと存在価値がなくなっていく分野でもあります。ヘルプディスクをメイン業務にしている方は、ルーティンワークを管理することを意識して作業を行わなければなりません。よく聞く『社内SE=雑用』のイメージは、誰でもできる作業範囲が多いからかもしれませんね。実際には、『チャックリストリスト作成』も『作業員管理』もスキルが必要です。作業員ではなく、『SE』を名乗るなら、より精度の高いチャックリストや作業工程表など『成果物』を生み出していきたいところです。
社内SEの情報管理
近年、情報漏洩に関する問題がメディアなどで取り上げられるようになったおかげで、経営陣から会社の情報漏洩対策について聞かれることが多くなってきた。企業が顧客情報を外部に漏らしてしまうと、信頼を失ってしまい、それが業績に直結する問題に発展することもあります。経営陣としては、対策がされているか気になるのは仕方がないところでしょう。ただし、経営陣は、対策の方を気にしますが、情報管理をしすぎると経営効率の妨げになることまでは連動して考えていないことが多いです。一方では、『しっかりメールやデータの抜き出しにしっかり制限をかけろ』と指示し、また一方では『もっと早く対応できないのか?』と言います。情報漏洩のためのデータ抜き出し制限やその解除にかかる制約のせいで、素早く行動出来ないのを理解していないのでしょう。
情報システム部としては、経営陣に情報管理を厳格化は経営効率との『トレードオフ』の関係にあることを伝えていかなければなりません。情報漏洩は避けなければなりませんが、全ての情報が重要な訳ではありません。漏れても問題ない情報もあると思います。情報の重要度に1〜5などのランク分けを行ない、ランクを応じた管理を行なっていくことで、経営効率の妨げを最小限にすることができます。
情報管理での社内SEの役割は、
・経営層に対して、経営効率と情報管理はトレードオフの関係があることの説明責任
・情報の重要度の重み付けを情報を扱う部門への依頼
・重要度にあわせた効率的な情報管理
が求められます。
メールアドレス管理
メールサーバーの運用やクライアントパソコンにメールアドレスを設定まで、企業の規模により、どごまで社内SEが行なうかは変わってきますが、少なからずメールアドレス管理を行なう必要があります。社員に割り当てられたメールアドレスを台帳という形で管理し、社員の入社、退職などに合わせて、追加・削除していきます。社員用に割り当てを行なったメールアドレスは管理できるのですが、近年問題となってきているのが、スマートフォンなどに使用する、フリーメールと呼ばれるメールを会社用に勝ってにユーザーが使用する場合があります。これらのメールアドレスの把握は困難で、情報漏洩などのリスクが高まっています。
どんなに会社用ドメインメールの監視を強化しても、フリーメールでは、制限をかけるどころか、監視ログすら取ることができません。また、会社用ドメインメールでは、添付ファイルにパスワードを付けないと送れない用にしたり、上長承認のメールしか送れないようにしたり、制約を設けすぎると、会社用ドメインメール自体使用されなくなり、フリーメールを使うユーザーがでてきてしまう恐れがあります。
フリーメールを禁止する手段が実現難しいのだとしたら、社員のモラルに頼るしか有りません。日頃から、社員に対して、ITモラルの向上を図る取り組みが必要ではないでしょうか。
社内SEの仕事は、機械的に制約をかけるのではなく、社員に対して、なぜこのような制約をかける必要が出てきたのか、説明していくことが求められます。
ベンダーロックについて
あるシステムを1度導入すると、頼んだベンダーと保守契約を結んで、何かあったら対応していただいたり、新たなカスタマイズが発生するたびに別途改造費用を払い、変更対応してもらうことになります。変更対応に関して、どこか別のベンダーに相見積もりを取ったりすることが出来ず、保守契約を結んでいるベンダーが見積もり金額に対して主導権を持ってしまいます。対応スピードや金額に不満がなければ良いのですが、そこに不満があったとしても、なかなかベンダーを変更することができません。ベンダー変更=システム自体の変更を意味するからです。
グループウェアなどパッケージ製品ならいいかも知れませんが、経営スピードに直結する基幹システムとなると、対応が遅れたり、変更金額がかかりすぎたりすると、会社的には機会損が発生してしまいます。まだ対応が遅いだけなら、ましかもしれません。ベンダー側の担当SEが変更になった場合、システム全体の仕様を把握しきれなくなり、最終的には変更対応すらできなくなってしまいます。変更対応できないようになると、また、何億とかけて同じようなシステムを作る羽目になってしまいます。
基幹システムなど、経営スピードに直結するシステムは、社内SEが開発フェーズもプロジェクトマネージャーになり、複数の請負会社あるいは派遣会社のSEを指揮する方法が理想的だと思います。そうすることで保守開発時も社内で対応できますので、変更スピードが速くなります。開発規模が大きな変更案件にしても、複数の請負会社に相見積もりを取ることができ、コスト面でも有利になります。
ベンダーロック状態であることは、ベンダー側の都合で、会社に損害を与えてしまうリスクがあることを認識しなければなりません。
情シスの未来を考える
ここ数年、クラウドサービスがいろいろな分野で広がりをみせています。もともと一般ユーザーでは敷居が高かったサービスが、簡単に実現できてしまいます。そうなってくると、ITサービスを導入したい部署があった時に、今までは、ほぼ必ず情シスを通して導入計画が立てられていましたが、クラウドサービスは簡単操作、簡単導入であることが多いため、情シスを通さずに一般ユーザーの担当者だけで、導入、運用されていきます。必ずしも、情シスに頼らなくても、サービスを運用できてしまいます。(実はいろいろな問題も隠されています。)また、身近にインターネット環境があることで、一部の知識では、情シス部員よりも詳しいエンドユーザーがいたりします。その人たちからみれば、情シスは何の知識もない、サービス導入の邪魔な存在となってしまいます。
情シスの今後は、二極化すると思われます。技術や知識を持たない情シスは、必要性はどんどんなくなってやがては部署自体なくなるでしょう。(請求管理、ライセンス管理などは総務部でやればいいだけになります。)技術力、組織力がある情シスは、クラウドサービスを含めた提案をしていけば、存在価値が高まるでしょう。
どちらにしても、単なる御用聞きだった社内SEの人たちは、考え方を改めないと、変化の時代についていけません。自社の業務にあったIT投資を促すために、自社業務フローを詳しく理解し、最新のIT動向に目を向け続けなければならないのでしょうね。