SHIFTとは？

私たちSHIFTは、品質保証・テストサービスを軸に、ソフトウェア開発やコンサルティングなど多岐にわたる事業に取り組んでいる東証プライム上場のIT企業です。

■市場ニーズに応え、高い売上高を継続

• 2005年に創業。連結従業員数13,000名超、売上高約1,100億円。
• 売上高は10年で約50倍。複数の事業を立ちあげ拡大しつづけています。
• 「IT業界の多重下請け構造の変革」を掲げており、プライム案件比率は73.5%。
• （※ソフトウェアテスト関連サービスにおける外部顧客への売上高に占めるエンドユーザー企業への売上高比率）
• 売上高3,000億円を達成することを目標とした中期成長戦略「SHIFT3000」を掲げています。

■フェアでオープン。明確な評価基準で「やりがいと報酬」を大切に

• 人事評価は相対評価ではなく、絶対評価を採用。年間平均昇給率は6.9％。
• 経営陣が半期に一度、120時間以上をかけて「従業員一人ひとりの5年後」に向き合っています。
• 技術を尖らせるのか、マネジメントスキルを磨くのかなど個人のキャリア実現を支援。実績に加え、スキルやマインドも評価。
• 「やりがいのある仕事」と、成果に対して「報酬」でしっかり応える好循環を生み出しています。

■安定も、成長も。30代からの理想をかなえる職場を目指す

• 月平均残業時間は8時間、離職率は6.1％。
• UJIターン歓迎。仙台・浜松・名古屋・大阪・広島・福岡などに拠点あり。
• パパママコミュニティや介護のお悩みコミュニティの設置など独自の取り組みも多数。
• 70歳定年制で役職定年もなし。

※各実績数字は2024年8月期時点のもの

SHIFTについてくわしく知りたい方は、下記コンテンツをご覧ください。

自己成長、年収UP、Uターンなど、さまざまな期待を胸にSHIFTへ。生の声を紹介

30代は、仕事やプライベートにおいて変化を意識しはじめるタイミングではないでしょうか。SHIFTには年間数千人のITエンジニアが入社しており、30代の方も多数含まれています。

彼らはどのような理由で転職を考え、なぜSHIFTを選んだのか、生の声をお届けします。その背景には、キャリアに対する真摯な思いと、SHIFTが提供する成長の機会がありました。

【大手SIer出身、現：グループ長補佐】

■転職を考えた理由は？

さまざまなプロジェクトを経験してきましたが、同じメンバーと同じようなプロジェクトの進め方だったので、マンネリやモチベーションの低下を感じる時期がありました。

10年も同じ環境にいると将来のキャリアが予測でき、現状の延長では自己成長に限界があると感じて、転職活動をはじめました。

■SHIFTに決めた理由は？

転職を考えはじめたとき、ちょうど個人目標のテーマを「品質」に設定していたんです。現場での取り組み以上に、品質についてより体系的に学び、深く理解を深めたいと思っていて。

そんななかで、SHIFTの標準化・体系化された品質保証のアプローチを知り、これまでとは異なる形で品質向上に挑戦できる点に魅力を感じ、入社を決めました。

▼イベントレポートはこちら

【中小SIer出身、現：インフラエンジニア】

■転職を考えた理由は？

今後のキャリアとして技術を極めたいと考えていましたが、前職では次のステップとしては管理者としてマネジメントを担うことが決まっていました。

そのため、技術者として邁進できる環境と、子どもが生まれたこともあり、中長期的に収入アップが期待できる場を求めて転職しようと思い立ちました。

■SHIFTに決めた理由は？

右肩上がりに成長している会社でないと収入アップは望めないので、SHIFTの勢いに惹かれましたね。

実際に面接を受けてみたら「配属部門はここ1〜2年で設立した新部署で、これから拡大していくフェーズ」とのこと。

1つの部署の立ちあげ期に関われるのは面白そう！とますます魅力を感じ、私もいっしょに挑戦したいと思い入社に至りました。

▼転職体験記はこちら

【独立系SIer出身、現：PMO】

■転職を考えた理由は？

前職の勤務地は関東でしたが、地元は名古屋。以前から30歳を目安にUターンして地元で腰を据えたいという思いを抱いていました。

地元の友人が結婚を機にUターンした話を聞くうちに、私も地元で新たなキャリアを築き、家族や友人との時間を大切にしたいと考えるようになったのがきっかけです。

■SHIFTに決めた理由は？

SHIFTは名古屋に拠点を構えており、Uタ―ン転職が実現できることに加えて、今後のキャリア形成を考えると、30代でさらなる成長を目指すのであれば、事業領域が広く、多様なサービス、ソリューションをもった会社でチャレンジしたいと思っていました。

また、名古屋でモビリティ領域のキャリアを積めることも魅力的に感じてSHIFTに決めました。

【SES出身、現：開発エンジニア】

■転職を考えた理由は？

前職の業務内容は決められた範囲内での作業が中心で、将来的なキャリアパスに不安を感じるように。

このままでは、自分のスキルや知識が限定的なものに留まり、成長の幅が狭まってしまうのではないかという危機感から転職を決意。

プロジェクトを統括・推進できる技術や能力を身につけ、上流工程で活躍できるエンジニアになることを目指しました。

■SHIFTに決めた理由は？

面談や面接を通じて、前職では実現できなかった技術力や知識の向上が可能だと感じました。

また、会社の業績がいいことから、優秀な人材が多く集まっている印象を受け、そのような環境で働くことで自身の成長につながると考えました。

さらに、SHIFTには多種多様な業態のグループ会社があり、グループ内で技術やナレッジを共有する文化にも非常に魅力を感じました。

SHIFTに興味をお持もちいただいた方へ

いかがでしたか？転職はキャリアの方向性を大きく変える重要な決断です。特に30代は、これまでの経験を活かしつつ、大きな飛躍を見込める環境に飛び込む絶好のタイミング。

SHIFTに少しでもご興味をおもちいただけましたら、各種求人をご確認ください。

また、本サイトには、「仕事を知る」、「転職体験記」などをテーマにした従業員インタビュー記事を掲載中です。ぜひ気になるタグ、キーワードで絞り込んで探してみてくださいね。

インタビュー記事一覧はこちら

WebSocket×AWS Lambdaで挑戦するリアルタイム通信

みなさんこんにちは、辺見です。今回はリアルタイム通信についてお話しさせていただきます。よろしくお願いいたします。私は、セキュリティコンサルタントです。沖縄ははじめてです。ワクワクしております。

みなさんは、リアルタイム通信が必要なアプリケーションをつくりたいと思ったことはありませんか？私はスライドのような条件でクライアントからリクエストいただき、つくることになりました。

そのときは、想定最大同時接続数とグローバルリーチという条件があったため、サーバーレスでつくることになりました。

今回の発表では、リアルタイム通信をつくるにあたり、どんなことに失敗したのかをお話しさせていただきます。

ところで、リアルタイム通信ですが、実装するときは以下のスライドに記載したようなものが候補にあがるかと思います。

今回はWebSocket通信を選びました。AWSでつくることにしたのですが、AWSのサーバーレスでSocket通信を実装します。スライドのようにフロントエンドはVue.js、バックエンドにはNode.jsを選びました。

データベースはAWSのサービスです。スライドではいくつかのAWS構成案が提示されております。

それぞれの案にはバックエンドの構成に違いがあります（以下は採用した構成）。

この構成ではAPI Gatewayに2時間のコネクション制限があり、これは解除できませんでした。また、Lambdaはユニキャストしか使えませんでした。2時間のクォータ制限ですが、クォータ解除はありませんでした。

次に、ユニキャストしか使えないこととDynamoDBについてお話しさせていただきます。こちらはチャットアプリの一般的な画面です。画面内のボタンを押すことで発火するアプリケーション内部の動きを整理します。

まず1番でログインボタンを押すと、Amazon DynamoDBでコネクションIDを作成します。2番で送信ボタンを押すことで、メッセージをDynamoDBに格納できます。

3番でメッセージは画面に表示されます。4番で退出ボタンを押すと、DynamoDBからコネクションIDを削除するという仕組みです。

次にアプリケーションを含めた全体像を見ていただきます。

この構成の場合、ユニキャストでDynamoDBに入っている全コネクションIDに対し、Lambdaでメッセージを1件1件ループで送信することになります。ここで課題が見えました。 

ユーザーへメッセージが届くのが遅かったり、届かなかったりする事象が発生しました。

サーバーサイドのログにはエラーが出ていましたが、開発者側からすると「チャット画面にログインしている人が少ないので、処理は問題なく通るはずなのですが、どうして…？」という状態になりました。

「幽霊コネクションID」という誤算を乗り越えて

トラブルシュートとして、ユーザーのコネクションIDがDynamoDBに残りつづけていることを確認しました。「切断処理を実施したはずなのに、なぜ残っているのか？」という疑問がありました。

