パンうめぇ

園児ニアの日記帳

enpitに参加しました!

12/22日にenpitの発表会があり,もう一週間たってしまったのですが,得られたこと,感じたことを忘れないように書き記していきたいと思います.

まずenpitとはなんぞやってことですが, 情報人材育成のプログラムで,4分野における高度IT人材の育成を目指しているものです. この4分野は以下に分かれています.

  • ビッグデータ,AI分野
  • セキュリティ分野
  • 組み込みシステム分野
  • ビジネスシステム分野

今回僕たちはビジネスシステム分野で,アジャイル開発を通してWebアプリを作成し,成果発表会で発表するという取り組みを行いました.

www.enpit.jp

開発したプロダクト

自己紹介と共通点の抽出ができる名刺に近いアプリを作成しました.

キャッチフレーズは 「人見知りのあなたも,初対面から熱く語ろう」

アプリはこちらです. ぜひ使ってください!!

Github

github.com

なぜ参加したのか

Webアプリの開発に興味があったのと,ポートフォリオを学生のうちに残しとかないとなーという思いがあったからです.あとは無料で県外にいけるので(笑)

チーム開発が好きっていうのもあります.

チーム開発のプロセス

  • 期間
    • 10月~12月
  • 手法

アジャイルスクラムという開発手法を用いました.

僕はスクラムマスターでした.メンバーに恵まれて基本的は楽でしたが,発表前は資料準備や残ってる作業のタスク管理でお腹が痛かったです(笑)

一週間のスプリント

火曜日にデモ・レビューを行い,得られた意見を振り返りながらKPT分析とタスク割当を行いました.

そんでもって土,日はモブプロ,他は個人作業で常にTrelloやLINE,slack等で進捗確認を行いながら作業しました.

アプリを開発していくと,どうしても開発者側の偏った視点に立ってしまい,使いづらいUI/UXになりがちです. なので,火曜のデモで他チームからのユーザー視点な意見がすごく助かりましたm( )m

大変だったこと

  • デザインの統一

これは一番苦労しました.

僕たちのチームには6人中デザイン班が4人もいたので 宗教戦争が勃発し,統一性のないデザインになってました.

なかなか意見がまとまらず意思決定が遅くなっていたので,週2でデザイン班は集まりを設けて意思疎通を行うようにしました.

  • レールを外れたModelの扱い

これはRuby on Railsのレールを外れたModel処理を行おうとして沼った問題です.

Railsは設定より規約なので,レールを外れると度々闇の中に放り出されましたorz

  • エレベーターピッチ

僕たちのアプリが機能上マッチングアプリと勘違いされやすく,コンセプトがうまく伝わっていないことが多々ありました.(たぶん9割伝わってなかった...)

なのでアプリ本来の使い方をしてもらえず,レビューを見ながら 「違う,そうじゃねええええ」と心の中で連呼してました.

いろいろ相談した結果,エレベーターピッチの説明がいまいちだということを指摘され,メンバー全員の語彙力を集結してなんとか簡潔にまとめました.

たとえ高機能でも意図したように使ってもらえないと意味がないので, 語彙力がほしい....

  • 学業との両立

他の課題がめちゃくちゃ多くて,結局0:00まで作業することもしばしばありました.

睡眠大事(戒め)

  • 遠隔メンバーとの作業

メンバーに一人仙台の方がいたので,遠隔でモブプロするのが大変でした.

画面共通ツールを使っていたのですが,ラグや解像度の問題でなかなかうまくいきませんでした...

enpit発表当日に教えてもらったのですが,どうやらVSCodeにリモートペアプロが行える機能があるそうですね!

はやく聞いとけばよかったなあ

工夫したこと

  • 認識のズレをなくす

一番気をつけました.デザインのこともあり,とにかく共通認識をもつためにペアプロ,モブプロを積極的に取り入れて,作業報告はコミュニケーションツールを使い事細かく行いました.

おかげで同じところを作業したりすることもあまりなかったです(あまり)

ペアプロをすると進捗が1/2に減るかもしれないと思われますが,実際は作業効率が2倍近く上がったと感じます.

あと,ミーティングに遅刻したら全員にアイスを奢るということで時間の認識のズレもなくしました.二回無料でアイスが食べれました(๑´ڡ`๑)

スプリントバックログを細かくすることで,作業の見積もりを行いやすくしました.

改善点

  • テストの記述をおろそかにした

テストほとんどかいてませんゆるして

テストに対する知識が足りないのと,毎回のデモで進捗を見せないといけないという焦りから,ModelTestをほんのちょっとしか書いてませんでした.

結果,後半になるにつれおもわぬバグが発見されることが度々あり,テストで潰しとけば安心して開発ができたと思います.

ただ,テストを勉強しながら開発するとスケジュール的に間に合わなかったと思うので,そこらへんの調整は難しいと感じました.

  • issuesの活用

他のチームを見てみると,わからないことがあればすぐgithub issuesに書き込むことでメンターさんからアドバイスを貰え,効率よく開発を行えていました.

自分たちチーム(の主にバックエンド)はわからないことがあっても,数日考えて作業してたので,少し効率が悪かったもしれません.

これからは積極的に活用していこうと思います.

  • メンターさんとのコンタクト

前述のissuesと重なりますが,メンターさんに相談することが少なく,内側で活動していたのも反省点です.

enpitを通してまなんだこと

  • ユーザー視点にたつ

ユーザーにとって何が大切か,意外と開発側では見失うこと多かったと思います.

なのでユーザーレビューを取り,どうすれば使ってもらえるのかを考えることが重要だと痛感しました.

  • 会話の重要性

意思疎通は重要だと思います.

1年生の頃はコーディング能力さえあればプログラマはなんとかなるんじゃないかと思ってましたが,一人で開発するには限界があるので,チームマネジメントみたいなスキルが必要不可欠だと学びました.

やっぱりコミュ力大事ってことです(震え)

感想

いろいろ思うところもありますが,なんだかんだ楽しかったです!!

アプリを作った背景が,「仙台の方と仲良くなりたい!」という想いだったので,コミュニケーションも取れたし,一緒にお酒も飲めたし満足です.

Best Team賞もいただけて,メンバーに恵まれたと思います.

またなにかしら開発したいです(^^)