昨年、筆者は「PyCon JP 2014」の基調講演で、「⁠新しいものに気づくためには視点を変えることが必要だ」という話をしました。

みなさんはゾウの全体像を把握していますよね。もしゾウの鼻にだけ注目して「ゾウは太いホースのような生き物だ」と言う人がいたら、変な人だと思うでしょう[1]⁠。

でも彼は自分の正しさを確信しています。鼻だけを見ている彼にとって、見えるすべての情報は「ゾウはホースのよう」という信念を肯定するからです。もしゾウの耳にだけ注目し「ゾウは薄っぺらい」と言う人がいたら、互いに相手の主張を根拠のないデタラメだと思うでしょう。

彼らが「自分の視点から見えた風景」に基づいて他人の発言を判断している限り、この不毛な状態は解消しません。判断を保留し「相手にはそう見えている」と受け入れ、なぜ自分の視点と見え方が違うのかを考えることが大事です。それによって、あなたは全体像の把握に一歩近づきます[2]⁠。

本連載では、いろいろな視点をみなさんに紹介して、視点が変わるキッカケを提供できるといいなと思っています。

よく学ぶ人はパフォーマンスが低い？

よく学ぶエンジニアってどんな人でしょう？ 本誌のような技術誌を定期的に読んでいる人？ 社外の勉強会によく参加する人？ 社外のエンジニアと交流して技術情報をやりとりしている人？

そうですね。そういう活動は「良いこと」のように感じます。ところが残念なことに、エンジニアが組織外の人を情報源に使う度合いと、その技術者のパフォーマンスには負の相関があります[3]⁠。つまり上記のような「よく学ぶ人」は、実はパフォーマンスが低いのです[4]⁠。

なぜパフォーマンスが下がる？

どうしてそう見えるのでしょうか？ 2つの解釈を解説します。

1つ目の解釈は、「⁠外の人とは文脈を共有していないので、中の人から情報を引き出すのに比べて効率が悪いから」です。

昨年4月の本誌特別企画[5]で筆者は、学びには3つの軸があり、「⁠応用対象」の軸は目立ちにくいが重要だ、と解説しました。

知識は、具体的な問題に応用してその問題を解決したときに、初めて経済的な価値を生みます。社会人にとって知識の価値は応用によって作り出されるものなのです。

そして応用するためには、応用対象についての詳しい情報が必要です。たとえば、どういう問題を解決したいのか、どういう目的を達成したいのか、どういう制約があるのか、何がすでに持っているものか、何が新しく手に入れなければならないものか─⁠─これが文脈です。

組織の外の人とは文脈が共通ではありません。なので、社外の勉強会での「こういう方法を使うとうまくいく」という話は「その会社の文脈ではうまくいった」という意味であり、あなたの会社でうまくいくかは不明です。

パフォーマンスの評価基準の違い

2つ目の解釈は、「⁠パフォーマンスの評価方法が原因」というものです。

大学内の研究者を対象とした研究では、先ほどとは逆に「組織の外とのやりとりが多いほうがパフォーマンスが高い」という結果が出ています[6]⁠。

研究者のパフォーマンスを論文の質と量で評価する場合、その評価の主体は大学組織ではなく、学会などの「専門分野のコミュニティ」です。評価基準が特定の大学組織と密結合ではなく、組織をまたいで均質化しています。一方で多くの企業では、評価基準がその企業と密結合しています。

開いたコミュニティと閉じたコミュニティ

大学は開いたコミュニティ、企業は閉じたコミュニティ、そう考えると状況がよりクリアに見えてきます。

あなたの会社にも社内でしか通じない「社内用語」があることでしょう。社内でしか通じない用語が発生するのも、文脈の情報が社外と共有できないのも、企業が閉じたコミュニティだからです。

そして社外の知識を、社内用語・社内文脈へ翻訳することには時間的コストがかかります。そのコストは、組織外部の情報源を使う人が支払っています。

負担が集中するのは全体最適

たとえば、ある知識を外から取り入れるのに5時間、社内で共有するのに1時間かかるとしましょう。3人がそれぞれ5時間かけて同じ知識を獲得するより、1人の人が5時間かけて獲得して、それを社内で共有したほうが組織全体としてのコストは低くなります（図1⁠）⁠。

個人の視点では、1人に負担が集中して、良くないことに感じます。しかし、組織全体のコストは後者のほうが低いのです。

学ぶことは損？

「負担が集中するのに、評価にはつながりにくい。だから組織の外から学ぶなんてやめたほうがいい」……筆者はそうは思ってほしくありません。外から学ぶことが損に見える視点は、確かに存在します。ではその逆に、得に見える視点を2つ紹介しましょう。

1つは、外のコミュニティの評価を重視する視点です。エンジニアには、会社の外にエンジニア同士のコミュニティが存在します。外から知識を獲得し、外へ情報発信をすれば、外のコミュニティでの評価が高まり、人脈を通じた転職が容易になります。そういう転職の容易さを重視し、もし会社が自分を評価してくれない場合には、評価してくれる会社へ転職すればよい、という考え方です。

組織の吸収能力

では、会社に残る場合はどうでしょう？ もう1つの視点は、組織の吸収能力を高める視点です。

閉じた組織には、新しい知識が入りづらくなります。組織が新しいものに気づく能力が下がります。その結果、新しいチャンスや脅威に気づくタイミングが競合他社より遅れるようになります。

また、普段から知識獲得の訓練をしていないことで、知識獲得をする速度が下がります。その結果、たとえ新しいものに気づいたとしても、競合他社に比べて「獲得するために必要なコスト」が大きく見積もられ、「⁠獲得のために投資すべきではない」という判断がされやすくなります。

こうして組織は市場の変化から取り残されます[7]⁠。あなたが自由意志で会社の一員となった以上、会社がこの泥沼にはまらないようにすることは、あなたの責任でもあります。

企業の経営と個人の経営

この話は企業の経営戦略の文脈です。しかし企業の経営と、エンジニア個人が自分を「経営」することの間には共通点があります。

「組織」という言葉で「会社」をイメージしがちですが、仕事上のものとしては「部署」や「チーム⁠」⁠、個人的なものとしては「家庭」や「クラブ」などの小さい組織がたくさんあります。人は1つの組織だけではなく、いくつもの組織に属して生きています。その中で最小の組織が「個人」です。

経営戦略の重要な側面は、限られたリソースを最適に配分して最高の成果を得ることです[8]⁠。これは企業でも個人でも同じです。

たとえばたくさんあるプログラミング言語のどれを学んでどれを学ばないのか？ 無償のコンテンツで学ぶのか、雑誌を買うのか、有償の勉強会に行くのか？ 転職し新しい組織に慣れるコストを払うか、今の組織を改善するコストを払うか？ 評価される成果と評価されない学びのバランスは？ これを決めるのがエンジニア個人の経営戦略です。

プログラミングも経営だ

プログラミングと経営の間にも共通点があります。実装にかかる時間や実行時の消費メモリなど、いろいろな限られたリソースを最適に配分して最高の成果を得る、これが良い設計ですよね。良いエンジニアと良い経営者の違いは、注目しているリソース、つまり視点が違うだけです。

エンジニアの視点のほかに、経営者の視点を持って、まずは自分個人を経営してみませんか？「ゾウは太いホースのような生き物だ」という変な視点にとらわれないために、複数の視点を持つことが重要です。