なぜ危機感は伝わらないのか？現場と経営層の「すれ違い」

吉川：私たちCSIRTの現場は、日々のシステム監視やリスク分析、そして発生したインシデントへの対応に忙殺されています。

サイバー攻撃は分単位で巧妙化しており、現場はつねに「いまそこにある危機」を感じているんです。 

ですが、現場が「新しいセキュリティツールを導入したい」と提案しても、なかなか承認してもらえない。

いわば、現場は「火事だ！」と技術的な悲鳴を上げているような状態ですが、経営層は「それでビジネスへの影響は？」と「経営判断に必要な材料」を求めている。この温度差が大きい印象を受けます。 

現場が出すレポートには「インシデント件数の推移」や「攻撃の検知数」などの精緻なデータが並びます。ですが、経営層からすると「結局、何がいいたいの？」「データばかりで見る気が起きない」となってしまう。

これは経営層の理解不足というより、私たちが渡している判断材料が、彼らの求めている形になっていないことが原因なんです。 

一番怖いのは、こうして話が噛みあわないことで意思決定が遅れることです。セキュリティにおいて現状維持は後退を意味します。結果としてリスクが拡大し、企業価値を損なうことになりかねない。

この「意思決定のボトルネック」をどう解消するかが、いまの大きな課題なんです。

データは足りている。通じないのは「言語」が違うから

渕上：私がデザインの視点からお伝えしたいのは、「問題はデータ不足ではない」ということです。両者の話が通じない、その原因はエンジニアと経営層の「言語」が違うことにあると考えています。 

エンジニアは詳細や原因を追求する「技術言語」で語ります。一方で経営層が使うのは「経営言語」です。「サービスは止まるのか」「投資対効果はあるのか」という、リスクや事業への影響、大局的な状態を知りたがります。 

同じデータを見ていても、エンジニアは「修理箇所」を探し、経営層は「事業の健康状態」を知ろうとしている。この深い断絶がある限り、どんなに精密なレポートを出しても伝わりません。 

そこで「情報デザイン」の出番です。ただし、ここでいうデザインとは、単に見栄えをよくする装飾のことではありません。

技術言語と経営言語の間にある意味を正確に伝えるための「翻訳機」をつくること。つまり、「情報デザイン」の本質的な役割です。 

私たちがめざす「情報デザイン」は、意思決定の速度を最大化するものです。エンジニアにはエンジニアの思考プロセスに沿った「思考のゴールデンパス」を、経営層にはビジネス判断を助ける「決断のコンパス」を提供する。

相手にあわせてインターフェースを変えることで、情報の受け取り方は劇的に変わります。 

吉川：「翻訳」して相手に届けることができれば、「火事だ！」「影響は？」という不毛なやり取りもなくなりますからね。

0.1秒で直感に訴える「天候メタファー」という解決策

渕上：では実際にモニタリングダッシュボードのデザイン例をご紹介します。経営層向けの翻訳で私たちがたどり着いた答えが、「天候」というメタファー（比喩）です。 

経営層の方々は非常に多忙で、細かいログを読む時間はありません。彼らが必要としているのは、詳細な分析データではなく「いまは安心してもいいのか、それとも何かアクションが必要なのか」という直感的な判断材料です。 

そこで私たちがたどり着いた答えが「天候」でした。

システムのセキュリティ状態を晴れ、曇り、雨で表せば、ITの知識がなくても、誰もが直感的に「よい状態」か「悪い状態」かを感じ取れます。この「共通言語化」をデザインの起点にしました。 

実際に私たちが開発したダッシュボードには、美しい富士山の写真が使われています。システムが順調な時は「快晴」で、青空に富士山がくっきり見えます。これなら一目で安心できますよね。 

何かしらの予兆がある時は「曇り」になり、雲がかかって富士山が見えにくくなる。そして異常事態の時は「雨・嵐」になり、視界が真っ暗で何も見えなくなります。

経営層の方々は、普段は「快晴」の画面を見て安心している。でもある日、ふと見たら「曇り」や「嵐」になっている。そのとき、強烈な「違和感」を感じますよね。 

データを読んで頭で考えるのではなく、0.1秒で「感じる」レベルまで情報を昇華させる。そうすることで、「これは報告を聞かなきゃいけないな」「判断が必要だな」と即座にスイッチが入るんです。

これこそが、意思決定のスピードを上げるためにSHIFTが考えた情報デザインの答えでした。

エンジニア×デザイナーの共創が、組織の意思決定を加速させる

吉川：このダッシュボードを見て気づいたのは、エンジニアだけでは「富士山」という発想は出てこないし、デザイナーだけでは「どのデータが嵐に相当するか」というロジックは組めないということです。 

渕上：そうですね、実現には三種類の人材が必要です。一つ目は、膨大なデータから意味のあるパターンを見つけ出す「セキュリティの専門家（ドメイン知識）」。

二つ目は、人と情報の関係性を設計する「コミュニケーションデザイナー」。 

そして三つ目は、それを直感的なビジュアルに落とし込み実装する「UI/UXデザイナーとエンジニア」です。 

吉川：分析から実装まで、一気通貫で連携しないといけないんですね。 

渕上：デザインには「面白そうだな」と興味を惹きつけ、相手の意識を向けさせる力があります。これを「武器」として活用しない手はありません。 

吉川：セキュリティのような堅い分野こそ、そういった「引き」をつくるデザインの力が重要だと痛感しました。 

渕上：SHIFTには、吉川さんのようなセキュリティのプロもいれば、私のようなデザイナーもいます。この両者が社内で連携しているからこそ、単なる見た目の改善ではなく、本質的な課題解決ができるんだと思います。 

吉川：「翻訳機」としてのツールをつくり、組織の意思決定を加速させる。それが私たちの提供できる価値ですね。 

渕上：データをただ並べるのではなく、相手の言語にあわせて「翻訳」する。そして、0.1秒で伝わる情報デザインを取り入れる。これが経営層を動かし、組織をサイバー攻撃の脅威から守るための新たな鍵です。 

吉川：現場のエンジニアとデザイナーが手を組むことで、日本のセキュリティはもっと強くなれるはずです。本日はありがとうございました。 

渕上：ありがとうございました！

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

防御から「検知・復旧」へ。なぜ「守り方」の基準が変わったのか？

令和5年度から、防衛省は新たな「防衛産業サイバーセキュリティ基準」を施行しました。 

これまで採用されていた旧基準は、一般的に知られるISMS（情報セキュリティマネジメントシステム）をベースにしていました。

しかし、新基準では米国の国立標準技術研究所（NIST）が定める「NIST SP 800-171」がベースとなっています。 

最大の違いは、「守り方」の哲学です。

これまでの基準は「事前の防御」に重きを置いていました。しかし、高度化するサイバー攻撃を前に、事前対策だけでは現実的に困難になっています。

そこで新基準では、防御に加え、「侵入されることを前提とした検知」および「事後の対応・復旧」が強く求められるようになりました。

つまり、仮に情報漏洩などのインシデントが発生した場合、企業は「24時間以内に報告し、迅速に復旧に着手する」といった具体的な時間制限つきの対応能力をもつ必要があります。

単にウイルス対策ソフトなどで事前対策することに加え、「何が起きたか即座に検知し、迅速に被害を抑え、復旧させる能力」も、いまの防衛産業に求められているのです。

バラバラな情報を集めると「機密」になる？CUI保護の重要性

では、これほど厳重に守るべき情報とは何でしょうか。それは「CUI（Controlled Unclassified Information：非機密情報のなかでも重要な情報）」と呼ばれるものです。 

情報の格づけには、誰でも閲覧できる「非機密情報」と、国家の安全に関わる「機密情報」があります。CUIはその中間に位置し、単体では機密でなくとも、集約されることで機密情報と同等の価値をもちうる情報を指します。

