情シス立ち上げマニュアル - 採用、マネジメント編
数年前にQiitaに書いた記事の大幅アップデート版です。
このシリーズは情シス何もわかんないけど、1人目の情シスを採用し、一緒に情シスを作り上げていく、そんなマニュアルです。1人目の情シスが採用できたあとは、一緒にこれを読んで実行に移してみてください。
全部で4つの記事に別れています。
- 採用、マネジメント → この記事はコレ
- 戦略づくり（ルール、業務基盤）
- 戦略づくり（セキュリティ）
- 戦略づくり（BPR / 業務改善）→ ※内容薄すぎた場合作成しないです
そして、本記事をレビューしてくれた某分家コミュニティの人たち、そしてより良いものにしようとコメントくださった、おかしんさん、ゆりねえの二人に感謝を。
想定読者
* 情シスがいない企業で情シス立ち上げを行おうとする人（CTOなど）
* 1人目の情シスとして入社して、これから立ち上げを行っていく人
※世の中のすべての情シスを知り尽くしているわけではありません。あくまで僕の経験と見聞きした情報を総合的に咀嚼した上での個人的な意見が多く入っております。この記事をもっと良くしていく、という観点でコメントいただければ、記事に反映することも検討しますので、ご連絡ください。
なぜ情シス採用するのか
まず大前提として、なぜ情シス / コーポーレートエンジニアを採用するのか？という背景をきちんと確認しましょう。
ネット企業の場合
一般的に多いのがビジネスが軌道に乗り、それに合わせて従業員が増えてきた。そんな中で、これからきちんと組織として環境、ルールを整えつつ、もっとビジネスを加速させていきたい、というパターンです。
非ネット企業の場合
この場合多いのが、最近の言葉でいうとDXやりたい、というパターンだったり、純粋にIT詳しくないので、専任の担当がほしいというパターンです。
現状を確認しよう
あなたの会社が今、どのぐらいの規模か？によらず、情シス的な業務というのはすでに誰かが兼任でやっているはずです。
それはCTO本人だったり、プロダクトのSREだったり、総務だったり、人事だったり...
そういう人たちにまずは「情シス的な業務ってどんなことやってる？」と聞いて、具体的にどんなことをやっているのか聞いてみましょう。そして、それらの業務負荷が高いかどうかも聞いてみてください。
また1人目の情シスを採用したときに、それらの業務を移管したいか、それとも情シスと協力して継続して担当していきたいか、はたまた、情シスになりたいかどうか、など聞いてみると良いかと思います。
兼任でやってくれていることに感謝と労いの言葉をかけつつ、現状や今後の意向を聞いておきます。これによって1人目を採用し、実際に業務を始めるときにスムーズに協力してもらえる体制が整うかと思います。
情シスの業務を知る
次に、情シスに詳しくない場合は、一般的に情シスの業務がどういうものが大枠で良いので把握しておきましょう。
その上で、どの業務を担当する情シスがほしいのか考えていきます。
情シス全体が担う領域は組織の規模、業種などで大きく変わってきます。大前提として、この神note記事をインプットしましょう。
その上で少し、書き方を変えたこの業務分類(12banパターン)を使って、ビジネスモデル別に理解を深めていきます。
情シスの業務分類（12banパターン）
ネット企業 - B2C
この場合、メインとなる領域はインフラやセキュリティ、ヘルプデスクとなります。3つのパターンの中では一番担当範囲が狭くなります。赤枠以外の項目については別の部門が担当したり、それなりに規模が大きくならないと会社の課題として出てこないです。
ネット企業 - B2B
B2Bの場合は、より事業サイドの業務が増えます。
BPR / 業務改善は範囲外としていますが、実際は企業次第です。
一応、プロダクト以外が範囲といえます。
非ネット企業
この場合は、この図すべて＋プロダクトも範囲になります。本当の意味で企業内のすべてのテクノロジーを管轄することになります。
情シスの転職環境を知る
採用の目的、情シスの一般的な業務範囲を理解した上で、どういうことを担当する情シスがほしいか、なんとなくイメージはつきましたか？
ここで視点を変えて、情シスを採用するために情シスの転職環境を理解していきます。
大まかに「大企業、中小企業」と「スタートアップ、ベンチャー」という区分けで考え方が変わることが多いです。ただ、大企業、中小企業の方との交流が少ないため、これは正しい認識ではないかもしれません。
大企業、中小企業の情シスは一般的にあまり転職をしません。5年以上在籍することが多いでしょう。逆にスタートアップ、ベンチャーの情シスはよく転職をします。数年単位で転職するのではないでしょうか。個人的にはエンジニアとして捉えたときにこれは健全だと思っています。（当然、人によります）
また全体的に40代以上が非常に多いです。過去、情シス採用に関する書類選考を200人ぐらいやっておりますが、8割40代以上でした。
一概には言えませんが、大まかなイメージとして、「大企業、中小企業」の情シスと「スタートアップ、ベンチャー」の情シスでは、下の記事にある、情シスとコーポーレートITぐらいには違います（結局はその会社のIT部門の方針次第なところなので、そういう傾向があるぐらいに捉えてください）
1人目の採用
さて、自社の情シス採用の目的、情シス業務、そして情シスの転職環境を理解した上で採用に挑みます。
- 具体的にどんなことを担当してほしいか？
- どのような考え方を持っていてほしいか？
- 手が動く人材がいいか？
- それとも最初からスケールすることを見越して情シス部門のマネジメント経験がある人がよいか？
- ほぼおまかせできる人材がいいのか？
- それとも一緒に相談しながらやっていける人がいいのか？
こういった視点でジョブディスクリプションを考えていきます。
ここでもし私なら、という一例をあげておきます
必須要件
- 情シス、コーポレートエンジニアとして経験があること
- エンジニアとしてインフラ、開発のどちらかの経験とマネジメント経験の両方があること
- 継続的な学習をしていること
- ご自身である程度、課題発見、解決が行えること
歓迎要件
- ソリューションありきでなく、課題ベースで考えられること
- ヘルプデスクなどの顧客対応の経験があること
- APIを使ったスクリプト開発ができること
- 社外でイベント登壇した経験があることジョブディスクリプションを考えたら、採用チャネルについて考えていきます。2020年7月時点において、情シスで有効な採用チャネルは4つです。
- 求人サイト
- Green → ネット企業中心
- Wantedly → ほぼネット企業
- Bizreach → 大企業、ネット企業多め
- Doda → 大企業、中小企業中心
- 転職エージェント
- コミュニティ
- 情シスSlack → リクルートチャンネルあり
- リファラル
自社の状況に応じてこれらのチャネルを使って採用していきます。採用できたら、この「情シス立ち上げシリーズ」の戦略づくり編を1人目の情シスと一緒に作ってみましょう。
軸をつくる
どこかのタイミングでミッション、バリュー、哲学、軸、言葉は何でも良いので、情シスとしての軸を作っておくことをおすすめします。
なぜ、必要なのか？
それは課題解決するときに、コストに振り回されない、ためです。
例えば新しいSaaSで課題解決しようとするとき、当然、1つの基準としてコストがあります。しかし、必要以上にコストを重要視してしまうと、情シス、企業において不幸を招きます。
それは運用にかかる負荷が大きかったり、、従業員側での作業が多くかかったりするのです。またこういうのは組織が大きくなってもスケールしないパターンだったりするのです。（※具体例）
例えばわかりやすいのが、クラウドファースト、という軸です。
これを設定しておくことで、クラウド前提で解決策を考えてみる、その上でコストやらなんやらを検討する、という考え方になります。そうすると、上記のようなスケールしない、という負債を減らしておくことができます。
ちなみに、この考え方は昔、Googleの方に教えてもらった考え方です。
かなり記憶が曖昧ではありますが、前職では
- モダンファースト
- 日々色々なSaaSが出ているので、まずはモダンな選択肢を考えてみるという意味。過去の経験にとらわれずにゼロベースで考えるという意味もあり
- チャレンジ & スピード
- 早く試して、早く失敗して、学ぶという意味。失敗を許容するという意味もあり
- コラボレーション
- 積極的に他の部門と交流する。何か導入するときIT部門だけでなく、関連部門を巻き込むという意味
といった、軸を設定していました。
情シスのマネジメント
改めてマネジメントという項目を作ったのは、情シスとしてこういう傾向にあるので気をつけてください、という意味合いでこの項目を入れました。
情シスの特徴として、
1. 疲弊しやすい（気がする）
2. 自分の存在価値に悩む（気がする）
3. 定型業務の多くかかえたまま、定型業務の圧縮や業務効率化、新規サービス導入を行わなければいけない
の3つが、やや顕著な気がします。
特に3つ目は極少数で増加する定型業務に対応しつつ、この定型業務の業務改善、また本来の仕事である組織の課題解決の3つを行わないといけない、というフルスタックにならざるを得ない特徴を持っています。
この辺をうまくフォローしてあげると、勝手にモチベーションを上げて働いてくれます。情シスに限らずですが、マネジメントの基本みたいなところです。
私はいつもラインマネジメントの立場になったとき、毎回この書籍の内容を読み直し、実行しています。マネジメントの書籍は世の中にたくさんありますし、経験豊富な方もたくさんいるでしょうから、その方たちから学びましょう。
この本にかかれていることを簡単に記載します。
1. 匿名性
一人情シスは孤独です。自分が無視されていて、誰でも代わりのきく匿名の存在だと本人が感じていると疲弊してしまいます。適度に情シスの仕事に関心を払うのがポイントです。
2. 無関係
一人情シスは孤独です。情シスの仕事が誰かにとって重要であることを、本人が理解していないと疲弊しています。情シスの仕事が誰にとって意味があるのか、適度に言葉にしてあげるのがポイントです。
3. 無評価
人は承認欲求を持っています。この仕事をやるのは当然だ、という態度で接していると相手は疲弊してしまいます。まずは昨日と同じ今日が訪れたことを褒めてあげるのがポイントです。
マネジメント部分はもっと書きたいことがあるのですが、情シスに特化した話ではないので、この辺にしておきます。
2人目の採用
さて、1人目が採用できて、ホッと一息。
2人目を採用するタイミングは非常に難しいです。ビジネスが急成長し、従業員が急増している、という前提で言えば、実際に1人では回らない、という課題が表面に出る前が望ましいです。
逆に従業員が急増していない場合は、そこまで急がなくても大丈夫です。
一般化した考え方の1つとして、従業員数50名につき、情シス1名が相場と言われています（大企業とかはわかりません）
例えば採用計画上、年内に従業員数50名を超えることがわかったら、2人目も年内に採用するという形でよいかと思っています。
もう1つ注意することがあります。これは可能であればですが、できれば、1人目と2人目の間に上下関係をつけたほうが良い、と思っています。
なぜなら、考え方の違いによって、チーム崩壊するリスクがあります。（そして、そういう事案も結構聞いたことがあります）一応、このあと説明する情シスとしての軸を設定したり、1人目と2人目の相性を重視して採用することで、リスクを低減させることができます。
この職種に限らずですが、多くの人は過去の経験を引きずります。昔、この製品、技術、SaaSがよかった、前職はこうやっていた、などなど。
情シスの場合、それがやや顕著な気がしています。また、このような0→1をやりたがる人材は少なからず、オレオレ的なところがあるのかもです。
補足 : 軸を設定しない場合の具体例
具体例で説明します。
例えばMicrosoft Officeが必要で契約したいという場合を考えます。
現在、Microsoft Officeはパッケージ版（買い切り）とクラウド版（月額）があります。
この2つの選択肢を単純に製品のコストという基準で見ると、確実にパッケージ版になるでしょう。どこかの時点でクラウド版のほうがTCOが高くなるからです。
じゃあ、パッケージ版が正解なのでしょうか？
運用を考えてみます。
1. Microsoft Officeを使いたい旨の申請を出してもらう
2. Microsoft Officeのパッケージ版を買う
3. 到着まで待つ
4. 納品されたらDVDドライブをつなげてインストールする
5. メディアとシリアル番号を管理台帳に記載して管理する
こんな風な運用になるのではないでしょうか。
これってスケールしますか？
たとえば50人ぐらいだったら良いかもしれません。じゃあ100人なったら？200人になったら？ヘルプデスクの追加人員が必要かもしれません。
この記事が気に入ったらサポートをしてみませんか？