cover image
🎐

サーバーサイドKotlinはじめました!

tag
技術
プロダクト
エンジニア
writer
LennonLennon

はじめに

はじめまして!シェルフィーでテックリードをしているレノンと申します。
これまでGreenfile.workはPythonでプロダクトを作ってきたのですが、今回段階的にKotlinに置き換え始めました。
✌️
使用技術についてはこちら!
この記事ではこのプロジェクトの始まりや言語選定のときに意識したことについて書こうと思います!

なぜKotlinを選んだのか?

Python時代の課題

弊社はGreenfile.workというサービスを作っていますが、構想段階だった2018年末からバックエンド開発の言語としてPythonを選んで開発を始めました。
当時は立ち上げということもあって、 お客様にヒアリングをさせていただきながらアノ機能も足りない、コレも足りないといった感じだったので、コードの品質は二の次にして、とにかく機能を足していたと聞いています。
2020年に私が入社したときは、さらなるニーズが見つかったこともあり、 後にリリースする入退場機能やその他検証のためにいくつかほぼプロダクトに近いような大きな機能を新たにつくっていました。
その頃くらいから 「簡単な変更をしたくても密結合でやりたいことがすぐできない」 「dictionaryに何が入っているかprint()しないとわからない」 など、サーバーサイドのコードは保守性が低い状態になっていました。
また、チーム全体で質とスピードについてもうまく捉えられておらず、 「ユニットテストを書く時間がない」という声が上がっており、テストコードがない状態で開発が進んでいた状態でした。
とはいえ、どの機能が本当に価値を提供できるかわからないようなプロダクトのフェーズで、 目の前のお客様の要望に応え続けて検証する必要があった状況もあり、この問題は一旦横に置いておいていました。 (ちなみに、これは今の自分が当時に戻ったとしても横に置いておくと思います。危機感や提案くらいはするかもしれませんが。)
そのフェーズを超えてからはいよいよエンジニアの負担が大きくなっていきました。 そうして2021年の9月頃にこのままではプロダクトを育て続けていくのは難しいと判断し、エンジニアマネージャーの鈴木やテックリードの柳に相談して別の方向性を模索しはじめました。
当時プロジェクトが発足したときのNotion。
当時プロジェクトが発足したときのNotion。

言語選びのときに大切にした軸

1つ目の軸は「静的型付け」であることです。
私達が対象にしている建設業界は業界そのものが複雑なので、 いかにドメインの知識をコードに落とし込むかがより大切になってきます。 その場合、クラス設計がしやすい静的型付けの方が相性がいいと思っています。
また、今後チームやサービスがスケールしていく上で、 静的型付けであれば各エンジニアのレベルに左右される度合いを小さくでき、複雑度の上昇はある程度抑えられると考えています。
2つ目の軸は「チーム開発に向いている」ことです。
チームの拡大に伴って、他人が書いたコードの割合も多くなっていきます。 簡潔に書けることやいわゆる黒魔術みたいなことが起こりにくいことが大事だと考えました。
3つ目の軸は「ライブラリが充実している」ことです。
私たちのプロダクトではPDFやExcelといった帳票の出力も行っているため、 そういった処理がしやすいライブラリが提供されているかどうかも大事なポイントでした。 また、例えばコレクションを操作するためのfilterやmapなどのメソッドが標準で提供されていると前述の読みやすさにも繋がると思いました。
4つ目の軸は「採用で不利にならない」ことです。
私たちは言語はあくまでもサービスを実現するための手段だと思っています。
とはいえ、スタートアップの転職市場において敬遠されやすい言語であったり母数が少ない言語だと、採用上で不利に働く可能性があると考えこの軸を4つ目としました。
 
最終的に上記の軸をもとに検討した結果、今回私たちはKotlinを選択しました。 Javaのエコシステムを使えるというのも大きいですね。 Spring Bootなどは経験者も多いので、学習コストが相対的に低いと思っています。
Kotlinに決まった瞬間のエンジニアマネージャー鈴木。喜んでいます。
Kotlinに決まった瞬間のエンジニアマネージャー鈴木。喜んでいます。

やってみて今のところどう?