NIST SP 800-171は、このCUIを適切に保護するための管理策を定めており、これを満たすことが、国の安全を守るための最低ラインとなっているのです。

防衛案件で求められる、妥協なき文書管理と組織統制

防衛省の案件に参画する企業は、膨大な規則を整理しなければなりません。具体的には以下の文書整備が求められます。 

情報セキュリティ三文書： 

1. 基本方針：セキュリティに対する基本的な考え方 

2. 規則：組織の管理策としての教育、情報の取り扱い体制など 

3. 実施手順：具体的なシステムのポリシーやコンセプト。SSP（※）を含む。 

※SSP（System Security Plan：システムセキュリティ実装計画書）…実施手順に記載されたシステムセキュリティ要件を細部化したもの。 

さらに、これらの運用記録を管理・記録する様式まで定める必要があります。デジタル全盛の時代に逆行するようですが、確実な記録と証跡管理が重要となります。 

文書整備に加えて、組織体制についても「誰が責任をもつか」が明確に規定されています。 

一般的に、セキュリティ部門は情報システム部などが兼務することも多いですが、防衛案件では基本的にCEO直下に専門部署を置き、他部門の干渉を受けずに情報統制できる体制が求められます。

実は、NIST SP 800-171には「何をすべきか（What）」は書かれていても、「具体的にどう設定すべきか（How）」までは書かれていません。 

そこで参照されるのが「NIST SP 800-53」です。171の要求事項を53と照らし合わせることで、53より具体的なパラメータや設定値が導き出されます。この二重構造を理解することが、実務への適用の第一歩です。

物理的な隔離と「完全オフライン」。利便性を捨てて安全を取る現場

ここからは、実際に現場で行われている物理的なセキュリティ対策の実態に迫ります。 

防衛省の案件に参画する場合、通常のオフィスで作業することはできません。「保護すべき情報を取り扱う専用の部屋（取扱施設）」を設置し、通常の執務室と物理的に隔離する必要があります。

この部屋には出入口を映す監視カメラの設置はもちろんのこと、入退室管理も極めて厳格に行われます。

取扱部屋への入室には、静脈認証などの入退管理機器の設置が求められます。「誰が入ったか」をなりすまし不可能なレベルで特定・記録する必要があるためです。

一般的なオフィスセキュリティを遥かに超えた、極めて高度な物理セキュリティが標準装備となります。 

さらに、「取扱施設内はインターネット接続禁止」というルールもあります。外部との通信は遮断されるため、当然ながらプロキシ経由での通信もできません。

Windows OSセキュリティパッチやウイルス対策ソフトの定義ファイル更新は手動で行います。 

外部で取得したセキュリティパッチや定義ファイルは、安全な媒体を経由して持ち込み、ローカル環境で一台一台適用する必要があります。

インターネットに繋がないことで外部からの侵入を遮断する一方、維持管理には膨大な手間とコストがかかる。これが防衛産業の現場のリアルです。

米国のCMMCと日本の都度監査。似て非なる2つの制度

米国と日本では、この基準への適合を確認するプロセスも大きく異なります。 

米国防総省（DoD）では、CMMC（Cybersecurity Maturity Model Certification）というサイバーセキュリティ成熟度モデルを導入しはじめています。

企業は事前にセルフアセスメントまたは第三者機関の審査を受け、レベルに応じた認証を取得すればDoDとの取引資格を得られます。

一方、日本には現在のところ同様の認証制度はありません。その代わりに行われているのが、案件ごとの防衛省による「都度監査」です。

企業は案件に参画する前に情報セキュリティ三文書やSSPを提出し、防衛省より承認を得る必要があります。認証がないからといって、決して緩いわけではありません。

日本では、納品直前に防衛省による厳しい実地監査が行われます。この監査では、事前に提出した計画書通りに運用が行われているか、事細かにチェックされます。

もし1つでも重大なルール違反（不履行）が見つかれば、それが解消されない限り、納品は認められず、次年度以降の契約にも深刻な影響を及ぼす可能性があります。 

「納品できない」ということは、企業にとっては売上が立たないことを意味します。プロジェクトの最後に待ち受けるこの監査をクリアしなければ、それまでの努力が水泡に帰す可能性があるのです。

まとめ

防衛省と取引する元請けだけでなく、下請先含むすべての企業に対して、同等の基準への準拠が求められます。 

攻撃者は、セキュリティの堅固な大企業ではなく、対策が手薄な下請け企業を踏み台にして情報を盗み出そうとします。

こうしたサプライチェーンリスクがあるため、防衛産業に関わるすべてのプレイヤーが、この厳しい基準をクリアしなければならないのです。 

防衛省が求めるセキュリティ基準は、一見すると過剰に思えるほど厳格で、非効率的にも見えます。しかし、そこには明確な意図があります。 

新基準が「検知・対応」を重視しているように、重要なのはルールを守ることそのものではなく、サイバー攻撃などからの「レジリエンス」を確保することです。

攻撃を受けることを考慮し、それでもなお業務継続し、情報を守り抜く強さが企業には求められています。 

防衛産業への参入は、企業にとって大きなビジネスチャンスであると同時に、国家の安全保障の一翼を担うという重い責任を負うことを意味します。 

防衛省のセキュリティ基準は、サプライチェーン全体で日本の防衛情報を守るための防壁です。

この基準の意図を正しく理解し、組織全体で取り組む覚悟をもつことこそが、防衛産業において信頼を勝ち取るための第一歩なのです。

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

前例なき制約を抱えた「ガバメントクラウド移行プロジェクト」始動

私は、官公庁案件を中心に、行政機関のガバメントクラウド（ガバクラ）導入を支援してきました。そのなかから今回ご紹介するのは、中央省庁の政府情報システムをガバクラへ移行するプロジェクトです。

このプロジェクトは、大容量データ移行に加え、「AWS Snowball利用不可」「システム間の直接のデータ移行不可」という二重の制約に直面した、前例のない試みでした。

私は、この移行プロジェクトに、プロジェクト管理支援として関与し、官側・ベンダー側双方に助言を行いながら、技術的制約などを整理しました。

ガバクラ環境では、デジタル庁が定める共通のセキュリティ要件に加え、各省庁が独自に設ける規則も遵守しなければなりません。

特に重要となるのが、扱う情報の「機密性区分」です。政府が扱う情報は、その重要度に応じて3つの区分にわけられます。

• 機密性1：インターネットで公開されている情報
• 機密性2：漏洩すると政府的なインシデントに発展しうる重要な情報
• 機密性3：漏洩が国家安全保障に影響のあるレベルの秘密情報

私が支援したシステムが扱っていたのは「機密性2」の情報。これは、「機密性3」の情報には至らないが慎重なとり扱いが求められるレベルです。

当然、インターネット経由でのデータ移行は許されず、セキュリティを担保した経路の確保が大前提となりました。

Snowballもシステム連携も封印。制約をどうのり越えるか。

大容量データを安全かつ効率的に移行する手段として、多くのエンジニアが真っ先に思い浮かべるのが「AWS Snowball」でしょう。

専用の物理デバイスにデータを格納し、輸送することで、ネットワーク帯域の制約を受けずに高速なデータ移行を実現するサービスです。

しかし、このプロジェクトでは、そのベストプラクティスが通用しませんでした。省庁側から「Snowballは使えない」という通達があったのです。

その理由は、省庁が独自に定めていた「サプライチェーンリスクマネジメント」という規則にありました。

サプライチェーンリスクマネジメントとは、製品やサービスが提供されるまでの一連の流れ（サプライチェーン）に潜むリスクを管理・統制する考え方です。

