パブリテック事業部プロダクトチームの所属のたけだです！
この記事はトラストバンクAdobent Calender 2024の記事です。
qiita.com
- 何を話すか
- 何を話さないか
- パブリテック事業部と私
- LeSS実践者トレーニング（CLP）を受けて
- スクラム開発（LeSS）組織におけるマネージャーの役割とは
- スクラムガイドに「マネージャー」というポジションが一切登場しない背景
- DoD（DONEの定義）はチームの能力を表す
- コンポーネントチームではなくフィーチャーチームにする
- 自己管理化された組織づくり
- マネージャーはスクラムチームの中に置かない
- 個人の成長なくしてチームの成長はしない
- 社員採用にチームを巻き込む
- 個人だけで達成するような評価対象となる業績目標を設定しない
- リソース思考に囚われ過ぎない
- チームがオーナーシップを持てる組織構造とプロセスルールにする
- 組織に何かを追加するのは簡単。取り除くのはめっちゃ大変。
- 内製化は優先。でも業務委託の皆さんも大事
- ステークホルダーや上司や会社を説得し理解してもらう
- まとめ
何を話すか
早くない...？もう1年経ったのね、、 去年は1年を振り返って挑戦したことをアドベントカレンダーに書きチームビルディングや成果物の話を中心にまとめました。
今年は1年振り返りつつ、マネージャーという役割について思うことや、意識していることを書いていこうと思います。ちょうど私が所属するパブりテック事業部では、昨年からスクラムを導入して開発を進めています。スクラムガイドを読んでいると、“マネージャー”というポジションは出てきません。この1年で私自身が感じた、「スクラム開発（LeSS）の組織におけるマネージャーとは何なのか？」そして「マネージャーはどう動けばいいのか？」という点を整理して書こうと思います。
何を話さないか
スクラムとは？やLeSSとは？に関しては触れません。LeSSに関しては以下で詳しく解説してますので知りたい方はご参照ください。 less.works
パブリテック事業部と私
パブリテック事業部では、全国の地方自治体向けのSaaSを提供しており、私はマネージャーという役割でこれらのサービスのプロダクトグループ全体の責任者を担っています。具体的には以下のプロダクトがあります。
- 自治体専用ビジネスチャット「Logoチャット」
- 行政手続きデジタル化総合プラットフォーム「Logoフォーム」
- スケジュールや掲示板サービス「LoGoチャットPlus」
- 各業務シナリオに合わせて利用する「LoGoチャットボット」
- LoGoチャットでChatGPTを利用できる「LoGoAIアシスタント」
いずれも自治体の皆さんの業務や住民とのコミュニケーションを効率化かつ安全に支えるプロダクトです。私はこれらを束ねる形で、開発組織をどう育てるか、チームをどう活性化するか、そして事業をどう成長させるかをミッションとしています。
昨年、私たちのチームではスクラムを導入して、アジャイルな開発フローに移行しました。その結果、チーム内でのコミュニケーションが活発になり、プロダクトの改善サイクルも速くなりました。しかし、その一方で「スクラムにはマネージャーが出てこない」という疑問や不安が大きくなったのも事実です。そこに出会ったのが次の見出しにあるLeSS実践者トレーニング（CLP）でした。
LeSS実践者トレーニング（CLP）を受けて
今まで様々な本や研修を受けて「マネージャー」という役割について学んだつもりではいたんですが。
結局の所必要なことは全部やる！くらいの感覚で、自分が何を意識して何を大事にしているのかを言語化することを避けてきた気がします。
特に去年スクラムを導入してから、スクラムガイドの中にマネージャーが登場しないことでスクラム開発におけるマネージャーってなんだろう？と自信が持てずにいた所に2024年10月22日〜24日の3日間で認定LeSS実践者トレーニング（CLP）を受けたことでそれまでにスクラムを学んできた中でマネージャーというポジションが登場してこなかった理由もどう振る舞うべきかもクリアになりました。
また経営者や管理職など組織のマネージャーに該当する人にとっては、LeSSを導入していなくても学びが多い研修だと感じました。 私が受講したものは公開されていないクローズドなトレーニングでしたが、こちら
と同じ内容と思います。もし興味があれば、ぜひ参加されることをおすすめします。とにかくワクワクする研修でした。
スクラム開発（LeSS）組織におけるマネージャーの役割とは
Go See
LeSSでは「Go See（日本語だと現地現物）」という言葉が何度も出てきます。直訳すると「見に行け」ということですが、簡単に言えば「現場に足を運び、チームがどう動いているかを実際に見て理解しろ」ということです。マネージャーである私が、ふだん忙しさにかまけてSlackで会話するだけになると、チームが何に困っていて何を改善したいのかを見落としがちになります。そこでとにかく「現場の声を聞き、現場の雰囲気を知る」というのが重要だと再認識しました。
開発を管理するのではなく、より高い提供価値のために改善する
チームが自己組織化して価値を生み出すのがアジャイルの大きな特徴です。従来型のプロジェクト型開発のPMは、“いかに進捗を管理し、スケジュールを守るか”に注力していた気がします。しかしスクラムではそれ以上に、“どうすればより高い価値をユーザーに届けられるか”や“チームの能力を引き上げるための改善点は何か”にフォーカスします。
私自身も、昔は“マネージャーなんだからスケジュール管理をがっちりやらないと！”と思っていましたが、アジャイル・スクラムではチーム自身が自然に進捗を把握し、必要な調整を行うフローができ上がります。そこでマネージャーは、価値提供を最大化させるためのボトルネックを見つけ出し、そこをチームと一緒に改善することに力を注ぎます。
パブリテック事業部のプロダクトグループにはPMもチーム間の調整役もいないですし（私が行うものでもない）進捗定例会議もありません。
詳しくは以下にマネージャーの役割について解説したページがあり、
以下の図はイメージしやすかったです。LeSSの役割となっていますがスクラム開発においてマネージャーがいた場合でも同じだと思っています。
スクラムガイドに「マネージャー」というポジションが一切登場しない背景
冒頭でも触れましたが、スクラムガイドを何度読んでも「マネージャー」という言葉は出てきません。これは「マネージャーは要らない」という意味ではないと、研修や本で繰り返し説明されています。理由を分解すると以下の通りです。
スクラムはスクラムの外のことを語っていない
スクラムガイドは、あくまでチームの自己管理化によるプロダクト開発の手法を定義しているだけです。マネージャーに言及していないのは、スクラムの守備範囲を超えるためです。マネージャーはスクラムの外のステークホルダーである
スクラムチームの内側にはPO（プロダクトオーナー）と開発者（Developers）とスクラムマスターがいますが、マネージャーはそこに含まれません。あくまで“スクラムの外からチームを支援する立場”にあるという捉え方をします。不要と言っているわけではないが、いなくてもまわる
スクラムの本来のメカニズムからすると、マネージャーがいなくても問題ないようにチームが動ける仕組みが出来上がっています。ただ、それは「いないほうがいい」という極論ではなく、「仮にマネージャーという肩書きの人がいなくてもチームが回るよ」くらいのニュアンスです。
「不要かどうか」よりも“どう関わるか”が重要なんだと思っています。マネージャーはスクラムチームの中にはいませんが、チームが価値提供をしやすいように舞台を整えるのが大切な役割だと考えます。
DoD（DONEの定義）はチームの能力を表す
スクラム開発では、「DoD（Definition of Done）」がよく登場します。簡単に言えば「このスプリントで作ったものを“完成”とみなすための条件」であり、例えばテストが完了しているか、ドキュメントが整備されているかなど、様々な観点が含まれます。
LeSSの文脈でも、DoDはチームの能力を示す指標だと考えられています。
PO（プロダクトオーナー）とDevelopersとの合意事項として、インクリメントごとに何をすればリリース可能になるのかを定義しておく。 本来リリースまでに必要だけれど、各スプリントですべて完了しなくてもよいものはUNDONEとして扱い、リリーススプリントなどで対応するケースが多いと思います。 重要なのは、チームがDoDを満たすために必要なスキルセットやプロセスを常に進化させ続けられるかという点です。マネージャーである私の役割としては、チームが「どうすればDoDをクリアできるか」を考えるのを支援したり、チームの横断的なスキルアップを推奨したりすることです。スクラムが理想とするクロスファンクショナルなチームに向かって、常に観察し改善を促すことが必要だと感じています。
コンポーネントチームではなくフィーチャーチームにする
大規模なプロダクト開発では、しばしば「バックエンドチーム」「フロントエンドチーム」「QAチーム」といったコンポーネントチームに分かれるケースがあります。しかしスクラムでもLeSSでもフィーチャーチームを推奨します。つまり、1チームがプロダクトリリースに必要な意思決定と作業をすべて完結できる状態を目指すのです。
私たちパブリテック事業部でも、スクラム導入時点でバックエンド、フロントエンド、QAといった部署横断のチーム分けを撤廃しました。ただ、現在でもSREやOps（運用）チームがまだ分かれています。そこで今後は、その領域も含めて１つのプロダクトのフィーチャーチームとして合流する方針で考えています。全員が“プロダクトエンジニア”として、ある程度のスキルを身につけ、不得意な部分はチーム内で助け合い学び合う。そのための学習・支援体制を整えるのがマネージャーとしての大事な仕事だと考えています。
自己管理化された組織づくり
スクラムやLeSSでは「自己組織化」「自己管理」が非常に重要なキーワードです。マネージャーとしても、チームの中で意思決定ができる状況を作り上げることを意識しています。
必要に応じてISMSや開発プロセスルールを見直す
私たちの事業部ではISMSや各種開発に関わるルールが存在しますが、時折チームの動きを妨げる部分を見つけたら、一緒に修正するよう動きます。承認運用が必要な場合には、極力手続きを簡素化する
たとえば数時間かかる承認フローを、自動化ツールやワークフローシステムを使って数分単位で済むようにするなど、チームがストレスなく動ける工夫を行います。
結局は「開発に集中できる環境」を整えることが、チームの生産性とモチベーションを最大化します。マネージャーはチームの外から、こうした制度やルールを整え、チームが自己管理しやすい組織づくりをサポートするのが大きな役割になります。
マネージャーはスクラムチームの中に置かない
スクラムチームの中には評価者や組織の管理者が混ざらない方がいい、というのは多くのアジャイル文献や研修で強調されています。
チームメンバーがプレッシャーを受けることなく、“自分たちで考えて動く”ようにスクラムチームの中に評価者は兼務含めて配置しないようにしました。もし評価者が同じチームの中にいると、時には自分を良く見せようとしてオープンな議論がしにくくなったり、リスクを言い出しづらくなったりする可能性があるからです。
私はチームから一歩引いて、チームの観察とサポートに徹しつつも、個々の悩みや目標設定は1on1などでフォローするという形をとっています。
個人の成長なくしてチームの成長はしない
自己組織化を促す一方で、個人が成長しないとチーム全体の成長も停滞するのが現実です。（まだまだ発展途上ですが）私が意識しているのは、学びとコラボレーションの仕組みづくりです。
1on1で学習ロードマップを作成して支援したり、時には一緒に作業をして育成したり、共通認識とスキルをつけるために全員に研修を受けてもらうなどを試しています。ここあたりはまだ課題が多く、成功体験持っている方などいらっしゃったら是非お話聞きたい、、
社員採用にチームを巻き込む
採用活動にも必要に応じてチームを巻き込みます。フィーチャーチーム化を進める上では、幅広いスキルセットや経験が求められます。なので現場のメンバーが「どんな人材が入ってきたら嬉しいか」をリアルにイメージし、それを私にフィードバックしてもらったりカジュアル面談や面接に同席してもらい相性や技術スキルの確認を行っています。 採用段階からチームと協力して“仲間を迎える”という流れを作ることで、オンボーディングの円滑化やチームのモチベーション向上にもつながる効果がある気がします。
個人だけで達成するような評価対象となる業績目標を設定しない
マネージャーの仕事には社員の評価があります。私もメンバーの目標設定と評価を行っていますが、スクラムで開発を進めている以上、あまり個人タスクだけを追う目標は設定しないようにしています。スクラムはチームで価値を提供する仕組みだからです。
目標はタスクではない
よくあるミスに「〇〇の機能を実装する」など、単なるタスクを目標にしてしまうことがあります。こうなると“やったけど成果に結びつかなかった”ときに評価が難しくなります。個人の目標は“チーム全体の生産性向上やケイパビリティ強化”にどう貢献できるか
例えば「TypeScriptの知識を身につけて品質向上に寄与する」や「自動テストの導入を推進してチームのリリース速度を上げる」などです。個人の成長が、どうチームに寄与したかを評価するイメージです。
リソース思考に囚われ過ぎない
私は10年間ほどSIer企業でウォーターフォール開発のPMをやり、その後コンサル企業でも「工数管理」「リソース管理」が当たり前の世界を生きてきました。しかしCLPで人は“リソース”ではないと聞き自分が人をモノとして捉えていることのメタ認知を持ってハッとした記憶があります。
「リソース」は「モノ」であり「ヒト」に使うべきではない
「人は学習するメタ的な機能がある」という考え方がアジャイルでは強調されます。つまり人は日々成長し、スキルを獲得し、チームにより大きな価値をもたらすことができる存在です。効率を追い求めすぎて、チームが学ぶ機会を奪わない
たとえば「今月はこの実装に特化してほしいから、〇〇さんには別の新技術を学ぶ余地はない」としてしまうと、短期的には効率が良くても、長期的にはチームの学習機会や成長の芽を摘み取ることになりかねません。
私自身、スクラムやLeSSを経験して分かったのは、少し遠回りに見えても、学習を積み重ねることで中長期的には生産性も成果も上がるということです。マネージャーはそこを理解し、あまりにも厳密なリソース管理の視点だけでチームを見ないように気をつける必要があると感じています。
チームがオーナーシップを持てる組織構造とプロセスルールにする
組織構造やルールは、しばしば「形骸化」しがちです。たとえば書類提出や承認フロー、会議体などが形だけ存在しているような状態です。しかし、チームがオーナーシップを持つためには、「なぜこのフローがあるのか？」「誰のための仕組みなのか？」を常に問い直す必要があります。
マネージャーとしては、無駄なプロセスやルールをどんどん取り除き、簡素化することも大事ですし、逆にチームが“これは必要”と思うルールはスピーディーに導入できるようにすることも大切です。
組織に何かを追加するのは簡単。取り除くのはめっちゃ大変。
研修や書籍でも繰り返し言われたフレーズですが、本当にその通りだと痛感しています。「あれを導入しよう」「これを試そう」と追加するのはいつでもできるんですが、「人」や「役割」に関しては一度導入したものを後から取り除くのはとても難しい。
日々仮説をもとにした実験を繰り返す中でも何を追加し、何をやめるかを見極めるのも、マネージャーが意識すべき視点だと思います。
内製化は優先。でも業務委託の皆さんも大事
スクラムやLeSSを軌道に乗せるうえで、内製化は非常に強力です。私自身、「MVV（ミッション・ビジョン・バリュー）の浸透や組織の柔軟性、学びの場づくりを考えると、社員主体でチームをつくることは不可欠と考えています。
ただ現実的には、業務委託やコンサル企業の支援を受けなければ回らない部分もあります。私が意識しているのは、“社員と外部の委託先の混合型のスクラムチーム”の場合には、現場に入らない責任者の方も巻き込み、定期的に対話する時間を設けています。業務委託の場合には本質的なマーケットが異なるため「なぜやるの？」「価値ってなに？」が抜けがちになるため、共通認識を持ちそれを浸透させることが必要だからです。
今年は私自身も多くの業務に追われましたが、何より優先したのは採用でした。内製でスクラムを回せる体制づくりに集中しつつ、必要な局面では業務委託やコンサルの支援を受けスキル・知見を補完する。どちらも大事だと考えています。
ステークホルダーや上司や会社を説得し理解してもらう
最後に、これはLeSSやスクラムに限らず、マネージャーとして心掛けていることですが、周囲のステークホルダーを味方につけるのがとても大切です。
「今はできていない」「今は時間がかかる」という事実を伝える
（私も含め）経営者や責任者、PM経験者は、「人を増やそう」「体制やルールを変えよう」「私が中心に立ってリードしよう」という解決策を考えがちです。もちろんそれが必要なときもありますが、チームの学びや成長を待たずに解決策を外から与えすぎると、結局チームが自律的に成長するチャンスを失います。「チームを信じてほしい」ことを伝える
今はできていない現実を正直に共有し、でも「将来的にチームは必ず成長する」という信念を持っていることを、ステークホルダーや上司に示すのです。そうすると“今は多少時間がかかったとしても、長期的にはその方が大きなメリットをもたらす”という考え方に理解を示してもらいやすくなります。
まとめ
ここまで長文にわたって、スクラム開発やLeSS組織におけるマネージャーの役割や、私が感じたポイントを紹介しました。振り返ると、私自身が「マネージャーってどうあるべき？」と考えた時間分、LeSS実践者トレーニング（CLP）に参加したことでより大きく視界が開けたと感じています。
- スクラムチームの中にマネージャーはいない。だけど不要ではない。
- 自己管理化されたチームを支援するために、Go Seeを徹底する。
- コンポーネントチームを廃止し、フィーチャーチームをつくる。
- DoD（DONEの定義）をチームの成長指標として捉え、クロスファンクショナル化を促進する。
- 採用や評価もチーム視点で考える。個人よりチームの成果と学びを重視する。
- 学習する機会を損なわないようにリソース思考を脱却する。
- オーナーシップを持てる組織構造とプロセスルールづくりを推進する。
- 外部ステークホルダーを味方につけ、チームが成長する余地を確保する。
実際のところスクラムやLeSSにおいてもマネージャーが成すべきことはもっともっとたくさんあるはずです。いかに“スクラムチームが動きやすい環境”を提供できるかが腕の見せ所だと思います。私自身もまだまだ試行錯誤中ですが、今後もチームの声を聞きながら、“より高い価値を提供できる組織”を目指して邁進していきたいと思います。
これからもパブリテック事業部では、自治体の皆様と住民の皆様により良いサービスをお届けできるようスクラム開発と自己管理チームの進化に取り組んでいきます。少しでも興味を持ってくださった方は、ぜひ採用情報などご覧いただき、お気軽にご連絡いただければ嬉しいです！
