見出し画像

小説編

「ひとつ先の一歩を踏み出す」──そう口にしてみても、実際に足が前に出るかどうかはまた別の話だ。

大手金融グループのユーザー系IT企業でプロジェクトマネージャーを務める三浦亮介(32歳)も、まさにその一歩に悩んでいた。


三浦が所属する会社は、グループ内のITインフラやシステム開発を担当している。

一般的には“ユーザー系”と呼ばれ、ベンダーからの開発リソースを取りまとめたり、外部企業を管理しながらプロジェクトを進めたりするのが主な役割だ。

実際、三浦の業務は請求関連の手続きやスケジュール調整、そしてグループ内のユーザー部門からの問い合わせ対応といったところが中心だった。


もちろん、プロジェクトマネージャーとしての名目はある。

しかし三浦が実際に手を動かしているのは、どちらかと言えば「ベンダーの作業内容を管理し調整する」部分が大きい。

技術的な部分や詳細な設計はベンダーが得意とし、自分は“名目だけのPM”に近いのではないか──そのような後ろめたさを抱くようになったのは、ここ1年ほどだ。


そんなとき、会社として「内製化」を進める取り組みが正式にアナウンスされた。

これは、今までベンダーに一任していた開発フェーズやプロジェクトマネジメントの部分を、可能な限り自社のメンバーが担うように変革していく動きである。

会社の上層部は「リスキリング改革」という言葉を掲げ、社員の技術的知識やマネジメントスキルを強化するための研修や勉強会、さらにはプロジェクトへの実践配置を始めたのだ。

三浦も、その対象となるプロジェクトマネージャーの一人だった。




「三浦さん、今回のプロジェクトでは、コア部分の設計も僕たちがやる方向になるかもしれませんよ」

社内のキックオフ会議のあと、同僚の永田がそう声をかけてきた。

永田は同じ部署に属するSEで、これまでテストフェーズや運用検討など、比較的後工程の調整役を担ってきた。

しかし今回の内製化方針により、より上流の工程にもチャレンジすることになる。

「本当に大丈夫かなあ……。ベンダーの方が慣れているし、そもそも向こうの方が専門知識豊富じゃないか」

三浦が顔をしかめると、永田は苦笑しながら肩をすくめる。

「ま、上の方針だからね。とはいえ、自分たちで経験積むしかないし。会社として動いてる以上、サボれないよ。三浦さんはPMなんだし、一緒にがんばりましょうよ」

「……そうだな」

内心、不安は隠せなかった。

三浦はグループ会社のアプリケーション開発プロジェクトのPMを引き受けることになったが、実はまだ技術的なスキルにも自信がないし、本格的なプロジェクトマネジメントも習得途中という自覚があった。




「それでは、今回のプロジェクトの進め方について整理しましょう」

大きなプロジェクターの前で、コンサルタントの鬼頭が説明を始めた。

この日はリスキリング改革の一環として、外部のコンサルタントが主催する学習会が社内で開かれている。

各チームから選抜されたメンバーが参加していて、三浦も当然その一人だ。

鬼頭がスクリーンに映し出したのは「PMBOK(Project Management Body of Knowledge)」の一部に準じたフレームワークと、アジャイル的アプローチを組み合わせたプロセスの図表だった。

三浦はプロジェクトマネージャーとしてその図をじっと見つめる。

「計画」「実行」「監視・コントロール」「終了」という四つのフェーズに分割されてはいるが、それらをアジャイルの反復的な手法で回すイメージが描かれている。

「このプロジェクト、ウォーターフォールでやるんじゃないんですか?」

参加者の一人が手を挙げて尋ねると、鬼頭は静かにうなずいた。

「基本はウォーターフォールで進めることになるでしょう。

ただ、要件定義の中身が複雑になると見込んでおり、途中でユーザー部門の変更要望が頻発する可能性があります。

ですから、各イテレーションを短く区切り、フィードバックを早期に反映できるようアジャイル的に進めていくのが望ましいという話です。