Snowballを利用する場合、デバイスにデータを格納した後、物理的にAWSのデータセンターまで輸送するプロセスが発生します。この輸送を担うのは、AWSから委託を受けたパートナー企業です。

つまり、元請けのAWSから二次受け、三次受けの輸送業者へと、複数の企業が連鎖するサプライチェーンが形成されます。

省庁側は、この連鎖が長くなるほど統制がむずかしくなり、情報漏洩のリスクが高まると判断しました。

当時、その省庁では物理デバイスを外部業者に委ねることへの理解が得られなかったのです。これが、Snowballが使えなかった最大の理由でした。

さらに、プロジェクトを複雑にしたのが公共システム特有の調達による制約です。今回は、移行元のオンプレミス環境を運用する事業者と、移行先のガバクラ環境を構築する事業者が異なっていました。

それぞれのシステムは完全にわけて管理されており、移行先の事業者が移行元のシステムに直接アクセスしてデータを抽出することは不可能でした。

これにより、移行元から移行先へデータを直接転送するというシンプルな構成がとれず、二つの断絶したシステムをいかにしてつなぐか、という新たな課題が生まれたのです。

物理輸送NG、システム間の直接移行NG。残されたのは「通信の工夫」だけ。

Snowballによる物理輸送が不可能である以上、残された選択肢はネットワーク経由での転送です。ただし、機密性2の情報を扱うため、インターネットは使えません。

そこで活路を見出したのが、デジタル庁が整備するGSS G-Netを経由した、省庁LANとガバクラをつなぐ専用の閉域網でした。

物理的なモノの移動がリスクなら、厳格に管理された通信経路でデータを送る。これが第一のブレークスルーでした。

次に、システム間の断絶という組織的な課題も解決する必要があります。

移行元の事業者が移行先のシステムにふれず、かつ移行先の事業者が移行元のシステムにふれないようにするには、両者の間に緩衝地帯を設けるしかありません。

そこで考案したのが、以下のステップを踏むアーキテクチャです。

• 移行元の運用事業者が、オンプレミス環境からデータを抽出する。
• 抽出したデータを、移行先の構築事業者が「中継サーバー」に一旦配置する。
• 移行先の構築事業者が、別途調達した「データ移行用端末」を使い、中継サーバーからデータを取得する。
• その移行用端末から、閉域網を経由してガバクラ上の移行先環境へデータを転送する。

これは、ベストプラクティスとはほど遠い、制約のなかでひねり出した苦肉の策です。しかし、このアーキテクチャによって、2つの制約を同時にのり越えるための道筋がみえてきました。

安全な経路の先に残る、「転送の信頼性」という落とし穴

移行経路は定まりました。しかし、ここで新たな懸念が浮上します。それは、「単純なファイル共有でデータを転送するだけで、本当に安全なのか？」という点です。

閉域網とはいえ、万が一の事態は想定しなければなりません。転送中のデータが破損する可能性、あるいは何らかの要因でデータが漏洩するリスクはゼロではありません。

特に、官公庁のプロジェクトでは、あらゆるリスクを想定し、その対策を論理的に説明する責任があります。このままでは、もっとも重要な「セキュリティの担保」が不十分だと考えました。

技術の“勘”を裏づける、定量的アプローチとは

どうすれば、この特殊な経路で、安全かつ効率的に20TBものデータを移行できるのか。そこで考えたのが、「AWS DataSync」の活用です。

DataSyncは、オンプレミスとAWS間のデータ転送を自動化・高速化するサービスです。

転送中のデータは自動的に暗号化され、データの整合性もチェックしてくれるため、セキュリティと信頼性に優れています。この機能こそ、我々が抱える課題の最適解だと思いました。

しかし、「よさそうだから」という理由だけで高価なサービスを採用することはできません。特に、官公庁のプロジェクトでは、あらゆる決定に客観的で論理的な根拠が求められます。

そこで私たちは、データ移行方法の選択肢を3つに絞り、リスクとコストに重みづけを行い、各選択肢を定量的にスコアリングするというアプローチをとりました。

例えば、「移行データ漏洩リスク」の項目では、暗号化機能がないネットワーク共有のスコアを高く（リスク大）、標準で暗号化されるDataSyncのスコアを低く（リスク小）設定します。

同様に、コストやほかのリスク項目も数値化し、それぞれの重要度に応じて重みづけをして総合点を算出しました。

その結果は、一目瞭然でした。総合スコアがもっとも低かった（＝リスクとコストのバランスがもっとも優れていた）のは、DataSyncだったのです。

比較結果を共有したところ、技術的な詳細がわからない関係者にも、なぜDataSyncが最適なのかが論理的に伝わり、最終的に満場一致で採用が決定しました。

DataSyncを現実解に落とし込む「実践的アーキテクチャ」

最終的な構成は、非常にシンプルです。中継サーバーに置かれた移行対象データに対し、データ移行用に用意した物理端末からDataSyncを使ってAWS Direct Connect経由で転送します。

ここで1つ、実践的な工夫を加えました。DataSyncエージェントは通常、仮想マシン上での稼働が推奨され、メモリ64GB以上といった要件があります。

しかし、今回は移行のためだけに高性能な仮想化基盤を用意するのは現実的ではありませんでした。

そこで、調達した物理端末（メモリ64GB）に直接DataSyncエージェントをインストールして稼働させるという、少しイレギュラーながらも現実的なソリューションを選択。

これにより、コストを抑えつつ、要件を満たすことに成功しました。

制約は、思考停止のいいわけにならない

ガバクラ導入プロジェクトでは、規則の縛りなどによって、世の中でいわれるベストプラクティスをそのまま適用できないケースがあります。しかし、制約は思考停止のいいわけにはなりません。

ベストプラクティスを鵜呑みにするのではなく、なぜそれが最適とされるのか、その本質を理解すること。

そして、その本質を理解したうえで、目の前にある制約のなかでどうすれば目的を達成できるのかを考え抜くこと、その考えの妥当性を周囲にきちんと説明することが、これからを生きるエンジニアには必須のスキルになるでしょう。

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

SHIFTは、国家防衛のITを支える「実働部隊」。人手不足を抱えた巨大市場

――まずはK.K.さんの現在の役割について教えてください。所属部署であるNSサービス部は、国防システムに関わる非常に重要度の高い仕事をされていますよね。

K.K.：NSサービス部は大きく「コンサルティング」と「エンジニアリング」に分かれています。

私はグループ長補佐という立場から、後者のエンジニアリング部隊として、防衛省、防衛装備庁をお客様とする大手ベンダーが関わる案件の管理を任されています。

私の役割は大きく2つあります。1つは、新しい仕事を獲得してくるプリセールス的な動き。もう1つは複数プロジェクトを管理・横断的にみる上位PMとして、課題の早期発見と調整を行うこと。

お客様と現場のPMを繋ぎ、品質と納期の双方を守るのが私の仕事です。

――大手SIerで40年のキャリアをもつK.K.さんからみて、防衛領域におけるSHIFTの存在価値については、どのように捉えていますか？

K.K.：非常に重要なポジションにいると自負しています。防衛省のエンジニアリング案件は大規模なものが多く、大手ベンダーしか対応できないケースがほとんどですが、圧倒的に技術者が不足しています。

特に、クラウドリフトやゼロトラストの設計、構築といった最先端の技術者の要請が強いなかで、そういった技術者を多く有していることが強みになっています。

また、コンサルティングチームと一体となってグランドデザインを描くことから、設計や実際のパラメータの設定、構築まで、どこのフェーズでも柔軟に対応できる要員を抱えていることも強みです。

上流工程から下流工程までたしかな技術で支援し、確実にプロジェクトを完遂できる「実働部隊」としての価値が大きいと思います。これは他社にない強みだと思います。

