小幡 知弘 
こんにちは、小幡です。
今回は、ネットで無料で公開されている『スクラムガイド』を読んだ感想です。
リンクは以下の通りです。（日本語版）
このWebサイトへは、以前読んだ本で紹介されていたのでたどり着くことができました。
この記事は個人の備忘録です。
スクラムの実践について
このPDFを読んで一番最初に思ったことは、「スクラムの実践は難しい」ということです。
私がSES企業で働いていることもあり、上流工程と下流工程が明確にわかれているような開発体制を多く見てきたため、求人票などに記載してある「アジャイル開発・スクラム」などをアピールポイントを挙げている企業でも、この『スクラムガイド』に則った実践が出来ているのかとても怪しいと感じています。
『Clean Agile』や『エクストリームプログラミング』でも明確にルールが記載してあるのと同様に『スクラムガイド』にもルールが明確に記載してあります。
なかでも、スクラムチームの中に属する開発者とプロダクトオーナー、スクラムマスターを明確に決めてスクラムチームを運営している状況を作り出すのが難しいようにも感じました。
なぜならプロダクトオーナーはスクラムチームに所属しているが、ステークホルダーよりも決定権が強いように表記されているように見えます。
ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
私の想像では、プロダクトオーナーは、そのような決定権がないステークホルダーの意思決定から出た注文に対してプロダクトの納品までを保証するプロジェクトマネージャーのような権限となっていることが多いように思われる。
さらに開発者は、自分の作業について計画と実行の権限が与えられているように見えましたが、開発者が計画を立てることができる現場は稀なのではないかと考えています。
スプリントの計画（スプリントバックログ）を作成する。
私も常々、計画と実行は開発者が行った方がより実際に近い予測となると考えてはいますが、実際の現場では大抵プロジェクトマネージャーが工数を決定したり、作業の工程管理を行っていることが多いように感じています。
これらについては『アジャイルソフトウェア開発宣言』などでも感じたことですが、「プロセスやツールよりも
個人と対話を、」という事が実践できていない結果なのではないかと感じています。
スクラムマスターの責任と仕事
SESの現場においては、上流工程と下流工程の明確な権限の違いや会社メンバーの違いなどによって「この人はスクラムマスターだ」という様な経験がほとんどありません。
スクラムマスターは、チームが最高の生産性を手に入れるために、チームために奉仕するような責任と仕事が記載されているような印象ですが、チームないで上がっている障害物をどうにかするためには、プロジェクトマネージャーに相談することが多いように思います。
また開発者のコーチは開発者自身か、所属する会社の先輩であることが多いように感じています。これは、そもそも会社単位で考えた時に、スクラムマスターとしてチームに参画することはなく、開発者として参画することが前提となっていることから仕方のないことなのかなと考えています。
システム開発の現場においては、記載されている責任と仕事を成し遂げるスクラムマスターをおくことができるのは、ある程度の規模と信頼関係が構築できてる状態でチーム開発ができる場合に限られており、SES企業が複数集まっている現場では、実現可能性が低いように思います。
これはネガティブスパイラルに陥っているようであまり嬉しくないですね。
朝の報告会とデイリースクラム
仕事をしていると、朝の15分くらいの時間を使って、全員が昨日の作業報告と今日の作業予定を発表する時間があったりします。
これはこれで、リモートワークで誰がどんな作業をしているのかを確認するという意味では有効なのかもしれないと感じていますが、『スクラムガイド』に記載があるデイリースクラムではないと考えています。
なぜなら、その前提となるスプリントプランニングが行われておらず、そもそもスプリントとして参加者が認識していためです。
つまり、デイリースクラムとはスプリントイベントの１つですが、参加者にスプリントの認識がないのでそれはただの朝の報告会だと考えています。
こう言った状況の開発を行っているプロジェクトでも「デイリースクラム」と表現しているのはいかがなものかなと感じています。
『エクストリームプログラミング』だったか記憶が曖昧ですが、その単語のパワーに憧れて、手段が目的化してしまうことはよくあることですね。
そういう風に思いを巡らせていると、コロナの影響もあってかリモートワークするためのツールや、安定した開発プロセスが整備されたおかげで、個人との対話がとても減ったのではないかと感じました。
まとめ
今回は『スクラムガイド』について感想を書いてみました。
改めてこうして思ったことを書いてみると、本来のスクラムを実践できているプロジェクトがあるとすれば、それは素晴らしいことのように思う一方で、自分に何かできることは無いものかと考えさせられました。
エクストリームプログラミング、アジャイル開発、スクラムと、ここ最近より大きい視点でシステム開発と向き合ってきましたが、よりよい開発体験に向けて、自分ができることを少しでも実践できたらと考えています。
以上です。