はじめに
プロジェクトの責任者として複数チームの調整を担う中で、ある小さなミスに気づきました。
「依頼文の書き方ひとつで、自分が責任を背負う構造を作ってしまっていた」という話です。
大きな判断ミスではありません。でも、こういった日常のコミュニケーションの中に、責任範囲の意識が浸透しているかどうかが、プロジェクト全体の健全さに関わってくると感じています。
背景
異なる役割を持つ複数のチームが連携する構成のプロジェクトを担当しています。それぞれに担当領域はあるものの、実際の調整の場面では責任範囲が曖昧になりやすい状況が生じていました。
ある依頼文から気づいたこと
何が起きたか
あるシステム連携の検証対応を進める中で、他チームへの依頼文を考えていたときのことです。
当初は「本番に近い条件で検証を実施したい、そのために設定値を調整してほしい」という形で依頼しようとしていました。
意図としては至ってシンプルで、検証の目的を達成するために必要な協力をお願いしたい、それだけでした。
しかし、この書き方には問題があった
この形で依頼してしまうと、「指定した条件で検証を行い問題がなければ、本番でも同様の性能が担保される」という前提を、暗黙的に引き受けてしまう可能性があります。
つまり、検証結果に対する責任を自分たちが持つ構造になってしまうというリスクがありました。
本来、検証で確認できることは何か
今回の検証で確認できる内容を整理すると、
- 想定データ量で処理した場合の処理時間の目安
- 一定条件下における性能の傾向
であり、本番環境において同一の性能が常に再現されることの保証ではありません。
設定値の妥当性や環境構成の判断は、当該システムを管理するチームの判断が重要となる領域です。それを自分たちが「指定」する形にしてしまうと、判断の責任まで引き受けることになります。
責任範囲はコミュニケーションの言葉に宿る
この気づきから、責任範囲の意識は制度やルールとして定めるだけでなく、日々のコミュニケーションの言葉遣いレベルまで浸透させる必要があると感じています。
① 「やり方」ではなく「目的」を伝える
避けたい書き方：
設定値をXXにしてください
この方法で実施してください
こうした書き方は、実現方法までこちらが決めてしまっている状態です。
望ましいのは、「どのような観点を担保したいのか」 を伝えることです。
例：
本番相当の負荷でも運用可能な処理時間であることを確認したい
新しい連携経路でも問題ない処理時間であることを把握したい
② 実現方法は責任範囲を持つ側に委ねる
環境構成や設定の調整については、
- 既存処理との兼ね合い
- システム全体の状況
などを踏まえて判断する必要があります。これらは当該システムを管理しているチームの責任範囲です。
どうやるかは相手側が判断し、責任を持つべき領域として委ねることが、結果的に全体最適につながります。
チームへの共有事項
今回の経験を踏まえ、チームとして以下を意識した動き方をしていきたいと思います。
責任範囲は明示しないと崩れる
自然に整理されるものではなく、意識して言語化する必要があります。
目的を先に決める
やり方よりも、何を保証したいのかを明確にすることが出発点です。
他チームの責任範囲を尊重する
それぞれの責任範囲の中で最適な判断をしてもらうことが、全体最適につながります。
まとめ
責任範囲の意識は、組織の取り決めとして存在するだけでは不十分です。
プロジェクト責任者として痛感したのは、「やり方を決めるのか、目的だけを伝えるのか」という言葉の選び方が、そのまま責任の所在に直結するということです。
小さな依頼文のひとつひとつに、責任範囲への意識を宿らせていくこと。それがプロジェクト全体の健全な運営につながると考えています。