时雨堂：一家5个人的日本软件公司，把经营手册全部公开了

株式会社時雨堂（Shiguredo）2013年3月在东京成立，主营WebRTC实时音视频中间件Sora，GitHub账号是 shiguredo 。创始人voluntas持股100%，公司登记的代表取締役是中井亮介。员工人数上限写死为5人。

这家公司把雇佣条件、薪资、奖金实绩、评价制度、产品战略、工作时间制度全部写成公开文档挂在GitHub Gist上，定期更新。销售额、奖金占比、赞助和捐款金额都写在里面。

下面是其中七份的中文版，让AI按原文结构压缩编译，关键事实都保留了。原文是日文，篇幅很长，每一节都给了链接，以原文为准。这些文档还在持续更新，各篇更新日期不同，日期也标了。

一、公司总纲

原文：時雨堂コトハジメ（更新2026-08-01）

方针

创始人（持股100%）想怎么干就怎么干的公司。开发自社产品赚钱，回馈员工和社会。不做出售，不做上市。想成为赚很多、也捐很多的企业。

规模

员工上限5人。人多了销售额也许能涨，但会带来各种弊端，最在意的是 信息共享成本变高 ，这个绕不开。5个人的话，对全员保持透明还勉强做得到。少人数、高利润率、高收益，盯住这个就不会跑偏。

想增加人的时候，做法是 再开一家公司 。守住时雨堂这个文化，5人是极限。

雇佣条件

项目	内容
雇佣形态	只要正社员。不招兼职、实习、应届
工作地点	东京都台东区台东2-10-2竹田大厦4F
工作时间	10:00–13:00、14:00–17:00（6小时）
休息日	完全双休、法定假日、暑假2天、寒假（不定）
带薪假	试用期结束时给20天，之后每年20天
发薪日	当月工资次月10日发，遇休息日提前
工资	正社员全员同额
评价	没有评价制度
加薪	看公司业绩判断，不保证
交通费	每月上限3万日元
奖金	看公司业绩判断，10月底发，无最低保证
退职金	有退职金制度
考勤	在公司聊天工具里写一句
体检	每年一次全面体检
副业	不影响本职工作即可
远程	有条件采用

加薪实绩

创业第4年涨到了原定的工资水平，之后不打算再涨。但国家情况变化会考虑，比如消费税加税：

消费税从5% 涨到8% 时，加薪10%
消费税从8% 涨到10% 时，加薪17%

奖金实绩（只登实绩）

期	奖金占销售额
第2期	约15%
第3期	约20%
第4期	无
第5期	约15%
第6期	约30%
第7期	约25%
第8期	约25%
第9期	约20%
第10期	约20%
第11期	约20%
第12期	约15%
第13期	约25%

第4期集中开发自社产品，没有奖金。最高年收的上限已经取消——不设上限也没关系，只雇能扛得住的人就行。

福利

伤害保障：加入「あんしん財団」企业共济，公司负担，役员和全体正社员都在内，工作中和工作外24小时都保。
癌症保险：セコム損保メディコム，公司负担，役员和全体正社员。
退职金：加入中小企业退职金共济。本来的立场是与其发退职金不如当下就返还，但对员工几乎没有坏处，所以引入了。
流感疫苗：每年一次，公司负担，含役员在内全员。
体检：不分年龄都做钡餐或胃镜，每年一次，追加项目公司负担上限2万日元。

规则

规则很少，只在「遇到麻烦时」才慢慢加。举例：

不是裁量劳动制，是10:00–17:00定时工作制
午休13:00–14:00
22:00之后的加班给调休
带薪假第一年就给20天
1小时以内的迟到不扣钱（到11:00）
1小时以内的早退不扣钱（16:00起）

迟到早退这条不是预设11:00–16:00会变成常态，是给有事的时候留的口子。

把规则定严很容易，所以要尽量把规则定得松。规则是「拿不准的时候拿来对照的东西」。**为了防员工而设的规则，能不做就不做。**今后也尽量不加规则。

育儿

公司内部共享的规则原文：

孩子出生到1岁期间，因育儿难以到公司上班的，可以在家远程办公（基本还是请正常出勤）
孩子出生到1岁期间，因育儿难以按正常时间上班的，只要保证相当于10–17点的6小时工作时间，开始和结束时间不限。但到公司上班的情况下，极端晚退和极端早到不行，请在常识范围内调整
远程或错开工作时间时，在Slack上提前（当天早上也行）告知同事即可，不必每次给总务发邮件
孩子看病或突发看护要请假的，按正常流程申请带薪假
- 万一带薪假用完，按育儿介护休业法给「子女看护假」每年5天（每个学龄前儿童），但这部分无薪（不算旷工，不作处罚），且不能结转到下一年
孩子满1岁后仍需要适用上述规则的，商量后从满1岁次日起最长可延长半年
适用上述规则期间，工资和奖金与其他员工没有差别

酷暑、台风、大雪时的出勤

**等上司判断是浪费时间。**台风或大雪时，觉得上下班可能有困难， 由个人 判断，推迟出勤、提前下班、居家办公，或者当天改成带薪假都可以。在聊天工具里说一声就行。

公司信用卡

给 有需要的 正社员发公司信用卡，公司名义、印员工名字。用卡必须报告，事前事后都行。

社内环境

显示器尽量大
工作台尽量大
PC尽量高性能
椅子在30万日元以内，挑坐着舒服的

