2年ぶり2度目のenPiT受講
はじめに
筑波大学大学院に入学してから早10ヵ月、本日、筑波大学のenPiTビジネスシステムデザイン分野（のはず）を全課程修了しました。まだ修了証書[1]をもらっていないので修了と言っていいのか分かりませんが、ちゃんと参加しましたし、レポートとしてこの記事を提出するつもりなので大丈夫でしょう。
enPiTは大学院生も参加可能で、大学3年次に引き続いてもう1回参戦してきたので、作ったプロダクトの紹介と、開発の流れの紹介をして、最後に個人的なふりかえりをしたいと思います。
↓↓↓ 前回参加したときのレポートはこちら ↓↓↓
プロダクト紹介
どんなもの？
主要な機能
他の人が読んだ論文レビューを見ることができます。論文を読む前に簡単な前提知識を構築したり、分からないところを参考にしたりすることで、論文を読むときに、スムーズに理解ができるようになります。
そして、それらの論文レビューは所属する研究室[2]で蓄積することができます。これまでの研究室の先輩方が、どんな論文を読み、どのように理解したのかを参考にすることで、キャッチアップがスムーズになり、研究のスタートダッシュに繋がります。
また、それぞれの論文レビューに対して、コメントをすることもできます。「コメント」として、議論のきっかけを気軽に作れることで、議論の機会が増え、より深い理解を助けます。
開発プロセス
ここでは、今回の開発についての概要、プロダクトカイゼンの過程、チームカイゼンの過程を紹介します。
概要
enPiTでの開発は、10月~1月末までの約4ヵ月間で行いました。私たちのチームは6人のチームでした。
開発はアジャイル開発手法の1つであるスクラム、計4回のスプリントで、1スプリントは大体2Weeksで進めていきました。各スプリントは4つのブロック(ここではショートスプリントと呼びます)に分かれていて、それぞれのショートスプリントは、3時間でスプリントプランニング、開発、デモ、(デモのフィードバックを踏まえた)PBLリファインメント、ふりかえりを行うものです(講義の都合上、結構時間はシビアですね)。
プロダクトのカイゼン
私たちのチームは「ユーザーに向き合うこと」をかなり意識していました。そして、この意識が、より価値のあるプロダクトの提供に繋がっていると思います。
特に、議論においては、「この部分は自分たちの想像だよね。」「この議論は自分たちだけでは解決できないよね。」→「だから、次回以降のデモで価値検証をしよう」という声掛けが多く、「ユーザーが実際に困っていること」と「ユーザーが困っていると(自分たちが)思っていること」を分けることが意識出来ていたと思います。
また、ショートスプリントにおけるデモについても、フィードバックを貰いやすいデモを行うよう心がけました。
ショートスプリントのデモでは、チームに5分発表時間が与えられます。その時間の中では何をするも自由です。基本は、プロダクトの紹介→プロダクトの仮説検証、の流れが多かったです。
ショートスプリントのデモにおいて、デモに参加してくれるユーザーは、各チームに割り当てられたDiscordのフィードバックチャンネルにフィードバックを書き込む、というシステムでした。
しかし、私たちのチームはこの「フィードバック」の質や数が芳しくなく、デモに対してほとんどフィードバックがもらえない状況が続いていました。
この問題の対策として、私たちは「テキストによるコミュニケーションのハードル」が存在すると仮説を立て、口頭でフィードバックを受け取れるような仕組みを作りました[3][4]。
それにより、フィードバックの数が増加し、「ここのボタンの○○という言葉が直感的じゃない」というような細かいフィードバックも口頭でもらえるようになり、プロダクトのカイゼンに繋がりました。
チームのカイゼン
チームのカイゼンのために最も効果的だったのは「ふりかえりの有効活用」だと考えています。私たちのチームは「全員が当事者意識を持つ」ということを重要視していたので、よりふりかえりが重要だったと思います。
ここでは、「ふりかえり」での取り組みに重点をあてて、チームのカイゼンに役立ったことを紹介していこうと思います。
ショートスプリントの最後に、1日の取り組みのふりかえり(10分)をチームで行います。今回の開発のふりかえりでは、「よかったこと」と「改善できる点」を挙げ、アジャイルソフトウェア開発宣言の「個人との対話」「動くソフトウェア」「顧客との協調」「変化への対応」にカテゴリー分けをしました[5]。
私たちのチームが行った「ふりかえり」に関する取り組みで特徴的なものは、「共感できるふりかえりに★マークをつけること」「TRYをきちんと言語化し残しておくこと」です[6]。
「共感できるふりかえりに★マークをつけること」で、メンバーそれぞれの共通した問題意識を可視化することができ、効率的に問題意識の掘り下げや議論に繋がりました。
「TRYをきちんと言語化し残しておくこと」で、次回以降の行動指針が明らかになります。言語化せずにチームの(暗黙の)共通認識として理解することもできますが、テキストとして残しておくことで、「共通認識である」と明確に認識することができます。
また、今回の講義では期間が決まっており、追加の開発メンバーが加わることは想定されていませんでしたが、実際の開発現場ではNew Joinerのキャッチアップを考慮する必要があります。テキストとしてチームの成長過程を残しておくことで、そのキャッチアップの手助けにもなるかと思います。
個人的なふりかえり・感想
本節では、今回の開発を通じて「学んだこと」「意識したこと」「思ったこと」をトピック(各小節)に分けて紹介していきます。
「学んだこと」は、開発を通じて新たに習得したこと、考えがアップデートされたことをまとめていきます。
「意識したこと」は、開発プロセスを通じて心がけていたこと、気を付けていたことをまとめていきます。
「思ったこと」は、半分独り言みたいなもの、考察などを含まないただの感想をまとめていきます。
なお、自身の思考整理のためのアウトプットが多量に含まれていますので、興味のあるトピックをピックアップして読んでいただけたらと思います。
[学んだこと] 他者との乖離を認識できた
この講義を通じた学びとして最も大きかったのは、「他者との乖離を認識できた」こと、そしてそれを習慣化できたことだと考えています。
これまでもチーム開発の経験などはありましたが、これまでの自分が共に開発をしていたのは「Aさん」「Bさん」ではなく、自分の中に存在するイマジナリーの「Aさん(仮想)」「Bさん(仮想)」であり、他者との乖離を認識できておらず、その乖離を埋める努力を怠っていたことに気が付きました。
また、ユーザーが「欲しいもの」と自分が「ユーザーが欲しいだろうと思っているもの」の分離についても意識的にできていたわけではなかったので、その点に関しても意識できるようになりました。
「エンジニアリング組織論への招待」は、それらの気付きのきっかけとなった本です。この本で読んだ内容をenPiTでの体験と結びつけることで、知識を自身の体験としてブラッシュアップすることができました。
[意識したこと] 外部からのInputをOutputする
私は、enPiTをアジャイル開発を学ぶ、Inputができるだけでなく、講義内で学んだこと、自分なりに考えたこと、インターンや本など、外部で学んだことをノーリスクで実験する、Outputすることができる場だと考えていました。
結果責任は問わないという前提で、チャレンジを推奨してくれる会社はありますが、金銭的にも心理的にも完全にノーリスクで挑戦できるのは学校の講義ならではですし、本当に貴重だと思います。
[意識したこと] 何かを良くするためなら、遠慮せず声を上げる
より良いプロダクト、より良いチームを作るにはメンバーが主体的に「こうするともっと良くなると思う」という声を上げ、他者から「フィードバックを受け取る(という姿勢を見せる)」ことが重要だと思っています。
チームとして、組織として環境に適応(環境に合わせて改善)していくには、メンバーそれぞれが「アウトプット」をして「フィードバックを受ける」というプロセスを繰り返して改善をしていくことが必要だと考えています[9]。
また、プロダクトのUXに直接関わる部分のみを改善するためだけに(例えば、PBLの優先順位を決定するためだけに)アジリティを発揮するのではなく、チームや組織、enPiTという枠組みであれば、講義の改善にも受講生として貢献していく姿勢が、結果としてプロダクトの改善に繋がると思いますし、受講生がよりよい学びを得ることにも繋がると思います。
[意識したこと] チームメンバー全員が「幸せ」になるチーム作り
長かったので別の記事として分割しました。
[思ったこと] 優秀賞取れて嬉しい
頑張ったことがこのように評価されるのは嬉しいです(正直、最優秀賞取れなかったのはとても悔しいですが)[10]。
並走してくれたチームメンバーに感謝です。
また、はこだて未来大学でのenPiTの分野WSでも発表を行うので、私たちのプロダクトや、チームでの取り組みを共有していきたいです。
他大学のチームとも交流できそうなので、技術的な話やチームビルディング、開発の進め方など、色々話を聞きたいと思っています。
さいごに
このような素晴らしい機会を提供してくださった教員の方々、メンターの方々、チームメンバーのみんなに感謝します。
これからも感想畑の開発は続けますし、進路としてもWeb系企業に就職する予定なので、今回の講義の学びを活かして社会をより良くしていきたいと思っています。
院生は貰えないようです…。
現在は筑波大学情報学群の研究室のみ対応しています。
「デモに参加してくれたユーザーに対する課題の前提の共有不足」「デモで提供する体験が想定しているユースケースと異なる(ので、価値検証したい内容と齟齬が生まれる)」という課題もありました。図中の「体験を意識」という取り組みはこれらの課題を解決しようとしたものです(私個人としては、これらがフィードバック数に対するボトルネックだったと考えています)。
これは、オンライン併用の講義であるenPiT特有の課題かもしれません。
この方法は私たちのチームで考えたものではなく、講義で指定されたテンプレートです。
「共感できるふりかえりに★マークを付ける」方法はenPiTのメンターの方に教えてもらいました。困ったことは(個人でも、チーム内でも)抱え込まずに、どんどん聞いていくのが大切ですね。
1について、念のため補足しておくと、私は、チームメンバーが「価値のあるプロダクトを作りたい」と思っていない、とは思っていません。ここでは、私ができた可能性のあったことを議論するため、このような表現を用いました。
もちろん自由参加でやりました。ちなみに教材はこれを使いました。
チームを改善する目的は、チームとしてコンセンサスを取っておいた方が良いと思います。「みんなが楽しく開発できることを目指す」のか「エンドユーザーに価値を届けることを目指す」のか、など。状況によって求められるものは変わりますが、どんな意思決定も間違いではない思います。
16チーム中6チームが優秀賞、1チームが最優秀賞を受賞しました。
この記事が気に入ったらサポートをしてみませんか？