※ふりかえりが形容詞じゃないという部分は投げ捨てています

アジャイル、スクラムのなかで、とても親しみやすく、そして奥が深いのが「ふりかえり（Sprint Retrospective）」というイベントです。
スクラムを始めて1, 2年のチームの話を聞くと、こんな悩みをよく聞きます。

• Tryを出しても行われず、毎回似たようなTryが出てくる
• 出てきた問題がチームだと対処しようがない問題で、解のないまま終わってしまう
• ふりかえりの〇〇の手法をやっているけど、しっくりこなくて…
• どうやって自律的に（スクラムマスターが不在でも）ふりかえりが回せるようになるの？

これらの悩みの中には、下記のような潜在意識が隠れています。

• 「ふりかえりで問題を解決すべき」と思っている
• 「ふりかえりが問題を解決してくれる」と思っている
• 「ふりかえりをうまく回す」ことが目的化している
• 「特定のふりかえりの手法が問題に対しての特効薬となる」と思っている

こういった考え方は間違いではありません。ただ、それがふりかえりのすべてのように感じられてしまっている、もしくはそう思い込んでしまっている現場も少なくありません。

「Do ふりかえり」の意識では、あくまで「ふりかえりの中でなんとかする」という考え方が生まれがちです。ですが、ふりかえりの時間は仕事の時間の中ではごくわずか。アジャイル開発・スクラムにおいては、1週間で40時間働くうち、毎週1時間ふりかえりをしたとしても、たった2.5%の時間でしかありません。この時間の中で、残り97.5%で生まれた問題を解決するというのは酷です。

それではどうするのか。97.5%の時間で問題が解決される（もしくは良い方向に変化が起きる）ような状態を作り上げます。それが「Be ふりかえり」です。ふりかえりをするタイミングに合わせてふりかえるのではなく、チームの中で「自然とふりかえっている」状態を作ります。

この状態を作るには、「ふりかえり」の活動だけでは実現できません。チームビルディングを常に行い続け、チームのコミュニケーション・コラボレーションを活性化させる。「継続的チームビルディング」とも言える活動を取り入れてこそ実現できます。そして、その継続的チームビルディングを行いやすい場が、「ふりかえり」の時間なのです。

このセッションでは私が複数の現場で再現性を高めてきた、「Be ふりかえり」の状態に至るまでのプロセスと、その一歩目の踏み出し方・継続の仕方をお伝えします。ふりかえりをより楽しみ、チームとプロダクト、そして事業が成長していくための道のりと実際の事例をお話ししたいと思います。

スクラムフェスのような社外コミュニティのイベントに参加や登壇する際、会社公式として活動できるかどうかは、会社の状況に大きく依存します。既にそういった活動が当たり前になっている会社もあるでしょうし、ルールやプロセスが不明確だったり存在しなかったりする会社もあるでしょう。明示的に禁止している会社もあるかもしれません。もし、そのような活動を望む場合に道がない状況であれば、自分たちが第一人者となり切り拓いていく他に方法はありません。

私たちはDNPグループの情シス子会社であるDNP情報システムに所属しています。数年前、いくつかのきっかけが重なったことで、自身の存在意義が「チェンジエージェントとして組織を自由にしていくこと」にあることを（勝手に）見つけ、それを実現する方法を模索するなかで、私（寳田）個人として社外で活動するようになっていきましたが、最近に至るまで、会社公式ではなく個人としての社外活動することに特に不満も問題意識もありませんでした。

しかし、今年に入ってから新年度を迎える頃、マネージング・フォー・ハピネスの出版やそれに関する登壇で個人としての活動に一定の満足を得たからか、チェンジエージェントとして自分が社内で起こしてきたことに段々と自信が持つことができたからか、それによって他のことを考える余裕ができたからか、あるいはそこそこいい歳になってきたからか、はたまたその全てが合わさってか、自分がやるべきこと（すなわち、自分にしかできないこと）で今いる場に貢献していくことを考えてみると、

