Zenn
🔃

「チーム運営や、ユーザが本当に必要としているものを掘り下げる技術」を学んだ記録

2022/02/13に公開
#
アジャイル
#
スクラム
idea

この記事は？

自分が2020年度に受講生・2021年度にメンターをやった筑波大学の講義である、enPiTについての記事です。

  • 自分は記憶力が弱いので忘れる前に、自身の学びをメモ化しておくこと。
  • enPiTやスクラムに興味がある人に少しでも参考にしてもらえること。

を目標に書いています。

enPiTって？？

公式サイトには

プロジェクト型学習(Project Based Learning, PBL)を基軸に、学生がチームを組んで自律的に自分達のテーマの具現化を目指します。チームでのプロダクト開発を通じて、チーム運営や、ユーザが本当に必要としているものを掘り下げる技術を体験します。

と書かれています。

  • 学生たちでチームを組んでスクラム開発でプロダクト開発をする。
  • プロダクト開発の授業ながら、プログラミングのスキルではなくチーム運営や、ユーザが本当に必要としているものを掘り下げる技術に重きをおいている。

のが特徴だと思います。

何を学んだの？

受講生のときはチーム開発のときのプラクティス( 具体的な工夫 )の学びが多かった[1]と思います。

受講生のときに生み出したプラクティス

受講生のときのSeeeeee:Dチームのプラクティスはとても良かったと思いますが、この記事の主旨からはそれるのでいくつかをここに書きます。

メンバーチェンジモブプロ

  • チームの基本の開発方針としてモブプログラミングを採用しました。
    • 技術力がまちまちな中で、プログラミングのテクニックのシェアや、実装の共有。リアルタイムでコードレビューができるなどのメリットがありました。
  • 6人で1モブにしていると何もできない時間(オーバヘッド)が大きいので、3人モブを2つ設ける体制にしました。
  • コードの属人性をさらに減らすために一定期間ごとにメンバーを一人づつ入れ替えるようにしました。

ミームによる会話の心理的安全性の担保

  • オンラインで表情が見えない状態でも会話の心理的安全性を担保するために、発言に対するリアクションを大切にしました。

一方で今年度はメンターとして活動することで、自身がスクラム開発の当事者ではなくなったことや様々なチームを俯瞰してみることができたことから、メタな視点でenPiTを見ていたところがありました。
その結果、「一つ一つのプラクティス」だけではなく大切な価値観みたいなものを強く意識するようになりました。(受講生をしていた頃からもっとちゃんと意識していればよかった... )

学び① いいチームを作ること

振り返りをしよう

  • 振り返り(レトロスペクティブ)を大切にして自己組織化されたチームを作ろう。
    • チームのあり方のカイゼンをチーム自体ができるのって素敵じゃないですか？
  • チームでやって良かったプラクティスをストックしておくのもおすすめです。
    • 言語化して記録しておくことで再利用性・配布性が高くなったり(ソフトウェアのライブラリみたいですね)、チームの大切にしている価値観を再認識するきっかけになると思います。
    • enPiT2021では、これを繰り返し現れる良い構造「パタン・ランゲージ」と呼び、各チームがストックしていました。この内容は先生方がデブサミで発表されているので興味を持たれた方は確認してみてください〜。(リンク)

学び② いいプロダクトを作ること

コアの体験から検証と実装をしよう。

プロダクトを開発する時、

  • 運営チームが提供したい体験はユーザーに求められているのか
  • プロダクトはその体験を提供できるのか

ってすごく大切だけど不確実です。そして十分に検証していないことが多いのではないでしょうか？
実装してリリースしてから誰にも使われなかった...みたいな悲劇を避けるためにも検証を大切にしましょう。

  • ユーザー体験のための最小限の実装で作れるプロダクト MVP (Minimum Viable Product) を作ってまずはフィードバックを得ましょう。
    • 場合によっては実装すら不要で、紙やプロトタイピングツールでいいかも
    • MVPは本来ならば動的なところがハードコーディングでもいいし、BotのロジックができていないならばWoZ法[2]でシステムのフリをして中の人が返信していてもOKです。
    • それでもユーザーにその体験が求められているかの検証はできます 。
  • 運営チームで考えて議論することも大事ですが、動くものを触ってもらって得たフィードバックが一番確実だと思います。経験主義的ですね。
  • 実験を繰り返すことで本質的なユーザー価値に近づいていく事ができると思います。