最大的强项可能是「时雨食堂」——每周一次在自家厨房做的饭，总务或员工做，考虑健康，参加不强制。

书籍补助：公司买的书 归自己 ，每年2万日元以内。电子书很多情况下法人买不了，主要是为这个。

食堂规则原文：

基于「要精神地工作，吃很重要」的想法，尽量选对健康好的菜单，味道和豪华程度排在后面
食堂能让役员和员工之间产生交流，也能当午餐会议的场所，因此全额作为「会议费」由公司经费运营
在时雨食堂吃饭是自愿的，绝不强制，按菜单和自己的健康状况决定

公司还买过家用面包机、面条机、章鱼小丸子机（后两个「最近没怎么用」）。

开发环境

PC基本发移动本，外接显示器 + 移动本统一。有需要也发台式。开发用的服务积极用：Vultr、Akamai Cloud、GitHub（含Copilot）、Claude、ChatGPT（含Codex）、Claude Code、Slack、Google Workspace（含Gemini）、Cloudflare、Kibela、1Password、Gyazo、Dropbox（含Sign）。有新服务就主动去碰。自动化也积极引入，人少的时候自动化收益很大。

评价与职位

没有评价制度，正社员工资全员相同。总务和技术一个数。没有面谈、没有考核、没有奖金评价。每年的利润留下公司需要的部分，剩下按人数分。比如员工2人，扣掉公司要用的之后剩100万日元，那就一人50万。就这样。

时雨堂没有职位。正社员全员同一，没有管理职。人少就没问题，目前没遇到麻烦。

人才与教育

聚起来的基本是「只要是工作什么都干」的人。技术上有好恶正常，但能把这事分开看。当然这个「什么都干」的前提是 不接烂活 。另外基本要求不挑食。技术人员招的是「尽可能作为技术人员挣钱的人」——小团队基本不需要经理，但技术人员的资源管理和信息共享能力非常看重。 光会写代码不行 ，组队时能带动周围的人很重要。

没有教育机制。有信息共享，但不专门留出「教育」时间。不过自社产品相关的工作不设截止日期，可以花时间做。方针三根柱子：持续开发、积极更新、持续测试。

各期主题与销售额里程碑

期	主题	里程碑
第4期	转向自社产品，减少外包受托	集中开发，无奖金
第5期	以自社产品为轴，Sora成形	自社产品收入够付全员工资
第6期	填外围护城河	2018年3月月销售额超3000万日元
第7期	培育自社产品	2019年6月月销售额超3000万日元
第8期	增强自社产品	2019年12月月销售额超3000万日元
第9期	做能带动主力产品的周边产品	2021年2月月销售额超4000万日元
第10期	主力产品服务化	2022年4月月销售额超4000万日元
第11期	主力产品服务扩张	2023年4月月销售额超4000万日元
第12期	主力产品进入新领域	2024年4月月销售额超5000万日元
第13期	不做新开发，彻底加强现有产品
第14期	彻底加强自社开源

第9期之后的外部帮忙只接现有客户，第10期起只接现有客户或熟人。

分工

经营者自己的工作只有三件： 做决定 、 产出利润 、 持续传达想做的事 。其余时间和其他技术人员站在同一位置干活。

经营相关的事务作业全部交给总务。给总务的要求只有两条：「减少支出」和「把职场环境弄好」。劳务、税务、法务全部外包，连创业手续本身也全外包了——判断是专心把钱赚好、把公司做好更划算。

技术上不分工，技术人员从前端到基础设施全包。

每月写一份《YYYY年MM月的时雨堂动向》，共享销售额、销售目标、外包支出、对全体员工期待的动作。理想状态是做到不需要看这个。

不招销售

时雨堂做的产品面向技术人员，不打算做「不懂技术的销售也能卖出去」的产品。 参与开发的技术人员 去讲，说服力非常强。

销售活动只靠博客、Gist技术资料、自家活动。不参加其他活动，不参展。

支持

自社产品的支持不雇专职，由产品开发者本人做。因为做的是开发者用的产品，来问的基本也是开发者。

经营

无借款经营
不做让员工吃亏的事
做能带来下一次的活
病态程度的透明
把员工当成年人

这行业不需要借钱是好事，有PC和网络就够，成本只有人工，也就是只有固定费，几乎没有变动费。每月做到固定的销售额就能转。

因为没有评价，人事上就没有要藏的信息，几乎所有信息都能共享。对公司的不满多半来自「有些决定莫名其妙」。没钱就说没钱，有钱就说有钱。销售额在聊天里共享。

对员工「当成年人对待」，细节不插嘴，交出去。定好大框剩下交给员工，出问题自己负责。

管理

尽量不做管理。长期愿景靠闲聊传达，短期方针靠文档。目标是做成自立型组织：全员在没有具体指示的情况下，各自判断当下该做什么。

活动

欢迎会、忘年会这类下班后的酒局，公司一概不办。要办就在时雨食堂把午饭时间拉长一点。想喝酒的人自己约。如果公司来办，应该在 工作时间内 办、 公司出钱 。比如年末最后一天的纳会，那天下午放假，午饭时间办。

固定活动（现在全远程所以没做）：12月最后一个工作日13:00收工后自愿参加纳会午餐；3月8日创业日13:00订个好点的地方跟员工和相关人士吃午饭；10月1日期初日同上。都有拒绝权，绝不强制。

