Tweet Driven Development(つぶやき駆動開発) に最近ハマっているので、まとめてみました。

TwDD 概要

TwDD とは

TwDD(Tweet Driven Development) とは、つぶやき(Tweet)により開発を駆動させるという考え方です。

TDD(テスト駆動開発)や TiDD(チケット駆動開発)のような「ザ・手法」というよりは、もうちょっと緩い、あえて言うなら「考え方」を表したものです。類似したニュアンスを持つ駆動開発を挙げると、以下になると思います。

つぶやくとはどういうこと？

TwDD における「つぶやく」とは、ブツブツ声に出してつぶやくことではなく つぶやきを書く ということです。

つぶやく先はインターネットではなく 組織内 になります。部署、チーム、コミュニティ関係者限定のシステム上でつぶやくというイメージです。

つぶやきというと Twitter を連想しますが、TwDD では使いません。使うのは主にローカルのテキスト、Wiki、チャット、VCS(バージョン管理システム)などです。

TwDD のレベル

TwDD には適用範囲やつぶやく人数に応じたレベルがあります。

レベル1「Private Solo」: 完全なる自分用。自分だけがつぶやく＆自分のみ見れる
レベル2「Public Solo」: 自分だけつぶやきマン。自分だけがつぶやく＆他人も見れる
レベル3「Public Multi」: つぶやきマンがちらほらいる状態。何人かがつぶやく
レベル4「Public Everyone」: メンバー全員がつぶやく

個人的な便宜を図りたいだけなら Private Solo で十分です。

みんなに言いたいことやアピールしたいことがあるならレベル2の Public Solo を使います。

先進的な組織であれば、レベル2からレベルアップして Public Multi となれるかもしれません。賑やかで楽しい場が生まれると思います(筆者はレベル2止まりなので想像です)。

レベル4については理想論というか枠だけ書きました。実態は想像もつきません。

各レベルについて

各レベルについてざっくりと解説していきます。

レベル1: Private Solo

Private Solo は 自分しか見ない つぶやきを書いていく TwDD です。行うことは 作業過程や思考過程をつぶやくこと です。

効果

頭の中でモヤモヤしている思考を、文章化という作業を通じて整理できる
「あ、これ、前に調べたぞ。どこだっけ」にすぐに対応できる(過去のつぶやきを検索すればよい)
自分がいつ、何をしたのかが後になってもわかる(振り返り等に重宝)
批判、不満や愚痴を吐き出してスッキリする(うっかり相手にぶつけてしまうのを防ぐ)

メモや日記やはけ口として汎用的に使えます。

開発らしく使いたいなら、開発ネタをたくさんつぶやくと良いでしょう。筆者はアイデアや実装方針、調べ事のメモなど何でもつぶやいてます。

コツ

Private Solo を実現する上で重要なのは以下です。

操作性 …… 出来るだけ簡単につぶやけること
一覧性 …… つぶやきを簡単に見返せること
検索性 …… つぶやきを簡単に検索できること
秘匿性 …… つぶやきを自分以外の誰にも見られないこと

まず自分用なのでストレス無く使える(つぶやける、見返せる、検索できる)ことが重要です。Twitter、チャット、Wiki などを使ってもよいですが、ブラウザや API を介すると遅い・重いので、できればローカルのテキストファイルを直接編集するのが望ましいです。

それからもう一つ、特に気を付けたいのが 秘匿性 です。「間違えてみんなが見てるチャットに書いちゃった」なんてことにならないようにしましょう。筆者は Slack で Private Solo をしていた時にやらかしたことがあります。この点も、ローカルに書くようにすれば回避できます。

サンプル

サンプルとして筆者の運用例を紹介します。仕組みの部分は GitHub にも置いてみました。

GitHub に TwDD 用のプライベートリポジトリを作って、つぶやきを書きまくってます。

操作の流れはこんな感じです。

(1) Win + i キーを押すとテキストファイルが開かれる
(2) つぶやきを書く
(3) 終わったら上書き保存して閉じる(これで tweets.md に日付時刻付きでつぶやきが追加される)
(4) Win + Enter キーで push する(毎回やるとだるいのでテキトーなタイミングで)

ポイントは以下のとおり。

なるべく簡単につぶやけるようにする(Windows 限定ですが AutoHotkey、バッチファイル、Python を活用)
簡単に検索できるようにする(Plain Text なので Grep が簡単)
見易く見返せるようにする(Markdown ファイルなので GitHub 上で HTML で見れる)

今では声に出してつぶやくかのように自然につぶやけます。もう手放せません。

今まで Wiki とかチャットとかメモツールとか色々試してきましたが、筆者は今のところこれが一番しっくり来ています。

レベル2: Public Solo

Private Solo が自分しか見ないつぶやきだったのに対し、Public Solo では 他人に見られることを前提として つぶやきを書きます。

ポエム駆動開発と似ているかもしれません。違うのは、書く単位がつぶやき単位であるところと、書いているのがみんなではなく自分だけなところです。

具体的を挙げると、こんな感じです。

