今回は、前回の記事に引き続き、社内ハッカソンについての記事を書いていきます。
社内ハッカソンがどんな風に行われたかについての詳細は、前回の記事をご参照ください。
ハッカソンの内容をざっくり説明すると以下のような内容です。
- 目的は、「エンジニアが他のチームの業務を理解すること & 他のチームがエンジニアの仕事を理解すること」
- テーマは「チームの業務効率化」
- 10:00~17:00でヒアリングと実装を行う
- 各チーム5分で発表
私は、コーポレートチームにエンジニアとして参加しました。 今回はコーポレートチームがどのような活動をしたのかについて書いていきます。
チーム概要
コーポレートチームは、コーポレート部2名 + 社外取締役1名 + エンジニア(私)の4名です。 コーポレート部は、経理・労務・総務などの業務を行う部門です。 コーポレート部2名のうち1名はM&Aのアドバイザーや上場準備などとの兼務のため、コーポレート部は実質1人で成り立っています。
ヒヤリング
コーポレート部の状況
最近は社員数が一年で倍以上になっており、入社手続きや給与の処理など業務は増えていく一方で、コーポレート部の負担が増加していました。 これからも社員数が増加することを考えると、コーポレート部の業務効率化は重要なミッションです。 ヒヤリングをしたところ、真っ先に出てきたのが、契約書の管理 についてでした。
これまでの契約書の管理
コーポレート部で日常的に取扱う契約書は、プラットフォームへの掲載をする企業様と弊社との契約書です。 以下のような問題がありました。
- SalesforceとSpreadSheetの2重管理
- 契約締結からファイリング・保管までの細かな作業が多い
- 多部署から口頭で契約状態や契約の内容の問い合わせを受ける
- SalesforceもSpreadSheetも必要な人が必要な情報を気軽に見られるように整備されていなかった
効率化の試み
話し合いの結果、以下のような仕組みの開発を行えばかなりの効率化が計れることがわかりました。
コーポレート部が契約書PDFをSalesforceにアップロード ⬇️ 文章中の重要事項(契約の種類や締結日、金額など)を自動で抽出 ⬇️ Salesforce上に自動入力
この仕組みができれば、
- 契約書ファイルを開いてて入力する時間の削減
- 多部署のメンバーはSalesforceですぐに契約状態を確認できるため、問い合わせ対応の時間削減
を実現できます。
試算では、年間720分(12時間) の時間を削減できることがわかりました。 これは、現状の契約数をベースに算出したもので、弊社がグロースすれば、その恩恵は積み上がっていきます。 2年後に現在のクロージング数の4倍まで成長すると仮定すると 年272時間 もの時間を削減できる見通しです。
そんな感じで、やることは決まりました。
実装
エンジニアがまず最初にすべきことは、やりたいことが実現可能か判断することです。
- 技術的に実現可能か?
- 与えられた時間・リソースで開発可能か?
- 実現できないリスクはどの程度あるか?
今回はSalesforce上の機能の開発が必要そうですので、おそらくはApexという未知の言語での開発になることは予想していました。
私「ApexはJavaみたいって聞いたことあるしJavaは何となくわかる」 私「Javaならライブラリもいっぱいある」 私「やれるかどうかわからないけど、とりあえずやってみよう」
ということで、「実現可能かをいつまでに判断するか?」「実現できなかったらどうするか?」など考えずにヌルッと技術調査を開始しました。
私「ApexってJavaっぽいけど結構ちがう 全然ワカラナイ」 私「ApexからSalesforceにアップロードしたファイルにアクセスするにはどのAPIを使えばいいの?全然情報が見つからない」 私「ApexってJavaみたいにいろんな便利なライブラリ使えいないの? PDFを文字列に変換するにはバイナリにして自前でガチャガチャしなきゃいけないの? 」
こんな具合で、限られた時間で落とし所を見つけるのすら難しそうなくらい実現が厳しそうだとわかりました。
私「えっもうこんな時間! 今から作る内容変えるの無理だ・・・」
作業にのめり込みすぎて実現不能だと判断するのに時間がかかりすぎたため、作る内容を変える時間は残されていませんでした。 最初から未知の技術を選ぶのがミスってるし、「できないかもしれない」と思った時に、作業に没頭するのではなく手を止めて、「できません」というべきだったなと反省しています。
プレゼン
契約書の管理方法を変えて業務効率化を行うというアイデアと、業務時間が多く削減されるという点から社内からの反応はいい感じでした。 また、実装はうまくいきませんでしたが、なぜうまくいかなかったかを素直に話したら結構盛り上がりました。
まとめ
コーポレートチームの開発はうまく着地できませんでしたし、エンジニアとしてもっとうまくやれた点もあって反省している部分もあります。 ハッカソンは失敗せず限られた時間でいいものを作れるのが理想ですが、失敗しても大丈夫なところに魅力があるなと感じました。
他のチームでのハッカソンの様子については、また次回あたりで紹介されると思いますので、お楽しみに!