员工旅行去过德岛县（原本是自己一个人去考察地方IT特区）和石川县（想住加贺屋，纯属自己任性）。

赞助与捐款

「靠开源撑着公司转，却因为自己的事忙不过来没时间贡献」，于是改成给常用的开源和认同的非营利组织做赞助。

GitHub Sponsors对象包括Loïc Hoguin（ranch / cowlib / cowboy / gun）、Tatsuhiro Tsujikawa（nghttp2 / ngtcp2 / nghttp3）、Peter Saveliev（pyroute2）、Ulf Wiger（gproc）。

对象	期间	金额
Let’s Encrypt	2017-08 ~ 2026-07	年1.25万美元
OpenSSL（银牌）	2021-08 ~ 2025-07	年2万美元
Erlang Ecosystem Foundation	2021-08 ~~2022-07、2025-08~~ 2026-07	年5千美元
DuckDB Foundation（银牌）	2025-08 ~ 2026-07	年1万欧元
Zig Foundation	2022-09 ~ 2023-08	年1.2万美元
cpprefjp（金牌）	2023-10 ~ 2024-09	年800美元

捐款（企业版故乡纳税和研究支援）：冈山县总社市100万日元（2018）、东北大学大学院医学系研究科笠原好之199万日元（2019、2020、2021、2022、2023各一次）、东京大学生产技术研究所增田殊大60万日元（2019）、熊本县芦北町100万日元（2020）、静冈县热海市100万日元（2021）、青森县板柳町和鰺ヶ沢町各50万日元（2022）、京都大学修学支援基金200万日元 + 乌克兰危机支援基金100万日元（2023）、东京大学修学支援事业基金200万日元（2023）、宫城县儿童贫困对策100万日元（2023）、岩手县大船渡市山林火灾复兴100万日元（2025）、熊本县八代市水灾复兴100万日元（2025）、宫城县儿童笑脸项目和残障者工资提升支援各50万日元（2025）。

铜锣烧

在Google搜「時雨堂」，联想词是「どら焼き（铜锣烧）」，因为有家同名和菓子店很有名。起因是voluntas公开亚马逊愿望单后，总务说要给送礼的人回礼，就寄这个。后来变成给一起工作过的人、照顾过自己的人寄。反响很好，还有人主动说「想吃铜锣烧」。voluntas自己一开始完全没兴趣，对反响这么好很意外。

广报与广告

广报活动积极做，手段是更新网站、在Gist上公开技术信息。新闻稿成本高、好处少，不做。对时雨堂来说广报活动就是销售活动本身——公司小，没人知道，得让尽量多的人知道。

广告一概不做。

出资

时雨堂出资了ラムダノート株式会社。理由是voluntas年轻时从该公司代表鹿野先生策划编辑的技术书里学到很多。技术书不是能大赚的生意，但是必不可少的东西。做不说话的股东，股东优待是能拿到该社出版的书。

产品价格（原文末尾的广告部分）

Sora的价格是 同时100连接、年授权费84万日元 ，也有3个月的。含产品支持费用。有服务器的话10分钟启动，内置demo功能，15分钟能跑起来。内置信令服务器和TURN服务器，不用另外搭。

二、招聘方针 + 薪酬

原文：時雨堂を支える採用（更新2026-05-05）

现状

现在只接受时雨堂员工的推荐。

薪酬（原文）

給与については社員全員が同じ事もあり、社員のプライバシーを考慮して公開はしていない。

時雨堂の月収は高くはなく、さらに賞与の保証はない。

賞与 — 実績として 0円もあるし、1人2500万円以上もあるが保証はない。

中文：工资因为全员相同，出于员工隐私不公开。时雨堂的 月收入不高 ，而且奖金没有保证。请先理解这一点再来应聘。奖金的实绩有过0日元，也有过一人2500万日元以上，但不保证。

申请前会跟voluntas闲聊一次，那时候会把过去的实绩、本期的预估毫无隐瞒地讲清楚。

招聘活动

总之就是砸成本。 公司经营认为人才就是一切，没有一点可以妥协。花的时间很多，对应聘者的 负担也相当大 。这是最不能妥协的地方，所以要砸成本。这也会给员工带来负担，但这也是工作——时雨堂 全体员工的工作内容里都包含「招聘面试」 。

现在在做的事

今后10年只走用Erlang/OTP实现实时通信分布式系统这一条路。

要求对这个技术领域有 强烈兴趣 。但只想做WebRTC（或WebTransport）、Erlang/OTP、分布式系统这类 特定技术 的人不招，因为公司方向什么时候变不知道。

技术栈跨度：Erlang/OTP（Sora本体，Raft + Plumtree）、Rust（Hisui、mp4-rs，还打算自研RTMP / SRT / RTSP）、Python + nanobind（Python SDK及一批绑定库）、C++（Unity SDK / C++ SDK / Zakuro / Momo）、TypeScript（sora-devtools、JS SDK、Sora Labo、Ayame Labo、Sora Cloud、media-processors）、Go（Suzu、archive-uploader、sora_exporter、Ayame）、WebAssembly（rnnoise-wasm）、Swift、Kotlin。基础设施：Ubuntu LTS、Docker、Sphinx、Nginx、Meilisearch（计划迁到DuckDB-Wasm / DuckDB-FTS）、Cloudflare（ 将来打算废弃 ）、Akamai Cloud、PostgreSQL、DuckDB、Grafana、VictoriaMetrics、Tailscale、SQLite、Ansible。

