## 実装方針

ローカルのエディタで書いて、GitHub にプッシュし、差分管理する
GitHub Actions 経由で Vercel の Next.js が SSG する (DB を作らない)
簡単なスクリプトで対応 : markdown と yaml で管理しつつ、node scripts で調整する

markdown-it, front-matter, mustache を使って、大きなシステムは使わない

## 過去アプローチ

WEB管理画面がめんどくさい、DBに値を入れるほどではない
スクリプトを書く代わりに何かツールを使うが、結局は微調整が必要でツールの細かい学習が必要になる

* WordPress 的アプローチ
* Headless CMS 的アプローチ (startpass)
* Hexo の利用 (dojo.codebot.io)
* Gulp の利用 (codebot.jp)

## Scripts でやること

* timeline (sort)
* paging (range)
* word search
* category, tag
* related posts

outline が必要な場合は、yaml で書く
ここでいう outline は1記事の見出しのリストではなく、複数記事を並べたもの
ドキュメント、リファレンス、ウィキなどがこれに当たる
または、マガジン、ブックなど、1冊という単位があり、中身の記事が分かれているものを想定


当サイトの記事更新方法というメタな話

## 記事紹介

[ライブコマースが日本で流行らない裏事情、なぜ中国だけで「50兆円市場」に化けたのか ｜ビジネス+IT](https://www.sbbit.jp/article/cont1/96145?page=1)

```
publish_at: 2022/10/11
author: 牧野武文
publisher: SBクリエイティブ株式会社
```

> 中国以外の国ではライブコマースはまったく軌道に乗っていない

実感に近い。
アメリカでは Facebook, Amazon もやっているらしいがだめらしい。

> 日本のテレビショッピングと同じ手法で、最初は標準的な価格が示され、
> 「価格は後ほど発表」として商品の説明が始まる。
> 
> そして、いよいよ販売価格が発表になり、
> 「今から5分間だけ」「先着1000名のみ」などの条件がつけられる。
> すぐに購入ボタンを連打して購入しなければならない。

見出し通り、ジャパネットと同じ。
ゲーム的な演出というのはなるほどという感じ。

> ここまで大胆な割引をすると、販売するブランド側に利益が出るはずもない。
> それどころか赤字前提で販売していることも多い。

ではなぜやるか。
フォロワーの獲得のためらしい。
日本では、健康食品など単価の高い商品ではおこなわれている。
つまり、ライブコマースはアプリの新規顧客獲得の広告ということだ。
たしかに、アプリのインストールの CPA（Cost Per Acquisition）は高い。

## 私域流量と公域流量

恥しながら初耳だったので調べた。

* 私域流量 : Private traffic : 自社サイト・アプリおよび実店舗へのアクセス数
* 公域流量 : Public traffic : アリババおよび百貨店へのアクセス数

つまり、自分達が持っているお客なのか、看板を借りて集めたお客なのかという違い。

著者いわくアメリカも日本もそもそも EC が未発達らしい。中国は EC が発達し、アリババでの集客コストが高すぎて、ライブコマースをやる方が安上がりらしい。また、アリババに会員情報がある人が大量に買ったところで、その後のロイヤリティにつなげられないので、ビジネスの発展性を作ることができない。

そりゃそうだなと。

つまり、D2C だ、OMO だという単純な話ではない。
百貨店や楽天に対する、実店舗と自社アプリをどのようにバランスさせるか。
また、Instagram/TikTok でのライブ配信とどのように選別するか。

マーケティングコストとしてライブコマースをやるのか。
自社アプリを作り込むメリットはあるか。
(10X みたいな会社は、個社ごとにアプリを開発している)

小売ビジネスについて考えるいい記事だった。


ライブコマース と EC または、私域流量と公域流量の話

ビジネスモデルの評価

## 政治経済勉強会で利用したい

こんにちは、株式会社ダラフの斉脇です。
この度 Tparty という「Discord を利用した政治経済勉強会」で利用するウェブシステムを開発しました🎉
「**テキストのための舞台装置**」というコンセプトで、活字をいい感じに見せるためのシステムです。

この政治経済勉強会では、第1,3月曜日に「チャンネルマガジン」を発行し、毎週水曜日に「チャンネルニュース」を発行しています。チャンネルマガジンは、勉強会の管理人が編集者としてメンバー3人を指名し、それぞれが約1万字を執筆のうえ、編集者と約1時間ほどトークをする形式をとっています。つまり、1号あたり約3万字のテキストと、3時間のトークが収録されているリレーブログのようなものです。チャンネルニュースは、管理人がその週のニュース記事を3つほどピックアップし、記事それぞれについて約1,000文字のテキストと、約10分の音声を収録しています。簡単に言えば、メルマガを Discord ベースで発行しているという感じです (なのでチャンネルマガジンと呼ばれています)。

マガジンについては、テーマは自由ですが、編集者がレビューする形で作っています。特徴は、テキストに対して必ずトークを収録している点です。以下が、マガジンのタイトル例です。

* SNSは死んだ。思えば、僕たちは差し出し続けてきた
* 地域・農業スタートアップの半解体新書
* オミクロン真っ最中のフランス・ベルギーに飛んでみた
* ネット系スタートアップの過去と未来
* チリは南米の優等生か
* 花の美しさは存在するか
* セクシュアリティ・イン・ザ・ウッズ
* シティボーイと呼べない東京育ちのリアル
* 翻訳者になって初めて知ったこと
* 中小企業の強化が、日本を救う ～とある事業承継準備の記録～
* 美術展のキャプションに書いてあること、書いていないこと

## 執筆体験から考えたこと

私も一参加者としてチャンネルマガジンの執筆および音声収録を体験しましたが、とても有意義な体験でした。編集者とは PDF にハイライトおよびコメントをしてもらうことでコミュニケーションをとりました。また、知人の参加者にも事前に読んでもらい、同様の方法で感想をもらいました。

PDF なのでやりとりに限界はありましたが、良いと思った部分にハイライトをしてもらったり、コメントをしてもらうのは嬉しいものだと感じました。知り合い同士でクローズドにやっていたので不快なコメントがなかったというのもあると思います。ただ、近年のソーシャルメディア、ニュースサイト、ブックマークサイトのコメントに見慣れていたので、有意義なコメントに驚いたというのもありました。

逆に私が知人のレビューをする機会もありました。PDF ではできなかったのですが、やはりハイライトした上で、絵文字やスタンプを送れるようにしたいし、ハイライト箇所をベースに質疑応答ができるようにしたいと思いました。コンテンツ自体も良いのですが、コンテンツからコミュニケーションにつながるようにしたいと思いました。

この体験からいくつかのやってみたいアイデアを想起しました。ひとつは、ライブ動画のように投げ銭できないかというもの。ハイライトした上で、拍手👏のエフェクトを [SHOWROOM](https://www.showroom-live.com/) のように送ることができないかというものです。さらに、ハイライトした上で、ポイントを付与して質問する。その質問に著者が回答した場合に、ポイントが支払われる仕組みです。これは、Stack Overflow の [Bounty (懸賞金)](https://stackoverflow.com/help/bounty) という機能に類似しています。また、リアリティショーのように、編集過程自体を公開し、テキストが編集されていく様子をエンタメにできないかとも考えました。著者に対して有望だと思ったら編集者や校正者のように振る舞うことができ、その著者が有名になった場合にインセンティブが支払われるような仕組みも面白いでしょう。

当然このような思いつきのアイデアは誰か他の人が考えているもので、Google で検索すると出てきます。

約15年前に株式会社はてな創業者の近藤淳也氏のブログに同じようなアイデアが書かれています。
[ブログ作者に投げ銭を - jkondoの日記](https://jkondo.hatenablog.com/entry/20050810/1123662359)

また、リアリティショーのように編集過程を公開するのは、おそらくはプロセス・エコノミーなのでしょう。
[「プロセス・エコノミー」が来そうな予感です｜けんすう](https://kensuu.com/n/nf4270e069c20)

## 言文一致と日本語の条件

管理人の方に聞いたところ、チャンネルマガジンの号を重ねるごとにフィードバックが集まってきており、ある感想が目立つようになったそうです。その感想は「**トークがいい**」というものでした。ある読者の方は、最初にトークを聞いて、人柄を知った上でテキストを読むそうです。そうすると自然とテキストが読みやすくなるということでした。

この話を聞いて、7年ほど前の、大澤聡氏と東浩紀氏のトークショーを思い起こしました。このトークショーの 1:35:00 から約20分間、言文一致についての話があります。そこで東氏は、英語などの言語と違い、日本語は書き言葉と話し言葉でモードが異なり、2つの言語を扱っていると考えるべきだと展開します。そして、書き言葉と話し言葉という二つの全く違う言語の中でできた伝統をどのように引き継いでいくかという問いに着地します。チャンネルマガジンは、このような日本語の条件のなかでの取り組みだと考えられるのではないでしょうか。

有料ですが、面白いトークショーなのでぜひ見てみてください。
[Watch 20150206_大澤聡+東浩紀 Online | Vimeo On Demand on Vimeo](https://vimeo.com/ondemand/genron20150206)

もう一つが、小林秀雄の以下の一節です。

> 人間は、その音声によって判断出来る、又それが一番確かだ、誰もが同じ意味の言葉を喋るが、喋る声の調子の差違は如何ともし難く、そこだけがその人の人格に関係して、本当の意味を現す、この調子が自在に捕えられる様になると、人間的な思想とは即ちそれを言う調子である
> 
> 小林秀雄「年齢」

「年齢」という作品のなかで、小林は本居宣長を引きつつ、書かれた歴史より話された歴史にこそ大事があると語り、話し言葉を重く見る小林の言語観が言明されます。

## システムコンセプト

以上のような背景から開発し、以下の2点をコア機能にして設計しました。

* ArticlePlayer : 記事 + 「トーク、ハイライト、コイン」
* with Discord : Discord API, Bot, OAuth 2.0

### ArticlePlayer

ArticlePlayer は主に3つの機能から構成されています。

1. トーク
2. ハイライト
3. コイン

(1) トークですが、こちらは音声データ (mp3) の再生機能です。Podcast サービスとほぼ同様です。再生位置の保存、特定の再生位置へのコメント (これはニコニコ動画などに類似) などをサポートしています。

(2) ハイライトですが、文字通りテキストに対してマークすることができます。一番わかりやすい先行例は、Medium だと思います。ハイライトを中心に、コメントしたり、質疑応答したりすることができるようにしました。

[How Highlights on Medium changed publishing forever | Productboard](https://www.productboard.com/blog/how-medium-highlights-feature-changed-publishing/)

(3) コインですが、ギフトまたはバウンティとして送ることができます。ギフトでは、拍手👏 などのいくつかのアニメーションを送ることができます。絵文字やスタンプなどと同様のものです。バウンティは、YouTube ライブでのスパチャによる AMA のようなイメージです。コメントに対して、質問したりより詳細な説明をリクエストすることができます。

![ss 2022-08-08 21.35.23](/docs/articles/ss%202022-08-08%2021.35.23.png)

### with Discord

Tparty では、Discord をベースにしていることもあり、Discord の OAuth2 での認証にしています。

また、管理人の友人ベースでスタートしたこともあり、招待管理として Discord アカウントと実名の紐付けが必要な点。

通知やコメント連動などは、Discord と接続しています。

今回の開発から、Discord API についての知見を得ることができたので、Discord に関連する開発案件については是非お問合せください。

## ビジネスモデル

まず断っておきたいのが、Tparty のために、システムを作りましたが、開発費用を受け取っているわけではありません。ダラフ社として、システムを企画・所有・運営しており、Tparty にはシステムをライセンスしています。なので、売上は Tparty からのライセンス料になります。Tparty 自体のビジネスモデルについては、Tparty のサイトに説明を譲ります。

* Tparty : コミュニティであり、政治経済勉強会
* ダラフ : システム提供している会社

ダラフとしては、今後のビジネスモデルについていくつか考えています。

1. Tparty と同じことをしたいコミュニティに提供
2. 既存のウェブメディアやブログサイトに埋め込めるような形での提供
3. カスタマイズ開発案件をメディア会社に提供
4. 新しいオープンプラットフォームとして公開

(1) については、現状だと Discord を利用していることが条件になりますが、可能だと思っています。コミュニティの運営において、情報発信は常に課題であり、コミュニティ内のコミュニケーションを促進することは重要です。システムとしては、サーバーを共有する SaaS 形式なのか、サーバーを分離するコンテナ形式なのかが選択肢かなと思っています。SaaS 形式で提供できた場合、[Substack](https://substack.com/) や [Shopify](https://www.shopify.com/) のような展開が想定できるかもしれません。

(2) については、先行する例として、[Disqus](https://disqus.com/) や [codoc](https://codoc.jp/) があります。codoc は WordPress のプラグインとして提供されており、ブログサイトに読み込むことが容易にできます。npm でパッケージを公開しつつ、ハイライトやコメント保存のデータベース部分で課金する形かなと思います。

(3) については、既存のウェブメディア、出版、雑誌、新聞などに対して、既存顧客基盤 (認証) の仕組みを調整した上で提供する方法です。こちらは開発案件のため、おそらく初期費用が発生してしまいますが、オープンメディアからクローズドメディアという流れの中で、コミュニティを作り、ロイヤリティの高い読者を育てるという点で有効性を示すことはできると思います。

(4) については、おそらくやりませんが選択肢の一つかとは思います。消極的な理由は [note](https://note.com/) や [Medium](https://medium.com/) があるなかでやる意味があるのか疑問な点と、そもそも現在の炎上文化やポリティカル・コレクトネスにおいて、オープンなテキストプラットフォームを運営することの困難さがあります。Deep Learning を活用して機械的にパトロールをすることも可能なのかもしれませんが、昨今の言論の複雑さは、機械的な複雑さよりも、政治的な複雑さのように感じます。軍事行動の可否も、フェイクニュースも、陰謀論も、オカルトやスピリチュアルも、どこまでがヘイトで、どこまでが言論の自由なのか判断することは困難です。一つの記事に削除申請や内容証明が届くたびに、運営本体がどちらの陣営なのか評価されることは長期的な運営において厳しいと感じています。

つらつらと書きましたが、現状ビジネスモデルは未定というのが正直なところになっています。かなりフラットにビジネスパートナー含めて募集しておりますので、ご興味ある方がいましたら、ご連絡いただけたら嬉しいです🙇‍♂️

## ビジョンと今後

勉強会で利用するシステムとして作ったという背景がある通り、コミュニティをより良くするシステムになるといいなと思っています。なので、自然と想定顧客は、コミュニティマネージャーなのかなと思ったりもします。また、言文一致の箇所の話にも近いのですが、開発者である私自身が長文テキストサイトが好きなこともあり、面白くて勉強になるテキストが増えて、著者にお金が還元される仕組みが作れると最高だなとは思っています。2022年現在は、動画は儲かるが、活字は儲からないという感じに見えるので、ライバー並みにライターが儲かるシステムに成長させることができれば本望かなと思っております。

今後も開発する中で考えたことについて書いてみたいと思っています。
最後に予定しているテキストのタイトル案。

* Podcast の物足りなさは、ライブでの作家とハガキ職人が不在な点
* Discord の主従逆転が露呈する NFT コミュニティ (主:ゲーム / 従:Discord からの転換)
* ルッキズムやねこ動画に対抗するために「テキスト+音声」はどうか


「テキストのための舞台装置」を開発しました

## Daraf (ダラフ)

[ダラフ](https://daraf.co.jp) は、ウェブシステムの開発会社として受託開発をおこなっています。また、いくつかの社内システムの開発を通して、最終的には「ソフトウェアの受発注システム」を目指していました。ただ最近は軌道修正し、自社の開発業務の効率化にフォーカスしています。社内システムである、合意形成に特化したタスク管理システム (コードネーム: Threelane)、同意書管理システム (コードネーム: Consentform) を運用することで生産性と再現性を上げる仕組みを作っています。また、UI管理システムについては、後述する通り Picturebook として切り出す形で一般公開を目指しています。

元々、開発ドキュメントは社内用として積極的に作っていたのですが、そろそろ公開できるぐらいには内容も固まってきたので、公開するための準備をしています。こちらも、ダラフのサイトから[公開](https://daraf.co.jp/docs)する予定です。

最近のお客様の事例および、自社企画のシステムの進捗を紹介します。

### 事例: StartPass (スタートパス)

[StartPass](https://startpass.jp) というスタートアップ向けの経営目標と経営アクションを管理するシステムを開発しました。StartPass は経営加速クラウドを標榜し、スタートアップが色々なステークホルダーを巻き込んで仕事をすることができるワークスペースを提供しています。経営目標に合わせてワークフォースを組むことができ、それによりスタートアップの業務実行力が上がる仕組みを作っています。

### 事例: Tparty (ティーパーティ)

[Tparty](https://tparty.xyz) というクローズドな政治経済勉強会で利用するコンテンツ兼コミュニティ管理システムを開発しました。Tparty は Discord で運営されているので、Discord に付属するシステムになっています。コンテンツは、チャンネルマガジンという「1万字 x 1時間」がコンセプトのメンバーによるエッセイと、チャンネルニュースという1週間の政治経済系ニュースをピックアップして紹介するものを公開しています。チャンネルマガジンは第1,3月曜日に号あたり3人が執筆しています。チャンネルニュースは毎週水曜日に公開しています。Tparty のシステムについては、詳細な内容を別の記事で書いたのでそちらを参照してください。

## Schoiz (スクイズ)

[スクイズ](https://schoiz.com) という検定業者向けのシステムを「検定DX」をコンセプトに開発しています。過去問販売からスタートし、会場試験/自宅試験/更新試験という3つの試験管理が可能なシステムになっています。システムは、Headless API として開発しており、Shopify の検定業者版ということもできます。ビジネスモデルは、5つの変数[^1]を組み合わせてお客様ごとに提案しています。免許管理/コミュニティ管理までを射程に展開しています。

[^1]: 1.初期費用 (initial)、2.定額利用料 (subscription)、3.販売手数料 (transaction)、4.従量課金 (pay-as-you-go)、5.乗務代行 (BPO)

## Picturebook (ピクチャーブック)

[Picturebook](https://picturebook.dev) というUI管理システムを開発しています。「Media x SaaS」、「Bridging GitHub and Figma」、「Non-verbal」の3つをコンセプトにしています。Picturebook は社内システムとして内部テスト中ですが、近いうちに公開できるという手応えのもと社内運用をしております。

## 最後に

なかなか進捗報告やご挨拶できていない方も多いですが、変わらず開発業務をしつつ、検定とUIについて考えています。お客様経由ではありますが、スタートアップ支援やコミュニティ管理 (および web3) についても学ぶ機会をいただいております。現場としていくつか気づきもありますので、ご興味を持った方とはお話しする機会をいただけたら嬉しく思います。数ヶ月後の報告では、開発進捗やコンセプトの話ではなく、数字の話ができる段階に進むことを目指して進めていきます。

2022年9月  
ダラフ代表 斉脇


(2022年9月) ダラフの取り組みについて

## DarafDocs とは

私たちはウェブ開発 (Web Development) を生業にしています。現場で仕事をするなかで、ウェブ開発という仕事をどのように捉えるか、どのようにパターン化することで効率化できるか、パターン化のためにどのようなメモが有用かを考えてきました。そしてそれは今も継続しています。

このドキュメントでは、私たちなりに考えたウェブ開発についてをまとめています。ウェブ開発というと、プログラミングが思い浮かぶかもしれませんが、それだけに止まらず、受発注がどのように行われるか、開発プロセスはどのように制御されるかついても扱っています。

ドキュメントは大枠として、全体像、パターン、メモの三回層で整理しています。ブログ形式で記述されているものから、Wiki 形式で記述されているものまで、情報の特性に合わせて管理されています。また、それぞれのトピックについての俯瞰図を用意することで、抽象と具体のピントが合うようにし、全体像を見失うことなく情報を確認できるようにしています。

システム開発は複雑ですが、盤面を把握することで選択肢を管理することができます。ビジネスの羅針盤として活用されることを目指しています。

![](/docs/articles/index.png)

## 上層

「**プロセス**」は、一つの会社内の活動です。一つの会社で発生し、対処するべきイベントと言い換えることもできます。基本的にはウェブシステムの開発プロセスを扱いますが、その拡張としての起業プロセスも見ていきます。プロセスを整理する目的は、事前にどんなことが起こるのか予測するためです。プロセスを整理したからといって、うまくやれるわけではありませんが、自分たちがどの程度複雑なことに取り組んでいるか認識を新たにすることができます。そして、その複雑さがプロセスを同時に取り組まなくてはいけない、同時性にあるということに気づきます。同時性とどの程度向き合うか、どのように避けるかについて考えるきっかけを与えてくれるでしょう。

「**受発注**」は、会社間の取引を考えます。システム開発では、発注者と受注者でシステムへの見識の非対称性が発生します。結果的に会社間の取引で、意思疎通に齟齬が生まれます。それらを回避するために、システム開発の全体像を可視化します。全体を通して、どのように合意形成を取るのかを考えています。システム開発そのものをパターン化し、カタログ化することに挑戦していますが、その目的は合意形成のためです。見識の非対称性の解決策としてカタログ化、サービス化を推し進めています。

「**プロセス**」は社内に閉じて話を進めるのに対して、「**受発注**」は会社間の取引の話をします。

## 中層

中層では、ウェブシステムを開発するにあたり、よく発生するパターンを整理します。典型的で頻出のパターンを優先的に扱いつつ、できる限り全体をカバーするよう善処しています。いつもどのような仕様書を作っているか、もしくは仕様書を作成する上で基本的に考えているか。どのシステムでも繰り返し実装する機能。ウェブシステムのインターフェースの制約、インターフェースを作る上でのデザイン手法。これらについてパターンを整理しました。

本質的には、システムごとに、どんな特徴のデータを、どのように操作するか考えることにつきますが、少し俯瞰してウェブシステムそのものの特徴を考えることで、特定システムを比較分析することができるようになるでしょう。パターンの組み合わせにより、オリジナルなシステムを構築するイメージを共有します。

## 下層

下層では、具体的なメモを扱います。メモの蓄積により、パターン化や全体像の構築につながります。ソースコード、専門用語の解説と用語間のつながり、カテゴライズが一概にできない内容のエッセイなども公開しています。

全体像がわかり、パターンがわかったとしても、具体的な引き出しがなければ形骸化してしまいます。上層と中層は下層からノイズを消したものです。抽象と具体を行き来できるように気を使いつつ、実際に現場から出たメモを扱います。真偽不確かで、バイアスのある内容もありますが、現場のリアルとして公開することに意味があると考えています。この点は不誠実かもしれませんが、下層の情報の真偽は各々で判断してください。
