エンジニアリングや研究開発について思うこと

エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。

基礎を学び古典を知る

技術力を高めたい、成長したいという前提において、基礎を学ばずに発想で勝負などと、勉強もせずに過去の天才達とに渡り合うほど無謀なことはない。新しい価値を生み出すには基礎や古典を学ぶことは必須であるし、車輪の再発明においても、有効な選択肢を作るという点において必須である。

逆にいうと、歴史や古典からは過去の天才達が作り上げた知見を効率よく学べるという点においてすごくお得である。そういう積み重なってきたものをうまく踏み台にすることで、新たな発想がうまれてくる。人の発想力も、踏み台から飛んだ方がより高みに効率良く到達できることは言うまでもない。

サーベイと評価

自分の思う普通や「できない」という認識を超え、新しい「できる」を生み出すには、とにかくサーベイをすること。サーベイしまくって論文を書いていたら、ある時サーベイ論文になるぐらい知見が溜まる日がくる。自分は、それを大体体験するまでに4年ぐらいかかった。

入念なサーベイと抽象的な議論に基づいて、トップダウン的思考で新たな価値を生み出しつつ、ボトムアップ的思考で後付けでも良いので実績を細かく切り出した上で、従来手法と比較・分類しながら有効性を適切に評価することが技術開発においてはとても重要である。つまり、考えることも手を動かすこともどちらも必要である。

定性的かつ定量的な評価によって有効性を示す方法論を後付けでもしっかり考えるのはとても大事である。最初から新技術を導入した場合に何も問題が起きてなくても、もし仮に以前の技術で対応していたらどういう問題が起こりえたかという点についてもきちんと評価しておくと、新技術の有効性を主張しやすくなる。

有効性の評価が適切に行えれば、特定のケースにのみ有効であるかどうかも明らかになるので、別システムへの導入に対して一般化可能かも明確になるし、さらなる改善へ繋げることも容易となる。じゃあそれをどのようにすれば良いか？それは論文のテンプレ的書き方を学べば自然に何をやれば良いのかわかる。

研究開発における関連研究や基礎概念の体系的な整理とは、単にサーベイして技術を並べるのではなく、そこにその人の発想をもって論理的かつ説得力のある関連付けと分類、総括を行うことによる体系化であり、その体系的整理の上に新たな価値を見出していくことがその人独自の研究開発になり得るのである。

アーキテクチャを提案するというのはそういうことであり、さらに複数の新しいアーキテクチャに関連付けを持たすことによって、その上に新たな価値を持つアーキテクチャを提案できる。隙間の多い体系化ではその隙間にアーキテクチャが落ち込んでしまって支えられないし、個々が分散して発展性が生じないだろう。

論文という学習と貢献を両立する手法

アーキテクチャと実装の違い、アーキテクチャ自体の有効性を評価する、みたいなところについてはだいぶ慣れてきたと思っていたが、今回条件付き採録となった論文の査読結果を見ていると、まだアーキテクチャと実装を混ぜてグチャッと論述していることを指摘されており、精進あるのみだと思わされた。

アーキテクチャを考えて実験を繰り返すことにより有効性を示し、論文やコードを読むことにより関連技術をサーベイして必要となる新しい技術を検討し、得た知見をわかりやすく論文にまとめて知の連載を繋げ、社会が自分の貢献を平易に再利用できるようにする。そのために僕は論文とコードを書き続ける。

研究者でなくとも論文まで書けば、このプロセスを明確に実行できる。この作業によって技術の一般化がある種強制され、次に取り組む技術に対して再学習が大幅に短縮される。技術理解の抽象レイヤーを構築しやすい。その上、論文の体裁に載せることで、専門家の査読が受けられるため品質も上がりやすい。

頭の良い人にとってはこういうある種、技術を学び適切に理解するための手法がなくとも雰囲気で身に付けることができるのだろうと思うが、僕のような平凡な能力の持ち主にとってはこういう手法やツールを自分にうまく適用することによって、効率的かつ機械的に学ぶことができる、というのは実感している。

企業でのスペシャリストに求められるさらなるスキル

