天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

【受託アジャイル勉強会】オンラインOSTに参加してきた

contracted-development-agile.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

POは受託側と発注側どちらにいる?

受託開発を実施している中で、POが受注側にいる状況*1で、今後どういうことに気をつけていくとよいのか?みたいな話をしていきました。

まず、POが受注側にいる状況は長期的に見るとよくないと思うという話からスタートしていきました。
開発の進めやすさや意思決定のしやすさの観点から、POが受注側にいるのがベストだという話をする方もいますが、プロダクトの将来を考えると、受注側に発注側が依存してしまっている状況を作ってしまっている*2のは、発注側がプロダクトを発注する能力がどんどん下がってしまうということです。

ただ、受託開発をお願いしているという時点で、発注側にはプロダクト開発の理解が難しい可能性も高いし、(代理POにしかり)自分たちはだめなパターン踏んでいるんだ...と意気消沈してしまうのはもったいないので、どのようにして発注側を受注側が育成していくのかを考えていくのがよいのでは?という話も出ていました。
まずは受注側と発注側で信頼関係を構築していく取り組みをしたり、みんなでプロダクトの未来を考えたりするような取り組みをしていくのが重要だということです。

関係性の構築で気をつけていることやテクニック/コツを知りたい

前のテーマとも少し繋がって、受注側と発注側やスクラムチーム内で信頼関係を構築していくためのコツをみんなから集めるというテーマで話をしていきました。

以下のようなコツが出ていました。

  • 週1常駐をしてみる
  • 受け身にならず積極的にいく
  • お客さん側に味方をつける
  • できないことは正直にできないと言う
  • 初手デモ
  • チームのみんなで一緒に考える/一緒に意思決定をする練習をしてみる
  • お客さんよりドメイン知識に詳しくなる
  • 発注側の課題を知る
  • 一緒にごはんを食べる
  • インセプションデッキを作る。インセプションデッキの精度とかはどうでもよくて、チームの共通言語を増やすためにやってみる。チームの共通言語を作れるならなんでもよくて、ゲームでもふりかえりでも動画同時視聴回でもバグバッシュでもいい*3
  • プロダクトに愛称をつける
  • ビジネスモデルキャンバス→リーンキャンバス→USM/CJMな感じで全体像をつかみつつ、インセプションデッキみたいなアラインメントをとる

受託開発のいい話を聞く

最後に、ネガティブなイメージの話が多い受託開発だけど、受託開発のいい話を敢えてしてみようというテーマで話をしていきました。

以下のような話が出てきました。

  • 多種多様な領域を経験できるので知識欲が満たされる
  • 開発チームを変えずに動けることがある
  • お客さんにいいねと言われてまた別のチームに呼ばれる
  • 色んな人に会えるし、色々な経験ができる
  • 好きな仕事の発注をお願いできること

全体を通した感想

テーマを出した方が「絶望感がなくなって希望が出てきたし明日以降の仕事で現場がどう見えるのかが楽しみになった!」「火をくべしてもらえて嬉しかった」「こんな濃い話ができるなんて思っていなかった」といった前向きな感想がバンバン出ていたイベントで、神回でした。

仕事に対して真摯に向き合っている方々の話を聞くのって本当に面白いです。

*1:発注側が多忙でプロダクトバックログの管理ができないので受注側に一任されている

*2:=プロダクトの未来が受注側にかかってしまっている

*3:チームの共通言語を見つけるときは、まず個人ワーク→集団という順番にすることが多い。そうすると、「あの人が考えてくれる」という状態から抜け出せる