――防衛予算の増額がニュースでも話題になっていますが、IT現場でもその影響は感じますか？

K.K.：肌感覚としても強烈に感じますね。以前私が防衛業界で働いていたころと比べると、大手ベンダーの防衛省からの受注額は3～4倍、数千億円に跳ね上がっています。

急激な規模の増加に、ベンダーの従業員だけでは手がまわりきらないので、彼らは外部企業と協働し、そのマネジメントに専念せざるを得ません。

圧倒的な人手不足のなかで予算と需要は急増している。SHIFTにとっては、まさにいまが最大のビジネスチャンスという状況です。

防衛省の共通インフラサービス刷新とゼロトラスト移行。少数精鋭で担う国家基盤のセキュリティ

――では、実際にどのようなプロジェクトが動いているのか、可能な範囲で教えていただけますか？

K.K.：象徴的な例として防衛省の共通インフラサービスがあります。

これは防衛省の全システムが利用するネットワークインフラと共通サービスで、これまではオンプレミス環境で構築され、境界防御型で守られていました。

しかし、時代の変化と共にサイバー攻撃は高度化・巧妙化をつづけています。境界防御の限界が叫ばれるようになり、ゼロトラスト型のシステム構築が求められています。

同時に、システム環境の柔軟な対応要請に応じるため、商用クラウド環境へ移行という大規模な刷新が進んでいます。

――まさに国防インフラのDXですね。そのなかでSHIFTはどの部分を担っているのですか？

K.K.：防衛省の共通インフラサービスのクラウド化において、もっとも重要となる「セキュリティ領域」の設計・構築を担当しています。

ゼロトラストの設計、構築をはじめ、改ざん検知やエンドポイント監視など、セキュリティ関連の重要アイテムの設計を担っています。

また、米国国防総省の基準をもとにしたRMF（Risk Management Framework）対応は、国内でも扱えるエンジニアがほとんどいない特殊領域です。

SHIFTには、このRMFに精通した専門人材が多数在籍しており、他社にはない強みになっています。

そこで、SHIFTではRMF観点で漏れなくセキュリティ設計がなされているかといった設計の指導等も実施しています。

ほかの案件でも、RMF観点から設計、構築を支援するケースが増えており、防衛システムのセキュリティ確保は、SHIFTにお願いしたいという状況になってきています。

――参画規模としてはどれくらいなのでしょうか？

K.K.：防衛省の共通インフラサービス全体では100名規模のプロジェクトですが、私たちが担うセキュリティチームは現在6名ほどです。

人数だけ見れば少なく感じるかもしれませんが、少数精鋭で国家防衛のセキュリティ設計の根幹を担っていると考えると、その責任とやりがいの重さを感じていただけると思います。

いまは設計フェーズなので人数も少ないですが、構築フェーズになれば要員も2倍、3倍にしたいと考えています。

ロジ支援から宇宙監視まで。40年防衛を支えたSEのキャリア

――ここで少し視点を変えて、K.K.さんご自身のキャリアについて伺わせてください。新卒から約40年間、防衛畑一筋でこられたそうですね。

K.K.：はい。大学卒業後に大手ベンダーに入社して以来、ずっと防衛関係のプロジェクトに携わってきました。主に担当したのは「ロジスティクス（後方支援）」の分野です。

戦車や戦闘機といった「正面装備」ではなく、補給・整備・輸送・人事・給与といった、およそ25万人もの自衛隊員を支える業務システムですね。

また、先ほどからお話している防衛省の共通インフラサービスの立ちあげにも従事しました。

退職前の3年間は、スペースデブリ（宇宙ゴミ）が衛星に衝突しないよう24時間監視するシステムの開発にも携わりました。

現在、このシステムは改修中で、SHIFTとしてテスト支援主体ですが15名ほど参加しています。

――宇宙まで守備範囲とは、スケールが壮大でロマンがありますね。

K.K.：そうですね。防衛省は「自己完結型」の組織といわれ、衣食住からインフラまですべて自分たちで賄っています。まさに国家の縮図であり、社会貢献をダイレクトに感じられる仕事でした。

――そこからなぜ、SHIFTへ転職されたのでしょうか？

K.K.：正直、最初は転職するつもりはありませんでしたが、早期退職制度をきっかけにいままでの経験を活かせる環境を探してみようと思いました。その際、エージェントを通じて偶然SHIFTを知りました。

第一印象は「テストに目をつけるとは、おもしろい会社だな」と。長年現場を見てきて、品質検証がおろそかになりがちな開発の課題を痛感していたので、SHIFTの戦略には強く共感しました。

――入社当時はまだSHIFTにはナショナルセキュリティの部署はなかったですよね。

K.K.：ええ。最初は公共部門でPMをしていましたが、防衛事業を強化するということで自分の経験を活かせると思い異動しました。

NSサービス部の部長を務める澤田さんは、前職以前から国家安全保障機関（内閣官房、警察庁、防衛省、JAXAなど）のシステム整備に係る調査研究やシステム整備支援などにPM・総括責任者として20年ほど従事した人物です。

当時、澤田さんの人脈でコンサル案件はとれていたのですが、もっと大規模なインフラ開発に入り込みたいという想いがありました。

そこで私がツテを頼りに挨拶まわりをはじめたところ、さまざまな問い合わせをいただくようになり、これまでほぼゼロだったエンジニアリング支援の受注にもつながって、徐々に大きな案件の相談も寄せられるようになりました。

自分の活動が、防衛事業の発展に寄与できていることをやりがいに感じますね。

――やりがいを感じながら働かれていることが伝わってきます。

K.K.：私はSHIFTに入社できてよかったと思っています。40年間培ってきた経験や人脈を活かせること、商談を広げていける環境があることが本当にうれしいですね。

長年、国家安全保障のために微力ながら貢献してきたという自負がありますが、SHIFTのような『技術の実働部隊』として現場に近い視点でプロジェクトに向き合うと、また景色が違って見えます。

自分たちの技術がダイレクトに国家の安全に直結している。その手応えを肌で感じるたびに、責任感とやりがいが湧いてくるんです。

防衛×汎用技術が生む「希少価値」。スキルはむしろ広く通用する

――読者のなかには「防衛システムは特殊すぎて、これまでの経験やスキルが活かせられるか？」と不安に思う方もいるかもしれません。その点はいかがでしょうか？

K.K.：防衛システムをつくる技術そのものは、OSもネットワークもクラウドも、すべて世の中で使われている「汎用技術」です。インフラやネットワークエンジニアの方がもつ経験は活きるはずです。

むしろRMF（Risk Management Framework）といった、国家レベルの厳しいセキュリティ基準や、ゼロトラストのような最新トレンドを大規模環境で実装する経験は、市場価値を飛躍的に高めることになると思いますよ。

――「防衛分野の仕事をしていた」という実績自体が、エンジニアとしてのブランドになるわけですね。

K.K.：その通りです。特に外資系企業やセキュリティ意識の高い企業に対して、「日本の防衛インフラのセキュリティを構築していました」といえば、それだけで技術力と信頼性の証明になります。

「特殊で閉鎖的」なのではなく、「希少で価値が高い」経験ができる場所だと考えてもらえればと思います。

――最後に、今後の展望と、この領域に挑戦したい方へのメッセージをお願いします。

K.K.：現在、防衛市場は拡大しており、やればやるほどチャンスが広がるおもしろいフェーズにあります。今後はさらに営業を強化し、エンジニアが活躍できるフィールドを広げていきたいですね。

求める人物像としては、基本的な経験はもちろんですが、「主体性」や「責任感」を重視しています。

防衛省のお客様は、国を守るという使命感をもつ熱い方が多いです。困難な状況でも「自分がなんとかする」というオーナーシップをもって動ける方なら、きっと大きなやりがいを感じられるはずです。

