00:00
はい、うちゃらセキュアスト第103回ということで今回もゲストに沢山お迎えしております。よろしくお願いします。
よろしくお願いします。
今週のライフハックニュースなんですけど、少し大きめというかな、ノーニュースになるかと思うんですが、
Scrapbox、このうちゃらセキュアストの小ノートというんですかね、を作っているのもScrapboxなんですけど、そのScrapboxの開発元である、
Notaという会社があるのですが、10月1日、来月から社名がHelp Feelという名前に変わるらしく、
Help FeelというサービスがNotaの三本柱の一つだったんですけど、それを今度その一つを社名に掲げるということで、
つまりレベルアップをしたんですね、Help Feelが。アウトライン的にレベルアップしたということで、
だから今後このサービスがこのNotaにとっての主軸になっていこうという意思を感じられる社名変更かなと思います。
基本的にこのNotaってGazoとScrapboxとHelp Feelというのを三つサービスがありまして、
Help Feelに関して言うと、個人ユースのものではなく、個人向けのサービスの方を持ってよくて、
どういうのかというと、Q&Aサイトの開発、内地や提供、運用をサポートしてくれるものでして、
これが非常にScrapboxと同じように使いやすいというか、使いやすいというか非構造的、
非大分類的に使えるQ&Aサイトということで、
だいたいインターネットの企業サイトで自分がサービスを使っていて、Q&Aサイトとか自分がヘルプを見つけたいなというときって、
まず一番最初に提示されている大分類から、自分の求めている情報はどれだろうかというのを探さなければいけないんですね。
それからまた微妙にこれかな、いやこれかなっていうのがあって、
それを回想をいくつか同じ手順を繰り返して探していって、運よく見つかることもあれば見つからないこともある。
見つからなかった場合はまた回想を上に上がっていってっていう手順を繰り返さなければならない。
これ非常に手間だし、ユーザーもだいたいそんなことで付き合ってくれないので、
お困りの時は友人サービスでどうぞみたいな感じで結局人手が取られてしまうと。
せっかくQ&Aサイトを作って、その答えがそのサイトに書いてあるにもかかわらず人手が使われてしまうという。
このヘルプフィールドそれを解決してくれるということで、
どこの企業でも同じようなサイト構成になっているんですけど、一番上にインプットボックスがあって、
03:01
そこにあなたが聞きたいことを入力してくださいという感じになっている。
文章を入力していくと、関係ありそうなページが下の方にいくつか広報として表示されるっていう形になっていて、
大分類を選んで中分類を選んでじゃなくて、直接ダイレクトに質問、聞きたいことを入力していくことでページを探せるようになっているということで、
だいぶScrapboxと似た感じ。
似てますね。
多分バックエンドはScrapboxの仕組みが使われているんじゃないかなと勝手に思うんですけども。
これが結構Scrapboxと似ているのが面白いのが、一文字間違いとかも共用してくれまして、
例えばほとんどないと思いますけど、Excelの最後のLをRとかにしてもちゃんとExcelって出てくる。
これは結構大きいことで、やっぱり人間細かい間違いは普通にしてしまうので、一文字間違いとかの共用がある。
あとは、狂気というのかな、この単語とよく使われている単語っていうのがリンクでパッと出てくる。
例えば、注文とキャンセルみたいなこと、よく一緒に検索されているんですけど、それがリンクされて、
その両方のリンクを含むページが見つかれば注文キャンセルに関してのページだろうみたいな感じで探せるという風になっていて、
非常にデジタルをベースにしたヘルプサイトということで、結構今企業に人気らしいです。
なるほど。
なので、名前が変わってしまうことによって、スクラップボックスの将来大丈夫かなという声もあるかと思うんですが、
多分バックエンドがスクラップボックスなのできっと。
きっと。
スクラップボックスはおそらくは大丈夫でしょうし、ヘルプフィールを導入している会社は同時に自社ウィキとしてスクラップボックスを使う可能性も高いので、
その辺で収益を上げていただければなと思うところでございます。
今週はそれぐらいかな。
そうですね、あんまり話題だし、最近ツールの大きなアップデートとかもなく。
あんまりないですかね。
細かい改善が進んでいるということでいいことかもしれないんですが、
そういえば人を賢くする道具ってちょっとお読みになられました?わずかばかり。
そうですね、わずかばかりしか読んでないですけど。
そうなんですよ。
でも、目次を見ただけでも面白そうですね。
そうですね、これもうだいたい1章から10章まで非常に面白くて、
ツールを使うのはどういうことかなっていうのを結構考えさせられますね。
そうですね。
そうだ、買いましたと言ったのがちょうど2週間前なので。
06:01
こういう分厚い本はなかなか進まないものなので。
いや、これね、やっぱりね、面白そうだなと思うと、
ちゃんと読もうと思ってたらなかなか読めなくなる。
結構あるんですよ、そういうの。
そういう付き合い方も本との付き合い方ですからね。
本は逃げていかへんので、別にいつでも。
逃げていかへんからこそなかなか読まへんということもあるわけですが。
今回の主テーマ、現行のバージョン管理についてなんですが、
ないしは現行をどう管理しているかという話で。
バージョン管理というと、現状ほぼGitを使う管理かなとは思うんですが、
確かサブバージョン、サブフニャララみたいなのもあったと思うんですけど、
僕はほぼ使ったことがないので、Gitの話になるかと思うんですが、
現行をどう管理しているか。
ないしは、バージョン管理って言いますけど、
バージョンを管理しない管理もあるわけですからね。
最初にお互いどうしているかを確認したいんですけど、
僕はちょっと複雑なときがややこしいんで、
たくさんはどんな感じですかね、自分の書いた現行の管理。
そうですね、現行の管理というか、
実情バージョン管理と一緒だと思うんですけど、
アウトライナーでスタートした場合、大体そうなんですけど、
例えば主にアウトライナーとかライナリストの
一つの項目の下に書き始めるわけですよね。
大体一つ作業、例えば1日の作業をやって、
終わって翌日作業を始めるときに、
その昨日書いた項目のコピーを作って、複製して、
日付かなんか後ろに付けておいて、
それを重ねていく形でバージョンを積み重ねていって、
短いものはそのままできあがりまでやっちゃいますね。
長いものだと、あるところから先、
アウトラインモード中心のワードに移るんですけど、
ワードの場合は結構、
ワードのもともと入っている修正記録の機能を使って、
やっぱり1作業ずつぐらいにファイルをコピーしながら、
残しながらやっていくっていう、
会社の共同作業のフォルダの中で絶対にやってはいけない行為を、
自分一人だからいいので、
ファイルに日付を付けながらバージョンを重ねていくっていう、
まるに昔ながらのやり方ですね。
差分を取る代わりに、
特にややこしい編集をするときには、
09:02
ワードの修正記録の機能をオンにした状態でやって、
ややこしい編集が無事終わったら、
修正記録は削除しちゃって、
その書く日付のファイルだけを残していくっていう感じですね。
その程度ですね。
完全に脱稿した後、ファイル群とかはどうなりますかね。
えーとですね、
その完成版のファイルだけ残して、
何十とか何百残っているファイル群は、
フォルダの下にまとめて圧縮しちゃいます。
捨てはしないですね。
なるほど。
ダイナリスト上に作られる、
一回一回コピーされる項目の流度という単位は、
どんな大きさなんですかね。小チャプターごとですかね。
いや、それも長さによるんですよね。
記事レベル、要するに数千字レベルだったら、
もう一まとまりだし、
何万字レベルでも多分一まとまりごとにコピーしてますね。
要するに本、本印刷部の長さにはまだなってないけれども、
本全体のアウトラインを毎日、
毎日でもないな。
例えば最初から最後まで、
一回手を加え終わったなと思ったらコピーして、
一個次のバージョンを作ってっていう感じですね。
過去の、例えば1回前、2回前のファイル、項目が活躍する機会ってあります?
割にありますね。
あるんや。なるほど。
こういう、やっぱり編集してる過程でなくなっちゃうことってありますか。
書いたことが。
で、なくなっちゃったんだけど、書いてる途中で、
前にこのことを書いたな、
じゃあそこから、そこにつなげようと思ったんだけど、見たらなかった。
っていう時に、ダイナリストの中にいれば、
そのダイナリストの過去バージョンが入っているそこのところに絞って、
出てきそうなワードを検索すると、
ここから先でなくなったんだな、みたいなのがわかるんで。
それを開いて、別ウィンドウで開いて、そこの欲しかった部分が見つかったら、
そこだけポコッとコピーして、今のバージョンで持ってくるとか。
逆に言うと、気楽に削除できるために履歴を残しているという言い方もできそうですね。
そうですね。
で、その履歴を使う前段階で、いわゆる、いわゆるというか、
未使用という項目を作って、その下に落とすということをしてるんで、
使えそうなものの8割ぐらいはその未使用の中に見つかるんですけど、
12:04
本当に消しちゃってるときもたまにあるんですけど、
長いものほどそれが起こる可能性があるので、
意外に過去バージョンに戻って拾い上げてくるっていうことはやりますね。
で、ワードの段階になるとむしろ大規模なこの入れ替え、組み替え、
編集をするときに大失敗しないように残しておくっていう意味合いのほうが多分大きくなりますけど。
そうか。バックアップとして保存している段階段階で保存していると。
そうですね。
ちなみにGitは使われていないと。
使ってないです。
そうですね。昔テキストファイル中心にやっていた時代のやり方だったらもしかするとやってたかもしれないですけど、
その当時はGitはなかったので。
そうなんですね。今話を聞いてると、作業にテキストファイルが全然出てこないですよね。要するに。
そう。だから今はテキストファイル使ってないんですね。考えても。
中間ファイルとして使うことはありますけど。
実際に原稿を書くときにテキストファイルを使うっていうことが皆無になっちゃってますね。
そうか。確かにテキストファイル、
ワードで原稿を触る場合はそこまでGitの必要性はないんじゃないっていうか、
差分が取れるんか取れへんやろうな。
Git単体では差分が取りづらいでしょうね、きっと。
少なくともテキストファイルみたいにきれいには取れないはずですね、きっと。
バイナリーファイルでは多分取れない。
ですね。内部にテキストを持ってない限りは無理ですね、きっと。
だと思うんですよね。
まあ、その、そうか。Gitのビューアーがバイナリーファイルを解釈できたら取れるか。
テキスト表示に一回変換した後、差分、リフ取ったら一応取れますけど。
どこまでするかどうかは分からないよね。
普通の、例えば、VS CodeのGitの差分、やったことないですけど、多分取れないですね、きっと。
例えば、複数人で執筆するとかだったら、
もうちょっとちゃんとしたバージョン管理のツールを使わないといけないと思うんですけど、
まあ、一人なんでね。
とは思いますね。
ですね、はい。
そうか。
まあ、でも、やられてることは手動Gitみたいなものですね。
要するに、コピーが、手動Git履歴が残っていくという意味。
まあ、Gitのほうがもっと細かい単位で残りますけども、
そうでしょうね。
15:00
加工の自分のあるバージョンにいつでも戻れるという意味ではバージョン管理されてるといっても過言ではない。
まあ、そうですね。
デッキ内の例えばGitでいうと、枝分かれしていく、ブランチを切るみたいなことはできない。
うん、確かに。
やっても多分わけ分かんなくなるんで。
うんうんうん、そうかそうか。
うーん。
えっとね、僕の場合は色々試しているので、非常に色々形があるんですが、
一番単純なのが、多分、五流五参と共同でやっている
ブックカタリストの書き起こしを本にしようという2人でやってまして、
共同プロジェクトなので、Gitを使ってやってますと。
で、非常に単純で、作業用のフォルダを作って、そこで2人でお互いにテキストとかを共有して、
で、自分が作業したらそれをコミットプッシュしておくというだけで、
で、今のところブランチ切るとかもうほぼなく、ただ共同作業のためだけの、
ないしはそのコミットを残しておくためだけのGitの使い方をしてますね。
うん。
なので今までほぼロールバックというか、昔に戻したこともないですね、そのプロジェクトでは。
戻さないですか。
今のところはまだまっすぐ進んでいるだけ。
だからやってることとしてはほとんどDropboxで共有しているのとほぼ変わらない状況で、
仕組み的にGitを使っているというだけ。
Gitの場合はその1回1回のコミットに、そのコミットメッセージ、コミットログっていうのを残さざるを得なく、
残さないと書けよおいって言われるんで、そのツール側から。
だから例えばチャプター2までのここらまで書きましたっていうことがログとして残っていく。
で、2人でやっているので、そのログを共有するという意味でのGitは便利ですね。
これDropboxだとそのログをわざと多分自分たちで書かないんで、
お互いがどこまで進んでいるか、お互いの脳内では分かっているけど、
相手が分からないっていう状況になりがちなので。
そういう意味ではGitが便利だし、もっと使い込むこともあるので、
GitのIssueとかを使うことでタスクリストにも多分なるでしょうけど、
僕らはそこまでやっていなくて、テキストファイルにtoodoot.mdっていうファイルを作って、
そこでやるべきことを共有しているという形。
これが多分一番シンプルなものです。
逆に、トンネルチャンネルっていうニュースレターがあるのですが、
あれを書くとき、僕はもうブラウザーで直に書いてます。
そうなんだ。
だから僕のロゴカルにはあれ残ってないですね、全部。
一応だから、送信ボタンを押したものすべて僕のGmailに飛んでくるので、
18:04
ログがそこに残っているし。
言ってもちゃんとした文章っておかしいですけど、
ちゃんとした文章ではなくて、メールのような感じで書いてるんで、
ただブラウザー上でエディターの上に書いて送信ボタンをポチって。
だから何の管理もない。これが一番管理ゼロのパターンですね。
ちょっとややこしくなってくると、商業出版に進めている原稿とかはGitで管理してまして、
これはほぼバックアップの意味で、
そうすると、そのファイルがDropboxにもあり、Gitにも送っているから、
30のバックアップ先として使っているという意味合いが多いです。
一応、僕普段それまではブランチを切らずに、枝分かれさせずに書いてたんですけど、
とある藤井太陽先生という、
とある。
作家の方がブランチ上で作業するといいよということをおっしゃられてまして、
Gitっていう仕組みそのものが抱える問題ではないですけど、
テキストファイル以外にもいろいろ保存とかできますし、
言ったら自分で書いているミニスクリプトとかも一緒に保存しておけると。
そうすると、スクリプトの修正とかもコミットに入ってしまうと。
それはだからコミットログの一覧があまりにも多くなってしまうと。
だから、例えばチャプター1書くときにやったら、
チャプター1用のブランチをまず切ると。
で、そこで作業して一通り終わったら、それをメインブランチに戻すことで、
作業ごとのログを分割できるメリットがあるよというような話で、
なるほどなと思ったので、
そっちは僕は書くときのブランチを切って書いているやり方をしてますね。
その場合のブランチを切るというのは、
要するに一時的に対比させているような感じになるんですかね。
基本的にGitという複数人で進めるもので、
要するに同じプロジェクトを触るときに、
Aさんが部分Xを、Cさんが部分Yを作業しても大丈夫なように、
本流とは別に枝をするというのが多い。
できたらメインに合流、無理のない形で合流させるという風になっているんですけど、
僕は一人で書いているので、ブランチを切ったら、
そっちが僕の作業をメインに、一時的になるわけです。
本流の方はメインブランチはほぼ触らない。
ブランチで作業して書き終わったら、
その修正結果をメインに戻す。
だからメイン上で作業することはほぼないってことじゃないですか。
21:01
書くときに常にブランチを切っていくという感じ。
これはGitならではというか、Git以外ではできないやり方ですね。
でもこれもほとんどロールバックすることはないですね。
僕はそもそもロールバックほぼしないということが大体わかっているんですけど。
これは結局原稿の書き方の問題で、
バザール執筆法的な方法ってほぼ毎日進むなので。
そうですね。戻らないですよね。
だからあんまり書き直すぐらいなら、ゼロから書くというような感じになっているんで。
関連しているというか、ちょっと最近始めた方法としては、
今までやったらバザール執筆法の場合って、
チャプター1のテイク1を書くと。
書き終わったらもう一回書き直して、
チャプター1のテイク2を書くっていうのを2回か3回繰り返して完成するっていうことをしてたんですけど。
今やっている本のチャプターがちょっと1個1個短かったので、
チャプターの上のパート1,2,3みたいなので、まとめたファイルを作ったんですね。
1つのパートには複数のチャプターが入っているという形にしてたんですけど。
一覧性はいいんですけど、やっぱりファイルというか認知的にちょっと重たいんですね。
量全部入っていると。
作業を書くときだけは別ファイルでやろうかなと思いまして。
つまり、さっき言ってたメインとブランチの関係に近いんですけど、
パートのパート1MDっていうのを作るんですが、そこでは書かないと。
例えばパート1のチャプター2っていうのを書くときに、
チャプター2用のファイルを作り、そこで書くと。
書いた後、コピペしてメインのパート2にコピペするっていう、
これも手動ブランチみたいなことですけど、やってたんですが。
ここが難しくて。
この方式でいくと、どう言ったらいいかな。
答えを簡単に言うと、その時にファイルの名前をどうするかなんですね。
その分類、ブランチの。
ブランチファイルのね。
で、チャプター1、テイク1、テイク2とかしていく方法もあったんですけど、
ファインダー上でも邪魔になるので、日付にしたんですね。
もしそれを作業するなら、2022-09-08.mdっていうファイルを作って、
そこで作業する。
1日で終わるときもあれば、3日かかるときもあって、
24:01
3日かかって終わったら、とりあえずそれをコピペして、
メイン.mdのとこに置いて、
今度作業した3日後の11の.mdファイルを作ってっていうのを、
ずっと繰り返していく。
だから日付のファイルがどんどん増えていって、
そのコピペ先としてメインが残っていくっていう感じに今はなってますね。
なんかね、バザーを執筆をやると、
チャプター1-01、チャプター1-01、チャプター1-01、
それぞれ日付が違うっていうのができるんですけど、
ちょっと鬱陶しいんですね。あれ不思議と。
なぜか知らないんですけど。
なので今は日付ごとして。
日付ごとの名前が並んでてもあんまり鬱陶しくないんですね。
なんか知らないですけど。
なんとなくわかる気がする。
メインとメインじゃないものが同じような名前で並んでるのが気持ち悪いのか、
何かなんかわからないですけど。
とりあえず前の本ではチャプター1のファイルが共産あったんですが、
今はもう一つしかなくて、メイン用のところしかなくて、
全て日付ファイルで作業してますね。
はいはいはい。なるほど。
そんなところかな。
僕はアウトラインはワークフローリーで作ってまして、
僕はチャプターごとに作って、
チャプター07日付って書いてアウトラインを立てて、
しっぴつとかに反映された後にもう一回立てるときはまた新しく項目を立てて、
日付を振ってっていうので、この辺はたくさんと似ている感じですね。
アウトラインそのものを修正するというよりは新しく作る。
僕の場合はゼロから作るんですけど、一緒じゃないですね。
同じような項目が複数あるので、
過去のバージョンもだいたい全部残してたんですけど、
例えばチャプター07やってるんだったら、今まで作ったチャプター07全部残してたんですが、
ワークフローリーってよくよく考えたら、最近消しても残ってるんですよね。
トラッシュボックスっていう機能があって、復活できるんですね。
よくよく考えたら、置いとく意味ないなと思って。
新しいの作ったら前のままだいたい消すようにしてますね。
ホーム画面には最新のしか残ってないみたいな感じになってますね。
特にワークフローリーの場合はそうした方がいいですよね。
なんかそんな感じがしますね。
あと最近になってようやくなんですけど、触ったら上に移動させるができるようになりましたね。
これ昔からずっと聞いてたしやろうかなと思ってたけど、なぜかできなかったんですよね。不思議と。
できない? 順番にこだわってしまうのなんかわからないんですけど。
面倒くさいわけじゃないはずなんですけどね。
他の人からもそれ聞くんですよね。
27:02
その理屈はわかるんだけど、できないって言われることがあって。
できないっていうか、嫌なのかな。
何人かの方にそれ言われたことがありまして。
いじったやつを上に動かすのが感覚的に、整理的にできないみたいな。
整理的にが近かったんかな。
たぶんだから、一番最初に配置した、アレンジした時に、自分なりに意味づけを持って並べたから、それを壊したくないみたいなことなのかもしれないですが。
でも、改めて気づいて、これアウトライナーの使い方としては相当不自由なことをしてるなと思って。
触ったら移動させるのがアウトライナーのいいところなわけですから。
たくさん話を聞いてたら、GO3も使ったら上に移動させるって書かれていて、
ああそうだそうだと思って、最近は使ったら上っていうのをちょっとずつしてますね。
その方がいいですね、これは。
思うんですけどね。
順列を崩される、やっぱりリストっていう感覚は強かったんですね、たぶんきっと。変えられない時っていうのは。
最近は割りかしちょいちょいちょいちょいいじってますね。
やっぱり人気的に上下の並び、リストの並びっていうことからどういうものを受け取るかっていうのも多分人によって違うんでしょうね。
そうですね。
だから並べるときにすごくリソースを使って、
やっぱり一度それができちゃうと、もうそれを動かしたくないっていう感覚は分かるような気もするんですけど。
それに近いですね、それに近い感じがします。
それをこだわらないようになった時にまたちょっとアウトライナーの進化が見えてくる。
あとホーム画面にそんなに項目を置かなくなったからかな。移動しやすくなった。
数の問題はあるかもしれないですね。何百個もある、この89番目から上に移動するとか、あんまりやりたくない気がしますよね。
やりたくないです。ショートカットでもマウスでもどっちでもめんどくさそうですから。
コピペしたらいいんですけど、項目を全部消して新しい項目を作ってペーストするってやるので、ID変わるんですよね、そのツールの中に。
それが気持ち悪いんですよ、リンクが変わっちゃうんで。
だからあんまりしたくなかったのかな。
まあわからないですけど、とりあえず最近は使ったら上、ないしは触ったら上みたいな感じかな。
副者は下に作って置いておく。で、使ったら上にする。そんな感じかな。
30:06
だからそれで結構変わりましたね。
僕の原稿の執筆に使うのはアウトライナーと、あと情報カードと原稿で、原稿はすべてテキスト、ないしはほぼMDファイルかな。
MDになっているものはだいたいDropbox&Gitで保存されてますね。
ただ、ほんまにGitで戻ることはほぼないです。
もともとのロールバックに相当することはまずしない。
全体をロールバック、そのファイル自体をロールバックってあんまりしないですよね。
だけど、昔作ったファイルのあるこの部分だけちょっと取り戻したいっていうのはあるんですよね。
プログラミングと似ているようでもやっぱりちょっと違う部分があるとは思いますね。
思いますね。だからScrivenerのSnapshotがあんまり自分にとっては使い物にならないんですよね。
個別のパートだけSnapshotとってもあんまり意味がない。
確かに。
Scrapboxの仕様を見ると細かく分けることを良しとしているように見えるのに、
細かく分けた断片ごとにSnapshotとってもあんまり意味がない。
そうですね、確かに。
だから全体のSnapshotが欲しいんですけど、それはできないっていう。
それはもうバックアップになっちゃいますからね。
そうなんですよ。
ファイルが重いからあんまり苦手なんですね、そういうのが。
そうなんですよね。一応バックアップは取れるけれども、
じゃあ今の全体とバックアップの全体の差分を取ろうとしてもScrapboxの中ではできない。
できないですね。
Snapshot間でしかできない。
できないっていうのがあって。
かゆいところに手が届いてるのか届いてないのかよくわからんみたいなところがね。
届きそうで届かないところがあるんですよね。
あとはWordでいわゆるテキストエディターで言うところのリーフを取る操作ができるというのも実は結構大きくて。
なるほど。
修正記録を残すだけじゃなくて、原ファイルと旧ファイルを比較して、
差分をその修正記録として埋め込んでくれるっていう機能があって、それを結構使うことはありますね。
ほとんどそこの部分だけ言えば、ヒット的なことはできているという感じがしますね。
とはいえファイル単位なんで。
確かにね。
ヒットの代わりにはならないですけど。
33:03
あとバージョン管理、多分ファイルを分割するかどうかで随分変わりますね。
そこですよね。単位をどう取るの。これだから一人のときはまあいいんですけど、
共同作業するときにこれは必然的にテキストファイルとかが要求されて、
みんなが同じファイルを触ることになるわけで。
ある種のプロトコルがいりますよね、そこは。
だから自分のやり方で共同作業は僕はできないんですよね。
そうですか。
ワードを使う場合は難しそうですね。
リビジョンのときにお互いに何となくいつもと違う方法を教えてあげるという。
そういうことが起こるわけですよね。
まあそれもGitを中心になると相手方にテキストかMDファイルを使ってくれということにはなっちゃいますね。
難しいところですよね。
プログラミングであれば、プログラム開発であれば、
まあそれは当然最初からそうなってるんで、できるんでしょうけど、
文章、原稿を書くっていうことになると。
まあその、書者と編集者の場合は編集者が書者に合わせる形が自然ですけども、
対等な強調者でテキストをしかもお互いに持ち寄るみたいな場合は、
国境が異なる国がたまたまその国境がなくなるようなものですからね。
そうですね。
ちなみに倉下さん今書かれている原稿で、Gitに入っている文って、
それって編集者さんとの間でGit上でのやりとりってのはあるんですか。
今のところはないです。
今のところはないです。
それはいずれやろうかなと思ってるんですが、
僕自身がそんなにGitに慣れていなかったのもあるので、
お試しでやってたっていう、
まだファイルの構成をどうするかがわからなかったんで、
結構入れ替えたりとか、リポジトリをゼロから作り直したりってことを
結構たびたびしてたんで、まだ安定してないなって。
安定したら編集者の方に、特に技術系の編集者の方にやったら言ってもいいかな。
まあそうですね。
そうじゃない、ビジネス系の方やったらちょっと、
Gitって何ですかっていうところから入る可能性もあるので、
その場合は別にいいですけど、
相手がわかっている方やったら多分だいぶ早いですね。
結局その原稿の修正箇所とかのコメントが全部Git上に残ってくれるわけで、
メールプラスとかチャットプラス原稿って分離しなくなるので、
情報が一元化されて非常に進めやすくなるかなとは思いますね。
あと、たぶんちょっとしたコメントを送りやすいというかGitの場合は、
36:03
メールに比べるとやっぱりちょっと構えるじゃないですか。
はい。
変化なくなって、コミットログとか、
あるいはさっき言った共有しているテキストとかにちょこちょこっと書くというだけで、
コミュニケーションがより雑談的になっていくかなという感じがしますけども。
全く管理しない限りテキストで管理するのが、
僕の今までの主要なパターンで、
安定しているまでは言えないけど、
ベータ版ぐらいのところまではしているやり方なんですが、
今ベータ版にすらなっていないですが、
α版のやり方を試してまして、
これメールマーカーでも書いたんですけど、
自作ツールのTextBoxというものがありまして、
ウェブブラウザーで自分のローカルファイルにあるMDファイルをブラウジングできるというツールなんですけど、
最初はただのViewerだったんですが、
少し前に、
いちいちVS Codeでテキストファイルを開いて編集するのはめんどくさいなと思いまして、
ウェブブラウザー上でテキストファイルを編集できる機能を付け加えたんですね。
要するに、
HTMLのテキストエリアで表示させるだけなので、
コードの編集機能は全くないんですけど、文字を打つぐらいなら別にできると。
JavaScriptをかけると、
ただのテキストエリアでもある程度の機能を自分で付け足すことができるんですね。
例えば、Ctrl+Tを押すと今の日付を挿入するみたいなことですね、簡単に言うと。
テキストを選択した状態でブラケットを入れると、開きだけじゃなくて、
文字も自動的に保管されるよみたいな、僕が普段よく使っているツールで実装されている機能をちょこちょこ付け足したりとかしているうちに、
案外文章を書けるなっていうことに気がつき始めまして、
これで原稿を管理したらどうなるのかっていうのが気になったんですね。
テキストボックスっていうツールの一番のポイントは、
フォルダ管理しないという方式で、200以上のMDファイルが一つのフォルダの中に全部並んでいるのね、10日に。
だからもうFinder上ではほぼ使い物にならないんですけども、
基本的にViewer上に検索とかボタンとかリンクがあるんで、200何本があっても自由自在に使っていけると。
原稿もそこに並べようかなと思ったんですが、
どう考えても名前を付けるのがおそらくめんどくさいだろうということで、
仮にプロジェクト名のフォルダを作って、GTかな、GTっていうのを作って、そこに原稿を置いている形。
39:07
だから、そこに保存した原稿はテキストボックス上で閲覧もできますし、編集もできると。
テキストボックスっていうのはマークダウンを使うので、別に画像も置けますし、
ブラウザ上でPDFを閲覧もできる。
当然、記法を使えば、箇条書きも書けますし、ということができちゃうと。
画面を共有しよう。
画面を共有するのが早いな。
テキストボックスのこのProject GTっていう名前のページで、
ここからでもいけますし、
国語の検索ボックスに入れたら、これが表示されるということで。
しばらく見ない間にすごいことになってますね。
テキストファイルなんで、テキストと箇条書きを並列に並べても何もおかしいことはない。
ここに下に並んでるのがメルマガで書いたときの原稿なんですね。
それを素材にして、ここに今本文にしようと思うのがあって、
リンクが使えるので、ボタンを置いておくと、Next Chapterに行くと。
なるほど。
全然昔と違うものになってますね。
このボタン押すとちょっと時間がかかるんですけど、
これとこれを連結したPDFを作成してくれると。
それを当然ブラウザー上でも閲覧できるという形になってまして、
これが存外に面白い。
すごいですね。聞いてる人は全然わからないと思うんですけど。
今、美しいPDFができましたね。
これはちゃんとPandocだから、ラテフをかまして作られてるPDFですけど。
ラテフっぽい感じのPDFが。
原稿で初めて「1の1の1」とかって言いましたけど。
今までやったら、これが結構難しかったんですよね。
ボタン1個押すだけでPDFが作れて、それを閲覧するっていうことがなかなかできなくて。
ポイントは個別にファイルを作ってるけど、PDFは統合で作られるっていう形?
42:04
はいはい。そうですね。
VS Codeの場合は、例えばこのchapter00mdっていうファイルのプレビューは右側に出せる。
でも、統合したファイルを作るためには、統合ファイルをまず作らなければならない。
統合したファイルを作ると、さっき言ったようにコピペが絶対いるんですね。個別と統合。
それはちょっと手間すぎるかなと思って、個別にしたものを統合した。
でもPDFは絶対統合があればいいはずなので、別に一時個別に作る必要はないはずなので。
だからここで執筆して、こっちのPDFで読み返すっていう体制が結構スムーズに繋がるようになったなと。
これがもしうまいこといくんだったら、結構今後もこれでいけるんじゃないかなと今思っているところですね。
すごいですね。
こういうことをやりたかったら、LATFとかを直接使ってたんでしょうね。きっと今までだったら。
僕も結局、このボタンを押せば後ろでPandocが走る、LATFが走ってくれるんで。
PandocはこのMDファイルをLATFのソースファイルに変換して、そこからPDFにしてるんで。
要するにLATFを使ってるわけですね、基本的には。
LATFの面倒なあれを書かずに、マークダウンでそれができるってことですね。
できちゃうっていうところが一番のポイントで。
それが他の情報ツールと初めて同じとこに並んでて、しかも特に問題ない。
だからそもそもTextBox自体が、特定の目的のためのツールじゃなくて、あくまでビューアートして始めたんで可能になったんですけど。
大抵のことがこの上で完結しますし、もしエディター上に不満があるんであれば、
ここにVS Codeってボタンありますけど、これは今表示されているファイルをVS Codeで開けよっていうファイルの命令なので、
作業をVS Codeにすることも別にできますね。
できると。なるほど。
だからこれが今僕が新しくチャレンジしている原稿の書き方で、
この一時PDFを使いながら読み返すっていうことがどういう効果を持つのかっていうのを今確かめているとこですね。
PDFにするのは読みのためっていうことですね。
読みのためですね。やっぱり一番読みやすいはずで、しかもやっぱり書いたもので読み返すと飽きてきますし、
特に直接編集できてしまうから読みが止まってしまうんですよね。
気になったことを直しちゃう。
そのときに直したい気になったことが出てきたときにはどうする感じなんですかね。
45:04
コメントをどこかに書いといて原稿に反映でしょうね。
そのPDFの上に書くか。
例えば今日の日付書いてアウトライナーを作っておいて、そこにコメントを書くっていうことでも別にいいですし、
言語を開きながらでも別に修正はできますけども、多分やらないですよね。
コメントを書いておいてから後でっていうことにすると思います。
その辺はまた考えますけど、直接は意地じゃなくて、一回コメント挟むとは思いますね。
読む作業と書く作業を意図的に完全に分離しているわけですよね。
その方がやっぱりいいんじゃないですかね。最近思うのは。
僕ね、それができないんですよね。直したくなっちゃって。
直したくなるのは間違いないですけど、それで読むときは一回通して読んだほうがいい気がするんですよね。
読むときに確認するときって。
そうなんですね。だからプリントアウトしたんですよね。
そういうことだよと。プリントアウトの代わりにPDFイングしてるだけというか。
逆にデジタルのままだけどあえていずれに直接読めない状態で読むと。
やっぱり組まれてると、エディター上のものとは別な物質性を帯びてくるというか、硬さがありますね。
そうなんですよね。そうなんですよ。
で、結局僕がワードを使うというのは、読める状態の見た目とアウトラインを瞬時に切り替えられるから。
で、結局ワードには山ほど文句はあるんですけど、結局その代わりがない。いつまでたってもないんですよね。
はいはいはい。
で、やっぱり書く形と読む形って同じじゃないんですよね。
そうですね。
だから、たぶんその、なんだろう、このPDF、くらえさんがこのPDFで読み返すっていう時に感じてる必要性と、たぶん同じことだと思うんですけど。
そうなんですよね。だから僕がテキストファイルの有用性は痛いほど分かっていつも、あんまりそのテキストファイル上で作業ができないっていうのも、たぶんそのあたりにあるのか。
まあ、女性には慣れもあるんでしょうけど。
慣れもあるんでしょう。そのワードが持っている機能が、書くと読むを分離させてくれている点はだいぶ大きいですし、僕がこうやってわざわざ構築してるってことはテキストファイル上ではなかなか実現できないということなので、逆に言うと。
48:06
そうですね。
そこを考えた時に、プリントアウトも低いですし、ワードのモードとかビューを変えられるっていうところも大きいと思いますね。やっぱりテキストファイルだけでやってると、モードとかビューの変更がないんで非常に単調になりますし、自分が作業してるモード自身も混戦しやすいので。
そうなんですね。
やっぱり読み返しながら原稿を触るとね、僕の感じで足が遅くなる以上に細部にこだわりすぎというか。
はい、はい。それはわかります。
流れを追いかけるべきなのに細部に注目しがちというところがあって、それはね、やっぱり下げた方がいいなというのが実感ですね。
うーん。
うーん。
まあ、だからそんな現状そのとこない。今のところこれ始めてるのこの一つだけなんですけど、もしかしたらこのプロジェクトそのものが全部こっちに移動してくるかなという予感もありますね。
今やってるのは一つのプロジェクトだけ。
一つのだけ。これと似たことができたらなんかいろいろ面白いかなと。
これだから、例えばそのプロジェクトGTっていうのがそのプロジェクトのコラボの一番上にあるんですけど、これは要するに自分で配置できるんですよね。
順番が自分で決められると。まあ当たり前なんですけど。
これ元のMDファイルでこうなってる。
そういうことですね。だから、Evernoteの場合はこれを名前でコントロール、制御しなければならないですね、アルファベットの。
はい。
さすがに限界があると。で、他のツールの場合は逆に更新順とか作成B順になってしまって、自分の意思が反映されないと。
プロジェクトリストになるものはやっぱり自分で順番を決めないとほとんど意味がないと思うので。
だから、プロジェクトとか原稿とかをソードさせずにリストできる。
これはリストできる。内緒アレンジできるっていうことがこのツールを使うことの最大のメリットで。
多少の不便とかめんどくささがあるにしても、他のツールよりははるかにその良さがありますね。意思を反映している良さがありますね。
まあこのテキストボックス自慢は1時間くらいでも別にできますけど、結構大作なので。
そうですね。
この今スケジュールっていう欄があって、9月8日以降のスケジュールが出てるわけですね。
これ僕は手で入力してるんですけど、これスケジュール.mdtファイルが抜粋表示されてるんですね。
これ例えば開くと、これ過去のやつが全部ノータイム。
ボードで開いた時だけ今日以降のになるんですね。
51:03
この6とスケジュール帳がファイルの中で一体化してるんですけど、ビュー上では将来の予定しか出てこないっていう。
こういうのがやっぱりツールってビューが問題なのだっていうのがこの辺で思うんですよ。
だからどこをどう見せるかを選べば、どんなデータの景色であっても多分問題がないという感じがここにはありますね。
なんかもうこれ完全なダッシュボードになっちゃったんですね。
ここはボードっていうページなんで。
例えば取材というページやったら、自分のテーマごとのファイルがありまして、
こうやって書くことについてが集まってるファイル。
これ読むことについてがこのあって、これ開くとこれ開くとまた個別のファイルになってるわけですね。
はいはい。これは聞いてる方のためにやるんですけど、このテーマっていうのはちょっと看板的な感じの表示になっていて、
その看板の一つをクリックするとその個別のファイルがあると。
だからこういう風にテーマを一覧できる、しかも並べられる、これ僕は順番で勝手に並べてるだけなので、
もう配置できるっていうのも大きくて。
この苦心したポイントはファイルの名前なんですね。
テーマの名前にしないっていう。
ファイルのそれぞれが主題01、主題02、主題03になってるんですよ。
主題1には例えば仕事術に関してのアイディアが集まってるんですけど、
一般的にはその仕事術のアイディア.mdっていう名前にしたいんですが、
それをすると言ったらトップダウンになってしまうわけですね。
はいはい。
なのでいつでもそのテーマ性が変えられるように、変えても問題ないように、
ファイルの名前をあえて抽象的なものに留めておくっていうのがこのページの工夫ですね。
なるほど、なるほど。
あとこう、ページによって全部違うんですけど、
ここに上にあるページって全部他のページからの抜粋が集まっている。
だから階層でいうと1個上のページばっかりですね。
この青を押すと個別ページに飛ぶっていう形になってまして、
だからもうほとんど僕必要な情報ってここに集まってますね。
ほんとですね。
この辺日記とかカッターフォンとか。
おお。
だから他の情報ツールではうまくなしになかったことができている。
なぜならばそのページごとにデザインが違うからっていう。
そうですね、全く違いますね。
見えない人には全然わからないでしょうけど、いくつかボタンを押したんですけど、
全ページレイアウトが違うんですね。
54:00
うんうん。
ちょっとタブでページを切り替えられるみたいになってて、
切り替えると全部こうレイアウトが違う。
それぞれの合わせ、自分が適切だと思ったページのデザインになっている。
それぞれがボタンを押すと個別ページになっている。
個別ページの集合ページ、インテグレートページと言うんですけど、
僕自身のデザインによってなっている。
これを少なくともエバーノートとかでは難しいですね。
多分ノーションを持ってこないといけないですね、きっと。
ノーションでもここまで自由にはできないはずです。
できないでしょうね。
うん。
なので、はい。
ブロックが結局みんな違いますもんね。
そうそうそうそう。
この、すべきの形が。
この左上にあるのって、プロジェクトの今までの歩みが出てるんですけど、
今週はこれをやろうみたいなことが書かれてるんですけど、
個別ページ開くとログがあるんですね。
で、これボードページだとログが隠されて、ヒドゥンされてるんですよね。
うん。
これもここのページと一緒で、見たい情報がページごとに違うようにデザインできるっていう、
これもJavaScriptのおかげなんですが。
これ一つ一つのページのこのデザインは手動でやってるんですか?
はい、そうです。手動でやってます。
そうですよね。
だから手動でやるのがめんどくさいから、フレームワークを使うという話になって、
結局、非個性的にならざるを得ないということがあるわけですね。
なるほど、確かに確かに。
で、例えばこのプロジェクトごとやったら、個別にデザインしてますけど、
共有できる部分もたくさんあるわけですね。個別の部品で言えば。
コピペして使い回せる部分もあるんで、だからもう別にそれぐらいでいいんじゃないかなと。
デザインする手間を惜しまない方がいいんじゃないかなと。
うーん。
そんな感じですかね。
なるほど。
うーん。
まあ、大脱線で、しかも聞いてる人にはさっぱりでしょうけども、
一回、一回そのあれですね、動画会やってこれを自慢しましょうかね。
うーん、いいんじゃないですかね。
これはやっぱり物を見ないとわからないですね。
わからないですよね。
一回、そうですね、動画で大会議。
これでもね、本当に僕自慢以上の話で、
情報ツールを自作できることっていうのは、
結構クリティカルにパソコンを使う意味っていうのが変わってくると思いますね。
なるほどね。
こんなことができるんやっていうのを改めて感じてますね。
うーん。
なんか、結構20年ぐらい前にこういうダッシュボード的なものがすごい流行ったというか、
57:06
流行らそうと誰かがしていたのかわからないですけど、
で、企業なんかが結構こういうデジタルダッシュボードみたいな言い方で、
導入してたと、まあ今でもしてるのかもしれないですけど、
あんまり個人でそういうものを使っているという話は、
当時はちょっとあったけど、今あんまり聞かないような気がするんですけど、
やっぱりそれは、なんかカスタマイズできるとは言っても合わせなきゃいけなかったから。
っていうところだと思いますね、きっと。
やっぱ不完全なレゴというか。
そこまで大胆には変えられないっていう。
せめて順番が変えられますよとか背景変えられますよとかっていうそのレベルであって、
デザインできるっていうレベルの裁量は多分なかった。
ないんでしょうね。
それはやっぱり中途半端っていうか、
むしろそれやったら手間だけが多いような気がして。
見た目ほど便利にならないのに、
画面だけやたらと細かく仕切られちゃって使いにくくなるみたいなことが起こったんですよね。
はいはいはいはい。
なんだけどそれはやっぱり応色性だから結局そういうデメリットの方が目立っちゃうのかもしれないですよね。
そうやと思いますね。
だからさっき見せた全てのページってすぐあの形になったわけじゃなくて、
作り変えながら、ここの部品いらんなとか、ここはサイズもっと大きい方がいいなっていうのを繰り返してたどり着いたんですね。
ある種の過程がある、道中があるっていう。
そこを省いた使いやすさって多分ないと思うんですよ。
自分にとって何が使いやすいかっていうのを発見する度なのでそれは。
だからそういう意味で手間をかけてほぼゼロから作っていく。
テキストボックスがやってるのは、MDファイルを読み込むっていうところまでしかやってなくて、
全てのデザインはそのMDファイルそれぞれが持ってるんですね。
SSをどうするとかJavaScriptとか個別に持ってるんで、それを個別に作っていったらいい。
ポイントは個別にしか作れないんで、何をどんなページ作ってもテキストボックスの本体に影響がないことなんですね。
デザインは要するに部品のパーツの側がデザインを持ってるっていうことなんですね。
だからテキストボックス本体自体はほぼいじらなくて、もう全て個別ファイル自身で同行していくっていう。
気に食わなかったそのMDファイルを消したら、もうそれは一個ゼロになるっていうだけの話で。
しかももっと言うと消さなくてもリンクを外せばテキストボックス上から見えなくなるんで、
1:00:01
なくなったら等しくてファイルが残ってるっていう形になるんで。
なるほど。
だから小さいデザインを積み重ねながら作っていけるという意味でもやっぱりデジタル的ですし、
既存のファイルにあんまりない、特にノーションは逆に最初に作っていきましょうみたいな感じなので。
デザインの自由性が高いといっても方向性がやっぱり反対な感じがしますね。
確かにこれは動画自慢会やるといいですね。見たいですね。
自慢したところで一応システムを公開して誰でも使えるようにはできるんですけど、
個別のページは皆さんでデザインしてもならないわけですが、必要性としては。
でも大きな枠組み、ローカルファイルのMDを読み出しますよっていうところまでは全然共有できるんで。
いやこれほんと面白い。面白い以上に便利ですね。便利としか言い、だって便利に作ってるわけで便利じゃないわけがないんですけども。
でも結構時間はかかりましたけどね。
いつ頃からやってましたか?1年以上やってましたけど。
やってましたね。で、そのページを編集できるようになったのと、
ページの中にページを読み出せるようになった。さっきみたいな統合ページを作れるようになった。
のでやっぱりだいぶ変わりましたね。
最近は偉大だなと思いましたけど。
情報整理ツールのエトセトラって色々あるんですけど、複数で見てこそなものも結構あって、
Obsidianはやっぱりその辺がいいんですよね。そのページを複数開けるっていう。
Evernoteの場合は一つのページ開いてるときは他のページは見られないっていう形になってるんで、
それを解決するのがホーム画面なんですけど、あれのアレンジ性も低いと。
で、セットで見たい情報と、あと何ていうのかな、
イント的に見に行かないけど見たい情報みたいな。
っていうところもセットで表示させてこそみたいなところがあるので、
だから情報を合わせられるっていうところが、別にこのツールに限らないですけど、
情報整理ツール、特にセルフマネジメントとかを扱うようなツールの場合って、
複数の情報が一画面で見られることって結構大きいかなと思いますけど。
だから結局これが難しいのって、ツールを単に作る技術だけじゃなくて、
自分が情報整理というか、自分がどういうふうに情報を見て、
どういうふうに使いたいかっていうのが分かってないと、
それを分かろうとする考えのベクトルを持ってないと、
1:03:07
枠だけ作っても多分うまくいかないような気がするんですよね。
間違いなくそうでしょうね。
だから結局、今見せてもらったやつは、
クラシタさんが便利なように作ったんだけれども、便利なように作ったという以上に、
クラシタさんが自分の情報との向き合い方というのは、
どういうことなんであるのかっていうのを考えた結果なわけですね。
だから、両輪がないと。
そうですね。
逆に言えば、それがあれば。
便利ですし、このツールを作ったことで、初めてそれをより深く考えられるようになったっていうのはありますね。
今までやっぱり、枠組みの中でどう便利にするかっていうライフハック的な感じでしたけど、
必要なものを作っていいっていうところになると、
もう一段深く自分にとって情報をどう向き合ったらいいのかっていうのを考えられるようになったし、
やっぱりただ頭で考えているだけでは、ここまでは分からなかったと思いますね、きっと。
そうか。ツールを作ろうとすることで初めて考えられることがあるっていう。
特に仮説を持ってこれ便利そうだなってやって、やっぱ違うっていうのを繰り返すことで、
フィードバックというか精度が高まっていくところがあるんで。
やっぱり、俺が考えた最強の情報ツールっていうものが、よりリアルになっていく感じがありますね。
思ってて実装しても便利じゃないっていうのが結構あるんでね。
あると思うんですよね、それ。
それを分かるだけでも面白いですね。
面白いですね。
だから、原稿管理の幅を超えた話ですけど、原稿管理でも一部になっている情報ツール。
パソコンは本当に何でもできるようになっているなってちょっと思いましたね。
なるほど。
という話が聞いている方にどれくらい伝わったのかちょっとあれなんですけど。
見てみたいという方はぜひコメントをつけていただければ、動画会をやってみたいと思います。
動画会っていうか、YouTubeで打ち合わせキャストやけど、僕のブラウザがずっと表示されているっていうタイプの会かな。
でもたまにそういうのあってもいいかもしれない。
そうですね。画面が必要な会はね。
ほぼポッドキャストやけど画面だけあるみたいな会があってもいいですね。
そのとこかな。
聞いている人が原稿を書いている方が多いかもしれませんけど、
ファイル全般をどう扱っているか、何かバックアップとかどうしているのかっていうのはちょっと、もしご意見あれば、
1:06:03
#打ち合わせキャスト、ひらがなで打ち合わせアロバイトでキャストまでいただければと思います。
何かたくさんご連絡したいこととかってございますかね。
特にはないです。
はい。じゃあ今回はこれまでにしたいと思います。お疲れ様でした。
お疲れ様でした。
