スクラムとボク
この記事は、マネーフォワード関西拠点 Advent Calendar 2021- Adventar の23日目の投稿です。
株式会社マネーフォワード の 関西拠点 に所属するメンバーのテーマ自由なアドベントカレンダーです。
22日目は杉浦 大貴さんの「銭湯で学ぶプロダクトマネジメント〜僕たちには「ととのう」が必要だ〜」でした。なかなか秀逸な文章でしたね。まだ読んでない方は銭湯に行く前に読まれることをお勧めします。
はじめに
この記事はポエムです。
こんな経験をして、こんなことを考えている人がいるんだな、ということを知ってもらえたらと思い筆を取りました。何らかの形でスクラムに関わっている人の参考になれば幸いです。
僕は現在、株式会社マネーフォワードの関西開発拠点でエンジニアリングマネージャというロールで働いています。そんな僕は自分自身のミッションを「いいチームでいいプロダクトを作れる環境を整える」ことだ、と定義し、そこかしこで吹聴してみます。いいプロダクトを作ってお客さんの課題を解決したい。そのためにはいいチームが必要です。いいプロダクトって何？いいチームって何？という話をし始めるとそれだけで本が１０冊くらいかけそうなのでここでは雰囲気だけご理解いただいた上で読み進めて頂けますと幸いです。そんなミッションを果たしていくための重要な方法論として、スクラムに取り組んでいます。
現状、僕がみているチームでは2年強ずっとスクラムでマネーフォワード クラウド会計Plusというプロダクトを開発していて、LeSSのプラクティスを取り入れながら多チームスクラムをやっています。手前味噌で恐縮ですが、まだまだ伸び代はいくらでもある、という前提をおきつつ本当にいいチームだなと思っています。そして、いいチームをもっと増やしていけたら、会社全体としてもっとお客さんに価値を届けられるのではないか、と考えています。
そんなスクラムと僕の関わりを振り返りながら、どんな経験をした結果、何を得て今があるのか詳らかにしていきます。
スクラムとの出会い
僕が前職の新卒3年目の時にとある研究開発の部門で働いていたのですが、偉い人がこれからはアジャイル開発やっていくべきなんじゃないか、という提案をし、回り回って僕がアジャイル開発が有用かどうかを検討する担当になりました。自分自身、従来の開発手法に対して課題感を持っていた、ということもありアジャイル開発を採用することで開発スピードを高めていく、協力してプロダクトを開発できるチームを作っていく、ということにチャレンジしようという気持ちになったのを覚えています。
とはいえ、アジャイル開発を実現するためには何をやったら良いのか、さっぱりわからなかったので当時有名だった書籍を読み漁り、知識を蓄えて「なぜアジャイル開発をやるべきか」というプレゼン資料を作ってアピールして回りました。
何やらアジャイル開発にも色々とフレームワークがあるらしい、というのがなんとなくわかってきた中で「スクラム」というものがあり、事例なども多くて導入しやすそう、ということでスクラムを採用しました。（ちなみに開発スピードを上げることとアジャイル開発を採用することは全然別軸の話であることにはこの辺りで気づきました）
なんとなく「スクラムやってみよう」という空気感を偉い人を含めて醸成することができたので、次は何を開発しようか、というのを探す必要がありました。（本来作りたいものがあって、それに適したプロセスは何なのか、という順番で考えるべき、というのは今なら理解できますが、当時はそんな頭はありませんでした。。。）
社内を駆け回って開発を検討しているプロダクトを見つけ、つてを辿ってプロダクトオーナーをやってくれる人を口説き、開発チームを結成して準備を整えることができました。自分はスクラムマスターのロールでそのプロジェクトに関わることになりました。
当時の自分はスクラムマスターをプロジェクトの成功のためになんでもやる人、という認識だったのでバックログの管理からプロダクトオーナーのサポートから実装までなんでも手を出してやっていました。
無事にリリースするところまでやれたのですが、そのタイミングで人事異動があり、そのプロジェクトとはお別れになってしまいました。
新規事業開発をスクラムでやるぞー
異動後はWebサービスを手がけるグループ会社に出向して、2年くらいウォーターフォールなプロジェクトでプロジェクトマネージャとして開発をやりました。そこで出会ったPMOの方にPMBOKの基本と実践を教えていただき、正しく変更管理をされたウォーターフォール開発というのを経験して多くのことを学びました。これは自分にとってとても良い経験で、ここで培ったプロジェクトマネジメントのスキルはスクラムをやっていくにあたってもとても役に立つこととなりました。
しかし、そんな日々も唐突に終わりを告げました。そう、新規事業に向けたプロダクト開発が始まることになったのです。プロジェクト開始に伴って何やかんやありましたが、「あのアジャイル開発の好きな人」というラベルがついていた自分が担当するということでアジャイル開発でやってみよう、という話に持っていくことができました。経験がある、ということで今回もスクラムを採用することとしました。
久しぶりのスクラムでまたもスクラムマスターとしてプロダクトに携わることになったのでかなり息巻いてやり始めたのですが、書籍に書いてある通り、最初の１ヶ月は本当に何もできあがらない、という状態になりました。そう、文字通り何も。経営陣にスクラムの最初の１ヶ月ってこういうものなので徐々によくなっていきます、と説明しつつ、冷や汗が止まらなかったのを今でも覚えています。
そんな状況を変えるために、できることはなんでもやりました。とにかくコミュニケーションに問題がありそうだ、ということがレトロスペクティブから明らかになっていたので、全てのslackの会話、全てのRedmineチケットの更新履歴に目を通して、何が起こっているのかどこで情報が分断しているのかを明らかにして色々と手を打っていきました。余談ですが、最初の頃のレトロスペクティブは午後から初めて深夜にまで及ぶ白熱した議論になっていました（今ならちゃんとタイムボックスを決めてやりましょう、っていえますが当時はそんな余裕も知恵もありませんでした）。そんな甲斐もあって３ヶ月くらいするとコミュニケーションの課題も解消され、チームの目指す方向が揃ってきたのでいい感じにスプリントが回っていくようになり、ベロシティも安定してきました。
そこからは事業の成長のためにチームをグロースすることをビジネスサイドから求められ、最大30人くらいの体制でのスクラムとなりました。当時は大規模スクラムの知見がなかったのですが、結果的にはScrum@Scaleのような形のプロセスを考えて、実践していきました。チームの人数が増えていくのに比例してベロシティも伸びていき、チームのグロースに成功した、という手応えがあったのを今でも覚えています。
しかし、そんな日々も長くは続かず、健闘虚しくサービスはクローズすることになってしまいました。あれだけのアウトプットを出せるチームを解散しないといけないのはシンプルに悲しかったです。しかし今思うとアウトプットは出せていましたが、アウトカムは出せていなかっと思います。まさにビルドトラップに囚われていたのでは、と今となっては反省しています。（ちなみにアウトカムとは何か、という点については冒頭の杉浦さんの記事をぜひ読んでみてください。）
プロダクトマネージャに挑戦するも・・・
それでもめげない僕は次は自分で事業の舵取りをしてみたい、と前職にはなかったプロダクトマネージャというロールを勝手に作り出し、別の新規事業を始めました。どうやってユーザー体験を作っていくのか、プロダクトマネジメントとして必要だと思われることを試行錯誤しながら検討を進めていきました。
そこまで予算が大きなプロジェクトではなかったため、自分が思い描くものを作るためにはプロダクトマネージャ兼スクラムマスター兼システムアーキテクト、みたいな全ての役割をこなす必要がありました。さらにサービスグロースのためにマーケティングについても方針を検討したり、広告運用のマネジメントをしたり、事業計画を書いたり、手が足りない部分は自分で実装したり、本当に何でもやりました。
このプロジェクトの中で今でも印象に残っているのが、チームビルディングの大切さです。このプロジェクトはいわゆるオフショア開発で行っていたのですが、オフショア先のエンジニアにプロダクトのビジョンや戦略を（用意しておいた）英語で語ったり、ユーザーインタビューの様子を翻訳しながら伝えたりすることで、どんどん一体感が増していってエンジニアたちからいろんな提案が出てくるような状態まで来ることができました。ここでスクラムにおけるチームビルディングの大切さや、プロダクトでワクワクできることの大切さを学日ました。
しかし、全てを自分で抱え込んで事業を進めていく状況は負荷が高かったです。その結果、無理がたたってしまって精神的に少し落ち込んでしまったり、サービスもクローズの方向に進んでいったり、そもそも感じていた会社の方針への違和感が自分の中で折り合いがつけれなくなったりしたことで新しい道を探したくなり転職することを決意しました。
ただ、ちゃんと自分でサービスをクローズせずに退職してしまったのは本当に無責任でしたし、残されたメンバーには本当に申し訳ないことをしてしまったと反省しています。
エンジニアとして参加したスクラム
そんなこんなでマネーフォワードに転職してきました。そして初めてエンジニアとしてスクラムに参加することとなりました。
プロダクトマネージャやスクラムマスターを経験した上で、エンジニアとしてチームにジョインできたのはすごく価値があったと思います。
スクラムの中で発生する様々なことに先回りして対応できるし、プロダクトマネージャの気持ちや考え方も理解できるのでエンジニア、プロダクトマネージャ間の翻訳係としても貢献できたと思います。
レトロスペクティブにおいても過去の知見を活かしつつ、いろんな提案ができますし、スクラムマスターとしてファリシテーションするという立場でもないので自分の考えていることをどんどん発信できてそれはシンプルに楽しかったです。
今までいろんなロールをかけもちながら仕事をしてきたので、初めて１つのことに集中して没頭してコードをかけたのは自分にとってめちゃめちゃ楽しかったですし、財産になりました。やはり自分はコードを書くことが好きなのだ、ということを実感しました。
また、素敵なスクラムコーチの大友さんに出会えたのも大きかったです。「なぜスクラムをやるのか」であったり、「デュアルトラックアジャイル」という考え方に触れて、プロダクトマネジメントとスクラムのループを体系的に理解することができましたし、ファシリテーションやコーチングの真髄というか、自分に足りないものを自覚することができ、何を改善していけばいいのか、多くのヒントを頂きました。
エンジニアリングマネージャとしてスクラムと向き合う
しかし、そんな日々も長くは続きませんでした（そればっかり）。
前任のエンジニアリングマネージャが退職することとなり、マネージャをやってみないか、という打診をいただきました。本音を言うとマネジメントをするより自分でコードを書く方が好きなのですが、プロダクトやチームのために自分にできることがあるならやってみようと思い、やらせて欲しい、と返事をしました。
プロジェクトマネジメントは長年やってきましたがチームマネジメント、ピープルマネジメントをするのは初めてだったので、最初は本当に何をどうしたら良いのか分からなくて右往左往しましたし、メンバーを不安にさせてしまったこともあったと思います。エンジニアリングマネージャになって最初の１、２ヶ月は人生で初めてご飯が食べられなくなりました。（注：筆者はチーム１の大食いなので、食べられなくなっても人並みには食べてました）
マネージャになってからも関西開発拠点のコンセプトである「Give it a Try」の精神で色々なチャレンジをして、上手く行ったり行かなかったり、いろんな経験をしてきました。
上手くいった例としては、スプリントレビューに実際にプロダクトの販売をしているセールス部の方や、お客様からの問い合わせを受けていただいているカスタマーサポートの方をお招きしてデモを実施するようにしてプロダクトへの素早いフィードバックを頂いたり、お互いの関係性が向上したりしました。他にもメンバー数の増加に伴いLeSS（Large Scale Scrum）のプラクティスを利用して多チームスクラムに移行することにチャレンジし、今では複数チームで安定した開発ができるようになりました。
逆に上手く行かなかった例としては、他チームへの留学制度を作ってチーム間の交流やスキルアップを実現しようとしたのですが、狙ったような効果が出なかったり、当時は今ほどチームが大きくなかったため開発リソースを集中したい、ということで中止せざるを得なかったりしました。他にもプロダクトを改善していくために必要と考えて技術スタックの拡充などにもチャレンジしていきましたが、しっかり根付いたものもあれば、うまく行かずにペンディングしているものもあったり、ということもありました。
多くのチャレンジした結果、いっぱい失敗しはしましたがそのフィードバックを活かしてきたからこそ今のチームがあると思います。
そして、もう１つ分からなくなったのがスクラムとの関わり方です。チームの中でコードを書く、と言うのは引き続きやっていたのでスクラムチームの一員ではあったのですが、スクラムマスターではないし、マネージャとして何をミッションとしてチームに貢献すべきなんだろうというので悩んでいます。ここでもスクラムコーチに相談することで自分の立ち位置や役割を認知することができ、エンジニアリングマネージャとスクラムの関係について解像度を高めていくことができました。
エンジニアリングマネージャは組織課題を解決するのがミッション、という当たり前の結論が僕なりのスクラムとの関わり方だと現在は考えています。この考え方をキャッチーに伝えたい、ということで考えたのが冒頭の「いいチームでいいプロダクトを作る環境を整える」です。校長先生よろしく、この言葉をことあるごとに唱えることでみんなに浸透させて、いいチームとプロダクトを増やしていきます。
最後に
横道に逸れますが僕は大学時代、ゲーム理論をベースにしたアルゴリズムの研究をしていました。ゲーム理論には「囚人のジレンマ」や「牧草地の悲劇」など非協力ゲームの難しさが語られていたりします。しかし、非協力ゲームを協力ゲームに変えることでそのような状態を回避できる、という理論を今でも強烈に覚えています。同じ目的をもつ集団が協力するだけで良い結果が出せるのです。つまり協力し合ういいチームができれば結果は出せるはずです。しかし、現実はなかなかそう単純にはいってくれません。でもその課題を解決できる手段や思想としてスクラムというのは有効だと考えていますし、その思想が僕は好きです。
つらつらと自分語りをしてしまいましたが、プロダクト開発に関わる中で長い付き合いになったスクラムにこれからもコミットしていきたい気持ちが強いですし、もっともっといいプロダクト、いいチームを作っていきたいです。
そのためには同じ目的を持って進んでくれる仲間が必要です。エンジニアやデザイナーはもちろんのことですが、専任でスクラムマスターをやりたい方も大募集してますのでまずはカジュアル面談などを通して、お話しできると喜びます。
Money Forward 関西拠点 Advent Calendar 2021 - Adventar 、 明日は24日目、吉岡さんです！
この記事が気に入ったらサポートをしてみませんか？