なぜ暗黙知は生まれてしまうのか？　設計のための、問題の捉え方 Part2

「事実」「関係」「原則」

magnolia_k_氏：じゃあどうすればいいかということで、「じゃあ、僕らどうすればいいんですか？」「わかんないですよ」「書いてないことは書いてないんだから」と。

「じゃあ知ってる人に聞きますか」といって、「あなたの知ってる暗黙知を教えてください」と言っても「はぁ……」と言われるだけですね。

（会場笑）

これ、けっこう、マジで言ったことあります（笑）。

（会場笑）

けっこう困られちゃうんですよね。「いや、そういうことじゃないですよね」ということで、暗黙知が潜んでいそうな場所をちゃんと考えていったほうがいいんじゃないかと。僕もわりと長い経験値を持っていますので、じゃあそういうときにどういうところにいつも暗黙知があるのかなというと、僕はここで「事実」「関係」「原則」という3つのキーワードを挙げてみたいと思います。

「事実」はもう書いてありますね。存在する事柄、本当のことで、これはいつかどこかで見た風景ということです。「このサーバ、手順書どおりにコマンド打ってもログインできないんですけど」「そのサーバ、踏み台サーバ経由しないとアクセスできないよ」「手順書にそんなこと書いてないんですけど」「書いてないけどそうなんです」「お、何すか？」みたいな感じになるんです。

だいたい手順、歴史、根拠、こういう事実というのは暗黙知になりがちなんですね。いろいろ書いてますが、こういうことが書かれてないですよねっていうことが、プロジェクトの現場ではよくあると思います。

じゃあ「なんで書かれないんですか？」っていうと簡単で、知っている人は書かれなくても困らないですよね。知っている人は困らないんで、なるべく書きませんということがあります。

次に「関係」ということになるんですけど、物事の間になんらかの関わりがあること、またはその関わりっていうことで相互の関わりですね。まあ、このとおりなんですけど。

関係っていうのは、事実以上にけっこう暗黙知になりがちだなっていうふうに思っていて。例えば、「相互に関連する複雑なビジネス要求の関連性・関係性をパッと答えなさい」って言われても、「いや、ちょっとよくわかんないです」とか。直接は連携してないはずなのにそのシステムが落ちるとあっちのシステムが落ちます、そういうことがよくありますよね。

あとは、ありがちですけど、グローバル変数が多用されたモジュール構造とか、参照するときに例外条件が多いテーブル設計とか。実はこないだハマったんですけど「同じテーブルに入ってるんですよ」って言われて、「そんなのわかんないですよね」っていうことで、「それ集計するとバグるんですけど」って言われて困っちゃいますと。

このような、事実と事実の関係性ですね。「これはこういう関係になってますよ」も、いつも暗黙知になるよねっていうのが僕らが戦っていることなのかなと思います。

なんですけど、なんでそれかというと、やっぱり関係っていうのは勝手に出てくるものではなくて、問題に対する視点だと思うんですね。ただ単に事実だけを並べていても、関係はわからなくて。

関係っていうのは、「どういう問題を我々が解こうとしてるか」というときに初めて見出されるものなので、ただ単に事実だけを並べていても、「関係ってよくわかりませんね」っていう話になるので、なかなか書くことができませんねと。

加えて、関係を言葉だけで正確に表現するっていうのはやっぱり難しいので、やっぱりこれも「面倒くせーな」っていうことで、なかなか書かれませんね。

“原則”は暗黙知になりがち

最後は「原則」です。原則っていうのは、ちょっと難しく書いてますね。人間の社会的活動のなかで、僕はこの社会的活動をしてるのかよくわかんないですけど、多くの場合にあてはまる基本的な規則や法則、「基本的な規則」って書いてあるんですね。

プロジェクトの現場でみなさん思い出してほしいんですけど、規則と違って原則ってやっぱり暗黙知になりがちなんですね。例えば、命名規約が完全に統一されてなくて「ほとんどローマ字なんだけど、一部英語です」とか言われて。レビュアーに聞くと「いや、俺が決めたから」みたいな話とか。

データのバリデーションの深さ、範囲、それから機能分割の単位とか、モジュールの粒度みたいなのが明らかにある管理者だけ違いますとか、そういうのがあって読み取れませんねと。後任の人がやってくると、「よくわかんないですね。なんですかね、これ。どういう思想なんですかね」っていうのに困り果てます。

