はじめに

2024年7月にJMDCに入社し、プロジェクトマネージャー（以下、PM）の立場でクラウド移行開発に取り組んでいます。

ここでは、入社後の所感やPMとしての取り組みについて記載します。転職先としてJMDCを検討されている方や、PMといったポジションで初めて転職される方の参考になればと思います。

入社理由

前職では、SIerの立場で顧客のデータ基盤開発運用を行ってきました。

扱うデータは数百TBの大規模な基盤であり、ETL処理を中心にスクラム開発(プロダクトオーナー)や短周期ウォーターフォール開発(上流工程)を行っていました。

6年半従事し、今度は事業会社でデータ活用を推進したい、モダンな開発をもっと学びたいと思うようになり、JMDCに入社しました。

JMDCでは、お預かりしている個人のヘルスケアデータが事業の根幹となっています。そうした個人情報に対するセキュリティ確保の取り組みの一つに、「セキュリティ・バイ・デザイン」の推進があります。

「セキュリティ・バイ・デザイン」とは、開発の初期の段階からセキュリティを考慮することで、導入後の効果的なセキュリティ確保と運用コスト削減が可能となる、という考え方です。（参考：セキュリティ・バイ・デザイン導入指南書 | デジタル人材の育成 | IPA 独立行政法人情報処理推進機構）

JMDCにはセキュリティやインフラを統括する部署があって、セキュリティに関する相談にも気軽に乗ってもらえます。明確な考え方とともに具体的な推奨事項や構成案を提示してもらえるので、いかにしてシステム面・運用面でリスクを抑制するかに集中することができます。

セキュリティに関するしっかりとした考え方を実際の開発の中で学べることは、大変有意義だと感じています。

JMDCでは輪読会やLT会等の勉強会が各部署あるいは部署横断で実施されています。

入社時、私のグループでは「システム運用アンチパターン」の輪読会を行っていました。読み応えのある書籍だったことも手伝って、具体的事例の意見交換をしながら、学びの多い充実した輪読会となりました。

今は同じPM職の同僚と、同じく読み応えのある「PMBOKガイド第7版」の輪読会をしています。

また、データウェアハウス開発部には様々な自己学習支援の施策があります。こうした点も含め、技術者の育成に力を入れる会社/部としての価値観の現れだと感じています。

現在、PMの立場で3つのクラウド移行プロジェクトに取り組んでいます。そのうち2つは、1年以上かけて取り組む比較的大規模なPJです。

入社後は、プロジェクト（以下、PJ）開始のための役員説明等の対応に加え、PJ対応に必要となる前提知識の習得を進めてきました。ここで前提知識とは、例えばシステムの要件、ユーザー業務に関する知識、チームの開発運用の環境の知識等を指します。

逆説的に聞こえるかも知れませんが、着任後は前提知識が十分でないからこそ、具体的な作業の主担当になることにこだわるべき、と考えています。

JMDCは、Confluence上に作られた社内公開資料や、部署のオンボーディング資料が充実しています。キーワードで検索したり、ドキュメントツリーを辿ったりすれば、有用な資料を発見できます。

しかし、PJを捉える上で資料では語られない情報はたくさんあり、そちらに早期にアプローチすることもとても重要です。

知識を身につけ実際に使えるようにする上で、具体的な課題対応に取り組むことが有効です。具体的な課題とは私の場合は、PJのスコープ調整が必要な現行機能についての詳細把握や、調達するサーバーのスペックの決定などでした。

OJTを主軸としてOFF-JTを主体的にアレンジする（OFF-JTに頼りすぎない）と言ってもよいと思います。

課題対応を念頭において関係者とやりとりすれば、背景を知る機会が得られますし、どんなメンバーがいて誰がどんなことを考えているかもわかります。仕事も進みます。 PJを取り巻く現実に対するメンタルモデルができてくれば、打合せで話についていけない、という事態も着実に改善していくと思います。

私がPMを務めるPJは、どれもプロジェクトリーダー（以下、PL）がベテラン揃いです。開発チームに関しては、PL中心のチーム運営を尊重したいと考えていました。

そして、管理のための追加工数は抑えつつ、PJの現状にフィットしPJの成功に資する管理を模索しました。

PJの進捗は、PL中心で策定・見直ししてもらっている計画をベースに評価しています。

私はリスクヘッジのため別基準でも進捗を測りたいと考え、方法を検討しました。

進捗測定のインプット情報の候補としてPJのWBSとBacklog（タスク管理ツール）がありました。検討時点での運用実態について、WBSとBacklogを比較してみます。（下表）

観点	WBS	Backlog
運用	PJ開始前に作成。その後は基本的に見直ししない	直近のタスクについてチケット登録
用途	全体作業見積もりと、メンバーへのタスク割り当て	タスク管理
利点	全体網羅性と一覧性	実態を反映（作業内容やステータス）
欠点	PJ進行とともに実態から乖離	部分的。PJの全作業を登録した場合、計画変更時の手間が大きい