• 特定の人が周囲の人を動かすことでパフォーマンスを出すのではなく、皆が自律的に自分の思うままに（衝突も含めて）動いた結果の相互作用によって1人では実現し得ない総体としての結果を出すような組織に変えたい
• これまでの過去や現在ではなく、これからを支える次の世代がいきいきと活躍していけるような道筋や（ルールやプロセスや文化や風土などを生み出す構造としての）システムを残したい

の2点であることに気づき、それらを自分の仕事におけるゴールと考えるようになってきました。

一方で、社内では「情シスのメイン業務で得た業務ツールの利用促進（ときどき横連携強化）から仕事のやり方を変えていい感じの働き方ができるようにしていく」を目的にコミュニティも立ち上げていましたが、ここもコミュニティメンバーと今後の在り方や活動方針を見直す機会があり、これからは「仕事のやり方を変えていい感じの働き方ができるようにしていくこと」すなわち「セルフマネジメントの理解と実践による自律的な行動や責任に満ちた組織へのトランスフォーム」の方に重心を置くこととし、そういった変化への認識と欲求を刺激する（社内で自分たちも変わりたい、変わらなければいけないという想いが生まれるようにする）ためのロールモデルや良い意味での外圧となるべく、今年4月から「公式に社外活動に取り組んでいく」「そのためのスキームを整備する」を目標に動いてきました。

このセッションでは、そういった状況にいる「とある情シス子会社の今はまだ小さな現在進行形の物語」として、今に至る経緯、いくつかの時点でどう考えて何の行動をとったか、これから何を狙っているかについてお話します。

物語の行く末はプロポーザルの採択によっても変わるところもあると思います。当日、皆さんの前で/皆さんと一緒に話をして、一定の目標を達成した喜びが共有できれば幸いです。

　変化が激しい状況の中、組織自体もアジャイルに変化していく必要性が出ています。そのため、開発だけでなく組織運営自体もスクラムの概念を取り入れ、プランニングやレトロスペクティブをしながらバックログを消化していく事で、組織を成長させていく。そのような「組織アジャイル」の考え方が注目されています。

　その中で肝となるのが「組織バックログ」です。書籍「組織を芯からアジャイルにする」においても

>バックログでチームの「脳内」を表す
>今取り組むべきものについて、チームや部署内で共通の理解を得るための「可視化」、さらに粒度を合わせるための「構造化」、何から取り組むのかという「順序付け」を行う事で、チームの脳内を整えて行動を揃える

とバックログの重要性について記載されています。

「なんだ？チームでタスクを見える化して計画・ふりかえりを繰り返していく。普通の事じゃないか？」

と我々も「組織アジャイル」なる活動を始めてみましたが、始めてみると開発でのアジャイル適用以上にうまくいかない事の連続でした。

　本セッションでは組織アジャイルとしてバックログの管理・運用が何故難しいのか？どういった事に工夫したらよいのか？という点について実際に運営する中での気づきとTipsを報告したいと思います。特に組織バックログを対応していく上で必須と思える協働のメンタリティをどのように育んでいったかを解説したいと思います。組織を変化させたいリーダー層に参考になれば幸いです。

＜組織バックログがうまくいかなかった理由＞

1.ゴールが見えづらい

・組織のプロダクトゴールが必要だが、組織単位で意味のあるゴールを設定・共有することが難しい。結果、プロダクトゴール、スプリントゴールがうまく設定できず、単にバックログをこなしていく、いわゆるビルドトラップの罠にはまってしまう

2.バックログの構造化が難しい

・プロダクト ゴールを設定できても、バックログ化するにはゴールとバックログを紐づける構造化が必要となる。ただし、抽象的なゴールから具体的なバックログを整理するやり方が分からない

3.担当の役割分担が難しい

・組織活動を実施する場合はリーダー層が集まって対応することが多くなるが、忙しいリーダー層で効率よく作業ができるよう、タスク分担をして対応した。

