教育体験記
当時書いていた日報を参考にしながら、もう少し具体的な内容についてお伝えしていきます。
全体構成の調査
まずは、Slack botの構成の調査から入りました。部署管理のさまざまなアカウントがありましたが、どのアカウントが必要で、誰に聞けば情報をとれるのかを考える必要があります。
部署管理のアカウントにGoogle Apps Scriptのコードがあるのを知り、そのコードの中身を読み込んでどんなサービスが必要になるのかを1から調べました。当時の私は「APIって何？」「Webhookって何？」といったレベルだったので、この調査ではかなりの時間を割きました。
検証環境の構築
全体の構成が分かったら、検証環境を構築します。今後自分でいろいろと実験することも見据えて、Slackで実験用ワークスペースを作ったり、実験用Google Cloud Platformアカウントを作ったりと、環境構築だけでも大変時間がかかりました。
コード修正
次に、コードの修正を行います。Javascript自体も初めてだったので文法の調べ方やドキュメントの読み方などを勉強しました。修正しつつ実行し、エラーログを見ながら修正する、といった一連のフローについても慣れていきました。
また、もともと手元にあったコードを読んで「アクセストークンがなぜ必要なのか？」「正規表現の一つひとつの意味は？」「各変数名の意味は？」などを理解していきました。特に、最初はアクセストークンの役割がピンと来ず、この理解までにかなり時間がかかりました。
現状報告
進捗は逐一、上司に報告します。実装進捗・理解度・不明点を整理して報告する練習になりました。日報にも記録しておき、後々見返せるような形で保存しておきます。特に自分が壁にぶつかった箇所については、今後別の案件でもぶつかる可能性があるのできちんと記録に残しました。
本番環境移行
本番環境に反映させるため、「〇〇から〇〇の時間は使用しないでください」といった連絡を部内に流します。どれぐらいの時間がかかりそうかを見積もり、本番環境に移行しましたが、最初の見積もりが甘かったため、予想の3倍近くの時間がかかってしまいました。
ドキュメント作成
実装内容についてドキュメントにまとめます。フォーマットの指定は無く、「他の人が見てトレースできるように」という要件だったので構成も1から考える必要があります。この辺りでは、第三者が読んでも分かるようなドキュメントを書く練習になりました。
社内の反響
その後の反響として、「今まで1日ずつ予定を入れる必要があったのでかなり楽になった！」というありがたい声や、「投稿した予定一覧機能も欲しい」といった追加の要望もいただきました。また、ここで作成したドキュメントは後に他の部署へと渡り、他部署でもこの出社予定プログラムが採用されました。記録に残すことの大切性を改めて実感しました。
学んだこと
今回の「勤怠管理botの機能強化」を通して、APIやGoogle Apps Script、Webhookといった技術的な知識だけでなく、部内での振る舞いなど社会人としてのビジネススキルも学ぶことができました。開発中は他業務と合わせて計画を立てる必要があったので、スケジュール管理についても経験を積むことができ、新人教育として非常に良い題材でした。私が実施したプロトタイピング案件は他にもいくつかありますが、そちらはまた別の機会に改めて記したいと思います。
最後に伝えたいこと
- 新人の技術力・ビジネス力を磨く目的で、「プロトタイピング」はおすすめです。
- もしテーマが無ければ「部署にとっての『便利グッズ』を作る」と良さそうです。
- 業務以外の自己研鑽をしたい方は、何かしらの「便利グッズ」を作ってみるのもおすすめです。
