今年に入ってから自社製品向けのオンラインドキュメントを改善していくのを本格化しようと思い、自社製品向けの Sphinx テーマを開発しています。

自社でオンラインドキュメントツールに投資するというのはあまりないと思うので、その話を雑に書いていきます。

なぜドキュメントなのか

実際、ドキュメントツールに投資する話はほとんど聞かないと思います。自社でも「やっと投資できるような状況になった」というのが正しいです。

今まではなんとか自社製品で利益を出すというのが目標だったのですが、ありがたいことに、自社製品の売り上げで会社が回るようになってきました。そこで投資先を考えた結果、「既存のお客様が頻繁に利用するドキュメントを便利にする」ということにしました。

ドキュメントが使いづらいというのはとてもストレスを感じます。特に弊社製品はミドルウェアやその SDK という事もあり、ドキュメントありきです。ドキュメントが使いづらいということは自社製品が使いづらいということになるからです。

なぜ Sphinx なのか

もともと Sphinx を使っていた理由は、自分が reStructuredText (rst) に慣れていたというのが理由です。Python を利用していたこともあり、Sphinx を使う前から rst に慣れ親しんでいました。

もちろん Sphinx 以外のオンラインドキュメントツール（サービスを含む）も検討しました。

• readme.com
• gitbook.com

ただ、決め手としてはラムダノートの鹿野さんから「オンラインドキュメントであれば Sphinx 一択だと思う、特に rst に慣れているなら」というアドバイスを頂いたのが決め手でした。

また自前でホスティングしたいというのもありました。その点 Sphinx は Netlify との相性が良く、気軽にデプロイできます。

既存の Sphinx テーマへの不満

現時点では Read the Docs の Sphinx テーマを利用していますが、いくつか課題があります。

• デザインやレイアウトが好きではない
• 日本語との相性が悪い

そのため、自分たちにとって使いやすい Sphinx テーマを用意することにしました。

Sphinx コミッター小宮さんの招聘

残念ながら社内には Sphinx に詳しい社員はいません。そのため専門家のアドバイスが欲しいと思ったときに目を付けたのが「プラチナスポンサー」です。

時雨堂は Sphinx コミッター小宮さんのプラチナスポンサーです。このスポンサー特典として小宮さんの「答えられる範囲」で Sphinx のアドバイスがもらえるというのがあります。

小宮さんに弊社 Slack に参加頂き Sphinx テーマ開発時に Sphinx のアドバイスをしてもらえないか打診したところ快諾頂きました。

Sphinx テーマ作り

フロントエンドを普段担当している社員にお願いすることにしました。小宮さんとも面識があり（むしろ元同僚）、連携に困らないと思ったからです。

社員にお願いしたことは以下の通りです。

• 3 ペインレイアウトにして欲しい
• 日本語が読みやすくして欲しい
• 時雨堂のテーマカラーにして欲しい
• 検索に Algolia が使えるようにして欲しい
• rebar3 のドキュメントのような感じがいい

• Apache License 2.0 でオープンソースとして公開できるようにして欲しい
• 将来的に Algolia の検索部分は拡張として外に出してオープンソースとして公開して欲しい

検索機能

Sphinx の検索機能は残念ながら頑張れてるとは言えないと思います。そこで検索サービスを組み込むことにしました。ここは費用を払っても問題ないと判断しました。

いろいろドキュメント検索サービスを調べましたが、 readme.com が採用している Algolia が日本語にも対応しておりかなりよさそうと判断しました。

Algolia を Sphinx テーマに組み込む事で、検索が便利になるだろうと判断しました。

公開に向けて

現在テーマを少しずつ作成中です。特に隠すことはないのですでにオープンソースとして GitHub に公開しています。

小宮さんからは「この仕組みを実現したい場合は、何をすべきか」という的確なアドバイスをもらえており、本当に助けられています。

