アーカイブ動画

外部パートナーとの協力関係を構築し、求人原稿の掲載リードタイムを10日から5日に半減

パーソルキャリア株式会社
dodaプラス事業部 プラス企画統括部 プラスプロセス＆システムデザイン部 プラスカスタマープロセスデザイングループ
リードコンサルタント　江見 佳緒里氏

最初に登壇したのは、求人・転職情報サイト「doda」における原稿制作業務に関するシステムのコンサルティングや、各種プロジェクトの推進などを担う、江見佳緒里氏だ。江見氏は、SIerでシステムエンジニアとして公共インフラ関連の業務システムの開発や運用などを経験した後、2022年にパーソルキャリアに入社した。

江見氏はまず、プロジェクトの概要と着手時の課題を紹介した。以下スライドで示したように、クライアント企業から求人票を共有してもらい、そこから実際に「doda」のサイトで掲載に至るまで、以前は最大10日間かかっていた。

業界では情報の提供が遅れると採用充足のリスクが高まる。そのため、この10日を少しでも短くすることが、結果としてクライアントのニーズに応えられると感じ、低減に向けて新たな体制を構築することとした。

業務内容を精査していくと、大きく2つの課題が見えてきた。1つ目は「doda」への掲載申請手続きにおいて、求人数が増加していたことから、「doda」の担当者の作業時間が増加していたことだ。そこで江見氏は、特定の対象を除き、自動で掲載申請が進む機能を追加することとした。

2つ目は原稿作成が終わった後、内容をチェックして実際にサイトにアップされるまでの審査を行うフェーズでの問題だ。90％の原稿が修正の必要なく掲載に進む状況であったにも関わらず、修正が必要な原稿と同じ日にアップするとの設定となっていたからだ。同設定を変更、審査を通過した原稿は最短で掲載される仕様とした。

続いては、実際にプロジェクトを進めた際の課題が紹介された。大きくは2つある。プロジェクトマネージャー並びに、業務企画チームのドメイン知識が不足していたことであり、江見氏は次のように当時を振り返った。

「入社から半年ほどということもあり、原稿制作に関する業務もシステムへの理解も、5～6割ほどでした。また企画担当部門も体制が変更した後であったため、同じような状況でした」（江見氏）

課題解決に向け、江見氏は情報のキャッチアップや業務理解に向けた努力を行うことはもちろん、「doda」の原稿制作システム関連のプロジェクトに携わった実績を持つITパートナーを選定することで、不安解消を補完しようとした。

さらには、困りごとを包み隠さず共有し、気軽に相談できる雰囲気を意識するなど、パートナー企業との協力関係構築における工夫、ノウハウについても紹介。「いつも心がけていることですが、オープンなコミュニケーションを意識しています」と述べた。

アイデアや成果に対してもこまめなフィードバックを意識することで、メンバーのモチベーションアップ並びに、プロジェクトの品質アップも目指した。

また、フィードバックの際には「ポジティブに行うことを意識しています」ということを補足した。

プロジェクトで、具体的にどのような悩みごとをオープンに共有していたかも紹介された。原稿制作の業務スキルに不安を持っていたことに加え、システムが止まると事業への影響が大きく、「プロジェクトが失敗したら、パーソルキャリアでの自分の人生（キャリア）が詰んでしまうのでは」という不安な気持ちでいることなどである。

江見氏は自身が語ったノウハウ通り、心の内にある本音、心境を包み隠さず赤裸々に吐露したのである。すると「素敵な方だった」と江見氏が話すように、パートナー企業のリーダーがそのような江見氏の状況や不安を汲み取ってくれ、それぞれの対策を具体的に提示してくれた。

続いて、マトリクスや網羅性のあるテストシナリオを作成し、リリース後の万が一に備え、データ補正の手順も準備しておくといった取り組みである。

江見氏はパートナー企業のリーダーからの提案を元に実際に制作した、業務パターンとシステムの仕様をかけ合わせたマトリクス表とシナリオも紹介した。

そして、同シナリオを元にテストを実施し事前にバグ出しを行っていたことで、ユーザーの受け入れテスト時には、クリティカルなバグはゼロであり、担当者からも「こんなに不具合が出ないのは初めてかもしれない」と、褒め言葉をもらって感動したという成果、エピソードを語った。

こうした江見氏の取り組みもあり、プロジェクトは無事終了。目標であったリードタイムは約10日から約5日まで半減した。江見氏は笑顔で以下のように述べ、セッションを締めた。