　しかし、タスクの偏りやメンバーでの優先順位の違いが出て、中々進まなかった。また、当然スクラムマスターも専任できない中、バックログの見える化やメンバーの調整、ふりかえりやゴール設定のファシリテーション等、タスクは進まない中で、スクラムマスターの負荷だけが大きくなり、疲弊した

＜対応方法のTips＞

1.組織のMVVの及びゴールの設定

・ ゴールが見えないという課題については、リーダー層で合宿を実施し、MVVを策定

・MVVとバックログの関係を構造化した

2.ゴールに対してのバックログの構造化

・1年後、3ヵ月後、1か月後といった期間ごとのゴールを言語化しKPIを仮設定

・スプリント中にゴールと仮設定したKPI自体を見直すようなタイミングを設けてふりかえり・むきなおりを実施

3.協働のメンタリティ

・ メンバー間でソーシャルサポートのスキルの重要性を共有し、助けてもらうスキルを意識的に伸ばす

・モブワークの枠を多用し、集まれるメンバーで集まりながら、タスク担当者とは関係なく、モブ作業で課題解決や計画を実施

Abstract

ラスボスゾンビとは「ゾンビスクラムサバイバルガイド」に触発され、私が独自に定義した言葉です。
「チーム・組織をゾンビスクラムに陥れるリーダーやマネージャー」です。

スクラムフェス福岡にてお話しした「ゼロからスクラムを推進したスクラムマスターがラスボスゾンビEMになるまでの失敗と心の中」でラスボスゾンビのチェックリストを紹介いたところ、ご好評をいただきました。

このセッションは、ラスボスゾンビ株式会社（架空）が世の中にラスボスゾンビを普及するというストーリーに沿って、コミカルにラスボスゾンビにならないためのポイントをチェックリストに沿ってお話しします。

* ラスボスゾンビSMのチェックリストの項目の紹介
* それぞれの項目がなぜこのポイントがゾンビスクラムを招いてしまうのか
* どのような行動がゾンビスクラムに招いてしまうのか

ラスボスゾンビ株式会社からのメッセージ

こんにちは、世界の皆さん、私はラスボスゾンビ株式会社の代表取締役CEOのおーのAです。
弊社のミッションは「世界の全てのスクラムをゾンビスクラムに」です。
我々はラスボスゾンビという素晴らしいリーダーを育成するコンサルティング業を生業としております。

本日はお集まりの皆様に、特別にラスボスゾンビトレーニングを提供いたします。
弊社独自に開発したラスボスゾンビトレーニングにより、皆様を立派なラスボスゾンビへと育成したいと思います。
皆様と共に世界をゾンビスクラムの脅威に陥れていきましょう。

ふりかえり、大切だとは思いながらも形骸化してしまったり、なかなか定着しなかったことはありませんか？
また、毎日のふりかえりって開発以外の分野ではどうしてるんだろう？と気になっている方もいるかもしれません。

本セッションでは、ふりかえり手法「Fun Done Learn」の魅力、そして開発ではないマーケティングのチームが毎日Fun Done Learnを実践している事例をご紹介します。

事の始まりは、2022年11月。KAGの中島が「Fun Done Learnのうた」を発表しました。
この曲の歌詞には、KAGのPoCチームが毎日Fun Done Learnにてふりかえりをおこなっている実践知が込められています。KAGのPoCチームでは、顧客との価値検証を目的に1日単位のスプリントにて計画〜レビュー〜ふりかえりを実施。今の状態をチームで把握するために、毎日Fun Done Learnで2年以上ふりかえりを続けています。

そして、スクラムフェスでKAGと出会った、ITプレナーズのメンバー。この曲の中毒性に取り憑かれ、毎日ふりかえりをするというエピソードを知ったことがきっかけで、ITプレナーズのマーケティングチームは毎朝の朝会でFun Done Learnによるふりかえりを始めました。この取り組みは半年以上経った今でも継続され、すっかり定着しています。

