portal shit!

なぜ Day One は Markdown を捨てたのか

Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。

Day One がクソになった

Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー...

portalshit.net

自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する¹という戦略は疑問だった。

ひと前の WYSIWYG は最悪で、Word での文書作成や Google Docs にも良い思い出がない。とにかく文章が書きにくい不自由なツールだった。

WYSIWYG 勢が力をつけてきている

一方で、お洒落な UI で話題になった Notion を使ってみると Markdown の要素を残した WYSIWYG だった。 Dropbox Paper も Markdown 風 WYSIWYG 、 Slack も最近段階的に WYSIWYG 化しつつある。

Changes to message objects on the way to support WYSIWYG

New features, recent happenstance, and happenings across the Slack platform

api.slack.com

どうやら WYSIWYG の波が到来しつつあるようだ。

なぜ WYSIWYG なのか

Markdown は HTML を書いたことがない人には難しい

エンジニアやデザイナーなど、 HTML を理解している人からしたら Markdown は簡単だが、そうでない人には難しい。組織内に非エンジニア・非デザイナー（ HTML を書けない人）が増えてくると、途端に社内ドキュメント管理ツールがカオス（ ・ や全角空白 　 で装飾された文書が氾濫）になる。

プレーンな Markdown では、リストの概念や文書を構造化するということに対する理解がないと読みやすい文書は書けない。プレーンテキストベースの Markdown には読みやすく構造化された文書を書けるようになることを助ける仕組みが欠落している。

普通の人が Web 系のように働きはじめている

Slack は DAU が 1200 万を超えたらしい。もはやエンジニアだけのツールだけではなくなってきているようだ。

大切なのは DAU の「U」! 生産性向上の鍵は真のエンゲージメント - Several People Are Typing

この記事を英語 (英国)、英語 (米国)、スペイン語 (スペイン)、スペイン語 (ラテンアメリカ)、ドイツ語、フランス語、ポルトガル語 (ブラジル) で読む。 今、職場でのコラボレーション方法に世代交代が起きています。コミュニケーションはメールからチャンネルへの移行が進み、プラットフォームでも、業務ツール間の連携が弱いレガシースイートから、連携しやすくカスタマイズ可能な新しい製品への乗り換えが進んでいます。2019 年 9 月、Slack の日間アクティブユーザー数が遂に 1,200 万人を突破し、前年比で約 37% の増加。さらに、有料プランの利用数は 600 万を超え、Slack を日々アクティブに愛用してくれているユーザーは急速に増え続けています。 DAU (日間アクティブユーザー数) はよく話題に上る指標ですが、実際に重要なのは何でしょうか？私たちが最も重要視しているのは DAU の「U」、つまり実際にどれだけ「Use = 使用」されているかです。そして「エンゲージメント」 こそが Slack がその真価を発揮する鍵であると考えます。私たちは、Slack によって皆さんのより良い働き方へ貢献したいと日々開発に取り組んでいますが、どんなに便利なツールでもそれを実際に活用してもらえなければ何の効果もありません。そういう点においても、Slack のエンゲージメント促進に大きく貢献してくれる、Slack プラットフォームでアプリやインテグレーションを構築している皆さんには大変感謝をしています！Slack とともに Slack 開発者コミュニティも成長し、このエンゲージメントの糧となる豊かなエコシステムを創出しています。現在、Slack のインテグレーションとアプリの構築に従事する開発者向けの年次カンファレンスである Spec に向けて準備を進めており、このコミュニティをベストな方法でサポートすることに集中的に取り組んでいます。 使われてこそ、良いコラボレーションツール Slack を仕事に活用する全世界数百万人のユーザーの皆さんのため、私たち Slack と 1 日あたり約 60 万人にのぼるアクティブな登録開発者の皆さんが、Slack を活用したよりよい方法を日々創りだしてしています。それにより様々な企業の間で濃厚かつ持続的なエンゲージメントが生み出され、つながりが希薄な他の方法から Slack への移行が進み、使い続けられる存在になっています。 米国を拠点とするユーザーへのアンケートでは、87% のユーザーが Slack により組織内のコミュニケーションとコラボレーションが向上したと答えました。有料プランのお客様の場合、ユーザーは 1 …

