アジャイル開発の現場で発生しやすい問題のひとつが、ナレッジの蓄積や共有化がスムーズにいかないこと。結果的に、属人化が進み、特定の人しかわからない情報が多くなったり、社内の知見を活かした人材育成ができないといった弊害を生んでいます。
その課題に対し、対策としてScrapboxが活用できるのではないでしょうか。アジャイル開発の専門家である、Nota Inc. Service Evangelism Lead長沢智治と、ギルドワークス株式会社所属、DevLOVE関西主催者で現場コーチとして活躍する中村洋氏が対談を行いました。
アジャイル開発チームが情報共有ツールに求めるもの
まず最初に、アジャイル開発の現場におけるナレッジの蓄積や共有化に関する考えやスタンスをお聞かせください。
中村洋（以下、中村）：そもそも「開発現場でナレッジの共有は必要か？」という疑問があります。
プロジェクトが円滑に運ばなかった際に、その原因を確認すると「情報共有がきちんとできなかった」「お互いの認識が異なっていた」といった回答が多いんです。じゃあどうしたら解決できるか？と促すと、「共有できるようにドキュメントを残す」「認識をあわせるために会話を行う」などがあがりますが、共有や認識を完全にあわせることは不可能だと感じています。人間はひとりひとり違う生き物である以上、どれだけドキュメントを残そうが、会話しようが、解釈が異なるのは当たり前なんですよ。
それならば、共有の確率をあげるより、お互いの認識がずれたときに早めに検知できる仕組みをつくったり、認識のずれをなるべく小さくする取り組みを行ったほうがいいのでは？と。
長沢智治（以下、長沢）：そうした現状があり、「なぜナレッジを共有しないといけないのか？」というところに行きつくわけです。
なにかアクシデントが起きた際にも、よくあがるのが「情報を共有していなかった」。ところが、いま中村さんがお話したように、「情報共有していたらそのアクシデントは起きなかったのか？」と突き詰めていくと、そうじゃないわけですよ。
ナレッジの共有にはコストがかかるため、果たしてそのコストに見合った効果が得られるのか？については、誰も検証していません。「情報が残っていないとまずい」「共有されていないからアクシデントが起きた」といった先入観でしかないんです。
中村：単に犯人探しになってしまっているんですよね。
長沢：それもありますね。そうした現状のなかで僕の考えとして、最近では形式知と暗黙知の話をしています。
「形式知化しよう」という表現がよく出てくるのですが、実はアジャイル開発とは真逆の概念なんですね。そのため、アジャイルを形式知化するとコストがかかるということもありますが、形式知化を目指すのではなく「暗黙知を集合知化して闘う」というスタンスでいます。
中村：とはいえ、最近のツールには形式知化や情報共有の促進に活用できるかな？というものも登場しています。
既存のドキュメントの体系、たとえばSIerにおける詳細設計があるものと、最近登場してきたScrapboxに代表されるもの。両者の大きく異なるポイントは、関連付けのしやすさです。
SIerなどは、「このドキュメントも見ておいたほうがいい」という関連付けがしにくい。対する後者の考え方は、レコメンドされるツールが多く、関連を表現しやすい構造になっているものがメインです。こうした観点から、ドキュメントやナレッジの共有に関するコストが多少低くてもやれるのかな？とは感じているんですね。
長沢：ただ、それだと結局のところ、形式知化しやすくしているだけですよね。
中村：確かにイノベーションは起きていないですね。
長沢：そう、起きていないんですよ。
SIer時代のファイル共有やシェアポイントは、ツリー構造と統制で無理やり情報を出させていました。ただ、それだと正しい情報しか出せない。じゃあ正しい情報はなにか？となると、読みやすさや作法といった守らなくてはいけないハードルが高すぎて、結果的に情報の共有ができませんでした。
そこからConfluenceなどが登場し、比較的やりやすくなりましたが、あくまで形式知の話でしかないんです。そこの域は超えていないし、イノベーションは起きていないと感じているんですね。
中村：わかっていることしか形式知化できない、と。
長沢：そうなんですよ。本来、形式知化すべきものが、よりやりやすくなったという点では非常に便利なイメージがありますが、ナレッジ共有は「形式知化しにくい部分まで形式知化させる」ことがもっとも重要です。少なくとも、形式知化できるものはすぐに形式知化して、形式知化しづらいものの扱いをきちんと考えなくてはならない。
アジャイル開発でいえば、「暗黙知を集合知化して闘う」というスタンスにおいて、その暗黙知のボリュームなど必要要素のレベルがいくつかありますが、そうしたところを正しく知る機会をつくる、といったことこそが大事なんですね。
中村：私がコーチをしていて感じるのは、なにかあると情報共有が指摘されるものの、そもそもどこのルートが足りていないのかがわからない、ということ。
形式知ができていないだけなのか？暗黙知を暗黙知としてお互いノウハウを出しあうプロセスがうまくいっていないのか？理由が大きく違ったらツールや方法論も変わってくるのに、「情報共有ができていないから、じゃあConfluenceを入れよう」などとやっている。いや、そこじゃないのに、とずっと思っているんです。
長沢：戦略がないんですよね。とりあえずツールを放り込んでおけばなんとかなる、を繰り返している。
中村：「まずやってみよう」というのはある意味、正しいのですが、その先がないですよね。
長沢：設計における話をすると、個人レベルとチームレベルで必要なものや方法論が違います。個人とチームが両翼でまわりながら変わっていくのですが、そこが議論されず、「まずは暗黙知は形式知にしよう」になってしまっている。強迫観念でやらざるを得ない感覚なのかな、と。
そうすると、最終的には正しいものを入れないといけない。じゃあ、レビューしよう。正しくないものは入れないようにしよう。正しくないものにはドラフトとつけよう。そのうちに、なにか変更が生じたら、それに応じて更新しているものと更新していないものが出てくる。そうなってくると、どちらが正しいのかわからない。結果的に、もうどれも役に立たないね、となってしまう。実はこういうことが多くの現場で起こっているんですよ。
僕が見ているなかで、ツールを用いて形式知の共有に唯一成功しているのは、すべてが不確かな情報であることを認め、「まずは放り込もう」というスタンスで実践している現場です。その大前提がないと、やっぱりむずかしいですね。
中村：形式知に関する認識の違いというのもあるかもしれないですね。
形式知を「正解のドキュメント」「知識」と捉えている人が多いのですが、アジャイル開発の現場の人たちからすると、たまたまその状況でわかったことを記したものでしかなくて、もしかしたら明日になれば変わっているかもしれない。つまり、ツールもそれを前提として組み上げられているかどうかで、だいぶ変わるんじゃないですかね。
長沢：たとえばConfluenceなどがそうですが、いいね機能やメンション機能が搭載されていて、これは確かにすごく便利なんです。メンションされていれば「自分が関係しているな」とわかるし、いいねがついていれば「読んだよ」というライトウェイトなフィードバックになる。
こうした機能や概念は、ドキュメントを書いて共有するという意味では促進面でプラスになります。ただし、あくまで促進するためのものでしかない。もっと言えば、そうした機能がなくても共有しあえるようになるべきである、というのが本来の在り方ですね。
先ほど中村さんがお話されていたことですが、共有や認識をあわせることは不可能で、なぜならば人によって解釈や捉え方がまったく異なるのは当たり前だから、と。まさにその通りなんですよ。つまり、あるべき論で進めると表層の上辺しか集まらなくなってしまう。それ以上のことをやろうとすると調整事が増えていくんですよね。
本来はツールでの対話やドキュメントが大事で、この部分をうまく補完できるツールや方法、考え方が生まれてこないと、「形式知を集めよう」というレベルから脱却できません。アジャイル開発でも「正しいものはなにか？」という正解探しになってしまい、現状を知ればいいだけなのに「こうあるべきだよね」「こうなっていないのは悪だよね」「じゃあ誰が悪いの？」みたいになってしまう。振り返りは必要ですが、また違った次元でこうした状況が発生して、なかなか情報が残せなくなっています。
ナレッジ共有における情報共有ツールの課題と、たどってきた変遷
お話いただいた、開発現場におけるナレッジの蓄積や共有化に関する考えやスタンスを踏まえたうえで、情報共有ツールの課題や、これまでの変遷をお聞かせください。
中村：まずツリー構造ですが、あれで共有を促進させるのは無理だと感じています。途中で必ず「この情報はどちらに入るんだっけ？」というように、ツリー構造だけだと正解探しになってしまって大変だからです。最近のツールの構造や概念は、明らかにツリー構造は諦め、タグ付けなど別の機能で共有を促進させようとするものが多いですね。
長沢：便利なので、おのずとツリー構造が左側にあるという形になっていますが、すごく引っ張られている感じがします。決めた人の想いなどに縛られてしまうというか、ドキュメントの本来の法則と一緒で、組織構造や、声の大きな人に引っ張られるところがあるんですよ。
中村：ツリー構造をつくると、そこに描かれない種類の情報は残らないですよね。そもそもその情報が載っていないから誰も必要とは思わないし、その情報が必要ということに思い至らなくなってしまう。
長沢：ツリー構造が全部悪いわけではないんですが、ツリー構造があることで、さらに形式知の表層しか集まらなくなっていますよね。
中村：新たなプロジェクトにジョインしたときに、まずツリー構造の情報を眺めるんですが、非常に効率が悪いんですよ。
現時点での自分が知らないこと、知りたいことに対して、たとえばインセプションデッキやテスト構造の書き方など、その答えが返ってくれば済む話にもかかわらず、ツリー構造だと「テスト構造の書き方は、たぶんこのあたりのフォルダに書いてある」。で、探してみると、あることもあれば、ないこともある。あったとしても、古い情報と最新版が混在していることが多く、じゃあどれが正しいの？と。こうした状況が現場に溢れかえっているんですよね。
私は、この情報共有の形式知やナレッジは、人間のやりとりと同じだと考えているんです。誰かに「これってどうなの？」と質問すると、「これはこうだよ」「こういうことも知っておいたほうがいいよ」といった会話になりますが、それがツール上でできれば非常に楽です。また、とりあえず質問してみたら、「これだけだと完結しないけれど、これを書いた人間に確認できるよ」「これに関連するものがあるよ」といった流れになると前に進めます。完璧な正解ではないけれど、一歩前に進めるなにかを提供してくれればいいんじゃないかな、と。
長沢：その流れでいうと、Q&Aはどうですか？Yahoo!などが有名ですが、質問と答えがあり、ベストアンサーがあって、分野ごとにベストアンサーがスコアリングされて、トップはこの人、というような構造になっていますよね。
僕は現場で「ドキュメントが書けない」と言われたときは、まずQ&Aからはじめることを進言しています。Q&Aだと答えやすい、というのが理由です。
中村：そういう活用法なら、私もQ&Aはよくやりますよ。Qだけ書いて放っておくと誰かがAを書いてくれる。「詳しくはないけれど、自分はこうだと思う」という回答が集まり、ドキュメントとして活かしていければいいかなと考えているんです。
長沢：その促進や共有という意味では、Q&Aもおもしろいですよね。ただし、限界はありますが。
中村：Q&Aなら書きやすい、という要素も影響するんでしょうか？
長沢：「聞く・答える」だと簡潔ですからね。これがフリーテキストだと、どこまでQに書くべきなのか？どこまでAとして書くべきなのか？と迷いが生じてしまう。しかもフラットな構造なので、自分がどこを書いたのかということが落としにくいわけです。その点、Q&A方式なら、誰が答えたか一目でわかるし、誰がどれだけ支持しているのかもわかります。そういう意味では使いやすいですよね。
ドキュメントやナレッジを共有するツールより、Q&Aのほうが、ひょっとしたら暗黙知にアプローチできるのではないか、と。ひとつの手段でしかないし、断片的にはなりますが、効果があるんじゃないでしょうか。実際にやってもらうと効果が出たという話もよく聞きますしね。
中村：私は、「必要なときに必要なドキュメントを書く」ということは「必要なときに必要な知識を出す」ということでもあり、その「必要な知識を出す」作業が楽になっていることがすごく大事だと考えています。
最初から「こういうものをつくるから、これをやろう」ではなく、「これを聞いた。次もまた聞くだろうからメモっておこう」、聞かれた側は「たぶんこれはまた聞かれるだろうから、URLだけコピーしておこう」といった感じで、最初はそれでいいと思っているんですね。で、それを見た人間が「このURLがあるんだったら、この情報も載せておいたほうがいいよ」「それならこういう質問もあるよね」みたいに育てていける関係だったらいいな、と。
長沢：見えている形式知を共有するのは当たり前だし、ツールはそろっているので、速やかに行う、そこで悩んだらダメですよね。組織のルールや作法など当然のこととして定義するべき。昔よく使った言葉でいうと、躾。「躾としてやるべきだ。当たり前にすべきだ」というスタンスが大前提です。
そのうえで、見えていない形式知があるので、そこにもっと早めに着手するべきだと考えています。それができるようになると、暗黙知も大事にできるようになってくるので、「暗黙知を集合知化して闘う」体制がやっと整うんです。そこでScrapboxが役に立つんですよ。
「暗黙知を集合知化して闘う」ために、課題を解決するScrapbox
「暗黙知を集合知化して闘う」体制づくりにおいて、Scrapboxが活用しやすいポイントと、具体的な理由をお聞かせください。
長沢：Scrapboxは、ドキュメント作成において重要な要素がそろっています。もっとも優れているポイントが、関連のリンク構造がつくりやすくなっていること。カギカッコでくくるだけですから。
中村：あれはすごくいいですよね。ほかのツールでも関連をつくることはできますが、ひと手間かけなくてはいけないことが多いですね。
長沢：新しいページを起こして、といったように、意図的につくらないといけないですからね。
中村：これはどこのページにつけるのか？といったところで、思考のベースがまったく違うな、と。
長沢：ツリー構造の原理が入ってきてしまうんですよね。どこに入れたらいいんだろう？と悩みだすことになる。その点、Scrapboxならカギカッコでくくるだけなので、不確かな定義でも放っておけば誰かが書いてくれる、といったことができます。
中村：その不確かな定義、タグとも呼べないくらいにふわっとしたものに対して、誰かに書いてもらったという体験をすると、こういうものなんだと理解できるし、すごく便利だなと実感しますよね。
長沢：知らないことやわからないことを、「わからない」とそのまま素直にドキュメントに出せるというのは非常に画期的です。わからなければ誰かが埋めてくれるし、誰もいなければ外部に頼ることができる。
形式知にするべきところはやったほうがいいとはいえ、その方法がややこしいと気持ちまで萎えてしまいます。ほかのツールでも形式知は浮き彫りになりますが、Scrapboxだとそういうところをまったく意識せずに実践できることも大きな魅力です。
ただ書く、みんなで書きあえるということができるので、わからないことはわからないでいいし、誰かが答えてくれる。間違っていることは直してくれるし、足りないところはどんどん増える。そうすることで知らないことがまた増えていくので、形式知の水面を下げて表層を増やしていくことができます。
その作業が、非常にシンプルな機能でできる。メンションやいいねの機能はいっさいありませんが、本当はそういうのは必要ないんですよね。
中村：「読んでおいて」って、なんであなたに決められなくちゃいけないんだ、必要だったら読むから強制しなくてもいいよってね(笑)。
長沢：ほかのツールで同じようなことをやろうとすると、ドキュメントが古くならないための工夫が必要です。反応がないと人間はやっぱり書きたくないわけですよ。そのため、メンションで強引に読ませたり、いいねをしたりするんですが、まるで幼稚園児をうまくあやしてやってもらう的な印象があります。Scrapboxはそういった概念がないので、自立した大人が使えるツールという感じでしょうか。
中村：確かにすごくシンプルですよね。
長沢：それでいてなにかを強制されているわけではなく、ただ書いているだけで自然と情報が浮き彫りになってくるし、知らないこともわかってくる。集合体で使えるツールなので、チーム全員で使用できるのですが、全員が知らないことも当然あるわけです。ところが、ほかのツールだとそれが見えない。みんなが知らないことは、そこに存在しないものになってしまうんですよ。
中村：「これ誰か書いて」と言われて、書きやすいツールと書きにくいツールがありますが、Scrapboxは書きやすい部類に入りますよね。
ツールを2種類の切り口で考えていくと、最初から正しい情報を入れなくてはいけない強制力が働きやすいツールと、そうではないツールのふたつがあります。さらに、「この人が書いているドキュメント」というように持ち主が決まりやすい特色をもつツールと、らくがき帳みたいに誰が書いてもいいツール。この両者を比較すると、最初から正しい情報を入れなくてもよくて、誰が書いてもOKのツールのほうが使いやすいと感じています。
「自分はこんなことを調べたけれど、この部分がわからないから誰かお願い」というスタンスなら書きやすくなるし、それができるツールがScrapboxかな、と。
長沢：社内の規約など、ほぼ変わらないものは、PDFでもなんでもいいのでどこかで共有しておいて、変更になったらアップデートすればいいだけのこと。
それに対して、アジャイル開発に限らず、開発の現場では「いま、起きていること」そのものが大事なんですよね。これ以上は変わらない、というものはそんなに多くないわけです。情報ややり方などあらゆることが日々変化していきますから。
中村：私が最近感じることは、シームレスの概念が非常に重要だということ。パッと思いついたことが、パッとドキュメントに残せる。
思いついたことを書き起こす行為自体が無意識になるのはもちろん、思いついたままを書いていくだけで暗黙知が少しずつ形式知になっていき、誰かが暗黙知からサポートされる世界になれば、ナレッジ共有の領域でひとつ上のレベルにいけるのでは、と。
長沢：少し話がそれますが、従来型のドキュメントの共有、つまり正しい情報を共有する方法論を用い、形式知化できるものを共有できるようにして、チームとして暗黙知を集合知化し、情報をドキュメント共有ではなくナレッジ共有するという方向にもっていけると思いますか？
中村：それは無理じゃないでしょうか。暗黙知の共有は、たとえば会話のなかで「そういえばさ」といったように発生するものなので、静的に固定されたドキュメントを見ていて閃くことは少ないと思います。
Scrapboxがいいなと思うのは、先ほども話した通り、知識を落とし込んだときに関連まで出してくれること。そのときに、「そういえばこれもあるよね」と気づいて、そこから視野が広がったりするのでは、と感じます。つまり、従来型のやり方で形式知から暗黙知化は無理だな、と。それをやろうとすると、かなりの工夫が必要だと思うんですよね。
長沢：やっぱり従来型の延長線上に暗黙知への到達はないですよね。成熟度モデルを書いていて、途中で「あ、これは行きつかないな。別次元の話だな」と実感しました。成熟度モデルは、下のレベルから積み上げていき、段階を踏んでレベルをあげていくと高みにのぼれるという概念ですが、積み上げていっても高みにのぼることはできないんです。
中村：暗黙知はその延長線上ではないから、どれだけ繰り返しても行きつかないと思います。ツールは日夜進化していますが、その延長線上でしかないんですよね。形式知を楽に書く仕組みではあるけれど、暗黙知を集合知としてみんなの前に出すという方向性ではないだろうな、と感じています。
Scrapboxがもたらす、チーム共有の脳の外部記憶装置としての価値
現在のアジャイル開発の現場では、暗黙知を集合知化する際、どんな方法で行っていますか？
中村：みんなで一緒にやるプラクティスが非常に多いですね。ペアプログラミングを筆頭に、ドキュメント化されない過程を一緒に行うんです。相手にとっては価値がないことでも、もう一方にとっては知りたいことだったりします。それをドキュメントに落とし込もうとすると非常にむずかしい。なぜなら、相手がその情報を必要としていることを知らないからです。
まず理由のひとつが、その重要性の判断が一方ではできないため、全部書き起こすこと自体が不可能だということ。もうひとつが、情報を必要としている自分自身も、なにが必要かわかっていないということ。一緒に作業することで、「そうか、自分はこれを知らなかったんだ。この情報が必要だったんだ」となる。その結果として進んでいくので、ドキュメントを書き起こそうとしてもむずかしいんですね。
それから、情報の保存や再共有のための作業がどこまで必要なのか？という疑問もあります。そのふたりで行ったペアプログラミングが、ほかの場面で本当に必要になるのか？というと、その確率は割合として低いからです。
長沢：あえて形式知にしようとすると、無駄なコストがかかるだけですから。
中村：アジャイル開発の文脈では、問題と解決手段はその時々で変わってきますからね。アウトプットは、成果物があるのでそれを見ればいい。アプローチは、またそれぞれ別の人とペアで見つければいいんですよ。
長沢：アジャイル開発がチーム固定にこだわっている理由は、まさにそこですよね。「暗黙知を集合知化して闘う」スタンスなので、チームだからこそ、チーム内での暗黙の了解や阿吽の呼吸で動けます。反対に、チームが変わると、お互いのどこがわかっていて、どこがわからないのか？というところから作り直しになってしまう。
中村：たとえば5人体制のチームでひとり抜けると、上司が気を利かせてひとり増員しようとしますが、私はまずは様子を見るように伝えることが多いです。「だったら4人のままで続けたほうがまし。パフォーマンスは落ちないから」と。むしろ新たに人を入れられてしまうとパフォーマンスが落ちてしまうんです。
長沢：人が増えたことで、「なにを知っているの？」からスタートしなくてはいけなくなりますもんね。
新たなプロジェクトが立ち上がって、既存のメンバーをスクラップ・アンド・ビルドして大幅に入れ替えないといけなくなった場合、1からやらなくてはいけないプロセスの短縮のためにどんな工夫をしていますか？
中村：4人体制チームであれば、4人で同時に仕事をします。スピードを落としてもいいから、それぞれ別の仕事をするのではなく、4人全員で同じ仕事をしよう、と。一緒に仕事をすることで、お互いになにを知っていて、なにを知らないのかを共有するんです。これにより、お互いの理解速度が早まります。
そこでScrapboxを導入するとしたら、どんな使い方をしますか？
長沢：アジャイル開発の現場でドキュメントが必要になるのは引き継ぎですね。担当していた作業を次の人に引き継がないといけないとなると、やっぱりなにかしら残さないと引き継げないですから。逆に言うと、チーム一丸となってやっているのであれば、引き継ぎがないのでドキュメントも必要ありません。
こうした現場のスタンスを考えると、Scrapboxはチームの脳の共有という形で使えると感じています。もちろん書くという行為は必要ですが、チーム共有の脳の外部記憶装置をもっているイメージですね。
中村：ドキュメントツールの特性として、誰が手を入れてもいいツールは、うまくいっている現場ほど更新頻度などに共通点があるんですね。ドキュメントの変遷が似ていて、頻繁に更新が行われている現場は情報共有がうまくいきやすい傾向があります。その価値をちゃんとわかっている現場だな、と。真逆の現場だと、特定の人物しか知らない暗黙知が多いので混乱やアクシデントが起こりやすいです。
長沢：なにか事故が起きて、「やっぱりちゃんと残しておかないといけない」と考え、必死に残しても結局あまり見る機会がない。残すために残すのではなく、お互いの議論の活性化の結果としてたまたま残っているくらいがちょうどいいですよね。
そういう点でいえば、Scrapboxは非常に書きやすいし残しやすいです。全部をドキュメントに残すことが果たしてよいことなのか？というのはまた別の話ですがね。チーム共有の脳の外部記憶装置といっても、あくまでもお互いの理解促進のためであって、第三者に参照してもらうことが主目的ではないので。
そう考えていくと、共有された外部記憶装置なので、新たなチームメンバーがキャッチアップする目的としても使えます。文脈だったり温度感的なものが早い段階でわかるんですよ。
中村：既存のドキュメントツールと比較すると、Scrapboxは書きやすさを重視したサービスで、楽に書けることを目指しているのかなという印象です。
長沢：本当に楽ですよね。リンクの順番も関係ないし、思いつきでリンクできるのがいいんですよ。「これがわからない」が出てきたら、カッコでくくっておいて、後で調べたり、誰かに書いてもらうことが簡単にできるわけです。
中村：リンク先がないと、勝手に記事ができあがりますしね。この構造はWikipediaに近い。Wikipediaを使いこなせていた人にとっては、なつかしい体験になるんじゃないかな、と。
長沢：自分で全部ケアしなくてはいけないわけではないし、そうやって蓄積されていくのはある意味、斬新ですよね。
中村：チーム共有の脳の外部記憶装置としての活用法はぜひ試してみてほしいですね。
Scrapboxについて
企画書、社内マニュアル、議事録など、チームに必要なドキュメントを共同で瞬時に作成できます。ドキュメント同士を関連性を元に自動で繋げ合い、何千、何万ものドキュメントを管理する苦労から解放してくれることが特徴です。