「ご協力いただいたパートナーとは、現在も引き続き新規プロジェクトの開発業務などでとても良い関係が続いています」（江見氏）

グループ148社、1万8000人が利用するシステム刷新プロジェクトで得た知見

パーソルホールディングス株式会社
グループデジタル変革推進本部 ビジネスITアーキテクト部 ファイナンスBITA室
リードコンサルタント　岩佐 優子氏

続いて登壇したのは、パーソルホールディングスの岩佐優子氏だ。新卒で入社した前の会社で広報やIR、経営企画などを経験した後、グループ全体に業務会計システムを導入するプロジェクトなどの、プロジェクトマネージャーを何度も経験してきた。

2023年にパーソルホールディングスに入社した後もそれまでのキャリアを活かし、業績管理ツールやワークフローをグループ全社に導入するプロジェクトなどに、プロジェクトマネージャーとして携わっている。

現在は、それぞれの部門で独立していたシステムを連携・統合すると同時に、集計作業の自動化なども実現する、パーソルホールディングスの全148社、国内グループ社員約1万8000人が利用する管理会計や稟議システムの刷新プロジェクトに携わる。

岩佐氏が取り組んだプロジェクトは規模が大きいシステムとなるため、スクラッチ開発は難しいと判断。全て外部のSaaSやクラウドサービスを使うことを決めると同時に、システムの機能に業務を合わせる、Fit To Standardも目指すこととした。

ただ実際に進めてみると「Fit To Standardは意外に難しいと思いました」と、岩佐氏は語る。大きく3つの理由を紹介した。1つ目は、「ポジションにより思惑が異なることで、実際に現場で利用するメンバーは業務をシステムに合わせる視線を持ちにくく、議論になりづらかったです」と、述べた。

2つ目は、運用設計での視点不足だ。利用者に業務改善を求めたり判断を仰いだとしても、業務全体のことを知る人は少なかったり、そもそも正解を持っている人材がいなかったからだ。

3つ目はカスタマイズ性である。後ほど改めて述べるが、岩佐氏はカスタマイズ性の高いツールを採用した。その結果、業務をシステムに寄せることが本題であるにも関わらず、カスタマイズ機能を使うことで業務改善に繋がるのではないかと、議論の論点が違う方向に行ってしまったからである。

実際にプロジェクトを進めてみての成果や感想、反省点も紹介した。まずは当初の目論見どおり、SaaSやクラウドを利用したことで、通常1年はかかるプロジェクトを3カ月～半年ほどで終えることができた。

現場の担当者も正解を持っていないため、IT担当者が運用設計にも関与していったことも大きいと岩佐氏は語る。その際には「他のシステムではこうでした」「一般的には～」といった言葉でコミュニケーションすると、「現場の人たちも同意してくれ、スムーズに進みました」と、まさに現場で得たノウハウを視聴者に共有した。

反省点においては、カスタマイズ性能が高すぎたことにより、「スクラッチ開発と変わらないほどの深い議論になってしまった」と、岩佐氏。既存業務の掘り起こしを徹底する必要から関係者が増えすぎたが、ここでも誰も正解を持っていないため、議論がまとまらなかったと振り返った。

岩佐氏は、改めてFit To Standardを成功させるためのポイントを述べた。まずは、これまで紹介してきた通り、製品においてはカスタマイズ性ではなく、標準機能でできるだけ対応できるシステムやサービスを選定することだ。

また、業務設計とシステム導入は、それぞれ対応のコンサルタントも分けた方が良いと語った。現場ユーザーの想いや答えに寄り添い過ぎずに、IT担当者やコンサルタント、プロジェクトマネージャーが「一般論として」とのくだりで進めると、スムーズなことを強調した。

意見が食い違う関係者との合意形成のコツについても紹介した。こちらも岩佐氏が実際にプロジェクトを通じて得た知見やノウハウであり、11の項目に渡り、表にして事細かに示した。

例えば「1」では、トップ自らが語ることで「社内で動きやすくなりますし、責任の所在もはっきりします」とのメリットを述べた。

「9」の抵抗勢力への対処フローでは、「感情的に意見をぶつけてきたときや、理不尽なことを言われても大人の対応をすることが一番重要です。大抵の場合は、大人の対応をしている側の味方についてくれるからです」と、理由と併せてノウハウを述べた。

「11」のリリース後では、新しいシステムや機能はどのように使うのかなどのユーザーに向けた社内広報を、プロジェクトマネージャー自らが行うことも重要だと語った。

