こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
プロダクトの革新を支えたの開発組織づくりについて、現クリエイティブサーベイCTO鈴木康寛とHelpfeelCTO秋山博紀がLT, パネルディスカッションの形でぶっちゃけトーク！
マネジメントを行う上での苦労や取り組みについてお話しします。
会の様子
スクラム導入と透明性のための実践プラクティス〜CTOとして1年間スクラムと向き合った結果〜 by suzukiさん
スクラムガイドを読むと、How寄りの部分に注視してしまいプロセス重視の開発になりがちですが、スクラムの理論と価値基準を重視することでうまくいくという話がありました。
特にクリエイティブサーベイでは「透明性」を重視しているということで、GitHubのIterationやカスタムパラメータのEstimateを活用してプロセスの可視化を行っていたそうで、Ruby/Railsのバージョンアップやコンテナ導入、インフラのコード化、OpenAPIによるスキーマ駆動開発の導入など技術的負債の解消に成功できたそうです。
また、技術的負債の解消のみならず、Notionを活用してプロダクトバックログを刷新することも目指したということで、技術的課題とプロダクトが解決する課題両方を解決できたということでした。
スクラムしない組織のアジャイル論
続いて、スクラムではないアジャイル開発を実践しているHelpfeelの秋山さんから発表がありました。
秋山さん的には、アジャイル開発とウォーターフォールの境目は「エンジニアの人数を増やそう」という話が出始めたときだと考えているそうで、ランウェイの終わりが見えたときにアジャイル開発かウォーターフォールか？という話がHelpfeelでも出始めたそうです。
この議論が出始めた後は、アジャイル開発としてスクラムを導入するか議論になったそうですが、Helpfeelではスプリント単位に区切りつつ目標設定やスプリントごとのふりかえりはしない(=スクラムをやらない)決断をしたということで、結果的にランウェイをぐっと伸ばすことができたということでした。
それを踏まえて改めてHelpfeelのアジャイル開発をふりかえると、
- ドッグフーディング重視
- プロダクトマネジメント的発想(ハッカー気質)
- 自律的・自己組織的なチーム編成
が特に成功に寄与したと言えそうだということで、組織に合わせたカスタマイズの重要性を実感したということです。
パネルディスカッション
登壇後は、登壇したお二方のパネルディスカッションがありました。以下、常体で話があった内容を記載していきます。
- スクラムを前提としたツールの成長が伸びているので、標準的にはやるんだと思う
- やらない選択は勇気があるくらいのレベルにはなっていると思う
- 一方で、スタートアップだとプロダクトマネジメントの上手さレベルでスクラムをやっている/やっていないが変わるので、そこは相性の悪さを少し感じてしまう
- ステークホルダーとの会話からプロダクトづくりするところを開始した結果、スクラムに近い形になった
- 秋山さんは何でもかんでも情報公開すれば透明性が上がるとは思わないということで、透明性ある組織をどのように作っていくのか？に問題意識を感じている
- 情報の濃淡によって出すチャンネルを変えるというのは絶対に必要(意図的に壁を作るようにしている)
- 透明性に関するテーマでスクラムの話がされているのをあまり見ないので、今後深めていきたい
- Railsを3->7に上げることができたのは、自動テストが充実していたことが原因だと思っている
- Helpfeelのデザイナーは自律的にチームの中でデザインに関する課題を発見するような仕組みになっている。ただし、これはデザイナーに対して高い負荷を与えているとも言えるため、どうするべきか悩んでいる。また、現在フロントエンドが書けるデザイナーしかいないので、スケールできるかというと難しいと感じている
- 自律的にメンバーが進んでいる一方、プロダクトとしてどういう方向性で進んでいくのか？はCTOなどが中心にはっきりと明示している
会全体を通した感想
各社のスクラムに対する考え方が聞けて、興味深かったです。
アジャイル開発やスクラムをしたことでどのように利益や成果に結びついたのか？の部分がもっと聞けると面白いなあと感じました。