もちろん、最初からすべてを自社でやるのは難しい面もありますから、ベンダーの力を借りながら、段階的に内製化を進めるのが現実的でしょう」

三浦はふと、自分がベンダー管理だけで回していた頃を思い出す。

当時、仕様変更に伴うタスクの整理やスケジュール再調整などを、ベンダー任せにしてしまっていた部分が大きい。

しかし今回の方針では、それを自分たちの手で主導していかねばならない。

要件をまとめ、変更管理を行い、ユーザー部門への調整を行い、場合によってはコスト試算まで……。思わず冷や汗がにじむが、同時に「いつかは身につけなければならないスキルなんだろうな」と自覚する。




プロジェクトが本格的に始動すると、早速さまざまな課題が噴出した。

「何でこんなに時間かかってるんだ!」

ユーザー部門の担当課長から怒りの連絡が入り、三浦はそれを黙って受けるしかなかった。

実際、要件定義のヒアリングで見落としていた箇所が見つかり、設計フェーズの途中で大きな仕様変更が発生したのだ。

その変更を踏まえてスケジュールを練り直すことになったが、各ステークホルダーとの調整が難航し、結果的に予定よりも二週間以上の遅れが出てしまった。

「すみません。こちらとしても急いで対応しますが、追加機能が大きく、想定外の工数がどうしても発生してしまって……」

電話越しに何度も頭を下げ、ひたすら説明するしかない。ベンダーに投げてしまえば簡単かもしれないが、今回のプロジェクト方針としては自分たちが主体的に動くことになっている。

むしろ、こういう場面でベンダーとの連携や、負荷のかかるタスク分担を的確に行うのが三浦の役割のはずだ。

だが、実際のところスケジュールの再編成や工数見積もりの算出は、まだ慣れていない。

協力ベンダーに頼らざるを得ない場面が多く、そこで頼りっぱなしになってしまう自分に苛立ちを覚えることもあった。




そんな三浦をフォローしてくれたのは、ベンダー側のリードエンジニアである北見だった。

彼は「先生役」として会社がアサインしてくれたコーチでもある。

北見は開発歴15年という筋金入りのエンジニアで、同時にプロジェクトリーダーの経験も豊富だ。

専門的なプログラミング知識だけでなく、PMBOKの知識やアジャイル開発の経験もある。

今回のプロジェクトでベンダーとの懸け橋となってくれる存在だ。

「三浦さん、要件定義の見直しのポイントは、実際の業務フローをどれだけ具体的に可視化しているか、ですよ。これが曖昧だと、あとから仕様変更が来るのは当然です」

北見はミーティングの合間を見て、しきりに三浦にアドバイスしてくれる。

「でも、なかなかユーザー部門も時間を取ってくれなくて……」

「そこは調整術ですよ。『あなたたちが困る前に、今一緒に詰めましょう』って強気に出ることも必要。プロマネは気配りだけじゃなく、時に強権を発動して物事を進めるスキルも必要です」

三浦は「なるほど……」と思いつつも、自分にそんな強気が通用するのかという不安が拭えない。

そもそも、ユーザー部門から頼られる存在になれていないのだ。

さらに言えば社内では歴も浅く、気を張っていてもどこかで「ベンダーに頼るのが当たり前」という意識が抜けきらない。

とはいえ、北見の言うことは筋が通っている。

三浦は必死にメモを取りながら、少しずつ実践に移していった。




プロジェクトは一進一退を繰り返す。

ユーザーからの問い合わせや要望は尽きることがなく、スケジュール管理にも常に綱渡りのような緊張感がある。

しかし、会社として内製化の学習と実践を進める以上、逃げる選択肢はない。

三浦はなんとかプロジェクトを回すために、勉強会や社内ワークショップにも積極的に参加するようになった。


ある日の夜、三浦は自席に残ってPMBOKのテキストを読み返していた。

「スコープ管理」「リスク管理」「ステークホルダー管理」──どれも耳慣れた言葉ではあるが、改めて定義や手順をじっくり読むと、自分がこれまでいかに感覚的にプロジェクトを動かしていたかを痛感する。

