見出し画像

enPiT個人レポート 〜初めてのアジャイル開発を通して〜

たくみ

はじめに

この記事は、筑波大学大学院で開講されている授業の「プロジェクト実践ワークショップ」および「イニシアティブプロジェクトI」における最終レポートです。
本ブログでは、特に秋の授業「イニシアティブプロジェクトI」に関して書いていますので、enPiTの履修に迷っている方などはご一読いただければ幸いです。

enPiTに参加したきっかけ

私は現在、筑波大学大学院 情報理工学プログラムに所属しているのですが、大学院に進学する前の学部時代では、あまり実践的なスキルや経験がなく、自身の実力に不安を感じていました。
学部3年次にもenPiTの授業の履修は考えましたが、「ついていけるか不安」、「大変そうで気乗りしない」、「半分くらい宗教みたいな感じで入りにくそう」などの不安があり履修には至りませんでした。まあ実際行動力がなかっただけでこれらは言い訳に過ぎませんが。
そんな中大学院で授業の履修を考えていると、「実践的ITカリキュラム」というものを目にし、修了証もいただけるということでなにかしらの実績が欲しかった私はそのカリキュラムを履修することを決めました。
その中にenPiTの授業の履修があり、本授業への参加に至りました。

チームについて

チーム名

理工情報生命学術院チーム

チームメンバー 

  • O.Hくん：プロダクトオーナー(PO)

  • M.Sくん：スクラムマスター(ScM)

  • D.Rくん

  • Y.Cくん

  • A.Mさん

  • S.Nくん：春授業のみ参加

  • S.T：私

他のメンバーの活躍

O.Hくんがプロダクトオーナーとして、最終意思決定を委ねられる場面も多く、活躍していました。
M.Sくんはスクラムマスターとして、Miroの整理やチームの意思確認、メンター・教員の方への声かけなど開発外での取り組みに力を入れてくれていました。
D.Rくんは、Webアプリの開発に関する知見が多く、Next.jsのスキルを活かして、開発の先導をしてくれていました。
Y.Cくんは、積極的な意見出しやモックの作成などで活躍してくれていました。
 A.Mさんは、デザイン力・資料作成に長けており、モック作成や最終発表資料の作成で活躍していました。
S.Nくんは、春授業のみの参加でしたが、唯一のB3で中々アウェイな状況の中積極的に取り組んでくれていました。

プロダクトの概要

プロダクトの名前：感想畑

どんな課題を掲げていてどんなプロダクトなのかについては、こちらのスライドで共有しておきます。
スライド開くのはめんどくさいという方のためにエレベーターピッチと、参考画像を以下に貼っておきます。

エレベーターピッチとは、エレベーターに乗っているくらいの短い時間で自分自身や自社のビジネスなどについてプレゼンする手法のことで、アメリカのシリコンバレーが発祥とされます。

https://qr.paps.jp/SDpLF

エレベーターピッチ

「感想畑かんそうばたけ 」は、
「論文を理解するのが難しい」という課題を解決する
「筑波大で研究に取り組んでいる人向け」の、
「論文感想共有システム」です。
これは「他人のレビューを参考にできる」ことで
「通常のGoogle ScholarやNotion」とは異なり、
「論文を理解しやすく」なります。

プロダクトの画面

ホーム画面
メニュー画面

以上のようにホーム画の他にもマイページ・マイラボページなどがあり、研究室内で論文のレビューを共有できます。

使用技術

スライドには記載していないため使用した技術について簡単に紹介します。基本的にフロントエンド側もバックエンド側もNext.jsを使用しています。データベースにはFirebaseを採用しています。

プロダクトの開発

本章では、開発の方法やどのように進められたか、どのような課題に直面したか、などを簡単に共有したいと思います。履修前の学生は、授業の開発がどんな感じに進んでいくのか想像できるかなと思います。

秋授業のスタート前

私たちのチームでは、夏合宿では似たような課題に対するサービスとして「情報工学先生」を制作しました。
夏合宿が終わり、メンバーも1人B3の子が抜けてしまったのみで、変化が少なかったことから「このプロダクトを継続して進める」か、「新しいプロダクトを作るか」に関して話し合いました。
結果としては、新しいプロダクトを作る方針となりました。その理由は、「情報工学先生にこれ以上の拡張性が見込めなかったこと」が大きい理由として挙げられました。
しかし、秋授業は春授業と違って、課題を設定する時間があまり設けられていないため空いている時間でミーティングを行なって、課題を決める必要がありました。そのためこの時点ではメンバー間で細かいすり合わせができていない状態で課題の決定をしてしまっていました。

序盤〜課題とソリューションの決定・方針の決定・走り出し〜

授業が始まり、設定した課題が妥当かどうかミーティングをしたり、それに対するソリューションに関して議論をしました。秋授業でしっかり擦り合わせていなかったことが仇となり、議論が発散したり、衝突していた記憶があります。
長い議論の末、ソリューションの方針は決めることができました。しかし、この時点でも議論が発散しやすいことや細かい擦り合わせができていないことは解消できていない状態で走り出しました。
また技術選定でもチーム全員の技術力を配慮することは厳しく、わからない人は勉強会などでキャッチアップしていく方針となりました。