国家安全保障の最前線で、希少価値の高いキャリアを築きたい方をお待ちしています。

――本日は貴重なお話をありがとうございました！

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

実機を使う使わない？私の勉強方法、苦労もさまざま

――資格勉強のなかで工夫したことや自分ならではの勉強方法を教えてください。

桒原：スイッチとルーターの実機を買って、勉強がてらいじって遊んでいました。中古のジャンク品ですが、実際にふれるほうが楽しいですね。

佐藤：私は実機を買っていませんが、 Cisco Packet Tracerというソフトウェアを使用して学習していました。実機は研修で使った程度です。

桒原：ベテランのネットワークエンジニアは、実機を買って学習しているイメージがありますね。勉強方法も時代とともに変わってきているのかもしれません。

佐藤：以前、先輩従業員にわからない箇所を聞いたら、ツールが生まれた経緯までさかのぼって教えてくれました。歴史がわかると、勉強にも取り組みやすくなりますよね。

葉：Splunkは自分のパソコンにインストールすればさわれますが、実際のログを収集できるわけではないですし、十分なスペックのサーバーを複数用意するのも簡単ではありません。

その意味で、実際に本番と同じ環境を構築することができない」むずかしさはありました。

――ほかにも苦労したこと、悩んだことはありましたか？

葉：先に合格した人が社内におらず、相談できる相手がいなかったため、情報収集から対策までひとりで行うのは大変でした。

Splunk製品の勉強会は社内でも開催され、Splunk社をはじめとするベンダー主催のイベントに自主的に参加することはありましたが、資格に特化した勉強会は当時なく、インターネット上にも情報がほとんど出回っていなかったため、そういった点も苦労しました。

佐藤：私の場合、いままで学習したことのない分野の資格勉強をはじめるため、最初のうちは用語もまるでわかりませんでした。基礎知識がつく一歩手前の状態が辛かったですね。

桒原：ネットワーク領域は覚える量が多いですよね。

Aについて調べても、「AとはBのことです」と解説されていて、Bが何かわからないから理解できない。Bについて調べると、「BはCです」とわからないものが新たに追加されてしまうこともありました。

また、私は勉強を習慣化するのが大変でしたね。夜に勉強するのが苦手で朝やっていたのですが、その習慣をつけるまで苦労しました。

三人三様の原動力。昇給、学ぶ楽しさ、ポジションを確立

――そこまで大変な想いをして資格取得をする、その原動力を教えてください。

桒原：私の場合は、将来に対するポジティブな気持ちです。例えば、「この資格に受かったら昇給するだろうな」「仕事でいい結果を残せるだろうな」「自分が設定した目標を達成できるな」というものです。

学ぶ楽しさ自体も原動力の1つですね。勉強していてわからなかったことが「こういうことだったんだ」とわかってくることがモチベーションになっていました。

佐藤：私は、「合格します」と周囲に宣言することで自分を追い込んでいました。上司からの期待を感じられて、なおかつ時間に比較的余裕がある研修段階で勉強しました。

通勤中も問題集を解いていましたし、土日も家での勉強に疲れたらカフェへ移動して勉強していました。

葉：モチベーション維持がむずかしくありませんでしたか？

佐藤：「合格したい」というよりは、「知りたい、勉強したい」という知識欲がモチベーションになっていて。

学習したことが研修や業務で出てくると、以前はまったくわからなかったのに、内容を理解できるようになっているんです。勉強したことが自分の身になっているんだと実感できて楽しいですね。

葉：同期には、社内キャリアUP制度「トップガン」（※SHIFTグループ従業員を対象とした社内制度）など社内資格の取得に注力する方もいるのでは？

佐藤：そうですね、全員何かしらの資格を取ろうとしていました。いっしょに勉強したり、教材を紹介しあったりしたのもいい思い出です。

そういえば研修期間中のことですが、部長から「同期むけに勉強会の講師をしてください」といわれたことがありました。驚きましたが、こうした経緯で同期とは教えたり教えられたりする関わりあいができました。

葉：私の原動力はいくつかありますが、一番は「部内で自分の立ち位置を確立したい」という思いです。

当時は自身を表す肩書きが「新卒」しかなかったため、「この製品のプロフェッショナルです」と自信をもっていえるような存在になりたいと考えていました。そうした思いが原動力になっていたと思います。

資格を取得すると、業務内容も変わりました。Splunkに関する知見をもつメンバーとして案件に参画する機会が増えたほか、最近ではSplunk Observability Cloudという別製品のPoCを担当するなど新しい分野にも挑戦しています。

資格取得で新たな挑戦の場を与えてもらえることも、モチベーションの一つでしたね。

技術の奥深さに気づかされる。活動は幅を広げる

――いま葉さんが変化についてふれてくれましたが、みなさん資格を取得して、何か変化はありましたか？

桒原：一番変わったのは私自身のマインドだと思います。仕事を「もっとがんばろう」と思えるようになりました。

学んだことを活かしてチームに貢献できていることを実感したいというのが一番のモチベーション。今後は私自身の学びを技術ブログなどでシェアする活動にも取り組んでいきたいですね。

佐藤：私は研修中の資格取得でしたので業務の変化はありませんが、心境の変化はありました。CCNAに受かって、まだまだ学びが足りないことが見えてきたんです。

上位資格である「Cisco Certified Network Professional （CCNP）もとってほしい」といわれた意味がわかった気がします。知らなければならないことが積み重なっていて、技術の奥深さを痛感しているところです。

葉：私は、「ゆくゆくは特に技術面でプロジェクトをリードしていってほしい」と周囲から期待されるようになったと感じています。

資格を取得したことをきっかけに、資格取得を目指す方から相談を受けたり、Splunkを扱ったことのない人向けの勉強会を開催したりするなど、「Splunkにたけている人」として見られる機会も増え、後進の育成にも携わるようになりました。

「やりたい」を叶えてもらえる、挑戦の機会が多い

――目標にしている人や、今後挑戦したいことはありますか？

佐藤：私は、技術面でチームに貢献できるようになりたいですね。誰かを目指すというよりも、周囲のPMから一人前と認めてもらえるようになりたいです。

桒原：私は、セキュリティを軸にネットワークやAWSなど、ほかの領域にも精通している人を目標にしています。自分のできることも広げていきたいです。

葉：私は、技術に関する後方支援のような、自分も手を動かしつつ周囲をサポートできる人になりたいですね。

案件が増えているので、私が複数の案件を横断してサポートできるようになれば、人をうまくまわせるようになると思います。

――最後に、入社してから現在までを振り返って、「SHIFTに入ってよかった」「この成長ができたのはSHIFTだからだな」という経験はありましたか？

佐藤：研修で講師役を務めた経験を踏まえて、チャレンジの機会を与えてもらっている実感があります。本人の希望を叶えようとしてくれるので、希望はどんどん伝えていきたいです。

桒原：私も同感です。「Splunk以外の案件も関わってみたい」と上司に伝えたところ、EDRを扱うまったく別の案件に入れました。

いまはSplunkに戻ってきていますが、それも含めて個人の想いを大事にしてくれるカルチャーがあると思います。

葉：現場での努力や成果を発表するS-1グランプリ※で、社長や役員の前でプレゼンする機会をもらえるなど、新卒1年目からチャレンジの機会が多いと思います。

これからも、自身の努力をアピールできる場では積極的に発信していきたいと思います。

※多様化するお客様ニーズに応えるためのさまざまな取り組みについて、地道な努力や試行錯誤を称える社内イベント

――今日はありがとうございました！

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

技術への強い関心。評価してほしいポイントを見てくれた

――まずは、みなさんがSHIFTへの入社を決めた理由を教えてください。