時雨堂では 2020 年 3 月から従業員を全員フルリモート勤務に切り替えています。一カ所に集まり、顔を合わせて仕事をする事がとても重要という考えのもとで作った会社がフルリモートになりそろそろ 1 年経過しそうなので、雑にまとめていきます。

会社としてやってることや自分がやってることごちゃ混ぜです。

定期的に追記していく予定です。そのうち Gist へ移動するかも。

社外との打ち合わせ

オンラインのみ。オフラインは一切行っていない。もともと社外との打ち合わせは少なかったので問題は出ていない。

社内の打ち合わせ

自社製品を利用してオンラインで打ち合わせ、オフラインは一切行っていない。また「皆で話をする」や「常時接続する」というのはやっていない。自分が必要なメンバーを集めて話す。

基本的に全員が（同じ自社製品の仕事ではあるが）独立している仕事をしているので打ち合わせをする必要が少ない。

中長期的なタスクをお願いする

やってもらうタスクを中長期的（数ヶ月単位）にして、できるだけ連携を不要にしている。

もちろん短期的なタスクもあるが、それは Slack や GitHub Issues でやりとりすればできるレベルに抑えている。

例えばリファクタリングや新しいライブラリの導入、時間のかかる機能改善、調査から必要な新機能対応など。

売り上げを諦める＝会社を忙しくしない

売り上げを上げるためにやっている事をやらないようにした。それよりは余裕を持たせる方向にシフトした。いろいろしんどい中、会社自体を忙しくしないようにすることにした。

もともとキャッシュフローを健全型に寄せてる経営をしてるが、より健全型に寄せるようにした。

もともと何かあった時のためにと、会社にお金を貯めており、それは今だと判断した。今はため込んだお金を使うターン。

休めるときはさくっと休んでもらう

ちょっと調子悪いかなとか、無理しないようにしてもらった。もともと無理するメンバーではないが、そこはあえてお願いしている。

定時に上がってもらう

リモートワークだと遅くまで働きがちというが、それは単にマネージメントしている人がタスク管理に失敗してるだけなので論外。

また明日も元気よく働いてもらうために意識的に定時に上がってもらう。

ドキュメント＞コード

自分はコードを書くよりもドキュメントを書く事をすることを優先した。一ヶ月ほとんどコードを書いていないとかの時もあった。コードを書くのは社員に任せて、とにかくドキュメントを重視することにした。

自社製品ドキュメントは決まってる事をよりわかりやすく使いやすく書くだけなので、誰とも会話しなくてもいい。

総務の負担を減らす

零細企業の総務は本当にやるべき事が多いので、できるだけサポートに入るようにしている。今までは全部任せっきりでも問題なかったが少しでも負荷を減らせるようにしている。リモートでフルタイム総務はしんどすぎる。

齟齬が増えやすいのを前提に話す

リモートは伝わりにくい、というのを前提に話すようにした。今までであれば「口頭で雑に終わらせていた」ものを全部 GitHub Issues 経由にしたりした。お互いの負担を減らすための仕組みを積極的に導入している。

追記予定

プログラミングの本はほとんど読んできていない。プロトコル解説やプロジェクトマネージメントの本ばかり読んでる。特にプロジェクトマネージメントは他の人がどう考えているのかを手っ取り早くしれて良い。

Python 2 系な上に、とても古いので初心者にはオススメはできない。この本は目次を見てもらえればわかるが一通りのことが一冊で学べたので他の本をほとんど読まなくて良かった。とにかく何でも書いてある。特にモジュールと例外の章はオススメ。

最初は原著を読んでいたが、途中で日本語版に切り替えた。とにかく翻訳が素晴らしい。読みやすいしわかりやすい。ボロボロになるまでひたすら読んだ。この本を完全に理解すれば Erlang/OTP でご飯が食べられるようになる。

多くのツール、手法そして概念がその解決策として取り上げられているが、それだけでは解決しない。プロジェクトを形成するのは人であり、プロジェクトマネジメントに人が占める要因は決して小さくないからだ。本書は、その「人」についてフォーカスを当ててプロジェクトマネジメントを語っている

