エンジニア転職4ヶ月目(2019/01)まとめ
今月やったこと
1.社内ツール開発
当初の予定では社内ツール完成は12月末予定でしたが、遅れてしまい1月中旬のリリースに変更となりました。
リリースに向けての準備
- 現在スプレッドシートで管理しているデータをseedデータにして移行
- 環境ごとの設定
- セキュリティ関連の設定
- リファクタリング
- 当初から変更した部分を仕様書に反映
などなど、思ってたより多い!
目に見える機能や画面を作りきれば完成！という訳ではなく、安全に使うために色々な準備があるんですね。IPアドレスの制限が出来ることすら知らなかった。
また、エラーを通知するツールを入れてもらったことで、エラーが起きた環境や詳細が特定できるようになりました(こんな便利なものが...!!)。
エラーは必ずどこかで起きるという前提で、エラー発見->報告->修正->修正報告がスムーズに進むように考えられているんですね。
特に頑張って実装していたメール機能に関しても、SendGrid上で開発環境と本番環境でユーザーを分けて送信履歴や通知も区別することで、送信・受信ミスをより正確に拾えるようにしました。社内で一番SendGridﾁｮｯﾄﾃﾞｷﾙ人になれた気がする。
リリース...できない
1月後半に無事社内ツールをリリース!! 担当者さんと使用方法も確認!!
「これで使ってもらえる!!」
と思いきや、さっそくエラーが出ました。
エラー対応のために原因を調べて修正しますが、1箇所修正すると「あ、ここもダメだ」という部分が見つかり、GitHubのissueが芋づる式に増えていきます。
エラーが数箇所出るので担当者の方にはしばらく従来のツールを使い続けてもらい、また修正が終わったら再度使ってもらおうということになりました。
こっからめちゃめちゃに辛かったです。
導入スケジュールも大幅に遅れるし、当初考えていた導入手順も開発側の希望と使用する担当者の希望が微妙に食い違ってしまい変更になり、いろいろな所に迷惑と心配をかけているな～という気持ちになりました。
それに加えて1月中はエラー対応を基本的に1人でやっていたのも結構しんどかったです。
CTOや他のエンジニアも関わってアドバイスをくれていましたが、新バージョンのリリースタイミングの決定、エラーの優先度の決定、ドキュメント作成、使用する担当者とのやりとりなどは私が考えてやらないといけません 。
ただでさえ焦りとプレッシャーがある中で、コードを書く以外の仕事も増えてストレスを感じていました。今の会社に入って初めて、本当に本当に一瞬だけ「この仕事続けられるかな...?」という想いが頭をよぎりました。
その後、2月から別のエンジニアがセキュリティ部分のチェックをしてくれたりissueの解消も手伝ってもらえるようになり、かなり気持ちが楽になりました。
仕事量の多い少ないだけでなく、「同じプロダクトに関ってくれるメンバーがいるか」「その人はどれほど深くプロダクトに関わってくれるか」で気持ちはかなり変わるんですね。
その後、エラー修正と同時にセキュリティのチェックもしてもらうことで、ようやく使ってもらえる段階が目の前に来てます。長かった...。時間かけすぎた...。
2.その他
DB強いエンジニアが隣の席に来た
先月から新しいエンジニアがお隣に来ましてめちゃめちゃ喜んでます。今までのメンバーも凄く良いメンバーなんですが、やっぱり同性のエンジニアとなると嬉しい!
現実で女性エンジニア初めて見たかもしれない(愛知だから??)
私は(一応)フロントエンド、その人はDBやセキュリティが主な仕事なので仕事の内容は違いますが、だからこそDB周りなど私の知識が浅い部分でエラーが出たときに相談に乗ってもらうことが多々あります。 シーケンスエラー時もかなり助けてもらいました。
こうして相手の得意分野で助けてもらえる一方で、まだ自分がフロントエンド面で他の人をサポートできるほど実力が無いのが歯がゆいです。得意分野を作ることは特に弊社のようなベンチャーでは大切だと改めて感じます。
js頑張ろ。
最近そのエンジニアから、｢データセンター｣が何か教えてもらいました。 てっきり｢セキュリティ担当の人がたくさん働いている場所｣だと思ったら、サーバーが大量に置いてあるんですね…。
知らないことがたくさんあるなぁ。
仕様を考えるときにしておけば良かったこと
今回の社内ツール開発で、ヒアリング後～リリースの間に、聞いた内容とは違うよ?思っていたのと違うよ?という点が複数あり、ヒアリングや仕様書を作る段階で情報を上手く拾えていなかったと反省しました。
ヒアリングだけでなくデータ入力に使っていたExcelシートなどにも基づいて設計をしたのですが、「そのデータをいつ誰が何のためにどんな場面で使うのか」といった現場の状況を把握できていなかったのが良くない点でした。
結果的に後から機能詳細やDB設計を何度も変更することになり、今も運用については不安がいささか残ります。
そもそもヒアリングですべての情報を拾うのは無理
今回私がヒアリングも設計も初めてだったので、ヒアリングで本来拾えたはずの情報を取りこぼしていた箇所もありました。しかしそもそも、ヒアリングで欲しい情報を100%拾うのは不可能だと思います。
例えば今回のヒアリングでは「どんな情報を記録しているか知りたいので、普段データ入力をしてるスプレッドシートのコピーを下さい」と依頼したのですが、設計や実装をした後に「このスプレッドシートの情報は他チームも使うけど、スプレッドシートの使用を止めたらその人達はどうするの?」「他チームと共有したい情報はスプレッドシート以外にこちらにも記録してます」などと予想外の情報がどんどん出てきてかなり焦りました。
しかし決して「後出ししないでよ〜」とは責められません。向こうも私達がどんな情報を必要としているのか分からないので、とりあえずヒアリングで聞かれた内容に答えるのは当然です。ただ一方で、私も知らない内容はヒアリングしようがありません。
そんな事もあり、今後仕様を決める際には
- ヒアリング
- 実際に使っている書類やスプレッドシートを見せてもらう
- 隣の席で仕事をする
- 可能なら自分が同じ動作をやってみる
これらのアクション(特に上の3つ)は必要だと感じました。これで拾える情報量がかなり変わると思います。
例えば、今回起きた「情報共有のために実は別の箇所にもデータ入力をしていた」などは隣の席で1日仕事をすれば気づけた可能性が高いです。
また、最後の「同じ作業をやってみる」は実際に私がやってみて大切だと感じたことです。
リリース後、担当者の代わりに何度かデータ入力をしたのですが、そうすると「フォームはあるけど入力したデータを表示する箇所が抜けてる」のような見落としが見つかりました。
その他にも、フォームAとフォームBがもう少し近いと入力しやすい、とか、自動でスクロールする部分は無いほうが入力しやすいかもしれない、など仕様を決めるときに考慮したかった点が見つかり、ユーザーと同じ動作をしてみることで言語化しにくい情報(使い心地など)を得られることも分かりました。
これはまさにヒアリングでは分からないポイントだと思います。
仕様決定は難しいですが、ヒアリングを元に仕様書を書いたり、ユーザーの動作を図で表すのは楽しかったので上手く出来るようになりたいな〜。
まとめ
1、2ヶ月目は仕事に慣れることに精一杯で、3ヶ月~4ヶ月目の前半は目前で起きる事に慌てて対処しているうちに過ぎました。
4ヶ月目後半(1月後半)くらいから、自分が出来るようになってきた部分と、まだ全然出来てない部分が見えてきたように感じます。
そしてこれを書いている5ヶ月目現在、やっと少し落ち着いて「自分が出来ないことをできるようにはどうしたら良いかな?」「自分がこれから会社や一緒に働く人のために何をしたいかな?」と考えられるようになってきました。
相変わらずハードなんですが、考えることが増えてきて楽しい!
そういえば、2019年の目標の一つに「酔って突然人の家に泊まらない」という目標があったのですが既に達成失敗しました。
社内の開発チーム女子会で日本酒の美味しいお店に行ったのが原因です。
あまり反省してません...。
この記事が気に入ったらサポートをしてみませんか？