アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

ScrumMastersNightでOSTを体験してきました

ohataです

先日 Scrum Masters Night のイベントに参加させていただきました。

その時に[OST]という手法でディスカッションを行ったので感想を書いていきたいと思います。

f:id:k-ohata:20191107094342j:plain

OSTとは

[Open Space Technology] という課題解決を行うための手法です

主な方針としては、こんな感じです

  • 参加者がテーマ・課題を出し合う
  • テーマ・課題事にグループを作ってミーティングを行う
  • ファシリテーターを決めるのではなく、各個人が積極的に参加して成立させる
  • グループの参加は自由、途中でもグループから抜けて他のグループに参加できる
    • (テーマに意見を出せなかったり、自分が興味をなくした時)

詳しくは、こちらのブログで わかりやすく説明してくれています

すごい効率的だし、有意義な手法だなと思った反面

自分のグループに誰もいなくなったらちょっと悲しい

というネガティブな思いも心の80%くらいを占めました。

ただこの辺は運営の方がはじめに [OST]のやり方をしっかり共有してくれたので、 安心感を持って参加することができました。

特に自分としていいいなと思ったのが [終わった時が終わり] というルールです。

(ちょっとG.E.Rみたいですが、意味は真逆にちかい)

誰もいなくなったら[終わり]という風に個人的には捕らえさせてもらいました。

確かに[議論]しない事をいつまでも[議論]の場に置いておくのは良くないと思いました

始まり

参加者が課題を出して、自分の興味のある課題に投票していくスタイルでした。

時間の関係などもあり今回は10個の課題が選ばれました。

その中で2つのミーティングに参加する事ができました

  • リモートワーク前提の振り返り、うまいやり方ある?
  • 受託開発にScrumは導入できるのか?

リモートワーク前提の振り返り、うまいやり方ある?

課題を上げてくれた方の話だと、リモートとそうでない方との温度感の共有問題があるようでした。

アクトインディはリモート会議なども割と多いので、他の会社のやり方も聞きたいなーと思い 参加させてもらいました

主な課題

  • リモートワークの人と温度感が伝わりにくい気がする
    • リモートワークだと振り返りに集中できないこともあるのでは
  • 共有シートなどに振り返りを記載してもらうと他の人の意見も見えてしまうので引きずられる事がある
  • ホワイトボードでざっと話したい時に伝えにくい

解決案

  • 全員一緒の場所
  • 全員リモート
    • みんながヘッドセットで会話すれば同じ状態になる
  • リアルタイムで描けるツールの導入

こちらはいろいろ話が出ましたが、なんとなくみんな納得の解決案になりました。

結論的にはリモートでもリアルでも[同じ場を共有しながら行う]というのが大事なのかなと思いました。

何より良かったのが、割と話尽くせたこともあり、あってるかわからないけど 上手くいかなくても実践してみようと方針を決められることです。 

(初めての取り組みというのは、ある程度の覚悟が必要なので...)

受託開発にScrumは導入できるのか?

自社サービス会社なので受託案件はやっていないのですが、個人的には結構興味がありました。

何故かというと自分が読んだ多くのScrum本で、受託案件(というよりお客さんがあって、期限マスト) が多く取り上げられていたので、現実はどうなんだろうと思いました。

また、昔受託で結構素敵(大変)な思いをしてきたので、今はどうなんだろうと気になってた亊もあります。

課題

  • 受注時に予算と納期が決まっている
  • 成果物責任
  • 完成責任
  • お客さんの無理な要求

解決案

  • お客さんに[2025年の崖]などを説明して危機感を持ってもらう
  • 営業が仕事をとる時に進め方をScrumでやるのを説明してもらう
    • 営業さんがScrumの勉強をすれば理解が早いのでは
  • 自分が営業の場合は、一緒に進めていくお客さんかどうか見極める
    • でないと開発以外の話しも通じない可能性が高い
  • 顧客の教育
  • ラボ型の開発
    • お客さんも開発者と話すことによって自分の事として一緒に進められそう
  • お客さんとざっくばらんに話せる環境を作る
    • お客さんとの[Slack]をあだ名に変えると呼ぶ時もあだ名に慣れてきたりする
  • ストーリーポイント(プロダクトバックログ)をお客さんと共有する
    • 追加開発も常に見積もり優先度を決める
  • アジャイルコーチをいれる
    • お客さんにアジャイルコーチを入れる事をOKもらって、Scrumを体験しながらお客さん教育を行う
    • 発注者、受注者関係なくプロジェクトにアジャイル導入をする権限を持つ事を宣言する

やはり置かれている状況や立場が様々なので明確な解決案というのは、なかなか出てこないですが いろんな視点での解決案が共有された事は、試せる武器が増えたという意味では大変有意義でした。

またお互いの立場を理解しながら同じ経験の意見、第三者的な意見などを複合的に聞けたのは 自分の考えを整理するのにも非常によかったと思います。

まとめ

全体的に進行もスムーズでとても有意義に過ごせました。

運営スタッフの方、本当にお疲れ様でした。

Scrumでの悩みが聞けた事は大変参考になり、大きかったのですが 何よりOSTという手法を体験できたのが大きかったです。

チーム内で行ったら、振り返りの強化版的なこともできるんじゃないかなと思いました。

いろんな役割の人がいる中で、プロダクトを良くするための共通目的に対して 個々の課題を議論しやすい場を作りやすいのではないかと感じました。

運営の方がフランクな雰囲気を作り出してくれていたので、実践する場合はその辺も意識したいですね。

近々Tryしてみようと思います!

サービスを考えながら開発したいエンジニアの方いましたら、是非一緒にやりましょう!