知的体力とは？
いつも参考にさせて頂いているブログ「タイムコンサルタントの日誌から」に、以下の内容が記載されていた。
コンサルタントに必要な頭の良さとは、分析力よりも、問題解決案を考える能力だというのも、重要な指摘だ。とくに、著者が『知的体力』と呼ぶ、（正解のない問題を）何時間でも何日でも考え続ける能力は、ほとんどの人が見落としている、大事なポイントだと思う。
知的体力、という言葉は初めて目にした（耳にした）が、たしかにこれは誰しもが持っているスキルではないと思う。
コンサルタントに必要な水準かどうかは別にしても、このように答えのなかなか出ない問題を何日も考え続ける、という体験なら当方にもかなり思い当たることがある。
ただし、当方がいつもぶち当たっている問題とは、
「世の中の誰が考えても解決が容易ではない問題」
ではなく、
「世の中のエキスパートが考えれば答えは比較的容易に出るが、自分にとっては未経験の分野・未知の分野を含む問題」
といった問題である。
自分にとっての未知の領域を含む問題の特徴
この問題は、自分にとっては未知の知識がある、つまりインプットすべき知識が不足している、ということが問題解決を難しくしている大きな要因になっている。しかし、だからといって知識さえあればいいわけではなく、その知識を応用することが実務ではたいてい求められるので、インプットすればすぐに答えが導けるものではない。知識をベースに応用する余地が残されている。
たとえば、自社の戦略の方向性を考えたり、自分たちのチームの抱える生産性低下という問題の原因分析と対策の検討を行ったり、ＩＴシステムの設計において、未知の設計指向を採用しなければならない場合、といったような問題である。経営戦略については、経営管理・戦略論などのインプットが必要だし、生産性向上のためにはIEやオペレーション・マネジメント、プロジェクトマネジメントなどのインプットが必要になるだろう。
一般的なビジネスパーソンにとっては、こうした「自分の知らない領域を含む」問題のほうが、「誰が考えてもな答えが出にくい問題」よりは、日常的に遭遇しやすいだろう。
また半年や数年といった長いスパンでの解決が必要なものではなく、１週間～数カ月程度の比較的短いスパンで解決をしなければならないため、緊急性がやや高く、ほうっておいて忘れるに任せる、といったあいまいな態度では避けては通れない問題でもある。
なのでこうした問題へ対応しなければならない方々も多くいるのではないかと思う。
当方は、そういった問題に遭遇した時に、何日も考え続け、夢にも出てきて、あるときに不意に解決策を思いつく、といった経験は何度もしている。
だいたい共通しているのは、思いついた解決策は、ほんとうに「当たり前」のことのように感じる点だ。
初めからその解決策を提示されていれば、「あーなるほど」程度ですんなり理解できてしまうものである。もちろん、やや発想の転換が必要なものもあるが、それほど奇抜な解決策ではない。
ここでは、こうした当方の知的体力に関する経験から、「自分の知らない領域を含む問題」に遭遇した時に、どのようにすれば比較的効率的に問題解決ができるのかを振り返っまとめてみたい。
未知の領域を含む問題へのアプローチ
こうした問題に遭遇した場合に効率的に対応するためのポイントは次の２つであると考えている。
- 過去の仕事の進め方のプロセスを応用する
- 未知の知識をためらわずにインプットする
とっても当たり前のことではあるが、こうしたことがしっかりできれば、考えが堂々巡りになって悶々とすることは予防できると思っている。
（１）過去の仕事の進め方のプロセスを応用する
仕事の進め方とは、まずはどんな作業に着手し、どんなシナリオでその問題を解決していくのかを、大まかに方向づけることである。これができないと目先の作業だけにとらわれてしまい、実はやっておかなければならなかった作業などを見落とすことになる。
未知の領域を含む仕事を遂行しなければならない場合、仕事の進め方、段取りの仕方、必要とされる知識などが明確には把握できない。
そのために、何から手をつけていいのかわからず、仕事をうまく進めることができない、といったことが起こりがちである。
そのため、仕事の進め方や問題解決のプロセスを確実に適用し、「仕事の進め方」を万全にすることで手戻りを最小化することが必要だと考える。
具体的には、プロジェクトマネジメントのスキルが必要とされる。もしくは、問題解決の仮説設定・検証を行うスキルが必要とされると思う。
プロジェクトマネジメントでは、ある作業、たとえば組織の生産性を向上させる、といった作業のゴールに対して、どのような作業や成果物が必要なのかを構造的に細分化していく。そして、自分たちのスキルや知識をベースに着手する順番を定めるアプローチを採る。
自分たちの今の現状からスタートし、目的とするゴールまでに着実に近づく仕事の仕方を検討してから着手するのだ。必要によっては、「検討に必要な資料を本屋さんで探す」、「メンバそれぞれで勉強会を行う」といったタスクを設定してもよい。知識をインプットすることすらも作業計画にして、着実に前に進む計画を作成する。
また、遠い未来のことは不確実なため、直近の計画を詳細に行い、未来の計画は作業が進み次第繰り返し詳細化する、といった弾力的な計画方法についても採用することができる。
プロジェクトマネジメントは、まさに「自分が未知の領域を含む問題」に着手する時にこそ、真価を発揮できるのではないかと思える。
もう１つの仮説設定・検証スキルは、プロジェクトマネジメントよりももう少しスコープが狭くなるが、思考を整理してくれる大変強力なツールだと考える。
たとえば、システムの処理性能を向上させることが問題解決のゴールとしよう。そしてゴールにどのようにたどりつくのかは自分たちで考えなければならない。また自分たちは処理性能向上のエキスパートでもないとする。
このときに、まずはじめに処理性能を向上させる手段をリストアップしようと試みる。このときに、
「処理性能を向上させる方法って何があるのかな？」
という考え方でトップダウン的に検討してみても、思考が発散してしまいやすくいろいろなケースが想定され、有意義な検討にならない場合も多い。最終的には、意見がまとまらず次のアクションアイテムが整理されないこともある。
しかし、仮説設定・検証のアプローチでは、現在知っている情報・知識だけから、まずは仮説を設定することからはじめる。むやみに情報を集めてから検討を始めない。
すると、開発経験さえあれば、
・コード量を少なくする
・繰り返し処理のアルゴリズムを最適化する
といった程度のネタは出るだろう。
それらをグルーピングしてみると、上記の内容は「処理のステップ数削減」といった内容になるだろう。
そこで早速仮説を立ててしまう。この場合は、
「ステップ数を削減することで処理性能を向上できる」
という仮説である。
で、ここからが本番で、この仮説が強固なものであるのかを検証していく。検証とは具体的には、仮説が常に成り立たない状況は存在しないのか、という視点から批判的にチェックをするということである。
問いとしては、
・ステップ数を削減すれば、本当に処理性能は向上するのか？
・ステップ数削減以外に処理性能を向上させる手段はないのか？
・ステップ数削減によって新たな問題が発生することはないのか？
のように批判的に問う。
人は、あるアイディアにたいしてダメだしすることは得意なのだ。処理能力向上のアイディアを出せ、と言ってもなかなか意見が出ないが、「ステップ数を削減することで処理性能を向上できる」というアイディアを批判せよ、と言えば次々と意見が出てくる。
たとえば次のような意見がでるだろう。
・むやみにステップ数を削減させても、コアな処理に関連しない箇所だったら処理性能に影響しないのでは？
・ステップ数削減だけでなく、スレッドのスリープ周期で基本的な処理性能が決まってしまうので、まずはそこを見直すことが重要では？
・むやみにステップ数を削減すると、保守性の低いソースコードになる可能性があるのでは？
このような意見が示唆するのは、
・ステップ数削減をするためには、まずボトルネック箇所を特定することが必要
・ステップ数削減よりも、スレッドの基本周期を見直すことが優先
・ステップ数削減による保守性の低下を避けるように対策を打つことも必要
ということである。
このように、１つの仮説（アイディア）を批判的に検討することで、検討の焦点が絞りやすくなり、ボトムアップ的に様々な次のアクションアイテムが湧き出してくる。いくつか意見がでたら、それを取りまとめて仮説を更新し、また検証を繰り返していく。このようにボトムアップ的に、意見を出すことができる。
ブレーンストーミングの批判版といったところか。ブレーンストーミングは、自分以外のメンバの意見との相乗効果を求めるものなので１人ではできないし、用いる思考も発散系である。
これに対し仮説検証は１人でもできる（１人ディべート）。また、用いる思考も収束系であり、むやみに思考が発散せず狭い範囲を効率的に検討することができる。必要に応じて、発散系と収束系の２つの思考方法を意識的に切り替える、というのも個人的には大切なノウハウではあるが、これを実現するための具体的なツールとなる。
これを繰り返していくと、クリティカルシンキングが得意になる。システム開発を行っている人であれば、レビューアには必須のスキルといえる。またレビューだけでなく、自分のシステム設計内容を自己検証する際にも用いることができるので、設計品質の向上にも応用できる。
（２）未知の知識をためらわずにインプットする
案外これができていない人が多いような気がしている。
システムの世界では「ガベージイン・ガベージアウト」が知られているが、インプットしている知識が不足していれば、アウトプットされる成果物もお粗末なものになるのは必然である。
知らなければならないものは知るしかないので、ここは腹をくくって書籍を購入したり、ネットで情報を検索するなどし、集中してインプットしてしまう他はないのだ。ここを面倒くさがってためらうほど、その仕事の完結も先延ばしになるだろう。
場合によっては、何の知識をインプットすればいいのかがわからないことがある。
この場合は、プロジェクトマネジメントを応用してやるべきことを細分化していく中で見つけ出すか、仮説検証によって、「この仕事を完結するには○○の知識があれば良い」を徹底的に批判してみる。
（あとは「有識者に助言を求める」ことは、すべての仕事の基本なので、これはいずれのケースでもやることは忘れずに）
身につけるべきコアスキル
システムの受託開発をしていると、自分が身につけるべきコアスキルとは何か？を問うことが多くなる。
というのは、作ったシステムは顧客のものであり、ドキュメント類も顧客のために作成するから、自分の手元に何も残らない、といった印象を受けるためである。
実際は何も残らない、ということはないのだが、じゃあ、逆に何を残すことが重要なのだろうか？
やはり特定の技術要素や、特定業務知識というところに固執するのは危険だと考える。
なぜなら、次のプロジェクトがどの業界で、どのような技術要素を扱っているのかは分からないからだ。もちろん、安定的に業界固定で仕事を行うケースもあろう。
しかし本質的にはそこは流動的なはずである。
となると、他に転用しやすい、プロジェクトマネジメント、問題解決などの「プロセス」を身につけることが求められるのではないか、と思う。
あとは対顧客折衝のやり方、新たなプロジェクトに参画してから自分がどうやってリーダーシップを発揮するのかのやり方、知らない業務知識をすばやくインプットする方法などだろう。
これらはすべて「プロセス」である。
こうしたプロセスを組織で共有化することが大切なのだろうと思う。しかし多くの組織では、技術に目が行き過ぎていて、プロセスの共有化、再利用化、汎化、抽象化、といった作業を重視していないと思う。
ちょっと脱線した感があるが、答えがなかなかでない問題を考え続けるという知的体力とともに、問題解決のために効果的だと考えるポイントをまとめた。
