半年で会社全体をアジャイルになるまでやったこと
外部の人含め３０人ほどのスタートアップに転職して、開発組織から会社全体までをアジャイルになるまでやったことをnoteにまとめてみました。アジャイルって結局なんなんだろうと思っているエンジニアの人に少しでも何か考える参考になれば嬉しいです。
（注）コロナ前で対面コミュニケーションができていた頃の話となります。
（注）スクラムに関連する用語については説明していません
転職前
転職前は電子書籍サイトを運営している会社でシステム開発の責任者をしていました。組織的にはサービスを考える部署とシステム開発をする部署が明確に分かれた職能別組織で、社内受発注的な関係で開発を回していました。
WEBディレクターがパワーポイントに画面仕様などをまとめ、エンジニアは技術的に出来る出来ないを判断し開発・テストをしていました。
これまで私は複数社転職を経験していますが、このスタイルに特に不満を感じておらず、開発組織としては如何に品質を上げたくさんアウトプット出来るか、コスト面では開発人員数を会社状況に合わせて調整出来るかが自分のミッションだと考えていました。
スタートアップに転職、そしてめちゃくちゃな開発
縁があってM&Aをオンライン上でマッチングさせるプラットフォームをやっている会社へエンジニア１号社員として転職しました。それまでSESエンジニア数名で開発をしてたのこと。
そしてめちゃくちゃな開発を目の当たりにしました。
開発の管理方法の問題：
・Backlog上に100件を余裕で超える開発リストがある
・ほぼ全てが優先度高に設定されている
・Backlogのチケットはタイトルに機能名だけ書かれ中身が書いてない
・Backlogとは別にスプレッドシートでタスク管理されている
・Backlogにもスプレッドシートにもない開発タスクがslackで突然やってくる
etc...
開発フローの問題：
・WEBディレクターが複数在籍していたが、それぞれ独立してエクセルで要件定義しているので他ディレクターとサービスの整合性がとれていない
・要件定義の内容は作成者によってレベルがバラバラ
・壮大なエクセル要件定義書で代表と何度もレビューを繰り返し、一向に開発に進まない
・機能仕様だけつくるので、担当者は目的不明なまま作る物だけ決めて、効果測定もしていない
・数ヶ月かけてリリースした機能はほぼユーザに使われず、技術的負債となる
etc...
要件書通りにエンジニアは開発する形で回っており、このほかにも技術的な課題もたくさん。今思い返すだけでお腹が痛くなる状態でした・・・。
そんな中、「良く分からないアジャイルにしたら何か良くなるんでしょ？」的なことを代表が言っているのを聞きました。
転職早々こんな状況では長く続けられないと思い、アジャイルという単語だけを利用し「この状況だとエンジニアはみんな辞めるし、リファラルで紹介もしたくない。なので、ちゃんとしたアジャイルしましょうよ！」と代表に提案したのがアジャイルへの始まりでした。
・変えるきっかけにバズワード的に使われていた「アジャイル」を利用した
１ヶ月目 その１：社内LTで「アジャイルを勉強してみた」を発表する
LTを社員で持ち回り発表する文化があったので、その場でまず自分が何をしようとしてるのかを発表しました。入社間も無い自分が「全部変えよう！」と宣言しても反感を買いそうだったので「勉強してみた」程度で。。。
（ネットコピペレベルのLTスライドの一部）
なぜスクラムにしたのかというと、アジャイルといえばスクラムでしょ！程度の知識でしたが、まぁ最初はこれで良かったと思ってます。
・内容はともあれアジャイル？スクラム？とか言ってる人と社内で認識してもらう
１ヶ月目 その２：とりあえずやっみよう！な仲間を見つける
LT後、1on1などをする中で、同じ方向で一緒に改善を進めてくれる仲間を見つけることができました。社員１号で代表にも口論で負けないパワフルなMさん、知らないところで物事が決まることに不満だったマーケ担当さん、外部会社だけど社歴の長く代表にも信頼されてるSさん。
一緒にとりあえずやってみよう！なノリで推進してくれる仲間ができたことで、短期間で変革できたと思ってます。感謝。
・まずはやってみよう！は複数人で勢いで始める
２ヶ月目 認定スクラムマスター研修を受講。まずはスクラム初めてみる
会社負担で研修費用をGET。Odd-eが開催している認定スクラムマスター研修を３日間受講しました。
学んだこと
・中央集権型組織でスクラムをやるのは難しい。チーム中心組織が望ましい
・日本語の「責任」は英語では２つの意味がある。「accountability：過去に対する責任(人につく責任)」「responsibility：未来への責任(人につかない責任)」
・スクラムマスターには未来への責任がある
・スクラムマスターは組織の中で一番課題に気づく人であること
・論理的に再現できる方法で説明すること
・スクラムにプロジェクトマネージャーは存在しない
・ベロシティーを指標にするのは間違い
・意思決定に納得感という曖昧なものは要らない。とりあえず実行、よかった物だけ残ればよい
etc...
研修後、会社でまずは開発メンバー全員でスクラムガイドを読みつつ、こちらの本を参考にスクラムを初めました。
・デイリースクラムで誰が何をしているか全員がわかるようになった
・スプリントで開発サイクルにリズムができた
・話しやすい雰囲気がうまれた
３ヵ月目 アジャイルコーチの教えとスケボーと
社内でたまたま繋がりがありアジャイルコーチの原田騎郎さんに２ヶ月ほどアジャイルについてコーチングを受ける機会をもらえました。
エンジニアだけでなく代表やマーケ、広報などの人も含めワークショップをすることで、アジャイルな考えが全体にちょっとずつ広がっていきました。
教わったことの一部
・プロダクトバックログを価値を提供できる最小まで考え、開発しないで出来ないか考えること
・エンジニアは直ぐに開発したがるのをグッと堪えること
・（Opsチームが無い場合）ベロシティーの70％くらいの開発量にする
・エンジニアに時間の余裕を持たせれば、勝手に何か始めるので常に余力を持たせておくこと
・残業はしない
・使えないホワイトボードペンは直ぐに捨てる
・スプリント中のDoingなタスクを増やさない（チームで片付ける）
・デイリースクラムは報告をする場では無い。困っていることをチームに伝えて助けてもらう場
また、社内でMVP(Minimum Viable Product)について話す際、アジャイルで有名な画像を使い何度も説明するようにしました。
“The Myth of Incremental Development” by Herding Cats under CC BY-NC-ND 3.0
これにより「そのバックログ、スケボーじゃ無いよね？」「まずはスケボーでやりましょう」などバックログはスケボー（MVP）であるべきという考え方が浸透していきました。
・スケボー（MVP)になっていないものは砕いて小さく、でも価値を提供できるサイズに
４ヶ月目 ユーザーストーリーマッピングをやってみる
ユーザーストーリーマッピングとは、ストーリー(ユーザーにとっての価値)を付箋紙に書いて、ユーザーの体験順に時系列で整理する手法です。
これを実施する際に、M&Aの実務に詳しい顧問の人に実際に入ってもらい一緒にワークショップをこなすことで、かなりエンジニアも業務知識をつけることができました。
また、ユーザ視点に立つことでユーザのペインとなってそうな仮説を考えるようになりました。
この「みんなで考える」が非常に大事であり、言葉や絵を使って共通理解をつくることにより、「なぜこれが必要なのか」の認識が統一されることにあると思っています。
ユーザーストーリーマッピングを始めたことにより、壮大なエクセル要件定義書は無くなり、付箋に書かれた画面イメージから最小限のスケボーを、エンジニアがすぐに開発できるようになりました。
また常にスプリントに入る大きさかを考えているので、見積に時間のかかり目的不明で複雑な開発も無くなりました。
・ユーザーストーリーマッピングは会話してサービス全体の機能(価値）の抜け漏れを出して、優先すべきストーリーの共通認識を作る
５ヶ月目 その１：プロダクトバックログを大きな付箋で壁に貼る
会社として今取り組んでいることを全社員で共有できるようオフィスの壁にプロダクトバックログを貼るようにしました。
バックログは誰でも書くことができて、プロダクトオーナーはもちろんエンジニアもほぼ毎日新しく貼られたバックログを見ながら「これは良さそう」「これは課題がまちがえてないだろうか？」など自然と話し合うようになりました。
また、このバックログにはあえてHow（どのようにつくか）を書くことはNGとし、どのように実現するかはプロダクトオーナーとエンジニアで決めるようにしていました。
その他工夫したことは以下の通り。
・あえてバックログに記入者名を書かない（役職が高い人の意見をバックログの優先度に加味しないため）
・バックログにたくさん情報を書きすぎないように、太いペンだけ用意した
・良さそうにみえるバックログにスタンプを押せるようにした（POが優先度を決める参考にするため）
・優先度が常に後ろに下がるバックログは「冷蔵庫」コーナーに移動し定期的にゴミ箱に捨てた（必要ならもう一度出てくるはずなので）
・大き過ぎるバックログは検討行きボードへ移動し適宜ユーザストーリーマッピングや、非開発で検証できないか検討するようにした
・redashなどでリリースしたものが効果あったかどうか効果測定をエンジニアでも実施するにした
・スプリントプランニングでHowを考える
ちなみに大きな付箋はこちら↓
５ヶ月目 その２：スプリントレビューでフィードバックをもらう
スプリントの最終日に全社でスプリントの成果をデモするスプリントレビューを実施するようにしました。開発したものをレビューして共有するのと、その場でいろいろな人からフィードバックをもらえるようなりました。
アジャイルを始める前はリリース直前に、「やっぱりこれ、こうじゃ無い！」と鶴の一声がよくありましたが、小さく作って早くユーザのフィードバックを得ることに重点を置くようになった結果、そのようなことはほとんど無くなりました。
・レビューを会社全体ですることで「そんな機能知らない」が無くなる
・ユーザに価値が提供（価値を検証できる状態）であればレビューOK
・細かい指摘は次のスプリントに回せば良い
６ヶ月目 ユーザの声を直接聞きに行く
高齢化などで後継者がおらず廃業していく企業がたくさんある中、M&Aで少しでも良い事業が残っていければと思い働いていました。
営業の人と同行することで、M&Aに成功した社長さん、廃業寸前の地方のペンションのオーナー、売上低下で別事業を考える新聞配達会社の経営者などたくさんのお話を聞くことが出来き、様々な課題を抱えているということを知りました。
オフィスの中だけで想像しながらユーザストーリーマッピングをしても、この機能は良さそう・作ろうではダメだと気づかされました。如何に自分ごとに考え真剣に考え、プロダクト開発に取り組めるかが重要だと思いました。
・オフィスにいても本当の課題はわからない
・スケボー（MVP）の質を上げる
・エンジニアだろうがプロダクトオーナだろうが、肩書きなど関係なくチーム全員が同じ課題解決に向かっていること大事
最後に
最初は目先の課題を解決するために、アジャイルをスクラムから始めた訳ですが、
→ スクラムを学び、まずは形から実践してみる
→ スプリントにバックログを投入するために、小さく（MVP）にしたくなる
→ 小さくするためには業務知識やユーザ課題を理解しないとけない
→ 価値について考えるようになる
→ 直接ユーザの声を聞きたくなる
→ 全員の目指すところ(Vision）が同じことが重要と考えるようなる
スクラムをきっかけに組織は社内受発注な関係ではなくなり、チーム全員にプロダクトを通して社会を良くしたいというモチベーションが高くなったと感じています。
最後にアジャイルがあった方がいいと思う組織と、要らないと思う組織について考えをまとめてみました。
アジャイルがあった方がいいと思う組織
・もっと成長するために、小さく学習ループを回し学びを得ていきたい組織
・VUCAな時代なので変化に柔軟なプロダクト開発をしたい組織
・エンジニアであっても技術を超えた貢献を求めたい組織
アジャイルが要らないと思う組織
・決まったことをやっていれば売上を維持でき、大きな成長を望まない組織
・トップダウンの指示通りに動くことを求める組織
・エンジニアは開発リソースだと思っている組織
この記事が気に入ったらサポートをしてみませんか？