中盤〜フィードバックの危機感・キャッチアップの困難さ〜

ソリューションの決定・技術選定ができたところで本格的に開発が始まりました。授業でどのようなプロダクトにするのが良いかをフィードバックを得るために初めはFimgaを用いてモックを作成することにしました。ただ、開発も進めていかなければならないためモック作成班と技術班に分かれて作業をしていました。この分業の仕方はフィードバックを得るという観点では、効果的ではありましたが、キャッチアップで必死になっているメンバーと技術班の技術力の差が開いてしまったのは良くない点でもあったかなと感じています。
プロダクトの開発が進み、レビューで実際のプロダクトを触って、フィードバックがもらえるようになった頃、以下の2つ問題点があがりました。

  1. フィードバックが全然もらえない、質が良くない

  2. 開発にコミットできる人が少ない（属人化)

たった一件のフィードバックの回

以上のようにフィードバックがたった一件しか得られない回もありました。原因はさまざまですが、主な原因として、ユーザがプロダクトを使っているときのイメージが湧かないことが考えられました。
また技術力に差が開いていき、開発の内容がわからず、ついて来れていない人も中にはいました。もちろん意見やアイデア出しに注力して開発はあまりコミットしなくても良いというスタンスの人だったら良いのですが、開発にコミットしたいのにできないという人がいたのが残念でした。勉強会やモブプロなどいくつかの対処法は試しましたが、最終的にキャッチアップすることは叶いませんでした。

終盤〜独自の工夫・開発スタイルの定着〜

開発中盤で直面したフィードバックが上手く得られない問題に対して私たちのチームでは以下のような工夫を施しました。

  1. 画面共有の廃止

  2. 案内人の派遣

  3. メンターにプロダクト上でレビューの投稿を依頼

  4. 課題背景の詳細な説明

なぜ、以上のような工夫を施したか。まず、私たちはフィードバックが上手く得られないという問題は、ユーザが体験できていないこととフィードバックに対して消極的であることが原因にあると考えました。
そこで、より実際の体験に近づくようにメンターの方に論文レビューを投稿してもらうことでプロダクト上のデータを増やし、課題背景の詳細な説明・画面共有を廃止することで一緒にプロダクトを体験していくようなデモを行うようにしました。
 これだけでもだいぶフィードバックが盛り上がり、さまざまな意見を吸収することができました。さらに私たちはdiscord上で書きづらい内容も汲み取るために案内人を派遣し、より多くのフィードバックを収集するように努めました。

また開発に関しても、軌道に乗ってきたことでタスク割りや開発速度が上手くいくようになってきていました。個人的には最初の方は全員で歩幅を合わせて進んでいき、ある程度軌道に乗れたら、PBIごとにタスクを割り当てて多少の属人化は許容しながら進んでいくのが効率的なのかなと感じました。（アジャイル開発初心者の意見なのであまり鵜呑みにはしないでください。）

最終発表

なんだかんだで、チーム内で意見も統一でき、動くプロダクトを作り上げることができました。私たちのチームでは、なかなか上手くいかないところはあったもののたくさん議論し合い、たくさん試行錯誤して進めてきたので最終発表には自信を持って挑むことができました。実際に発表したスライドが先ほど記載したものです。（再喝)

そして、結果は・・・・・！！！
見事、優秀賞をいただくことができました。
（最優秀賞を狙っていましたが、琉球大学に神レベルのチームがありました。。。悔しい。。）

表彰時の写真

上記の画像にはenPiTにて琉球大学のチームNINが開発した肖像権指パッチンというプロダクトを使用してモザイク加工を施しています。

個人的振り返り

チームに関して

全体的にみんな優しく、かつ積極的に取り組んでくれるチームであったので個人的には居心地は良かったです。仲も良くなれたし、このまま付き合いは途絶えないでくれたら良いなと思っています。ただ授業を通して、細かい意思統一や全員の意思の尊重は叶わなかったと感じました。

細かい意思統一ができなかったというのは、例えば「勉強も残業の内かどうか」、「自主的な残業をされてどう思うか」、「残業の中でどんなことならやっても良いか」などの意思統一はできていませんでした。特に自主的な残業というのは、意欲的で素晴らしい様に聞こえますが、実際はやる気はあるけど残業できない人にとってモチベーションの低下につながることだと思います。そのため残業の中でやってもいいのは技術者の開発のみで議論や方針の決定は行うべきではなかったと個人的には思っています。（異論は認めます）
来年の履修生で、もし読んでいる人がいたら、チーム全体で意思統一を図るためにメンバーの意見は全力で引き出せるように努めた方が良いと思います。（難しいポイントですが・・・）

