暗黙知を形式知に変えるには？　設計のための、問題の捉え方 Part3

暗黙知から形式知へ

magnolia_k_氏：ということで、次のテーマが「暗黙知から形式知へ」ということなんですけど、「じゃあ、どうすれば形式知にできますか？」っていうのは、これはまた難しいテーマになってくるんですけど。野中郁次郎という方が書かれた『組織的知識創造』という本、これ20年ぐらい前なのかな、かなり古い本です。

知識創造企業

「暗黙知を形式知に変えていきましょう」っていうテーマが初めて書かれたのがこの本なんです。

この本のなかに、「SECIモデル」が書かれていて、暗黙知の左上から始まるんですね。まず「共同化」っていうところから始まるんですけど、最初に暗黙知を持っている共同体のなかに飛び込んでいって、暗黙知を持っている人から自分が教えてもらって、自分のなかに新しい暗黙知を作りましょうと。

作ったら「表出化」ということで、その暗黙知を形式知に変えていきましょう。その形式知を連結したり、その形式知のなかから新しい考えや知見が出てくるのが「内面化」というんです。「このステップをどんどんどんどん繰り返していくといいですね」と書いてあるのですが、残念ながら肝心の表出化の方法が書いてはないので「だから、どうすればいいんでしたっけ？」っていう話になって、この本だけ読んでいてもけっこう困り果てちゃいます。

なので、「これが絶対正解」という話ではなく、僕らソフトウェアだけかよくわかんないですけど、ソフトウェアエンジニアの人が使えることを考えていきましょうということで。「事実を形式知にしていくためにはどうしたらいいですか？」というと、これはなんとなくわかると思うんですけど、事実を構成する要素に分解していきましょうということで、お馴染みの「5W1H」で書き表すというのが出てきます。

これはみなさん習ったことありますよね？　When、Where、Who、What、Why、Howということで、これで事実を書き表していきましょうと。幸いに、プログラムってHowそのものなんですね。

プログラムっていうのはHowそのものなので、これはOKですね。Howは書けますねっていうかたちになるんですけど、たいがいコードにはHowはあってもWhyがないんで、「この設計ってどうやったのかな？」ってなかなか残らないというのがありますね。

「じゃあ、そんなときにどうしたらいいですか？」という話で、t_wadaさんの良いツイートがあって、僕はこれをいつも思い出すんです。

コードには How
テストコードには What
コミットログには Why
コードコメントには Why not

を書こうという話をした

— Takuto Wada (@t_wada) September 5, 2017

「コードにはHow、テストコードにはWhat、コメントログにはWhy、コードコメントにはWhy notを書こうという話をした」というすごく良いツイートがあって、僕はいつもこれを読み返すんです。

こうやっていろんなところに、「ここにはこれを書くべきだ」っていう場所をみんなで決めていって、「そこにどんどん書いていきましょう」ということを決めていくしかないかなと思います。

ここに正解はないんですけど、テストコード、コメントログ、コードコメント、Readme、GitHub、Qiita、Slack、Wiki、Javadocとか、言語のドキュメント機能にどんどん書いていくしかないですよねと。

ちゃんと検索できて、後世の人が到達できる場所、参照できる形式に残していくのがすごい大事です。当たり前ですけど、個人のPCのローカル、アーカイブされたメーリングリストに載っかってもダメですね、というところは気を付けていきましょう。

関係を形式知に

次は、「関係を形式知に」ということなんですけど、関係を言葉だけで表すのは非常に難しいのと、「そもそも何を関係として捉えればいいのかもよくわからんです」という話もあるので、「こういうのをちゃんと図とか表で書き表していくのが大事だよね」という話になります。

さまざまな技法が世の中には流通していて、集められた事実から関係を導出するための視点をちゃんと提供してくれるんですね。どういうふうに問題を捉えればいいかっていうのは、その図法とか技法がちゃんと用意してくれているので、それに従っていくととりあえず書けちゃうので、やっぱり先人たちの知恵には従ったほうがいい。

ということで、例えばビジネス領域に近いレイヤーだと、いろいろ本屋さんとか行くとビジネスフレームワーク集みたいなのが並んでいると思うので、そういうのはソフトウェアと直接関係ないかもしれないけど、一度読んでいくといいんじゃないかなと思います。

例えば、中身は入れてないんですけど、As is/To beモデルということで、現状とあるべき姿を対比させていくと、現状とあるべき姿の対比がわかりますよねとか。

それから、ロジックツリーでいけば、ある事実に対して「なぜそうなったのか？」っていうのを分解していくというのがロジックツリーなんです。これもWhyというキーワードで、それぞれの事実の関係性が明確になっていくんですね。そうすると真の課題が見つかりますみたいな感じなんですけど。

プロジェクトの現場では「なぜなぜ分析はやめてください」と言うと思いますが、そういうことに使うやつです。

よりコードに近いレイヤーを書き表すためには、標準化されたモデリング図を使いましょうということで、これはお馴染みER図、UMLですね。ここではClass図、こういうのをちゃんと使っていきましょう、という話になります。

なぜ関係を書き表すのか？

なんでこういうのをちゃんと使ったほうがいいですかというと、極端なことを言えば、クラスの継承、テーブルの継承とかなくても動くコードなんか書けるんですね。

みなさん昔に戻れば、オブジェクト指向がなければリレーションデータベースがなかった時代でも、プログラムを書いていた人は書いていたんですけども、それではやっぱり設計者の意図は伝わらないので、未来のために意図した関係をちゃんと技法・図法で伝えていくっていうのが大事じゃないかなと思います。

さらに、その関係をコードに戻せば、それは固定化されて、コードの制約となるのでより強い形式知になっていきますということです。言語機能でクラスの継承を定義する、DBMSのスキーマにリレーションを貼る、つまり、プログラムにおける要素同士の関係を定義する、っていうことなんですね。