还在开发中的：Amazon S3 API兼容对象存储。今后想做的：健康导向的定食食堂经营、实时媒体管线工具、面向嵌入式的实时通信工具（含灾害时用的P2P分布式实时通信工具）。

总务和管理岗

总务除本职外还要干很多别的：与税理士对接、与律师对接、销售事务、自社网站制作和管理、陪同销售、产品咨询应对。管理岗同理：项目管理、产品验证、与开发对接、客户协调、网站运营、陪同销售、咨询应对。因此挑活的人不推荐。

适合的人

能作为成年人工作的人
能对公司事业投入的人
不容易腻的人
「样样通样样松」的人
没有特别想做的事的人
工资低也能活的人
想在同一家公司长期工作的人
同一个问题被问多少遍都无所谓的人

不适合的人

憧憬时雨堂的人
不能作为成年人工作的人
想赚钱的人
对技术太执着的人
容易腻的人
早上起不来的人
拖到很晚磨洋工的人
讨厌「让谁都能做」的人
不愿意碰可能被用于成人用途的产品的人
不想被反复问同一个问题的人

应聘条件（共通）

想让自社产品的粉丝变多
日语母语级
每天能到公司上班
不是 Brilliant Jerks
能按定时全职（120小时）工作
是成年人
挑食少，最好没有（过敏除外）
有在规定时间内出结果的意识
能对自己投资
喜欢团队工作
喜欢闲聊
值得信赖
没有特别想做的事
能在不增加规则的情况下工作

技术岗追加：持续对时雨堂的开源或时雨堂使用的开源做贡献；持续做开源赞助或捐款；有Erlang/OTP开发、运维或验证经验之一；有写注释的习惯；有读文档的习惯；编程之外有别的爱好；想在时雨堂长期干。

管理岗和总务岗的条件只有两条： 有时雨堂员工推荐 、想长期干。

有员工推荐的话，上面的条件可以不满足。

申请材料

除此之外的信息不要发过来：

姓名（含假名注音）
用条目形式写
读完时雨堂公开资料后写的读后感，A4一页以内

采用流程

确认满足条件，发送申请材料
见面（线上，30分钟以内，voluntas负责，仅限没见过面的人）
一次面试（线上，60分钟以上，voluntas负责，主要讲技术面和公司， 工资在这个阶段说明 ）
二次面试（线上，与 全体正社员逐个闲聊 ，每人90分钟以上，确认是不是想一起工作的人）
有需要可以参观公司（60分钟以上）
有需要可以和全体员工吃午饭（60分钟以上）——二次面试全员判断 想一起工作 后，告知时雨堂有录用意向；最后这顿饭是 给应聘者判断自己合不合时雨堂气氛的场合

采用条件：役员和员工的一票没有权重差别。全体正社员没有人反对才录用。只要有一票反对，当场不录用。

原因：时雨堂的奖金是均分的，人一多自己的奖金就直接变少。所以要全员面谈、全员认可之后才让人进来。招人时的评价点是「这人能不能挣钱」「自己挣钱的时候他能不能帮上忙」，以及一起工作累不累、是不是比自己强。

三、没有考核的考核制度

原文：評価制度の無い評価制度（更新2024-10-08）

标题来自一位员工的说法：「我觉得我们是一家『没有考核制度』这个考核制度的公司。」

原文注明：考核制度要随情况和环境变化，这是 现在适用于时雨堂的 制度，不是银弹。时雨堂行得通不代表别家行得通。

前提

没有考核制度，也就是员工工资全员相同——不分职种，技术和总务一个数。奖金也没有评价，把公司准备的奖金总额按员工人数除。

员工入职前就被告知没有考核制度、奖金不保证，接受了才进来。另外， 月工资作为现金流对策被设得较低，用奖金来返还 。

公司状况

员工个位数的微型企业。voluntas持股100%、创始人兼代表取締役，实质掌握决定权。今后最多也只增加到7名。今后一概不雇销售。

制度细节

「没有考核制度」具体是这样：

没有考核面谈
没有奖金面谈
没有晋级考试
没有目标提交
没有职业路径面谈

也就是员工不需要意识到任何跟考核有关的事情。说难听点是 没法意识 。

再怎么努力出结果，工资也不涨。但公司销售额涨了，结果会被1/人数之后作为奖金返还的可能性很高。公司这边的做法是直接认定： 员工为了出结果已经在做能做的最大努力。

制度的问题与处理

问题	处理
「我比别人更努力」的情绪	推荐跳槽到有这种考核制度的公司
工资少	推荐跳槽到工资高的公司
想往上爬	推荐自己开公司或跳槽
「人多了就行不通」的忠告	本来就不打算把公司做大，不是问题
技术和总务干的事不一样，工资一样不合理	制度就是定为平等，推荐跳槽到别家

也就是问题全部靠两件事解决：入职前确认「这家公司是这个制度，你还想进吗」，入职后「给你介绍下家」。入口和出口两头兜住。

关于「人多了行不通」，原文的回应是：现在小、运转得好，就没问题，今后也不打算做成100人的公司。

一个和制度无关的疑问

「不把公司做大销售额就上不去」——小着把销售额做上去就行了：

2021年2月月销售额超4000万日元
2022年4月月销售额超4000万日元
2023年4月月销售额超4000万日元
2024年3月月销售额超4000万日元
2024年4月月销售额超5000万日元