桒原：私の場合は、在学中に研究と並行してITの勉強をしていたのですが、特に軸をもたず興味のままにやっていたんですね。

でもSHIFTは純粋な好奇心による行動を評価してくれて。技術系の部署が多かったことも後押ししました。

佐藤：私も学生時代に資格を取得したことを一番評価してほしいと思っていたところ、「自分の能力や努力を定量的に示した」と、真摯に受け止めてくれたのが決め手でしたね。

葉：在籍していた学部は情報系だったんですか？

佐藤：いえ、経済学部です。実は高校生のころ、情報系の学部への進学も検討していたんですよ。「そっちに進んでいたら何を学んだのだろう」と、気になって勉強したんです。基本情報技術者試験と応用情報技術者試験をとりました。 

葉：そうでしたか。

私の場合は、学部でAIの研究をしていたので、修士課程に進んでAIをさらに極めるか、学部卒でIT業界に入るか迷っていたのですが、最終的には最初に内定をくれたSHIFTに入社を決めました。

――みなさんは、セキュリティ・ネットワークサービス部への配属を希望していたのですか？

桒原：私は「どうしてもセキュリティに」とは思っていませんでしたが、とにかく技術にふれる部署にと思っていました。

当時あったいくつかの部のなかではセキュリティ領域が一番技術的なのかなと漠然と感じていました。

葉：私もほぼ同じです。また、セキュリティ・ネットワークサービス部は年齢層が比較的高めなこともあり、知識と経験が豊富で話に深みがある人が多いと感じて。

いっしょに働いたら多くのことを学べそうだと思い希望しました。

佐藤：私の場合も一つ目は技術にふれたいということ。二つ目は、資格の勉強をした際に、ネットワーク分野が一番面白いと感じて。その領域と親和性の高い部署に行きたかったんです。

葉：新卒向けに私がセキュリティの部署紹介に行った際も、佐藤さんはいろいろ聞きに来てくれましたよね。熱心だなと記憶していました。ネットワークにふれられてよかったですね。

佐藤：はい。希望を聞き届けてもらえて、すごく楽しいです。キャリアや業務についていったことはストレートに受け止めてもらえるし、ポロっと口にしたことでも調整してくれて驚くことさえありますね。

若手を育てる文化、フラット&カジュアルな雰囲気

――配属後、想像とちがった点・ギャップを感じた点はありましたか？

佐藤：私は特にありませんでした。配属前から資格の取得を推奨しているのを聞いていましたが、配属後も実感がありイメージ通りですね。

葉：資格取得は本当に後押ししていますよね。私も会社に受験料を負担してもらって資格を取得したことがあります。さらに部門が更新料を負担してくれることもあります。

会社としてのサポートに加え、部でも予算をとって継続的なスキルアップを支援してくれます。

桒原：資格以外の話をすると、私が入社したときは新卒が少なかった一方で、平均年齢は高めの部署だったので緊張していたんですよ。

でも実際には、大切に育ててくれるし、みなさん気軽に話しかけてくださって、いい意味でギャップを感じたことを覚えています。

葉：組織のフラットさがありますよね。部長や副部長とも大きな隔たりを感じることはありません。

大企業でいうと部長は接点の少ない存在かもしれませんが、SHIFTでは隣に座っていたり、チャットで直接話したりすることもあります。体制としても直属の上司が副部長ですし、階層がかなりフラットです。

佐藤：私たちが所属するグループは、カジュアルな雰囲気ですよね。リモートワークも多いですし、若手も比較的多いと思います。

葉：ベンダーの方と話す場でも、お互いにラフな服装で参加することもあります。部長も外資系出身なので、SHIFTのなかでは部全体が外資系IT企業寄りの雰囲気があります。

「自らの興味」「周囲からのすすめ」で、それぞれがはじめた資格勉強

――ここからは資格取得のきっかけを聞かせてください。佐藤さんと桒原さんはCisco Certified Network Associate（CCNA）を取得されていますが、佐藤さんは、先ほど発言があったようにネットワークへの興味から勉強をはじめたのですか？

佐藤：そうです。コマンドを実際に入力するような問題もあって、より実践的な内容になっているので。それと部長からCCNAはなるべくはやく取ったらといわれたのも後押ししました。

桒原：取得したタイミングはけっこうはやかったですよね。

佐藤：はい、配属されて2ヶ月目くらいですね。研修中は比較的余裕があったので集中的に勉強しました。

最近は、CCNP Securityの勉強をはじめました。桒原さんがCCNAをとろうと思ったきっかけは何ですか？

桒原：以前、顧客環境へのEDR製品導入・検討を担当していたのですが、その際に顧客環境のネットワーク構成図を拝見した際に全然理解できなかったことがきっかけです。

葉：必要に迫られて、というより自分で「勉強したほうがよい」と感じてはじめたんですか？

桒原：そうですね。業務では直接的にネットワークの知識は求められませんが、今後Splunkを扱ううえでは必要とも感じて。興味もありましたし、ネットワークの知識が陳腐化することは少ないですから。

――葉さんは、ログ分析製品「Splunk」の高難易度資格である「Splunk Enterprise Certified Architect」と「Splunk Core Certified Consultant」に、社内ではじめて合格されたそうですね。

葉：そうですね。私が最初に入った案件が、Splunkをコンテナ化してGKE（Google Kubernetes Engine）上に構築するというものでした。

ですが、こうした案件が当時の日本にはなかったようで、全員手探りの状態からなんとか勉強しながら形にしたんです。

そういった経験を踏まえて、上長からはSplunk構築の知識をさらに深めてほしいと期待され、「Splunk Enterprise Certified Architect」というSplunkの構築に関する資格を受けてみないかともすすめられました。

実際合格したことで、さらに上位の資格となるSplunk Core Certified Consultantにも「合格できるんじゃないか」という自信が湧いてきました。

試験を受けるためには事前に9時から17時半までの講習を5日間、つまりまるまる1週間受講する必要があります。

すすめられたことが受検のきっかけではありましたが、その講習と試験に合格できたことで自信がつきました。

桒原：私はSplunk Enterprise Certified Adminならもっていますが、Splunk Enterprise Certified Architectからはラボ※がありますよね。そのため、難易度が段違いに高く感じます。

※試験前に受ける教育で、課題があり合格する必要がある

――ありがとうございます。後編では、資格勉強のなかで工夫したことや苦労、資格取得の原動力などを聞いていきますのでお楽しみに。

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

ネットワーク一筋のプロが選んだ、次なる舞台

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

N.K.：はい。私は大学卒業後、大手SIerのグループ会社に新卒で入社し、SHIFTに入るまでずっと同じ会社に勤めていました。キャリアのほとんどをネットワーク畑で過ごしてきましたね。

――ネットワークの世界に入ったのはいつごろだったのですか？

N.K.：キャリアのスタートは、POSシステムの保守開発だったんです。転機は24歳のときでした。

まだ「ネットワーク」という言葉も一般的ではなかったころに、会社がネットワーク事業を立ちあげることになり、その一員としてスキルを学ぶため親会社に出向することになったんです。

仲間といっしょに新しいサービスを立ちあげ、会社も成長していくというなかで得られた達成感は何物にも代えがたかったですね。

そのあとは官公庁、学校、病院、通信キャリアなど、本当にさまざまな業種のネットワーク設計・構築に携わりました。

幅広い領域で学びを得たのが、私のキャリアで最も活きている経験です。

転職を考える直前の2年間は、GIGAスクール構想第2期に向けた文教領域で、国が掲げるゼロトラストのモデル設計やセキュリティ領域の戦略的な部分に関わっていました。

――そこから転職を考えはじめたきっかけは何だったのでしょうか？

