新たな収録の試み
こんにちは、つねぞうです。
デザイン・レビュー編第123回目。
このデザイン・レビュー編は、世の中の様々なもの、主に工業製品について、
私の主観で勝手にデザイン・レビューをしていこうという番組です。
今日はですね、2025年に読んだ本、まとめってものをノートに書いてみたんですけども、
それをまとめている中で、ちょっと思ったことがあるので、そちらについて話してみようかなと思います。
今日はですね、12月30日、もう年末も年末ですね。
今年、実家の方には子供たちと妻だけが帰省していて、
私は家で猫とオルスマンをしているというところで、ちょっと暇だったので、
このタイミングですけども、収録してみようかなと思いました。
ということで、マイクを握っております。
実際に握ってないんですけども、収録しております。
最近、マイクスタンドを買いまして、そこにつけて録音してますね。収録してます。
その前は目の前に、棚というかテーブルの上にマイクを置いた状態で収録してたんですけども、
最近はこのマイクスタンドにちゃんとマイクをつけて、
スタンドというかアームかな?結構腕が長いアームなんですけども、
ディスプレイの裏からアプローチできるような、そういうスタンドですね。
そんなに高くないんですけど、本当に数千円のやつなんですけども、
それを買って見て収録してます。
なぜ今でさらになってそういうスタンドを買ったかというと、
ちょっとね、自分の詳細的なものを作ったんですよ。
今まで自分の部屋というところはなくて、寝室の一角に自分のスペースがあったんですけど、
寝室につながるウォークインクロゼット的なところが2畳ぐらいあって、
そこにタンスとかハンガー、ラックみたいなのが置いてあったんですけども、
ちょっとそこを寝室の方に移動させてスペースを空けて、2畳ぐらいの私の部屋を作りました。
そこに机とか本棚とか移動して、
私の背中にはまだその服がね、ウォークインクロゼットに作り付けのハンガーラックがあって、
そこに服が残ってるんですけども、
そこら辺が収録をするときに反響をとってくれるんじゃないかなと思うので、
そこは残してあります。
ただやっぱりまだね、なんとなく今しゃべってると反響するような感じがあるので、
壁に響きを吸収するようなものを付けたらいいのかなとは思ってるんですけどね。
メカエンジニアの視点
すいません、ちょっと前置きが長くなってしまいましたが、
ちょっとノートでね、今年読んだ本をまとめました。
技術書編、非技術書編というところで、
技術的な内容を書いた本と、あとは小説とか関係ない本、
それぞれ1本ずつノートに書いてありますので、
それちょっと概要欄にリンク貼っておきますので、
後で気になる方は読んでみてほしいです。
そこでちょっと気になったのがですね、
技術書編の中で、
あるシステムというものを設計する上での心得とか、
働く上での心得、
あとはチームビルディングとか、
後輩育成とか、
そういう時の心得的な本、
というのが私結構好きで、
最近特にですね、そういう本ばかり読んでるんですね。
例えばスタッフエンジニアの道とか、
スーパーエンジニアへの道とか、
ハッカーと画家とか、
これちょっと趣が違うんですけども、
ライトついてますかという、
問題発見学みたいな、
問題を見つけるための本みたいな、
そういう本を今年多く読みました。
ただここら辺、これらの本って、
誰が書いたかというと、
ソフトウェアエンジニアの方が書いた本なんですね。
なので内容的にも出てくる例としては、
ソフトウェア関係の開発の現場の話が多くて、
機械、メカ的な、そういうエンジニアさんじゃないんですよ。
そこがね、なんでそういうメカエンジニアが書いた本が少ないんだろうと思いまして、
機械設計者が書いた本ね、
機械設計者、メカエンジニアが書いた、
そういう心得的な本があまりないなと思って、
そこがなんでだろうというのを疑問に思ったんですね。
なのでそこら辺をジェミンに聞いてみました。
なんで少ないんですかというのを聞いてみましたので、
聞いてみて、なるほどなという回答が返ってきたんですね。
なんでそこら辺ちょっと今日一緒に読んでいこうかなと思いますのでお付き合いください。
ジェミンにの回答ですね。
ちょっとかいつまんで説明していきますね。
確かにソフトウェアエンジニア界隈には、
スタッフエンジニアやハッカーとかが、
ギークのような技術そのものではなく、
エンジニアとしての生き方、振る舞い、キャリア論を説く名著があふれていますと。
一方でメカニカルエンジニア、メカ屋向けの同様の書籍は探してもなかなか見つかりません。
なぜこのような不均一が生まれているのか、
業界構造や文化の違いからいくつかの要因が考えられます。
書籍の少なさの要因
1. オープンソース文化と機密保持の違い。
これが最大の要因と考えられると言っていますね。
ソフトウェアの世界というのは、
UNIXやインターネットの例明記から知見を共有するオープンソース文化が根付いています。
コードや設計思想をブログだったりカンファレンスで公開することが推奨されて、
それがエンジニア個人のプランディングになると。
その延長線上でキャリア論だったりマインドセットも言語化されることで、
それが書籍化されやすい土壌がありますということですね。
確かにそうですよね。
オープンソースというところで、
そういったキャリア論、マインドセットというところもオープンソース化されているということなんでしょうかね。
一方、メカの世界というのは、製品が物理的なハードウェアであるため、
技術の革新というものは特許だったり企業秘密で守られています。
図面一枚、加工条件一つが競争力の源泉となるため、
現役エンジニアが自身の仕事のプロセスだったり、
そういう哲学というものを具体例を交えて外部に語るということはリスクになると。
リスクが非常に高くて困難になるでしょうと。
確かにその図面一枚、出せませんからね、企業の外でね。
ということがあるんじゃないかというのが一つ。
オープンソース文化と機密保持の違い。
二つ目、技術の抽象度と再現度ということで、
ソフトウェアというものはコードですね。
コードはテキストであり論理ですと。
クリーンなコード、素結合な設計といった概念は、
ウェブ開発でも組込みでも共通して語れる抽象度の高い哲学になりやすいですと。
一方、メカはですね、例えば熱処理の勘どころだったり、
交差設計の妙というものは、
ある特定の素材、特定の工場、特定の製品文脈に強く依存しますと。
汎用的な心得として抽象、抽出しようとすると、
逆に当たり障りのない内容になってしまい、
書籍としての魅力が出しにくいという側面がありますと。
確かに機械系であれば、熱処理に特化した本とか、
交差設計に特化した本とか、そういった本は実際多くありますよね。
それはソフトウェア関係でもそうなんでしょうけど、
そういった特定の技術、特定の分野に特化した本はあるんだけど、
そこを網羅できるような汎用的な心得として抽出しようとすると、
確かに難しいのかもしれないですね。
3つ目、キャリアパスと個の立ち位置ということで、
流動性の違い、ソフトウェア界隈、IT業界というのは、
人材の流動性が高く会社を渡り歩くことが一般的ですと。
確かに前々回、じゅんぼくさんとお話ししたときも、
3年、4年ぐらいで会社を変えられていて、
7年で長いというようなお話をしていましたよね。
メカエンジニアリングの特性
一方、私はもう入社して17年同じ会社に勤めていますから、
それは確かにそういうところがあるかなと思います。
そのため、どの会社でも通用する普遍的なエンジニア論への需要が高く、
市場が成立しますと。
なるほどね。
IT業界というのは、その変的なエンジニア論。
どの会社に行っても通用するエンジニアというのはこういうもんだと。
そういう書籍、そういう内容に需要がありますよということですね。
組織への帰属。
ハードウェア、特に日本のメーカーでは、
長期雇用を前提とした組織づくりが主流でしたと。
技術や心得は本で読むものではなく、
オジェティで先輩の背中を見て盗む、
あるいは社内、秘伝のタレとして継承される文化が強かったため、
外部向けの書籍にするインセンティブが低かったと言えます。
これが一番しっくりする、しっくりくる感じがしますね、私ね。
流動性の違いね。
確かにそうだな。
一番しっくりきますね。
4番目、歴史の長さと言語化の必要性。
ソフトウェア産業は歴史が浅く変化が激しいため、
我々は何者かどうあるべきかを言語化して定義し直す必要に常に迫られてきましたと。
一方、メカエンジニアリングは数百年以上の歴史があり、
職能としての定義が既に確立されていますと。
改めてメカエンジニアの道を解く必要性が相対的に薄かったのかもしれません。
メカエンジニアの心得はどこにあるのか。
ここから提案もしてくれていて、
メカエンジニアに学ぶべき領所がないかというとそうではありませんと、
形を変えて存在していますということで、
いくつか例を挙げてくれています。
1つ目はプロジェクト実力です。
あるプロジェクトの実力、個人の心得本ではなく、
プロジェクトX的な開発秘話の中に哲学が含まれています。
例として、超音速機開発等の階層、ロッキード社の伝説的開発チームの話だったり、
創業者の辞伝、哲学という本ですね。
例えば、ホンダ・ソウイチロウやトヨタ・キイチロウなどの言葉というものは、
エンジニアとしての心得の塊ですと。
これ、支部長さんに聞けば教えてくれそうですね。
ホンダ・ソウイチロウの夢を力にという本が本当にあるのかな。
ちょっとここは裏取りできていないんですけども、
ホンダ・ソウイチロウの夢を力になどはそういった本ですよと。
確かにそれを恥ずかしながら、
ホンダ・ソウイチロウさんの本を私はまだ読んだことがなくて、
支部長さんがお勧めしている本をいくつか読んでみようかなと思います。
あとは、設計工学としては失敗学。
畑村陽太郎先生の失敗学の勧めなどは、
メカエンジニアが持つべきマインドセットを説いた名著ですと。
最後、結論として、メカエンジニアの心得本が少ないのは、
知見が社外に出にくい構造と、
学びが現場の文脈に紐づいているためですと。
そのため、ソフトウェアエンジニアのように、
ハッカー文化として横口で語られることよりも、
偉大なプロジェクトや偉大な創業者の物語の中に
そのエッセンスが散りばめられていることが多いのが特徴ですと。
なるほどね。
だから、メカエンジニアが書くそういった、
働く上での心得、マインド的なものの本が少ないんですよ、
ソフトウェアエンジニアリングの流動性
というジミニの回答でした。
なるほどなと思うところがありましたね。
特にキャリアパスのところかな。
ソフトウェアエンジニアというのは、流動性が比較的高いと。
だから、どこの会社でも通用するものが必要なんだよと。
一方、メカ的なハードウェアの会社というのは、
ある意味この年功序列の文句がまだ残っていますので、
その会社の中、それぞれの、ある意味、
特化したような文句があるよということですね。
私自身も他の会社に行ったことがないので、
今、その違う会社に行ったら果たして通用するんだろうかというところは、
非常に不安なところではあるんですよね。
ただ、最近は我々のメカエンジニア、機械設計者というところも、
結構その流動性みたいなのが出てきたんじゃないかなとは思いますけどね。
ということで、今日は、
なんでメカエンジニア、機械設計者が書いた心絵本というものが少ないのかというのを、
ジミニに聞いてみましたという話をしてみました。
このポテキャストへの質問お便りは、
概要欄のGoogleフォームからお待ちしております。
また、Xでハッシュラグデザインフレームを付けてポストしていただけると探しに行けます。
そして、このポテキャストがいいなと思ったら、
各ポテキャストアプリでのフォロー、そして高評価を付けていただけると、
今後の励みになりますので、ぜひぜひお願いいたします。
では、お疲れ様でした。
ご安全に。
