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

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

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

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

一、公司总纲#

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

方针#

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

规模#

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

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

雇佣条件#

加薪实绩#

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

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

奖金实绩（只登实绩）#

第 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 万。就这样。

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

人才与教育#

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

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

各期主题与销售额里程碑#

第 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）。

捐款（企业版故乡纳税和研究支援）：冈山县总社市 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 一页以内

采用流程#

1. 确认满足条件，发送申请材料
2. 见面（线上，30 分钟以内，voluntas 负责，仅限没见过面的人）
3. 一次面试（线上，60 分钟以上，voluntas 负责，主要讲技术面和公司，工资在这个阶段说明）
4. 二次面试（线上，与全体正社员逐个闲聊，每人 90 分钟以上，确认是不是想一起工作的人）
5. 有需要可以参观公司（60 分钟以上）
6. 有需要可以和全体员工吃午饭（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 小时工作变成习惯。

原文链接汇总#

本文整理的七份：

其他相关：

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

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