また、元々業務側にいた岩佐氏だから分かる、システム側のプロジェクトマネージャーが見落としがちな業務観点や注意すべきことなども、「忘れていると危ない内容です」と強調した上で、紹介した。

まずは「1」のガバナンスや規程だ。特にパーソルホールディングスのように上場している企業の場合は、上場の際に取り交わした規程などもあるため、新たなシステムが規程に沿っていないと大きな問題に発展するからだ。

「規程の存在を知らない人も多いので、まずは存在を知っておくとの視点が大事だと思います」（岩佐氏）

「4」の業務の巻き取りでは、せっかくいいアイデアや業務フローを思いついたとしても、巻き取り方まで考えないとお蔵入りになったり、後からトラブルの原因になったりする。業務・システム設計両チームを設けることが大事だと述べた。最後は「7」の予算について解説し、セッションを締めた。

「担当プロジェクトの予算を守る必要は当然ありますが、費用負担などで揉める可能性もあります。予算の使い道は他にもたくさんあるため、それぞれの状況を知っておく、そのような視点を持つことが重要だと思います」（岩佐氏）

部門横断の調整を乗り越え、「e-契約書プロジェクト」で顧客満足度向上を実現

パーソルテンプスタッフ株式会社
テクノロジー本部 ビジネスIT推進部 スタッフIT室
マネージャー　鈴木 美智子氏

続いては、パーソルテンプスタッフでテクノロジー本部のスタッフIT室室長を務めている鈴木美智子氏が登壇した。2004年に入社し、当初は営業職であったが、2011年にテクノロジー本部に異動。以降は様々なシステム導入プロジェクトのサービスマネージャーやプロジェクトマネージャーを経て、現在に至る。

鈴木氏は部門を横断したITプロジェクトにおける課題や具体的な解決への取り組みを、実際に手がけたe-契約書プロジェクトを例に挙げて紹介した。まずはどのような部門が携わったかについて語った。

鈴木氏が属するテクノロジー本部、事業部門、そしてグループ会社も含めた外部のパートナー企業の三者であり、工程においては複数の部門が担当するフェーズがあるという。

プロジェクトの概要については、事例をもとに紹介された。人材派遣業を扱うパーソルテンプスタッフでは、クライアントならびに派遣スタッフどちらに対しても、基本的に3カ月に一度契約更新の書類を郵送していた。

ただスタッフの数は10万人という規模感であったため、外部委託していた。ところが数年前に契約書が電子でのやり取りで可能となったこと、COVID-19によりリモートワークが推進されたこと、さらには障害者雇用を促進するとの経営課題などから、PDF化しメールで送付する体制への変更を行うことになった。

その結果、外部への委託費はもちろん郵送コストの削減、さらにはペーパーレスということで、CO2の削減といった社会貢献にも寄与するプロジェクトであったと、鈴木氏は振り返る。

同社では、クライアント企業、派遣スタッフと二者に送っていることに加え、数が膨大であること。さらには委託先も既存ならびに障害者雇用を手がけるグループ会社も含め、複数に渡るため、契約書の電子化、業務委託切換と2つのステップに分け、それぞれの業務がスムーズに進むようなタイミングで、切り換えなどを行うよう配慮した。

一方で、プロジェクトに携わる組織や部門、システムは多岐に渡り、プロジェクトは複雑な体制となった。そしてこのような状況に伴い、いくつかの課題が生じた。

まずは、参加者が大勢いるために、それぞれのメンバーの温度差が生じやすいことだ。そこで鈴木氏はキックオフミーティングを開催することにした。実際、集まったメンバーは100人以上となった。

キックオフミーティングの場で鈴木氏は、プロジェクトを実施する目的（大方針）を掲げると共に、ミーティングの前・後半と意図的に同じ内容を2度繰り返した。そして「熱く語りました」と述べ、ある意味感情的にメンバーに訴えることで、温度差が生じないように努めた。

また、納期遵守がマストの案件であることも、同じく全メンバーに理解してもらうよう、同メッセージも先と同じく強い口調で伝えたという。

コミュニケーションロスを防ぐために、会議体とコミュニケーションの内容や実施日時の詳細を記した計画表を作成し、メンバーに共有した。また参加者の日々の業務に配慮し、参加が必須な会議体以外には、報告書やメールで伝えるなどして、負担を減らすよう努めた。

タスクの抜け漏れを防ぐために、それぞれの領域の責任者が集まり、スケジュールも含め整合性を確認しながら、計画表も作成した。