ユーザー側のコードを解析したところ、ユーザーがチャットから離脱する際に、退出ボタンを押さずにブラウザを閉じていました。

その結果、API Gatewayはユーザーの離脱を認識できず、コネクションIDがDynamoDBに残りつづけていました。

解決方法として、新しくユーザーがログインしたときの処理に別の処理を追加しました。まず新規ユーザーの接続を確認します。

その後に全クライアントへのメッセージを送信する処理において、このとき、ユーザーがすでにブラウザを閉じていればエラーを検知し、メッセージ送信時にエラーが発生した場合、該当のコネクションIDをすべて削除するようにしました。

これで不要な処理がなくなり、コードが改善されました。

もう一つ、AWSが公式に発表している構成があります。こちらの構成を選んだらどうなっていたのかという点は、こちらのスライドをご覧ください。

ご清聴ありがとうございました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

クラウドアーキテクトが振り返る、AWSセキュリティ構築案件

「6ヶ月でカットオーバー！ファンクション型BtoB SaaSで実装したインフラレイヤーのセキュリティ」というテーマで発表させていただきます。株式会社SHIFTでクラウドアーキテクトをしている寅野と申します。 愛知県出身です。趣味は釣りを含めて基本外で遊んでいます。

今回ご紹介するシステムのアーキテクチャは以下の通りです。

AWSのネイティブのサービスで、ファンクション型のWebサービスとして典型的なサービスを利用しており、フロントエンド、バックエンド、キュー・データストア、外部サービス連携用にハブ環境を利用しています。

このようなサービスに対して、どのようなセキュリティ要素を入れ込んだのかご紹介します。大きくは、アーキテクチャ、権限統制、振る舞い検知、脆弱性の対応を行いました。

1. アーキテクチャ

今回はアーキテクチャの部分を重点的にお話しさせていただきます。アーキテクチャのなかでも大きく3つあります。

1つ目は、階層的なアーキテクチャをとるということです。今回の事例の構成をサービス観点で見ると、このような図になります。

①でCDNを利用することにより、インターネットからパブリックのアプリケーションへの直接のアクセスを防いでいます。そして、②でデータへのアクセスをアプリケーションに限定しています。

これらをサービスではなく、Amazon Virtual Private Cloud （VPC）リソースの観点で整理すると以下のような図になります。

これはAWSのひとつの特徴なのですが、ローカルルート が存在するため、ルートテーブルのみで特定サブネットへのアクセスを防ぐのはむずかしいです。そのため、ネットワークACL とセキュリティグループ を活用し、データが置かれているリソースへの接続元を制限していきます。

2つ目は、グローバルやリージョンリソースへのアクセス方法です。通常、インターネットへの接続経路を作成し、リソースがアクセス可能な状況にすることもできますが、インターネットへのアクセス経路があるというだけでリスクの検討や対策が必要になります。

このような場合は、VPCエンドポイント というサービスを使って、インターネットへのアクセス経路をつくらずにグローバルやリージョンリソースにアクセスできるようにする対策をおすすめします。今回の例でも実装しています。

3つ目 がメンテナンスです。アプリケーションを保守運用していると、どうしてもリソースに直接アクセスしたくなるケースが出てきます。その際に、以下のスライドに並んでいるようなサービスをご利用いただくと、インターネットからのインバウンドを開けることなくメンテナンスができるようになります。

また、ツールを使う際にアップデートなどが必要な場合は、専用のLambda関数などを用意して、NATゲートウェイやルートテーブルの更新を行い、必要なときだけアウトバウンド通信で取得できる環境を準備し、常時開放しないことが大事です。

2. 権限統制

次に、大きなポイントの2つ目の権限統制です。権限、暗号化、シークレット管理がポイントになります。

権限では、リソースにロールを付与することは一般的ですが、さらにリソースポリシーを使ってリソース側から想定外のアクセスを防ぐ二重の対策が可能です。また、暗号化を併用することで、対象リソースの権限だけでは、利用した暗号鍵への適切な権限がないとアクセスできなくなり、よりセキュアな構成にできます。

3つ目 がシークレット管理です。アプリケーションのデータなどにアクセスする際に利用するシークレット情報の管理です。設定ファイルに記載する必要はなく、シークレット情報へのアクセスもLambda関数などに権限を使ってコントロールできるため、よりセキュリティに配慮した構成にできます。

3. 振る舞い検知／脆弱性チェック・防御

大きな観点の最後、3つ目です。これらは、アーキテクチャや権限上問題ない場合でも、リクエストが怪しい、もしくは構成上望ましくないものや脆弱性を含んだアプリケーションの本稼働を防ぐ仕組みです。

1つ目がWAFです。これはアプリケーションリクエスト内容をチェックし、怪しいものをブロックまたは検知するために導入します。

2つ目は、何らかに侵入された後の早期検知を想定していますが、GuardDutyなどのサービスを用いることで、アプリケーションの振る舞いやログなどをチェックし、アプリケーションが通常時と異なり、怪しい動きをしていれば検知できます。

最後の3つ目は、構成上好ましくないものや脆弱性が含まれるアプリケーションのデプロイを検知し、事故を未然に防ぐ対応です。これは本番だけでなく、その前のフェーズや環境で検出できるとよりいいです 。

以上、駆け足になりましたが、セキュリティ対策のご紹介でした。
ご清聴ありがとうございました。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

「点が線へ、そして立体へ」。SREという天職と、SREの真価

―――まずは島田さんのSREとの出会いから教えてください。

島田：はい。時間をかなり遡ったところからお話しさせてください。

SIerに入社して、最初は百貨店系の受注システムのハンディプロジェクトでDBやWindows／Linuxサーバーの運用を担当し、次はネットワーク、その後はヘルプデスクといった具合に、1〜2年のスパンでまったく違う職種を渡り歩くことになったんです。

「これって全然違う仕事をしているけど意味があるのかな」と悩みました。

DBエンジニアとしての深さを極めるわけでもなく、ネットワークエンジニアとしての専門性を高めるわけでもなく…キャリアの「点と点がつながらない」ことに1年目から5、6年目までずっと不安を感じていました。

そんななか、最初の転機が訪れたのは、大学のサーバー・ネットワーク構築運用案件に携わったとき。システムのユーザーは、教員・職員・学生です。

セキュリティを確保しつつ、学術的な研究をシステムが阻害しないよう設計するにはどうすればよいか――この視点で、フロントからバックエンドまでシステム全体を俯瞰できたのはとても貴重な体験でした。

この案件ではじめて、それまでの経験が活きる場面に出会ったんです。「こうやって少しずつつながるんだな」と感じました。

―――なるほど。でもそれだけでは満足できなかったのですね？

島田：そうなんです。もっと深いところまでやってみたいと思い、大手企業に転職して、そこではじめてSREに出会いました。

それまではお客様のシステムを守ることが仕事でしたが、今度は自社サービスを構築・維持する立場になり、ビジネス目線で考える必要がありました。

前述の大学の案件では技術的な「点と点が平面的につながる」感覚がありましたが、SREでは技術だけでなく、事業の価値向上を目的に据えて「なぜそのサービスを提供するのか」「なぜその機能が必要なのか」というビジネス視点で考える必要がありました。

技術とビジネス、2つの視点がかけあわさり、キャリアの点と点が「立体的に」つながったんです。

―――SREによってキャリアが立体的に。そんななか、なぜ転職を？

島田：単刀直入にいうと、前職でSREとしてやれることが少なくなってきたからです。

SREの考え方を導入して、みんなでプラットフォームを改善していったのですが、あるところから成熟してしまい、「あとはそれに沿って平常稼働させるだけ」という世界観になってしまったんです。

培った経験が活かしづらくなってしまいました。

もう一つ大きかったのは、SREの価値を広く伝えたいという思いです。

SREについて調べると世の中には「Googleや大企業だからできるんだ」という反応も多くて。でも私はそうではないと思った。

すべてGoogleと同じことをする必要はなくても、要点を押さえて企業規模やサービスにマッチするSREのやり方があるはずだと。

そんな思いで、まだSREをまだ積極的に導入していない会社を支援していきたいという想いで転職を決意しました。

私のSREに対する情熱や、実際にやりたいと思っていることをきちんと聞いてくれたのがSHIFTだったんです。

いままでなかった、ツールフリー＆伴走型のSREサービス

―――SHIFTに入社されてしばらくしてから、SREサービスを実際に立ち上げたそうですね。世の中にはないまったく新しいものと聞いたのですが。

島田：Googleは自社プロダクトの信頼性担保のためにSREという手法をもち込みました。まず前提として、SREは自社プロダクトに対して行うものです。

企業にとってDX推進は避けて通れない課題ですが、その実現には「内製化」が不可欠です。外部依存を減らし、競争優位性を高めるためです。

