Hit me up Inc.

19/01/2026

SIer/コンサルファール/ベンダーなどの発注権限に向けてAPI Keyデリバリーはじまってます。

◾️ご利用申請はコチラから
→https://ses-hub.app/contact
「事業会社・SIer・コンサル会社」よりリクエスト!!

08/01/2026

〜RBACの話を、できるだけ噛み砕いて〜

この図を見たとき、
正直ちょっと 「強そう」「排他的そう」 に感じた人もいるかもしれません。

・AとBにはAPIがあって
・Cには無い
・Key？ 承認？ リクエスト可否？
・UIはなんだか冷たい感じで…

第一印象としては、そんなところでしょう。

でも、これは
なにかを排除するための設計ではありません。

⸻

何をやっているかというと

SES業界を含むITの現場って、
• 情報がバラバラ
• 判断基準が人に依存
• 責任の所在が曖昧
• 「誰がどこまで決めていいのか」が分からない

この状態がずっと放置されてきました。

SES_HUBではまず、
• 情報フォーマットを揃える
• 職種・役割ごとに共通言語を定義する
• 一度フラットに可視化する

ここまでを、4年間で徹底的にやりました。

実はここだけで、
営業や調整の心理的な負荷はかなり下がります。

⸻

属人性と抜け漏れを、構造的に削減する

次にやったのが、
• AIとRPAで
• 営業個人差・行動量の差
• 「忙しくて忘れた」「確認漏れた」
こういう人間由来のブレを極限まで減らすこと。

提案・登録・リクエスト発火はワンクリック。
営業がやることは 判断だけ。

実際、
同じ成果を出すための工数は 1/10以下 になっています。

⸻

ここまでが、2025年12月までのSES_HUB

で、
「じゃあRBACって結局なに？」
という話ですよね。

RBACは、
• 商流を否定するものでも
• 慣習を壊す思想でもありません。

現実的に散らばっている
不確定要素・リスク・責任を、

「誰が、なにを、どこまでやるのか」

この役割分担を
権限（パーミッション）として明文化する仕組みです。

シリコンバレーでは当たり前ですが、
国内IT、特に人材・プラットフォーム文脈では
まだほとんど浸透していません。

正直、
「母数」「ユーザー数」がKPIになる世界では
かなり相性が悪い考え方です。

⸻

結論：マッチング至上主義、やめました

SES_HUBでは
母数確保のためのマッチング設計をやめました。

理由はシンプルで、
• SES形態でも
• 成約の再現性と量産性は実証できた
• その過程で、業界全体に歪みを生む構造も見えた

からです。

約2年かけて、
機能実装 → ユーザー反応 → 成果 → 質の変化
ここを全部検証しています。

⸻

これからのSES_HUB

SES_HUBはもう
「人材マッチングツール」ではありません。

RBAC設計で運用される
BPaaS型の営業支援・取引設計ツールです。
• 既存の商習慣を無理に壊さず
• 中長期の選択肢を残しながら
• 企業側がセキュリティと責任を持って
• “自由に使える” 状態を作る

そのための基盤です。

⸻

正直なところ

少し早かったかもしれません。
でも、準備としては早すぎないと思っています。
• 役割分担が曖昧なプロジェクト
• 判断コストが膨らみすぎている現場
• 人材・情報・責任の線引きに悩んでいる企業

そういうところから
静かに効いてくる設計です。

もし
「うち、まさにそこ詰まってるな」
と感じたら、
まずは現状の整理からで、お話大丈夫です。

03/01/2026

最近、
「AIって、便利になったはずなのに、
　なんか考えること増えてない？」
という話を知り合いとしていて、なるほどな〜と思いました。

いまAIって、
いろんな分野にどんどん入り込んでいて、
もはや「使う・使わない」を議論するフェーズではないですよね。

だから
「新しい技術はダメだ！」とか
「今までのやり方が正しい！」
みたいな話は一旦ナシで。

どう共存するか。
どう使うと “ちゃんと楽になるのか”。
そこを考える段階に来ている気がします。

最近、企業の方から聞くニーズを整理すると、
だいたいこの3つに集約されます。

-自動化したい

-生産性を上げたい

-固定費（人件費・外注費）を下げたい

突き詰めると、
「単純作業を、誰か（何か）に代わってほしい」
という話なんですよね。

それ自体は、ぜんぜん悪くないと思っています。
少子高齢化もありますし、
採用は年々しんどくなる一方ですし。

