Tantiny 、ろくにドキュメントを読んでいなかったので知らなかったのだけど、リアルタイムで検索インデックスの更新ができるようだった。これまで一時間に一度バッチ処理を動かして、更新された記事があればすべての記事を読み直してインデックスを更新するような富豪的なことをやっていた。アホだった。
プレーンテキスト Markdown 時代の終焉
なぜ Day One は Markdown を捨てたのか
Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。
自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。
ひとむかし前の WYSIWYG は最悪で、Word での文書作成や Google Docs にも良い思い出がない。とにかく文章が書きにくい不自由なツールだった。
WYSIWYG 勢が力をつけてきている
一方で、お洒落な UI で話題になった Notion を使ってみると Markdown の要素を残した WYSIWYG だった。 Dropbox Paper も Markdown 風 WYSIWYG 、 Slack も最近段階的に WYSIWYG 化しつつある。
どうやら WYSIWYG の波が到来しつつあるようだ。
なぜ WYSIWYG なのか
Markdown は HTML を書いたことがない人には難しい
エンジニアやデザイナーなど、 HTML を理解している人からしたら Markdown は簡単だが、そうでない人には難しい。組織内に非エンジニア・非デザイナー（ HTML を書けない人）が増えてくると、途端に社内ドキュメント管理ツールがカオス（ ・ や全角空白 で装飾された文書が氾濫）になる。
プレーンな Markdown では、リストの概念や文書を構造化するということに対する理解がないと読みやすい文書は書けない。プレーンテキストベースの Markdown には読みやすく構造化された文書を書けるようになることを助ける仕組みが欠落している。
普通の人が Web 系のように働きはじめている
Slack は DAU が 1200 万を超えたらしい。もはやエンジニアだけのツールだけではなくなってきているようだ。
チャット、 Wiki 、社内ブログ、タスク管理ツールなど、文章を入力させる系の SaaS が徐々に IT 産業以外の職場でも普及しつつあり、そのような環境でも受け入れられやすいようにプレーンテキストの Markdown ではなく、 Markdown 風の WYSIWYG を入れてきているのだと推察する。
普通の人でもぐちゃぐちゃにならないように文書を書くための仕組みとして WYSIWYG が注目され直しているのだろう。
抑制された WYSIWYG
Dropbox Paper や Notion の UI はシンプルでクール
MS Word や Google Docs など昔ながらの WYSIWYG はボタンが多く、出来ることが多すぎて逆に不自由だと感じる場面が多かった。一方で Dropbox Paper や Notion の WYSIWYG には悪い印象がない。Paper や Notion の WYSIWYG はできることが限定されていて、制限されているがゆえの使いやすさがある。 MS Word のような大小の文字が入り乱れ、文字が七色に輝いているような文書は書けない。
ぐちゃぐちゃな文書を書かせない仕組み
Paper や Notion はアウトライナーを WYSIWYG 化したような感じで、文章を並べ替えたり入れ子にしたりできる。
文章を構造化することに慣れていない人でも、まぁまぁ読みやすい構造化された文章を書ける、あるいは構造化された文章の書き方を学べるようになっている。
WYSIWYG 化で失うもの
文書のポータビリティー
WYSIWYG の前提として、下書きする場所と最終的な出力をする場所が同じだということが挙げられる。でないと独自の装飾フォーマットが使えない。
Notion で書いた文書は Notion でしか読めないし、 Dropbox Paper で書いた文書は Dropbox Paper でしか読めない。 Markdown で書いたテーブルならほかのツールに取り込めるが、 Notion で書いたテーブルは Notion でしか使えない。入れ子にしたり装飾したりする便利な機能も Notion で使うからこそ約束されているものだ。その場所でしかその書き方はできない。
だから、ローカルのお気に入りのテキストエディター（ Vim など）で書いたあとにクリップボードにコピーしてブラウザーに貼り付ける、という使い方が出来なくなってしまう。
いまこの文書は Notion を使って書いているが、プレーンテキストでコピーできない2のでブログにこの記事を投稿するときは一旦 Markdown フォーマットで書き出して Vim で開き、コピーしてブラウザーのブログ記事入力欄にペーストする必要がある。
冒頭に挙げた Day One も Markdown で文章をコピーすることができなくなった。文書作成・管理プラットフォームとして考えたときにはこれは正しい戦略で、 Markdown ではない独自のフォーマットで文書を書かせることでユーザーをロックインできる。ひとたび Notion や Dropbox Paper に文章を書きため、その独自フォーマットに慣れてしまえば、データと記法の両方によってロックインされてしまうわけだ。
Notion や Dropbox Paper はよくできていると思う。特に Notion は WorkFlowy のようなアウトライナー的な側面を持ち、いわゆる「ファイルの壁」問題を解決しつつ Markdown のサポート、画像の埋め込みや表の挿入などにも対応している。良いなと思う反面、一人のインターネットユーザーとしては、オープンかつ自由なフォーマットで書くことができる Markdown がやっぱり好きだとも思う。
人のふんどしで相撲をとる
仕事面で 2017 年を振り返ると、いろいろやったけど自分でなんか作ったというのはほとんどない。 人のふんどしで相撲をとっていた一年（転職してからは半年強）だと言える。SaaS として提供されているツールを導入したり、 OSS の分析ツールを導入・構築したり、会社の仕組みを調整したりしてただけだった。各ライブラリを作ってくれた人には感謝しかない 🙏🏻
組織方面
- チーム横断の定例 MTG 働きかけ
- 人が増えて「あの人何やってるかわからない」「仕事を横からいきなり依頼される」などの問題が出てきたため、チーム横断の定例ミーティングを開催してお互いの状況を確認したり依頼しそうなことがあれば前もって共有するように
- 全体ミーティングフォーマット整え＆司会業
- かつては社長が考えていることを聞くだけの場だったが、チームごとに資料を作ってみんなで発表し、議論をする場に変えた
- Slack 導入
- Slack に変えるまでも別のチャットツール使ってたけど、平アカウントでは大したことできず、窮屈な感じがした
- Slack は平アカウントでも外部ツール連携したり API 使ってなんかやったりできて便利
- ベンチャーには平社員でも必要なことをやれるようなシステムの方が向いてると思う。 Slack はデザインだけじゃなくてそういうところが優れている。フラットで雰囲気が明るい。使うのが楽しくなる。
- Kibela 導入
- Wiki と Blog 、 Board （ Group ）の概念がちょうどよい。 Qiita:Team で厳しかったところが解消されている。
- Kibela 導入以前、情報共有は Issue Tracker に何でも書いてる感じだったが、 Issue Tracker は Issue Tracker なので close することができない問題を扱うのに向いていない
- タスクには落とし込めないけど社内で見解を表明しておきたい事柄を社内ブログに書いて問題意識をみんなと共有する文化を構築できた
- Kibela は PlantUML で図を書けるのがとにかくすばらしい。込み入った処理フローをシーケンス図にすることで設計・実装がはかどる。
- HRT について説く
- OKR 導入
- OKR を設定してやっていきましょうという風にした
- とはいえ自分は HR の専門家ではないのでちゃんと運用して行くにはそういう人に入ってもらわないと厳しいと思ってる
- OKR を設定してやっていきましょうという風にした
エンジニアリング方面
- t_wada （テスト文化根付かせ）業
- No Test, No Merge
- CI が回る仕組み構築業
- テストコードは別の人が書いてたけど回せてなくて fail しっ放しになってたので気合いで通るようにして CircleCI で Pull Request ごとにビルドするようにした✌🏻
- Pull Request テンプレート導入
- どんな問題を解決する Pull Request なのか、何をやったのか、完了条件を明記する✅
- Pull Request レビューフォーマット提案
- Must, Should, IMO などラベルを付けてレビューをするように
- すべてのレビューに馬鹿正直に答えてたら時間がかかってしまうのでレビュー内容にも優先順位を付けてレビューする
- pull request を利用した開発ワークフロー // Speaker Deck
- Must, Should, IMO などラベルを付けてレビューをするように
- gitignore されていた Gemfile.lock をリポジトリに突っ込み業
- Gemfile でバージョンが固定されてた😢
- Embulk で分析用データ書き出し業
- autodoc で API ドキュメント自動生成の仕組み構築
- Google Spreadsheet による手作業更新からテストコードとビルドによって自動生成される仕組みへ（📝 CircleCI と autodoc で Rails API のドキュメントを自動更新）
- Git Flow から GitHub Flow へブランチ戦略変更
- 1日に何回もデプロイするような製品はこっちの方が向いてる
- Rubocop 導入＆ .rubocop.yml 番人業
- 👮🏻♂️
- CircleCI から勝手に deploy される仕組み導入
- 社内確認環境には master ブランチにマージされたタイミングで勝手にデプロイされる（🏭 Docker を Production 投入するメリットを考える）
- F/E の人に聞かれて「あ、デプロイしてませんでした🤷🏻♂️」がなくなる
- docker-compose 導入
- Docker は使われてたがクラスターの管理は手運用だったので docker-compose 使うようにした
- AWS ECS 導入
- 自分のブログで結構金かけて検証した甲斐があった（🚨 Docker & ECS 化追跡 24 時）
- 社内 Gyazo 導入
- Gyazo る文化がなかったので
- サーバーサイドは yuya-takeyama さんのやつをフォークして使ってる
- Redash 導入
- 経営陣しか数値に関心を持ってなかったので全員が見るように毎朝 Slack に KPI を通知するようにした
- 複雑なクエリを組んでテーブルごとに値を集計しているだけでは見えてこない値を追えるようになった
- 独自に KPI/KGI を設定して Growth Hack に取り組むエンジニアも
- リードレプリカ作ってデータ分析がやりやすくなる仕組み導入
- RDS で Multi AZ にはなっていたがリードレプリカがなく重いクエリを投げられなかった
- 複雑な JOIN クエリも書けるようになりデータ分析し放題
- 来年は BigQuery とかも使えるようにしてさらに分析が捗るようにしたい
- Itamae でプロビジョニング（ Linux アカウントの管理）
- Itamae 一発で Linux アカウント追加できるようにしてサーバーサイドのエンジニアしか DB にクエリを投げられない状況を改善
- cronbot 導入
- 他人が作ったスケジュールも更新できて便利
- KPI 通知は redashbot と cronbot を組み合わせて実現
- iOS と Android のダウンロード数自動取得
- iOS 側はタイムゾーンがずれる、 Android 側は更新が異常に遅いという問題があるものの、ある程度の目安となる数値が毎朝自動で Slack に通知されるように
- お問い合わせがあったときに Slack に通知する仕組み導入
- お問い合わせはカスタマーサポートの人が一手に引き受ける感じだったけどみんなが関心を持って見るようになった
- カスタマーサポートの人からエスカレーションされる前にエンジニアが回答
- 不具合あったときはいち早く対応可能に
- Ruby app の前段に CloudFront 導入
- app サーバーへのリクエストが半減
- Nginx でキャッシュしきれてなかった静的ファイルを CloudFront でキャッシュするようになり爆速に
- サイト全面 HTTPS 化
- CSS/JS が並列で配信されるようになり爆速に
自分でまともな OSS を作れないことにコンプレックスを感じていた時期もあったが（ OSS コミュニティでの活動が評価軸となるような職場では全然評価されない）、自分が作れなくても他の人が作ってくれるので、それをいかに組み合わせて有効活用し、価値を生み出せるかに注力すればいいかなぁと思うようになった。
もちろん、 OSS 使っててバグを見つけたり不便なところあったら改善する Pull Request なんかは出していきたいと思ってる。ただ自分は頭がよくないし、抽象的な思考は苦手で個別具体的なコードを書くことしかできないので、自分で OSS を生み出すことは諦めて個別具体的な事象に特化してやっていく方が自分的にも世の中的にも幸せだよね、という風に割り切れるようになった。
こういう割り切りができるようになったのは Kaizen Platform で仕事する機会を得たからだよなぁと思う。 OSS への考え方に限らず、コードを書く部分以外で組織を変革したりだとかオペレーションの仕組みを変えたりだとかは全部 Kaizen Platform で学んだ気がする。1年11ヶ月と短い期間だったけれど、いまの自分の血となり肉となっていると思う。
Kaizen を辞めたときの記事で以下のように書いてたけど、いまのところ失敗を糧にしていい方向に向かってるのではないかと思う。
Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。
というわけでいまは YAMAP という会社で働いています。元同僚の pyama86 さんに比べたら知名度では全然負けててミジンコみたいなもんだと思うけど、そのうち逆転できるようにプロダクトの完成度を高めていって pyama86 さんの方が YAMAP のパクりであるような雰囲気を醸成していきたい。今後ともよろしくお願いいたします🙏🏻