しかし日本企業では、外部ベンダーに過度に依存し「ベンダーロックイン」が起きがちです。

その結果、コストの肥大化だけでなく、柔軟なシステム変更や市場変化への対応がむずかしくなります。

自社プロダクトに対して行うSRE活動と、DX推進の必須条件である「内製化」は切り離せない関係にあります。

だからこそSHIFTでは、お客様のSRE支援にあたって、「伴走型」で取り組み、「内製化」の力をいっしょにそだてていくことを大切にしているんです。

―――なるほど。SHIFTが提供しているのは、具体的にはどんなサービスですか？

島田：まずSREの本質は「事業価値向上」です。

そのためには、組織がシステム、サービス、プロダクトにおいて適切なレベルの信頼性を持続的に達成できるように、「スピード×品質のシーソー」をコントロールしていく必要があり、信頼性の担保に関わるすべてのことにSREは責任をもって向き合います。

その役割を果たすため、SHIFTではお客様のシステム・サービス・体制の成熟度別／ご予算別にあわせてフレキシブルに提案内容をカスタマイズしたSREサービスを提供しています。

要件定義～設計～実装～運用設計～教育（リリース引き渡し）～運用のすべてのフェーズを網羅していて、例えば「なぜか障害が多くて、慢性的に時間がない」という場合、アセスメントから入りますが、「高度監視化ができていないことに課題がある」と認識されているお客様には、導入コンサルティングから入ることもあります。

綺麗なレポートを作成し「論理的にあなたの課題はこうで、これを導入すれば解決します」と提案するだけで終わることはしません。

導入後、最適化やSRE活動の定着まで伴走させていただく場合もあります。このアプローチが他社にはない強みです。

―――お客様ごとに最適な解決策を提案するとなると、選定するツールも幅広いのでしょうか？

島田：はい。特定の製品に縛られないマルチベンダーなので、お客様が使いたいものに合わせて対応できますし、どのツールを使えばよいかわからないお客様には、最適なツールを選定するところから支援します。

製品に縛りがない分、つねに最適解を模索しつづける姿勢が重要です。

プロジェクトの背景や前提があることもよくありますが、それでも私たちはつねに脳で汗をかき、最適解を見つけ出す努力をつづけなければなりません。

実はあるプロジェクトで、技術的に国内に先例のない「Splunkのコンテナ化」を行うことになったものがあって。

決定事項だったので後戻りはできず、またその後プロジェクト自体も成功したのですが、私は「本当にこれが最適なのか」と自問自答しつづけました。

妥当性をつねに問いつづけ、お客様と対話しながら進めていくこと、これを大切に心に刻んでいます。

信頼性は会話によってつくられる、私にとってのSRE

―――これからますます引き合いが増えていくなか、いっしょに働く仲間にはどんな方を求めていますか？

島田：まず知的好奇心です。SREはインフラ全体を見る必要があるので、インフラだけでなく、アプリケーション開発、ネットワーク、DBなどさまざまな領域の知識が必要になります。

そんなスーパーマンはいないので、自分の得意分野をベースに、課題に応じて「これはネットワークの知識が必要だ」「これはPythonの知識が必要だ」となったときに、自ら学んでいける知的好奇心が重要です。

「SREは会話だ」という言葉があるのですが、人に相談でき、円滑にコミュニケーションがとれ、助けを求めることができるかも重要です。

わからないことを恥じず、自分のできないことを認め、あるべき姿に向かって最適な行動をとれる人がSREに向いていると思います。

―――SREエンジニアとして、SHIFTではどのような姿勢が評価されるのでしょうか。

島田：私自身、目標設定は「お客様の課題解決への貢献」を軸に上長とすり合わせています。

何よりむずかしいのは、お客様と課題感を共通認識としてもつこと。そのために大事にしているのは「ここが問題だ」と提起しつづけ、まわりを巻き込んで解決していくことです。

発信すること、相手の話を聞くこと、共通認識をもつこと。そのうえで、技術的な知識や体制の組み替えなどを活用して、課題を解決していくこと。

私自身、これを実践することで評価していただけているのではないかと思います。

―――ご自身の今後のキャリアパスについてはどのように考えていますか？

島田：私はSREのエバンジェリスト、つまりSREの伝道師として活動したいと考えています。

事業としてますます多くの企業のSREを支援していくためにも、まず社内にSREを伝え、さらに対外的にもSREを広めていくことが重要です。

実際、社内でコミュニティを立ち上げ、勉強会を開催し、社外イベントへの登壇もしはじめています。

SHIFTはテストのイメージが強いですが、SREの領域でもSHIFTブランドを確立したい。そんな「やりたい」を自分たちで実現していけるから、やりがいも生まれます。

人間が携わる以上、不確実性と向き合わなければならないITシステムの構築運用において、SREはみんなが幸せになる道を探求する営み。

これからもその思いを大切に、SHIFTのSREサービスを広げていきます！

―――本日はお忙しいなか、ありがとうございました！

（※本記事の内容および取材対象者の所属は、取材当時のものです）

イベント登壇者と審査員たちによる記念写真

エンジニアが輝く場、エンジニアが刺激を受ける場

テクシェアは、SHIFTグループの従業員一人ひとりの技術やナレッジをグループ全体へとシェアするイベント。各自が信じる技術を発表する、エンジニアが輝く場です。

発表者の熱がグループ全体へ波及し、学習モチベーションや技術力の向上につながれば、という想いから開催されています。

今回は、さらに多くの方に、自分の信じる技術を共有してもらうために、各登壇者にメンターをつけたほか、発表後のオンライン交流会も設けるなど、コミュニケーションチャネルの拡充を試みました。

第6回テクシェアの登壇者は、以下です。

発表時間は、1人あたり20分間。発表内容を受けて、審査員が「最優秀Tech TOP賞（もっとも優れた発表者に贈られる賞）」の受賞者を決定します。

代表の丹下をはじめとするSHIFT役員陣も参加するほか、Sun Microsystems社在籍中にCIツールの草分けJenkinsを開発し、SHIFTでは技術顧問を務める川口 耕介氏や、DeMiA 代表取締役の坂本 京也、Airitech代表取締役の山﨑 政憲、SHIFT VPoEの池ノ上 倫士、アジャイル推進部 部長 秋葉 啓充が審査員を務めました。

技術者にとって、こうした技術のエキスパートからコメントやフィードバックをもらえる機会は貴重なもの。各登壇者が審査員から受けたコメントや質問の一部を、発表内容の概要とともにご紹介します。

発表①SHIFTのDNAとAIの融合：普及から活用へのパラダイムシフト（SHIFT 林 栄一）

生成AIが十分に普及し性能がよくなり、だれでも簡単にすばらしいアウトプットがだせるようになると、多様性がシュリンクし、画一的なアウトプットが生成されるのではという懸念もあります。

アウトプットの差別化がむずかしい時代において個性ある生成をうむには、どれだけよいプロンプトを入力できるかが重要で、「よいプロンプト＝各人のもつ経験と学習がもとになる」と林は語ります。

「AIの性能が及ばない現状では、『いかに意図どおり動かすか』が重要ですが、今後のAIの活用フェーズでは、意図どおりに十分動くようになるので、『いかに適切かつ有用で意義のある意図をもち、それをAIに伝えるか』ということのほうが重要になってきます。

AIは暗黙知をもちませんから。製造業を発端にIT業界、ソフトウェアテストにおける暗黙知を形式知にしてきたSHIFTだからこそ、生成AI活用をリードする企業になるでしょう」と林は力強く説きました。

＜審査員からの質問＞

丹下：AIがコモディティ化したあと独自性をもつようになっていくのは、いまのSNSとよく似ている流れだと思います。マジョリティになれるAIやその派生となるAIはありますか？

林：AIをサービスとしてとらえた場合、経営者は「マジョリティになるかどうか」が気になるかもしれませんね。

サービスの便利さという指標はコモディティ化によって横並びになり、価値がなくなるでしょう。私は、「AIは透明化していく」と思います。

さまざまなサービスに、これから溶け込んでいくんです。「SHIFTは何か違うな」と思わせる、便利さだけでない質を出せれば、独自性という価値を担保できると考えています。

細田：仕事には、標準化が必要なものと独自性が求められるものの2種類がありますよね。それと同様に、AIも二分化されるのではないでしょうか？林さんの見解を聞きたいです。

林：たしかに、社内用のAIであれば標準化して業務の再現性を高めることが重要です。メンバーの多様性が、標準化すべき方式についてイノベーションを起こす重要なファクターになります。

一方で、社外に向けたサービスは、市場か全体からみた多様性を活かした状態、つまり企業単体視点では、独自性が商品価値になる重要な要素になると考えられます。

「SHIFTでなければ」という理由づけ＝魅力が単なる性能や便利さを超えた人の意図が反映されることが必要だと思っています。

発表②Viteの魅力とビルドプロセスに迫る（クロノス 錦織 拓人）

