POLに入社して組織のアジリティを高めるためにやってきたことをふりかえる
こんにちは、株式会社POLでソフトウェアエンジニアをしているmotikomaです。最近の趣味はエルデンリングの実況を鑑賞することです。
さて、今回はPOLに入社してから組織のアジリティを高めるために自分がやってきたことをふりかえりたいと思います。
※「大規模な組織変更！」とかそんな大層なことはしていません。一人の開発者として自分が楽しく開発したいというモチベでやったことを書きます。
アジリティとは
アジリティ（Agility）には「敏しょう性」「軽快さ」といった意味があります。ビジネス的には状況の変化に素早く柔軟に対応できる力と言ったニュアンスで使われることが多いのではと思っています。
会社全体に対する取り組み
「エンジニアリング組織論への招待」の輪読会を企画
前職でも「エンジニアリング組織論への招待」を輪読したことがあるのですが、POLに入社してからも再度実施しました。「不確実性に向き合う思考と組織のリファクタリング」という副題が掲げられおり、アジリティを高めるために知っておくべきことがまとまっていると感じています。また、「事業に関わる全員と同じ言葉で会話できるようになるとめっちゃ仕事楽になるんじゃね」と思っていたので、参加者は開発者に限らず開催しました。参加者自体はそこまで多くなかったのですが、隣接組織のメンバーと同じテーマで意見交換することができて良かったです。
隣接組織に対する取り組み
カスタマーサクセスチームに対するアジャイル開発研修
カスタマーサクセスチームのメンバーから「カスタマーサクセス業務を進める際にアジャイル開発のエッセンスを参考にしたい」という相談があり、アジャイル開発研修を実施しました。
「アジャイル開発って何ぞ？」という深淵な問いについに答えを出さなきゃいけないのかと一瞬絶望しましたが、普通に「アジャイルソフトウェア開発宣言」と「アジャイルソフトウェアの12の原則」に読み合えばいいじゃんということで直ぐにことなきを得ました。
構成としては下記のような感じで進めました。
自己紹介とどんなこと考えているのか
アジャイルについて理解を深める
スクラムについて理解を深める
プラクティスについて理解を深める
今回の研修はカスタマーサクセスチームが自分達の状況に合わせて業務を少しずつ改善するイメージを持てれば成功と思っていたので、まず最初に研修を通してどうなりたいと考えているのか？を話し合いました。そこで得た問いを元に「アジャイルソフトウェア開発宣言」と「アジャイルソフトウェアの12の原則」を読んでいきます。その際には自分の方で事前に両者はこんな感じに整理できるかもという枠組みを図化して話を進めました。個人的には具体的な取り組みよりも価値や原則を先に理解してもらうことで、自分達の業務に活用するプラクティスを生み出してもらえるんじゃないかという期待がありました。
その後はアジャイル開発を進める際のフレームワークとしてスクラムを説明したり、プラクティスとして「相対見積もり」「1個流し」「モブワーク」などを説明していきました。
参加者からは概ね好評だったので、実施して良かったです！私としては「こちらこそアジャイル開発に興味を持ってくれてありがとう！」という気持ちでした。
カスタマーサクセスチームのお客様要望報告フォーマット変更
もともとカスタマーサクセスチームがお客様からヒアリングした要望をSlackのフォームでプロダクトチームに報告するというフローがありました。ただ「要望よりもその背景にある状況と課題を整理したい」と考えていました。そこで、カスタマーサクセスチームに上記の旨を伝えつつ、フォーマットを下記のように変更しました。
種別：フィードバック or 不具合報告
利用状況：具体的にイメージできるように記載してもらう
課題：要望の背景にある課題を記載してもらう
解決策：要望 or 自身が考えた解決策を記載してもらう
メモ：気になったこと何でも書いてね🌟
「いきなり要望の背景にある状況や課題を記載してほしいと言われても、ただでさえ忙しいし難しいかもな…」と思っていたのですが、従来報告されていた内容と比較して、「ユーザーの利用状況が具体的に脳内で再生できるぞ…!」「これは課題っぽいな」という内容が報告されるようになり感謝の念が絶えません。
報告された内容をもとに施策を考えることもありますし、さらに利用状況を深掘りするべくプロダクトマネージャーや開発者が直接カスタマーサクセス担当者に話を聞きに行くこともあります。利用状況と課題がイメージできると次のアクションをどのように取るべきか考えやすくなった気がします。
利用状況の変化を適切にキャッチアップするという意味ではアジリティを高める際の前提として役に立っているのではと考えています。
自チームに対する取り組み
スウォーミングを促す取り組みを推進
幸運なことに自分がジョインした段階で機能横断的なチームでアジャイル開発を実践できていました。さらにより良くするにはという観点で、下記のスウォーミングを促す取り組みを徐々に推進していきました。
プロダクトバックログをユーザーストーリー（価値単位）で再構成
ユーザーストーリーの受け入れ条件をみんなで確認する
スプリントゴールを導入
モブプロ, ペアプロを推進
Gatherを導入して話しかけやすい環境構築を推進
フロー効率性を意識して、ユーザーにインクリメンタルかつイテレーティブに価値を届けること。また、スプリントごとにプロダクトバックログアイテムの優先度を見直し、優先度の高いものから対応することで、状況の変化に素早く柔軟に対応できつつあるかなと。
チェッキング, テスティングに関する取り組みを推進
プロダクトを利用してくれるユーザーに申し訳ないのでなるべく不具合を減らしていきたいなという思いから、テスト駆動開発やQAについて集中して勉強しました。なお、参考にした書籍やスライドの一部はこんな感じです。
勉強した内容を整理して社内ドキュメントとして参照できるようにしてメンバーに共有しました。日々の開発でテストコードを書く際に見返しています。もともとUXリサーチを生業としていたので、QAが要求定義段階にも踏み込んでいたということを知ることができて俄然学ぶモチベーションが上がりました。やっぱり、ユーザーに愛されるプロダクトを作っていきたいですからね。
テストコードがあることによってリファクタリングしやすくなるため一定の内部品質を保つことにつながり、QAによって要求定義の不備や機能の不具合の発見を出来るだけ前倒しにすることで、状況の変化に素早く柔軟に対応できる土台となるのではと考えています。
ベイビーステップかつ高頻度でアジャイル開発について考える機会をもつ
アジャイル開発について集中して勉強する時間も必要だと思いますが、チームとして日々の開発で実践するにはもっと高頻度で触れる機会があった方がいいのではと考えました。そこで、毎日夕会で「いちばんやさしいアジャイル開発の教本」を少しずつ読み合うことにしました。
上記の本は見開き2ページで1テーマを紹介しているため、ちょっとずつアジャイル開発についてお互いの考えを話し合うためには最適な本でした。
他にも「スクラム実践者が知るべき97のこと」なども見開き1テーマ形式なので読んでみたいと思います。
※最近はちょっと休止していたのですが、チームも変わったのでそろそろ再開したいと考えています！
まとめ
POLのメンバーで「アジリティ高くしていきたいよね」と共感してくれる人が増えると嬉しい。そのためには自分ができることを少しずつやってきたし、これからもやっていくぞいという話でした。
プロダクトは一人で開発しているわけではないので、自分だけがアジリティを高めたいと思っていても意味がありません。また、自分が一方的に教えるという関係も変だなと思っています。だからこそ、メンバー間でお互いに考えていることを話し合う機会が重要だなと考えています。メンバー間で共通言語で大事にする価値観が醸成されると組織文化になるのかなと。
また、組織文化 = 体質のようなものだなと考えており、日々の取り組みは漢方薬みたいなものだと考えています。いきなり変化を求めると体もびっくりしちゃうので、ゆるゆるとやっていければなあと思っています。