佐藤： 以前は拠点も違いましたし、週1回の定例会議でビジネス部門の⽅々にお伺いを⽴てるような形でした。それではスピードも出ません。⼼
理的安全性という⾯でも⼤きな違いがあります。POのコミットメントやチームとの距離の近さは開発スピードの向上に⼤きく貢献していると思
います。

稲岡： 以前は、ビジネス部門との打ち合わせの資料準備に、印刷や内部レビューなどで1週間をかけるような⼿順を踏んでいました。今はそうい
った無駄を省くことができています。

鶴岡： 私が以前インターン生と共に弊社の社内システムの開発を担当した際、特に課題と感じたのは、アジャイル型開発に不可⽋なフィードバ
ックを通じた改善プロセスでした。レビューやレトロスペクティブを実施しても、なかなか活発な意見交換にはなりませんでした。しばらくし
て、インターン生がPOやビジネス部門の⼈（開発中のプロダクトのユーザー）から直接フィードバックを受ける機会がないことに気づき、意見
交換の場を増やすようにしました。すると、インターン生側から「もっと良いものを作らないといけない。」という気づきが⽣まれ、以降、ミー
ティングでも積極的になりより良い変化が⾒られました。これもこれまでのお話に通ずるものがあると思います。

ー　各役割に求められるものについて、POから議論を始めたいと思います。POの⽅々は多忙で他の業務もある中で、どのようにプロジェクトに
関わり機能していただくのが最適でしょうか？

佐藤： 特にスピードの⾯で課題となるのは、POは任命されているものの、実際の判断権限がPOの上司に委ねられている場合です。例えば、スプ
リントプランニングで決定した内容が、後からPOの上司に承認されず変更を求められることがあると、無駄なユーザーポイントが消費される原
因となってしまいます。理想的にはPOが決定権を有することですが、POに上司がいる場合は、所属部⾨やチーム単位で事前に合意を取り、その
POが確実に判断できる権限を持てるようにすることが⼤切だと考えます。POが議題を持ち帰って検討するという状況は致命的な遅延を招く可能
性があります。 同時に、POとしても、その覚悟を持って取り組んでいただく必要があります。

たとえば、POは、スプリントプランニングやバックログ・リファインメントでバックログの優先順位を決定しなければなりません。上司に相
談が必要な場合は、それを⾒越して事前に段取りを組んでおく必要があります。無策で、その場で回答できない状況は避けるべきです。

ラファウ： 同感です。決断力に加え、重要なのは決断を下す速さです。結論を出す時点では、必ずしも全ての情報が揃っている必要はありませ
ん。アジャイル型開発では、初期段階での情報は限られています。その時点での最善の結論を出し、新しい情報やフィードバックに応じて後か
ら修正していけばいいのです。逆に、結論がない状態が続くと開発全体が停滞してしまいます。

鶴岡： 他には、先に出てきた「覚悟」が、POのマインドセットとして欠かせないと思います。上司もステークホルダーの⼀部として考えると、
POはステークホルダーと対峙する⽴場であり、ただ⾔われたことを聞く役割ではありません。POが⾃分で良いと判断して実行することについ
て、ステークホルダーに理由を説明して納得してもらう必要があります。

ステークホルダーが直接スクラムチームに指⽰を出すのは最悪のケースです。必ずPOを通す必要があります。ステークホルダーとスクラムチ
ームの間に⽴つのはストレスの多い役割ですが、そのような覚悟を持った方が理想のPOです。

梶沼： 林さん、ウォーターフォールにおける プロジェクトマネージャーとアジャイルにおけるスクラムマスターの違いはどう捉えていますか？

林： リーダーシップのスタイルには様々なパターンがありますが、ウォーターフォールでは、調整役としての側⾯も重要ですが、どちらかとい
うと引っ張っていくタイプのリーダーシップが必要です。特に⼤規模プロジェクトでは、各チームを束ねながらお客様やステークホルダーとの
調整も実施するため主導的な姿勢が不可⽋だと思います。

逆にアジャイルではチームメンバーの⼀⼈としてフラットな⽴ち位置が求められます。⼀⼈だけが突出するのではなく、同じ⽬線に⽴ちなが
ら、良い雰囲気作りをしつつ、スクラムの知識を活かしてチームをリードしていく形です。そこが⼤きな違いだと感じています。

佐藤： スクラムマスターは究極的にはいなくても良い存在なんです。チームメンバーが⾃⽴していけば、その役割は終わっていくからです。プ
ロジェクトマネージャーの場合、その方がいないとチームが動かないような状態になりますが、アジャイルでは逆です。チームの自立を支援し
て、そこに導いていくことは、スクラムマスターに求められる重要な役割です。

佐藤： ウォーターフォール型開発では問題発生時、開発者が提示する複数の選択肢（A案、B案、C案など）の中から、ビジネス部門が解決策を
選択するパターンがよく⾒られます。リスク管理の観点からは選択肢を増やすのも一理ありますが、メリット‧デメリットの⽐較検討用に資料
を作成したりと、意思決定に時間がかかります。

⼀⽅、POとの信頼関係の下、開発者側が⾃信を持って最適な選択肢を提⽰すれば、他の選択肢の検討の必要もなくなり、問題解決や⽅針決定
が⾮常にスピーディーに進むようになります。 私の実体験でも、最初は「どうしましょうか？」「これにしますか？」とお伺いを立てていたスク
ラムチームが、チームの⾃律性が⾼まるにつれ、「この状況ではこの選択肢が最適だと考えます。」と提案が出るようになり、POも素早い決断が
下せるようになりました。