アーカイブ動画

独立系プライムベンダーとして多種多様な案件に従事

株式会社JSOL
HR本部 人財開発部 採用課　白井 友海氏

最初に登壇したのは、SAPエンジニアとしてさまざまなプロジェクトでプロジェクトマネージャーや各種リーダーポジションを務め、現在はキャリア採用業務に携わっている白井友海氏である。

白井氏はまず、JSOLの事業について簡単に紹介した。JSOLは1969年、銀行のシステム子会社からスタートし、その後、多種多様な業界のシステムやアプリケーション開発などを手がけ、SIerとしての存在感を示している。

現在はNTTデータと日本総研を親会社に持ち、安定した基盤のもとでビジネスを展開している。プライム案件率95.2％という高い数字が示す通り、独立系プライムベンダーとしても強い存在感を持っている。SAP分野には約30年前から取り組んでおり、その実績としてSAPが優れたパートナー企業を表彰する「SAP AWARD」をこれまで28回受賞している。

顧客の課題解決に効くSAPコンサルのための「導入方法論/PM論」

株式会社JSOL
法人ビジネスイノベーション事業本部
エンタープライズビジネス第一事業部
エンタープライズビジネス第三部 一課 課長　清水 武氏

続いてSAPシステムの導入ポイントを紹介すべく登壇したのは、清水武氏だ。学生時代からSAPに興味を持ち同領域に強い会社でキャリアを重ねたいという考えのもと、2007年に日本総合研究所（現JSOL）に入社した。

清水氏は入社以降、SAPシステムの保守運用から新規導入プロジェクトなど、現場メンバーからチームリーダー、プロジェクトリーダー、プロジェクトマネージャーなど多くのポジションの経験を重ねてきた。

医薬、自動車、不動産など多岐に渡る業界にSAPシステムを導入してきたキャリアを持つ。

このようなSAPプロジェクト経験を持つ清水氏。SAPシステムの導入プロジェクトは、規模の大きな案件が多くプロジェクト期間が数年に及ぶことが多い。そのため「始まる前」「始まった直後」「推進中」「稼働後」と4つのフェーズに分けてプロジェクトマネジメントしていくことが重要だと清水氏は説明した。

「始まる前」の企画フェーズでは、SAP導入の目的や、推進に向けた体制について検討する。体制作りにおけるポイントは大きく3つある。1つ目は、プロジェクトの最高意思決定者である『プロジェクトオーナー』を明確にすることだ。清水氏はその理由を、次のように語る。

「プロジェクトを計画通りに推進したとしても、プロジェクトオーナーの期待値とプロジェクトのゴールが異なっていると、結果としてプロジェクトは失敗したことになります。事前にしっかりと、プロジェクトオーナーにゴールを確認しておくことが大切です」（清水氏）

2つ目のポイントは、「情報共有を行うための会議体を設計しておくこと」だ。その際はステアリングコミッティだけでなく、顧客と自社の関係部門が参加する会議体を設定することで参加メンバーの意識のずれを防ぐことが重要である。

3つ目のポイントは、メンバーのアサインと体制構築だ。大規模プロジェクトの場合は、外部からメンバーをアサインする必要が出てくる。しかし、プロジェクトマネージャーやチームリーダーなどの主要メンバーには、必ず自社のメンバーをアサインすることが重要となる。

また、経験の浅いメンバーをアサインする際には、1つ上のロールを経験させることで育成を図ることを意識する。その際、メンバーが不安を感じないように目標を明確にし、常にフォローやサポートができる体制を整えることが重要である。

体制が整ったら、キックオフ会議を行い、体制図の共有や参加メンバーの自己紹介などを行う。ここで清水氏は、過去に取り組んだプロジェクトの体制図を紹介した。

プロジェクトオーナーがワンチームの体制を重視したため、先述のイラストのように顧客とJSOLチームの両社メンバーが全てのチームにアサインされていたケースだ。

「このように体制図を見れば、プロジェクトオーナーの意識やプロジェクトに対する期待が反映されていることがわかります」（清水氏）

続いては、SAP導入目的の明確化である。DX基盤の整備や経営課題への対応など、目的は企業によってさまざまだが、その目的がなぜ必要なのか、その原因となる課題を洗い出し、明確に文書化することが重要だ。清水氏はこのように語る。

「明確な動機付けがないと、メンバーも顧客も意義を感じず熱量の乏しいプロジェクトになってしまいます」（清水氏）

明確化した上で、SAPを導入した後、その課題を具体的にどのように解決するのかを考える。いわゆるギャップ整理を行い、実際にシステムを利用する各部門に確認しておくことが必要だ。

例えば、ホールディングス主導でシステムを導入する場合には、「各グループ会社に導入した際の課題解決をこのフェーズで把握し、解決策を考えておくことが重要」だと清水氏は強調した。

また、清水氏はSAPユーザーのコミュニティであるJSUG（ジャパン SAP ユーザー グループ）に集まった課題・目的・手段の事例も紹介した。大規模プロジェクトでは課題を整理することで目的を明確にし、相関関係を整理することも必要であると補足した。

常にコミュニケーションを取ることでトラブルを最小限に抑える