幅広く現場のスキルを身につけるよりも専門性を突き詰めることを選択した技術者が企業で活躍するために大事なことは、自分の専門性がいかに将来的に会社の価値を高めることになるかを説得できる、というところだと思う。専門家でない人や会社にその理解を求めるのは無理があるだろう。

僕が今の職位になってから「新しい技術の作り方、考え方、見せ方」を周りのエンジニアに広めていくことをひとつの使命としており、少しずつではあるがそれが広まってきている。これは高度な基礎スキルというか、エンジニアを裏切らないスキルだと思っている。その状況を見ていて、自分の体験だけでは判断がつかなかったが、今ではやはり「新しい技術の作り方、考え方、見せ方」を学ぶことがエンジニアのひとつのブレイクスルーになると確信している。

技術への深入りの効能

その瞬間では他の技術と比較してそれほど新規性や有効性が見出せなくても、その方向に深入りするモチベーションがあるなら是非深入りして頂きたい。深入りを諦めて使っているだけじゃ得られない副次的なスキルが得られることが多く、それらがある時結びつくときが来る。それらが革新的技術を生み出す。

新しい技術は常に合理性の元に生まれているわけではなくて、単なる人間の知的好奇心や探求力が、当時は想定できないような価値を生み出す。そういうきっかけやモチベーションは人生でもなかなか出会えないので、そこに巡り会えた人はすごく幸せだしその機会を中長期の目線で大切にできるようにしたい。

現状の自分の論理的思考、その瞬間の知識に規定された短期的な合理性に規定されてはいけない。周辺知識を増やして幅を広げ、論理的思考の上に成り立つ結果と新規性や有効性が一致し始めるまでは、実現したいことをベースに情熱がある限り深入りし続けていくことが大事。それを繰り返すうちにいずれ自分の成長は合理性に基づいていないことに気づく。

なので、偉い大人がその瞬間の知識に規定された短期的な合理性だけでエンジニアや研究者、ひいては学ぼうとしている若者の中長期的戦略や将来性を潰すのはやめて欲しいと強く思っている。

好きな技術にしっかり取り組むことで、関連技術への理解が芋づる式に必要になってくるし、その際に横道にそれる学習を許容することで、ある時システムとしての理解へとつながる事があるように感じている。横道に逸れた学習が後々のアーキテクチャ設計で手段として活きる事は多々ある。ただ運用することは必須であろう。  

インフラエンジニアのキャリア再び

元インフラエンジニアのキャリア、大きく二通りあって、ひとつはWeb開発でやってた領域にも手を出して幅広いレイヤーを習得していくキャリアか、ひとつはインフラの専門領域の知識を活かしてそのレイヤーの定番ソフトウェアと戦えるソフトウェアや新規性のある技術を開発するキャリアだと思っている。

全く違う分野へ行くのもあり得るが、同じWeb業界だと上記キャリアが現実的かなと。前者は幅広い技術の理解が必要で競争率が高く、後者は専門性高く高度な知識が必要だけど競争率が低い、というような特徴があって、どちらも生きていくには同じぐらい大変だと思うので自分の興味に合わせると良さそうだ。

さらに前者は1人でWebアプリを作れるが専門性がないのことを悩み、後者はエンジニア達と協力して良いWebアプリを作れるが1人では作れないことを悩む。全てのレイヤーを理解し、高度に専門性を持てれば理想であるが、Web技術の進化の速さと人の能力の限界がそれを容易にはさせてくれない。

前者はスタートアップや新規サービスを少人数で素早く作り上げるような小回りの効く組織の場合に向いていて、後者は規模が大きくなって分業による効率化が進んだ組織においてサービスを差別化する場合に向いている。この住み分けが必要となる領域はとにかく技術を日々学ぶことを前提にした先の話である。

僕は後者の道を選んだわけだが、研究所という枠組みを新たに設け、自分の研究開発力や研究開発のコミュニティとの連携に力を発揮できているし、日々新しい技術や既存サービスを差別化するための研究に日々取り組めている。そのために博士号取得のプロセスを利用するのは一つの手段としてあり得るだろう。

技術という真にフェアな領域

