今年作ったもの
カンムの中嶋と申します。2024年も終わりですが、今年作ったものを思い出しつつ、工夫したところなどを残しておきたいと思いこれを書いています。
この記事はカンム Advent Calendar 2024の記事です。
12/20の担当でしたが遅れての投稿です。
前日19日の記事はGODmoguさんの「ポチるか」擬人化でした。
私は絵を描きませんが、自分の納得と折り合いをつけていくところや自己満の世界というところで、ものづくり全般におけるほんとそれ感を感じてました。
竹垣
何を作ったか
御簾垣という種類の竹垣を作りました。
これは支柱(杭)に横向きの長い竹をビスで取り付け、最後にビスを隠すように縦の竹を取り付けた簡易な構成です。
使ったもの
資材
防腐杭
竹
シュロ縄
ビス
工具
ノコギリ
電動ドリル
穴掘りドリル、スコップ、ゴムバンド
工夫したところ
穴掘り機で岩を砕く
支柱となる杭は竹垣の高さの1/4程度の深さで埋める必要があり、今回は2mとしたため50cmの穴を掘りました。
尚、この工程が最難関と言っても過言ではありません。
このような穴ほり機を使うことで基本的には簡単に穴を掘れますが、時折大きい岩にぶつかります。
この場合
諦めて少しずらして再度掘る
岩を取り出す
岩を砕く
が選択肢になりますが、岩が脆ければ3が楽です。
上記の穴ほり機の取っ手をゴムハンマーで叩くと脆い岩は破壊でき良かったです（当然、穴ほり機は破損します）
釘ではなくビスを使う & ゴムバンドで仮止め
支柱への竹の取り付けは一般には「トンカチ + 釘」を使いますが、支柱の先端を叩くと支柱が揺れるため非常に難しいです。
そこで「電ドリ + ビス」としたところとても簡単でした。
雪吊
何を作ったか
主に北陸地方で行われる雪に対する樹木の保護の施工です。
これをしないと特に樹形を整えた松などの細い枝は折れます。庭に背の低い松を植えたので自分で施工してみることにした。
使ったもの
竹（竹垣のあまり）
縄
杭
工夫したところ
もやい結び
枝と縄の接続は、もやい結びで枝から離れたところに結び目を作りました。
小さく結んだほうが見栄えは良いですが、素人では枝を傷つけそうと考えこの実装としました。
なお、もやい結びはこの歌で覚えました: https://x.com/AboyYasunaga/status/1865542860910768419
なお、私は松の葉が爪の間に刺さって終わってしまったので、薄くて硬い手袋を使うべきです。
サクっと資金調達
何を作ったか
次のサービスの設計・開発に取り組みました。
ここでは簡単にプレスリリースからの引用でサービスを紹介させていただきます。
【「サクっと資金調達」とは】
将来の売上を買い取ることで、すぐに使える資金を提供する中小企業向けの資金調達サービスです。申し込みから資金提供までオンラインで完結し、AI審査とオンライン面談を経て、最短7営業日で資金調達が完了します。そのため、一般的な銀行で融資を受けるよりも短い時間で簡単に資金を調達できるのが特長です。決算書・担保・保証人など全て不要なため、スピード面・心理面共に“サクっと”お手軽にご利用いただけます。
なお、この「将来の売上を買い取ることで資金を提供する仕組み」は一般にRBF(Revenue Based Financing)と呼ばれています。
使ったもの
BE(API/ Batch)
Go
PostgreSQL
AWS
Firebase
FE
TypeScript
React
工夫したところ
はじめに本サービスの開発では以下の点を重視しています。
リリーススコープを柔軟にし、迅速かつ品質の高いリリースを目指す
仕様変更・拡張に対する柔軟性をもたせる
その上での実装上の些細な工夫を一つ記します。
できるだけロジックを持たない
まず前提となる仕様を共有します。
RBFでは資金提供後、実際に発生した売上から資金を回収します。
サクっと資金調達では決済代行業者との連携により、次の図のようにカンムが売上の流れの間に入る形で回収する仕組みを取っています。
この決済代行業者からの売上の入金は決まったスケジュール(毎月n日など)で実施されます。
またサービス仕様として、回収すべき合計金額と回収期間は資金提供時に定まり、期間内の売上入金の各機会ごとに均等額を回収していくものとします（回収不足があった場合は次回に繰り越します）。
※この仕様は簡易化したものです。正式な仕様はサービス紹介・利用規約をご参照ください。
ここで本題ですが、図の「回収」にあたるカンムが入金を受けた際に控除すべき金額を取得する実装を考えます。
金額算出のロジックとしては、入金スケジュールを実装に落とし込み期間内の入金回数を求め各回の控除額を求めるものになり、これをアプリケーション上に実装するという方針が思いつくかと思います。
金額算出の例
- 買取額: 600万円
- 回収期間: 6ヶ月
- 入金頻度: 月1回
- => 回収期間中の入金回数: 6/1 = 6回
- => 入金毎の回収金額: 600万円 / 6 = 100万円ただし、これを実装してしまうと、入金スケジュール・回収などの仕様に変更があると実装の回収が必要になってしまいます。初期の段階においてこの様な変更も予期されるので、これは実装しない方針としました。
この方針は次のように実現します。
事前に回収スケジュールを計算し、日ごとの回収予定金額を1レコードとしてDBに保持しておく
入金の発生時にはそのスケジュールを参照するのみ
この事前計算を初期は手動で行い、入稿する
1のデータのイメージ
入金予定日, 回収予定金額
2024-12-25, 1000000
2025-01-25, 1000000
2025-01-26, 1000000
...2の処理のイメージ
入金発生時の控除額の計算(d: 入金日, x: 入金額) =
p <- 入金予定日がd以前の回収予定金額合計を取得
a <- 回収済み金額を取得
return min(p - a, x)このようにデータを挟むことでロジックを分離する選択は次のような利点があり、これは初めに書いた「重視する点」から望ましいです。
初期のロジック実装が不要。回収ルール変更時などにシステム改修が不要
初期は手動とした事前計算を追って実装すれば、自動化も地続きに可能
この例は単純で当たり前の範囲かもしれませんが、よく意識すべき視点だと思いました。実際に開発中にも仕様の変更はあり、最初からロジックを実装しなかった恩恵を受ける機会もありました。
終わりに
来年はもっと色々作りたいと思いました。
プライベートではウッドデッキを作りたい。仕事ではみんなでお金の新しい選択肢をつくっていくぞ！
この記事でカンムに興味を持ってもらえた人がいたら、ぜひ以下の採用ページを覗いてみてください。