N.K.：その2年間はバックヤードのモデル開発が中心で、お客様と接する機会がほとんどありませんでした。

「やはり自分は、お客様と直接関わるのが楽しい」という思いが強くなったのが1つです。

さらに、「裁量権」の問題もありました。

ビジネスプランを進めるにも、立場を越えて積極的に動けないところがあり、私がいうのと裁量権をもつ人がいうのとでは、まわりの動きが明らかに違う。

自分の力で物事を動かせない歯がゆさがありました。

それに加え、会社の方針としてネットワーク事業が以前ほど重要視されなくなってきた感覚もありました。

このまま60歳の定年を迎えたら、再雇用でさらに裁量権がなくなる。

「自分はまだいろいろやりたいのに、このままでいいのか」という違和感や、子どもが社会人になり子育ての責任を終えたことも転職への最後の一押しになりました。

――そうした状況で、SHIFTとはどのように出会ったのですか？

N.K.：私は、リファラル（知人紹介）でSHIFTに入ったんです。毎年年賀状のやりとりをしていたのですが、そこで「そろそろ転職を考えています」と書いたら、連絡をいただいて。

彼がSHIFTにいるとは知らなかったのですが、仕事内容やクラウドにも力をいれていることを聞いて「カジュアル面談を受けてみよう」と思ったのが、私の本格的な転職活動のはじまりでした。

これまで人脈づくりに積極的ではなかった自分を反省していたので、SHIFTならいろいろな人と出会い、新しいチャレンジができるかもしれないという期待ももてました。

――カジュアル面談での印象はどうでしたか？

N.K.：対応してくれたのがいまの上長だったのですが、「セキュリティをやるにも何をするにもネットワークは必須。

その知識をもっている方にご入社いただきたいです」と言ってもらえました。

その言葉を聞いて、「もしかしたら、ネットワーク事業の立ちあげを、もう一度経験できるかもしれない」とわくわくしました。それが、入社を決めた大きな理由の1つです。

加えて、70歳定年制度も大きな魅力でした。実際、入社時研修では、私より年上の方も若手の方もいて、多様な年齢層のメンバーとのグループワークがとても刺激的でした。

裁量と信頼を手に――SHIFTでかなえた理想の働きかた

――入社してからは、どのような業務を担当しているのですか？

N.K.：SASE（Secure Access Service Edge）、SSE（Security Service Edge）といった、いままさにお客様の関心が高まっている領域で、ネットワークとセキュリティ両面の知見を活かして技術支援を行っています。

現在に至るまで、教育系で2案件、省庁や防衛関係ありましたね。最近だと、技術支援で一ヶ月にFAQ数十件ほど対応することもあります。

ネットワークベンダー様とともにお客様支援にあたっているのですが、SHIFTとの最初の取り組みである案件に私がアサインされました。

支援領域は要件定義からテストまで開発工程の全領域で、例えば「リモートアクセスでこういうことがしたいがどうすればいいか」といったテーマに対して提案をします。

あとは、まだはじめたばかりですが、SSEやセキュアアクセスといった製品の習熟度トレーニング、いわゆる学習コンテンツの作成にも携わっています。

実はアサインから約4ヶ月後にはネットワークベンダー様から「これからは、プロジェクトをSHIFTがリードしてくれないか」というお話をいただきました。

私にとっては大きなチャレンジでしたが、自分の裁量で「やります」と即答しました。

さらにその3ヶ月後には、SHIFTがリードする案件が3件に増え、全体としても5案件に。お客様との信頼関係がこうした形として表れています。

――まさに望んでいた裁量権を発揮されているように見えます。

N.K.：遠慮なく意見をいえますし、それを受け入れてくれる環境がある。期待以上に前向きに仕事ができています。

お客様からは「もっとはやくN.K.さん、SHIFTに出会いたかった」と嬉しい言葉までいただき、必要とされている実感があります。

最近では、「新しい座組みでいっしょにビジネスを展開していきませんか」という提案もいただいています。ビジネス創出にまでつながっていて、やりがいをとても感じています。

――短期間でそこまで信頼を勝ち得た背景には、どんな仕事へのスタンスがあるのでしょうか？

N.K.：私は、松下幸之助さんの「喜ばれて喜ぶ」という言葉が好きなんです。「技術でお客様に喜んでもらいたい。

その姿を見て私も喜びたい」という思いが、自分の原動力ですね。

単に技術だけを提供するだけでなく、先方が「なぜこれを必要としているのか」をきちんと聞き、信頼関係を築きたいと考えています。

――泥臭い部分も厭わない、と。

N.K.：はい。リモート対応が多いなかでも、なにかあったら「いっしょにお客様を訪問しませんか」と積極的に声をかけています。

そういう動き方は、これまでのビジネスパートナーにはなかったかもしれませんね。

――前職での経験は、いまの業務にどう活きていますか？

N.K.：ネットワークは道路のようなもので、そのうえにサーバーやクラウドがのった環境を、セキュリティで守っています。

私は前職でその全体像を見てきましたので、お客様と話す際も多角的な視点から提案をします。

例えば、「この学校なら、このクラウドサービスを使っているだろうな」という知識が役立つことも。

前職では、複数のメーカーの製品を組み上げてSASE同等のものをつくる、ということをやりました。

その経験が、いままさに案件に関する最先端のサービスを深く理解する助けになっています。

成長も、挑戦も、人とのつながりから生まれる

――N.K.さんから見て、SHIFTの技術的な強みはどこにあると感じますか？

N.K.：私が前職から取り組んでいたゼロトラストセキュリティの要となる「認証認可」と「ログ管理」の2つに対して、非常に強い会社だと感じます。

それに加えて、やはり人材が豊富な点も強みですね。さまざまなバックグラウンドをもつ経験豊かな方が多く、セキュリティ領域に関しては本当に強いと思います。

それをベースに、いまはSASE、SSEといった領域でサービスを立ちあげようとしているので、インフラまわりも含めてさらに強くなるのかなと。そんな期待をもっています。

ネットワークの知識があるかどうかで、クラウドやアプリケーションの理解度は大きく変わります。

ですから、ネットワークの知識を土台に、上流工程やプロジェクトマネジメント、新しい技術に関わっていきたいという志向性の方には、SHIFTは最高の環境を提供できると思いますよ。

――では最後に、N.K.さんの今後の目標をお聞かせください。

N.K.：基本的な業務への向き合い方は変わりません。技術でお客様に喜んでいただくことを原動力に、お客様目線を貫きたいです。

そして、日々の業務を通じて、お客様やビジネスパートナー、SHIFTのメンバーといった「つながり」を大切にしていきたい。

信頼関係があるからこそ、新しいチャレンジが生まれると信じています。

あとは、自分の経験を若い人に伝え、彼らの成長を後押しできるような人材になりたいですね。

――本当に生き生きと仕事をされている様子が伝わってきました。本日は貴重なお話をありがとうございました！

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

3案件を担当。特権ID管理のPoCから本導入に至ったものも

――T.Y.さんは現在、3つの案件を担当されていると伺いました。それぞれについて教えてください。

T.Y.：3つの案件すべてでPMを務めていますが、同時にシニアエンジニアとして、プロジェクトの技術的な部分をリードすることも期待されています。案件はそれぞれタイプがまったく違うんですよ。

1つ目は、長期的な運用支援案件です。

以前SHIFTが導入支援したセキュリティソリューションをお客様が運用されているのですが、そこで発生する技術的な課題への対応や改善提案、トラブル発生時の解決策の模索などを行っています。

直接システムを触ってトラブルシューティングも行う、かなりテクニカルな内容ですね。

2つ目は、1つ目の案件と同じお客様で、新しい基盤へ特権ID管理システムを拡張していくプロジェクトです。

