最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。
もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。
ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。
一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、設計原則などは役にたつが、それは「検算」的な部分で役に立つ感じで、問題とがっぷり四つに組んで頭に汗をかいて設計しなければならないように感じる。
これがマイクロサービシーズになってくると、どのようなマイクロサービスにどのような責務を負わせ、どのように分割するのかがかなり思考問題寄りで、サービス間の連携についてはけっこう知識問題に寄っているように思えるのがおもしろいところだ。
そんな視点で眺めてみると、去年ぼくがbuildersconで話した開発現場で役立たせるための設計原則とパターンという発表は、設計原則やパターンは、このように活用すると思考問題を解く際の武器にできるよ、という話をしているというように理解ができそうだ。一方、今年のbuilderscon に応募している（たのむ！採択されてくれ！）、Ruby (off|with) the Railsという発表は、かなり知識問題よりの領域を扱っていると思う。まあこの記事で言いたかったのはそういう予告です……。
ところで、知識問題を解くための武器とも思考問題を解くための武器だったら、なんだか思考問題を解くための武器のほうが「ありがたがられ」そうな気がするけど、これらに優劣はない、とぼくは思っている。思考問題を解くための武器は錆びつくのが遅いけど、一方で「すぐに役立てる」のが難しい。知識問題を解くための武器はすぐに陳腐化するけど、明日からすぐに役立てやすい。これらは優劣ではなく、性質の違いだ。
自分が問題に向き合ってる時に、いま知識問題に向かい合っているのか思考問題に向き合っているのかは少し意識してみると、自分がいま向き合うべき問題なのかを考えられたりとか、「知識問題だけど知識が足りないから、すぐ使えるやつを仕入れてこよーっと」みたいなムーブができたりとかできて良いかもしれない。いや、しかしこれは「知識問題だとわかるためには知識が必要」という問題があるか？
あー、でも、少なくとも、ジュニアエンジニアが知識問題に戸惑ってたらシュッと知識をインストールしてあげる、思考問題に戸惑ってたら本人の気づきをナビゲートしてあげる、みたいなことはできそうですよね。知識問題と思考問題という視点はけっこう便利であるなあと思います。
なんかとりとめない話になっちゃったけどブログだからいいよね。
