generated at
業務でScrapboxを使うイメージが湧かない
今の業務のドキュメントはカチッとしたものがほとんどだな
GitHubで管理してPRでチームメンバーでレビューして・・みたいな
存在する文書は最新である事が期待され、腐らないように運用できている(デザインドキュメントのようなものを除く)
腐らないのがすごい基素stastatakkermeganii
腐らせないために、ドキュメント内容に重複をなくすことや、不要なドキュメントを作らないみたいな圧があるように思うinajob
これが良い場合もあるし、悪い場合もありそう
悪い面は業務でScrapboxを使うイメージが湧かない#6297fec06eb40600001c9b9eとして顕在化?しているのかも基素
知らぬ間に文書の内容が変わっていること、壊れていることを避けたい
手順書、設計書のようなもの
Scrapboxで扱うメモと少し性質が違う気がする
Tipsみたいなものが個人の中に閉じてしまっている気がするのでScrapbox的な文書置き場があっても良いのかも?
ドキュメントが腐っていても良い?
属人化しちゃってるtakker
知ってると効率が良くなるが、知らなくても何とか業務はできる、みたいなものが多い気がするinajob
まぁ一種の属人化なのはそう
Scrapboxはプライベートでそこそこ使っているが、いまいち業務でうまく使えているイメージが沸かないな・・
個人メモを入れるのには良いと思うが、複数人で使うイメージがわかないな・・
ちょっとわかるcFQ2f7LRuLYP
scrapbox.io/nota-private-sampleみたいなイメージ?takker
今会社で使っているツールで言うとGitHubの文書リポジトリ, Issue, Slackでの業務連絡・雑談が一か所にまとまってる感じにみえるinajob
しかし現状のワークフローがあるのですべてをScrapboxに移すのは色々考える必要がある気がする
すべては難しい気がするyosider
通知したい系とか
Slackの雑談ならすぐ移動できそうだが・・
GitHubのIssue
ラベルやマイルストーンによる運用が確立している
ex 今期やるタスクの分類、優先度付け、メンバーへのアサイン
GitHubで管理している文書
確認すべき人が変更点をapproveしたことが保証できている
議論だけScrapboxでやって、清書をこういうところでやるとか?yosider
それはアリですねEtherpadでそういうのをやったことがありますinajob
ショットでやるならEtherpadで十分なので、蓄積する良さみたいなのがあるとScrapboxでやる意味が出てくる?
+1sta
あとはリンクによる繋がり
GitHubのIssueや SlackのThreadにだらだらやったことを書いていくと、ちょいちょい同僚が見てくれていて、アドバイスくれたりするやり方をしているが、これはScrapboxでもできるかもしれないし、ナレッジもGitHubのIssueよりは活用しやすいか?
気の合う同僚と数人で始める?
この場合もビジネス利用に当たるのかな?
普段の雑談や喫煙室談義で仕事の話がカジュアルにされる、みたいな話を聞くが、ああいうのをテキストで非同期でできるのがScrapboxだと思っているsta
NotaがScrapbox上の議論で決めた諸々の決定事項をどうしてるか、はきになるstastainajobinajob
何もしない(スクボ見ればええやん)
何もしない(コードに実装してるのでそれが答え)
スクボにサマリーとかまとめなおす
何かちゃんとしたドキュメントを書く etc
おそらく「何もしない」になってるんじゃないかと思っていますsta
業務では「その諸々の決定事項をちゃんと正式に残さねばならない」みたいな固定観念がある気がする
+1inajob基素yosider
業務でScrapboxを使いたい、という場合、雑談を越えて使う場合は、この固定観念をどう取っ払うかが鍵になりそうinajob
そこまで使いたい、という人はあまりいない気がするが・・?
使って価値が理解できない状態で推しても↑こういう判断をされて終わる気がする基素
VRやってない人にVRの価値がわからないのと同じ構図だと思う基素
パラダイムシフトなので理解されづらい
小さく使って価値を体感してもらうのが一つの手基素
これを固定観念と言い切ってしまうのはバイアスがあると思うnishio
法律や税金の関係でキチンと情報を残さないといけないケースはある
これに関してはその要件を満たす必要がある基素
「キチンとしないといけないもの」と「しなくていいもの」があり、しなくていいものまでキチンと管理しようとしてしまうことと、しなくてはいけないものを雑に扱ってしまうこととが揉め事を起こしてる感じ
社内規定とかもある意味そうかもsta
PDFレベルのガチガチ文書派、Markdownレベルでいい派、スクボなどメモレベルでいい派
Markdownレベルはクックパッドがやってたっけか →Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
GitHubだとリポジトリがキチンとした文書、WikiとかIssueにはそこまできちんとしていない文書を扱っている気がするinajob
SIでもお客様の指定で「こういう文書をこの形式でつくれ」となることがあるsta
Scrapboxはこれを緩和できる
んなことしなくても業務は成立するんですぜ?というアンチテーゼ
実際、Notaでは緩和できている
Scrapboxで日々雑談的に議論していくだけでうまくいってる、なんとかなってる
これが業務でScrapboxを使うということなのだ!
って感じなのかなと想像しているsta
とはいえ「快適に書けるツール」じゃないと固定観念に争うのもかえって厳しいかも
会社でちょうど良い感じのツールがなくてBox Notesでメモや議論をしてるんですが、きつい……sta
どういう経緯でツールが選定されたのか気になるyosider
単にデフォルトで使えるツールの中でマシなのがこれだった、ですねsta
JTCなので想定されてないツールを使うハードルがめちゃくちゃ高い

