世界を動かす技術を、日本語で。

優れたエンジニアを育む要素は、優れたエンジニアリング組織を作る (2024)

2025年5月19日原文(moxie.org)

概要

  • ソフトウェア開発は 科学と工学の境界 に位置する独特な分野であることを指摘。
  • ビジョンとエンジニアリング の関係は一方向ではなく、相互に影響し合う関係であることを強調。
  • 抽象化層の利用 が創造性と理解にどのような影響を与えるかを考察。
  • 組織構造 における抽象化とサイロ化の弊害を論じる。
  • 深い理解が 高品質な成果物 やイノベーションの鍵であると結論付ける。

ソフトウェア開発における科学と工学の境界

  • ソフトウェア開発者は 自らを「ソフトウェアエンジニア」と呼ぶ が、大学の学位は多くが 「コンピュータサイエンス」 である状況を指摘。
  • 科学(サイエンス)工学(エンジニアリング) は本来異なる分野であることを確認。
  • ソフトウェアは 完全に理解された計算機という人工の宇宙 の中で行われるため、工学的側面が強いように見えることを説明。
  • 物理学や生物学のような科学分野は 未知の理解を追求する のに対し、ソフトウェアは 既知の要素を組み合わせる工学的作業 であるという見解を紹介。
  • しかし実際には、ソフトウェア開発もまた 発見の連続 であることを主張。

ビジョンとエンジニアリングの相互作用

  • ソフトウェア開発においては ビジョンとエンジニアリングが双方向に影響し合う ことを強調。
  • 例として、初期の コンピュータグラフィックス におけるカラーサイクリング技法を紹介。
    • Indexed color system を本来の用途とは異なる形で活用し、 想定外のアニメーション効果 を生み出した事例を説明。
  • 深い技術理解が 新たなビジョンや発見 をもたらすことを示唆。
  • 理解と創造 が相互に作用することで、革新的な成果が生まれることを確認。

抽象化層と創造性の関係

  • ソフトウェア開発では 抽象化層(abstraction layer) の利用が一般的であることを説明。
    • 例: RDBMS、HTTPライブラリ、ゲームエンジン などの抽象化層を活用することによる効率化を確認。
  • 抽象化層を 「理解の省略記号」 として使う場合と、 「ブラックボックス」 として使う場合の違いを指摘。
    • ブラックボックス的利用は 創造性や品質の低下 を招くリスクがあることを強調。
  • 抽象化層が増えることで 量産は進むが、質や独創性は必ずしも向上しない 現象を指摘。
    • 例:ゲームエンジンの普及によりゲーム数は増加したが、 高評価作品の割合は増えていない ことを確認。

組織構造と抽象化の弊害

  • エンジニア組織の拡大に伴い、 自律型チーム(autonomous teams)階層型組織(hierarchical organization) の議論があることを説明。
  • どちらの組織論も ビジョンとエンジニアリングの一方向的関係 を前提としていることを指摘。
  • チームのサイロ化や抽象化は、 組織内のブラックボックス化 を招き、 洞察やイノベーションの阻害要因 となることを強調。
  • Skypeのモバイル対応 を例に、組織のサイロ化が 迅速な変革や創造的対応を困難にする ことを示唆。

深い理解と高品質な成果物

  • ソフトウェア開発や組織運営において、 深い理解が創造性や高品質な成果物の源泉 であることを再確認。
  • 抽象化やブラックボックス化に頼り過ぎることで、 本質的な理解や創造性が損なわれる危険性 を警告。
  • 理解と創造性のバランスを意識的に保つこと の重要性を提案。

Hackerたちの意見

映画製作者はカメラの詳細な作り方を理解しなくても素晴らしい映画を作ることができるし、カメラの仕組みを知っていることと出来上がった映画の質との間には予測可能な関係はあまりないと思う。この文は、単一のポイントを支持するために二つの異なることを混同している。一つは正しいが、もう一つはそうではない。映画製作者が素晴らしい映画を作るために「カメラの作り方」を知る必要はないのは正しい。しかし、映画製作者は確かに「カメラの仕組み」を知っている必要がある。レコボタンの位置を知っているというペダンティックな意味だけでなく、偉大なバイオリニストが自分のバイオリンの仕組みを知っている必要があるのと同じように(でもバイオリンの作り方は知らなくてもいい)。カメラは映画の芸術的な道具であり、それをうまく使うためにはレンズの選択、絞り、シャッタースピード、露出、焦点面、照明、フレーミングなどを理解して、望む芸術的な結果を得る必要がある。この文のもう一つの混乱の可能性は、「映画製作者」という包括的な用語で、実際の例がカメラの操作に狭く焦点を当てていることだ。映画を作るためにカメラをどう使うかを決めるのは一般的に撮影監督の責任だ。時には特別なスキルを持つ監督が自分自身で撮影監督を務めることもあるが、役割やスキルセットは作曲家とバイオリニストのように大きく異なる。

この点で混乱している人は、YouTubeのWolfcrowによる「なぜ[映画]は今でもビリオンダラーに見えるのか」という動画を見てみるといいかも。映画アーティストがカメラの仕組みを知らなくてもいいという考えは笑えるよ。カメラだけじゃなくて、フィルムの種類、処理方法、レンズ、照明、そしてそれらすべての相互作用や撮影対象についても。素晴らしい映画には細部への注意がすごい。