「決して間違ったわけじゃないんだろうけど、体系立てて理解してなかったな……

疑問が出るたびに、参考書やネットの情報を参照し、翌日の朝一で北見に相談する。

そうすると北見はポイントをかいつまんで教えてくれたり、過去プロジェクトでの具体的な事例を挙げてくれたりして、三浦の理解を深めてくれた。

「PMBOK的にはそうなるんだけど、実際の現場ではこういうアプローチもあるよ」と北見は柔軟な思考を示す。

例えば、すべてのプロセスを厳密にやるのではなく、重要度の高いプロセスを優先して最初に定義し、細かい部分は後から補完していくやり方もあるという。

「要は、理論と実践をうまくつないでいくことが大事なんです。わかっていても、実際にできないというのはよくある話ですから」

ユーザー部門からのクレームは依然として続いたが、プロジェクトの中盤に差し掛かった頃には、三浦も少しずつうまく立ち回れるようになっていた。

ひとつは、ステークホルダーとのコミュニケーションを以前より丁寧にやるようにしたことだ。

会議に臨む前にアジェンダを明確にし、確認しておくべき事項や想定されるリスクをあらかじめ洗い出しておく。

その上で、ユーザー部門や関連部署に「この部分について意見をもらいたい」「ここで合意しておきたい」と伝えておくことで、無駄なトラブルを減らせるようになった。


「三浦さん、最近は何だかしっかり仕切ってるじゃないですか。前より落ち着いて対応してる気がしますよ」

永田が席を立ちながら、にやりと笑う。

そう言われると、三浦は少し照れくさい気持ちになるが、同時にどこか心強さも感じる。

「まあ、そう見えるならよかった。実際はドタバタだけどね」

「でも、やっぱり経験してみると違いますね。ユーザーからの要望を直接聞いて、そのままベンダーに振るんじゃなくて、こっちで整理してから渡すだけで全然トラブルが減るんだって、実感しましたよ」

永田の言葉に三浦は大きくうなずく。

実際、要望や変更点をすぐベンダーに丸投げしていたころは、ベンダー側の作業遅延や仕様誤解がたびたび起こっていた。

それが、こちらで主導して要件を整理し、優先度やリスクを見定めたうえでリクエストを出すように変えただけで、ずいぶんスムーズに回り始めたのだ。




もっとも、大きな山場はまだ先にあった。実装フェーズ中に大幅な仕様見直しが必要になるという話が、ユーザー部門の上層部から突然降ってきたのである。

「うちの部門長が、このタイミングで見直しを指示してきて……。ユーザーインターフェースのデザインとか、ワークフローの分岐条件など、根本的に変えてほしいらしいんです」

ユーザー担当の課長が頭を下げる。三浦はため息をつきたいところを必死に抑える。

「開発も後半に差しかかっているので、あまり大きな変更は難しいんですが……。ただ、会社としてやる以上はできるだけ対応しなきゃいけませんね」

社内会議で三浦がそう告げると、北見も表情を曇らせながら「工数としてはかなり厳しい」と肩を落とす。

とはいえ、断るわけにもいかない。

プロジェクトマネージャーとしては、まず変更を受けて何がどれだけ影響を受けるかを明確化し、工数やコスト、スケジュール再調整の方法をユーザーと合意しなければならない。

「僕が対応します。まずは変更点を全部洗い出して、インパクト分析の資料を作ります。北見さん、開発チームの方々と連携して、技術的に何がどれだけ追加になるかまとめてもらえますか」

「ああ、わかりました」

やるべきことは山ほどある。

けれど、以前の自分だったら、ただただ焦って右往左往していただろう。

今回は、体系立てて進めるための知識もあるし、何より北見と同僚の永田をはじめとするチームの協力体制がある。

三浦は心持ちを切り替え、一つひとつタスクを具体化していく。


まず三浦は、ユーザー部門と合同で「どこがどのように変わるのか」のリストを作成した。

画面構成の大幅変更や、業務フロー内での承認ルート再編成が含まれることがわかり、影響範囲がかなり広いことが判明した。