なぜこういうことが発達していったかというと、「やっぱり関係は設計の意図として未来の人に残していったほうがいいよね」っていうのがベストプラクティスとして残った結果として、ああいうことができてきているので、ただ単に言われたとおりにER図書けばいいとか、Class図書けばいいっていうわけじゃないです。

これは問題に対する視点なので、設計者の意図が残って伝わるような書き方をしましょうと。プロジェクトのルールだからといって、「一律バンと書きます」みたいなことはやめたほうがいいよねという話になります。

「原則を形式知に」という話なんですけど、これを探したんですが、さすがに原則を形式知にする定型的な手法はまだなかった、ないような気がするので、「言葉とか文章で書いていきましょう」ということなんです。

そのときも厳密に考えすぎずに、「原則っていうのはゆるやかな一貫性をもたらすもの」ぐらいに捉えて、どんどん書いていきましょうということです。設計原則、開発方針、設計思想とか、最初さんざんみんな議論するんですけど、だいたい忘れ去られがちなので。

こういうことはちゃんと記録をして残していくっていうことを意識的にやっていくのが、大事なのかなと思うので、「あ、これ、みんなで話した原則だ」と思ったら必ずWikiに書くとか、そういうところを気を付けていくといいんじゃないかなと思います。

継続的に“問題を捉える”ために

最後に、「継続的に問題を捉えるために」ということで、一番最初の論点は、「じゃあ、これ、どこまでやればいいんですか？」と、「じゃあ、設計書10万ページ書けばいいんですか？」と、「そういうわけじゃないですね」という話になるので、なんですけど、これ、「ケースバイケース」って言いたくなるやつなんですけど（笑）。

そうも言えないということで、アンチパターンをいくつか紹介していくと、これはよく言われるやつですね。「素人でもわかる完璧かつ詳細な手順書を作るんだ！」「すべての設計要素を一覧化して、その関係を詳細に定義し、追跡可能にする！」「完璧な設計規約を例外も含めてすべて網羅的に作れば、誰でも設計できるようになる！」とか言われて、まあ、たいがい破綻するやつですね。こういうことじゃない、ということですね。

あと、先ほどの関係という意味では、関係っていうのは視点なので、これが多すぎると逆に混乱を招いて工数もかかりますということで。ネタが被ったんですが、やっぱりEnterpriseQualityCodingはみなさんゆっくり読んどきましょう（笑）。

（会場笑）

これはやっぱり膨大すぎる形式知って、今度は形式知の読み取り方という暗黙知が出てくるんですね。ちゃんと書いてあるんだけど、膨大すぎて「これ、どっから読んでいいのかようわかりません」みたいな話になるので。膨大な形式知を作ればいいってものではない、というのは良いアンチパターンだなというふうに思います。

ということで、僕らはやっぱり「継続できますか？」という観点で判断していくしかないので、2つですね。

まあ、「後任の人にまったく同じ苦労をさせない」というのが、1つの観点かなと思うので、やっぱり「後輩にディスられない気持ちドリブン開発」が大事ですねと。「1年後に、後輩が絶対俺が作ったやつディスってるよ」みたいなことがあるので、こういうのはきちんと作っておいて、少なくともまったく同じことを後輩に苦労させるのだけはやめよう、という話と。

これもしんぺいさんの議論にまた戻っていくんですけど、最後は「変更されやすい箇所はどこですか？」っていう話になって、費用対効果の話になるとけっこう月並みな話になっちゃうんですけども、変更されやすい箇所を予測して、そこに注力していくっていうのがやっぱり大事です。

当然そんなものは当たるわけはないんですけど、外れる可能性があっても「変更されやすい＝みんなが思ってる価値が高い場所」ですね。変更されるっていうのは、絶対そのビジネス領域のなかで価値の高いところじゃないと変更されるわけがないので、その議論は僕は絶対無駄にならないと思っていて「変更されやすい場所は何ですか？」っていう議論は必ず大事かな、と思っています。

問題を捉えるとは、問題を理解すること

ということで、これまでの話をまとめると。「問題を捉える」っていうのは「問題を理解すること」。そのためには、これまで積み重ねた事実と、その間にある関係を定義して、それらが導かれてきた原則を言葉で書き表していくというのが大事なんじゃないかなと。

そうすることで、問題を理解するために必要な条件がそろってきますということを今日はお話したかったです。

まとめですね。このへんちょっと先ほど言ったことなので飛ばしていくと……、ということなんですけど。

実は、今日話さなかったこともあって、先ほど暗黙知ということで「事実」「関係」「原則」って言ったんですけど、あともう1つ「基準」っていうのもけっこう暗黙知になりがちなんです。これはけっこう説明しづらいというか、僕のなかでまだ固まっていないので今日はちょっと外したんですけど。「基準」もけっこう暗黙知になるので、僕らはこれを形式知にしていかないといけないですねと。

あとは、「データをそろえるのも、またやっぱり難しいですね」という話。それから、分析によって未知のことは変わっていきますよね。「全部難しいじゃないか」っていう話なんですけど、「分析から設計に対してどうやってつなげていくか？」っていうのも、またどこかでお話できればなと思っています。

最後に、僕が設計について超大好きな言葉があるので、これだけ紹介して終わりたいと思います。

Dick Hammingという方が50年ぐらい前に言った言葉らしいんですけども、「誤った問題を正しく解くよりも、正しい問題を誤った方法で解くほうが良い」ということで、「問題さえ正しく捉えておけば、それを解決するチャンスっていうのはいつでもやってくるよ」という話なので、問題を正しく捉えておきたいと思いますということで、ご清聴ありがとうございました。以上です。

（会場拍手）