ふるさと納税エンジニアな話

この記事は Hamee Advent Calendar 2019 22日目の記事です。

　やぎぬと申します。新卒でHameeに入社して4年目になります。
　5月からふるさと納税関連の新規事業にはじめてのエンジニアとしてジョインしてから7ヶ月が経とうとしています。今回は自分の振り返りも兼ねて、振り返りつつ、開発時に意識していたことや経験談をまとめたいと思います。なにかの参考になれば幸いです。
(技術的に具体的なことは、これからアウトプットしていこうかなと思います。)

ジョインする前

　2年ほど前からはじまった新規事業はふるさと納税関連で自治体が行う必要がある作業を受託し、そこから手数料を頂くというビジネスモデルです。弊社のプロダクトであるネクストエンジンをふるさと納税運用にフィットさせて、作業効率化をしています。ただ、ふるさと納税独特の運用などがあり、それは効率化・自動化できていない状態でした。ネクストエンジンはネクストエンジンアプリを開発し、機能拡張できるのですが、そのアプリ開発(外注)もうまくいっていない状態でした。そのときの事業メンバーは営業のスペシャリスト2名です。

ジョインした後

　社内公募があり、5月からジョインしました。当初は外注先が開発したアプリがまったく使えるものになっていなかったり、事業内容を詳しくわかっておらず、なにから手を付けていいかわからず大変でした(白目)が、現在はスクラッチでネクストエンジンアプリを開発して本番運用しています。ここからは開発時に意識していたことをまとめます。

開発で意識していたこと

　アプリケーションはIF、認証&ネクストエンジンAPI通信、各ドメイン毎の4つのマイクロサービスから成り立っています。ロジックは基本的にジョブ化していて、現状20以上のジョブが動いています。設計時にはTwelve-Factor Appや同僚エンジニアのアドバイスを参考にしました。いくつか紹介します。

・マイクロサービス
　現状、4つのアプリケーションが動いています。1人なので、自分で投げたボールを自分でキャッチしている感覚です。うまくサービスを分けられているかはおいておいて(苦笑)、各アプリの独立性は担保するようにしています。各アプリ毎にデプロイ可能なことや、耐障害性、アプリケーションロジックレベルでも複雑になりにくいなどなどメリットはたくさんあると思います。

・設定情報とコードの分離
　外部リソースの連携に必要な情報などの設定情報はコードと分離し、環境変数に持たせるようにしています。また、productionやstaging毎の各種設定も環境変数指定で注入するようにしています。(環境変数次第で少し仕様が変わるように作っていたりしているところもあります)
　後からコードを変更せずに設定情報を変えるだけで、リソースをスイッチできるかを意識しています。

・処理をジョブでわけること
　すべてジョブ化して、ロジックがシンプルになるようにしています。といってもできてないところありますが...細かくわけることで、後からメンテナンスしやすいようにしています。

・とにかく最小限の単位で、運用をまわしつつ改善すること
　価値が提供できるところまで実装&検証したら、デプロイして運用しつつ改善するようにしています。未来をみつつ、できるだけYAGNIを意識しています。(矛盾していますが、なんとなくそんな意識でやっています)

・とにかくスピード重視
　新規事業で早く事業に貢献しなければならない状況かつ現状のプロダクトは運営側しか利用しないもの(受託している作業の効率化が目的)だったので、細かいIFは後回しでやっていました。

・価値を提供すること
　エンジニアとしては当然だと思いますが、価値を提供できているかを意識して選択や判断をしています。新機能を作りつつ、保守運用をしつつなので大変ですが、マルチタスクをこなしています。また、コーディングだけにとどまらず、運用方法の改善やそもそもの追求をすることで断捨離することも考えています。

経験談

・はやくつくって問題
　ジョインしてすぐに「はやく自動化してほしい。いつできるのか？」と言われました。ただ、すでに存在していたプロダクトは動いていない、コードやアーキテクチャをみても、このまま運用・改修していっても明るい未来は見えなかったので、スクラッチで開発することにしました。スケジューリングを立てて共有したところ、あまりみんなのリアクションは良くなく...それでも判断は間違っていないと奮い立たせながら、開発をしていました。
　しかし、価値を提供できていない自分にも嫌悪感があったので、そこで、アプリケーション開発と同時並行で、サポートツールの作成もすることにしました。弊社はGoogle系のツールを導入しているので、GASやスプレッドシートなどで、できるだけ作業効率化をしました。結果として、少しでも価値を提供できて立場回復になったし、時間稼ぎ(笑)にもなったし、これから作る機能の材料にすることもできたので、やってよかったなと思います。

・現運用から自動化フローに移行するところが大変な問題
　手作業でやっている運用から自動化フローに移行する際に、一筋縄ではいきませんでした。データを整える必要があったり、2つのフローを同時並行で行う必要があったり、それによって運用が複雑化したり、移行しても他のフローに影響がでてデータ加工をする必要があったり...これらも、ツール作成したり、PJ内で認識を頻繁に共有したりするようにしていましたが、あとは辛抱強く作業していくしかありませんでした。今はデータも運用も整いつつありますが、あのときは辛かったなあと思います。

・自治体とお仕事するということ
　初体験でした。対企業とは全く異なるので、難しさも楽しさもあります。エンジニア目線だと、自治体毎にフローや体制や共有ドキュメントが違ったりするので、そのまま作るととても複雑なアプリケーションになってしまいます。依存性が高いところは外部リソースやデータとしてもつなどして、汎用性を担保するようにしています。

おわりに

　今回は時間もなかったので、簡単な振り返りと意識していたことと経験談をまとめてみました。自治体とは受託の関係ではなく、共創の関係を持ちつつ、事業としてスケールしていきたいなと思っています。まだまだこれからな事業なので、引き続き"やっていき"していこうと思います。

エンジニアとしての底力は、「答えの無い実装に取り組んだ回数」に概ね比例すると思う。

ほぼ既存コードのコピペで済む実装だと、スキル/知識は伸びても底力は付かない。
自分なりに設計やアーキテクチャを検討して、（周りの協力を得ながら）実装に落とし込む経験が一番「使える」力になる。

— Tau@駆け出して這い上がるエンジニア (@tau_tau_x) May 29, 2019

底力つけていき。

感謝

　アーキテクチャ等のアドバイスや保守して頂いていたり、実装時のアドバイスをして頂いている弊社エンジニアの方々にはとても感謝しています。いつもありがとうございます。あと、ネクストエンジンにはとても感謝しています。いつもありがとうございます。