そこで、北見に相談しながら想定される工数をざっと算出し、元のスケジュールに対する差異を見える化する。

「結果として、あと二か月は工期が延びる計算になります。コスト増についても、これまでのベンダー契約に追加の発注が必要です」

「二か月……。さすがに延びますね」

ユーザー担当課長が眉をひそめる。

だが、変更を受け入れるのであればやむを得ない。

ここで大事なのは、その事実を明確に示し、説明したうえで“合意”を取ることだ。

三浦は自分でも驚くくらい冷静な口調で、課長や部門長にリスクと対策案を示していく。

先回りする形で、「仮にさらに仕様追加が出る場合は、今回のようにまたスケジュール全体を見直さなければなりません」と釘を刺しておくことも忘れない。

結果として、仕様変更の要望は少し縮小された形で承認され、追加で一か月の延長と予算を捻出する形で決着がついた。

もちろん、予定通りにはいかなかったし、負担が増えることに変わりはない。

それでも、「どれだけの追加コストや工期が必要か」を明確化したことで、ユーザー部門との衝突は最小限に抑えられたのだ。

北見は会議室から出てきた三浦にそっと声をかける。

「いやあ、最初に一緒にやった頃とは比べものにならないくらい、PMっぽくなりましたね。ちゃんと状況を整理して、ユーザー側とも腹を割った話をしてくれた」

三浦は照れ笑いを浮かべながらも、内心は達成感で満たされていた。こうやってプロジェクトを回していくのだと、身をもって理解できたのは大きい。自分が前に進んでいることが、うっすらと確信に変わりつつある。




プロジェクトも最終段階に近づくと、テストフェーズからUAT(User Acceptance Test)に至るまでの工程は社内メンバーが大きく関わる形で進められた。

当然、バグが出たり、ユーザーから更なる微修正の依頼が来たりして、決して楽ではなかった。

しかし、三浦は「問題が起きるのはむしろ当たり前。それをどう解決するかが重要だ」と考え方を切り替えていた。

リリース予定日の前日。三浦は何とかすべての工程をやり切った報告を受け、ホッと胸をなでおろす。

もちろん、これでゴールではなく、運用フェーズに入ってからも微調整や追加対応が待っている。

しかし、今回のプロジェクトが無事に大きなトラブルなくリリースまでこぎつけられたのは、三浦にとって確かな自信となった。

リリース後の打ち上げの席で、ユーザー部門の課長や開発に協力してくれたベンダーのメンバーが口々に「お疲れ様でした」と声をかけてくる。

その中で、北見が静かに三浦に近づき、グラスを軽く合わせた。

「今回は本当に色々あったけど、お疲れさまでした。三浦さん、ちゃんと内製化のPMになりつつあるよ」

「いえいえ、まだまだ北見さんたちに助けてもらってばかりです。これからが本番というか、もっと技術も学ばないといけませんし」

三浦の言葉に北見は笑みを深める。

「そういう姿勢が大事なんですよ。プロジェクトマネジメントって、正解がひとつじゃないし、技術も常に進化していく。学びを止めたらすぐに取り残される世界だから、これからも頑張っていきましょう」

「はい……!」

三浦はグラスを握る手に力を込め、北見に頭を下げる。

自分はまだ道半ばだ。それでも、ベンダーにただ頼るだけではなく、イニシアチブを取りながらプロジェクトを動かす経験が積めたことは大きな成果だと思う。

リスキリング改革という会社の方針には戸惑いもあったが、今はむしろ感謝の気持ちが生まれ始めていた。

仲間とともに歩んだこのプロジェクトを通じて見えたのは、単なる技術やスキルではない。

それを活かして、関わる人たちとどうコミュニケーションを取り、どうゴールに向かって進んでいくか──それこそが、本当のプロジェクトマネジメントの醍醐味なのだろう。

三浦はもう一度グラスを口に運び、空を見上げる。

次のプロジェクトはきっと今回よりもさらに複雑で、ハードなものになるかもしれない。

しかし、何とかなる。そう思えるだけの「自分の力」を、今回のリスキリングへの挑戦によって少しずつ手にしつつあるのだから。