JavaScriptのフレームワークの1つ「Vue.js」をこよなく愛する錦織。その熱量は、Vue.jsのカンファレンスに対して個人出資して有識者に話を聞きに行くほど。

Vue.jsがさまざまなシステムで使われていることもあり、6年間多様な案件に関わってきたといいます。

そんな錦織でも、Vue.jsの2系の小規模システムを3系へ1人で移行した際、楽しさの反面苦労を感じました。その際に活用したのが、フロントエンドツール「Vite」です。

Vue.jsでの開発がより効率的になったと顔をほころばせる錦織。

そもそも、Viteは「フロントエンドのビルドプロセスを超高速化することで、快適な開発体験を提供する」という技術者ファーストの目線で設計されたものです。

これまでメインで使われていたWebpackとViteには、どのような違いがあるのでしょうか。

発表では、デモ環境でViteを実際に使い、その利便性をアピールしました。

＜審査員からの質問＞

秋葉：エンジニア目線に立ったすばらしい発表でした。ビジネスの視点では、リファクタリングの必要性が認識されづらい側面があります。

Viteの高速起動などは、リファクタリングのときなどに真価を発揮しそうですね。リファクタリングの経験はありますか？

錦織：リファクタリングの経験はありません。技術的負債を解消する方法の1つとして、いかにビジネスサイドに提案するか重要だと思います。

池ノ上：私は日常的にViteにあまりふれないので、新鮮な気持ちで聞いていました。

Viteはすでに流行っている技術ですか？それとも、これから流行る技術ですか？これから流行るとしたら、きっかけには何があると思いますか。

錦織：Viteは流行りつつある技術だと思います。

Vite開発者の発言によると、フロントエンドのライフサイクルをすべて見直していくという目論見もあるようなので、これからフロントエンド開発が変わっていくんだろうなと感じています。

坂本：小規模の開発ならVite、大規模ならWebpackという認識がありました。Viteの弱み、Webpackの強みはありますか？

錦織：開発環境のビルドのバンドルでいえば、Viteの弱点はあまり思いつきませんね。

ただ、プロダクションビルドに関してはまだ発展途上といえます。後者は、ESモジュールとViteを併用することになります。

発表③サイバー攻撃のシミュレーション：攻撃者の視点からみる防御のむずかしさ！AWSで試してみよう（SHIFT 辺見 久美子）

個人情報が売買される現代社会。辺見は、「良質な個人情報を得るために、攻撃者はさまざまな手法を用いてきます」と説明します。

代表的な攻撃手法が、攻撃対象が日常的にアクセスするWebサイトを改ざんし、閲覧するだけでマルウェアに感染させる攻撃です。

辺見は、攻撃者がどのような手順を経て企業・組織やエンドユーザーに攻撃を仕掛けるのか、実施に起こりえる攻撃の手法とその対策について解説しました。

＜審査員からの質問＞

山崎：Airitechはセキュリティは専門外ですが、生成AIに脆弱性を突かせるような攻撃性能も高まっているんだろうなと日々脅威を感じています。対策はむずかしいのでしょうか。

辺見：AIはすでに攻撃に使われていると思います。そして、攻撃者はわずかな脆弱性を見つけてしまえば攻撃できてしまう。現時点では、攻撃者に分があると思います。

坂本：興味深いプレゼンでした。攻撃手法を学んだエンジニアは、その学びを「守る」視点でどう仕事に活用しているのでしょうか。

辺見：攻撃手法を知ると、ログがどこに吐き出されるのか、リクエスト値はどう変化するのかなどがわかります。

防御の勘所がわかるようになるため、非常に意義があることだと思っています。

丹下：攻撃者がコストをかけてまで攻撃する意味を感じられないようにする、つまり攻撃しても個人情報を盗めないように「企業・組織が個人情報を保持しないようにする」という解決策もあるのかなと思いました。

セキュリティ担当者は、お客様にどのようなアドバイスをしていますか？

辺見：たしかに、「データベースやストレージに個人情報をもたせない」という観点から、Webアプリケーションを開発したことがありました。開発者からみても、有効な打ち手だと思います。

発表④教えます！AWSにおけるセキュリティ対策の可視化の方法やってみた！！AWSにおけるセキュリティ対策の可視化の実践（SHIFT 大瀧 広宣）

昨今、多くのAWS利用企業・組織は「普及期」から「成熟期」を迎えており、AWSの利用状況などを見直して最適化する機運が高まっています。

AWSでは、セキュリティ手法に合わせたサービスを展開しています。これから攻撃手法が増えれば、おのずとセキュリティサービスのラインナップも増えていくでしょう。

そして、セキュリティを徹底したい企業・組織は、AWSの多様なセキュリティサービスを導入しています。

そんななか、SHIFTには「AWSのセキュリティサービスを使いこなせているか自信がない」という相談が続々と寄せられているといいます。

発表では、大瀧がお客様に実際に提案している、AWSのセキュリティ対策状況を簡単に可視化する方法を説明しました。

74項目の質問に答えるAWSセキュリティ成熟度モデルを用いた診断結果や、セキュリティ改善のアプローチに、聴衆は熱心に聞き入っていました。

＜審査員からの質問＞

川口氏：これまでのセキュリティのビジネスモデルは、リスクアセスメントは無料で提供して、可視化されたリスク改善のためにサービスを購入してもらう、というものでしたよね。

SHIFTの場合はアセスメントに重きを置いているとのことですが、ローコストで簡単にアセスメントを行える方法を編み出したんですか？

大瀧：アセスメントを行う場合、セキュリティへの深い理解が求められます。そこで、セキュリティ担当者がアセスメントを伴走し、セキュリティを改善する。

その後、セキュア開発などお客様のシフトレフトの実現に貢献できればいいな、と考えています。

最優秀Tech TOP賞受賞者発表。丹下・川口氏の総評

厳正なる審査を経て、今回の最優秀Tech TOP賞は辺見が受賞。

その理由について、川口氏は「前回登壇時よりさらに成長を感じられ、辺見さんがセキュリティにかける情熱が伝わってきました。攻撃手法のデモンストレーションは、視聴者に大きなインパクトを与えられたと思います」と説明します。

登壇者全員の技術への向き合い方を賞賛する、代表丹下と技術顧問 川口氏の講評をご紹介します。

＜丹下の総評＞

SHIFTグループがもつ、『技術への熱量』を感じられるよい発表でした。

SHIFTはソフトウェアテストからはじまり、事業を徐々に拡大してきました。エンジニアが活躍できる場所を提供したいと思ってのことです。

昨今では、クラウドサービスをはじめ新しい技術が次々と世に出回っています。

そうした技術を使ってみなさんが自分の居場所を見つけ、いきいきと働いていることを誇りに思います。熱意をもつ方が多く入社してくれていることを改めて実感しました。

登壇された方の『お客様の役に立とう、社会をよくしよう』『SHIFTを日本一に押し上げよう』という気持ちがすべてのメンバーに伝播するテクシェアを、今後もつづけていきたいと思いました。

＜川口氏の総評＞

SHIFTは、各自が思い思いに技術を学んで、『これだ！』と思うものをもち帰り共有し、みんながその技術をとりに行く『アリ』のような側面があるなと感じています。集団としての結束力がありますよね。

これは、各自の興味が多様な分野に向いているからこそ可能となる組織文化です。そうした文脈で、今回のテクシェアではSHIFTが発展する理由を垣間見ることができました。

ナレッジを競争力に変えるSHIFTの文化

テクシェア終了後の4月25日、オンライン交流会が開かれました。当日の様子を簡単にお届けします。

交流会では、zoom内に林＆錦織、大瀧＆辺見の2つのブレイクアウトルームを設け、聴講者が各登壇者と直接コミュニケーションをとれるように工夫。聴講者は、登壇者に対して当日できなかった質問や意見をぶつけました。

どちらのブレイクアウトルームも大いに盛り上がり、登壇者がすすめた書籍に興味を示している人も多数見受けられました。

まとめ

徹底した業務分解と業務標準化により事業を拡大してきたSHIFTでは、ナレッジ共有の文化が根付いています。暗黙知を共有知にする意義を従業員全員が深く理解しているともいえるでしょう。

テクシェアが盛り上がる理由の1つは、こうした下地がすでにできあがっているから。そして、テクシェアで学んだことはお客様、ひいては日本社会に還元されていきます。

今後ますます盛り上がるであろうSHIFTのテクシェア。読者のみなさんも入社後はぜひ参加を！

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

お客様と共に汗をかく“真のDXパートナー”をめざして

寅野：私は、新卒からIT業界で働いてきました。独立系SIer、コンサルティングファームを経て「お客様にもっと伴走したい」、「その傍らで技術を磨きたい」と考えるようになり、2021年8月にSHIFTへ入社。