格ゲーやってた時もだが、技術を学んでいく過程で挨拶の強制や内輪な交流とか社交辞令的なことを求められる雰囲気になるのがすごい嫌だったし、優れたエンジニアと知り合いであることのアピールとかも大嫌いなので、僕は単純にゲームや技術の内容を楽しみたいし、そういう気質で動ける人には好感を覚える。

ごちゃごちゃと挨拶だの懇親会だの勉強会だの参加すべきか迷っているぐらいなら、さっさと家に帰って本を読むなりコード書くなりブログ書くなりして発表資料でも作ってどこかで発表する準備をすれば良い。それを繰り返すことにより道は開けるし、その結果行きたいと思える場が自然とできれば進めば良い。

これは人と関わりたくないとかではなく、無理に挨拶や社交辞令をしたり、影響力のあるグループだからといって無理に関わる必要なんてなくて、技術の良いところはまず技術に素直でありさえすれば多くの場合フェアに取り組んでいけるところ。技術を学ぶ中で自然に気の合う仲間ができてそこで楽しめば良い。

エンジニアへの動機付けと教育

エンジニアの教育で大切なことは、その人の技術力と学習速度とやる気を計り、今は出来なくても先に掲げた目標を達成する頃にはできるレベルになっているかを予測し、そのタスクやプロジェクトの技術面を全て任せること。任せるとは、自分の貢献と言いたい欲求によって手を出すことすらも堪えることである。

取り返しのつかないことを除いて失敗も含めて判断や思考を任せることにより、内発的動機付けを促すことによって促されている人が成長した時、最も成功したパターンとは促されていることすら気付かないことであり、それを促した側がちゃんと受け入れられるようになれば組織としてはとても成長できる。

色々試したり葛藤しながら思ったこととしては、促すことを気づいてもらいたいとか考えたり相手にそれを求めたりするから中途半端になるのであり、そこを諦めたら究極的に内発的動機付けを促せるようになるように思う。ただいずれそれではスケールしないので、どこかではその方法論を伝えないといけない。

僕の場合、最も成長する時とは、その対象を学ぶことにおいて内発的動機付けの方が外発的動機付けよりも強く生じるもののバランス良く生じている状態において、適切な負荷に基づいて取り組むことにより継続的に活動可能であり、かつ、動機付けも損なわれない時、だったように思う。

周りを成長させることと自分が成長することは同意と言っても良い。周りに技術的な情報をオープンにして共有し、自分のスキルを隠すことなく伝えることによって周りが成長すると、自分では見つけられなかった視点、新たな分野の知見や活発な議論が得られるようになり、そこから自身の成長に繋がっていく。そういうスキルが改めて必要である。

知識をコードで表現する専門職としてのエンジニア

役職高くてもエンジニアという名がつく人はちゃんとコードを書いてソフトウェアを作り続けるべき。人に任せたり社内調整や兄貴分みたいなことしてるだけではただ少し仕事が回せる人になるし、専門職としてエンジニアを冠しているのだから、人に任せる分、自分にしか書けないコードを増やしていかないとダメであろう。

エンジニアとして生きていきたいと思っている人が、周りにできる人が増えてきて任せてたら色々なものができるようになってきて、自分はまとめ役に徹するみたいな考えに至ったたらそこで試合終了だと思っている。周りにできないものを作れるようになってこそエンジニアだろうと思うし、その努力をしてこそである。

エンジニアも役職が上がって色々な調整やマネージメントをやることが増えてきても、エンジニアとして生きていくのなら忘れちゃならないことは、とにかく知識をつけてコードを書くスキルを高めてより良いプロダクトを設計し作りあげることだし、その気持ちを誤魔化さずに向き合っていけば、エンジニアもヒーローになれる。

エンジニアは属する組織のプロダクトのユーザ価値を最大化することが大事だけど、それをコードやアーキテクチャ、CSのスキルを上げずにできるなんて甘い話だしそんな時代でもないので、ちゃんとコードを書き続け新しい知識を身につけてプロダクトに反映していくしかないし、それが最も優先すべき技能である。

技術に対する思考

技術に取り組んでいるときにその取り組みが、頭の中にキャッシュとして定着しているのか、それとも、新たなコードとして実装されているのか、ってのを意識したいなっていうの感覚がある。キャッシュとして定着しているだけでは一見良い感じに思うのだけど、他の人と最終的には差がでないことが多い。