今、自社で製品を提供していく上で何よりも役に立っている本。一人では何もできないことを学べる。

自分はデマルコ信者なのでデマルコ関連は全部読むことをオススメしておきたい。

現代のアプリケーションエンジニアは、UIやデータ処理、開発言語、プラットフォームの仕様や癖だけでなく、サーバやネットワークについても、上から下まで、表から裏まで広く知ることを求められます。本書は「ブラウザ」に関連し、インターネットで使用されるさまざまなネットワーク技術をまとめたものです

レビューワーの方から頂いて読んだのだが、本当に良い本で衝撃を受けた。定期的にオススメしている。オライリーの方に「本当に良い本ですよね！！！！！」って熱く語ったら「そんなに売れてないんですよ … 」って悲しい反応をされたことがあるので、ぜひ読んでみて欲しい。損はさせない。

実際に TLS を実装する必要があり手に取った本。知りたいことはほとんど書いてあって衝撃を受けた。本当に細かいことまで書いてあってとても良かった。

ただ、今はもっと良い本が出ているので、読まなくてもいい。

WebRTC で getUserMedia を利用してカメラから映像ストリームを取得するとカメラのランプが点滅します。

このカメラのランプってミュートするだけでは消えません。デバイスを掴んでいる限りはカメラのランプはついたままになります。

カメラをミュートにしたにもかかわらずカメラのランプがついてるのはとても気持ち悪いと思います。

カメラをミュートにしたときはカメラのランプも消えて欲しい、つまりデバイスを一度開放して欲しいという需要があると思います。

実はこれ WebRTC 的にはちょっとだけですが、めんどくさい機能なので、自社製品の WebRTC SFU Sora の JavaScript SDK のヘルパー機能として、用意しました。

SDK に依存しない仕組みとして用意したので、Sora を利用していなくても活用できます。

ちなみに、この機能を実現するキモは replaceTrack という機能ですので、もし良ければ調べてみて下さい。

Sora JavaScript SDK では今後もアプリを開発するにあたって Sora JavaScript SDK に依存しない、WebRTC の getUserMedia や RTCPeerConnection に関するちょっと便利なヘルパー関数を増やしていこうと思っています。

2020 年末に最新の WebRTC SFU Sora をリリースしました。録画周りの課題をいろいろ解決し、サイマルキャストを正式版機能としてリリースしました。まだまだやるべき事はありますが、基本的には改善フェーズに入ったと考えています。

インターコネクト機能

Sora は「単独で動くミドルウェア」として単体での性能、単体での機能を改善してきました。ただ、単体ではどうしても改善できないのが「多拠点に Sora を置いて利用したい」という要望です。

簡単に言えば複数の Sora を一つの Sora として見なす機能です。

現時点の Sora は 東京、ブラジル、アメリカ、イギリスそれぞれに Sora を立てた場合、現時点では「どこかの Sora」に集まる必要がありますが、それを不要にします。皆が東京に住んでいればいいですが、東京、ブラジル、アメリカ、イギリスに住んでいたとしても、皆が東京の Sora を利用する必要があります。

インターコネクト機能はそれぞれの Sora を相互接続させることで、東京の人は東京の Sora へ、アメリカの人はアメリカの Sora へ繋いで 良くなります。

例えば AWS では「異なるAWS リージョン内の 2 つの EC2 インスタンス間のトラフィックは、その 2 つのインスタンスが存在する VPC 間にインターリージョン VPC ピアリング接続が存在する場合、AWS ネットワーク内に留まります」と書かれています。もちろん AWS ネットワークに依存しますが、インターネットよりは明らかに安定したネットワークが利用されるため遠く離れた拠点同士でも安定して利用できるようになります。

この機能は国内外問わずに拠点を持つ大企業から多く要望を頂いています。

副産物としての大規模配信

インターコネクト機能の副産物として大規模配信がついてきます。

