お疲れさまです。インフラチームの山口です。
新型コロナウィルスの影響下でのリモートワークに伴い最近社内でいくつかのVPNアプライアンスのPoCを実施したのでその際に考えたことや振り返ってこうしておくべきだったという内容を戒めとして各フェーズに沿ってエッセイとして記載します。 なお、現在進行系で数種の製品のPoC中のため、「何か特定の製品を使ってうまくいった」や「弊社はこうしている」などの情報は何もない、私が感じたチラシの裏的なレポートになります。
要は、技術的に新規性のあることはない内容ですが、同じような問題意識を持ってる人間に届けばいいなといった感じの文章になります(文章でもなんでも刺さる人にだけ刺さればいいというポリシーなので、そういった感じです)。
本稿の構成を以下に記載します。
まず、筆者の経歴および、前提条件を説明します。 次に、製品選定や実際のPoC準備から実施までに考えたことを記載します。 そして、最後に感想をまとめます。
筆者の経歴
前職は以下の感じの業務に従事しており、お客様のネットワーク構築やビデオ会議の導入などをしていました。
- 顧客のNW(主にWAN)構築・運用(所謂ネットワークエンジニア)
- ビデオ会議の端末やサーバの導入・運用など(これは何エンジニアなのか適切な表現は思いつかない)
その後弊社に転職して今に至ります。
要は、法人のお客様にベンダーのアプライアンス製品を導入したりする仕事をしている人の気持や挙動は薄々イメージつくといった感じになります。 前職では、企業の情シスの方が主に対面となる顧客の形でした。
が、今回のPoCでは、どちらかというと企業の情シスに近い動きをしており、立場変わると見え方変わるなというのを感じています。 その一方で、再販のベンダーさんが英語の資料ベースにパワーポイントなどでまとめられた日本語の手順書などいただくと、「こういう類作るの面倒だよね(困ったら英語の一次資料頑張って読むけど、利用者としては日本語でアウトラインまとめられているのはありがたい)」という気持ちもあったりして日々勉強させて頂いています。
前提条件
本稿全体の前提にかかる弊社の現状について開示可能な範囲で簡単に箇条書きで記載します。 今回のPoCについては基本的に情シスと協力して進めるという形を取っています。
- 社員数
- 150人強(業務委託の方なども含む)
- 人員の構成
- 情シス: 2名
- 社内NWや社内のPC/社内で利用する外部サービスの管理など
- インフラ: 7名
- 自社サービスのインフラ部分を担当
- 当初は情シスワークもインフラで実施していたが、専任の情シス担当者着任に伴い移管したという経緯がある
- 情シス・インフラは部署としては別ライン(会社でよくある構成だと思いますが、情シスは人事総務系の所属・インフラはエンジニア部門の所属)
- 情シス: 2名
- NW構成と運用
- 問題意識
製品の選定
製品の選定の際に考えたことを記載します。
まず、選択肢として、ベンダーの提供している製品を使うか、自分たちでOSSをベースに構築するかがあると思います。
弊社の状況としては、OSSなどを組み合わせて自分たちで独自に構築して運用する工数を取ることは避けたかったため、ベンダーの製品を選択する形を取りました。 また、ベンダーという単語は本稿では、サービスや製品を提供している企業と、その製品の代理店をなんとなく指す意味合いで使います。
- OSSを組み合わせて構築する
- ベンダーの製品を使用する
次に、製品を選ぶ際に考えた点を以下に記載します。 以下に明示的に記載はしていませんが、コストも気にはします。
- 利用者の観点で設定が簡単か
- VPNの設定のサポートが辛いという問題を解消したいのでこれは重要。
- 端末のアップリンクでのポートの遮断などに対応可能か
- 要は、リモートワーク時のご自宅のNWなどでポートが遮断されている場合はTCP:443などにフォールバックしてつながってくれるような製品かどうか。
- リモートワークの際に、社内のメンバーのご自宅のNW機器の設定起因と思われるトラブルに対して、会社としてどこまで手を出すかは悩ましいところなので極力robustに動いてくれる製品が良い。
- 前職なら「お客様責任のお客様機器」なので設定変更はご法度的な箇所を、製品の型番教えてもらいマニュアル読みつつ影響なく問題を回避する方法を調べ対応するのは面白くもあるが、しくじったときにお互いに辛い。
- が、まあ最近の製品は、おおよそフォールバックして通信してくれるのでそこまで気にする必要は実際無い印象。
- PoCや導入に際し既存への通信影響がなく、可能であればNW構成も変更せず利用可能なこと
- サポート体制
- 英語での問い合わせでも良いですが、辛いので可能であれば日本語でサポートが受けられるのが望ましい。
- 息が長い製品であるかどうか
- 要は、ベンダー都合でEOS(End of Support もしくは End of Service)にすぐならなさそうか。
- これは前職でベンダーの日本法人がなくなったり、EoSに伴う後継の製品への置き換えが辛かったりというケースがあったので少し気にしました。
- が、根本的に利用者側としては回避する方法はないので頭に留めておく程度。
PoC準備
次に社内PoCの準備に際して考えたことを記載します。
- 事前に製品の検証をしておく
- 社内でPoCの依頼をする前に、事前に製品の挙動などの検証をしておきます。
- 社内のメンバーに使ってもらう状態になると気軽に設定変えて試験といった形が難しくなるため事前に気になる点は検証をしておくのが望ましい。
- 協力を依頼する部署に事前にお願いしておく
- 会社の規模にもよるとは思いますが、流石に昨日の今日で社内の各部署に「明日から社内PoCやるんで協力よろしく」は避けたいので、事前に協力を依頼したいメンバーをリストアップし、上長含めて事前にご協力のお願いを出すという形にしました。
- 各部門で数人ずつ協力していただき、概ね漏れがないような人選としました。
- 各種手順の準備
- インストール/アンイストール/トラブルシュートの手順は事前に準備しておきます。
- 準備しておけばおくだけ、後が楽になるため注力しておいた方が良いと思いますが、後から漏れなどが出てくるので実際社内PoCの間にも追加で準備したりしていました。
- ローカル開発環境でも影響が無いか
PoC実施&評価
PoC実施中から評価の際に考えた内容を列挙します。 実施する状態になったらやりきるしかなくて、どれだけ事前に準備して問題潰しておくかだなと言うのが正直な印象です。
- PoC中はPoCに対する問い合わせ対応を最優先にする
- 社内PoC中はPoCに関連する問い合わせの対応を最優先にするよう事前に自分の持っているタスクの段取りなどを調整していました。
- PoC実施中にうまくいかないケースがあったら問題判別を強行しない
- PoCしてもらっているメンバーからうまく動かないなどの問い合わせがあった場合、長時間に渡る可能性がある問題判別は極力避けるようにしました。
- これは、社内PoCに協力いただいていること起因で、既存の業務に影響が出てしまうのは本意ではないため、うまくいかない点の解消がすぐできなそうなら、既存のVPNに切り戻して業務継続していただくような形です。
- 評価方法
- 複数製品を評価する場合何らかの形で数字に落として比較できると嬉しいので、PoCに協力していただいたメンバーにアンケート取る形にした。
まとめ(というか感想)
まとめというか感想なのですが、社内の利用者・情シス・インフラ・再販事業者・製品ベンダーなど立場が変わると見え方も変わると思いますが、それぞれの立場でみんな幸せになる形で、構成を改善していけるといいなという気持ちです。