脳に技術情報をキャッシュとして取り込めたのなら、その情報を単に辞書的に使うだけでなく沢山のキャッシュ情報の関連やつながりを発見し糸で繋げるような思考に挑戦してみる。何日も何日もそういう思考をしていると、ずっと迷子になっていたつながりが新たなつながりを発見して、新たな技術が生まれる。

僕の思考は、無数にある星のような技術情報がindex的に頭の中にあって、それを俯瞰してみることはできるけど、その繋がりは簡単には見えない。新たなアーキテクチャやアイデアを考える時は、ひたすらその繋がりがたどり着く先を探っていくようなイメージである。繋がりが目指す先をとにかく辿る。

答えが見えず諦めかけるのだが、技術要素が揃っている事はなんとなく俯瞰的に見えていて、きっとそれらがつながるはずという大局観みたいなものはある。だから、諦めずに「わからんな」って所からさらに3倍時間をかけて思考を深めると答えが見える事が多い。繋がりが見えたという体験が諦めを防止する。

脳にとにかくキャッシュとして技術情報を貯める方法は、とにかく手を動かし、とにかく技術情報を読む、に尽きる。そうやって脳の中に俯瞰的にたまったキャッシュ情報は、I/Oがめちゃくちゃ速いので、熟考しているときに技術情報の繋がりを探索する作業に集中できて効率が良い。キャッシュ化して繋ぐ。

そういう意味でも、新規性ある技術や差別化できる技術を生み出すことは訓練でも達成可能であると考えている。そのためには幅広い技術の脳内キャッシュをとにかく得て、繋がりの探索や分類のスキルを訓練すると良い。そうでなくてもできる人はいるだろうけど、自分はそうやって生み出してきたように思う。

技術力の醸成による先行報酬

今いる慣れた環境から外に出て考えを発言し、世の中にいる猛者達と議論することによってさらに知識が増えるとともに理解が深まり、前提が一致しないことからも自分では思いもよらない考え方を得ていく。これは特定の組織やコミュニティが生み出す価値を最大化する基本原理として認識が広まると良いのではないか。

科学技術の発展のための方法論も、論文を書いて発表してそれを国際会議で共有して引用してそのサイクルを繰り返すといったように、ずっとそういうアウトプットと共有をやってきているわけで、技術の限界とプロダクトの限界が一致し始めている昨今においては企業としても当然求められる方法論であろう。

セキュリティにおいて問題を隠すことによるセキュリティなんてものが意味をなさなくなっているのと同様、技術においてもクローズドすることによる一時的な先行報酬よりも、オープンにすることによって集合知から得られる技術力の醸成及び常に先を進み続けられる技術力の醸成による先行報酬が意味をなす。

楽しいことと貢献とその評価を重ねる

今はできていないけれど、自分がやりたいことを実現するために時間を作って無理して頑張る、というのはなかなか長続きしない上に大変なので、自分が今当たり前にできていることをやり続けることによって、やりたいことが実現できる、という風に持っていくにはどうすれば良いかを検討してみてはどうか。そしてこれは、「自分がやりたいこと」を「好きなこと」や「楽しいこと」と置き換えてもよい。

僕は、楽しいこと、論文でアカデミアに貢献すること、コードで事業に貢献すること、これらがうまく重なり評価されるように社会活動をコントロールしている。だからこそ自分は中立であり公平でありたい。その姿勢と活動が共通点を見出し、自分を効率よく成長させることを体験的に知っているからである。

技術と自由

自分の好きな技術領域があったとする。好きなことと仕事を重ねるために技術を学んで技術力を高めて自由を得て童心に戻る。それが体験的に自分の生産性を最も高めることだと知っている。ただそれだけなのだ。人生観として、ある分野において自由を得るために勉強しているという感覚はある。色々なことができるようになるというのは僕にとって自由を得ることなのである。僕の行動原理は自由と面白さだから、それが得られる人生を作っていく

技術が目的

僕にとって、根源的には技術が目的である。技術が目的でそれを達成し続けるために生きる手段を駆使している。