続いて全員の意思の尊重が叶わなかった件についてお話しします。私たちのチームでは全員「開発経験を積みたい」、「技術力を磨きたい」、「プロダクトに積極的にコミットしたい」という思いがあったと思います。（少なくとも私はそう認識しています。）
その中で、実際に自分のやりたいことができたなと感じたのは私の他に1、2人程度なのかなと思いました。
最後までキャッチアップが叶わず、開発にコミットできた人は少なく、モック・資料作成や議論に参加して終わってしまった人もいました。本当に申し訳ないなと感じています。ただ、私は全員の技術を合わせて素晴らしいプロダクトを作れるような力は持っておらず、全員の意思を完全に叶えることは難しかったかなと思います。特にこの授業は、課題とソリューションに対して技術を選定するものですので、メンバー全員が持っているスキルから選定するのは難しいためです。そうは言っても叶えられなかったことは残念でしたし、特に私はチーム全員が楽しく有意義に過ごせることを目標にしていたので申し訳ないと思っております。

この授業を通して、チーム開発というのは考慮するべきことがたくさんあり難しすぎることを学びました。ただ、個人的にはやはり人と一緒にものづくりができるのは楽しいですし、良い経験になったと強く感じています。チームのみんな、ありがとうございました。少しでも良い経験だったと感じてくれていたら幸いです。

授業に関して

総合的には、実践的で学べることが多く、経験を積むという観点からは申し分のない素晴らしい授業でした。もう少し単位がいただけたら神だと思います。
ここでは、よく挙げられていた以下の意見について私の意見を述べておきたいと思います。

  1. 開発時間が短い

  2. レビューが形骸化している

1.開発時間が短い
これは、本当に短いです。夏合宿ではまとめて時間をとっているためあまり短さは感じませんでしたが、秋は1スプリント(2時限分)で開発・デモ・振り返りを行うため、時間が足りないと感じることが多かったです。正直、残業しないと良い評価がもらえるプロダクトを作るのは厳しいかなと思いました。
ただ、メリットもあると思います。少し短すぎる気がしますが、実際の業務でも納期に追われ、短い時間内で最低限の完成度のものを提供することが求められることは多いと思います。そのような場合のための訓練と考えたら、一概に悪いとも言えないかなと思いました。
結論としては長くできるなら長くしてほしいですが、授業の時間的にも改善は厳しそうなので、受講生の力量が試される部分かなと思います。

2.レビューが形骸化している
これは、レビューの機会が多く開発時間を圧迫する上、意義のあるレビューが行えているところも少ないという意見です。この件に関しては、レビューの回数は2回の授業で1回で良いかなと感じましたが、形骸化はしていないと思っています。
レビューの回数を2回の授業で1回にした場合、前回の授業で何をやったのか忘れていてうまくレビューができないなどの問題が挙げられると思いますが、それは 振り返りや PBLリファインメントの重要性を認識する機会になると思います。
形骸化していないと考えた理由は、「どうしたら良いフィードバックをたくさん得られるか」をいかに工夫できるかが求められており、それが上手くできていないところは良いフィードバックを得られていないだけと感じたからです。実際、社会で良いフィードバックを得るのも容易ではなくさまざまな工夫がなされていると思います。本授業でも工夫次第では良いフィードバックを得ることは可能だと思いますし、実際に私たちのチームでは完璧とは言えずとも改善をすることができました。
ただ、オンラインによる制約やフィードバックへ真面目に取り組んでくれない人がいるなどの問題点はあるためレビュー形態に関しては改善の余地はあるとは思います。

自身に関して

この授業を履修して、チーム開発の経験・開発スキルは十分に向上させることができたかなと思います。ただ、以下の2点はもう少し頑張れたかなと感じております。

  1. チームメンバーへの配慮

  2. アジャイル開発に対する理解

チームメンバーへの配慮
これはチームに対しての振り返りで述べたように、もっとチームメンバーの夢や目標を叶えてあげられたかなという反省です。私個人としては、全員が成長を実感できて、全員で達成感のある授業にしたかったので、そこは少々不完全燃焼な部分がありました。特に開発へのコミットと残業の点では、メンバーの意思を汲み取りきれていない部分があったかなと思います。どのようにチーム開発を進めて、どんな風に貢献したいかなどをもう少し深掘りしておけたら良かったのかなと思います。ただ、個人個人でモチベーションや目標は異なり、全員が満足するように進めるのはなかなか困難であるという学びは得られました。

アジャイル開発に対する理解
これはもっとアジャイルのフレームワークを理解しながら開発を進めた方が良かったという反省です。何となくアジャイルとはどういうものであるかは理解できていたものの、しっかり規則通りに進めていたかというとそんなことはありませんでした。スクラムマスターが規則に則って進行してくれたためチームとしては破綻しませんでしたが、自分ももっとアジャイルに関して理解を深めながら、進めた方がチームに貢献することができたと思います。

最後に

enPiTに関して私の意見や感想を述べてきましたが、本当に実力が身についたことを実感できましたし、本当に楽しい授業であったため履修して良かったなと思います。
また、メンターの方々、川口先生をはじめとした教員の方々、全員の授業に対する熱意は素晴らしく、多くの人にその思いが届いたら良いなと思います。本当にありがとうございました！
大変拙い文章をここまで読んでいただきありがとうございます。

この記事が気に入ったらサポートをしてみませんか？