現在はAWSのプロフェッショナルとして、アーキテクチャの検討からデリバリーまで一気通貫でお客様をご支援しています。

岡田：私は、新卒のときに大手の外資系ITベンダーに入社し、40年近くその会社に勤めていました。

定年退職を迎えたとき、前職でプライベートクラウドやオンプレミスにしかふれられなかったことから、パブリッククラウドにふれたいと強く思っていました。

SHIFTに入社してからは、すべてパブリッククラウドを扱う案件にアサインしてもらえたので、とても感謝しています。

寅野：IT業界に長く身を置いて思うことは、これまでのSIは「決まった仕様を納期通りにつくること」を最優先にしてきたということです。もちろん、それはそれで価値がありました。

ですがいまは、世の中の変化があまりにもはやい。案件立ち上げの際に決定した要件が、走り出したときにはすでに現場のニーズとズレているということが当たり前のように起きます。

そうなると、「変化が起こる前に決めた仕様書通りにつくりました」だけでは、お客様の本質的な課題解決にはならないですよね。

そのため私たちは、単なる受託ではなく“共創”の姿勢で、お客様といっしょに考え、いっしょに悩みながら、最適な答えを探っています。

こうした姿勢でお客様に関わる存在が、本当の意味での「DXパートナー」だと思っています。

プライムならではの対応力でお客様の目的を果たす

岡田：まさにその通りだと思いますし、それを実践できることがSHIFTで働く醍醐味ですよね。

私はいま、お客様と非常に密にディスカッションしながら進めていく案件に関わっています。プロジェクト開始当初は、要件も大まかなものしか決まっていませんでした。

だからこそ「真のDXパートナー」であるためには、「システムをうまくつくる方法」よりも「何をつくるべきか」を見極めることが求められています。

これを見極めるためには、お客様のビジネス要件や実現したいことを深く理解する必要があります。

そのうえで、最適なソリューションアーキテクチャを選択し、かつ、さまざまなアーキテクチャの選択肢のなかからそれを選んだ理由を論理的に説明し、お客様に納得していただいたうえで進めていく、という仕事の進め方が必要だと思います。

このようにお客様と直接話せるのは、プライムとして仕事を行うことができるからこそだと思います。

「何を、どのようにつくるか」はビジネス要件を基に私たち自身が整理する必要があるため、責任が問われるむずかしい仕事でもあるわけですが、やりがいも大きいです。

お客様と近い位置で働きたいという方に、SHIFTはマッチすると思います。

寅野：私も最近、「お客様の実現したいこと」を汲みとる重要性を感じたことがありました。

新規のプロジェクトに初期から関わったのですが、私が担当するインフラへの機能要件や業務要件が固まっていませんでした。しかし、リリースのスケジュールだけは決まっている。

私たちは、お客様が頭のなかで描いている“こうしたい”という思いを言語化し、そこに対して、インフラはもちろん担当領域ではないアプリケーションの側からも、お客様をどう支援できるかを1つずつ提案していく必要がありました。

合意形成を段階的に進めながら、「いつ何をするか」というロードマップを引いていく作業は、とてもチャレンジングでしたね。

お客様の要件に合わせて柔軟に対応できるのは、SHIFTがプライムとして案件に参画しているからだと思います。

岡田：お客様の要件は、プロジェクトが進むうちに変わるものですね。

そのため、私たちはつねにお客様とディスカッションしながらプロジェクトを推進していくわけですが、これはお客様の期待に応えながらSHIFTのビジネスを拡大する機会があることも意味しています。

それが我々の基本的なビジネスの進め方でもありますね。

柔軟性と対応力を高める「ナレッジベース」を充実させていく

寅野：こうした柔軟な対応力が必要だと聞くと、ベテランにしか務まらないのではと不安に思う方がいるかもしれませんね。たしかに、対応力は個人の経験や勘に依存してしまいがちです。

そこで、いま私たちはその属人的なノウハウを「共有知」にする仕組みをつくろうとしています。

具体的には、岡田さんといっしょに、現場で得た知見を「再現性のあるナレッジ」として整理し、それを社内で共有・再利用できるようにしていきます。

例えば「この要件だったら、こういう設計パターンがよくフィットする」とか「この規模なら、こういったレビュー体制が有効」といった実践的な知識です。

AIやツールなどを使いながらナレッジ整備していくことで、ほかのお客様の案件でも高い品質を維持できます。

岡田：ほかのSIerと同じことはしたくありません。いまは、お客様からの期待値がどんどん上がっているため、「ただつくるだけ」では競争力が上がらない、差別化できない時代ですよね。

お客様の要望は、“高い品質のものを、短い時間で、低コストで提供してほしい”というものですね。

そのために、現場で得たナレッジのエッセンスをドキュメント化したり、コードサンプルに落とし込んだりしています。この「ナレッジベース」には、すべてのSHIFTメンバーがアクセスできます。

SHIFTには多様な案件が舞い込みますが、ナレッジベースを基にインフラ設計を提案することを行っています。

寅野：「境界をつくって制限しない」という点では、ナレッジベースにもSHIFTらしさが出ているなと思います。

SHIFTはDXパートナーとして、幅広い技術を多様なお客様に提案しています。

それは、CI/CDやセキュリティ、AI、データ分析といった領域に深い知見をもつ社内の人材を組み合わせることで多岐にわたる案件に対応できるから。

さらに、品質保証のチームとも密に連携していて、プロダクトのリリース後まで一貫して伴走できる。こうした“エンドツーエンド”の体制が整っているのは、ほかのSIerにはなかなか真似できないSHIFTの強みだと思います。

岡田：「全部任せてください」と胸を張っていえる体制ですよね。実際に、お客様から「こんなに手厚く支援してくれると思わなかった」といわれたことがあります。

SHIFTは、“チームワークで価値を提供する”ことを大切にしているから、分野が違っても自然と助け合う文化がありますね。

それはグループ会社でもみられます。SHIFTグループ全体で価値提供することを指す「ONE-SHIFT」という言葉が体現されていると思います。SHIFTのチームワークを、ぜひ体感してほしいですね。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

「挑戦したい」気持ちをかなえるためにSHIFTへジョイン

――まずは、それぞれの経歴を教えてください。

U.T.：私は約10年間、電力業界からシステム運用管理サービスに携わってきました。主にインフラ関連の業務を担当し、運用から構築、お客様への提案まで一貫して行ってきました。

特に、数千規模の業務システムをAzure環境に移行するプロジェクトのリーダーを務めた経験があります。

お客様の基盤をオンプレ環境からクラウドのAzure環境に移行する際、プロジェクトリーダー（PL）としての立ち位置で携わり、移行手法を確立しました。

しかし、Azureの幅広い知識を深める必要性を感じ、さらなる技術向上をめざして転職活動をはじめました。

H.N.：私は新卒で地方公務員として働いていましたが、情報セキュリティ関連の部署に配属されたことがきっかけでIT業界に興味をもちました。大学では文系を専攻していたため、ITの知識はゼロからのスタートでした。

前職では主にオンプレミスの環境構築を行っていましたが、クラウド領域に挑戦したくてSHIFTに転職しました。

現在は公共系のアプリ開発案件の運用設計リーダーとして、AWSを使った環境の設計を担当しています。SHIFTに入社してからは、クラウドの案件に携わっています。

SHIFTでは、「発見」と「成長」の繰り返し

――SHIFTに入社して、どのようなスキルが身につきましたか。

U.T.：前職では特定のお客様との関係が長かったため、技術の幅が限定的でしたが、SHIFTに入社してからの3年間、多様なお客様と関わることで、さまざまな技術を学ぶことができました。

SHIFTでは、特にAzureに特化した案件を多く担当しています。入社当初は、Azureの知識を深めることが目的でしたが、実際にプロジェクトに参加することで、技術力が向上しているのを実感しています。

H.N.：私もU.T.さんと同様に、SHIFTでクラウドの案件に携わることができたことが大きな成長につながっています。

入社当初はクラウドの知識がゼロでしたが、勉強会を通じてクラウド技術の基礎を学び、実際の案件で経験を積むことができました。

――PMスキルについては、いかがでしょうか。

U.T.：それも向上したと思います。プロジェクトの上流工程から関わることが多いためです。視野が広がったとも思います。

「この技術がいまお客様から求められているんだ」「こんな困りごとを抱えているお客様が多いんだ」という発見に近いかもしれません。

H.N.：いままさに関わっている案件では、メンバーやスケジュールの管理など、プロジェクトマネジメントの要素を学べており、自信につながっています。

――H.N.さんにとって、クラウドはまったく未知の領域でしたよね。勉強会への参加以外で、どんな工夫をしてキャッチアップしていったんですか？

H.N.：インフラグループ内でのチャットを駆使して、先輩方に積極的に質問するようにしていました。

私たちのチームは、多様なインフラのプロフェッショナルがそろっていて、ときには直接話したことがない方からもアドバイスをいただきました。