何故、ふりかえりを始めようと思ったのか？その背景は？
毎日Fun Done Learnをやって感じている効果とは？
Fun Done Learnをしている際に気を付けていることとは？

チームで習慣を作ることは大変なことです。
KAGとITプレナーズ合同で、毎日実践しているFun Done LearnをFun Done Learnでふりかえることで、Fun Done Learnの魅力を更に掘り下げます！

※参加者からも随時ふせんを募集します！

スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。
特にSaaSだとそもそもウォーターフォールがそぐわないので、自然とそういう形態になりがちです。

しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。

これを引き起こすのは、スタートアップ特有の個人分担制です。
多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 

しかし、個人開発の延長で大きくなったスタートアップはそのうち大きな壁にぶち当たります。

• 特定のエンジニアに負荷が集中する
• 開発のリードタイムが異様に長くなってしまう
• etc.

それは、事業がいわゆる Product Market Fit を終え、これから事業を大きくしよう、売上を伸ばしていこう、というときに特に顕在化し、問題になります。
こんなとき、みんな「人手が足りない」「開発が回らない」と考えがちなのですが、その実、個人開発をやめれば人を増やさなくても開発は回るようになります。たいていの場合。

こんなチームを救うのは、協働です。協働を意識したチーム開発への移行がこの危機を救うのです。

このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個人開発からスクラム流のチーム開発に移行すればいいのか、を、実際そういった傾向を持った複数のスタートアップ企業にアジャイルコーチ／スクラムマスターとして関わった経験を元にお話しようと思います。

昨年、Ebackyのkeynoteで10分程お話させていただいた、アルプスアルパインの白石です。
昨年は、テストチームならではの取り組みについてご紹介しましたが、10分には収まり切らなかった話がまだまだあります。
今年は、私たちのチームメイトの矢田から詳細な内容を話してもらおうと思っています。
----
アルプスアルパインの矢田です。
皆さんのプロジェクトには、テスト専門チームはありますか?

私たちは、アルプスアルパインで製造したAndroid™ OSのカーナビゲーションに対し、Google認証を取得するためのテストを一挙に担っているテストチームです。
スクラムでテストチームと聞くと、どういうイメージを持つでしょうか。
何がプロダクトバックログになると思いますか？
何が完成の定義になると思いますか？
...

こういった具体的なプラクティスや、実際に起きた問題をお話しする予定です。
テストチームの話にはなりますが、一般的なソフトウェア開発チームを改善する発想のきっかけも得られると思います。

※ AndroidはGoogle LLCの商標です。

大企業のSIerでシステムエンジニアをしています、Katsuyaです。

本セッションでは、発信し続けることと『Fearless Change』のパターンを意識することで

• 社内で同じ志を持つ仲間を見つけられる
• 熱意や目標を見失わずに楽しく継続的に活動できる

という話をします！『Fearless Change』の第二部にはパターンの事例紹介が4人分掲載されていますが、私のストーリーが5人目の事例になれますように...!!

■セッション概要

3ヶ月ほど前から、会社の1つ上の先輩と業務時間外にWebアプリ開発を始めました。本業でアサインされているプロジェクト（メインプロジェクト）と対比して、このアプリ開発の営みをサブプロジェクトと呼んでいます。

なぜ先輩と私がサブプロジェクトを始めるに至ったか。それはメインプロジェクトに対して次のようなことを思っていたからです。

• コーディングの時間が少なすぎる（=基礎となる開発力が向上しない）
• アーキテクチャや開発プロセスレベルで試験的な取り組みをすることは工数的に不可能（相当な理由がないとクライアントが納得してくれない）
• 自分たちがアーキテクチャなどに対しての裁量を持てる職位になるまでに、試行錯誤する時間やタイミングがない
• そもそもこうしたことに興味があって意欲的に取り組める人が周りにほとんどいない

