# 反省会→これはメモ書きなので、後で清書用のページを作ろう
## スケジュール面からの振り返り
- 向後くんが作っていた資料と当初の目標を突き合わせたい
## プロジェクトの進め方

- こまめなコミット、プッシュ、ブランチをきる（向後）
- コミット・ブランチの粒度をルール化するべきだった（稲葉）
- コミットに関しては[commitizen](https://dev.classmethod.jp/articles/commitizen/)などのツールを導入したい。（稲葉）
- 開発環境の効率化と統一ができていなかった。個人的に一番大きな反省（稲葉）
- gitについての知識がガチで無かった　根幹部分のところなので、真剣に勉強会を一回すべきだった　チーム内のgit運用のルール、履歴の見方、差分の見方くらい統一できてればまたちょっと違った気もする（前田）
- ソースコードレビューみたいなこともしたかった　まあ余裕がなかったのが一番の原因ではある（前田）
- 個人の責務がガバガバになっており、結局としきが解決していた。（稲葉）
- 共同開発って難しいよなあって思った（前田）
- スキルがまだ低いこととかとかDB構成の理解度的に、ある機能の開発を全部丸投げするということがむずかしくて、こっちで作業を細分化してから投げようとしても、そのくらいの作業であれば説明して振って出来上がるのを待つ（一週間）よりも自分でやれば数時間だな、となって自分でやる、みたいなジレンマがあった（前田）
- 会社とかで、部下を教育するとかなったら結構ダメなムーブな気がする（前田）
- 最低限動くものをまず作る。それが終わったら体裁を整えるということを徹底したい。体裁は気にし出したら無限に時間が溶けてしまう。最初からいいものをつくろうとしない。（向後）
- 俺もこのイメージにすごい賛成だけど、UIをしっかり作りこむという話と矛盾してない？（前田）
- どれくらいの
- 必要な工程をリスト化して見通しがつくようにしたい(Treroのようなもの)（向後）
- いついつまでにこれを作るみたいなスケジュールが大まかにしか描けていなかった。意識としても今やっていることとそれに対する締切が結びつけていなかった。意識してこれはいついつまでにやるべきなどを念頭にないといけない。スケジュールが人から与えられたら、それを模写するぐらいの気持ち(さらにそこから自分で細かいスケジューリング)ができたらよい（向後）
- 初めての経験だったので仕方なかった、というのを踏まえた上で、アプリ開発のフェーズは王道に沿うべきだと思った。去年の夏に見た[これ](https://budibase.com/blog/how-to-make-a-web-app/)↓（稲葉）
-
1. Ideation（実現したい機能を決める。これはできてた）
2. Design（UI・プロトタイプ作成）
3. Development（DB設計→フロントエンド→バックエンド）
4. Launch（実運用開始。徹夜で（向後が）なんとかした。）
- 開発前はこのフェーズ分解はなあなあでよくね？と思っていたが、今なら重要さが分かる気がする。DB設計もUIを決めてから行った方がベターだった。
- **これめっちゃ感情的にはそうではない（技術自体が低いために、フェーズ分解とかの難易度がとても高いという意味で）　なんか客観的な一般的な知見欲しいな（前田）**
- そもそも今回、実作業に入る前に紙で「作業の遷移図」「アプリのUIのデザイン（案）」「DB構成」を作成している（作業中に色々変更しているが）　作業スケジュールの振り返りとともに、その段階でどこまでできているべきだったかについても振り返りたい（前田）
- Designフェーズに関して、反省会ではタブレット上といったが、ページ遷移もシミュレートしないといけないのでタブレット上ではダメだ。Figmaなどを使うべき。
- 新しい機能を追加したい時は、一度決めた仕様→デザイン→実装→リリースの流れを一通り終えるまで我慢して、次のバージョンの機能として実装すべきと思った。
- テストをしっかりと行うべき　どうしてもなあなあになりがちではあるが…

## 精神面
- 基本締切がなければこいつはやる気を出さない。来週までにhogehogeを実装するという目標の決め方では締切の前日になって手をつけて結局間に合わないということになってしまうので、目標はできるだけ細かく区切ってこの日はこれを実装するといって目標を定めていきたい（向後）
- どうしたって、やる気がでないことはあるのでそういうときは、やる気の出る環境、誰かと作業するなど（向後）
- 自分の遅れは周りのモチベの低下に直結することは留意したい。（向後）
- マルチタスクをこなせる人間ではないのでそもそも複数のタスクを抱えるような状況を作らないスケジュール管理をしよう。お前はバイトがある日にプログラミングとか勉強とかはできない。バイトを優先させない。（向後）
- 自分の持っている作業のイメージの詳細や、そのイメージにするモチベーションの部分を伝えきれていなかったまま投げてしまったことがあったと思うので、意味・意義の分からないものを作っている感じになってしまった（前田）
- 先行してイメージがありすぎて、議論の段階で他人の意見を上手く聞いて取り入れられていなかった気がする（結局のところそういう時は丸投げしていたので、作ってみてもらってからこれでいいやん、となることもあったが）（前田）
- 何かで難航することがあったとき、①分かっていないことがあるのを認めて、②どこまで理解しているか、どこが理解できていないか切り分けて、③わかっていない部分について言語化し、④その部分を調べるまたは質問する　というステップは想像以上に難しい。
- 問題の難易度がスキルに比べて高くないときは体感的に④だけで済んでしまうので、そうでないときに①や②ができない（前田）
- 自分だと、こうしたステップを踏まずに行き当たりばったりであれこれ試してみて上手く行ったらそれでよしとなってしまいがちなので、気を付ける・改める（前田）
- そもそも思い込みで、解決すべきではない問題を意識している場合とか、前提が間違っているとかもあるので、注意深く見直す（前田）
- 自分以外が困っている時も、やみくもに「相談して」と要求するばかりではよくなかった（前田）
## プログラミング
- 間接的な目標としての、開発者のスキルアップ。それなりについた気がする。もう少し個々の課題にフォーカスしてもよい？（前田）
- コメントはしっかりかこう（向後）
- わからない概念や実装はできるだけ、読み解くように努めたい。フワッとした理解のまま使い回すのは効率が悪い（向後）
・繰り返し表現や、共通部分が多いと感じた。抽象化を念頭におきながら開発したい。（向後）
- 簡単な実装をサクッと実装できる実力と慣れがほしい、競プロでも始めるか？（向後）
- わからない概念、機能を「わからずともうごけばいい」ではなく「わかって動かせる」状態にできるように時間が許す限りしたい。「わからずともうごけばいい」では理解が深まっていかない。成長できないし避けられない壁にぶつかった時にそれを解決する力と粘り強さがない。（向後）
- 根本的なスキル不足は、スケジュール組みやモチベーション維持が難しかったり、他人に教えることも不十分になってしまうなど、実作業以外の部分でも負担が増えることを痛感した（前田）

## アプリの出来
- これまでのノートより使いやすくする（ポジティブな面を増やす）
正しく動作する
- 基本的に正しく動作する状態でリリースできた。泊まり事務当モードに関しては改善点あり
- これまでのノートを代替する（ネガティブな面を無くす/減らす）
- 障害・混乱につよいつくりにする
- 仕組み的には実現できている。引継ぎ的な面で課題。庶務部などとの連携は課題。
- 事務当の負担軽減
- 操作時間の短縮
- ミスの減少
- 庶務部の負担軽減
- 要ヒアリング。仕事としては確実に減っているはずだが、pokkeの名簿管理などの保守は、部会の仕事として根付いていないらしい。
受取側の寮生にとっての利便性の向上
好評。slackの利用については要ヒアリング。
- 当初は意図していなかった効果や、間接的な効果があった。（前田）
- 名簿管理がリアルタイムになった
- 名簿管理の利便性はあがったものの、セキュリティ等の懸念がある
- 改善したい↓
- [ ] slackの利用率なども調べたい　調べられるようなアップデートをする
- [ ] さらなる機能追加に向けて、大体これだノートが丸い
- [ ] 不在票のslack飛ばすやつとかどうなんや
- [ ] なんか名簿がどうとかこうとかいうやつ　webapi ruby?
- [ ] 雑記帳電子版（紙を廃止するわけではない）
- [ ] 壁紙をアップデートできる的な
- [ ] 泊まり事務当番わかりにくい。デザイン、UIのみなおし
- [ ] 庶務部管理用メニューの作成
- [ ] 庶務部管理用メニューの中で紛失した荷物の削除をできるようにする。
- [ ] 荷物がいつから紛失したかをタブレットで追えるようにする
- [ ] 事務室、庶務部、荷物アプリへの要望、荷物アプリへの意見をタブレットに入力できるようにする。(庶務部長,情報部技術セクションにslackでDMが飛べばなおよし
- [ ] ヘルプボタン
- [ ] sharing_staus=10が反映される範囲がよくわかってない。寮生同期ボタンはいつつかうのか？
- [ ] 通信時に一度に送る件数を増やす
- [ ] 通信が切断されてることを通知したお
- [ ] 名簿の更新を誰にでもできるようにする
- [ ] 庶務部が定期的に長いこと放置された荷物を削除する

## これからの目標
- 名簿の流出などを防ぐことができる仕組みにする（ただし現状の他の名簿管理のレベルに準ずる）
- あまり良くない。ノートパソコンが剝き出しでおいてある（なぜ？）
- 操作を直感的なものにする/ミスを生みにくいシステムフローにする
- 好評。ただしミスったデータが残っているのもあるらしい。
- システム導入に伴って増える部会等の仕事のフローについてもわかりやすいものを提案する
- 根付いていない。原因や方針をもう少し明確にする必要がある。
- 作業の分担、スケジュール管理、タスク管理の面から、熊野寮へのシステム導入のモデルケースを目指す。（前田）
- （POKKEは）導入前の議論：根回し・BL会議・寮生大会など、意見収集等も積極的に行った。
- 導入前：議論を十分行い、プロセスを踏む。
- 導入後：部会へのシステム導入、引継ぎ等の移行。ドキュメントの整備。ソースコードの整備。
- 寮生ポータルシステムへの発展を見込む

## 引き継ぎ
- そもそも引き継ぐのかという問い（資料システムは引継ぎのことは考えていない）引き継ぐと曖昧に言っているが、もう少し具体的に考えたい（前田）
- アプリのソースコードを引きつぐのか、DB構成のみ引き継ぐのか
- 「引き継いだ人」に何をしてほしいのか
- トラブル対応
- 名簿の管理
- アップデート、機能追加
- 機能的な残存課題の解消
- 泊まり事務当モード的にはどうなっているのか？
- 不在票
- 現状把握、統計等の集約、それらの周知。結構面白いと思います　4か月間で荷物が何件、とかそういうの　好きじゃないならいいけど
- 寮生データ・荷物データをWEB上におけるようになれば、寮に住んでなくても開発・テストできてかなり楽だし、引き継ぎもいらないかもしれない（稲葉）
- 現状の開発環境が限られている（タブレット・閉域）中で実装を強いられるなら、寮内で引き継ぎ人員を確保する必要がある。
- その場合、アプリ開発したい＋αで、ちゃんと自走できる人じゃないと回らない気がする。