3月末にKotlinの1つめのAPIをリリースしましたが、安定して稼働しています。 1APIずつ置き換えていくので全体でいうとまだまだ先は長いですが、やっと1歩目という感じです。
はじめてのKotlinリリース時のSlack。みんなたくさん盛り上がってくれました!
はじめてのKotlinリリース時のSlack。みんなたくさん盛り上がってくれました!
今は施工体系図という書類の機能をKotlinで開発しています!
サーバーサイドKotlinも最近は他社さんでも導入事例をよく目にするようになっているので、一緒に盛り上げていけたら嬉しいですね!

おわりに

まだまだ始まったばかりですが、より良いサービスへと進化させるべく引き続きKotlinと共に頑張っていきたいと思います!
よかったらKotlinについて情報交換できたら嬉しいです!気になる方はご連絡ください!
 
採用もめちゃくちゃ頑張っているので、Kotlinに興味がある方やプロダクトに向き合うことがお好きな方はぜひ一度お話しましょう〜!
エンジニア アプリケーション - シェルフィー株式会社
■ 募集背景 SHELFYでは「建設現場での事務仕事をゼロに近づけ、工事に集中できるようにする」ため、工事「外」を業務効率化する「Greenfile.work」シリーズを提供しています。 建設現場のコア情報である「施工体制」を軸に機能展開しており、 現在は2サービスを提供しています。 ・書類業務(作成, 提出, 承認管理, 保管) ・入退場管理 ゼネコン50,000社以上に活用され、対象領域の業務時間を70%以上削減するなど、 建設産業最大のペインである「人手不足」の解消を担うサービスです。 「建設現場の時間とストレス」を指標とし、コア提供価値だけでも大きな価値を生み出していますが、これから先さらに便利にし、さらに現場の方々を楽にするには、 スケーラビリティを確保しつつ、プロダクト利用体験をもっともっと可能な限り磨きあげる必要があります。 お客様に価値あるプロダクトを届け、本来やりたいことに集中していただくべく、プロダクト開発をするエンジニアを募集しています!       ■ 業務内容 ・Greenfile.workを新しい顧客に届けるための新機能開発 ・プロダクト利用体験の向上 ・新規プロダクトの開発 ・顧客業務の本質を深く理解したうえでの情報整理、要件定義、開発 ・迅速でホスピタリティのある顧客対応。カスタマーサクセスや営業との連携 ・採用やチームビルディングなど、プログラム外でのスケーラビリティへの主体的な行動 ※まだまだ変化の多いフェーズです! 業務内容が変わること(自分から変えに行くこと)も多いので、 会社のビジョン・ミッション・一緒に働くメンバーなど、変わりづらいものにモチベーションを抱くことを推奨しています!       ■ エンジニアチームについて シェルフィーのエンジニアチームは、3〜6人程度のスモールチームを組み、 3属性で「力の化身・愛の化身・知恵の化身」としてのmissionを元に動いています。 ・指示ではなく示唆で、自律的に動く(そのため3属性と、枠組みを大きくしています。) ・事業やサービス全体像を考え行動する ・基本的に全員がフルサイクルエンジニアとして、要求分析~実装~テスト/リリースまで一連を担う などが特徴的なチームです。 👹 力の化身 事業機会拡大のための「売りやすくする」機能開発チーム。 開発例) ・お客様側での現場運用の進捗確認機能 ・CCUS(建設業界版マイナンバー)との連携 ・社内運用支援用の管理画面構築 👰‍♀️ 愛の化身 導入してくれたお客様の使い心地を向上させる機能開発チーム。 開発例) ・お客様の利用コストを下げるUX改善(動作速度、検索性能、導線改善など) ・複雑なドメインをわかりやすく反映したUI、権限等の設計開発 ・CSチームとお客様のコミュニケーションを円滑にするための開発 🦧 知恵の化身 ビジネスサイド、プロダクトサイド含んだSaaSチーム全体の効率と持続性を向上させるチーム。 技術の力で全体を加速・安定させる役割を担っています。また会社として初めて挑戦する難しい技術課題にも取り組むチームです。 開発例) ・CI/CDパイプラインの最適化 ・データ分析/活用基盤の整備 ・セキュリティの強化 ・サービスの監視システム構築 etc...