TSRでとある会社(IT受託メイン)の会社情報を引っ張ってきたら、セクシーな動きをしていた。
ある年の売上が4億ちょい、当期純利益が▲7000万で、自己資本比率が10%ぐらい。翌年もほぼ同額の売上なのに、損失が拡大して自己資本比率▲140%になっていた。
請負大型案件を焦げ付かせた香りが強烈にするけど、こんだけ一気に純資産(資産ー負債)が悪くなるのは、でかい売掛の損失と炎上案件での採算悪化、それに伴う借入金の拡大などしか、思いつかない。IT受託系なら。請負なら検収不可→契約不履行で一発アウトというパターンかなー。
現預金が1億あって借入が3億あるとかそういう感じにも見えない。4億の売上だと、引っ張れるとしても5000万じゃないかな。
受託はそうそう跳ねるビジネスじゃないので、こんだけ派手にやらかしたら、まともな財務状況になるのに10年かかりそうだけど。行くも地獄引くも地獄なら、行くしかないけど。リビングデッドな気がするなー。
財務諸表も引っ張れるけど、色々仮説を立てて来月になったら、諸々買ってみようと思います。
言いたいこと、これだけだよね。人類はコードを書いたら負けだよって。デバッグ？ もはやデバッグという概念すら存在しなくなるかもしれない。
ただ、飛行機に乗ると同じなので、離陸・航路監理・着陸の設計をどうするのか、自分たちのコードは何か、どこからがノウハウで、どこからがボイラーテンプレートなのか、議論する必要がある。それがContextと言ってる部分でしょ。
残るのはContextとMonitoringの2つだけ。仰るとおりです。
こんな時代になると、知を組み立てる引き出しの多さが問われる気がしてならない。大学入りたいわｗ
仕事の話のみです。
当たり前のことすぎるのですが、企業が生きていくには顧客の数を増やすしかありませんので、自社をPRするためのコストを「多く」割かないとダメということに気づく。
今までリファラルでやってきて、今後もリファラルでやっていくのですけれど（SESはリファラルが最強なので)、リファラルの範囲をもっと広げる必要があります。まずは、Yentaのような ビジネスマッチングアプリを本腰入れて運用することにしました。仲間を増やさないとね。やっていく。
自分をPRし、売り込んで、こういう使い方出来ますよメリットあるよが「滲み出る」レベルになりたい。
3ヶ月に1回ぐらいは、定期的に何かあったら（仕事の）相談してねpingを打つようにしたほうが良いなと思ったので、これもやっていく。タイミングで決まるから、案件の9割が。
まずは年間売上、1億。倍近い成長が必要なのですけど、そういう目線から逆算して考えないと、成長なんかできない。要員をただブクブク増やすのではなく、プロダクトとSESの両輪を追いかけて、2:8にしたい。SESが悪いというわけじゃなく、下請だけで生き延びていくのは限界があるので。
プロダクトについては、やっと、今年の2月にリリースできる見込みが立ちました。自分が最も知見のある販売管理の分野で、勝負できる良いものが出来ました。Claude Codeがなければ、とてもじゃないと作れなかった。
今年で会社を起こして10年目になるので、向こう3年を生き延びていけるよう、2026年を飛躍の年にします！
考えてみたら当たり前のことなんだが・・・
これまでのデフレーション時代において、企業が最も警戒していたのは、需要の縮小だった。産業の担い手となる生産者が減少する一方で、需要や供給も縮小し、例えば花屋やスーパーの売り場も少なくなると予想されていた。しかし実際は、むしろ医療や介護だけでなく、電気や水道、ガス、道路等のインフラ、そして生鮮食料品花き卸売市場のエッセンシャルワーカーのサービス需要が旺盛でありながら、それを支える人手が足りなくなるという供給面での制約だった。 地域の要となる市場の生産性向上 - 株式会社大田花き
需要が無いのではなく、供給が追いつかないから需要が消えて生産が進まない、それが今。需要が消えることはない、供給が追いつかないから需要の花が開かず根から朽ちてしまう。
供給が追いつかないから、数少ない生産・資本を奪い合う状態になるので、価格が上がるわけか・・・
供給の受け皿が小さすぎてもだめなんよね、ある程度のキャパを抱えられる会社が増えないといけないけど、資本効率の観点からSaaSやクラウドのようなサービス開発に走ってしまう。ウチのように数名しかいない会社ばかりが増えてもしょうがない（自分で言ってて虚しくもなるが、事実だからしょうがないｗ)
生成AIである業界向けのシステムのカスタマイズなどが可能になる枠組みを技術的に作れる気がするが、DB設計から始めないといけないので、これはこれでハードルが高い。今のiPhoneにあるように、チップやカメラのマイナーチェンジに近しいことを今後繰り広げて行くような気がする、生成AI。革新性は今の延長線上に存在しないから。
生成AIのイノベーションのジレンマは、来年辺りから始まる気がするな。
ま、それは、おいといても、こちらの記事には色々考えさせられることがあった。でも、業界の構造変えるなら、業界の外からズラしていかないと、変わらないよね。僕は園芸・花卉業界でIT目線で禄を食んでいるので、引き続き、いろんなことを考えていきたい。
バックエンドでGo Langを使う案件や会社のお付き合いが最近ぐっと増えたため、Go Langの基礎文法を学びます。A Tour of Goをざっと回したので、メモ。
:=を使うことで、変数の型推論と代入が可能。
「短変数宣言（short variable declaration）」と言うらしい。また、この宣言はグローバルにはできず、関数内部が最大のスコープとなる。
a,b,c := 10, "10", false;
deferが使えるTypeScriptでは、async/awaitが必須のdeferがこれだけで実現できるのは驚き。意味合い的には、try-catchのfinallyに近いなぁ。
deferは後入れ先出しで、最後にdeferしたものから順番に実行される。
package main import "fmt" func main() { fmt.Println("start") defer fmt.Println("end") // ← 最後に実行される fmt.Println("middle") }
a := [3]int{1, 2, 3} s := make([]int, 3)
// for..in的なループ // 自動的に第1引数にindexが入る for index, value := range items { fmt.Println(index, value) } // index使わない場合はこ for _ , v := range nums { fmt.Println(i, v) } m = make(map[string]int) // mapはこうなる for key, value := range m { fmt.Println(key, value) } // Pythonと同じでStringも回せる for i, r := range "GoLang" { fmt.Println(i, string(r)) }
func counter() func() int { x := 0 return func() int { x++ return x } } func main() { c := counter() fmt.Println(c()) // 1 fmt.Println(c()) // 2 fmt.Println(c()) // 3 }
cはxの内容を常に記憶してるわけですな。
type User struct { Name string } func (u User) ChangeByValue() { u.Name = "Value" } func (u *User) ChangeByPointer() { u.Name = "Pointer" } func main() { user := User{Name: "Init"} user.ChangeByValue() fmt.Println(user.Name) // Init （変更されない） user.ChangeByPointer() fmt.Println(user.Name) // Pointer（変更される） }
implementsがない。シグネチャが同じなら同じTypeだとみなされるようだ。へー。type Greeter interface { Greet() string } type User struct { Name string } // Structに紐づいた関数Greetが、interfaceのGreetと同じシグネチャ // UseはGreeter interfaceを実装したものとみなされる func (u User) Greet() string { return "Hello, " + u.Name } func PrintGreeting(g Greeter) { fmt.Println(g.Greet()) } func main() { u := User{Name: "Taro"} PrintGreeting(u) // User は勝手に Greeter とみなされる }
var x any = "hello" // okで型がマッチしたかどうかが代入される // 例外が存在しないGoらしい考え方だ。 s, ok := x.(string) fmt.Println(s, ok) // "hello" true
// x が取りうる型の「Union」を型制約として定義 type Printable interface { ~int | ~string | ~[]int } // x は Printable だけに限定 func printType[T Printable](x T) { switch v := any(x).(type) { case int: fmt.Println("int:", v) case string: fmt.Println("string:", v) case []int: fmt.Println("slice:", v) default: fmt.Println("impossible (for now)") } }
Pub/Subする。ch := make(chan int) // {}()で無名関数を作成し、funcに渡している // goroutine を作るには「関数を渡す必要」がある go func() { ch <- 10 // 10 を送信 }() v := <-ch // 10 を受信 fmt.Println(v)
func fetch(ctx context.Context, ch chan string) { select { case ch <- "done": case <-ctx.Done(): fmt.Println("canceled:", ctx.Err()) } }
Error()をメソッドで実装して任意の型を表現するのが良さそう。type error interface { Error() string } type ValidationError struct { Field string Message string } func (e *ValidationError) Error() string { return fmt.Sprintf("validation failed: %s - %s", e.Field, e.Message) }
このエントリのお陰で更に解像度あがった。
ReactRouterを敬愛する私ですが、案件の都合上Next.jsに手を染めることに。。。案件の数は全然違いますしね、こんなVercel専用フレームワークの何が！とか思いつつも、ちゃんとプロダクションでリリースしてからだな！
盲点だったな。。。固定費は少ないほうがいいと思ってたが、業務委託ビジネスだと、ひとがいないと新しい大手の付き合いができない。 年間3千万 x 3社(エンプラ) を6〜7名、受託を年間1千万叩けば、1億が見える。それを叩いたほうが絶対に良いわ。そのコネもあるし。というわけで、リファラル前提で採用を加速する！！
