開発チームのメンバーにとって、担当部分を実装することは最低限必要なことですが、それだけではプロジェクトは進みません。どのような形であれ、実装したものをリリースすることは必要となるでしょう。ただ、実装しつつリリースのことを考慮するのは、別のスキルやマインドチェンジが問われることも多く、何かしらの仕組みがないと難しいこともあります。

私たちは、2年前の2017年1月ごろから、Webアプリケーションのフレームワーク移行プロジェクトを進めてきました。当初は、開発チームのメンバーが実装部分にのみ目がいき、なかなかリリースまでこぎつけることができない状況となっていました。ですが、現在では1週間に2,3回リリースするなど、リリースを見据えてプロジェクトを進められるようになっています。

本セッションでは、プロジェクトを成功させるために、WIP=進行中の作業をコントロールしつつ、WIPの状況に応じたメンバー構成の遷移について紹介します。

ここ数年で、エンジニアリングマネージャーという職種が脚光を浴び始めています。個々のエンジニアだけでは解決しづらい組織的な課題を解決し、組織全体の生産性を高めることが求められるようになりました。

私達が所属する組織・チームでも、プロダクトの成長にともないチームも増大した結果、チーム間でうまくコミュニケーションが取れない・フローが整備されていないために意思決定が遅いといった、組織的な課題が徐々に顕在化していました。

個々のチームだけではなく、組織全体としてより大きな成果を出すために、必要なことはなにか？

それを考えていった結果、エンジニアリングマネージャーとアジャイルコーチという2つの視点からプロダクトとチームの成長を支えることが一つの答えなのではないか、ということに行き着きました。

本セッションでは、私達が上記の職種の必要性に至った背景と、両者がどのように組織・チームに働きかけるかの構想について紹介します。

このセッションでは、ある現場の社内アジャイルコーチと、その現場を外部から支援するアジャイルコーチ、2人のアジャイルコーチの視点でお話します。

社外のアジャイルコーチに支援してもらうとき、支援した方・された方、片方の視点からの事例を聞くことはありますが、案外双方の立場からの意見を聞くことは多くありません。ですが、ある一場面をとっても、お互い見えているものや感じていることは違うはずです。

本セッションでは、社外のコーチにチームの支援を最初に相談した時・改善の踊り場に来た時といった各場面で、双方のアジャイルコーチは何を見てどんな行動を起こし、どういう結果となっていったかをお話します。

BacklogというWebサービスを題材に、少数精鋭・個人プレイである程度の成功を収めていたサービスにおいて、組織改正の際にリーダーを任されてからの試行錯誤や取り組みについてお話します。

従来までは、チームメンバーも4〜6名程度で、数年間ほとんどメンバーの入れ替わりもなく、阿吽の呼吸でサービス開発を進めることができていました。ですが、リーダーを任されるのと時を前後して、メンバーも10名・20名と着々と増えていき、チームの大多数がスキルは十分なものの文化的な背景を共有できていない状況でした。そのような状況下で、従来型の個人プレイでは行き詰まりを感じており、チームで物事に当たってより大きな成果を出すプロセスへの変換を迫られていました。

本発表では、リーダー改め駆け出しのスクラムマスター・アジャイルコーチが、チームプレイを根付かせるために行ってきた取り組みについて、紹介します。