为什么取消考核

一直对考核制度有疑问，最主要的理由是感觉 根本不存在人人都能接受的考核制度 。

最初也考虑过「由上面的人评价所有人」，但自己不是那种完善的人，没自信做到公平评价，能避开就想避开。而且自己想写代码，不想做下属的考核面谈；也希望下属把用在考核面谈上的时间用来磨练自己。

「没有评价」是自己唯一能做到平等评价的评价制度。

运营成本

实际运行了10年，双方都完全没有考核负担，感觉非常好。

被评价的一方：不用害怕「评价」，用自己想的方式出最好的结果就行。当然辛苦的时候不勉强就好，那时也不用在意评价。

评价的一方：只需要盯销售额。销售额下降就降低奖金比例。但经营者的工作本来就包含提高公司利润，销售额下降是经营者的责任不是员工的责任，这跟考核制度是两回事。所以评价一方也基本不需要意识什么。

员工增加了怎么办

原文说这本来是最担心的点，但考虑到招聘流程，其实不太需要担心——时雨堂员工的职务之一就是「招聘面试」，录用条件是「全体正社员没有人反对」。员工在招人时必须意识到「自己的奖金会减少」，所以评价点会是这人能不能挣钱、能不能帮上自己，评价会相当严格。 在面试上砸成本，就能降低「没有考核的制度」的运营成本。

另外还打算让实际在无考核环境下工作的员工，在面谈时把自己的感受讲给应聘者，让理解彻底，避免入职后双方都不幸。

加薪与奖金实绩

因社会情势原因会加薪，除此之外一概不保证加薪，但没有降薪的打算。微型企业不知道什么时候倒闭，工资是固定费，压现金流。时机也一概不保证，目前用多发奖金来补。

第2期转第3期时加薪10%（利润稳定 + 消费税上调）
第7期转第8期时加薪17%（消费税涨到10%）

奖金实绩：近几年一人1200万日元以上。

不招销售

招销售的话，销售会要求按实绩来，就有人说需要考核制度。但按时雨堂的经营方针，一概不招销售，理由：

不做「不懂技术的销售能卖出去」的产品
靠数量和成果提升销售额，靠广报和市场就能覆盖
销售和技术之间的协调成本非常高

而且时雨堂做的产品，除非是有销售能力的开发者，否则很难卖。目标客户也是工程师层，销售基本没什么能做的。

原文还写了一条想法：微型企业搞内部竞争，公司会从内部开始变弱。时雨堂应该跟外部竞争，而不是在内部竞争。

总务难以评价

取消考核的一个原因是「自己不了解的事没法评价」。作为经营者总务的事也得看一些，但不想在那上面较劲，宁可写代码。基本想交给信得过的人，被辜负了就是那么回事，这个态度。

不同领域评价不了，而且总务的成果不好看见——不像技术那样短期内能看到「做了什么、销售额涨了」。评价那个的成本非常高，不想花这个成本。所以决定认定：总务和技术一样，会把能做的做到最大。反过来说，总务做的是自己做不到的事，光这一点就够了。

应届 / 中途 / 兼职

不做应届招聘，要招也按社会招聘同等对待。中途入职者除入职第一年的奖金外全部同一，第一年的奖金由经营者判断金额。兼职不招。

四、自社产品的起点和逻辑

原文：時雨堂自社製品コトハジメ（更新2024-05-21）

前提

时雨堂的目标是只靠自社产品吃饭（已达成）
一概不做外部融资 ——公司靠大家一起转，技术负责增加收入，总务负责减少支出

产品史

**第一弹：Lua的Lint工具。**当时忙着挣饭钱，拜托CTO做的。没怎么卖出去，但这是起点。2017年5月开源并停售。

**第二弹：MQTT系列。**某个项目里用WebSocket做的系统很麻烦，被人介绍了MQTT，边学边写了个broker。与其说是做想做的东西，不如说是觉得有意思。还提供了免费或500日元/月的MQTT broker服务，以及IoT数据汇聚网关。broker没怎么卖出去，有咨询但很少走到成交，跑去大阪、京都做产品说明，结果对方说「学到了」就结束了。IoT在概念验证阶段有钱出，长期使用的服务很难。传感器和硬件那边对网络理解不足，支持负担也高，于是决定撤退。加上开源的VerneMQ出来，商用包很难打。服务那边用的人不少，2017年6月结束时有1000多人用过，这点很高兴。

**第三弹：WebRTC系列。**原本想做SIP相关产品，但SIP脾气太怪，资源少扛不住，于是转向WebRTC。P2P谁都能做，所以采用经服务器的模式，做WebRTC SFU。开发期约1年，从库开始全部从零写。2015年12月正式发布，2016年3月发布免费试用服务，同期发布嵌入式WebRTC实验产品。

2017年7月，发布1年半，员工工资全部能由自社产品销售额覆盖
2018年9月，发布2年半，销售额是前年2倍
2019年12月，发布4年，销售额是前年1.5倍
2020年11月，发布5年，销售额是前年2倍

**第四弹：压测工具。**做出来了，早期客户也拿到好结果（ FGO采用的压测工具）。但发现压测工具做成自社包产品非常难：压测范围太广，不做定制就得先实现一整套功能，还得让客户能自由配置以适应各自环境；跑不起来时支持很痛苦，只在客户环境出现的问题很难复现。以现在的规模开发、维护、支持不下来，于是放弃向新客户销售。