規則っていうのは、行為や手続きなどを行う際の標準となるように定められた事柄・決まりになるんですが、ソフトウェアにおいて「一貫性」っていうのがすごい大事なキーワードになると思うんですね。だいたいみなさん一貫性って重要な要素として設計のときに考えると思うんですけど、ソフトウェアがバグったり良くないことが起きるっていうのは、一貫性が崩れているときなんですね。

一貫性がどうやったら確保できるかというと、だいたいそのプロジェクトにおける規則とか原則においてもたらされるんですが、規則はちゃんと明文化されておいてほしいですね。たぶん規則は明文化されてないと規則とはいえないと思うんですけど、書いてないのに「規則だ！」って怒られたときは、「ごめんなさい」ってとりあえず言って、心のなかでヘイトをためておきましょう。

（会場笑）

一方で原則っていうのは、必ずしも明文化されているとはかぎりません。自分でもやっぱり思うと思うんですね。このモジュールをこう命名してみたけど、どこにもなぜそういうふうにしたかは書いてませんとか、そういうのってあると思っていて。無意識に決めた原則にしたがって設計してるときってあると思うんですね。

「なんとなく決めたんだよね」みたいな話って絶対にあると思っていて、それをいちいち公開するとか、「これ、どうやって決めたんですか？」って言われても「いや、ちょっといまさらいらわれてもよくわからん」「あんときの気分かな」みたいな感じで、なかなか自分のなかの原則って言語化するのが難しかったりするんですよね。

ということで、もう1つ「問題」というのが、規則と違って原則ってあくまでも原則なので「例外も含めてあらゆるパターンを、最初から網羅して挙げてください」みたいなことを言われても、「そんなの無理ですよ」っていうことです。

「とりあえず原則はこれです」って言っちゃうんですけど、「例外はまた別途」みたいな話を言うんですけど、そもそも原則を宣言する段階、設計の最初の段階で、「原則はこれです」みたいな話を考えたときに、例外まで全部考えたりできないですし、実際しないですよね。そういうこともあるので、なかなか例外まで組み込めないので原則っていうのはなかなか書けない。

「例外はどうなってますか？」っていちいち聞かれるのも面倒くさいので書かないっていうことがあるので、原則の例外を最初から網羅的に挙げていくのは難しい。あらゆる原則を書き出そうとすると、自分との会話みたいな話になって、面倒くさいし、だんだん暗い話になってくるので、そういうことはなかなかしませんねということで、暗黙知がだんだんたまっていきますね。

なぜ暗黙知になってしまうのか？

じゃあ「なんで暗黙知になってしまうのか？」というのを、先ほどのおさらいなんですけど3つ挙げてみました。

事実やわかっていることは書かれません。「わかりきってくること聞くんじゃねー！」みたいなことを先輩に言われてショボンとするようなことあると思うんですけど、そういうことは書かれませんねと。

関係というのは、「何が必要な関係ですか？」とか、そういうものはあらかじめわかんなくて、問題とか設計の視点があってこそ初めて関係は定義ができるので、そういうのはなかなかよくわかんない。「とりあえず事実を並べてとくか」みたいな話になりがちですよね。

それから原則については、例外も含めて書ききれないし、そもそも意識なかなかできないですねという話になります。

でも、暗黙知は確かに存在して、知ってる人とか考えた人に適切に聞くと出てくるんですね。だいたいそのプロジェクトの重鎮みたいな人に聞くとだいたい教えてくれるので、「教えてくれたけど、これ、どうしたらいいんだろうな？」っていう話になるんです。

あと、自分でも思ってない暗黙知っていうのが絶対あるはずなんですね。聞かれたら答えたんだけど、「あ、俺、答えちゃった」みたいなときがあると思うんです。自分のなかでも、自分で意識してない暗黙知っていうのが絶対あって、なかなかそういうものを書き表すことはできないですね。

そういうことで、これらの暗黙知がありそうな場所を予想するだけでも、問題の条件に対する見直しが減らせるんではないかなというところですね。書いてないことはやっぱりわかんないので、予測するしかないかなと思うんですけど。「どこに暗黙知って潜みそうですか？」っていうのを予測するというのが大事なことで、予測すれば対策も立てられるんですねっていう話があります。

じゃあ「教えてもらったりとか、自分のなかにある暗黙知って、どうしたらいいですか？」っていうと、「これはもう形式知にしていくしかないですね」という話になります。形式知っていうのは、これは先ほどの暗黙知の裏返しで、言語化・記号化された知ということで、書かれているんですね。

書かれてることは形式知になりますということで、僕らは形式知にしていくっていう活動を、未来に向けてしていくべきじゃないかなと思います。