Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

Scrum Fest Osaka 2023 に協賛します&登壇します

こんにちは、関西開発拠点に所属し、マネーフォワード クラウド会計Plusでスクラムマスターをしています、堺(@yukke3duck)です。

マネーフォワードは、6月30日(金)〜7月1日(土)に開催されるScrum Fest Osaka 2023を、ゴールドスポンサーとして応援させていただきます!

Scrum Fest Osaka 2023 とは

Scrum Fest Osakaはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。この2日間を通じ、参加社同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。

【開催概要】

  • 日時:2023年6月30日(金)〜2023年7月1日(土)
  • 場所:オンライン と オンサイトでのハイブリット開催
    • オンライン会場は、Discord
    • オンサイト会場は、こちら
  • 主催:Scrum Fest Osaka 実行委員会

【参加申込】

以下のイベントページよりお申し込みください。 https://www.scrumosaka.org/

オンライン会場のDiscordでは、マネーフォワードのスポンサーブースチャンネルが設置される予定です。 登壇内容に興味持たれた方、マネーフォワードに興味ある方、気軽にお越しくださいー

登壇者&セッション

Scrum Fest Osakaのセッションは公募されていました。 昨年は、マネーフォワードから3名登壇させていただきましたが、今年も業務委託の方を含む3名が登壇予定です! (うち1名は、なんと2本採択されています!!)

また、スポンサー枠でも、登壇予定です!

以下で、セッション概要をご紹介させていただきます。興味を持たれましたら、ぜひご参加ください! ※内容は更新されていることがあります。興味を持たれましたら、各タイトルのリンク先から最新情報をご確認ください。

7月1日(土) 10:00〜10:45 【スポンサーセッション】会計SaaSで実践するアジャイルテスティング

登壇者