こちらは設計段階から参画し、構築、テスト、そして運用にのせるまでをワンストップで支援しています。

3つ目は「特権ID管理を導入したい」というお客様に対して、PoCを実施した案件です。

SHIFTが提案した製品の有効性を検証し、結果が良好だったため、本導入も受注できました。ゼロからお客様との信頼関係を築き、我々のビジネスが広がっていく手応えを感じられた案件です。

――特権ID管理に関する悩みを抱えているお客様は多そうですね。

T.Y.：はい。いまやどんな企業でも多くのITシステムを使っていますが、そこには必ず「特権ID」、つまり管理者ユーザーアカウントが存在します。

これが乗っ取られると被害が甚大になるため、最優先で守らなければなりません。 

ですが、導入には専門的なセキュリティ知識や、IDをどう管理していくかという複雑な運用設計が必要で、導入に踏み切れない企業が非常に多いのが実情です。

これに対して、特権管理IDだけではなく、一般IDも含めたIDの棚卸しからSHIFTでは支援が可能です。

中立の立場×高い技術力──信頼を勝ち取るSHIFTの強み

――SHIFTが受注するセキュリティ案件には、何か特徴がありますか？

T.Y.：まず、案件そのものの難易度が高いこと。

そしてもう1つ、SHIFTは特定のセキュリティ製品のライセンス販売はしておらず、販売会社とタッグを組んで、我々がシステムインテグレーションを担っています。

普通ならSIer同士で案件の取り合いになりがちですが、我々はライセンスを売らない中立的な立場なので、競合せず、むしろ強力な協力関係を築ける。これがSHIFTの大きな強みだと感じています。

――なるほど、製品をかついでいないので課題に応じた最適な製品を選ぶこともできますね。「お客様からSHIFTが選ばれる理由」という観点で、ほかにもSHIFTの強みはありますか？

T.Y.：そうですね。SHIFTの強みは多数あると思っています。まず、セキュリティ領域の深い知見をもつエンジニアが、テクニカルな部分にしっかりと対応できる点です。

これに応えつづけられているからこそ、何年もつづくプロジェクトとしてご依頼いただけているのだと思います。

技術力を裏付ける一例をあげますと、私たちが扱っている「PAM」という特権ID管理ソリューションは、国内では特定のパートナー企業さんが専売しているのですが、その製品を構築できるのは、国内ではほぼSHIFTだけなのです。 

「実機で理解する」姿勢が導いた、技術リーダーへの転機

――ここからはT.Y.さんのキャリアパスに話を移したいと思います。SHIFTに入ってから、ご自身のキャリアに特に影響を与えた、ターニングポイントになったような案件はありましたか？

T.Y.：はじめて担当した特権ID管理の案件ですね。当時はまだリーダーではなくメンバークラスのポジションで、自分より経験の浅いメンバー2名の指導をしながら、技術リーダーに教えを乞うという形で参画しました。

参画して3ヶ月ほどで、当時の技術リーダーが別のプロジェクトに注力することになり、私が技術リーダーを引き継ぐことになりました。 

――どう乗り越えたのですか？

T.Y.：私は「自分で手を動かして理解する」ことをつねに大切にしています。

当時は詳細設計のフェーズで、ドキュメントを読むだけでは、設定項目ひとつの意味や影響がイメージできない。

そこで当時の技術リーダーと交渉し、詳細設計と並行して検証環境を構築させてもらえるよう、計画を変更してもらいました。

このおかげで、私だけでなくチームメンバー全員の技術習得が加速し、プロジェクトを早期に立ちあげることができました。

チームとして成長するにはどうすべきか、という視点を得られた非常に大きな経験です。

――T.Y.さんはもともとサーバーやネットワークが専門で、そこからセキュリティの領域へキャリアを移したそうですね。 

T.Y.：前職で、インフラの部署からセキュリティの部署へ出向になったのが直接のきっかけです。

実際にやってみて気づいたのは、セキュリティは完全に独立した分野ではなく、ネットワークやサーバー、アプリケーションといった各IT領域に「どう関わるか」という話なんだな、ということでした。

――と、いいますと？

T.Y.：セキュリティを突き詰めると、自然と「攻撃者の視点」で物事を見るようになります。サイバー攻撃には、下調べから攻撃実行までの一連の流れ、いわゆる「サイバーキルチェーン」があります。

その攻撃者の目線で各IT領域を見ることで、日々のシステム設計や運用で気をつけるべきポイントが明確になる。セキュリティの領域に踏み込んだことで、視座が一段階も二段階も上がったと感じています。非常に面白い世界ですよ。 

「セキュリティ」と「利便性」の両立。特権管理IDの領域で広がる技術的視野

――セキュリティ領域にやりがいを見出しているのですね。SHIFTに入ってから、成長したと感じる点はどんなところですか？

T.Y.：技術的な視野の広がりです。特権ID管理の対象は、Windows OSやLinuxサーバーだけでなく、AWS（Amazon Web Services）やMicrosoft Azureのようなクラウドなど、本当に多岐にわたります。

当然、知らない製品を管理対象にしたいという要望も出てきます。 

そのたびに技術仕様を調べ、検証し、対応していく。つねに新しい知識やスキルを吸収できる環境なので、世の中の技術トレンドに触れながら成長しつづけられる実感があります。

先ほど「手を動かす」ことを大切にしていると話しましたが、セキュリティエンジニアには「探求心をもち、キャッチアップを怠らない」姿勢が重要だと思っています。

知らないキーワードや技術が出てきたら、自分が納得するまで手を動かして調べる。これはもう、私の軸になっています。

それから特権ID管理の領域では、「セキュリティ」と「利便性」の両立を追求することができます。

セキュリティを向上させつつ、定期的なパスワード変更やログインを自動化するなど利用者の手間を減らし、利便性を高めていく。

ただ、製品を導入するだけでは「セキュリティ」と「利便性」の両立は実現しません。

お客様の現場に深く入り込み、運用設計や教育支援まで踏み込むことで、はじめて本質的な改善が図れるのだと実感しています。

そこに自分自身の付加価値を発揮できる余地があり、課題に向き合うたびに、自分の成長を強く感じられる仕事です。

――これからT.Y.さんのチームに参加するメンバーに、この仕事の面白さを伝えるとしたら、どうアピールしますか？

T.Y.：先ほどお話しした「新しい技術に触れつづけられる」という点もそうですが、ベースとなるサーバーやネットワークといったインフラの知識が非常に重要になってくる点も面白いポイントです。

結局、特権ID管理システムと管理対象システムを「どうつなぐか」は、ネットワークやサーバーの世界です。

「つながらない」といったトラブルシューティングでも、この知識がないと手も足も出ません。

インフラの経験を深めたい人にも、これから身につけたい若手にとっても、成長機会が豊富にあると思います。

――最後に、T.Y.さんの今後の目標を教えてください。

T.Y.：2つあります。1つは、部内にあるほかの主力ソリューション、例えば「Splunk」のようなログ分析ツールと、私の専門である特権ID管理を掛け合わせた、より付加価値の高い提案をしていくことです。

2つ目は、人材育成です。最近、SHIFTには新卒やセキュリティ未経験の方々も多く入社してくれています。これは喜ばしい反面、どう育成していくかという課題もあります。

セキュリティは幅広いIT知識がベースになるため、未経験者には正直ハードルが高い面もあります。

そうした方々が早期にセキュリティ人材として立ちあがれるような、教育コンテンツの作成にも力を入れていきたいと考えています。

――ご自身の成長だけでなく、組織や後進の育成にも目を向けているのですね。本日は貴重なお話をありがとうございました！ 

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

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が公式に発表している構成があります。こちらの構成を選んだらどうなっていたのかという点は、こちらのスライドをご覧ください。

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

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