はじめに

　どうも、おしげです。僕は普段の業務として、お客さん先でではアジャイルコーチをしながら、自社ではアセット開発を行うチームでスクラムマスターをしています。
　今回は、自社開発のなかで、スクラムマスターとして課題改善に取り組むうちに、繰り返し実施が必要な申請系のプロセスをうまくやることの重要性、開発以外の外部チームとの連携して仕事を進めることの重要性等、みんな気にしているが、あまりスポットライトが当たらない点に対して、取り組む機会を得て、しかも、いい感じにチームと組織の生産性向上に寄与できそうで、他の方でも流用ができそうなアプローチだと感じたので、自身の整理のためにも記録に残しておこうと思います。
　そんなこと、スクラムマスターがやることなの？？とか、色んな意見もあると思うのですが、重要なことなので、僕は気がついた誰かがやればいいと思うし、たまたまスクラムマスターとして取り組むなかで、チームが開発に注力するために、スクラムマスターがサーバントリーダーシップを発揮すべきじゃん、って思ったので、対応しました！！異論は歓迎です！！

チームが向き合っていた課題について

　案件については、語れないので、チームとチームが向き合っていた課題について整理します。
　チームは、経験値が高いメンバの兼任アサインで構成されています。ロールとしては、アーキテクト、エンジニア、デザイナー、プロダクトマネージャー、スクラムマスター、等々、ゆるく決まってはいますが、互いの役割に侵食していくような働き方をしています。スクラムを採用していますが、スクラムイベントは滞りなくこなせて、練度も高いです。
　そんなチームが最近どんな課題に向き合ってきたかというと、プロダクトバックログ（以降PBL）のUndoneです。所属している企業の特性上、バックログアイテムリストには、ものつくりに特化したPBLと外部の監査チームを巻き込んだ品質保証や各種申請といったようなPBLが並びます（過多はあるが、どんなプロダクトでも完了の定義やPBLに品質保証用のプロダクトバックログはあるかと思います）。Undoneはものつくり、品質保証、両方のPBLで生じていたのですが、課題視していたのは品質保証として外部チームと連携して進める必要があるPBLでした（ものつくりのPBLは、作り込みの中で挑戦や路線変更した結果Undoneになっているものもあったので、ポジティブなUndoneと評価しました）。もう少し課題を具体的に記載すると、必要書類を作成して、監査の申請を行い、指摘に対応しながら、承認基準を満たすまで対応をしていくのですが、待ち時間となるリードタイム、申請書類作成や申請自体を行うプロセスタイムのぶれ幅が大きすぎて、見積もり確度が低すぎる、ということが起こっていました。

成果

現時点では、まだ改善対応の途中ですが、生産性を24倍以上に向上できるポテンシャルがありそうだと考えています（個人的には100倍以上の改善インパクトを出したいと思っている）

1. 対応速度を4倍以上にできた：
   20稼働日かかっても終了しなかった監査プロセスが、5稼働日程度で対応できた（今後対応件数を増やして再現確度を上げていく想定）

2. ノウハウを展開して6倍のメンバができるようにした：
   ノウハウをチームメンバの5人から、チーム外の組織の30名程度に展開（定着のために伝達の機会は創出していく予定）

アプローチ

ステップ１：申請プロセスの各ステップの意図を理解する

やったこと
　そもそも申請プロセスの各ステップの単語が不明だったり、実施の意図が不明だったりしたので、補足情報にも目を通す、指示されている作業の意図を相手に確認する等を行いました。

おこったこと
　プロセス定義間の補完関係が理解できるようになり、どのような条件のときには分岐が生じるのか、意図が何なのか？を推察できるようになってきました。加えて、記載の内容に疑問が湧いてくるようになりました。

わかったこと
　疑問が生じている原因を突き詰めて考えると、記載量の不足があることがわかりました。当然ですが、プロセスにはすべての情報を記載することはできません。選択して記載した情報、意図的に記載しなかった情報、それらを取捨選択した理由があることがわかりました。プロセス定義は多様なコンテキストのプロジェクトのメンバが見ることになるので、あまりに個別自称二特化した記載は省かれて、最大公約数に近い記載が採用されます。最大公約数と自分たちのプロジェクトのコンテキストのズレが自分の推論の幅を超えた際に記載のミスが生じ、手戻りが発生するのだと理解することができました。

ステップ２：背景を共有して、対応をカスタマイズする

やったこと
　ステップ１を進める中で、プロセス定義にかかれていないことは、エキスパートに確認する方が手戻りのリスクが少ないということがわかったので、聞くことにしました。ただ、最短時間での対応を希望していたので、最もよくプロセス定義を理解している人と会話する必要があると判断して、可能な限り、プロセスを定義した担当者（エキスパート）に担当してもらえるようにしました。
　エキスパートとの会話では、プロジェクトのコンテキストを可能な限り伝えるようにして、ミスコミュニケーションを最小化するようにしました。この時点でステップ１での分析で得た知識がかなり有効でした（急がば回れだった）。あとは、メールでコミュニケーションを行う際には、下記のようにChatGPTに出すコマンドを意識した結果、相当ミスリードが減りました。

おこったこと
　プロジェクトのコンテキストを理解してくれたエキスパートから、今回の申請を最適に進めるために実施する作業内容の提案がありました。これは、ほんとに嬉しかったです。
　あとは、素人である僕がエキスパートに質問をする中で、エキスパート側もプロセス定義に不足を感じたようで、終わりに、今回に実施しなかったパスも含めて、条件分岐と各々の作業内容を整理してくれました。この内容は、まさに、”プロセス定義時に意図的に書かなかったこと”、を再考したことになるので、今後プロセス定義の更新時にも役立つことだし、記載されなかったとしても、僕たちのチームとしては得たノウハウとして別途整理しました。

わかったこと
　申請プロセスの内容について、記載されていないことも含めて理解して実践することで、監査チームの作業時間（僕らにとっては待ち時間）となるリードタイム、申請書類作成や申請自体を行うプロセスタイム、の見積もり確度は上がってきました。しかし、まだ通ってない条件分岐があり、体験していない作業もあるので、完全に平準化できたわけではない状態であることがわかりました。とはいえ、当初の状態からすると、作業内容は相当にクリアになりました。

ステップ３：委託する（今後）

やっていくこと
　ここからは、まだ実施していないので今後の話です。現状、生産性は上がっているのですが、まだ申請書類作成や申請自体を実施することはチームの作業として実施しています。弊社では、これらを委託することができる別のチームがおります。今後は、そのチームとも連携して、自分たちのプロセスタイムを極限まで減らして、申請系のプロセスは省力化。自分たちの付加価値を生み出すものつくりけいのPBLの活動に時間を充てられるようにしていくことが、スクラムマスターとしての仕事だと思っています！！

感想

　今回、意図せずプロセス定義と向き合う時間ができました。僕はプロセスコンサルをやっていたこともあり、楽しみながら改善に取り組むことができたし、以外にプロセスを読み解いて整理していくのは好きなんだなぁと思いまいた。そんな自分に気づくことができたのは、本当にいい発見でした。また、スクラムマスターとして、プロセスのような仕組みを整理することでチームにいいインパクトを出せるということを気づけたのは嬉しい気づきでした。今度も持続可能なペースでやっていこうと思います！！