ただ、少し気になるのは、
これらの取り組みが

・稟議が通りやすい

・他社もやっている

・なんとなくやってる感が出る

といった理由で選ばれているケースが、
意外と多いな…という点です。

DXやAIが、
いつの間にか 「何かの肩代わり役」
になってしまうと、だいたい話がややこしくなります。

AsIs / ToBe は描かれないまま、
判断や責任の線引きも曖昧で、
気づけばベンダーやコンサルに丸投げ。

大きな開発やマルチベンダー体制だと、
「で、これ何のために作ってるんだっけ？」
という状態、わりと見かけます。

で、これと同じ構造が、
いま AI導入の現場でも、もっと小さな単位で
起き始めている気がしています。

たとえば、

① よく分からないままAIに丸投げ
② それっぽいアウトプットが大量に出てくる
③ 誰も中身を理解していない
④ マネジメントの確認・判断作業だけが爆増
⑤ とりあえず動くから納品
⑥ 前提条件が変わって破綻
⑦ みんな途方に暮れる

…みたいな流れ。

「うごくもの」はできるけど、
運用できるものではない、というやつですね。

規模や対象は違いますが、
やっていること自体は
上流での「ベンダーやコンサル丸投げ」と
かなり似た構造だったりします。

これ、
AIが悪いわけでも、
現場がサボっているわけでもありません。

単純に、
人と技術（手段）の関係性を、
ちゃんと定義・設計していない
それだけの話だと思っています。

認知が追いつかないまま最新技術に頼っても、
出てきた成果物を
「判断できる」「責任を持てる」
とは限らないんですよね。

AIやDXは、万能薬じゃありません。
でも、

誰が判断するのか

どこまでAIに任せるのか

どこから人が責任を持つのか

ここを先に整理しておけば、
ちゃんと 「ラクチンになるパートナー」 になります。

これからは、
「AIを入れるかどうか」よりも、
AIと人をどう組み合わせるか。

そんな話を、
現場と一緒に考えていけたらいいなと思っています。

01/01/2026

お問い合わせをいただく中で、
メディアや流行の影響を強く受けたご相談をいただくことが少なくありません。

よく挙がるのが、
• 「自動化したい」
• 「効率化したい」
• 「デジタル化したい」

といった言葉です。

ただ実際には、
「正直よく分からないので、
　自分たちが何に困っているのかを教えてほしい」
というご要望に行き着くケースがほとんどだったりします。

専門外の分野であれば、
それぞれの仕組みの違いや、
それが機能なのか概念なのか分かりにくいのも無理はありません。

⸻

「それ、大体RPAですよね？」
正直なところ、
「AIっぽい」「DXっぽい」と言われているサービスの多くは、実態としては業務フローを整理して、トリガーで処理を動かす仕組みです。

つまり、
• 業務をフロー化して
• 条件でリクエストを発火させ
• スクリプトや処理を起動する

これができれば成立する話がほとんどです。

物理的に
「AIのトークンを叩く必要があるか？」
というと、必須ではないケースも多いのが実情です。

⸻

よく聞くAI幻想
• 自動化できる
• 生産性が上がる
• 人件費が削減できる
• 入れたらDXになる

残念ながら、これらは半分幻想です。
AIの使いどころは、そこではありません。

⸻

なぜこうした誤解が生まれるのか。
理由はシンプルで、パワーワードが売れるからです。

「AI」「DX」「自動化」
人とお金が集まりやすく、売る側にとって都合がいい言葉だからです。

実際、
SEOやキュレーション経由で紹介されるサービスも、
AIやマッチングプラットフォームを名乗るものが大半です。

ただし、
そのまま「DXツール」を導入しても
「思ったほど成果が出ない」という結果は、すでに多く見えています。

⸻

大事なのは「何のためにDXするのか」
だからこそ私たちは、
「何のためにDXをしたいのか」
このフェーズから一緒に整理することを大切にしています。

もともとITで、
会社の業務設計や業務改善のコンサルティングをしてきた背景もあり、ツールありきの話はあまりしません。

実際には、

「それ、まずスプレッドシートで整理すれば変わりますよ
で解決するケースも少なくありません（笑）

01/01/2026

マッチングさせとけばそれでいいの？
きっとユーザー目線ではそうではないはず。

自由に繋がれちゃうSNSがふつーな今、
逆に調整や判断、責任の線引きにかかるコストやリスクが見えにくくなっている…と感じることないでしょうか。