Keisuke Ookura(@okeicalm

概要

会計SaaSというドメインの複雑なプロダクトに対して、チームで品質保証を実現するために実践しているアジャイルテスティングのような事例を紹介します。

  • 1週間というタイムボックスの中でテスト活動をどのようにフィットさせているのか
  • QAエンジニアがスクラムチームの中でどのような活動をしているのか
  • 誰がどのようにテスト活動を実施しているのか
  • どのようにテスト自動化を設計し、運用しているのか
  • 今、課題となっているのは何か

対象者

スクラムチームにおける品質保証の実践について興味のある方

7月1日(土) 13:00〜13:20 形だけスクラムから熱いスクラムチームに変貌したきっかけは内発的動機づけだった

登壇者

Daisuke Ashihara(@ashihara_d

概要

スクラムフレームワークに沿ってイベントをこなしながらプロダクトを作る。

一般的なスクラムを進める中で、ふと違和感を持ったことありませんか?

「ウォーターフォール開発を短期間で分割して開発してるだけでは・・」

「ラグビーチームのような一体感を持ったイメージと何か違う・・」

私がスクラムマスターを担当した ”とあるチーム”も、上記のようにスクラムを淡々とこなしているチームでした。

プロダクトの価値やチームの成長について熱く語るようなチームになって欲しいと願い、スクラムマスターの立場から色々とチームに働きかけても変化を起こせずにいました。

そんなある日、ちょっとしたことがきっかけでチームが生まれ変わりました。

それはチーム内から起きた内発的動機付けによるものでした。

生まれ変わったチームは、優れたプロダクト体験・機能を素早く届けることにこだわり、メンバー間が相互のタスクに興味を持って助けあい、スプリントゴールを懸命に追いかけるようになりました。

振り返ると劇的な変化が起きたので、他チームでも活用できるようにいつか情報を整理したいと思っていました。

今回の発表はちょうど良い機会なので、チームを変えた内発的動機付けについて考察のうえ言語化したいと思います。

対象者

スクラムフレームワークをこなす以上の状態になってない(なりたい)スクラムチーム

7月1日(土) 14:00〜14:20 スクラムアンチパターンを踏みまくったときの話をしようか

登壇者

Daisuke Ashihara(@ashihara_d

概要

スクラムうまくいってますか?

うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。

つまり守破離って大事ですよねと。

”スクラム アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ!」と散々警鐘が鳴らされています。

そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。

例えば・・・

  • エンジニアが3人未満のチーム構成
  • 全員が他の開発業務を掛け持ち
  • スプリントバックログが常に終わらない
  • 不完全なインクリメントでスプリントレビュー
  • デイリースクラムをやめる ...etc

なぜ安直なアンチパターンを踏みまくったのか。

起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。

アンチパターンを踏みまくった結果、このチームやプロダクトはどうなってしまったのか。

スクラムアンチパターンを踏みまくったときの話をしようか。

対象者

自チームでスクラムを行っているエンジニアリングマネージャの方、またはエンジニアリングマネージャとの関係性に悩んでいるチームメンバーの方

7月1日(土) 14:00〜14:20 転職したので社内にアジャイルコミュニティを作ったら、思いの外楽しくなってきた〜!!

登壇者

Yusuke Sakai(@yukke3duck

概要

スクラムマスターは孤独、と言われますが、どう思われているでしょうか?

前職で、(外部コーチの方はいたものの)社内にアジャイル・スクラムの導入を進め、スクラムマスターとして、チームと伴走を続けていました。

スクラムマスターが自分1人という状況で、頼られることは、嬉しいことでしたし、貴重な経験とレベルアップにつながったと思っています。

一方で、僕自身がアジャイル・スクラムについて壁打ちしたい、スクラムフェスやコミュニティから持ち帰ったものを議論したい、というときに、社内ではそれができず、少し物足りなさを感じていました。(今、客観的に思えば、自分のマインド・巻き込み力のなさゆえで、立ち回りようはいくらであったと思いますが…)

その後、色々と事情があり、現職に転職することになるのですが、配属先以外にもスクラムで開発しているチームがいる、と聞いた私は一人、「他のスクラムマスターやアジャイル実践者と、相談や情報交換を気軽にできる場を社内に作れたら、めっちゃ楽しいんじゃね?」と思うのでした。

始動から約1年半、ちょっとずつ参加してくれる人も増え、コミュニティ内の相談や情報交換だけでなく、スクラムマスター不在のチームが外から相談に来てくれたり、会社的にスクラムマスターの立ち位置を作る運動がおきたり、想定外の効果も発生しだしているのを、わくわくしながら眺めています。

このセッションでは、私が社内アジャイルコミュニティをどう立ち上げ、運営を続けるために何をしてきたか、コミュニティがあることでどんな嬉しいことがあったかをご紹介します。

かつての私と同じように、もっと会社でアジャイル・スクラムの話をしたい、社内でアジャイルコミュニティを作りたい、と思っている方に、実際にやってみた一例を伝えると共に、行動のきっかけになれるようなセッションにしたいと思っています。

対象者

社内アジャイルコミュニティを作りたい人 / 会社でもっとアジャイル・スクラムの話をしたい人

7月1日(土) 15:00〜15:20 君たちのスクラムが炎上するのはリスクコントロールができてないからだよ!!!

登壇者

Shimpei Nito(@tonyfactory210

概要

皆さん!スクラムやってますか?そして、うまくいってますか?(笑)

スクラムやアジャイルが脚光を浴びて、日本の多くの開発現場で採用されていますね。 ただ、プロジェクトにスクラムを導入したものの、うまく進められなかった経験を持つ方もいるんじゃないでしょうか? 僕は自分が失敗してきた経験も踏まえて、スクラムを導入して、炎上してしまうのは、適切なリスクコントロールを行っていないからでは?と考えています。 ここでいうリスクとは「ゴールに向かうまでの不確実性」を指しています。

このセッションでは、数々の失敗経験を踏まえた僕が炎上スクラムプロジェクトに火消しとして参画し、どのようにリスクコントロールを行い、立て直していったかの物語をお話します。

以下、アウトラインです。

  • なぜ俺たちのスクラムは炎上してしまうのか
  • 僕が参画した炎上スクラムプロジェクト
  • 正しく現状を理解し、リスクを見積もる
  • 顧客に本当に必要な価値だけに絞る
  • 見立ては大きく、検証は小さく
  • もし最初からやり直せるなら、どのように行動を変えられるか

もし、あなたのチームがスクラムを採用しているにもかかわらず、炎上している場合、このセッションを通じて、どのようにリスクコントロールを行うかの見直すきっかけになれば幸いです。

対象者

スクラムを取り入れたがプロジェクトが炎上してしまうすべての人へ

最後に

みなさんにお会いできることを楽しみにしています!!