チャットシステム Slack にて tweet-stakiran という部屋を作り、つぶやきを書く
Wikiシステム Mediawiki にて tweet_stakiran というページを作り、つぶやきを書く
GitHub Enterprise にて tweet_stakiran という公開リポジトリを作り、tweets.md を配置し、そこにつぶやきを書く

要するに みんなが使っているシステム上に、個人用のつぶやきスペースをつくる ということです。

目的

Public Solo の目的は 自分のつぶやきをみんなに読んでもらう(ことで何かを期待する) ことです。何を期待するかは様々でしょうが、たとえば以下があります。

自分の強み/弱み/性格をさらけ出して、普段から配慮してもらうことを期待する
開発に対する自分の意見を挑発的に主張し、読者(チームメンバーや上司)を刺激させることで、物議を醸し出させる
気軽につぶやくという前例をつくることで、チームの雰囲気が緩やかになることを期待する

Q: 個人のつぶやきなんて読んでもらえるの？

最初のうちは読んでもらえます。なぜなら 浮いちゃうからです。

チャットにせよ Wiki にせよリポジトリにせよ、Twitter みたいなことを始める奴がいたら、そりゃ浮きます。みんな見ます。何なら(口づてで広まって)普段見ない人まで見ます。

Public Solo は、このような「浮いちゃう」「目立つ」性質を利用して、みんなに読ませたいことを読ませ、伝えることを目論む活動とも言えます。

読み続けてもらうために

ただし読んでもらえるのは最初のうちです。飽きられたり、呆れられたりすると読んでもらえなくなります。そもそも「他人のことを知りたがらない人」は見向きもしません。それでは Public Solo を書く意味がないというものです。読み続けてもらうための工夫が必要になります。

……なんだかアクセス数を稼がんとするブロガーさんみたいですね。あながち間違ってないです。 どうやったらみんなが見てくれるのか、リピーターになってくれるのか、を考えて取り組む ということです。

やり方は色々ありますが、簡単なのは

(みんなわかっているけど口に出さないような)本音を書く
宗教論争ネタで自分の宗教を書く
批判ネタを書く
- もちろん社会人なので配慮は必要です
- 例1: 具体的な名指しはしない
- 例2:「特定個人を非難するものでありませんが」などクッション言葉を適宜活用する
社内事情(社内通知とか情報通社員から聞いた噂話とか)をスピーディーに展開する

あたりでしょうか。

なんだか難しそうですが、ブログやSNSを使ったアクセス数集めほど難しくはないです。というのも、社内という閉じられた環境ゆえに、よほどつまらないか不快にさせない限りは、なんだかんだチラ見する人が多いからです。

筆者が社内 Wiki で試した時はトップページよりもアクセス数が多く、何ならアクセス第一位のページになることもありました。

Q: 口頭で伝えればいいんじゃないの？

はい。口頭で伝えられる、あるいは伝えて通じるのならそれに越したことはないでしょう。

しかし、口頭だけで済むとは限りません。相手も忙しいので、自分から尋ねる形式のコミュニケーションだと、どうしても伝えられる時間が限られます。かといって何度もしつこく主張すると、今度は煙たがられてしまい、まともに相手されなくなります。

TwDD を使うと、自分から尋ねるのではなく 相手が好きなタイミングで自分の意見を読む という相手ペースの伝達を実現できます。直接尋ねるやり方よりも即行性は劣りますが、長期的に見ると伝えやすいです。

もちろん「つぶやきなんていちいち読んでられるか」という人もいますが、一方でちらちら覗く人がいて、そういう人はちゃんと読んでます。そういう人から、読んでない人へと口づてで伝わったりもします。

要するに TwDD は つぶやきをみんなに読んでもらうことで「少しずつ」影響を与えていく やり方であり、口頭とは異なる「主張のアプローチ」です。

レベル3: Public Multi

Public Multi は、 つぶやいている人が複数人存在する 状態を指します。

「Slack（チャット）で雑談してるけど、それとは違うの？」

違います。Public Multi は、組織内限定の Twitter アカウントが「つぶやいている人の数」だけ存在するようなものです。各個人のつぶやきスペースが複数存在するとも言えます。チャットの「部屋」のように複数人がつぶやける場所だと、どうしても空気を読んでしまったり遠慮してしまったりする上、みんなに通知も行ってしまうので、実はかなりつぶやきづらいです。

反面、個人のつぶやきスペースなら遠慮なくつぶやけます。個人のつぶやきスペースだからこそ、つぶやかれる言葉があります。それを引き出せるのは TwDD だけです。

残念ながら筆者はレベル3に片足を踏み入れようとする段階でしかないので、これ以上詳しいことは書けません。

レベル4: Public Everyone

Public Everyoneは、チーム内・部署内のみんながつぶやいている状態 を指します。

レベル3すらままならない筆者には想像も付きません

TwDD システムの検討

TwDD の各レベルについて書きました。次は「どこでつぶやくか」の「どこ」に相当する話をします。