これは新規プロダクトに対してはもちろんですが、すでにあるプロダクトに新規機能を実装する場合も同じだと思います。

自分もそうでしたが、個人開発してる時にはじめの画面である、トップページやログインページから作る人は少なくないと思います。
でもログインってアプリケーションのコアの体験ではないので、ログイン機能が実装できても、人からアプリケーションが提供する体験に対してのフィードバックをもらう事ってできないんですよね。
ぜひ一度、コアの体験の検証から始めてみてはどうでしょうか？？

実際のアプリケーションで得られるフィードバックはプロトタイプに勝る

FigmaやXDなどのプロトタイピングツールでのデモよりも、実際のアプリケーションを触ってもらったほうが解像度の高いレビューを得ることができます。
これもまた、経験主義的ですね。
ここではアプリケーションはフィードバックを得ることが目的なのでアプリケーションの様相であれば、ハードコーディングでもいいしWoZ法でもいいです。

プロダクトが提供できるのは体験だけ。

ユーザーはプロダクトに対して機能を求めているわけではなくて「体験」を求めている。

「何の機能を作る」から始めるよりも、「どんな体験」を作るかから考えたほうが、ユーザーの困りごとに寄り添ったプロダクトを作ることができると思います。
アジャイルで「ユーザーストーリー」って概念があるのも似た発想かなって思います。

これらの学びがフレームワークになってるスクラムってすごい

これまで度々「経験主義」と書いてきましたが、スクラムは経験主義を基本にしているとスクラムガイドに書かれています。
また、自己組織化されたチームのためのレトロスペクティブやデイリースクラム。
「どんな体験を与えたいかリスト」とも言えるプロダクトバックログ[3]、スプリントプランニングで選んだプロダクトバックログアイテムを、実装タスクレベルにまで分解したスプリントバックログの存在。
プロダクトバックログと実装のタスクレベルにまで分解されているスプリントバックログを別にすることで、ユーザー体験と実装の話の切り分けができるところとか本当にスクラムフレームワークはよくできているなと思います。

抱負

自分は来年度から社会人のエンジニアになります。
来年度から働く会社ではスクラム開発をやっているわけではない(聞いてる範囲だと多分ない)ですし、アジャイル・スクラム開発をそのまま導入して使えるかは、作ってるプロダクトや組織体制によって変わると思うので会社でそのままプラクティスを使えるとは考えていないです。
ですが、enPiTで学んだチーム運営や、ユーザが本当に必要としているものを掘り下げる技術はめちゃくちゃ役に立つだろうなと思います。受講生・メンターをしてるときに得た学びを大切にしていきたいです。
また、「とりあえずやってみる」の経験主義的な姿勢を持ち続けたいです。やらないことが最大の失敗で、やればうまく行かなくても結果と学びを得ることができます。

また、アジャイル界隈の学ぶことを楽しんでいる雰囲気が大好きです。:waiwai:
enPiTではSlackのtimesや、授業内外のDiscordで、受講生・メンター・先生方・豪華な外部講師の方々の別け隔てなく、熱い議論が交わされていて素敵なコミュニティだなぁと思っています。

直接enPiTとか関われなくなっても、分散アジャイル、スクラムフェスやRSGTなどのイベントで学びを深めていきたいと思っています。
どこかで会ったときには声をかけていただけると嬉しいです！！🙌

脚注

  1. 受講生のときの最終レポート。プロダクトと行ったプラクティスの説明が多い。 ↩︎

  2. システムのふりをした人間がユーザーと対話を行う. https://www.jstage.jst.go.jp/article/tjsai/17/3/17_3_293/_pdf/-char/ja ↩︎

  3. スクラムガイドにはPBIにはユーザーストーリーを書く旨は直接的には書かれていませんが、ユーザーストーリーを含めることが一般的なようです。（参考） ↩︎

GitHubで編集を提案

Discussion