slackhq.com

チャット、 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 を使って書いているが、プレーンテキストでコピーできない²のでブログにこの記事を投稿するときは一旦 Markdown フォーマットで書き出して Vim で開き、コピーしてブラウザーのブログ記事入力欄にペーストする必要がある。

冒頭に挙げた Day One も Markdown で文章をコピーすることができなくなった。文書作成・管理プラットフォームとして考えたときにはこれは正しい戦略で、 Markdown ではない独自のフォーマットで文書を書かせることでユーザーをロックインできる。ひとたび Notion や Dropbox Paper に文章を書きため、その独自フォーマットに慣れてしまえば、データと記法の両方によってロックインされてしまうわけだ。

Notion や Dropbox Paper はよくできていると思う。特に Notion は WorkFlowy のようなアウトライナー的な側面を持ち、いわゆる「ファイルの壁」問題を解決しつつ Markdown のサポート、画像の埋め込みや表の挿入などにも対応している。良いなと思う反面、一人のインターネットユーザーとしては、オープンかつ自由なフォーマットで書くことができる Markdown がやっぱり好きだとも思う。

Memolist.vim の保存先を Dropbox にする運用を長年続けてきたが、 iOS の Markdown エディターの iA Writer で編集時にファイルが無限複製されるという問題があることや、最近のポリシー変更で Dropbox を無料で使い続けるのは難しそうかつお金を払うにしてもプランが高め（最安でも ¥1,500 / 月で 2TB まで使えるプランしかない）で個人では使いづらそうなので iCloud Drive を代わりに使ってみることにした。 iCloud は今のところ無料で使ってるが 50GB 使えるプランでも月額 ¥130 なので個人で使いやすい。 iCloud Drive は Windows や Linux からは使えないが、 Linux デスクトップはもう何年も使ってないし、 Mac と iPhone にロックインされた生活に不満はないので無問題。

移行の手始めにまずは iCloud Drive にターミナルでアクセスしようとするが、 cd ~/iCloud\ Drive などではたどり着けない。以下の記事を読んで調べた。

ターミナルからiCloud driveに移動する方法 - Qiita

#iCloudを使う理由 職場でDropBoxを使っていて、クラウドで保存するのに慣れていた。 私用ファイルの保存場所としてiCloudを使ってみる。 #iCloud Driveはどこにあるのか やりたかったことは、 `pwd i...

qiita.com

パスは ~/Library/Mobile\ Documents/com~apple~CloudDocs で良いみたい。

~/Dropbox/memolist ディレクトリを ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/ ディレクトリに移し、 .vimrc を以下のように書き換えた。

diff --git .vimrc .vimrc
index 6c4987e..56882b2 100644
--- .vimrc
+++ .vimrc
@@ -568,7 +568,7 @@

     " memolist.vim {{{

-      let g:memolist_path = "~/Dropbox/memolist"
+      let g:memolist_path = "~/Library/Mobile Documents/com~apple~CloudDocs/Documents/memolist"
       let g:memolist_unite = 1
       let g:memolist_unite_source = "file"
       let g:memolist_unite_option = "-auto-preview -start-insert"

これで Memolist.vim の Markdown ファイル保存先を iCloud Drive に移行できた。

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの PM が書いたもの）でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。

以下は HTML バージョン

プロダクトマネージャーの役割

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

ビジネス上の成功とは何か？

Product/Market Fit

※図は Dan Olsen のスライドから引用

Product/Market Fit とは何か？

良い市場を見つけ、市場の要求を満たすプロダクトを作る

なぜ Product/Market Fit が重要か？

すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから

なぜプロダクトマネージャーが必要か？

• Market Driven な製品開発
  Market Driven でプロダクトを作っている会社の方が 31% 儲かりやすい
• 組織のゴールが明確になり、プロダクトのリリースと収益化が迅速化される

