エンジニアの2つの学習

エンジニアを続けていくためには、技術習得を続けますよね。これを前提にしますがこの前提に対しては肯定していただけるのではないかと思うのです。

まず、新卒の学生若しくは別の業界から何か勘違いがあって中途でシステムエンジニアとしてのリクルーティングの門を叩いて採用されたとします。採用後に行われる組織の教育は、ビジネス教育がほとんどなくてシステム開発に必要な道具のプログラミングの育成の機会を強制的に設けられるわけです。コードを書けるようになれ、って。

システム開発に必要な教育

システム開発に必要な教育は、プログラムを書けるようになることです。システムエンジニアですから顧客の業務課題をシステムで実現することがお仕事です。お仕事なので顧客の代わりにシステムを作り、対価を得てビジネスをするわけです。

対価を得るためにコードを書けないといけない。だから、コードが書けるように教育します。

ただ、いきなり言語をリファレンスを渡してコード書けよと言われても書けるものでもないし、それまで顧客の業務課題をコードにしてきたことはないのでどうすればコードを書くことができるかの手立ても一緒に教育しなければならいのです。

なので、いきなり言語のリファレンスを渡すのではなくて、道具の使い方からその道具を使って作ったコードの検査の仕方を教育することになります。

・道具の揃え方
・道具の使いかを覚えるための演習の進め方
・進め方の記録の仕方
・道具としてのコーディング
・コードの検査

言葉の選択についてはさておき、プログラミング教育での要点としては上記で包含していると思います。

ところで、こうした教育はテキストにして資料を配ります。つまり体系化されている。それは言語によって表現されている。だから、人数に関わらず、集合教育で行えるということなんです。

人数に関わらず、集合教育を行えるということは、教育が終わるかどうかを教育の対象者が身につけたかどうか検査、つまりテストや成果物の評価により習得状況を可視化できるということです。これは次にように捉えることもできます。

体系化され言語化できる対象については、形式知を移転できる。

上記のように移転できる教育で身につけた技術は、コードを書くための技術移転として行うのですから、育成されたエンジニアが教育後に従事する仕事はプログラム開発です。その世界にあるものは、決められた仕様をコードに変換する作業です。

言語化されていても形式知を移転できない

2つある教育の2つ目。2つ目は、体系化され、言語化されていても、形式知として移転しようとしても一律でできないものがあります。

それが企画、構想、業務課題からの要件抽出などです。こうしたテーマについては様々な書籍が出されていますし、研修も用意されています。そして高価なんですよね。こうした研修は。

必要だろうと研修の機会を与えられて行ってみると渡されたテキスト、方法論を学んで戻ってきて実践に使おうとするとこれが使えない。使えないのは、方法論なのか実は手法を習得しきれていないエンジニアなのかって話はありますけれど。

上記のような企画、構想、要件抽出などは、それを行う対象の背景や文脈を理解できる知識やそれに必要なスキルの両方が必要になるのです。両方が伴って初めて道具の方法論がつかえるようになる、と。

対象のテーマについて、考え方、捉え方にどのように向き合うか、思考の方向性を作り出す技術が必要となってくるのです。

言葉で書くととても短くで簡単なんですが、この

思考の方向性を作る技術

はとても難しいのです。簡単であれば、絶対的に不足しているアーキテクトのなり手の問題もコンサルタントの問題も当の昔に解決しているはずですから。

ここをブレークスルーしないといけないのですが、何せ、体系的に言語化したとしても、思考の方向性を作り出す技術は、教育対象者に依存しすぎてしまうのです。

それを理解して教育していないから高価な研修の機会を設けてもブレークスルーするための鍵を持っておらず、コーディングを覚えさせるための鍵穴が合わない鍵を持ってるくせに育たないと言っているにすぎないのです。そこを解消しないと一向によくはならないです。