今の私たちは圧倒的に知識と経験が不足しているので、現状のシステム開発を客観的に広い視点で評価することができず、ただなんとなく「イケていない...」と感じるだけに留まっています。かと言って自分たちがそうしたことに裁量を持てる職位に上がった頃には今までメインプロジェクトで経験したことのあるアーキテクチャや開発プロセスにしか理解がないので、他のアーキテクチャや開発プロセスを採用するのはリスクが大きすぎます。

そこで！サブプロジェクトを始めようじゃないか！、と。私が先輩に声をかけたわけです。まだ始めて2ヶ月程度しか経っていないのでこれといってサブプロジェクト自体の成果は上げられていませんが、サブプロジェクトを始めるまでの過程の中にいくつか良かったと思える行動があったことに気づきました。

今振り返ると、書籍『Fearless Change』に出てくるパターンに似ているのです。例えば、

• 小さな成功
  • 自分たちの取り込みからどんな小さいことでも学びを発見し、その学びを持って自分たちの活動は成功しているのだとお互いに称え合っています。決してプロダクトとして日の目を見ないと成功とは言えないわけではないと思っています。
• ステップバイステップ
  • 本当にたくさん試したいことはあるけれど、まずは1つだけ最も興味があるトピックを選んで取り組んでいます。これによって、自分たちは今何を検証しようとしてこの取り組みを行っているのかが明確になります。
• ふりかえりの時間
  • 活動した日は必ずふりかえりを行います。自分たちの取り込みによって何が学べて何が良かったのか、逆に何に困っているのかなどをつぶさに観察します。
• グループのアイデンティティ
  • サブプロジェクト開始直後にチームの名前を決めました。自分たちがこうして集まった理由となる「システム開発に対する熱意」をチーム名に込めたこと、またチーム名を決める一連の活動を通して、アイデンティティが形成されたと実感します。
• イノベーター
  • 私が会社の先輩に声をかけたのは先輩がこのイノベーターを担ってくれると期待したからです。
• 定期的な連絡
  • 先輩と私はプロジェクトを離れたあとも定期的に連絡を取り合い、技術的な関心事などについて話していました。
• 勉強会
  • もともとこのサブプロジェクトの前身として読書会を行っていました。

これ以外にも、私がプロジェクトのSlackで自分が興味あるトピックを発信し続けていたこと、工数に影響のない範囲で改善したり試したりできることは積極的に取り入れていたことなどが、サブプロジェクトを開始するにあたって良い影響を与えていたと思っています。

私たちのチームでは、有志が集まって自分たちのコードを一緒にわいわい読む活動をしています。ここでは、この活動を「モブコードリーディング」と呼ぶことにします。この活動は、コンポーネントチームからフィーチャーチームへの移行を支援するためにはじめたものです。

私たちは、4つのコンポーネントチームでNexusをベースとしたスクラムを導入し、1つの自社サービスを開発していました。開発を続けるうちにビジネス状況によりすばやく対応する必要性が高まり、私たちはフィーチャーチームへの移行を目指すことにしました。この移行に際しては、チームの構成を維持したまま、これまで担当外だったコンポーネントの開発を徐々に手掛け、各チームが開発できる範囲を拡大するアプローチを選びました。この状況の中で、普段の開発による学び以外でも自分たちのコードについて理解を深める機会があるとフィーチャーチーム化が加速するだろうと考え、モブコードリーディングを企画しました。

私たちのモブコードリーディングでは、特定の「お題」を設定し、そのお題に沿ってコードを読み解きます。参加者は各自でエディタを開く、もしくはVSCodeのLiveShare機能を利用して、その場でコードを読みながら動作や疑問について話し、理解を共有し進めていきます。モブコードリーディングにより、コードの理解が深まり、リファインメントやトラブル対応で効果的な議論ができる人が増え、また暗黙知なども共有されました。

このセッションでは、私たちがモブコードリーディングをはじめた背景と目的、そしてどのように実践し、その効果をどのように感じたのかについてお話します。

# このセッションで伝えたい