（良い） プロダクトマネージャーは何をするのか

• 何が作る価値があるものか、何がそうでないかを明らかにする
• すでに市場（ユーザー）で価値の検証が済んでいるものだけを作る

エンジニア・デザイナーとどう違うのか

• エンジニア・デザイナーは解決空間を担当
• プロダクトマネージャーは問題空間を担当する

具体的な役割

• ユーザーヒアリング
• 解決すべき課題の定義
  すでに存在する問題だけではなく、ユーザー自身も気づいていない問題も定義する
• 作るものの定義
  機能要件、スコープ
• 成功の定義とメトリクスの計測

※図は Making It Right から引用

プロダクトマネージャーが扱うデータについて

• データ分析チームとは異なり、ありのままの現実を調べる
  線形解析とか難しい統計とか機械学習などは担当しません

まとめ

• Product/Market Fit がミッション（ Objective ）です
• どうやったら Product/Market Fit したかを含め、成功そのものを定義します
• 成功するプロダクトを作ることに注力します（ Engineering からは身を引きます）

参考ページ

• Amazon.co.jp: Making It Right: Product Management For A Startup World (English Edition)
• Mastering the Problem Space for Product/Market Fit by Dan Olsen at Mind the Product San Francisco 2018 on Vimeo

ヒトデさんの以下のツイートを目にして便利そうだと思ったので fish + peco + vim でやってみることにした。

VSCodeの下にくっついてるターミナルで git ls-files | peco | xargs code とかやってファイルを開くと快適にファイルを探せて便利

— 趣味はマリンスポーツです (@hitode909) June 20, 2018

以下のような fish 関数を追加した上でショートカットキーを bind しておいた。

function peco_gitlsfiles_vim
  git ls-files | peco --query "$LBUFFER" | read selected
  if [ $selected ]
    vim $selected
  end
end

function fish_user_key_bindings
  fish_vi_key_bindings
  bind \cg\cv peco_gitlsfiles_vim
  bind -M insert \cg\cv peco_gitlsfiles_vim
end

これまで一旦 vim を閉じてしまうとファイルを開きたいときには vim . して Unite で調べててたけど、いきなり git ls-files して peco して絞り込めるようになってとても便利になった。

vim + tmuxでVSCodeっぽい開発環境を作る

MicrosoftのVisual Studio…

blog.craftz.dog

↑の記事を読んで tmux でウィンドウを上下分割して、上でコード書いて下でテスト実行したりするの便利そうだなと思ってまねしてみてる。とてもよい。

ただ分割比を調整するために毎回何度かキー入力が発生するのがいまいちだなと思っていた。 tmux のセッションを開始するときにしかこのコマンドを実行することがないので面倒だなと思いながら都度手動で調整していた。

しかし tmux には select-layout という機能があって、 Control
+b + Alt+1 とか入力するといい感じに pane を配置し直してくれることを思い出した。上下分割は C-b + M-3 に main-horizontal というスタイルが割り当てられており、上の pane をメインにして上下分割してくれる。このとき main-pane-height という設定項目に任意の値を設定しておくと分割した pane の高さを指定できるようだった。デフォルトだとメインの pane の高さは小さめなので自分は set-window-option -g main-pane-height 60 にしておいた。これで tmux を起動してウィンドウを水平分割したあと C-b + M-3 とやるだけで 8:2 くらいで二つの pane に水平分割されるようになった。ちなみに左右で分割したときの値を調整したい場合は set-window-option -g main-pane-width 230 などとしておけばよい。便利。

fish-shell に移行 してこれで .zshrc のお守り業から解放されたと思ってたが、最近異常にシェルの新規セッションの開始が遅くて死にそうになってた。特にやばいのが git mergetool したときで、これは内部的には沢山の fish のプロセスが起動して diff を調べて最終的に vimdiff で表示しているように見えた（僕は git config editor=vim です）。下手するとちょっとしたコンフリクトを修正するために vimdiff が起動するまで 15 分くらい待たないといけないことがあって、 20 年くらい前の Photoshop 作業の現場¹みたいな感じになってた。これはかなりやばくて、生産性ががた落ちになる。 vimdiff が開くまでに待っている間に他のことやり始めて、気がつくと平気で夕方になってたりする。