**第五弹：React Native用WebRTC库。**本来打算给现有的react-native-webrtc做贡献，但和自家不合，改为自研。iOS的起步和Android的起步都外包，最后一公里自己做。纯属个人兴趣。后来react-native-webrtc的开发稳定了，就关闭了。

**第六弹：把一个WebRTC产品重写并开源——Momo。**原本WebRTC Gateway Momo是闭源实验产品，几乎没人用也没资源投入，一直放着。第7期销售额稳定后想做新东西，于是完全从头开发成WebRTC Native Client Momo：Apache License 2.0开源，除树莓派外还支持Ubuntu（x86_64 / ARMv8）和macOS，容易定制，树莓派上能用GPU硬件加速。市场和需求都不管，只做自己认为需要的东西。开发本身请外部帮忙，自家专注改进和验证。买了Sora授权的客户可以获得Momo的技术支持，已经有几家签了。

**第七弹、第八弹：P2P用信令服务器Ayame和它的服务Ayame Labo。**不以盈利为目的，是对WebRTC这项技术的贡献。理由是不被厂商锁定又持续维护的信令服务器太少。Apache 2.0、Go写的简单服务器，提供Web SDK和React / React Native示例。把3人以上全网状那套容易让代码变复杂的机制砍掉， 限制一个房间2人 来保持代码简单。服务侧不为服务改动开源服务器本体，免费，用GitHub账号登录，靠认证和TURN提供附加价值，流量策略是「超过上限所有人都用不了」。

**第九弹：Sora Labo。**在试用评估版之前先「摸一下」的服务，验证目的免费，GitHub账号登录，服务器由樱花互联网提供，定期重置账号，企业和学术使用需要申请。公开后马上有客户转去用评估版。

第十弹到第二十四弹 （挑要点）：Unity SDK（开发和维护完全外包，接口设计和发布判断自家做）；压测工具Zakuro（「让人想买主力产品的工具」第一弹，只支持Linux，开发维护全外包）；E2EE库（用SFU就避不开「有恶意的管理员」，从客户端立场提供防御手段）；录像合成工具Hisui（第二弹）；统计收集工具（第三弹，TimescaleDB / Grafana）；浏览器端媒体处理库media-processors（虚拟背景、降噪，不绑定自社产品，npm提供）；Sora Cloud（按同时连接数和带宽计费，第一个自家运维的服务）；C++ SDK（作为其他SDK的核心库，Unity SDK已换成它，之后iOS / Android也要换）；Flutter SDK（ 开发终止 ——发布前判断Flutter用户和自社产品用户对不上，今后不再做这类跨平台产品）；文档全文检索（Meilisearch，日语也能即时搜索）；低码率语音编解码器的浏览器支持（ 已终止提供 ）；录像合成工具的云版（第一次把开源产品的云版做成收费）；Python SDK（基于C++ SDK，面向机器学习用途，上了PyPI）；轻量C SDK（基于libdatachannel，面向硬件嵌入，因为现有库4周一发布对嵌入式不友好）；SDK的H.265支持（向两大主要专利池确认过，用硬件加速并以二进制分发SDK的情况下不需要授权）。

从发布到第一笔收入

Sora：开发花了1年，这期间没有利润；发布后 花了半年才卖出去 ，因为「WebRTC SFU」这个概念完全没有认知度；咨询变多也是发布半年之后。原文推测这个概念渗透花了1年以上。

Sora Cloud：已经有包产品的客户、在这个领域有一定知名度的状态下发布，发布前就有人说想用，发布后马上有多个客户，销售额一发布就定下来了。

2024-05快照

光靠包产品Sora的销售额，员工工资和奖金已经够
开源产品的「优先实现」能产生销售额
Sora的云版能产生销售额
能雇多名全职QA了

闭源包产品方针

自社产品重视「维持自己做下去的动力」，不重视利润
卖的自社产品全部从零开发
卖点是 不宕、简单、便宜 ——不宕是为运维者，简单是为开发者，便宜是为经营者
因为是积累型，单台授权价格设得偏低，价格要设成能让人长期用下去的水平

**销售方针：**不开会；提供1个月的评估版，超过1个月就收费；产品网站积极更新； 一概不做定制 ；不接受降价要求（只对大量采购打折）；不设销售人员（靠博客、技术资料公开、面向开发者的研讨会）；只卖包产品；采用按年收费的订阅授权（1年 / 3个月 / 6个月三种更新周期）； 没有采用案例的话价格设高 （一开始必然从「无案例价格」起步）；对方公司大小不影响对待方式；加新功能不涨价； 不理会失礼的客户 。

**宣传方针：**在Gist上公开资料并积极更新，搜索目标锁定技术人员；网站做得好懂；定期做线上研讨会。

**开发方针：**重视持续下去；不实装太多功能；实验功能作为预览版提供看客户反应；授权费含支持费；对应OS只有RHEL和Ubuntu LTS；版本号用YYYY.RELEASE.FIX；至少6个月发一次；库永远用最新版；内部结构积极改。

**支持方针：**6个营业小时内首次响应；在支持系统做好之前只走邮件，不接电话；只在营业时间内，不做7×24；授权费里含的支持只覆盖产品本身，不含SDK；支持由该产品的开发者担当；产品发布后支持约12个月。技术支持（超出上述范围的）另外按月收费，在自家聊天里开专用频道。

