中途採用に求められること

中途採用に求められることは何か、考える機会があったのでまとめてみる。

単なる人員補充ということもあるが、ほかにも「現在の人員を刺激する」という大切な目的があると思う。
やはり一つの会社に長くいると、自分では気付かずに、そのカルチャーに染まってしまう。そこにまったく違うカルチャーで育った人間を入れることで、足りない要素を補うのだ。
SEであれば、SIerなどでウォーターフォール開発に携わっていた人間が、アジャイル開発チームに入れば、（良いか悪いかは別として）チームが予算や納期に置くウェイトが高くなるだろう。

それがアジャイル開発の良さを消してしまうことになれば元も子もないが、そうではなく、中庸であることを目指すのが何事においてもよいのだと思う。

また、逆にそういうよい「影響」を与えるのが、まずは中途採用者の役目だろう。社内のルールであったり、システム屋であれば開発環境やコーディング規約も知らないうちには即戦力にはなれない。そのような面で活躍するのはジッと我慢し、まずは「前職とは違う部分」を自分で意識して、それが良いのか悪いのか、また悪いとしたらどう改善すればいいのか、臆せず話さなければいけない。きっとそれが最初の責務なのだろう。

全身の毛が逆立つこと

全身の毛が逆立つような、身体の底から期待感、感情が湧き上がるような経験がある。
それは不意に訪れるものだけれど、その瞬間は身の回りの全てが調和している感覚がある。

今日は久しぶりにそういう感覚を感じた。

SQL Server自習(Oracle)との違い

今までOracleを使っていたが、転職先でSQL Serverを使うため、一からお勉強。
Oracleとの違いをまとめていく。

まずはOracleのデータベース・インスタンスについて。


1.データベース/インスタンス

■docs.Oracle.comより抜粋==================

Oracleデータベース・インスタンスの概要

データベース・インスタンスは、データベース・ファイルを管理する一連のメモリー構造です。データベースは、CREATE DATABASE文によって作成されたディスク上の一連の物理ファイルです。インスタンスは、関連データを管理し、データベースのユーザーに対応します。

==================

なるほどね。

対して、SQL Serverは一つのインスタンスに複数のデータベースを保有できる。

そのため、小規模なシステムならデータベースを一つのインスタンスにまとめることで、Oracleのように複数インスタンスを管理する煩雑さや、インスタンスに割かれるメモリを抑えることができる。

2.管理ツール

Oracleのsqlplusに該当するものとして、「sqlcmd」が用意されている。

コマンドプロンプト上で「sqlcmd -S サーバ名(PC等)\インスタンス名(SQLEXPRESS等)」を発行してインスタンスにログイン可能。

犬猿の仲であるアプリとインフラ、なぜそうなるのか。

アプリとインフラは仲が悪い。SIerに勤務していた人なら、一度はそう思ったことがあるだろう。
ちょっとググッてみても、そういう例は枚挙に暇がないようだ。なぜ、そうなるのか。アプリ・インフラ両部門においての自分の経験をもとに考えてみる。
※念のため、アプリはシステム設計～開発、インフラは基盤構築およびその後のセキュリティパッチ適用などを指す。

一番は、アプリ部門とインフラ部門のインセンティブの違いだろう。インフラは動いて当たり前。例えば、電力、ガス、水道、電信、どれも片時でもサービス停止すれば非難の嵐になる。システムも同じで、株式取引システムの場合、相場開局中に取引ができないということがあれば、エンドユーザ（トレーダーなど）の損失は計り知れない。

そのため、インフラ部門としてはそのようなシステム停止の原因となる芽（セキュリティホールによる外部攻撃、OSのバグ）を取り除く必要があり、その対応としてパッチ適用やアップデートをする。しかし、それらのパッチが本当にアプリに影響を与えない保障はないので、アプリ側が正常に動作するか試験をする必要がある。

しかし、アプリ部門にとっては、ここで以下の問題が出てくる。
１．アプリ部門はインフラ部門と別の工数で仕事をするため、そのような試験をどちらの工数でやるのか。
２．アプリ案件で忙しいのに、インフラの手伝いをしたくない。