例えば東京に複数の Sora を立てて、それらをインターコネクト機能を利用し相互接続させることで、複数の Sora を 1 つの Sora として扱えます。

1 つの Sora が 4K@30 の映像を 100 接続まで配信できるとしたら、100 台用意することで 4K@30 を超低遅延で 1 万ユーザに配信することが可能になります。どの Sora に繋いでも良いので、運用も少しだけですが、楽になると思います。

実現可能かどうか

可能だとは思います。ただ安定的に商用環境で利用できるようにするのにはとても大変だと思います。

そのために負荷試験ツールや監視ツールを育てていく必要があると思います。課題は山ほどありますが、取り組んでいきます。

WebRTC 関連でどんなことをやっているか、やっていこうかというのを書いていこうと思います。時雨堂が WebRTC で何をやろうとしているのかの可視化です。

毎月書いていこうと考えています。時雨堂の WebRTC 製品に興味がある方は読んでみていただけると嬉しいです。

今後 WebRTC SFU Sora は独立して書くことにしました。WebRTC SFU Sora については以下をご確認ください。

宣伝

時雨堂の CTO である SUZUKI Tetsuya が個人で WebRTC ネイティブライブラリガイド for iOS and Androidという解説書を書きました。主に libwebrtc をモバイルで活用するという内容になるとのことです。 CTO は WebRTC SFU Sora …

今年もよろしくお願いします。今回は 2020 年 12 月と 2021 年 1 月版をセットにしました。

リリース

リリース方針

Sora は毎年 6 月と 12 月に大きめのリリースを行います。それ以外はバグ修正などがメインとなります。

2020.3 リリース

2020 年 12 月に 2020.3 をリリースしました。詳細は別に書いていますのでそちらをどうぞ。

2021.1 リリース予定

2021 年 6 月 頭に 2021.1 のリリースを予定しています。大きな機能は今のところ 1 つ位で、基本的には既存機能の改善を予定しています。

• インターコネクト機能 (Sora と Sora を接続可能にする)
• DataChannel 機能 / DataChannel シグナリング機能

インターコネクト機能

まだ検討段階ですが、Sora と Sora を接続できるような仕組みを用意しようと考えています。 …

サブスクリプション方式のサービスに限定している。

似たようなサービスを使ってる人で「え、これ使ってないの？」というのがあったら是非コメントで教えていただけると嬉しい。

または皆さんが使っているサービスを是非教えて欲しい。

価格は税込と税別が混ざってるので注意。

DeepL Pro

月 750 円 (年払い)

これなしではもうやっていけないくらい。

Gyazo Pro

月 490 円

今まで出会った中で最高のサービスの１つだと思う。

iCloud 200G

月 400 円

バックアップ用途。

Google Drive ストレージ 100G

年 2500 円

昔からの Gmail ユーザなので容量がたらないため。

Feedly Pro

年 50 ドル

まだ RSS の人なので。RSS を読むのは Reeder というのをずっと使ってる。Reeder 5 が出たのでアップグレードした。

Dropbox Plus

月 9.99 ドル (年払い)

開始してから払ってる。上位プランは自分には不要。容量は余ってる。

Amazon プライム

年 4900 円

Amazon プライムビデオがメイン。

Pocket Premium

年 4500 円

あとで読むサービスとしては頑張ってる方。もうこれしか手がないのでは。

GitHub Pro

月 4 ドル

勉強用コードのバックアップ用として。

Apple Music

月 980 円

開始してから払っている。iTunes Match が Apple Music に統合されたの知らなかった。

Medium Partner Program

年 50 ドル

メンバー限定記事は書いていない。ブログ利用料として払っている。

Netflix

月 1200 円

見たいときに見れるのは大事。

YouTube Premium

月 1550 円

広告が得意ではないので本当に素晴らしい。最高なのでぜひ契約することをおすすめする。

Discord Nitro

年 99.99 ドル

Discord 愛用しているので。