• ビジネスやチームへの期待、メンバーのキャリア、ライフステージなど、チームの環境や状況は良くも悪くも変化し続ける
• 大事なことは、変化をコントロールしようとするのではなく、チームが変化に適用して価値提供を続けられること
• そのためにはスキルやプラクティスの前にチームのマインドセットが醸成されていることが肝要

---

僕たちはチームの立ち上げから1年でチームの形が6回も変えました。1チームスクラムから始まり、3チームスクラム、2チームスクラム、2チームスクラム+1チーム、2チームLeSS+1チームスクラム、3チームLeSS、そして今は2チームLeSSの体制です。メンバーの増減も頻繁なので毎月変化がありました。ビジネスの変化は対応するため、期待に応えるため、はたまた自分たちの挑戦のため、個人のキャリアのため、そのときどきの状況に応じて適切だろう体制を選択し続けてきました。

こんなにチームをいじりつづければ、チームはてんやわんや。成果も出ず、スクラムは破綻し、チームは空中分解…みたいになると思いませんか？

しかし、僕たちはちゃんと機能しているチームしてるんです！チームの形は安定させていないけど、安定した価値提供と成長を続け、社内で参考にされるプロダクトチームに成り上がりました！

なぜこんなことができたのか。それはマインドセットに力を入れてきたからです。アジャイルマニフェスト、スクラムやXPの価値基準、モダンアジャイル、テスティングマニフェスト、HRT、LeSSの原則…。そんなマインドセットをチームで理解し、それをベースにプラクティスに取り組んでいるから、形に拘らず変化に適応できるチームになれました。

このセッションでは

• なぜマインドセットが大切なのか
• 僕たちが大事にしているマインドセット
• どうやってマインドセットを当たり前にするのか
• 何を考えてチームの形を変化させてきたのか

などを共有します。変化に強いチームをつくる参考になれば嬉しいです。

ぜひ、チーム自慢させてください！

エンジニア時代の私は自身の技術面の成長を優先するあまり肝心の「プロダクトの成長」にあまり関心を持っていませんでした。「何を作ればユーザーに価値を届けられるか?」ではなく「自分がいかに多くのPBIを潰し、いかに多くのコードを書く経験を積めるか」が重要だったのです。

そんな私がスクラムマスターにロールチェンジし、約１年間スクラムマスターとしての責任に向き合った結果、開発に対する考え方が当時の価値観から大きく変化している事にふと気づきました。

スクラムマスターはチームや組織を変革する存在であったはずが、無意識のうちに自分自身が大きく変革している事に気づいた瞬間でした。

本セッションは、スクラムマスターを"たったの"1年間やっただけで開発に対する価値観が180°変わるに至った経緯とその要因を深掘りする内容となっています。

これからスクラムマスターに挑戦しようか迷っている方の背中を押すようなセッションにできれば嬉しいです。

歴戦のカンファレンススタッフであるAckyさんとこばせさんの二人に、カンファレンススタッフのお仕事を聞いたり、そこでの二人のやりがいを聞くことを通じて、スクラムフェスというコミュニティに潜むコントリビュータ気質のスタッフがいきいきと働ける、良さについて言語化していきます。ここで言うコントリビュータ気質とは、貢献のためにたくさん手を動かす気質を指します。

なおカンファレンススタッフ業務に関しては、スライドを用意し解説をしますが、二人のやりがいや価値観については、ばやしがインタビュー形式で聞き出していきます。

ソフトウェア開発のアジャイルプロジェクト自体は急速に増えてきました。そんな中、企業組織の中でアジャイルな活動がうまく根付かせ継続できていない、複数のアジャイルプロジェクトがうまく連携できていない、企業活動とアジャイルチームが噛み合っていない、アジャイルチームだけでなくそれを包含する組織自体も変わっていかなければいけない、そんな課題をお持ちではありませんか？

本セッションでは、企業組織やコミュニティ組織がどんな状態になってほしくてアジャイルをやっているんだろうか、という問いに対し、組織的にアジャイル導入を検討するリーダーのために、組織が幸せであるとはどういう状態かを言語化し、ゴールやそこに至るまでのギャップやアクションを整理・洗練させた「組織を幸せにする組織アジャイル5つの原則（略称：ソシアジャ五良核）」について概説します。その上で、各テーマについてディスカッションを通して理解を深めます。