そもそも、チームメンバーが全員、ちゃんとした日本語を書けますか?という疑問があるmiyamonz
scrapboxが良く機能するのは、誰もが編集できるから
ちゃんとしたドキュメントが求められてしまうのは、ちゃんとしたドキュメントが書けないから
誰もがすぐに修正できるなら、なにか変な文章を見つけたらその場で修正すればいいだけ
書いた人に確認取って、修正して、完了
それができないのは、文章を完結させられるメンバーが、チームの一部の人だけだからなのでは?
文章を書ける人にとっても、わざわざ書いた人に確認しないと修正できないのは面倒すぎると思うyosider
わかるmiyamonz
文章の意味が分からないときは確認する必要はある
たんなるtypoとかなら、確認取らずに修正すればいい
「こう書いたほうが伝わりやすそう」くらいの修正も、とりあえず書いてみて、なんか誤解があるなら戻そう、という感じで事後報告で修正したい
文脈の共有不足による勘違いは起きがちなので、確認はとったほうがよいとは思うが
データが復元できるのなら、事後報告、やって間違ってたら戻す、でよいはず
Scrapboxでも、他人が書いた文を消すことは推奨されず、そうしたいなら確認する必要があるyosider
(コメントを箇条書きでぶら下げるという形で)他人が書いた文に直接書き込めることで、認知的負荷が低いやり方で議論や修正ができるのがScrapboxの良さ?
チーム全員の文章力が一定水準に達していないと、scrapboxを回すのが難しい気がするmiyamonz
この場合、
そもそもドキュメントツールを使わない
使っているが、scrapboxのような柔軟性はなく、かっちり書いて階層構造に管理しなきゃいけないありがちなツールになる
文章力が高い人だけが、書き手側として動くという分業が発生する気がする
Kitenを思い出したsta
書くエリア(GitHub)のラッパーつくって、読者はラッパー側を読む
ラッパーには文書中の誤りをかんたんに報告できる機能がある(ので報告されやすい)
書けない読者でも報告はできる

文章力以外にも色々必要条件はありそうだなと(最近社内で啓蒙していて)感じているsta
うちはGitHubのIssueなどで非同期テキストコミュニケーションは出来てる気がするinajob
ややターン制コミュニケーションになってしまうのが残念だが・・
再利用性が低いのが気になってる基素
蒸し返せない・忘れる・提示できない
再利用したい部分は面倒でもGitHubリポジトリの文書として転記またはissueのURLを記録しますねinajob
すごいチーム!基素

もっと書くハードルを下げることの重要さが世間に認められてほしいyosidersk6cleine
管理上の多少の失敗を許してでもやる価値はあると思う
+1sta

書いたものがどこにあるのかわからない問題はとても大きいと感じている基素
書いてはあるけど、色々なところに書いてあって結局書いた人しかわからない
ともすると書いた本人もわからないsta
将来的にはLLMが全部読んで解決という方向もある
Scrapboxならrelated page list searchからたぐれなければ「書いてない」と判断して良いだろう
当初は、どこに置いてあっても(全文)検索すれば見つかるから、場所なんてわからなくてもいいのではと思ってたtakker
けど、検索すれば見つかったのに、自分の知っている場所だけ探してなかったから人に聞いたケースが2回続いたので、検索メインのメンタルモデルにするのは容易ではないと思った
多分この例は違うと思いますが、情報が増えるほど検索が機能しづらくてこまる(例:井戸端で切り出されていないAさんの発言を検索するのは難しい)基素
みんなが検索をする集団を仮定しても問題がある
Discordの運用で、チャンネルがたくさんあってわかりにくいという意見があった
伝えたいことは全部メンションしている(つもり)だから、どのチャンネルに情報を書こうが伝わると思うのだが、どうやらそうでもなさそうだ
わかりにくいを具体化する作業が必要だとおもう基素