業務でScrapboxを使うイメージが湧かない
今の業務のドキュメントはカチッとしたものがほとんどだな
存在する文書は最新である事が期待され、腐らないように運用できている(
デザインドキュメントのようなものを除く)
腐らせないために、ドキュメント内容に重複をなくすことや、
不要なドキュメントを作らないみたいな圧があるように思う
これが良い場合もあるし、悪い場合もありそう
知らぬ間に文書の内容が変わっていること、壊れていることを避けたい
手順書、設計書のようなもの
Scrapboxで扱うメモと少し性質が違う気がする
ドキュメントが腐っていても良い?
知ってると効率が良くなるが、知らなくても何とか業務はできる、みたいなものが多い気がする
まぁ一種の属人化なのはそう
Scrapboxはプライベートでそこそこ使っているが、いまいち業務でうまく使えているイメージが沸かないな・・
個人メモを入れるのには良いと思うが、複数人で使うイメージがわかないな・・
ちょっとわかる
今会社で使っているツールで言うとGitHubの文書リポジトリ, Issue,
Slackでの業務連絡・雑談が一か所にまとまってる感じにみえる
しかし現状の
ワークフローがあるのですべてをScrapboxに移すのは色々考える必要がある気がする
すべては難しい気がする
通知したい系とか
Slackの雑談ならすぐ移動できそうだが・・
GitHubのIssue
ex 今期やるタスクの分類、優先度付け、メンバーへのアサイン
GitHubで管理している文書
確認すべき人が変更点をapproveしたことが保証できている
議論だけScrapboxでやって、清書をこういうところでやるとか?
ショットでやるなら
Etherpadで十分なので、蓄積する良さみたいなのがあるとScrapboxでやる意味が出てくる?
+1
あとはリンクによる繋がり
GitHubのIssueや SlackのThreadにだらだらやったことを書いていくと、ちょいちょい同僚が見てくれていて、アドバイスくれたりするやり方をしているが、これはScrapboxでもできるかもしれないし、
ナレッジもGitHubのIssueよりは活用しやすいか?
気の合う同僚と数人で始める?
この場合もビジネス利用に当たるのかな?
普段の雑談や喫煙室談義で仕事の話がカジュアルにされる、みたいな話を聞くが、ああいうのをテキストで非同期でできるのがScrapboxだと思っている
何もしない(スクボ見ればええやん)
何もしない(コードに実装してるのでそれが答え)
何かちゃんとしたドキュメントを書く etc
おそらく「何もしない」になってるんじゃないかと思っています
業務では「その諸々の決定事項をちゃんと正式に残さねばならない」みたいな固定観念がある気がする
業務でScrapboxを使いたい、という場合、雑談を越えて使う場合は、この固定観念をどう取っ払うかが鍵になりそう
そこまで使いたい、という人はあまりいない気がするが・・?
使って価値が理解できない状態で推しても↑こういう判断をされて終わる気がする
VRやってない人にVRの価値がわからないのと同じ構図だと思う
小さく使って価値を体感してもらうのが一つの手
これを
固定観念と言い切ってしまうのはバイアスがあると思う
法律や税金の関係でキチンと情報を残さないといけないケースはある
これに関してはその要件を満たす必要がある
「キチンとしないといけないもの」と「しなくていいもの」があり、しなくていいものまでキチンと管理しようとしてしまうことと、しなくてはいけないものを雑に扱ってしまうこととが揉め事を起こしてる感じ
社内規定とかもある意味そうかも
PDFレベルのガチガチ文書派、Markdownレベルでいい派、スクボなどメモレベルでいい派
GitHubだとリポジトリがキチンとした文書、WikiとかIssueにはそこまできちんとしていない文書を扱っている気がする
SIでもお客様の指定で「こういう文書をこの形式でつくれ」となることがある
Scrapboxはこれを緩和できる
んなことしなくても業務は成立するんですぜ?というアンチテーゼ
実際、Notaでは緩和できている
Scrapboxで日々雑談的に議論していくだけでうまくいってる、なんとかなってる
これが業務でScrapboxを使うということなのだ!
って感じなのかなと想像している
とはいえ「快適に書けるツール」じゃないと固定観念に争うのもかえって厳しいかも
会社でちょうど良い感じのツールがなくて
Box Notesでメモや議論をしてるんですが、きつい……
どういう経緯でツールが選定されたのか気になる
単にデフォルトで使えるツールの中でマシなのがこれだった、ですね
JTCなので想定されてないツールを使うハードルがめちゃくちゃ高い
そもそも、チームメンバーが全員、ちゃんとした日本語を書けますか?という疑問がある
scrapboxが良く機能するのは、誰もが編集できるから
ちゃんとしたドキュメントが求められてしまうのは、ちゃんとしたドキュメントが書けないから
誰もがすぐに修正できるなら、なにか変な文章を見つけたらその場で修正すればいいだけ
書いた人に確認取って、修正して、完了
それができないのは、文章を完結させられるメンバーが、チームの一部の人だけだからなのでは?
文章を書ける人にとっても、わざわざ書いた人に確認しないと修正できないのは面倒すぎると思う
わかる
文章の意味が分からないときは確認する必要はある
たんなるtypoとかなら、確認取らずに修正すればいい
「こう書いたほうが伝わりやすそう」くらいの修正も、とりあえず書いてみて、なんか誤解があるなら戻そう、という感じで事後報告で修正したい
文脈の共有不足による勘違いは起きがちなので、確認はとったほうがよいとは思うが
データが復元できるのなら、事後報告、やって間違ってたら戻す、でよいはず
Scrapboxでも、他人が書いた文を消すことは推奨されず、そうしたいなら確認する必要がある
(コメントを箇条書きでぶら下げるという形で)
他人が書いた文に直接書き込めることで、認知的負荷が低いやり方で議論や修正ができるのがScrapboxの良さ?
チーム全員の
文章力が一定水準に達していないと、scrapboxを回すのが難しい気がする
この場合、
そもそもドキュメントツールを使わない
使っているが、scrapboxのような柔軟性はなく、かっちり書いて階層構造に管理しなきゃいけないありがちなツールになる
文章力が高い人だけが、書き手側として動くという分業が発生する気がする
書くエリア(GitHub)のラッパーつくって、読者はラッパー側を読む
ラッパーには文書中の誤りをかんたんに報告できる機能がある(ので報告されやすい)
書けない読者でも報告はできる
文章力以外にも色々必要条件はありそうだなと(最近社内で啓蒙していて)感じている
うちはGitHubのIssueなどで非同期テキストコミュニケーションは出来てる気がする
再利用性が低いのが気になってる
蒸し返せない・忘れる・提示できない
再利用したい部分は面倒でもGitHubリポジトリの文書として転記またはissueのURLを記録しますね
すごいチーム!
もっと
書くハードルを下げることの重要さが世間に認められてほしい
管理上の多少の失敗を許してでもやる価値はあると思う
+1
書いたものがどこにあるのかわからない問題はとても大きいと感じている
書いてはあるけど、色々なところに書いてあって結局書いた人しかわからない
ともすると書いた本人もわからない
将来的にはLLMが全部読んで解決という方向もある
Scrapboxならrelated page list searchからたぐれなければ「書いてない」と判断して良いだろう
当初は、どこに置いてあっても(全文)検索すれば見つかるから、場所なんてわからなくてもいいのではと思ってた
けど、検索すれば見つかったのに、自分の知っている場所だけ探してなかったから人に聞いたケースが2回続いたので、検索メインのメンタルモデルにするのは容易ではないと思った
多分この例は違うと思いますが、情報が増えるほど検索が機能しづらくてこまる(例:井戸端で切り出されていないAさんの発言を検索するのは難しい)
みんなが検索をする集団を仮定しても問題がある
Discordの運用で、チャンネルがたくさんあってわかりにくいという意見があった
伝えたいことは全部メンションしている(つもり)だから、どのチャンネルに情報を書こうが伝わると思うのだが、どうやらそうでもなさそうだ
わかりにくいを具体化する作業が必要だとおもう