fish-shell のバージョンを 2.7.0 に上げたことが原因かと思って、かつて快適に使えていた fish のバージョンに下げたりしてみたが解決しなかったが、以下の記事にたどり着いて $fish_user_paths への値の push をやめたところ解決した。

fish shellの起動が遅くなった時の解決方法 - Qiita

# TL;DR - fish shellの起動に3〜4秒ぐらいかかるようになった。 - `config.fish`の`$fish_user_paths`の設定方法に問題があった。 - この問題の原因と解決方法をまとめた。 # 何が...

qiita.com

fish-shell での PATH の通し方として以下のようなのがよく出てくる。 Homebrew で keg only なやつを入れたときにも表示される。

set -U fish_user_paths $HOME/Library/Python/2.7/bin $fish_user_paths

しかしこれをやると $fish_user_paths にどんどんパスが積まれていってしまう。どうもこれが原因で遅くなるようだった。自分の環境でも echo $fish_user_paths してみたところかなり酷いことになっていた…。

↑の Qiita 記事では set -U fish_user_paths するときに第三引数を消せとあったが、それでは根本的な問題の解決にならない（ Python やら Ruby やらいろんなものの実行ファイルを PATH に通したいはず）。自分は以下の方法で解決した。

set -x PATH /usr/local/bin $PATH

bash や zsh で export PATH=/usr/local/bin:$PATH とやるのと同じオーソドックスなやり方だと思う。

これだけではこれまでに散々肥えた $fish_user_paths は残ったままなので適当に set -U fish_user_paths '' とかやってあげると空になって起動が速くなる。

fish-shell の set -U はセッションをまたいでグローバルかつ永続的に設定される変数定義の方法っぽいので下手するとその環境で fish を使い始めてからずーっと残ってしまう可能性がある（端末を再起動したらリセットされるかも知れないけど）。

まとめ

• set -U は基本的にしない
• $fish_user_paths は設定ファイルの中では使わない
• PATH を通したいときは set -x PATH を使う

GW 前半の 4/29, 4/30 で山口県に行った。子どもが SL やまぐち号に乗りたがっていたのと、自分が下関の唐戸市場と角島に行ってみたかったから。旅行計画はこんな感じ。

家庭内 Kibela にエントリーを書いて嫁さんと共有しながら計画を練った。ただ嫁さんはめんどくさがって前日まで見てなかった。自分は電話が嫌いなので SL やまぐち号のチケット予約の電話を嫁さんにしてもらった。

予定では朝 7 時に家を出ることになっていたけどうだうだしてしまって結局は 9 時半頃家を出た。昼前に関門海峡に差し掛かり、関門橋を見渡すことができる PA で写真撮影して本線に戻り下関 IC で降りたところで嫁さんがシートベルトをしておらず後席シートベルト不装着で長州の官憲につかまえられた。関門橋のところの PA まではシートベルト着けていたとのことなのであれはトラップだと思う。ゴールド免許復帰の夢は潰えた。

下関市役所の駐車場に 11 時半頃到着し、歩いて唐戸市場へと向かった。下関の印象は門司と似ていた。昭和の雰囲気を色濃く残す寂れた商店街の感じは、あぁ、門司と下関は双子の都市なんだなぁという思いを抱かせた。

唐戸市場は昼時ですさまじい混み具合だった。ようやく食べ物を調達しても座って食べられる場所を探すのが大変。人混みの中で押し合いへし合い状態で買った海鮮丼は大したことなくて、唐戸市場はアクティビティとして来てみるのはよいけどわざわざ食事を目当てに来るほどではないなと思った。

テラスから関門海峡を通るタンカーや船を眺められるのはよかった。タンカー、普段は港に停泊してるやつか沖合を航行してるやつしか見ないと思うけど、間近で見るタンカーは結構速いスピードで動いてるという知見が得られた。

