はじめに
この記事は新卒1年目の終わり頃に上流工程の一部をチョッピリ任された案件の個人的振り返りです。
案件を振り回した讒言てきな意味合いもあるんですが…そこは社内の反省会でしごかれてきます。
こんなことがあった、ここがしんどかったとかKPT法を使って振り返りたいと思います。
案件で何したの？
GASを使った簡易的なwebアプリを作成しました。そのため、アサインメンバーも2人だけの超小規模開発でした。
<案件メンバーの役割り>
- 上長:
作業方針とかMTGの助っ人的存在。 - 自分:
お客さんとのMTGは基本的に自分が担当。
開発も自分がする。 - フロント開発メンバー1:普段はPMをしている他部署の上司。案件の助っ人として途中から参戦してくれた。
- フロント開発メンバー2：
フロント開発の凄いひと。「爆速の」●●さんと言われるぐらい作業ペースがヤバい人。同じく助っ人として参戦。最近は「神速の」にクラスアップしたらしい（たぶん本人は知らない）。
振り返り(KPT法)
良かったこと・共有したいこと・気付き（Keep）
要件定義、マイルストーンの設定について
開発の上流工程でやっていることについて、何をしているのか、お客さんと話すことについて実際に体験することができてよかった。
タスク切りのチケットについて
チケットがあらかた作成されている状態から作業は始めるものと言う事実を初めて知った。
作業の前にはチケットが完成していたので、どのタイミングで作成しているのかよく分からなかった。
gitでの開発について
gitの開発手順や付随するコマンドの扱い方の知識が少し身についた。
- コミットコメントの扱い方
- PRでの指摘や確認方法について
問題点・課題点（Problem）
環境選定に関して
開発環境のリスクに関して十分に説明できていなかったこと。
開発開始時のGASの選定理由と懸念点に関しての説明ができていなかった。
プロトタイプの作成、アジャイル開発だからこそ環境を適宜、選択肢する必要を伝えておくべきだった。
スプレットシートのレスポンスの悪さは使ってみて分かったことだが、開発規模の大きさによっては開発環境が不十分なものになるぐらいは説明するべきだった。
スケジュール感・成果物に関して
制作物の工程と制作物が明確になっていなかった。
特にCSS(デザイン)に関して、どのタイミングで作成するかが抜け落ちていた。
プロトタイプと言えども、最終的は理想像は持っておくべきだった。
最終的は理想像に近づけるために何をするべきかを考える必要があった。
2.3 改善点・反省点・次回やってみたいこと（Try）
フロントデザインの重要具合
モノのデザインは非エンジニアに触ってもらう上でかなり重要だった。
非エンジニアと成果物を握る時にはデザインの工数は必要なくても盛り込む。
開発への積極性
言われたものを作るぐらいの心構えしかなかったのはかなり反省するべき点。
自分が使った時の印象は最低限、ユーザー（クライアント）が抱く感想。
制作者としての個人的な妥協は仕事として甘えと同義。
GitのPRについて
PRで何を確認する必要がるのかは勉強する必要がある。
PRのmerge直後に修正依頼をすることが多々あったのは反省点
おわりに
振り返りをしてみて、エンジニアとして何を気にしているのかが本当にチョッピリわかったような気がします。特にTryに関しては次の案件で改善出来るように心掛けていきたいと思います。KPT法のフレームワークに従って正しく振り返りが出来ているかは怪しいですが…ちょっと気にしてやってみたと言う感じで許してください。