１．同じ方向性を向いて働けている
２．お互いに協働できている
３．お互いに敬意を持っている
４．組織も個人も成長できている
５．ビジネスが持続的に回せている

組織的なアジャイル導入にこれから取り組みたい、複数のアジャイルチームを連携させたい、開発 以外の組織にアジャイル的なマインドを広げていきたい、等々で今まさに苦労している方々、ぜひ一緒に議論しませんか？

どうも皆さんこんにちは, 鞍馬ぽめると申します
よろしくお願いいたします

コンサルみたいな働き方やアジャイルコーチとかをやっていると, "他のチームの事例を教えてください" と依頼いただくことがしばしばあるかと思います
その時皆さんはどのように伝えていますか？

人に何かを伝える時, "やってみせ" が結局一番伝わりやすいというのはあると思いますが, 秘密保持の観点などから情報にマスクをかけてドキュメントで伝えるしかできないようなことが多いのではないでしょうか

今の会社に入ってから２年弱, その "わずらわしさ" に何度もぶつかってきたぼくが抱いた思いは "自分のチームを持ちたい" でした

このセッションでは, わざわざ自分のチームで活動できる事業会社を辞めてまでベンダー企業に転職してきたぼくが, ここに来てどうしてこのような思いを抱くようになったのかについてお話したいと思います

"実際に活動しているチーム" こそ最強のリファレンスですよ

大企業のSIerでシステムエンジニアをしています、Katsuyaです。

本セッションでは、"モブ部屋"というオンライン会議を導入することで

• リーダーやマネージャーからの反発をなるべく少なくモブワークを導入できる
• リスクを抑えてモブワークを実施できる
• 作業の透明性を高められる

という話をします！

このセッションによって、聴いてくださった方が各々のチームにペアプロ・モブプロやモブワークを導入したいと思ったときの足がかりになれるよう、精一杯お話します...!!

■セッション概要

SIerはいわゆる人月商売なので、いかに稼働率を上げて工数に見合った働きをするかというリソース効率が重要です。しかし、VUCAの時代と言われる現代で早期に価値を届けたり、後続の依存タスクのために滞りなく作業を進めるためには、いかに課題解決までのリードタイムを短くするかというフロー効率という観点も重要になってきます。フロー効率を上げるプラクティスにペアプロやモブプロ、派生してモブワークなどがあるので、これらを要所要所に積極的に取り入れることで、フロー効率を改善できます。

とはいえ、今まで工数ばかりを意識していた組織の中でいきなり「モブワークをしてフロー効率を高めましょう！」と言ったところで、あまり重要性が理解されずにやんわりと却下されて終わりです。

そこで、私のチームではモブワークをチームに導入する足がかりとして"モブ部屋"というものを取り入れました。部屋とは言うものの実体は日次のオンライン会議なんですが、これが結構良いプラクティスだったので、導入方法やTipsについて共有します！

導入のポイントは

1. 場を作ってしまうこと
2. 無駄な工数を減らす目的だと伝えること

です。

1.に関しては、プロジェクトではOutlookやTeamsを使用しているので、毎日30分モブワークをする会議を設定してしまいます。2.に関しては、「関係のある人だけ参加してもらって...」とか「手戻りを防ぐために最初に会話させてください」というふうに、工数を無駄にかけるわけではなくむしろ減らすことが目的だという前置きを必ずします。

こうしてモブ部屋を導入することで、モブワークに対する距離が近くになり、自然とモブワークの解像度が上がります。なかなか定量的にモブワークの効果を説明することは難しいですが、実体験としてモブワークの効果を経験すると次第に「分担作業をするだけが効率じゃなかったんだ...!!」と気づき始め、リソース効率に加えてフロー効率の観点で作業手順を考えられるようになります。