インフラ部門としてはパッチを当てないことで問題が発生したときの責任を回避したいため、非常にレアケースで起こるバグも潰したいが、アプリはそんなにたくさんのテストをやる余裕がないし、インフラ起因の障害が起きてもアプリ部門の責任はないため、どうしても後回しになる。
つまり、アプリ部門の優先度としてはどうしても　「アプリ案件＞インフラ案件」となってしまう。

以上のようなインセンティブの違いを解消するには、アプリ・インフラを横断して案件の優先度を決めればよいのだが、そのような両部門に対し超越的な権限を持つ部門がない。そのため、なんとなくのアプリ、インフラ部門のパワーバランスで物事が決まっていく。両者が納得できる「優先すべき基準」があればよいのだが、結局社内におけるパワー（企業で働く人は、こういうエートスが存在するのが分かると思う）がものを言ってしまうので、その軋みによって相手に対し悪い心象を抱くようになるのだろう。悪いのは「相手」ではなく、「組織の形」であるのだが。

これを解決するには最終的にはSIerに仕事を委託する事業会社ということになるのだが、案件をやらなかった場合のリスクに基づき優先順位をつけるための情報は、一次請けSIer内にある。そのため、適切な判断は難しい。結局は、これも多重下請構造の悪しき点だろう。

退職と雑感

新卒以来、4年間勤めたSIerを退職したので、雑感をメモ。

そもそも何故退職したかというと、やりたいことがあるから。今後伸ばしていくスキルを変えたくなった。裏を返せば、将来的に就くだろう業務（マネジメント）と、今後得られるであろうスキルに希望が持てなくなったためだ。今後は、社内SEとして内製化したシステム開発全般に携わる。なぜSIerから社内SEになったのか、備忘のため書き記しておく。

私が勤務していたのはいわゆる子会社系SIerで、親会社の業務のシステム化、開発～保守運用を担当する。いわゆるSIerなのでほか会社と同様、一次請けとしてベンダーや協力会社の人と業務をしていくことになる。そのためシステム開発屋として手を動かすのはほんの1年、2年ほどで、あとはマネジメントが中心となっていく。

ここが私の最も懸念しているところで、私はマネジメントをする前に、もう少しアプリ屋として手を動かしたいというのがあった。少なくとも、設計～リリースまでの全てのプロセスを熟知して、マネジメントをしていきたい。私は開発（コーディング、試験）だけだったので、要件定義や設計を知らない。ユーザが本当にやりたいことを知らずして、本当にベンダーや協力会社の人と協業していけるのか？スキルもなく上に立って偉そうにするだけの、私が最も嫌いとする人間になってしまうのでは？という思いがあった。

また、マネジメントと言っても、社内調整やベンダとの調整がほとんどで、しかもベンダ配下の開発者には直接指示ができる権限がない。そのため詳細な日程（モジュール単位のテストの期限など）を決めたり、業務プロセスの改善をしたりすることは難しい。それは請負先のベンダが統括していることだからだ。こちらとしては「お願いしますね」と頼み込むのが精一杯で、せいぜい出来るのは問題があったら報告書を書かせたり、怒鳴りつけたりが関の山だ。会社でうまく業務を回している人は、そういうことをさせるのが上手い。いわゆる親分肌といったところだ。私はそのようなスキルが向上したところで、今後役立つか疑問に思ってしまった。

実は、よく問題点が指摘されるこの多重下請構造に胡坐をかいていていいのか、いつも恐れていた。一年目は開発をしていたが、周りには優秀なベンダや協力会社の人がいた。彼らはシステムの機能、それを実現する内部モジュールを熟知し、業務効率化のためのツールを率先して作成していた。私はソースコードが読むのが精一杯なのに。常識的に考えれば、私をクビにして、彼らを正社員として雇ってしまえばよいだろう。もちろん総合職は将来の幹部候補なのだから、最初は大目に見て現場を覚えさせているんだという人もあるだろう。しかし、今後雇用は流動化していく目算が大きいので、幹部候補を育てるのではなく、最初からマネジメントの上手い人を雇えばいいだけだろう。

愚痴っぽくなってしまったが、しかし、よいことももちろんあった。大規模な基幹システムの開発～運用の実態を知れたこと、また大企業での意思決定がどのように行われるか分かったことだ。これについては別途書きたい。