| @ブログ

#100DaysToOffload 7 月のふり返り

7 月 10 日に #100DaysToOffload に挑戦する宣言をしてからしばらくは調子よく記事を書けていたが、後半にだれてしまった。 11 記事以上書かなければならないところ、 9 記事しか書けなかった。

宣言後に最初に書いた記事は、昨年末のセールで買った新しい Kindle Paperwhite についての記事。ホーム画面がリッチになって目移りしてしまい本が読めなくなったというチラウラ記事だが、 Twitter で nagayama さんからリプライをもらって設定で回避できることを知った。情報を発信するところに情報が集まってくる良い例だと思った。

一番反響があったのは、エンジニアの求人を出している会社の顔ぶれが変わってきているという記事。一昔前は受託開発をやっている会社かウェブサービスをやっている会社が雑にエンジニア( HOW )を募集していて、何( WHAT )をやるかはエンジニアを採用したあとに顧客や状況に応じて考えるという感じだった。いまのエンジニア求人は何か解決したい課題があって起業された会社( WHAT )がエンジニア( HOW )を採用しようとしている感じ。 WHAT と HOW の主客が逆転しつつあるのでは、ということをまとめて書いた。

Numbers に関しての記事は、 Vim 、 Day One 、 Notion 、 WorkFlowy 、 Journler 、Yojimbo 、 Evernote などこれまでいろんなドキュメントエディター・オーガナイザーを使ってきて実現できなかったことが Numbers を使うとできるということをまとめようとして書いたが若干不完全燃焼感があった。例として出した登山の計画がニッチすぎたかもしれない。一般的な旅行の予定を Numbers で立てる、みたいな感じで紹介すればよかったかも。そういや Numbers のテンプレートに旅行計画ありますね。 Mac ユーザーで表計算ソフト使ってる人はわざわざ MS Office 入れて Excel 使ってるかもしれないけど Numbers はもっと評価されてよい。

Z6 の良さについては、オペミスで吹っ飛ばした過去写真の整理をしていて改めてその良さを伝えたいと思い立ち書いてみた。 NIKON は株価が低迷しているが、 Z は本当によいのでおすすめ。撮った写真をすぐに Bluetooth でスマートフォンに転送しつつ位置情報も付与してくれる機能が特に気に入っている。ちなみに NIKON は公式には Z 6Z 7 という Z と 数字の間にスペースを入れた名称にしているが、ググラビリティが最悪なので正式に製品名を Z6Z7 (スペースなし)にした方がよいと思う。

家の近所の長垂海浜公園の駐車場についての記事は本当にしょうもない記事という感じがあふれているが、たまにこういうのを書きたくなる。近所に住んでいる人間でないとわからない情報をインターネットに載せて社会貢献したいと思い、わざわざ夜に散歩してたときに写真を撮って回って記事化した。この手の記事は短期的にはアクセスが伸びないが後からじわじわと伸びてくる予感がある。 Garage Band でのアナログレコードの録音方法の記事 は 10 年以上前の記事だけどいまでもコンスタントにアクセスがある。

ブログは書かなくなると更新が滞ってしまうので、あまりクオリティの高いものを書こうと思わず、もっとライトな感じで更新していきたい。

なお、この記事を含めて 2020 年の記事は 40 記事なので、残り 5 ヶ月で 60 記事書かないといけない。一月あたり 12 記事は結構大変だ。

| @技術/プログラミング

Vim の設定に関してはペパボ時代に同僚のみなさん( glidenote さん、 banyan さん、 linyows さん)から色々学んでほぼほぼ不満がない状態になっている。正規表現拡張の eregex.vimrails.vimprojectionist.vimvim-surround など tpope プラグインと Shougo プラグイン( unite, vimfiler あたり)で普段のユースケースはカバーされているが、 EasyMotion というプラグインの存在と、同じ人がメンテしている incsearch.vim というものがあることを知って入れていみた。カーソル移動を楽にする Vim プラグインのようだ。これまで ⇧wf⌃d などで高速移動はできるといえばできるが、空白や単語の切れ目ではない位置を狙った移動では結局 hl を連打してしまっていた。 EasyMotion は冒頭の数文字を検索すると飛び先をアンカー表示してくれて、高速にファイル内を移動できるというもの。 Unite のファイル内ジャンプ版という感じかな。

さらに調べると incsearch.vim の方は Vim 本体に取り込まれたみたいで必要ないらしいのだが、 で検索にヒットしたカ所を移動したりする機能は incsearch.vim の機能っぽいので両方セットで使ってみることにした。 EasyMotion は incsearch と組み合わせて使うことでかなり便利になるっぽい(ブリッジに haya14busa/incsearch-easymotion.vim が必要だ)。こんな感じ↓(画像は incsearch-easymotion のリポジトリから拝借)

incsearch-easymotion demo

| @WWW

Markdown Logo.png

なぜ 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 化したような感じで、文章を並べ替えたり入れ子にしたりできる。

Notion

文章を構造化することに慣れていない人でも、まぁまぁ読みやすい構造化された文章を書ける、あるいは構造化された文章の書き方を学べるようになっている。

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 がやっぱり好きだとも思う。


  1. 正確には Notion と Dropbox Paper と同じような、 Markdown と WYSIWYG がミックスされた独自フォーマット 

  2. macOS 版の Notion では Markdown 形式でコピーできたけど、 iOS 版ではできなかった 

| @Mac/iPhone

Fire

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 などではたどり着けない。以下の記事を読んで調べた。

パスは ~/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

Product-Market-Fit.png

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

Product/Market Fit とは何か?

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

なぜ Product/Market Fit が重要か?

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

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

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

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

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

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

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

Product-Market Fit - 2.png

具体的な役割

Product-Execution.png

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

※図は Making It Right から引用

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

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

まとめ

Product-Market-Fit.png

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

参考ページ

| @技術/プログラミング

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

以下のような 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 して絞り込めるようになってとても便利になった。

2018-06-20 16.48.40.gif

| @技術/プログラミング

IMG_4652.jpeg

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

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

しかし tmux には select-layout という機能があって、 Control
+b + Alt+1 とか入力するといい感じに pane を配置し直してくれることを思い出した。上下分割は C-b + M-3main-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 などとしておけばよい。便利。