――それは心強いですね。

新しい技術に挑戦できる下地が整っている

――SHIFTで働く魅力について、教えてください。

U.T.：先ほどもふれましたが、SHIFTの魅力は、何といっても多様な案件に関わることができる点です。面接時に聞いた「幅広いお客様とのおつきあいがある」という言葉が、実際に入社してみて本当に実感できています。

H.N.：私も同じく、SHIFTの環境は非常に魅力的だと感じています。勉強会については、エンジニアとしての入門となる資格試験をベースにしたものを週１回程度の頻度で開催していました。

勉強会に限った話ではありませんが、SHIFTは意思決定のスピードがはやいというか、「とりあえずやってみる」文化が根強いんですよね。だからこそ、私たちは新しい技術に挑戦しつづけることができるのです。

――これまで、直面した壁はありましたか？

H.N.：私が直面した壁は、はじめてPLとして大規模な案件に関わったときです。経験が少ないなかでの管理は大変でしたが、周囲のサポートを受けながら無事にプロジェクトを完了させることができました。

特に、上長やチームメンバーとのコミュニケーションが重要でした。助けを借りながら、問題を解決し、プロジェクトを成功に導くことができたのは大きな自信になりました。

U.T.：私も、ある省庁の要件定義書の更改案件で高い要求に直面しました。

レベルの高い指摘が多く、苦労しましたが、上長と相談しながら解決策をみつけることができました。この経験は、私にとって非常に貴重な学びとなりました。

―― H.N. さんも、現在は省庁の案件に携わっていると聞きました。

H.N.：はい。表現や進め方、セキュリティについては、細やかな気配りが求められるなと感じます。

一般企業とは異なる視点のレビューがくるというか。「やれる」と直感していた案件でも、さらなる研鑽が必要だと気づかされますね。

SHIFTは助け合いの精神が強いので、こうした壁に直面しても挑戦しつづけられます。これからも、さらなる成長をめざしていきたいと思います。

――プロジェクトの幅広さ、勉強会、部内の関係性などが、個人の成長を下支えしていることがよくわかりました！

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

※「AWSぶっちゃけ討論会」シリーズ初回の様子は以下。

※SHIFT EVOLVEとは？ 
SHIFTグループが主催する技術イベント。 エンジニアコミュニティから技術をEVOLVEしていこう、という想いで運営し、メンバー登録者数は3,700人を超える（2025年2月時点）。開催予定のイベントは以下よりチェック。
https://shiftevolve.connpass.com/

LT「AWSマルチアカウント統制環境のすゝめ」 

パネルディスカッションの前に、SHIFTのナショナルセキュリティ事業部でシニアコンサルタントとして、官公庁案件におけるガバメントクラウド移行支援などを担当している松尾が、「AWSマルチアカウント統制環境のすゝめ」というタイトルでLTを行いました。 

「AWS上のリソース管理をシングルアカウントで行うとき、例えば本番、ステージング、開発の全環境を1つのアカウントでまとめて統制・管理できますが、本番のリソースを誤って削除するなどのリスクがつきものです。
ですから基本的には、本番、ステージング、開発のそれぞれでアカウントをわけて、アカウント間でリソースを分離します。アカウント間でリソース共有が必要な場合は、IAMのスイッチロールでのクロスアカウントアクセスで必要最小限のアクセスにより実施します」 

その際に、AWSマルチアカウント統制環境を構築・管理するマネージドサービス「AWS Control Tower」が有用だと、松尾は説明します。 

一般的にリソース操作に対して、シングルアカウントは統制がかかりにくいものの自由度が高い反面、マルチアカウントは統制がかかるものの自由度は下がります。

そこで、例えば複数のAWSアカウントの一元管理ができる「AWS Organizations」にてコントロール（旧ガードレール）を適用しない組織単位（OU）を作成し、ここに本来シングルアカウントで管理したいAWSアカウントを登録します。

「これによって、ほかのOUによるガードレール設定を継承せず、個々のシングルアカウント内でService Control Policy（SCP）、Config Rulesなどの設定を完結できます。つまり、AWSのマルチアカウント統制環境内で、シングルアカウントライクに管理できるようになります」 

詳細は以下の記事をご覧ください。 
AWSマルチアカウント統制環境の構築（AWS Control Tower シリーズ vol.1）

また、SHIFTのAWS CCoEチームの取り組みについては、SHIFT Group技術ブログ「AWS CCoE Blog」もあわせてご覧ください。 
SHIFT Group技術ブログ「AWS CCoE Blog」

パネルディスカッション「インシデント対応の最適解ってなんだろう」 

ここからは、登壇者3名によるパネルディスカッションの様子を、特に印象的なポイントをピックアップする形でお伝えします。 

テーマ：障害訓練の具体的な取り組み方 

土佐：障害訓練は2019年から毎年10月にやっています。きっかけは2018年10月末に発生した大障害で、2時間半ぐらい全サービスを止めてしまう事象が発生しました。

その反省をもとに、さまざまなリスク管理や障害発生時の初動対応を整備していったのですが、そのなかで「障害訓練もやらなくては」と。

「障害訓練月間」とした10月には、毎年大小さまざまな規模の訓練を行い、社内でムーブメントをつくっていきました。 

大瀧：具体的にはどのような障害訓練を行っているんですか？ 

土佐：リアリティをもってやろうということで、訓練専用の環境を用意して攻撃を受けたログを仕込み、障害対応するメンバーが攻撃を検知できるか試しています。

訓練内容も、対応するメンバーも伏せています。運営メンバーは毎年違いますが、2024年にはCISOとCIOを中心に、セキュリティのメンバー数人と広報が訓練を設計しました。

実践してみると想定どおり進まない場面もあり、気づきが多いですね。 

草間：きちんと実践できていることが本当にすごいですよね。もちろん、本には具体的な訓練方法は書いてあるのですが、実行できるかは別問題です。障害訓練をトップの方が大切なことだと認識しているからこそだなと。 

テーマ：大規模インシデント発生時のメディア対応 

大瀧：大規模インシデントが発生した時のメディア対応については、いかがですか？ 

草間：インシデント発生時は、シングルソース・オブ・トゥルース（SSOT）が大切です。つまり、情報を集約・コントロールすること。

情報を集約・意思決定するためのウォールームを物理的に設置する、ZoomやTeamsなどで窓を立ち上げるなどの対応策が考えられます。

そこでは、インシデントコマンダー（インシデントの解決に必要な意思決定を行う責任をもつ人）や、あるいはインシデントコマンダーから委任された広報官などが、統一された情報を発表します。 

土佐：当社でも、障害対応を優先的に話し合う会議室を設けています。また、障害発生時の報告用テンプレートをつくったり、フローを整備したりしています。

ちなみに、メディア対応に関しては広報が専任で担当しています。障害訓練にも、基本的には広報を巻き込んでいますね。 

テーマ：インシデントコマンダーの決め方 

草間：もともとインシデントコマンダーは、アメリカの消防現場から生まれた概念です。そのため、基本的には、障害に最初に対応する人が第一のインシデントコマンダーになります。

ただ、より被害が広範になったり高度になったりすると、より上位の人にインシデントコマンドが委譲されます。 

土佐： インシデントコマンダーは、紆余曲折を経てかなり成熟した状態で運用できていて、基本的にはエンジニアチームのメンバーからタスクフォース的に集まる「委員会制」です。

月曜日から金曜日まで当番を決めていて、その当番の人が初動をとにかくやると。障害速報が上がったら、事前に決めた当番が現場にいちはやく駆けつけて対応します。

委員会の人たちは一定の経験を積んでいるので、初動対応や情報整理、障害のレベル判定もできます。

加えて、委員会ではメンバーを半年に1回の頻度で入れ替える「任期制」を採用しています。ただし、リーダーは変えません。

リーダーの役割はそれほど多くはなく、当番にもなりません。障害対応の経験はエンジニアがキャリアを積むうえでプラスに働きますし、ほかのプロダクトのことを知る機会にもなりますよね。

草間：任期制、すごくいいですね。自分がエンジニアとして一番成長したのは、やっぱり障害対応しているときなんですよね。

全力で頭を使うし、すべての知識と経験を総動員して対応していくので、エンジニアとしてワンランクアップしたという感覚がすごくあるんですよ。

インシデントコマンダーに向いている人の特徴をよく聞かれるんですが、何か特定の技術のプロフェッショナルである必要はないんですね。

それよりも、インシデントが発生したときに権威をもって対応できる人だとか、システム間の関連あるいは組織間の関連がわかっていて、適切な人にアプローチできる人が向いているといわれます。

任期制だと、多数の人が経験を積めますよね。

土佐：実は最初は任期制ではなかったのですが、経験豊富な人がつねに対応している現状を改善するためにはじめました。 

テーマ：おすすめの監視方法、AIによる検知・対応

