ユーザー部門からの依頼が一方通行すぎて調整できず、プロジェクトを円滑に進められていない！と課題を感じるシステム部門。一方、システムリリースが間に合わず事業が計画通り進まない！と感じるユーザー部門。よくある対立関係を協力関係に変える方法について、プロジェクトマネージャーのエピソードを交えながらお話します。
K.K氏 プロフィール：新卒で250名規模の独立系システム開発会社に入社し、約10年間、一括請負案件の見積もりから保守まで幅広く経験。その後、事業の拡大を行うため、関西事業所の新規立ち上げを経験。営業からプロジェクトマネジメントまでマルチに活躍。その後、別会社にて約6年間PLやPM、PMOなどを経て、2020年に株式会社情報戦略テクノロジーに入社。
【エピローグ】そもそもシステム部門とビジネス部門の溝はなぜ生まれるのか
ユーザー部門は事業目標を定めそれを達成するためにシステムを活用します。事業計画を遂行するため、ユーザー部門はシステム部門にシステムの要件やリリース時期を依頼します。プロジェクトの背景によってはユーザー部門が設定する納期や要件を変えることのできない状態でシステム部門へ依頼されます。
こうした背景によりシステム部門はシステムをリリースすることに必死でシステム導入や開発の目的が事業目標の達成からシステムリリースに替わってしまうことがあるのではないでしょうか。
こうした状況で無理やりスケジュールを組みシステムをリリースした結果、要件変更に対応できないばかりか、障害が頻発するなど事業にマイナスの結果を与えてしまうシステムが生み出されてしまいます。システムはあくまでもツールであり、ツールを創ることを目的としてしまうと本来の事業目標を見失ってしまいます。
そうした状況にならないために、システム部門として事業目標を把握し、ユーザー部門に対しシステムの側面で事業目標の達成に向けた提言を行っていく必要があるのではないでしょうか。そのためにも、まずはユーザー部門とシステム部門がインタラクティブにコミュニケーションをとれる状態であることが求められます。
このように、ユーザー部門とシステム部門とで上下関係が生まれている中、いかにその関係性を解消し、インタラクティブなコミュニケーションがとれる状態を築いていくのか、実体験を持つISTのPM、K.K氏に聞いてみました。
【インタビュー】システム部門こそ、システム知見だけでなく他部門とのWin-Winを生み出せる調整者が必要
ー システム部門ではどのような課題があったのでしょうか？
K.K：システム部門で管轄しているデータプラットフォームについて、事業に有効活用していきたいとユーザー部門の要望がありシステム構築プロジェクトがスタートしていました。そのプロジェクトについてシステム構築に関する技術的な知識のフォローとプロジェクトマネジメントをお願いしたいとご依頼いただき参画しました。
参画してみると、当時の担当が孤軍奮闘してユーザー部門とスケジュールや仕様面の調整をしていました。1人ではユーザー部門のシステムすべてを把握できず、複数のユーザー部門との調整事も積み上がり手が回っていない状態でした。
他のメンバーはこれまでデータを解析しユーザー部門に提供することが大きな役割だったため、ユーザー部門とのシステム構築に関わる調整についてはフォローができていない状況でした。
システム部門のノウハウの問題もありつつ、私が最も頭を悩まされたのがユーザー部門との折衝でした。ユーザー部門からシステムのリリーススケジュールを指定されるのですが、当時は現実的でないことが多く調整したいと伝えても全く応じてくれない状況がありました。
事業部門長の肝入りのプロジェクトだったので、ユーザー部門の担当もスケジュールは譲れないといった背景があったのだと思います。それによってシステム部門は納期に間に合わせるために土日に対応したり、深夜の作業が常態化していました。
ー ユーザー部門に対してはどのような課題を感じていましたか？
K.K：ユーザー部門は私たちに要件を固めるところから依頼する一方で、予算とスケジュールだけ最初から固まっている状態でした。おそらくユーザー部門側も、システム部門がどんな情報を必要としているのかがわかっていないので、依頼内容がふわっとした状態であったり、スケジュールの調整が必要かどうかもわかっていない状況なのではないかと思いました。
ー 課題改善のために、どのようなことを行いましたか？
K.K：まずはシステム部門としてユーザー部門の理解を深めるために、ユーザー部門の案件企画の打ち合わせに参加しました。システム部門も案件化の前段階から参加することで、システム面や体制面での課題をユーザー部門にも理解いただき、予算やスケジュールをコントロールできるようにしました。ユーザー部門もシステム面の課題を事前に把握することで安心して進められている側面もあったように思います。
またスケジュールが変更できない中でユーザー部門から仕様変更依頼があったときは、業務委託で参画している立場ながらもお客様の上位役職者を巻き込み、ユーザー部門側と納期の調整をできるように対応しました。
そうした折衝を行う打ち合わせでは、システム部門に余力が生まれるギリギリのラインをあらかじめ設定し、そこを目指して調整しています。調整ができず私たちが多少無理をして対応するようなケースでは、向こうに「今回は特別な対応である」と受け取ってもらえるような話の仕方をしています。
今まではユーザー部門側に要求をしてこなかったのでシステム部に言えば対応してくれるという感覚が普通になってしまっていました。システム部門も今回もしょうがない、という感じで対応していましたが、それは当たり前じゃないというところを、お互いにプロジェクトを進めやすくするために示すことが重要だと思います。
ユーザー部門側もシステム部門がどれだけ無理をして対応してくれているかをわかってくれているので、参画当時よりスケジュールの調整はしやすくなってます。過去に常態化していた深夜残業や土日の対応などは大幅に減ってきたと感じています。
【総括】想定以上だった、システム部門とビジネス部門のコミュニケーション不足による弊害
ユーザー部門とシステム部門との間に上下関係がある原因の一つには、社内のシステムに関するノウハウやナレッジ不足があるようです。今回の事例では、システム部門の専門性が低いゆえにユーザー部門に対し受動的になってしまっていました。社内で知見者の採用や育成をするなど改善を行い、事業を成功させるためのパートナー部門に進化していくことが求められています。
またシステム部門内の体制を整えたうえで、ユーザー部門の事業企画などの打ち合わせに同席するなど積極的に関わっていく必要があります。事前に人員配置の検討や他のタスクとの優先順位の整理を行いシステム部門マターの遅延を減らすことができます。
またユーザー部門がどんな目的を達成したいのかその場で確認することで、代替案も生み出すことにもつながります。ユーザー部門も、ユーザー部門だけでは想定しきれない課題やリスクを把握したうえで計画を立てられるため、プロジェクトの成功確率を上げることができます。
こうした場を継続的に実施することで、システム部門の業務理解が深まり、ユーザー部門もITリテラシーが向上します。相互理解が深まるとビジネス環境の変化でシステム面にも手を入れる際、よりフレキシブルに迅速に対応できる体制が整っていくのではないでしょうか。