彼の物語はここで一旦の区切りを迎える。

しかし、この先も挑戦の日々は続く。時には失敗もあるだろう。

けれど、そのたびに学びと成長を重ねながら、三浦は“真のPM”への道を歩み続けるに違いない。

その足取りは、今までよりもずっと力強く、そして確かなものになっていた。


解説編

プロジェクトマネージャーとしての苦悩や成長の内容を解説しながら、ユーザー系IT企業がリスキリング改革に取り組む際に、人事部門がどのような支援や制度を整備すべきかを考えてみます。


物語のあらすじとリスキリングの必要性

物語の主人公は、大手金融グループのユーザー系IT企業で働く三浦亮介。

形式上はプロジェクトマネージャーを名乗りながらも、実態はベンダー企業の進捗管理と外部手配が中心で、技術的なスキルや本質的なマネジメント経験は不足しているという現状でした。

しかし会社の方針として「内製化」を進めることが決まり、これまでベンダー任せにしていた設計・開発やプロジェクト運営の核心部分を、自社の社員が担う試みが始まります。

三浦は戸惑いながらも、外部コンサルタントが主催する学習会やベンダーの“先生役”によるコーチングなどを通じ、少しずつプロジェクトマネジメントの真髄を学んでいくストーリーです。


なぜリスキリングが必要なのか

ユーザー系IT企業では、長年にわたり「自社は要件をまとめる」「ベンダーは開発と技術的な判断を行う」という分業体制が常態化してきました。

その結果、ユーザー系社員は業務調整スキルはあるものの、技術力や実践的なPMスキルの習得が遅れやすいという課題が指摘されがちです。

一方で、近年のDX(デジタルトランスフォーメーション)ブームや、IT技術の進化スピードの加速により、ユーザー系企業にも高度なIT知識やアジャイル開発などの新手法を理解する人材が求められています。

こうした背景から、従来の“外に丸投げ”ではなく、戦略的に内製化を進め、自社内で技術・マネジメント両面の蓄積を図るリスキリング改革が注目されています。


小説に見るリスキリングの進め方とポイント


学習会や研修プログラムの活用

作中では、外部コンサルタントが主催する学習会に主人公が参加し、PMBOK(Project Management Body of Knowledge)の基本や、アジャイル開発の考え方を学んでいました。

これは内製化への移行期によくあるケースです。

技術的な内容やマネジメント手法を、体系立てて学ぶ機会を提供し、そのうえで現場で実践できる場を用意する──この流れが人材育成に有効といえます。


ベンダーの“先生役”との伴走

小説では、ベンダー側のリードエンジニア(北見)が“コーチ”として主人公を支援しています。

これによって、座学だけでは学びきれない“現場ならではのノウハウ”や“ユーザーとの折衝のコツ”が身につきやすくなりました。

OJT(On-the-Job Training)の一種として、外部協力会社と協力しながら社員を育てる仕組みは非常に現実的です。

単発の研修ではなく、プロジェクト実務を通して育成するところに効果が期待できます。


小さな成功体験とステークホルダーとの合意形成

物語後半では、主人公が要件変更を受けてスケジュールや予算を再調整する過程を主導し、ユーザー部門と合意を得てプロジェクトを進める様子が描かれます。

これは“問題が起きても逃げずに適切なプロセスで対処する”というプロジェクトマネジメントの核となる部分。

三浦が最初は不慣れだったコミュニケーションや調整に苦戦しながらも、学んだ知識をもとに整理・提案してユーザーを納得させることで、「自分でもやれる」という実感が生まれ、モチベーションと実力が高まっていきました。


ユーザー系IT企業の人事部門が整えるべき支援・制度

物語の主人公が経験したプロセスを踏まえると、リスキリングを成功させるためには人事部門が積極的に以下のような施策を用意する必要があります。