**文档方针：**用Sphinx，自研主题，快速开始能跑起来，细节用FAQ形式，提供全文检索。

**SDK方针：**社区运营靠Discord；Apache 2.0开源；咨询先走Discord； 没有事先沟通的GitHub Issue和Pull Request不接受 ；示例做简单；尽量准备展示案例。

**咨询方针：**以购买产品为前提，有偿提供技术咨询。

盈利型开源产品方针（Momo、Sora的SDK和工具）

Discord社区运营；Apache 2.0公开在GitHub；定期更新； 路线图上没有的功能，可以付费优先实现 ；定制 收费也不接 ；定制的技术支持只对购买了闭源产品的客户有偿接受。开发上少加功能只做基本功能，跟进最新库，方便定制。

非盈利型开源产品方针（Ayame）

Discord社区运营；Apache 2.0；定期更新；功能压到最低；定制收费也不接；定制的技术支持收费也不接。开发上少加功能，跟进最新浏览器，优先维护效率。

云版方针

Sora Cloud： 始终只是包产品的云版 ；不贪心加各种功能；便宜可用；按同时连接数和使用带宽两个维度计费；高可用性优先；用自研工单系统提供支持。开发上「不着急」，提供API。

Hisui的云版：始终只是开源产品的云版；以给商用产品云版加功能的形式提供；不贪心；不额外收费。

验证 / 非盈利服务方针（Sora Labo、Ayame Labo）

Discord社区运营；免费；维护只在Discord通知；不做冗余； 不提供支持 ，但给建议；不保证可用性；定期初始化数据库。Ayame Labo还兼作自社产品的验证场。开发上「不着急」，加功能要慎重。

社区运营方针

只在Discord应对；设社区经理； 优先回答「以前回答过别人问题的人」 ；bug报告优先处理；Pull Request要求说服。

信念

提高质量来减少支持负担 ——靠产品销量取胜就避不开支持负担
不做定制 ——定制能一时产生利润，但会缩短产品寿命
不雇销售 ——大量利用互联网
做对经营者友好的产品
做对开发者友好的产品
做对运维者友好的产品

五、全远程怎么运作

原文：時雨堂を支えるリモートワーク（更新2024-05-22）

这份最短，全文只有一段：

暂定采用全远程办公，但判断远程办公的成本非常高， 员工以每周5天出勤为前提 。

配合另外两份看：《时雨堂コトハジメ》里写的是「 不采用远程办公，以出勤为前提 」，同时注明「现在从2020年3月起全体员工暂定为全远程」。《时雨堂を支える採用》的应聘条件里明写着「 每天能到公司上班 」。

也就是制度上的立场是出勤制，2020年3月起的全远程是暂定状态，到2026年8月的最新版文档仍然是这个措辞。全远程期间停掉的东西包括：每周一次的外送午餐、12月最终营业日的纳会午餐、创业日和期初日的午餐会。

《コトハジメ》里给出的理由是从《肾上腺素狂人》（Adrenaline Junkies）引的两段，大意是：

第8条「目光接触」——开发团队之间最重要的信号是信任与被信任。隔着距离建立信任很难，语气的微妙差别、自信、某种反讽、言外之意、确信的强度、绝望感和无力感、精力水平、有没有说谎，这些都难以读取。读不出这些细微差别，沟通就不顺；概要能传达，但由此得出的结论算不上确定。带着这种漏洞能推进项目吗——不是不可能，但不如团队在同一地点时顺利。
第14条「面对面时间」——现在的经理会说，在同一地点工作的少数精锐团队最好。这在30年前、40年前、50年前都是不变的道理，现在也一样。那是开发软件的最佳方式。

六、产品战略

原文：時雨堂を支える製品戦略（更新2024-04-16）

公开的理由：每次开会都要讲一遍，嫌麻烦。

基本战略

不做超出自社资源的勉强事。

自己（voluntas）有没有兴趣
成为在那个领域技术上有名的公司
绝对不接定制
不奔着眼前的利益跑
不提供有可用性保证的收费自社服务
挑活

产品战略

**做创始人自己想做的东西。**只有这句太单薄，所以展开：

**自社包产品：**做有状态或无状态的Relay / Proxy / Gateway / Broker。不为特定客户开发产品；基于开放协议开发；做「服务的零件」而不是解决方案—— 解决方案交给客户自己负责 ；选定一个起点技术然后往外派生（WebRTC的话就是信令服务器 → TURN服务器 → SFU）； 把利润排后面，重视稳定性和质量 （小公司优先利润的话质量必然被牺牲）；重视持续开发，积极升版本；先让人用带期限的试用版；做测试自动化。

自社收费服务： 补包产品的短板。尽量 原封不动 地提供包产品；能轻松切换到包产品；不提供自社产品以外的功能；尽量不做维护停机。

**自社免费服务：**缩短「试一下」的距离。让开发者能随便免费用；不提供超出包产品的功能；不做运营保证。

**自社开源：**缩短到产品的距离。License用Apache 2.0；公开自社产品的SDK和示例；做成简单的结构方便别人fork来用；开源产品不考虑利润；基本不做付费支持。

广报战略

很简单，基本只在互联网上宣传。

技术资料： 用Gist公开 持续更新的 技术资料，然后在最下面放自社产品的广告。靠一直跟进最新信息，做成让人愿意定期回访的资料。