バイオリンの話が出たから、最近の発見をシェアするね。ピアノ(グランドピアノみたいなやつや、最近の電子ピアノも含めて、洗練された鍵盤アクションメカニズムを持ってるやつ)は、双方向のフィードバックを提供するように作られてるんだ。鍵を押すときのフィードバックがあって、ペダルに足を置くと感じる低音の振動もある。この二つが組み合わさることで、楽器との「関係」を築くのに役立つんだけど、まだ自分では一つも作れないんだよね。

あなたのコメントはエンジニアリングの優位性の罠にはまってるね。確かに、カメラ(や他の多くの機器)の仕組みを理解する必要があるけど、異なる調整可能なパラメータが完全に直交していないからなんだ。> カメラは映画の芸術的な道具で、うまく使うにはレンズの選択、絞り、シャッタースピード、露出、焦点面、ライティング、フレーミングなどを理解して、望ましい芸術的結果を得る必要がある。これが重要な文だよ。もしフィルムカメラの出力を完璧に模倣するデジタルカメラがあったら、70年代の「映画製作者」にデジタルカメラを渡せば、同じ品質の映画を成功裏に作ることができるだろう。確かに、焦点距離が被写界深度に影響を与えることを理解する必要はあるけど、結局は出力をコントロールすることが大事なんだ。システムの内部の仕組みを理解する必要は本当にないんだ。理解すべきは、どのパラメータが出力にどのように影響を与えるかだけなんだ。>> カメラの仕組みを知っていることと、結果的な映画の品質の間には予測可能な関係はあまりないかもしれない。確かに、通常はその関係を理解してうまく使うためにある程度の技術的理解が必要だけど、道具の内部の仕組みを完璧に理解しても、良い職人になるとは限らない。重なる部分はあるけど、それだけなんだ。良い映画を作るためには、映画製作の部分をしっかり理解する必要がある。だから、技術的な知識が映画の品質に直結しないという観察があるんだよね - それは必要だけど、十分ではない基準なんだ。

ソフトウェアを作る人たちは一般的に自分たちをソフトウェアエンジニアと呼ぶ。エンジニアはプロセスに従い、物事を測定する。もし開発者が物事を測定していないなら、大抵はそうじゃないから、彼らはエンジニアリングをしていない。少なくとも、何か新しいことをしているなら、彼らは書いている。それ以外は、ただタイピングしているだけ。ソフトウェアはたくさんのタイピストを雇っている。優れたエンジニアを選びたいなら、二つの特性を見極めればいい:誠実さと持続力。誠実さは自分以外の世界への意識で、知性とは負の相関がある。誠実さがあれば、規律ある勤勉さが見つかる。少しの知性を加えれば、複雑な指示に従って高い精度を達成できる人も得られる。創造性は持続力と高い知性の子供だ。創造性はプロセスの多くのバリエーションを試し、観客や指標に対して質を慎重に見極めることで達成される。もし一群の道化師を雇ったら、サーカスができる。

ソフトウェアはたくさんのタイピストを雇っている。私たちは多くの強力なタイピストを持っている。

創造性には持続力と高い知性以上のものがあると思う。DockerやTerraformはどう?超シンプルなアイデアで、私が見る限り、持続力の結果でもなく、特に知的に負担のかかる発明でもなかった。創造性には公式があるとは思わない。時には起こるし、時には起こらない。

これは本当に馬鹿げた意見だね。もし、もっと伝統的なエンジニアの友達が既存の部品のドキュメントをもとに計画を立てるのに一日かけたら、急にエンジニアじゃなくなるの?サプライヤーのところに行ってプローブを持ってデータシートを全部やり直せって期待してるの?

価値があると思うものがウェブサイトにあるのに、著者がそのウェブサイトをWayback Machineから除外しているのを見るのはちょっとイライラする。これじゃ、コンテンツを信頼できる方法で簡単に保存できない。自分でホストして、見つけるための解決策を作らなきゃいけない。

もし役に立つなら、私が本当に楽しんでいて、また見返したい記事を見つけたときにやることを教えるね:Googleドライブにこれ用のフォルダを作って、軽いカテゴライズのためのサブディレクトリをいくつか作って、そこに記事のPDFコピーを保存してる。将来的にウェブサイトが消えちゃう心配もないし、検索もしやすいよ。

Pocketみたいなものはどう? https://getpocket.com/home

前半は、このエッセイが「ソフトウェア開発は実際に発見に満ちている」と言っているので、ソフトウェアエンジニアリングは科学のようだと主張しているが、「与えられたビジョンを実現するために、計算の複雑なシステムから利用可能なものを組み合わせて組み立てるというエンジニアリングの実践」ではない。これは非常に理解が乏しい。すべてのエンジニアリングは発見に満ちている。電気エンジニアは、同じタスクを異なるリソース使用とパフォーマンスのトレードオフで行う新しい回路を常に発見している。土木エンジニアも建物で同じことをしている。などなど。> ソフトウェア開発は抽象化レイヤーに依存する利点がある.... 他のすべてのエンジニアリング分野もそうだ。すべての新しい機械が最初の原則から作られていると思うの?> 計算は非常に複雑で、これらのインターフェースは決して完璧にクリーンではない... 著者はこれが計算に特有のものであるかのように暗示している。おそらく、彼らは複雑なアナログ回路を一連のコンポーネント回路を組み合わせて作ることを試みたことがないからだ。

Hacker Newsで議論の続きを見る