はじめに
こんにちは。クラウドネイティブでPMをしている、ひろき（ロッキー）です。
私はもともと情シスでキャリアを積んできました。そこからPMへ移ったのは、ビジネススキルをもっと伸ばしたかったからです。複雑な課題をチームで解きに行く、その一番前に立つPMという役割に惹かれて、2026年7月にこの会社へジョブチェンジしました。
とはいえ、まるきり畑違いに飛び込んだわけではありません。クラウドネイティブは、企業の情シスやセキュリティ領域を支援する会社です。情シスで培ったものが、そのまま土台として効く場所でした。PMとしてはまだ日が浅いものの、着実に前へ進めている手応えがあります。
というのも、情シスの日常業務には、もともとプロジェクトマネジメントの要素がたくさん詰まっていたからです。名前が変わっても、動き方の多くは変わっていません。情シスからの転身やキャリアの次を考えている方に向けて、その実感を具体的に書いてみます。
情シスの仕事は、プロジェクトマネジメントそのもの
情シスがやってきた施策を一つずつ思い返すと、どれも小さなプロジェクトでした。たとえば認証やデバイス管理の基盤を一つ入れるだけでも、なぜやるのかを整理し、現場や経営、関係部署、ベンダーを巻き込み、ほかの運用への影響を見ながら順番を決め、想定される事故に先回りして備え、現場に定着するところまで見届ける。基盤の更改も、内部監査への対応も、やることの骨格は変わりません。
情シスは規模の大小こそあれ、プロジェクトを回すことを日常業務として何度も反復してきた職種です。だからPMとして計画を立てたり、関係者と交渉したりする仕事に、まったくの初めてという感覚はほとんどありませんでした。ここからは、とくに地続きだと感じるところを、情シス時代の具体を交えて書いていきます。
納得で人を動かす
いちばん効いていると感じるのが、立場の違う人を巻き込んで前に進める力です。
情シスは社内を横断してかかわる一方で、他部門に指示を出す権限は持っていません。たとえば新しい認証基盤を入れようとしたとき、営業部からは『スマホからのアクセス手順が増えるのは困る！』と猛反発され、経営層からは『で、それはいくらコスト削減になるの？』と詰められる。同じ施策でも、刺さる理由は立場ごとにまるで違います。強制する力がないぶん、相手の関心に合わせて話す中身を組み替え、一人ひとりの懸念をつぶしながら合意形成してきました。
PMのプロジェクトでも、この構図はそのままでした。社内の各専門チームから集まったスペシャリスト、そしてお客様と、見ている景色も優先したいことも違う人たちが同じ場に並びます。ここで一方的に「こう決めました」と押しても、物事は前に進みません。それぞれの主張を一度テーブルに広げ、どこなら折り合えるかを一緒に探る。この進め方に抵抗なく入れるのは、権限で人は動かない、納得でしか動かないという原則を、情シス時代に数々の失敗と板挟みの中で、嫌というほど叩き込まれたからだと思います。
会議は始まる前に終わっている
情シスとPMで共通して効いているのが、会議に入る前の準備です。
私はいま、担当プロジェクトの計画とマイルストーンを組んでいます。経験者の知見も借りながら進めていますが、実際にやってみて効くと感じるのは、きれいな逆算の図を描くこと以上に、会議一つひとつの狙いを定める作業でした。社内の打ち合わせでは何を用意して話すのか。お客様との場では今回何を伝え、何を決めて帰るのか。そのために事前に固めておくべき論点は何で、自分が把握していないと話が止まる情報はどれか。ここを先回りして詰めておくかどうかで、会議が決める場になるか、ただの報告会で終わるかが分かれます。
情シス時代も同じでした。サービス導入の稟議を通すときは、経営がその場で判断できるように、コストや想定リスク、比較した代替案までそろえてから会議に臨む。あのころの準備の型を、いまもほぼそのまま使っています。
ツールは入れてからが本番
情シス時代は、サービスの比較検討から導入までも何度も回してきました。もっとも、クラウドネイティブでは製品や技術の選定は各エンジニアチームが担うので、この経験がそのまま活きるわけではありません。検討の話に多少ついていきやすい、くらいのものです。
情シスの経験が本当に効くのは、選定の先、導入のあとです。良かれと思って入れたツールが現場に嫌われ、結局使われずに元のやり方へ戻っていくというのは情シスなら一度は味わう苦い経験かもしれません。どれだけ技術的に正しくても、使う人が受け入れなければ意味がありません。この痛みを知っているので、お客様が製品を導入しようとする場面では、影響範囲の見立てや進め方について、伝えられることが頭に浮かんできます。まずは小さく始める、影響の大きい人を最初に巻き込む、変える理由を現場に先に伝えておく。導入後につまずきそうなポイントの懸念が先によぎるぶん、PMとしてアドバイスしやすいと感じている部分です。
やらないことを決めるのも仕事
情シスをやっていると、「それは情シスの仕事なのか」という線引きを日々迫られます。求められるまま何でも引き受けていると、本来やるべき改善に手が回らなくなる。だから、自分たちが担う範囲と担わない範囲を、理由つきで説明できるようにしておく必要があります。断るときも突き放すのではなく、なぜ範囲外なのか、代わりにどこが担うべきかまで示す。この線引きは、情シスでかなり鍛えられました。
やらないと決めること自体が仕事になる場面もあります。前職では、次の一手として検討していた仕組みを、費用対効果と会社のフェーズに照らして最終的に見送ったことがありました。魅力的な新しい仕組みほど「入れる前提」で話が進みがちですが、本当に必要かを冷静に見極めるのも情シスの役割でした。プロジェクトのスコープ管理もこれと同じで、範囲は放っておくと少しずつ広がります。最初に関係者と線を握り、増えてくる要望は「今回はここまで。それは別枠でこう扱う」と整理していく。削る判断ができて初めて、プロジェクトの輪郭が保てます。
トリアージ癖は抜けない
情シスは、インシデントや脆弱性に日常的に向き合う仕事です。次々に上がってくる事象すべてに同時対応はできないので、影響の大きさと緊急度で優先順位をつけ、いま何を止め、何は様子を見るかを判断していく。自分だけで抱えきれないものは、あらかじめ決めた基準で上位者に上げる。「全部はできない前提で捌く」姿勢が、情シスには染みついています。
プロジェクトで起きる課題やリスクへの向き合い方も、頭の使い方は変わりません。起こりうることを洗い出し、影響度と発生しやすさで並べ、先に手を打つものを選ぶ。問題が出てきたときに、自分で判断してよい範囲と、すぐ相談すべき範囲を切り分ける。大事なのは、慌てて全部に飛びつかないこと。何が起きても、まず優先順位に落とす。この癖だけは、職種が変わっても抜けそうにありません。
おわりに
こうして振り返ると、情シスの日常業務は、そのままプロジェクトマネジメントの実践だったのだと感じます。
PMになってまだ日は浅いですが、情シスで鍛えたものを頼りに、一つずつ前に進めています。もしあなたが情シスとして働いていて、キャリアの次に迷っているなら、その日々の経験は次の場所でも思っている以上に効いてくる、と伝えたいです。
こういう道もあると知ってもらえて、誰かの選択肢が一つ増えたなら嬉しいです。最後までお読みいただき、ありがとうございました。
