downey

自社と協業企業2社間の合意形成、チームの開発スケジュール、およびメンバーのリソース配分をマネジメントしました。 あわせて、要件のスコープ調整や進行中に発生した課題の管理も担い、双方の目的を見失わないよう、関係者間の認識をすり合わせながらプロジェクトを推進しました。

自社と協業企業が互いに納得し、円滑に開発を進められる合意形成された状態にすること、そしてチームが定めたスケジュール内に、品質を落とさず開発を完了できる状態にすることに責務を負っていました。 あわせて、限られたリソースの中でメンバーが適切にアサインされ、無理なく稼働できる状態を維持する責任もありました。

私は、自社と協業企業という異なる組織の人間が関わるプロジェクトにおいて、双方が同じゴールを見て動けている状態を作ることが、合意形成・スケジュール・リソース配分のすべての土台になると考えました。そのため、常に「サービス本来の目的」に立ち返って議論することを、自分自身の判断軸としました。 まず問題として直面したのは、自社と協業企業とで、そもそも優先したい事項が異なる場面です。自社は自社サービスとしての完成度やスケジュール遵守を優先したい一方、協業企業は自社の開発体制やリソースの都合を優先したいなど、それぞれの立場から見た「進めやすさ」を主張し合い、議論が平行線になることがありました。この際、単に譲歩し合うだけでは本質的な解決にならず、なぜその意見が出ているのかという背景まで踏み込んで確認する必要があると感じました。 そこで私は、対立が起きた際にまず双方の主張の背景にある事情や制約を丁寧にヒアリングし、その上で「このサービスを通じて最終的にユーザーにどんな価値を届けたいか」という本来の目的に立ち返って議論を仕切り直すようにしました。目的を何度も共有し直すことで、対立していた論点が「手段の違い」に過ぎないことが見えてくる場面が多く、そこから互いに納得感のある落としどころを探ることができました。 また、スケジュールとリソース配分の面でも問題がありました。開発の途中で仕様変更や協業企業側のリソース状況の変化が発生し、当初のスケジュール通りに進められなくなる場面が何度かありました。ここでは、すべてを予定通りに進めることに固執するのではなく、サービスとしての展望や優先順位に照らして、どこは死守すべき期日で、どこは調整可能かを見極めることを意識しました。その上で、影響が大きい判断については早めに関係者へ共有し、選択肢を提示した上で合意を取るようにし、後から手戻りが発生しないよう工夫しました。 このように、対立や計画変更が起きるたびに、目先の主張のぶつかり合いに終始するのではなく、常に「何のためのプロジェクトか」という本来の目的に立ち返ることを徹底しました。その結果、譲るべき場面と、相手に譲ってもらうべき場面の判断基準が関係者の間でも共有されるようになり、対立が起きても比較的スムーズに合意形成できる状態を作ることができたと考えています。