土佐：当社はDatadogを主に使っていて、リソース監視のアラートやログ監視からのアラートを見ていますね。ログに関しては、CSIRTやPSIRTが整備を進めてくれています。

あとは、ログをできる限り一箇所に集めてAWS SIEMなどを使って横断的に見られるように、日々PSIFTチームが努力してくれていますね。 

大瀧：freeeさんの技術ブログを拝見していると、トリアージの整備やレッドチームの配置など、多様な取り組みがありますよね。 

土佐：トリアージでは障害レベルを定義していて、レベルに応じて巻き込みの範囲や振り返りの方法などが決められています。工数を削減するためです。

また、PSIRTのなかにレッドチームとブルーチームを設けて役割分担をしています。例えば、以前外注していた脆弱性診断などはレッドチームで対応しています。 

大瀧：全社的なアセスメントなども社内で対応しているのですか？ 

土佐：そのとおりです。業界標準的な指標で見たときの脆弱性をプロダクト別に色分けし、対応しているポイントは経営陣に対して4半期に1回の頻度で報告しています。 

大瀧：ちなみに、最近話題のAIについて、インシデントの兆候を掴むために活用していますか？ 

草間：AIと一言でいっても、生成AIや機械学習などがありますよね。例えば、アノマリーディテクションは大量のデータを機械学習させておいて、何か異常があったときにアラートを上げさせるなどの形で広く使われています。 

また、生成AIも多様な使い方があると思っていて、例えばコミュニケーションツールのやりとりを生成AIがつねに学習していれば、インシデント対応時の状況をチャットベースで確認できますよね。

そうすれば、現場対応している人が都度工数を割いて状況報告をしなくても済みます。 

特に、今年はAIエージェントが高度化するといわれています。問題を切り分け、かつ必要なところに連絡するAIエージェントが出てくるのではないでしょうか。 

大瀧：インシデント対応へのAI活用の動向を、今後も探っていきたいですね。 

パネルディスカッションのほかのパートや全編をご覧になりたい方はこちら 

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。

※本記事の内容および取材対象者の所属は、イベント開催当時のものです

SIerから事業会社の“ひとり情シス”へ。手を動かし、できることを増やしてきた

──まず、これまでのプロフィールについてお聞かせください。 

西川：大学卒業後は中小のSIerに就職。入社してしばらくはカスタマーサポートを担当していました。

お客様の質問にただ回答するだけでなく、企業や店舗などにおもむいて機器のセッティングや故障対応まで行う、広範囲な業務。現職とはだいぶ違うポジションからキャリアをスタートしました。 

その後、異動して、大手企業のインフラの基本設計から構築、運用、保守を担うように。激務でしたが、いまに活きる技術をたくさん身につけることができました。 

視点を変えたい、と２社目は大手メーカー系のSIerへ。ネットワーク系のほか、電話交換機のようなアナログ案件など幅広い業務を経験したものの、想像以上にお客様への提案が通らなくて、もどかしい思いもたびたび。 

ある日、事業会社に勤める友人に「提案をする側より、される側になりたい」と漏らしたんです。

そうしたら、「じゃあ、うちの部署に欠員が出るけど、くる？」。これは渡りに船、と転職することにしました。 

──事業会社ということは……それから情報システム部門（以下、情シス）のキャリアを？ 

西川：はい。はじめは自社サービスを担当していたのですが、徐々に情シスの業務も並行するようになりまして。 

この会社が展開していたサービスはBtoB、BtoC両方をカバーしていて、システムは24時間365日稼働。

その運用だけでもなかなかハードだったんですが、一方で情シスの仕事の面白さにも気づき、どんどんのめり込んでいきました。 

4社目も事業会社です。自社サービスの運用と“ひとり情シス”を兼務でこなすのは以前と同様でしたが、オンプレミスからクラウドへの移行や事務所移転など、次々と大きな仕事を任され、充実した日々を送っていました。 

──なのに、転職を決意した理由は？ 

西川：もともとは業績がよく、成長性の高い企業だったのですが、ある出来事をきっかけに、株価が暴落。業績悪化し、従業員がどんどん辞めていきました。

当然、情シスの予算も大幅に削減。「これ以上、自分ができることはない」と悟り、転職先を探すことにしたんです。 

スピード内定で「決断がはやい会社」と確信。面白そうな取り組みも入社の動機に

──あらためて、SHIFTに入社した決め手を教えてください。 

西川：まず、選考がずば抜けてはやかったこと。他社は内定まで4～6回の面接を要しましたが、SHIFTはたったの2回。

これまでの経験から「大企業は動きが遅い」という認識でしたが、グループ従業員1万人クラスの会社で、このスピード感……とても魅力に映りましたね。

同時に「何事においても、決断がはやい会社なのでは」という期待が一気に膨らみました。 

2つ目は、経験が活かせそうだと思ったから。面接時に、VPNの切り替えや新規拠点の立ち上げ、オフィスの移転を予定していると聞き、胸が躍りました。

すべて経験している仕事でしたし、何よりも面白そうだな、と。特にVPNの切り替えは前職で頓挫してしまったこともあって、「今度こそやり遂げたい」と強く思いました。 

──では、いまはVPN切り替えのプロジェクトを？ 

西川：はい、晴れて担当になれました（笑）。VPNのソフトをつなげるOA機器が老朽化しつつあるため、その切り替えに取り組んでいます。

部署にもよりますが、SHIFTはリモートワークが基本。VPNのパフォーマンスや保守性の向上はとても重要だと考えています。来期中のリリースが目標です。 

そのほか、保守切れしているオンプレミスサーバーのリプレイスや社内監視カメラの管理見直しなどを任されています。

そのほかにも、各部署の部長やメンバーが直接相談にきて、突発案件が入ることも日常茶飯事です。 

はじめから完璧を求められない。だからこそ想像力や発想力、冒険心が宿る 

──かなりお忙しそうですが、入社後のギャップはありましたか？ 

西川：正直なところ、ほぼありませんでした。グループ長の中澤からいわれた通りすぎて、逆に驚いているくらいです（笑）。

もともとルーティンワークよりも不意の対応が好きなタイプ。他部署から相談がくると「よしきた！」と気合いが入ります。 

採用時に感じたスピード感も予想どおりでした。例えば、オフィスの移転。通常かかる時間の1／4ぐらいで完了させました。

正直いってかなり苦しいスケジュールですが、気負うことなく仕事ができているのは、完璧を求められていないから。 

SHIFTは急成長企業のため、変化しつづけています。途中で方向転換することは珍しくありません。「つくり直すぐらいなら、まずは60％のものをつくろう」というのが私たちの定石です。

メンバー側としてはアップデートが前提のリリースなので「失敗を恐れずに前へ進んでもいいんだ」と少し気楽に構えられます。 

──そのほか、インフラ運用グループで働く醍醐味は何でしょう？ 

西川：SHIFTグループ1万人超のユーザーに対して「できること」を自らで考え、行動に移せることですね。 

対象の人数が多ければ多いほど、つくるシステムの難易度は高いですし、影響度も大きくなります。

こうした壮大な試みについて、誰かが決めたことをただやるのではなく、「具体はメンバーに委ねる」のがこの会社のカルチャー。

個人的には、想像力を働かせながら、これから起こりえることを予測し、プランを組み立てていくプロセスが一番楽しいです。 

当然、神経を使う場面もあります。だからこそ新たなシステムを導入し、しっかり動いたときの達成感、従業員に喜ばれたときの充足感は、何物にも代えがたいですね。

コミュニケーションを大切にすれば、仕事はもっと楽しくなる

──西川さんが仕事で心がけていることは？ 

西川：とにかく、コミュニケーションを大切にしていますね。仕事の半分を占めるのが、社内メンバー、協力会社といったステークホルダーとのコミュニケーション。

特に「こちらからいいっぱなしにしない」「相手を敬う」の2点はいつも意識していることです。 

ここまで、仕事で楽しいと思える瞬間をいくつかお話しましたが、もうひとつ。相手と会話のキャッチボールがスムーズにできていると、充実感を覚えます。

やりとりのなかで双方に納得感が醸成されれば、お互い気持ちよく仕事に取り組めるので。 

──そういえば先ほど「各部署の部長からも直接相談される」とおっしゃっていましたが、それもコミュニケーションを重視しているから？ 

西川：そうですね、普段からグループの一次受け的な存在になろうと努めています。例えば、オフィスに出勤するときは、できるだけ多くのメンバーと話して、自分を知ってもらうように。

人間関係を広げれば広げるほどぞくぞくと相談が寄せられるので、大変は大変なんですが、結果的に自分が楽しめる仕事も見つかる。そう思ってやっています。 

大規模なシステムを少人数、短納期でつくりあげる経験は、間違いなくキャリアの強みに

──最後に、採用候補者に向けてメッセージをお願いします。 