段階的かつ継続的な学習プログラム

  • 基礎研修の充実
    PMBOKやアジャイル、クラウド基盤などの基礎を学べる研修機会を継続的に提供。入門レベルから中級・上級へステップを設定し、受講後のフォローや実務での活用を支援する。

  • 勉強会やワークショップの促進
    社員同士で学び合う勉強会を定期開催し、講師には社内外から専門家を招く。小説中でも、主人公が社内の学習会で刺激を受け、プロジェクトで試行錯誤しながら成長していく様子が描かれています。


メンター・コーチ制度の導入

  • ベンダーとの協業によるOJT
    小説で描かれているように、実際のプロジェクトに“先生役”をアサインし、現場で学べる環境を整備。最初のうちはベンダーが主導する領域が多くても、徐々に内製メンバーに任せる部分を拡大していく方針が効果的です。

  • 社内メンター制度
    社内に豊富な知識や経験を持つSEやPMがいる場合、メンター役として若手PMやエンジニアを指導する体制を構築する。コーチング手法を活用し、対話型で問題点を発見・解決へ導くと、社員のスキルアップが加速します。


キャリアパス再設計と評価指標の見直し

  • キャリア形成のビジョン提示
    これまでユーザー系IT企業では、プロジェクトの上流管理だけ行うキャリアパスが一般的でした。
    しかし内製化の推進により、アーキテクト的な専門知識や、アジャイル型のPMスキルが高い人材が求められます。
    企業としてどのようなキャリアを描くことができるのかビジョンを明示することで、社員の学習意欲を高められます。

  • 成果・学習過程を評価する仕組み
    従来の「プロジェクトが予定通り完了すればOK」という評価だけでは、内製化や新しいスキル習得に挑む意欲を後押ししきれない場合があります。
    新技術へのチャレンジや学習そのものを一定の評価項目として取り入れ、成果だけでなく成長過程を認める制度設計が求められます。


社外連携や情報交換の場づくり

  • コミュニティ形成の支援
    他社との情報共有や勉強会など、社外コミュニティに積極的に参加できるよう、人事部門が制度面で後押しすることも大切です。
    外部の専門家や先行企業の事例に触れることで、内製化や新しい開発手法の知見を取り込めるようになります。

  • 外部講師・コンサルタントの活用
    小説では外部コンサルタントが指導役として登場。自社メンバーだけではまかなえない知識や経験を、外部専門家に補ってもらうケースは今後も増えるでしょう。
    人事部門はこのような外部リソースを使いやすい契約形態や予算枠を整備し、現場と連携して活用を進められるようにするのが望ましいです。


「やらされる」のではなく「主体的に学ぶ」環境づくりへ

小説の主人公は、当初は“会社が決めたリスキリング改革”に戸惑っていました。

しかし、実際にプロジェクトの中で学んだ知識を活かし、成功と失敗を繰り返して小さな成果を積み上げることで、最終的には自ら成長を実感していきます。

リスキリングの取り組みは、単なる研修や座学だけでは完結しません。業務のなかで学んだことを素早く試し、小さな成功体験を積み重ねるところが肝心です。

つまり、人事部門ができる大きな仕事は「社員が主体的に学び、実践し、仲間と支え合う環境をつくる」ことにあります。


  • 学習機会の整備

  • メンター制度やOJTでの実務支援

  • 評価・キャリアパス設計の見直し

  • 社外とのネットワークづくり


これらを総合的にデザインし、「学んだだけで終わらない」仕掛けを社内に根付かせることが重要です。

ユーザー系IT企業には、「要件をベンダーに伝えるだけ」という状況から脱し、技術とマネジメントの両輪でイニシアチブを取れる人材を育てる絶好のチャンスが巡ってきています。

人事部門としては、こうした物語から学んだポイントを踏まえ、一人ひとりの社員が「自分から学ぼう」と思える場や仕組みを作っていくことが、リスキリング成功のカギとなります。

※本小説はフィクションです。実在の人物や団体とは関係ありません



最後まで読んでいただき、ありがとうございます。

自社で、リスキリングやIT人材・デジタル人材育成の検討にお悩みの方は、お気軽にお問合せくださいませ。

www.linkedin.com/in/翔-小出-a921642a9


いいなと思ったら応援しよう!