開発したプロダクトについて
春学期：情報工学先生
論文の調査を支援するプロダクトです。ある論文の参考文献をバックトラックできます。
秋学期：感想畑
論文の読解を支援する、筑波大生のためのプロダクトです。他人の論文のレビューを参考にできます。
EVP
機能
- トップ画面
論文のレビューが、最近投稿されたものから順に閲覧できます。 - ユーザ登録/ログイン
所属研究室、氏名、研究分野などを登録します。
（投稿の信頼性を上げたり、研究室単位でレビューを管理するために使います） - マイラボページ
ラボメンや指導教員の先生が書いた論文のレビューを閲覧できます。
研究室内で、論文の調査結果を共有しやすくなります。 - 投稿/編集とコメント
ある論文についての読んだ結果を書いて、投稿できます。- 書く際の負担を減らす機能
- DOIによる論文情報の自動補完：論文のDOIを入力すると論文情報を自動で全部埋めるようになっています。
- 編集機能：一旦投稿したレビューを、もう一度編集できます。
- マークダウン記法で書ける
- 書くモチベーションを上げる機能
- 画像を追加できる
- コメント欄がある：投稿には全てのユーザがコメントを書くことができます。
- 書く際の負担を減らす機能
- マイページ
ユーザ自身が投稿した論文のレビューを確認できます。
自分自身で論文の調査結果を振り返れるため、投稿するモチベーションが上がります。 - 研究室一覧
他の研究室について、レビューの一覧を確認できます。
担当した箇所
- 開発者として：サーバの一部の関数、初期の投稿フォーム、レビューの修正ページ
- その他：Figmaのモックのごく一部、PBLの作成・修正
学んだこと
- アジャイル開発は、「すぐ使える、すぐ効果を観察できる、データをとりやすい」システムを作るのに向いている。
チームについて
- Mくん：スクラムマスター。開発者。スプリントの枠組みから事務まで幅広く担当した。開発にも積極的に参加していた。スプリントよりも長期的・メタ的な何かを分析して課題点を見つけるのが圧倒的に得意だった。
- Tくん：開発者。next.jsとfirestoreに早く適応した。成長が早かった。
- Dくん：開発者。春・秋学期のテックリード。プロダクトのUXや価値についてアイデアを出すのが圧倒的に得意だった。
- 私：プロダクトオーナー。開発者。
- Cくん：プロダクトのデザイン・UXを考えるのが得意だった。
- Mさん：モックアップ・最終成果発表会のスライド作りが圧倒的に得意だった。
プロダクト・チームの軌跡
春学期 情報工学先生の開発
私たちのチームは、「研究を体系的に理解したい」という課題について関心を持つメンバーで集まって作られた。以下のような課題に直面した。
- アーリアダプタが少ない
- 競合がconnected papers, google scholarなど、たくさんあった。
差別化しようとすると結果の可視化方法などを工夫する必要があるが、適切なグラフ構造を決められないしレンダリングできない。 - 議論が過熱する。
秋学期 感想畑の開発
春と異なるプロダクトだが、やはり研究のためのプロダクトを作った。
実装した順番：以下の順でプロダクトの機能が成長していった。
- 最低限の機能
トップページで論文が見られて、投稿ができる。 - 閲覧者の体験を向上させる工夫
以下の機能をつけた。- プロフィール画面
レビュー投稿者の属性がわかり、情報の信頼性が上がる。 - マイページ
自分の投稿（レビュー）を振り返れる。 - タグ検索
自分がほしいレビューの情報がとってきやすくなる。 - マイラボページ
ラボメンや先生のレビューが見られるようになる。 - 新聞アイコン
論文のあるサイトへアクセスできる。
- プロフィール画面
- 投稿者の体験を向上させる工夫
- DOIによる補完
投稿欄では、論文タイトルなどの情報を打ち込むのが面倒であった。論文のDOIから論文情報を自動で埋めるようにして負担を減らした - Markdown記法を使えるようにした
- 投稿を書き直せる（編集）ようにした
1回の投稿では書き上がらないため。 - コメント欄をつけた
コメントがつけばモチベーションが上がる？
- DOIによる補完
開発を通じて起きた問題
- レビューを投稿するモチベーションがない
本文が長大である。またユーザにとっては、何のため・誰のために書くのか目標がはっきりしない課題があった。 - フィードバックが少ない
このプロダクトのアーリアダプタはB4~M1だが、enPiT授業では数が少ない。
レビューをやってもフィードバックの質・量が足りない課題があった。
以下のようにレビューを改良した。- 案内人の配置：ユーザのそばにメンバーが赴く
- 画面共有の廃止
- 質問の数を絞る：質問は1個だけにした。
- プロダクトの使用サイクルが長くて重い
このプロダクトを使って論文の読解を進める場合、ある論文を選ぶ→感想畑を見る→論文を読む→感想畑を見る→論文を読む...といった流れになる。
使用サイクルに終わりがない。重い。enPiTのレビュー時間中に効果が現れない。 - 投稿者・投稿が少ない。データがとれない
- 振り返らない
スプリント開始時に前回授業で起きたことを振り返らない癖があった。
これは解決された。 - コード書けない
- 開発者間での齟齬
学んだこと
- メンバーごとに考えていることが違う。確認が重要
- アジャイル開発は「すぐ触れられる・すぐ使い終わる・すぐ効果を見れる」システムを開発するのに向いている。長期にわたって・少しずつ効果が現れるプロダクトは本質的に向いていない。
- 現代のソフトウェアは、要求される機能の水準が高い。必然的にユーザ機能が必要になり、ユーザ機能を実装するために結構なコストが割かれた。
期間を通じた個人的ふりかえり
得られたもの
サーバへの関心、Webへの関心、多様なメンバーと協力するための力
最新技術にキャッチアップできない
TypeScriptが怪しい、Reactを使ったことがないままnext.jsの開発に挑んだ。
夏休みにReactに触れておくべきだった。
価値を考え出す力が弱い
技術を知らないのでプロダクトで実装できるものを想像できない。結果、プロダクトの価値を高める・現実的なデザインを考え出すことができていなかった。
今後やったほうがいいこと
- サーバとして使える技術を1個習得する。例えばGCPやAzureなどのクラウドコンピューティングサービスに触れる。フロントは向いていないため、サーバサイドに特化したほうがよい。
- 人を頼れるようになる。困りごとを抱え込む癖があり、2つ影響が出ていた。
1つ目に技術の成長が遅くなったこと,2つ目にユーザの困りごとを解決する方法を想像できなくなっていたことが挙げられる。