西川：SHIFTのような大企業でシステム構築や運用を経験すれば、間違いなく今後のキャリアにおいて強みになるということです。

代表の丹下はつねづね「うちの会社を大企業というな」といっていますが、従業員数としては同等なので。 

さらにいうと、規模に対して、私たちの部署が少人数・プロジェクトが短納期という難題にも向きあえる。

一つひとつ乗り越えるたびにスキルアップしていき、未来の可能性をぐんぐん広げていけることでしょう。「やりたい」と手をあげれば、実現しやすいカルチャーもあります。 

私の話に少しでも共感いただけた方、ぜひ門を叩いてみてください。 

──西川さん、本日はありがとうございました！  

（※本記事の内容および取材対象者の所属は、取材当時のものです） 

自ら策定したグランドデザイン。すべての核は“統合プラットフォーム”

──はじめに、基幹システム推進・統合グループの業務内容について教えてください。 

大網：SHIFTの基幹システムの企画・導入・初期運用・改善を行うグループです。正社員のメンバーは6人で、SaaS担当、スクラッチ開発担当、統合プラットフォーム担当、SRE担当にわかれて仕事を行っています。

また、フロント部門やグループ会社のエンジニアにも協力してもらうことも多く、現在は20人程参画してもらっています。 

──領域のひとつとして“統合プラットフォーム”を掲げているのが特徴的ですね。 

大網：2015年に入社してすぐにグランドデザインを描いたとき、中枢に置いたのが「ベスト・オブ・ブリード」の考え方でした。

数あるSaaSとスクラッチ開発という選択肢からベストなシステムを導入し、それらを統合プラットフォームで連携することで全体最適を実現するモデルです。 

当時からSHIFTは成長しつづけている会社でしたし、「SHIFTらしさ」と呼ばれている他社とは差別化された業務要件も存在し、改善されつづける文化がありました。

それを考慮すると、必然的に「ベスト・オブ・ブリード」のような柔軟性の高い考え方が必要と判断しました。 

──これまで、どのようなプロセスで、自ら描いたグランドデザインに近づけてきましたか？ 

大網：まずは、各業務領域で利用する業務システムについてベストなソリューションへと刷新・導入することを進めました。

具体的には、SFAや販売管理からはじまり、会計・原価計算、プロジェクト管理、稟議、経費精算などに関するものを順次導入しました。 

また、それと並行して、全体最適を実現するために必要な統合プラットフォームについても少しずつ整備を進めました。

具体的には、統合認証、ETL、DWH、BIツール、iPaaSなどを順次導入しました。当初描いたグランドデザインを実現するために必要な要素はある程度揃ってきています。

ですが、現在も業務システムの改善やリプレイスなども進めていますし、統合プラットフォームの活用した全体最適への施策も並行して進めているので、やることは多くあります。 

使ってもらわなければ意味がない。「ベスト・オブ・ブリード」を体現した“契約書管理DX”

──これまで、たくさんの開発をリードされてきたと思いますが、なかでも特に印象に残っているプロジェクトは何ですか？ 

大網：たくさんあるのでひとつに絞るのはむずかしいですね（笑）。最新のものでいうと、契約書管理DXでしょうか。 

契約を締結するまでには、契約内容の確認、契約書のドラフト作成、自社での法務チェック、相手側の法務チェック、両者の押印……と、数多くのステップで数多くの担当者が関わっています。

やりとりに使うツールも、メール、チャット、電子稟議や電子サインなどさまざまです。 

こうした煩雑な作業を一元管理する契約書ライフサイクル管理（CLM）というサービスがあり、それを導入することを企画しました。 

CLMサービスをベースにしつつ、既存の稟議システムを組みあわせることで業務がシームレスに流れるようにし、締結後の契約書は自動でSalesforceに連携し必要なときに契約書を閲覧できる環境を提供することで、相乗効果を実現しました。 

契約管理の中心となる法務担当にとってベストなソリューションが、契約に関わるほかのユーザーにとってベストとは限らないので、各ユーザーのユースケースにあわせてベストなソリューションと組みあわせたところがポイントです。 

単体のシステム導入だけでは得られないような効果をもたらすには、「ベスト・オブ・ブリード」の考え方で全体最適を実現する必要があります。

契約書管理DXは、全体最適の実現に統合プラットフォームを活かした事例となっています。 

参考記事：ベスト・オブ・ブリードで実現したSHIFTにおける契約書管理DX 

──ものづくりにおいて、大網さんが普段意識していることは何ですか？ 

大網：ユーザーが使いやすいシステムをつくることですね。触れられることでシステムの価値を実感してもらえるし、より長く使ってもらうことで、その価値はさらに上昇していくものだと捉えているので。 

1年かけて完璧なシステムをつくったとしてもその1年間は誰にも使われないので提供価値はゼロです。出せる効果は小さくてもはやく使ってもらえるようにすることを重視しています。

コアな部分からリリースすることで、ユーザーからも具体的な要件を集めやすいですし、はやくいいシステムができると考えています。

スモールスタート＆アジャイルというスタイルがよいのではないかと考えています。 

求められる自主性にどう応えていくかが、活躍できるカギ

──基幹システム推進・統合グループでは、どんなマインドやスキルをもった方が活躍できると思いますか？ 

大網：うーん。とてもむずかしい質問ですね。長く採用活動にはかかわっているものの、どう伝えたら求めている人が応えてくれるのか、未だにわからないんです。

経験やスキルはあるに越したことはないんですが、それがあるからといって活躍できるとは限らない。 

ただ、ひとつ断言できるのは、すばらしい企画書や計画書、提案書はつくれても、実現に向けて動けない人は評価されない会社だということ。これは私自身が身をもって知ったことです。 

入社して2ヶ月たったころ、自ら描いたグランドデザインをもって、意気揚々と代表の丹下に提案しにいきました。しかし手応えはゼロ。

いま振り返ると、実際に提供される効果や価値を具体的に見せられていなかったからだと理解していますが、当時は「このまま進めていいのかな？」と不安になりました（笑）。

不安はありながら、そのグランドデザインの実現に向けて、個々の施策を関係者と合意をとりながら進めて行きました。

その後、システムをリリースし運用改善を進め、具体的な価値が提供されていくと、ユーザーや経営層からの評価としてフィードバックされるというのがSHIFTにあった進め方だったのです。 

こういったスタイルにアジャストできる方が活躍できると思います。 

──SHIFTでは自主的に動くことを歓迎されるんですね。 

大網：そうなんです。どんどん自分で進めていくことが歓迎されます。誤解がないように補足しますが、事前に提案をし、予算を確保し、稟議が承認されないとシステム導入は進められません。

必要に応じてPoCしたり、スモールスタートするといった感じで目指すゴールに向けて進めていくイメージです。

事前に要件を明確にし、プロジェクト計画や体制など合意を取ってから進めるという過去の習慣から抜け出せたから、いまやりたいことに全力投球できています。

成功だけでなく、失敗も山ほど経験しましたが、あらゆる体験が自己成長につながっているように感じます。 

うちのメンバーにもつねづね「何事も尻込みせず、自分でどんどん進めてほしい」と伝えています。

予算とか人手が足りないといって、足が止まっちゃう人はうちのグループではちょっと厳しいでしょうね。 

情熱をぶつけられる、やりがいのある場所。情シスという名で食わず嫌いせず、門を叩いてほしい

──当初のグランドデザイン実現に向けて必要な要素が揃ってきているとのこと。グループ長として今後目指していきたい方向性について教えてください。 

大網：今後は、SHIFTならではの価値づくりに挑戦していきたいと考えています。 

SHIFTでは全従業員が毎日勤怠・工数登録しているのですが、オフィス入退室時の顔認証のログや、社内ネットワークへの接続ログなどを組みあわせたり、さらには別で取得管理しているストレスチェックや従業員満足度調査の結果との関連を見て、健康経営や働き方改革へのヒントが見つかるかもしれない。

これはほんの一例ですが、いずれにせよ、従業員のため、会社のためになるようなデータの利活用を進めていきたいです。 

──最後に、採用候補者の方にメッセージをお願いします。 

大網：いち企業の情報システム部門としては、非常にやりがいや面白さのあるポジションです。 

私自身、「与えられたものをただこなすのではなく、自ら考え、課題を見つけて自由度高く動けそうな点」に魅力を感じ、8年前、SHIFTに入社しました。

従業員が300人だったあのころも、単体7,000人超（※2024年5月末時点）の大企業に成長したいまも変わらない、ベンチャー気質が社内にみなぎっています。 

私たちの業務課題が発端となって、情シス向けの自社サービスがリリースされた例も複数あります。

「自分の手で、世の中にないサービスをつくるんだ！」というような熱い思いをもった方は、情シスという名前で食わず嫌いせず、ぜひご応募ください！ 

──大網さん、本日はありがとうございました！  

（※本記事の内容および取材対象者の所属は、取材当時のものです）