同計画表のポイントは、マスタースケジュールより一段細かい粒度ではあるが、WBS（Work Breakdown Structure）には至らないレベルだと鈴木氏は工夫を述べると共に、成果を次のように話した。

「計画表を作成し共有したことで、お互いのタスクを気にかけるようになりましたし、普段からお互い助け合うなど協力的にプロジェクトを進めていこうとする、チームとしての良き雰囲気が醸成していきました」（鈴木氏）

2つ目の課題は先述した通り、クライアント・スタッフと最終的な要件定義者が複数いたため、各要件の決定者は誰なのか、承認プロセスにおいても同じく明確化し、こちらもキックオフミーティングで周知した。

また、それぞれのポジションの役割についても、計画表に詳細を定義し記載した。

このような配慮や取り組みを行った結果、プロジェクトは無事終了。現在では紹介した計画表などを活用することで、以前と比べて数多くのITプロジェクトを推進している。

だが、新たな課題も生じているという。先述した3部門以外、他の部門からの起案によるプロジェクトの依頼などであり、「これまで携わったことのない部門もあり、工数の想定が難しく、思ったよりも時間がかかっているケースなどが生じています」と、鈴木氏は現在の課題を述べた。

現課題の対策についても、最初の段階で全体の流れをしっかりと提示、共有することを徹底した。さらには起案者の上司を巻き込むことで、業務調整や他の社員のアサインを配慮してもらうことなどを心がけていると鈴木氏は強調する。

「プロジェクトマネージャーの目線で俯瞰すること。業務システムの垣根を超えてお互いにゴールに向かっていくことを心がけています」と述べ、セッションを締めた。

【Q&A】参加者からの質問に登壇者が回答

セッション終了後は参加者からの質問に登壇者が答えるQAセッションも設けられた。抜粋して紹介する。

Q．前職のどのような経験が役立っているか？

江見：前職でのシステムエンジニアの経験がかなり役に立っていると思います。 前はパートナーが複数いるのが当たり前な職場で、タイプも様々な環境でした（笑）。そうした中、業務を円滑に進めるためにコミュニケーションした結果が、今の自分のプロジェクトマネージャーとしてのスタイルになっていると思っています。

Q．法務部門との連携や調整においての苦労や工夫した点は？

岩佐：法律の内容などは難しい話が大半なので、担当者の意見を理解するのが大変でした。法律などに強いメンバーをチームに加えておくことが必要だと思います。また、法務以外にもガバナンス室、監査室など関係部門が多かったため、それぞれの部門と議論したい内容や、課題解決したいテーマを事前にまとめ、かつミーティング前に共有、明示するようにしていました。

Q．システム部門が頑張り過ぎると受益負担の原則が希薄になるのではないか？

鈴木：紹介したプロジェクトでは大丈夫でしたが、そのような状況は往々にしてあると思います。そのため、役割定義を細かく記載すると同時に、仮に手伝う場合でも「本来は業務部門の方の仕事なんですよ」と、一声かけるようにしています。

Q．業務部門からシステム部門に異動したことで感じる違いや苦労、取り組みは？

岩佐：工程管理が以前よりも厳しく、しっかりしていると感じます。取り組みにおいてはシステム開発に関する技術系の本を読んで勉強したりしています。プロジェクトマネージャーのコツのようなサイトを見て、自分はどこまでできているか「○×」でつけると同時に、できていない箇所はどうすればできるようになるかを、ベテランの先輩や上司に相談したりしました。

Q．課題の発見はどのように行ったのか？

江見：業務側においては、社内の数値情報を分析したり、現場のメンバー数名に原稿作成における課題をヒアリングするなどしてまとめていきました。システム側でも同様で、改善することでスピードアップを実現するなどの箇所を、現場のメンバーにヒアリングしました。

Q．プロジェクトマネージャーがファシリテーターの役回りになるなど、意思決定がまとまらない会議が多い。どうすればよいか？

鈴木：事前にアジェンダを共有し、落とし所を考えた上で会議に臨むといいと思います。そうすることで意見を集約しながらも、どこを目指しているのか。意見を削ぎ落として、進めていくことができるのではないでしょうか。

パーソルホールディングス株式会社
https://www.persol-group.co.jp/

パーソルホールディングス株式会社 テクノロジー人材の採用情報
https://www.persol-group.co.jp/recruit/holdings/persol-tech/

パーソルグループ テクノロジー活用情報を発信するオウンドメディア「TECH DOOR」
https://techdoor.persol-group.co.jp/