唐戸市場を出たあとは商店街にある自家焙煎のコーヒー屋でサイフォンでいれたコーヒーを飲んだ。

その後角島を目指して日本海側を移動した。海沿いの景色は福岡の糸島と同じような風景だったけど、とてつもなく長いビーチがあって気持ちよかった。角島には 4 時頃着いた。運良く空いたところに停められたけどすごく人が多くて車を停める場所を見つけるのが大変だと思った。この日は曇り気味の天気でガスも多く、角島大橋の景色ははっきりは見えなかった。橋を渡って角島の方まで行ってみたけど観光名所となっている灯台のあたり（映画の舞台になったらしい）は駐車場代が福岡の天神よりも高くバカらしくて車を停めはせずぐるっと回って戻ってきた。角島大橋近くの店でコーヒーを飲んで休憩したあと、併設の萩焼の店で嫁さんがいくつか器を買った。

6 時頃から今度は宿泊先の山口湯田温泉に向かった。途中、秋吉台を見ていきたいと思っていたけど道に迷った＆日が暮れてしまい、結局秋吉台を見ることはできなかった。 8 時頃ホテルに到着し、繁華街に出かけて食事をした。結構迷ってふらっと入った店は悪くはなかったけど会計がすこぶる高く卒倒した。宿に戻ると 11 時半を過ぎており、併設の温泉の利用を断られた。予約していた部屋がツインではなくダブルの部屋だったことを嫁さんにとがめられ床で寝た。

翌朝、朝食が無料で付いていたので食べに行ったところ、無料なのに地元のおばちゃんたちが作る煮物などがどれもおいしくびっくりした。チェーンのビジネスホテルで家庭の朝食みたいなやつが食べられて良かった。

食事を終えてチェックアウトし、コインパーキングを探して車を停め、メインの目的の SL やまぐち号に搭乗すべく湯田温泉駅へとタクシーで移動した。湯田温泉駅はつつじが満開だった。

SL やまぐち号は非常に混雑していた。また車両は古くてすすけていた。 SL は子ども時代に家の近所を走っていた ASO ボーイの試乗運転にしか乗ったことがなく、長距離を乗るのは初めてだった。 SL 特有の動き始めたときに車輪が滑ってずるっとなる感じが印象的だった。

やまぐち号の目的地は島根県の津和野で、車窓からの風景は山また山、時々田園地帯という感じだった。石州瓦の赤い屋根瓦の家々が印象に残った。日本海側で降雪量が多いことも関係あるのか、切り妻屋根の家が多いなと思った。

津和野は昔ながらの雰囲気を残す街だった。小京都と言われているようだが、中山道の宿場町の馬籠宿に似ていると思った。小さな街なことと帰りの SL までの時間が限られているのでレンタカーを借りるほどでもなかったので駅前でレンタサイクルをかりて街を回った。昼飯を食べなければならなかったが着いた時刻が 14 時前でどこの飲食店も軒並みラストオーダーを過ぎており、昼食を食べる店を探すのに難儀した。森鴎外の出身地とのことなので鴎外の生家に行ってみたかったが、三時間弱の滞在時間では時間が足りず、菓子屋で名物の源氏巻を食べ、閉店しようとしていたところを何とか滑り込んで割子そばとうずめ飯を食べ、酒蔵を二軒回って日本酒を買った（2本買ったうち1本は列車から降りるときに嫁さんが落として割った）ところでタイムオーバーとなった。

山口の湯田温泉駅に戻るとどっと疲れが出て、これから福岡まで運転して帰るのかと思うと暗澹たる気持ちになったので帰る前に足湯に浸かって帰った。街中に綺麗な足湯スポットがあって 200 円で入れて、足湯に浸かりながらコーヒーなどを飲むこともできる。

いろいろ盛りすぎて一泊二日で行くには時間が足りなかった。特に津和野にはもう一度行ってみたいと思った。