**产品网站：**必要信息尽可能多，设计简单。产品站应该做到不用咨询也能在站上了解一遍。信息放少、等人来咨询，对小公司来说成本太高。 不设咨询表单 ——真有需要的话，只要公开邮箱地址就会有人来联系。定期更新网站也很重要。

**不参加面向销售的活动：**浪费时间。技术人员会自己搜，会找到开发日志。要参加就只参加面向技术人员、没有人力公司掺和的活动，而且不宣传自社产品，宣传自社产品用到的技术。另外也不给既有客户发邮件通知——自己收到会觉得烦。

**产品开发日志：无防守战法。**这点和别家不一样：基本上开发之前就公开要做什么，定期公开实际做到哪了，感兴趣的人可能在做完之前就来联系。日志写在GitHub Gist上，实际看到这里来联系的人很多。（時雨堂WebRTC SFU Sora開発ログ）

销售战略

**卖给竞争对手。**这是最先确认的一条。产品面向的规模偏大，客户往往有竞争对手。会明说：也会卖给你的竞争对手，也会跟他们合作。

**以公开采用案例为前提。**拿不到采用案例的话，产品价格就报高一点。

**注意支持成本。**和对方技术负责人沟通困难的话，支持成本可能暴涨。优先销售额就会掉进这个陷阱。所以要确认对方技术人员的水平，并写进签约条件。

**不做电话对应。**只走邮件或专用站点的咨询。

**技术支援只给自社产品的客户。**单独的WebRTC技术支援不做，只对买了自社产品的客户有偿提供。

**不做open price。**因为「价格不清不楚、用起来不方便」这件事自己不喜欢。

七、固定6小时工作制

原文：時雨堂を支える固定時間労働1日6時間（更新2024-01-20）

原文的注明：不是说这做法有多好，只是 认为适合现在的时雨堂 ，没有别家也该这么干的想法。而且定这个制度的自己并没有享受到这个制度的好处，所以好坏说实话不太清楚，只是员工没有不满，就这样吧。

前提

时雨堂采用10:00–17:00的固定6小时工作制。

IT公司，销售额几乎全来自自社产品
除少数例外，不分职种、不分远程与否，全部适用同一规则
午休13:00–14:00一小时（远程时不适用）
周末和法定假日休息，带薪假每年20天， 消化率接近100%
只要不常态化，晚1小时（11:00）到岗可以
只要不常态化，早1小时（16:00）下班可以
没有考核制度
全体员工工资和奖金相同

商业模式那边：没有销售；卖自社中间件包产品（支持只在营业时间，不接定制）；卖它的云版（同样）；自社开源的优先实现（把路线图上的功能提前做）；自社产品的技术支持（营业时间内聊天实时支持）；对外帮忙（提供闲聊）。

为什么采用固定工时

**因为员工工资全员相同。**工资一样，工作时间也想一样。可以随便安排的话，「总觉得不公平」这种不满会积起来。当然是想雇不会这么想的人，但人这东西很难，那还是全员工作时间一样比较好。

**为了防止工作过度。**裁量劳动给人的印象就是很容易工作过头。不让人工作过头，公司认为这非常重要。时雨堂的方针是赚到必要且足够的利润之后就不再勉强，所以不制造能工作过头的环境。在时雨堂想不被时间束缚地工作，只能当役员。

**为了把信息共享成本压到最小。**固定工时的话全员在同一时间工作，不会出现谁没来的情况。10人以下的小公司，全员在同一时段工作，信息共享成本最小。异步多任务很累，同步单任务好；要做同步单任务，就需要全员在同一时间工作。

**为了减少意外。**工作时间自由的话，自己没在工作的时候可能有联系或商量进来。固定工时的话全员只在这个时间工作，能减少这种情况。在工资相同的前提下，自己没工作时收到别人工作中的联系，总会觉得不公平。

为什么是6小时

**长时间集中不了。**认为人的注意力最多只能持续2小时左右，拖拖拉拉地工作浪费时间，断掉的注意力要恢复还得花时间。

**希望养成在规定时间内出结果的习惯。**员工本来就应该养成在规定时间内尽可能出大成果的习惯。 长时间劳动是役员的特权 ，不给正社员。可以「定额无限干」的只有役员。

**上年纪之后长时间劳动干不动。**人会变老，长时间劳动会变难。希望员工在自家干到退休，所以希望把每天6小时工作变成习惯。

原文链接汇总

本文整理的七份：

中文标题	原文	更新
公司总纲	時雨堂コトハジメ	2026-08-01
招聘方针 + 薪酬	時雨堂を支える採用	2026-05-05
没有考核的考核制度	評価制度の無い評価制度	2024-10-08
自社产品的起点和逻辑	時雨堂自社製品コトハジメ	2024-05-21
全远程怎么运作	時雨堂を支えるリモートワーク	2024-05-22
产品战略	時雨堂を支える製品戦略	2024-04-16
固定6小时工作制	固定時間労働1日6時間	2024-01-20

其他相关：

時雨堂を支えるビジネスモデル（2023-12-08）
時雨堂を支える技術（2025-05-13）
時雨堂を支える環境（2024-12-02）
時雨堂を支えるマネージメント
時雨堂を支える食堂
時雨堂WebRTC SFU Sora開発ログ
公司主页 shiguredo.jp / 产品站 sora.shiguredo.jp / GitHub github.com/shiguredo

《時雨堂を支える開発方針》这份已经被作者删掉，现在只剩一句「现状变化太大，暂时删除」，但其他文档里还挂着链接。