TwDD は 既存のシステム上で実施します。たとえば Slack によるチャットでコミュニケーションを取っているなら Slack 上で行うことになりますし、Wiki を積極的に使っているなら Wiki 上で行うことになるでしょう。なぜって つぶやき用のシステムを新しく作ったところで誰も見てくれない からです。ところが、既存のシステムにしれっとつぶやきスペースを作っておくと、みんなもしれっと見に来ます。

さて、本節では主要なシステムに対して、TwDD を実施する際のメリット、デメリット、その他性質などをまとめます。

ローカルのテキストファイル

ローカルにテキストファイルを置いて、そこにつぶやきを書いていくという最もシンプルなやり方です。

これはレベル1「Private Solo」で用いるシステムです。

メリット・デメリット
- 手軽に実現できる（何なら tweet.txt に一行一つぶやきで書き殴るだけでもOK）
- 軽い、速い、管理が容易
- 素早くつぶやく、見易く見返すなど使いやすさを求めたいならスクリプト等で多少作り込みが必要
- コミュニケーション要素は無い

モダンチャット(Slack, Mattermost, Rocket.Chatなど)

モダンチャットでも TwDD はできます。#tweet-username みたいにusername 用のつぶやき部屋を作って、そこにつぶやきます。

レベル1「Private Solo」としても使えないことはないですが、誤投稿しやすいですし、過去のつぶやきを読み返しづらいので、オススメしません。レベル2「Public Solo」用途で使うことになるでしょう。

メリット・デメリット
- チャット感覚で気軽に書き込める
- 貼り付けた URL が自動展開される
- Emoji、装飾、コードハイライトなどチャットシステムがサポートする表記も使える
- リアクションを付けられるため反応を得やすい
- つぶやく時にいちいちつぶやき用の部屋を開かないといけないので負担(コンテキストスイッチング)が大きい
- 多数のつぶやきを読むのがしんどい
  - 過去つぶやきは上にスクロールしてリロードしないと見えない
  - そもそも重い

なお、つぶやく際のコンテキストスイッチングについては、「REST API を叩いてつぶやきを投稿する」スクリプトを作って、それを簡単に呼び出せるようにすると良いでしょう。

Wiki(Mediawiki, Pukiwiki, あるいは Redmine や Trac など)

Wiki も馴染み深いシステムだと思います。TweetUsername みたいに「つぶやき用のページ」を作って、そこにつぶやくことで TwDD を行います。

Wiki には「自分だけ閲覧可能」にする機能が無いため、 Private Solo はできません。必然的に Public Solo になります。

Wiki の性質ですが、基本的にモダンチャットと相反します。

メリット・デメリット
- モダンチャットよりも軽い
- モダンチャットみたいにリロードせずともつぶやきを読んでいける
- つぶやく行為がだるい(いちいちページ編集が必要)
- 「Wiki全体の更新履歴」を乱してしまう
  - 特に更新内容を全て記録する Mediawiki は最悪で、50回つぶやいたら50個分の更新履歴がずらりと並ぶ。もはや更新履歴荒らし

つぶやく行為のだるさについては、Wiki システムによっては省力化できる余地があります。ここでは Pukiwiki と Mediawiki について例を挙げます。

Pukiwiki

Pukiwiki では各ページはファイルで保存されているので、そのファイルに直接書き込むスクリプトをつくれば良いです。まあ Pukiwiki 配置サーバへのアクセス権があればの話ですが。

ちなみに、Pukiwiki は文字コードが EUC-JP だったり、ファイル名が独自にエンコーディングされていたりするので地味に手こずります。

Mediawiki

Mediawiki ですが、REST API がサポートされているのでこれを使います。

筆者が使っている API ラッパー(Pythonスクリプト)は汚すぎるので載せませんが、大まかなアプローチは、

API:Login で編集トークンをゲット
API:Edit でつぶやき用ページにつぶやきを追加する

という感じになると思います。

VCS(GitHub, GitLab, GitBucketなど)

バージョン管理システム上でも TwDD を実現できます。TwDD 用のリポジトリを作り、つぶやきを書く用の Markdown ファイルを置いて、そこにつぶやいていく＆適当なタイミングで Commit や Push する、というやり方になります。

個人的に最も優秀な TwDD 方法だと思っています。最初に挙げた「ローカルのテキストファイル」案だと Private Solo しかできませんが、それをリポジトリで公開すれば Public Solo も可能です。

メリット・デメリット
- ローカルでテキストファイルをいじれるので軽い、速い、自由
- Markdown を HTML で表示してくれるので、ただのテキストよりも読みやすい
- 素早くつぶやく、見易く見返すなど使いやすさを求めたいならスクリプト等で多少作り込みが必要
- VSCという性質上、非エンジニアに読まれづらい
  - 「黒い画面が怖い」じゃないですが、Wiki やチャットと比べるとそういう雰囲気があります
- 他の人がコメントを書きづらい(のでコミュニケーションが生まれづらい)
  - チャットなら入室すれば書けますし、Wiki でもコメント書きたい場所のそばに追記することで書けます

ただし、VCS というエンジニア向けの UI を使う以上、どうしても非エンジニアの方からは読まれづらくなります。

おわりに

TwDD について紹介してみました。何かの参考になれば幸いです。