どうも おかしん です。
この記事は、クラウドネイティブの会社紹介連載「クラウドネイティブの仕事とセクションを知る」の一部です。会社全体の考え方や各セクションの記事一覧は、ハブページからご覧ください。
クラウドネイティブの主要サービスは、情報システムコンサルティングです。
ただ、「コンサルティング」と言っても、人によって想像するものがかなり違います。製品選定のアドバイスだけをするのか、設計書を書くのか、構築までやるのか、運用の相談にも乗るのか。この記事では、クラウドネイティブのコンサルティングが通常どのような仕事なのかを整理します。
製品を売ることが目的ではない
クラウドネイティブのコンサルティングで大事にしているのは、製品を目的にしないことです。
IDaaS、MDM、EDR、SASE、グループウェア、コラボレーションツールなど、扱う製品はたくさんあります。ただし、どの製品を入れるかは、あくまで課題を解くための手段です。同じ業種、同じ規模の会社でも、業務プロセス、既存環境、運用体制、リスク許容度は違います。他社でうまくいった構成をそのまま持ち込んでも、自社の現場で動くとは限りません。
だから私たちは、最初に「どの製品を入れますか」ではなく、「何に困っていて、何を変えたいのか」から入ります。
代表的なメニューに、グランドデザイン策定がある
クラウドネイティブのコンサルティングの代表的なメニューのひとつに、グランドデザイン策定があります。
ここでいうグランドデザインは、「どの製品を入れるか」の一覧ではありません。現状の構成、業務、データ、運用、課題を整理したうえで、これから目指す情報システム基盤の全体像を描く仕事です。
たとえば、次期IT基盤をどうするか、ゼロトラストをどう進めるか、IDや端末管理をどう統合するか、SaaSやデータの利用をどう安全にするか。こうした論点を、個別の製品や部門ごとの都合だけで決めると、どうしても部分最適になりがちです。
グランドデザイン策定では、最初に大きな絵を作ります。ただし、それはきれいな理想図を作るためではありません。現状から実装可能なTo-Beへ進むために、課題、打ち手、順序、費用感、運用の持ち方を関係者が同じ目線で議論できるようにするためです。
As-Isを作る
グランドデザイン策定では、まずAs-Is、つまり現状を整理します。
プロジェクトでは、まずスコープとスケジュールを確認します。そのうえで、現状の業務、システム、運用、課題をヒアリングします。
たとえば、次のような問いを一緒に整理します。
- 今のID管理は、入社、異動、退職に追従できているか
- 端末は誰が、どの状態で、どのように管理しているか
- セキュリティ製品のアラートは、見て終わりになっていないか
- SaaSの管理者権限やデータ共有は、現実的に統制できているか
- 情シスだけで運用し続けられる仕組みになっているか
この段階では、構成図、業務フロー、既存資料、台帳、ヒアリング結果、ワーキングシートなどを見ながら、いま何がどこにつながっているのかを整理します。重要なのは、現状を責めることではありません。見えていない依存関係や、運用で吸収されている無理を見える形にすることです。
情報の流通経路を見る
グランドデザインでは、システム構成だけでなく、情報がどこにあり、どこを通り、誰に渡っているのかも見ます。
クラウドネイティブでは、必要に応じてデータの分類と流通経路を整理します。どのデータが重要なのか、どのSaaSやストレージに保存されるのか、社外共有やダウンロードはどこで発生するのか、個人利用のSaaSや管理外の経路に流れうるのか。こうした点を確認します。
これはCASBのような製品を選ぶためだけの作業ではありません。どの情報を守りたいのか、どの共有は業務上必要なのか、どこに制御を入れると利用者の生産性を落としすぎずにリスクを下げられるのかを考えるための材料です。
この考え方は、ゼロトラストの基本思想にもつながります。社内か社外かだけで判断するのではなく、利用者、端末、SaaS、データ、操作、ログを組み合わせて見る必要があります。
Fit&Gapで打ち手を考える
As-Isと情報の流れが見えてきたら、次はFit&Gapを見ます。
Fit&Gapでは、現状のやり方で維持できるものと、理想状態に対して足りないものを分けます。既存の仕組みを活かせるなら活かします。一方で、ID管理が分散している、端末の期待状態を説明できない、ログはあるが追跡できない、重要データの外部流通を制御できない、といったギャップがあれば、そこに対する打ち手を考えます。
ここでも、製品から議論することはありません。ある課題に対して、製品導入が必要な場合もあれば、既存設定の見直し、運用フローの変更、台帳整備、権限設計、利用者向けルールの整理で進められる場合もあります。
ここで大事なのは、理想論だけを描かないことです。高機能な製品や厳格なルールを並べても、運用できなければ意味がありません。会社の規模、体制、成熟度、利用者の業務を見ながら、現実的に進められる理想像を作ることを心がけています。
ロードマップに落とし込む
理想像が見えてきたら、いきなり全部を変えるのではなく、段階を切ります。
先にIDの土台を整えるべきなのか、端末管理を先に固めるべきなのか、EDRやSASEの運用を見直すべきなのか。あるいは、今は製品導入よりも、棚卸し、ルール整備、運用フロー作成を優先すべきなのか。
クラウドネイティブのコンサルティングでは、こうした判断を、お客様と一緒にロードマップへ落とし込んでいきます。ロードマップは、絵に描いた大構想ではなく、「次に何を決めるか」「誰が何をやるか」「どの状態になったら次へ進むか」を判断できるものにする必要があります。
グランドデザイン策定の成果物には、プロジェクトの背景、As-Is分析、課題分類、To-Be構成、ソリューションの選定理由、課題と打ち手の対応、実装に向けたロードマップ、必要に応じたライセンスや費用の概算などが含まれます。
これは納品資料として閉じるためのものではなく、次の意思決定に進むための資料です。経営、情報システム部門、セキュリティ部門、利用部門、構築ベンダーなど、関係者が同じ前提で話せるようにすることが大事です。
導入支援や運用支援につながる
コンサルティングの結果、具体的な製品導入や設定変更が必要になることもあります。その場合は、製品導入・実装支援につながります。
また、導入後に日常的な相談や運用改善が必要になることもあります。その場合は、Q&Aサポート、情シス運用支援、複数領域をまとめて支援するProfessional Support Serviceのような形で継続伴走します。
つまり、コンサルティングは単独で完結する相談メニューというより、相談、設計、導入、運用定着をつなぐ起点です。
エンジニアが直接向き合う
クラウドネイティブの特徴のひとつは、エンジニアが直接お客様と話すことです。
もちろんプロジェクトマネージャーやセールスも関わりますが、技術的な論点を抽象的な伝言ゲームにしないよう、実際に設計し、検証し、導入や運用を知っているメンバーが議論に入ります。定例会では、現状ヒアリング、ToBe構成のすり合わせ、製品選定、タスク確認などを行い、必要に応じて分科会やハンズオンも実施します。
社内側では、Asanaでタスクを可視化し、デイリーや社内打ち合わせでプロジェクトを前に進めます。お客様との定例だけでなく、社内での認識合わせやナレッジ共有も重要な仕事です。
相談したい方へ
クラウドネイティブへの相談は、「この製品を入れたい」と決まっている場合だけではありません。
むしろ、「何から手をつければいいか分からない」「今の構成が本当に正しいのか不安」「運用が属人化している」「ゼロトラストと言われても自社では何をすべきか分からない」といった状態から始まることも多いです。
その状態を一緒に整理し、自社で判断し続けられる形にしていくこと。それが、クラウドネイティブのコンサルティングです。
募集中の職種
クラウドネイティブのコンサルティングに関わる仕事に興味がある方は、まずは募集一覧をご覧ください。技術領域では、クラウドエンジニア、IDaaSエンジニア、セキュリティエンジニア、デバイススペシャリストなどの募集があります。
どの職種が近いか迷う場合は、カジュアル面談から相談してもらっても大丈夫です。
一緒に働きたい方へ
コンサルティングの仕事では、技術力だけでなく、相手の状況を聞く力、課題を構造化する力、現実的な落とし所を考える力が必要です。
ID、デバイス、セキュリティ、SaaS、開発、運用支援など、得意領域は人によって違って構いません。ただ、どの領域でも共通しているのは、お客様が自走できる状態を目指すことです。この連載では、次回以降、各セクションの仕事をもう少し具体的に紹介していきます。
