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