heyの社内ITを支えるコーポレートエンジニアを探しています!
2021/02/15
追加募集はじめました
〜〜〜
2020/08/28
内定承諾もらえましたため、この募集は閉じます・・!
〜〜〜
2020年4月にフロントエンドエンジニアからコーポレートエンジニアに鞍替え(STORES ECから、いわゆる情シスであるITチームに異動)して今に至るのですが、このたびコーポレートエンジニアを 1名 増員することにしました 🎉 🎉 🎉
増員に至るまでこの数ヶ月やってきたことや、どのような方に来てほしいかを書きました。
興味を少しでも持っていただいた方は情報交換も兼ねてぜひカジュアル面談(リモート)に来てください!
次の採用サイトからでもいいですし、TwitterのDM(@howdy39)からでもOKです〜
2Q(4~6月)は立て直しフェーズ
冒頭に書いたように4月に異動したのですが、別部署からheyのITチームを見ていたのと実際の中から見るとだいぶ違いました。
例えるならば、いまにも崩れ落ちそうなジェンガ状態でした。
※ チームとしてもIT基盤としても
そのため、異動後の数日間は仕事の進め方の観察や過去のSlackのログをたどった情報収集に徹し、課題を洗い出しました。
そして一つずつ課題をクリアしていくことにしました。例としていくつか記載しておきます。
タスク管理
まず目についたのはチームへ上がってくる依頼タスクをきれいに捌けていないことです。
依頼対応を同時におこなっていたり、依頼を途中で忘れて放置していたりですね。
問題解決のためにチームの運用に最適化したタスク管理用のSlackアプリをheroku + nodeで自作しました。
(バックグラウンドは元々使っていたTrello。API経由でTrelloにカードを作ったりdoneにしたりしている)
この依頼は私がやるぞアピールのために自分にタスクを振ったり、チーム内の他の人に依頼したいときに使っています。Slackアプリなのでスマホからでも依頼メッセージを選択してタスクをサッと作成出来るようにしています。
ワークフローの整備
ITチームへの依頼申請系がとても多く、入力された内容をITチームが入れ直すだけという謎作業が多々発生していました。
直接社員が出来るように権限を委譲したり、Slackの標準機能(ゲストの招待や共有チャンネルの作成)を使うようにしたりして、作業自体を減らしました。
セキュリティ改善
SlackやG SuiteのカレンダーやDriveの設定を見直して、設定変更をおこなったり、良くない共有を検知するGASの作成などをおこないました。
その他にもSlackのAdminだらけになっていたのを減らしたり、大小合わせるとかなり手を加えました。
セキュリティに関してはまだまだなのですが、多少は安心して使えるようにはなってきたと思います。
ドキュメンテーション
作業内容がほとんど作業者の脳内だけの状態で可視化されていませんでした。
heyではesaを情報共有ツールとして使っているのですが、ドキュメントのカテゴリ分けや記載内容の指針を作り、新しく入った人(私)が作業できるようにドキュメント化を推進しました。
またドキュメントのレビューをして認識をあわせたり、ドキュメントを作ってから進め方を相談するなど、ドキュメントベースの会話ができるように徐々に整えています。
3Q(7月)〜は攻めのフェーズ!
2Qは立て直しで終わってしまいました。。。
しかし!
2Qでチームの作業自体を減らしたり交通整理をしたので、3Qからは各種プロジェクトを進めていく攻めのフェーズになります!
半年ぐらいを見据えた部分だと次のようなプロジェクトがあります。
・Intune, IDaaS, CrowdStrike etc の導入・運用開始
・おざなりになっていた棚卸しやG Suite統合
・IPOに向けた各種準備
今求めているコーポレートエンジニアには一番上の Intune, IDaaS, CrowdStrike etc の導入・運用 など技術的なことを中心にやってもらいたいと思っています!
私が情シス出身ではなくソフトウェア開発出身のため、課題の発見と改善、ドキュメンテーション、プロジェクト回しなどはできますが、コーポレートの技術に弱いので技術面で先導していただきたいです。
どういう人に来て欲しいか
「何かを変える」ということは「過去を否定すること」と同義だと思います。その「何か」を決めた時は最善の一手だったのかもしれません、しかし今それが最善とは限りません。
変えることは大きな痛みを伴います。
「何か」を決めたのが今いるチームメンバーかもしれませんし、変えることによって社内の人にお手数をかけるかもしれません。
今のやり方をそのまま維持しつづけるのが一番ラクでしょう。
失敗して怒られることもなければ責められることもありませんし。
※ 私は変化を求めた結果の失敗で怒る気も責める気もありません
しかし変化できない組織はいつか崩壊します。
私がここ数ヶ月やってきたことは、チームの人が今までやってきたことの否定です。良い方向に変化させるため、反発も覚悟の上での否定です。
※ 反発は起きなかったです
変化を恐れない人、論理的におかしいことや辻褄があわないことをたとえいろいろな人と対決することになっても議論できる人、を求めています。
さいごに
私達が目指す社内ITのレベルは「そこそこ」ではありません。
「heyさんの社内ITめっちゃイケてるなー」と言われるようなレベルを目指しています。
STORESというサービスにまけない最高の社内ITを一緒に作っていきたい方をお待ちしています!
この記事が気に入ったらサポートをしてみませんか?