私は Chatwork 株式会社にて、エンジニア・バックグラウンドで組織開発に携わっています。

Chatwork は今年で 11 周年を迎える息の長い SaaS となるのですが、社会の DX が加速することに伴って求められるプロダクト成長を実現するために、開発組織の構造変革や技術的負債へと向き合う必要がでています。

そのための組織開発は、不確定要素を持ちながらもスピードが求められるため、Chatwork においてはエンジニアと人事を一同に介した "DevHR" というチームを作り、スクラムを応用して PDCA を回しています。

本セッションでは、Chatwork における DevHR の活動を紐解くことで、組織開発や人事領域へのスクラムの応用可能性を考察します。

スクラムを勉強する方法はたくさんありますが、その中でも特に短期間でスキルアップしやすいのが各種研修への参加です。無認定のままアジャイルコーチとして数年やってきたkyon_mmがついにScrum Allianceの研修をうけてみました。また、実践者であるbleis-tift、アジャイルコーチであるoshige、ビギナーであるyamajiも各種研修をうけてきています。そこでたくさんのことを学び、研修の善し悪しについて考える機会もふえました。

今回はScrum Allianceの研修をうけてみた感想と、Scrum Allianceが策定している「この研修ではこれ学べるから期待しておけよリスト」に本当に研修が合致しているのかの検証結果をご紹介します。みなさんが研修をうけるさいの参考になれば幸いです。

現在、Chatworkでは大規模なマイグレーションを行っています。

システム開発にスクラムを導入する目的は、『要求に対して仮説検証を行いながら不確実性に適応するため』ですが、作り直しであるマイグレーションでは極論を言ってしまうと『要求に対する仮説検証』は発生しません。

それであれば、対象資産と移行手法を最初に確定させることによってウォーターフォールで進めることも可能に思えますが、実際には以下のような不確実性が発生します。

• 現新の環境差異によって発生する不確実性
• 他チームの活動による影響によって発生する不確実性

このような不確実性に対して、開発者出身の非PdMのPOとしてどのように取り組んでいるかについてお話します。

私はChatworkという会社で、フロントエンド開発を行うチームのマネージャーをしています。

これまでフロントエンドチームは、時には私がスクラムマスターの帽子を被り、時にはメンバーがスクラムマスターを担いながら、様々な改善を行ってきました。

私がマネージャーになった当初は、個々人でタスクを消化している色合いが強く、マネージャーやシニアメンバーがチームのボトルネックとなっていたため、チームをスケールをさせるのは難しいと思われていました。

しかしいまでは、チームを主語にしてお互い助け合いながら自律的に課題を解決している状態になりつつあり、社内からも「いいチームだね」と声をかけて頂いています。

これまでのチームの成長を振り返ると、チームが自律して課題を発見し、解決できるようになるためには、いくつかの段階があるように感じています。

このセッションでは、マネージャーとしてチームの自己組織化を支援するために取り組んだことを振り返りながら、チームの状態に応じてどのような改善をしていくのが良いか、そしてマネージャーとスクラムマスターの関係について考えてみたいと思います。