Rossi（ろっし）です。
今回は、過去１０年に渡るエンジニア経験の中で大きく影響を受けた書籍を紹介したいと思います。
どういう本を紹介しようか迷ったのですが、あまり専門的な本を紹介してしまうと、前提となる知識が必要になってくるかもしれません。
ですので、できるだけ専門的な知識を要せずに読めるものをピックアップしたいと思います。
最初に紹介するのは、G・M・ワインバーグの『スーパーエンジニアへの道』です。
この本は、日本語版の出版が1991年とかなり古いのですが…。
私の手元にある版でなんと37版！というベストセラー本です。
なぜ、この本が37版を超えるようなベストセラーになっているかと理由を考えるに、ただ単に技術的な要素を紹介しただけの本ではないというところに理由がありそうです。
「スーパーエンジニア」と聞いてみなさんはどんな人を思い浮かべるでしょうか？webサービスを作れて、AWSなどのインフラなども構築できて、AIを使った音声認識や画像認識も使いこなせる、ありとあらゆる分野に精通しているエンジニア、を想像するかもしれません。
わたしもそういうイメージを持って、この本を買いました。
ただ、読んでみると、ワインバーグが言っている「スーパーエンジニア」というのは、どうもそういうエンジニアではないようなのです。
ワインバーグのいうスーパーエンジニアとは
問題解決型のリーダーシップを持った人間
だということになります。エンジニアがどういう方向を目指せば良いか、ということをいくつもの例をあげて、指し示しているような気がします。それが、何十年経った今でも読み継がれる技術書の理由のような気がするのです。
一生エンジニアでいることはできない？
このブログを読んで頂いている方には、現在エンジニアをされている方や、これからエンジニアを目指そうとしている方もおられるかもしれません。
突然ですが、あなたは一生エンジニアでいることが可能だと思いますか？
35歳限界説とかいろんなことが言われています。私は不可能ではないもののかなり厳しいと考えています。
たとえば、web業界では20代～30代のエンジニアが中心で、50歳を超えてコードをバリバリ書いてるような人はあまり見かけないと言われています。私がメインで仕事をしているFA(ファクトリーオートメーション)の分野では、50代でエンジニアという人も見ないではないですが、やはりメインは30代かな、という印象です。
50代を超えてエンジニアだというのが、なぜ厳しいかというと、本来はコードをバリバリ書いたりするのではなく、若手を指導したり、ハードウェアやソフトウェアの橋渡しの部分をしっかりやったり、顧客との交渉においてできるだけ双方にとって意義のある仕様の着地点を見つけたりすることがベテランの仕事だと思うのです.
しかし、そういう部分をあいまいにしたまま「経験によって培われた俺の技術をみせてやろう」とばかりにコードを書き始めるベテランの方がけっこう多いのです。
自分にしか分からないレガシーな開発環境を持ち出してきて「君たちには分からないでしょ？」とドヤ顔です。それはそういった開発環境がスタンダードだった彼らにしか分からないような領域なのです。本来、20代～30代に任せておくべきプログラミング言語や回路設計を、レガシーな開発環境でやることで、若手に触らせないようにするやり方です。
それで若手に向かって「きみたちにはまだ無理だ」と言って自分たちの技術優位性を示してくるのです。
確かにその開発環境においては優秀なことは認めます。その域に来るまで大変な努力をされたことでしょう。でも、全然尊敬できないのです。正直こういうふうにはなりたくないな、としか思いません。
ですが、私たちも下手をすると技術にこだわり過ぎるとこういう扱いにくいベテランになりかねないのです。
エンジニアが技術にこだわって、高度なスキルを身に着けることは悪いことではないのですが、それに執着してしまうと、誰からも相手にされなくなっていきます。OS（オペレーティングシステム）を書いてるとか、Visual Studioのようなメジャーな開発環境を作ってますみたいなスーパースターでもない限り、どんなに優秀なエンジニアであっても、若手に引き継がなければならない時がやってきます。その後のことを真剣に考えておくことは、思いのほか重要な気がします。
ワインバーグの本は、そういうエンジニアの運命についての本質を突いているからこそ、これほどまで読み継がれているのだと思います。
「技術能力を失うのはいやだ」という最後の壁
『スーパーエンジニアへの道』に以下のようなような1文があります。
リーダーになりかかっている技術的なスターにとって、もっともつらい選択は、最新の技術との接点を失うことである。
ワインバーグは、『スーパーエンジニアへの道』で技術的なスターがとる選択の中でこのようなタイミングが最も難しいと言っています。
たとえば、社内で優秀なエンジニアとして、会社の基幹商品の設計に携わり、社内での技術的な評価も高い人がいるとします。「やっぱりこの技術は○○さんにしかできないですよね」とか言われて有頂天になっている時期もあったかもしれません。このような人にとって、技術を手放すということは、技術のエキスパートというアイデンティティの消失につながり、自分の存在意義が消えてしまいそうな気持ちがするのです。
ワインバーグも本書の中で、
登り坂をのぼるのはいつでも大変なことだが、何かを手放すことの大変さはそれどころではない。
と、技術を手放すことの難しさを指摘しています。ワインバーグは、IBMの中でもスタープログラマーでしたが、コンサルタントをし、本を書き、著名になっていく過程の中で、むしろ最新の技術との接点を失ったことを痛感していたようです。
100％技術革新方面出身の多くの問題解決型のリーダーたちと同様私も、いつでも技術の主流に戻れるのだと信じたいのは山々だが、そういう保証はどこにもないのだ。
また、ワインバーグは数々の問題解決型リーダーが出身分野へのセンチメンタルな執着を捨てきれていないことを目撃します。たとえば、ソフトウェア会社の社長やコンピューターのメーカーの社長と言った実力者たちが例に出てきます。彼らのオフィスに、数値解析の雑誌や高エネルギー物理学の雑誌が複数置いてあったことを指摘していました。
そして、ワインバーグは厳しくも以下のように言っています。
彼らが元の分野でスーパースターであったかどうかは重要ではない。だが、彼らが現在技術的なスーパースターではなく、恐らく過去にもそうであった試しはない。だが、彼らは専門分野を超越し、いまは技術というものを一般的な形でマスターしていた。彼らは何十という分野の技術専門家と話ができ、麦粒をたやすく籾穀から分離する能力を持っていた。
つまり、彼ら経営者は、技術革新の能力やエンジニアというアイデンティティを犠牲にして、動機付け、および組織化の能力を身につけたのだ。それは回避しようのないトレードオフであって、恐らく彼ら経営者にとってもっとも受け入れがたい選択だったのだと思います。
ですが、ワインバーグが引き合いに出した例の経営者のように、技術者の本質たる技術を手放すことで、かれらは次のステージに行くことができたのです。ワインバーグ自身も「もう一度若返ってマーキュリー計画モニタシステムの最新のわかりにくい虫を追いかけ、チームの仲間たちの感嘆の言葉を浴びるのを夢見ることがある」と書いています。
ワインバーグ程のエンジニアでも、技術的能力を手放すことは受け入れがたい選択だったのです。ですが、それを手放すことによって、ワインバーグ自身も、著述家としてコンサルタントとして、成功を収めていくことになります。本書はエンジニアが「エンジニアを乗り越えていくためのヒント」が随所に散りばめられています。
私が先に例にあげたベテランたちのように、技術にこだわりたければ、こだわることは不可能ではないと思います。しかし、自分達の世代にしか理解のできない開発環境を使ったりすると、若手からは嫌われてしまいますし、それが通用しない環境に入れば、頭の回転の速い若手と最新の技術にキャッチアップする競争をしなくてならなくなります。不可能だとは言いませんが、かなりシンドイですよね。
私自信もブログを始めた理由の一つが、いつまでもエンジニアでいる訳にはいかないという未来が見えてしまったことで、次のキャリアを考える時期にきたのだという危機感が芽生えたことにあります。
最近では、エンジニアを続けながらも情報発信をする人が増えてきましたね。彼らの中にもエンジニアであることを乗り越えて、インフルエンサーやプロデューサー的な立ち位置で仕事をし始める方が出てきています。かれらは新時代の『スーパーエンジニア』だと言えるのかもしれません。私も自分なりにエンジニアを乗り越えていく方法を考えたいと思っています。それが経営者なのか、設計コンサルタントなのか、著述家なのか、インフルエンサーなのかちょっと今はまだわかりませんが、昨今の動向を見ている限り、複数を兼ねることが正解のような気もしています。
エンジニアがエンジニアであることを乗り越えて、次のステップには何があるのか。ある程度エンジニアとしてキャリアが出来てきたときこそ、考えておいたほうが良い点かと思っています。
今日はこのへんで。また機会があれば、他に影響を受けた本を紹介したいと思います。
