アーキテクチャ(16)

ケースメソッドとテクニシャン

(ジョブディクリプションが、アーキテクチャ実現の鍵を握ります)

 

1)ケースメソッドとアーキテクチャ

 

ケースメソッドの目的は、アーキテクチャの作成能力の習得にあると書きました。

 

良いアーキテクチャの作成には、常に全体を見渡して、部分最適に陥らないことが必要です。

 

これは、実現の困難な課題です。

 

今、非常に優秀なAさんが、アーキテクチャの設計をしていると仮定します。

 

この検討中のアーキテクチャはかなりできの良いものですが、Aさんを持ってしても改善できる余地はあるでしょう。

 

それでは、どうして改善すべきでしょうか。

 

Aさんと同じくらい優秀な人を数人集めてきます。このグループBに属する人がカーバーする専門分野はAさんとは完全に重なることはなく、ずれているはずです。

 

ここで、Aさんが、グループBに属する人とディスカッションすれば、Aさんは、アーキテクチャを改善できるはずです。

 

つまり、ケースメソッドにおけるディスカッションとは、自分にかけている知識や視点を補うことで、アーキテクチャを改善する技術を習得する手法です。

 

ディスカッションは、アイデアを出すためのブレーンストーミングではありません。アーキテクチャを改善するための建設的な議論です。

グループBに属する人は、知識や判断能力の高い人でなければディスカッションする意味がありません。

 

グループBに属する人が、そのレベルに達しているか否かは、アーキテクチャを提案してもらえばわかります。

 

このようにケースメソッドで学習すれば、自分の知識や判断の不十分な部分を周囲の優秀なスタッフの能力を生かす形で補うノウハウを身に着けることができます。

 

ケースメソッドで学習したCEOは、独断に陥いらないノウハウを身に着けるわけです。

 

スマートフォンの発売に、スティーブ・ジョブズは反対であったことが知られています。ジョブズは最終的には、周囲の優秀なスタッフの意見を受け入れて、iPhoneの開発に着手します。ジョブズのこのような意思決定は、ケースメソッドの目指しているものです。

 

よく、ブレーンストーミングでは、ろくなアイデアは出てこないという人がいますが、アーキテクチャを設計するディスカッションは系統的なもので、思い付きではありません。ディスカッションの目的を明確にしないと、ディスカッションは時間の無駄になってしまいます。

 

2)テクニシャンとエンジニア

 

テクニシャンとエンジニア、あるいは、サイエンティストとエンジニアという区別が欧米にはあります。

 

日本では、テクニシャンとエンジニアの区別ははっきりしていません。

 

このためテクニシャンとエンジニアを身分制度のように感じている人がいるかも知れません。平均的な給与金額や、最終学歴をみれば、エンジニアがテクニシャンより高くなっていますので、差があることは事実です。

 

前にも引用した湯之上隆氏の説明を再度引用します。

 

<==

 

 まず、欧米人は、理論が先にある。そして、開発初期に徹底的に議論を尽くして方針を一本化する。その上で、規格、ルール、ストーリー、ロジックをつくる。逆の言い方をすると、欧米人の技術者は手先が不器用で実験が下手である(というより技術者は一切実験をせず、テクニシャンと呼ばれる職種に任せる文化がある)。

 

==>

 

ここでは、欧米では、技術者(エンジニア)とテクニシャンは別の職種であると書かれています。

 

Indeed Editorial Teamのテクニシャンとエンジニアの 違いの一部を紹介します。

 

<==

テクニシャンとエンジニア: 違い

 

テクニシャンとエンジニアは、プロジェクトを成功裏に完了し、機器を維持し、安全プロトコルが守られていることを確認するために協力することがよくありますが、これら 2 つの職業にはいくつかの違いがあります。最も一般的な違いは次のとおりです。

 

    テクニシャンはエンジニアの仕事を支援しますが、エンジニアは従業員を監督し、プロジェクトを管理します。

 

    テクニシャンはプロジェクトの大まかなレイアウトを起草し、エンジニアはプロジェクトの開発を担当します。



    エンジニアは、その業界に関連する科学の理論に基づいて作業を行いますが、テクニシャンは、エンジニアによって展開されたこれらの理論の実用化に重点を置いています。

 

    エンジニアは問題を解決することに重点を置いていますが、テクニシャンは問題を解決するために必要な変更を実装することに重点を置いています。



あなたに最適なキャリアを選択する方法

 

    責任のレベル: エンジニアは、テクニシャンよりもはるかに多くの責任を負っています。テクニシャンは「実行者」であり、プロジェクトを完了する任務を負っていますが、エンジニアはそれらのプロジェクトの設計と実装を担当しています。

 

    問題解決能力: テクニシャンは問題を特定して解決策を考案する能力が求められ、テクニシャンは解決策を実行に移すだけの能力が求められます。問題解決の精神が強い場合は、エンジニアとしての仕事が適しているかもしれません。

 

==>

 

以上のように、エンジニアはプロジェクトを実行するためのアーキテクチャを設計します。テクニシャンは、プロジェクトのモジュールを進めます。

 

日本で、エンジニアとテクニシャンの区別がないわけは、アーキテクチャ設計の出来たプロジェクトを進めることがないためと思われます。更に、踏み込んでいえば、日本にはテクニシャンしかいない、エンジニア不在なのかも知れません。

 

学習の速度は、人によって違いがあります。そのような場合、使うことのない知識を学習することは非効率です。テクニシャンの学習は、分野が限定されていて効率が高くなります。効率が悪ければ、給与は下がりますので、テクニシャンは合理的な制度になります。

 

実は、プロジェクトのアーキテクチャを考える上で、テクニシャンは不可欠な要素です。日本のように、専門性を無視した教育や人材育成では、モジュールを担当するテクニシャンがいないことがあります。そうなるとプロジェクトのアーキテクチャを組み立てられなくなります。

 

テクニシャンの給与を上げる方法は、ジョブディスクリプションを明確にすることです。ジョブ型雇用では、これが原則です。

 

日本のある企業のように、DXに対応するために、新規採用のうちITエンジニアの比率を10%にするというような方針の企業は最悪です。ITエンジニアでは、専門は細分化しています。専門外であれば、その部分を学習する時間が必要です。ジョブ待ちになったり、学習時間が必要になれば、労働生産性は、どんどんさがりますので、給与も下がります。これは、経営者はプロジェクトのアーキテクチャを組み立てる能力がないためにおこる現象です。このタイプの企業に就職しても、ジョブディスクリプションのできる外資系企業と比べれば、給与はがっがりするくらい安くなります。

 

職安にいっても聞かれるのは、資格を持っていますかで、ジョブデスクリプションはありません。エンジニアのジョブディスクリプションは、テクニシャンほど簡単にはいきませんが、それでも、資格取得よりは、明確な記述が可能です。

 

ジョブディスクリプションが明確になれば、大学のカリキュラムも、それに対応したものになります。現在は、この辺りの出口は真っ暗ですが、動き出せば、変化は加速度的に進むと考えます。

 

引用文献

 

Technician vs. Engineer: What's the Difference? 2021/02/23 By Indeed Editorial Team

https://www.indeed.com/career-advice/finding-a-job/technician-vs-engineer

 

半導体製造装置と材料、日本のシェアはなぜ高い? ~「日本人特有の気質」が生み出す競争力 2021/12/14 ET times 湯之上隆, 亀和田忠司

https://eetimes.itmedia.co.jp/ee/articles/2112/14/news034.html