はじめに

この記事は2019年11月に実施されたレガシー感謝の日での登壇内容をベースに記事化したものになります。

初めまして。さわやかのハンバーグから生まれました、
ハンズラボのあさひなです。

突然ですが、ユニケージ開発手法というのものをご存知でしょうか？

ご存じの方
→ 握手しましょう
ご存じない方
→ 詳しくは弊社の以下記事にて説明しております。
ハンズラボが採用しているユニケージという謎テクノロジーについて 第1回

ユニケージとは？
一言でいうならば、Bashのフレームワークです。

もう少しだけ細かく特徴を挙げると
・小売などで必要な帳票作成用の独自コマンド
・オリジナルのモデル設計を踏まえた開発手法
・DBを利用せず、テキストファイルでのデータ保持

などがあります。

あまり馴染みのある技術ではないのですが、
弊社では一番歴史が古く、かつ現在一番利用されている技術になります。

今回はそんなユニケージと弊社のあゆみについて書こうと思います。

弊社でのユニケージの現在

そんなユニケージですが現在のハンズラボでは技術的負債としての認識が強いです。

上記の説明や弊社の記事でドン引きされた方も少なからずいるのではないでしょうか？

弊社では全環境AWSに移行しているのですが、クラウドとの食い合わせの悪さや、長期的な保守システム的な限界を

また、いわゆる属人化→担当者の退職を繰り返し遺跡と化してしまったことも多くあります。

これ自体は言語に問わず起こり得ることかと思います。
が、読み解くべきコードは独特の記法で書かれたシェルです。

ちなみにフロントもシェルです。
BashでHTMLを組み立てます。

AJAXもシェルです。

シェルを叩くとjsonで返ってきます。



なんとなく、辛さがわかっていただけたでしょうか？


まだ受けたダメージが少なそうな方は先まで読み進めてください

重症の方は無理せず一旦休んでください、この記事はいつでも読めますから。

ユニケージ採用の背景

さて、そんなユニケージですが当然採用理由があります。

元をたどると弊社ハンズラボという会社がどうしてできたのか？
というところに帰結するのですが

もともとハンズラボという会社は東急ハンズの情シス部が前身となっています。

そんな中、東急ハンズ側のシステム内製化の指令が降りてきました。

つまり、「東急ハンズの販売員だけで、システムを全部内製化する」
・・・という限りなく無茶なミッションが降りてきていたのです。



その無理難題をクリアするために当時の社長より採用されたのがユニケージです。小売の同業他社での実績もあったというのもあります。

なにより学習コストの安さが最大の利点でした。

画面含めたほぼ全てをBash+テキストデータで管理するため、DBやFWなど0からの学習コストが圧倒的に安くすみます。

さらには
・小売には便利なコマンドが複数ある。
・設計思想や開発組織にまで細かく固まっているため迷いにくい
(規約によって開発速度を上げる、と書くとRailsっぽいですよね。ぽいだけですが。)

など、当時の担当者から見るとユニケージこそが最適解だったのです。

そして、実際そのユニケージでシステム内製化に成功し、今日までハンズラボは続いております。

紛れもない事実です。

そう・・・・ユニケージがあったからこそ今のハンズラボがあったのです。

つまりユニケージとは、母なのです。

巣立ちが近づいている。

負債だ、レガシーだなんだというのはあくまで結果論です。
当時いなかった人間がどうこういうべきではありません。

一方で、現在は状況も変わってきています。

弊社ハンズラボにも中途採用でのエンジニアも増えてきました。
そして当時は販売員だった方々も今は立派なエンジニアになってきています。
(とても東急ハンズで鞄売っていたとは思えないくらいゴリゴリPython書ける方もいます。)

クラウドへの移行も完了し、新規案件などユニケージを用いずに作成することができています。

いうならば、親離れの時期なのです。

感謝を胸に次のステージへ

ユニケージからの脱却、通称脱ケージ活動は現在社を上げた取り組みの一つです。
負債の解消に向けて、様々な取り組みを実施しています。

弊社CRMチームを例にあげます。

ハンズネットなどのECサイトやハンズクラブポイントのシステムはもともとユニケージメインで書かれていたのですが、
メンバーの尽力の甲斐あってかなりの部分のシステムがユニケージから置き代えられています。
CRMチームの技術展望

以下はGitHub ActionsでCI/CDを自動化した例です
GitHub ActionsでServerless FrameworkのCI/CDパイプラインを構築する

また、弊社の自社サービスであるPostfor
こちらはサーバーレスでの実装です
詳しくはコチラ

さらに受託の方でも新規案件や既存の改修の際に
ユニケージ以外の実装を行うことが徐々に増えて来ました。


既存の負債を解消する、という活動だけでなく負債を産まない体制作りのために
モデリング勉強会やリファクタ活動も積極的に行われています。

ドメイン駆動設計のモデリングハンズオンを開催して頂きました！
ハンズラボでもリファクタ部(整地部)やってみたってばよ

最後に

ユニケージのデメリットは確かにありますが、
今日まで弊社を支えているすごい技術でもあります。

今日まで得られた知見は必ず明るい未来に投資できるはずです。
今後も弊社のそんな活動模様は定期的にブログに公開されてゆきますので、いずれ乗り越えた報告ができると・・・・いいなあ。（がんばります。）


以上、あさひなでした。