続いてはフェーズ2となる、プロジェクトが始まった直後のグランドデザインや要件定義におけるポイントである。WBS（Work Breakdown Structure／作業分解構成図）を使い、タスクや開発スケジュールを明確化していく。タスクはゴールから逆算し、1タスクを5営業日以内で完了できる内容に設定する。

「5営業日以内に設定することで、1週間に一度、進捗を細かく管理できるからです」（清水氏）

また、何をいつアウトプットするのかも明確化し、顧客側のタスクや具体的な作成物のレビューも記述する。

この段階から顧客が参加することで、先のワンチームの事例のように、一緒になって進めているプロジェクトであるという意識を持ってもらうためだ。

進捗においては、グラフを活用して「見える化」することで顧客が達成感を覚え、プロジェクトに対する熱意の維持と醸成を図る。

企画フェーズでプロジェクトオーナーが確認した期待より、プロジェクト開始後の進捗が上回っていれば問題ないが、時には進捗が下回るケースもある。

そうなるとプロジェクトオーナーは不安を感じ、プロジェクトマネージャーに頻繁に連絡を取るようになり、場合によっては作業内容に対する指摘が入ることもある。

これらのコミュニケーションや対応に時間が取られるため、更にプロジェクトの進捗は遅れていく。メンバーのモチベーションも下がり、負のサイクルに陥る可能性がある。

このような負のサイクルを防ぐためにも、進捗の遅れは早めにエスカレーションし、適切にレポートすることが重要である。

「常に進捗が期待を上回っている状態で、プロジェクトを進めることが大切です」（清水氏）

メンバーや上長にエスカレーションやレポートをする際は、単に「このタスクはできません」と伝えるだけでなく、どのような原因や理由があり、実行が難しいのかを具体的に共有することが重要である。

具体的にはスライドで示した事例A（左側）ではなく、事例B（右側）のようなコミュニケーションを行うべきであるとした。

このようなコミュニケーションを実現するには、普段からメンバーが特に上位のポジションの人に対して、チャットなどを活用して、気軽に連絡が取れる関係性を構築することが重要である。

「良好な関係性を構築するためには、プロジェクトマネージャーは日頃から笑顔で明るく、前向きに振る舞うことが重要です。私自身も朝の挨拶を必ず行うなど、日々意識しています」（清水氏）

さらに清水氏は、プロジェクトマネージャーがフェーズごとに振り返りを行い、メンバーにさらなる期待を伝えることで、関係性やモチベーションの維持・向上につなげているとも補足した。

リプランが必要になった場合でもゴール（目的）は変えない

続いては「プロジェクトの推進中」、3つ目のフェーズでのポイントだ。まずは、課題の管理について説明した。

発生した課題は課題一覧としてまとめ、メンバー全員が把握・認識するようにする。そのため、解決までの期限、担当者などを明確化するなどフォーマットを統一し、誰が読んでも正しく認識・理解できる文章で記述する必要がある。

「プロジェクトマネージャーや上長も定期的に自分の目で内容を確認することが大切です」（清水氏）

品質においては、テストを強化するといった後手の対策ではなく、なぜ求める品質に達しなかったのか、その真因を特定し事前に対策を講じることが重要である。そのためにも「分析作業を見越したルールを事前に作っておくこと」が大事だと、清水氏は続けた。

しかし、どれだけ対策を講じていても課題やトラブルは発生するものである。そこで何か異常を感じた段階で、できる限り迅速に対処・解決することが重要となる。

なぜならメンバーの多くはリーダーやプロジェクトマネージャーが考えている以上に、自らトラブルの報告や連絡、アクションを起こすことが少ないからである。

そのため、上長から事前に察知し、積極的にコミュニケーションを取ることが必要だ。「実際、私は何かあったらすぐに電話をかけるようにしています」と清水氏は述べた。

どうしても課題が解決しないため、当初のプランを変更するケースもあるだろう。しかし、そのような場合でも「変えるべきはアプローチや体制であり、目的を変えてはならない」と清水氏は語る。

この場面でもメンバーの熱意が重要である。目的であるゴールを変えたり、縮小したりすると、プロジェクトに対する熱意が低下してしまうからだと、清水氏はその理由を述べた。

最後は4つ目のフェーズ、「システム稼働後のフォロー」である。清水氏は航空機の飛行を例に挙げ、離陸・着陸時のフェーズで約70％の事故が発生し、これが「魔の11分間」と呼ばれていることを紹介した。

SAPプロジェクトでも同様に、導入・稼働後のフェーズではトラブルの発生率が高く、結果としてプロジェクトマネージャーの業務量が増える。さらに、トラブルが発生した際の対応や心構えについても清水氏は言及した。

メンバーの責任にせず、自らが自責の念を持ち、責任を取る。トラブルを起こしたメンバーを特定する、いわゆる犯人探しのような行動はしない。

たとえ、メンバーの不手際によるトラブルであっても、自分に責任があるという姿勢を持つことが重要である。

清水氏は最後に次のスライドとメッセージを示し、セッションを終えた。

「粘り強さや、最後まであきらめないといったスキルは、私も備えています。ただし、根っからの明るいキャラクターかというと、そうではありません。可能な限り明るく振る舞うようにしています」（清水氏）

株式会社JSOL
https://www.jsol.co.jp/

株式会社JSOLの採用情報
https://career-jsol-recruit.com/