BPaaSとしての営業支援機能で、発注や人材デリバリーの大切な情報に「だれに」「なにを」「どこまで」リーチさせるのか。そんな流通経路をセキュアに設計できちゃうAIツール、もうはじまってます！

オープンなソーシャルネットワークがあたりまえになった時代だからこそ、母数のみ提供してるSaaS設計はもう限界かも？！

31/12/2025

Role-Based Access Control
なんだそれ？
ってなったであろう2025年も年末を迎えました。

多重構造から生じる課題には、商流制限したり会社合併吸収してスケールで占有したりいろいろな対策があるのですが、
弊社プロダクトに関してはSESという仕組みの【拡張性】【柔軟性】【選択肢】これらを担保していく方針として、RBACの構造設計をシステム化。
IT業界の発注とリソースデリバリーの権限と独自性の保持を両立しつつ、情報セキュリティー観点からリーチとアプローチの制御をおこなうことを可能としました。

BPaaS型プラットフォームとして、
五月雨式で不特定多数なマッチングを生み出すことはせず、価値あるものの創出には価値あるもの同士の再定義と接続を可能にする設計が必要不可欠です。

「BPが欲しいだけなら無料SNSでよくないですか？」
そこに弊社プロダクト思考はありませんけど。

CPOとして以下は個人的な考えも含めですが、
このようなサービスを概念から立ち上げるのは4年ぶり。その結果レイヤー特化の横展開のみ助長してしまったことに疑念を感じながらも、サービス軸是正に2年ちかく要しました。その中で実際に対応策として機能設計し効果を得たものをこのたび縦横軸を同期的かつフレキシブルに成立するよう再設計。
ロールごとにパーミッションとして付与するかたちで実装に成功しました。

プラットフォームとして、
ユーザー権限を抑制しながら権利の保全をセキュアに実現しているプロダクトは他にほぼ例を見ないとおもいます。

「よく分からない」
これが健全な感覚ではないでしょうか。
だって前例がありませんので、それが当たり前ですね。

2026年もいろいろな経営者のかたとお話しできたらいいなと感じている大晦日🎍
みなさん、よいお年を。

26/12/2025

afnさんのWebに掲載していただきました！

全国のお得なショップ情報からショッピング・ビジネス・芸術・求人情報 etc... 満載のポータルサイトです！

25/12/2025

ここ数年の開発活動をとおして切にかんじることではあるのですが、
「生産性の低下」が謳われ久しい昨今、結局それってただの責任たらいまわしにしながら、なにかに依存するためのテンプレロジックを重宝してるからではないかと。

みんながみんなラクしたい。
結局だれもコミットしたがらない。
挙げ句の果て、やった人がなぜか責任追求されまくる。
最終的にバカみるくらいなら誰も手を上げない空気感増幅。

これ、ユニットの規模によらず蔓延したあとの雰囲気は停滞感そのもの。
つまりそうなってはそのチームや組織って改善コスト莫大だし、よくなる見込みもないどころか、それを維持するバイアスすら生まれてくる始末で、改善を叫ぶもその心理的安全性を担保したい勢力の都合で最適化されるという。

まるで地獄みたいな負のスパイラル、それが「生産性を低い状態で担保したい」まである沼った認知的な現状維持バイアスがネックになってるんですよね。

開発をする上で気をつけてる点は、
何をつくるかより何のために？って目的意識の浸透度。

なにかをよくしたいというニーズはあっても、それはその状態になってる理由がらあって、そこに改善策を提案、コンサルしながらは正直時間溶けるし骨もバキボキに折れちゃう。

なので合意形成していくこと自体を構想から外し「もうこうしちゃえばイイじゃない？」って仮説たてながら、実際にうまく事例つくれたことのみリソースを割く。
こんなサイクルで廻してますので、「それ結果でるの？」という質問はじぶんに対してはあまり意味をなさないってことだけ、ご理解いただきたくです。

25/12/2025

SES_HUB Next.
プレスリリースです。
各ロール順次ご利用申請再開させていただきます。
よろしくお願いいたします。https://prtimes.jp/main/html/rd/p/000000004.000090400.html

24/12/2025

SES_HUB Next.
こちら今回正式導入したRole-Based Access Control / RBAC構成図になります。
明確に発注権限と、開発リソースのデリバリー側からの情報管理におけるガバナンスを主体的に行える体制構築の支援が可能となります。