少し前のことになるが、今年の 4 月に「エンジニア基礎」という資料が公開された。概要欄の説明とそこからリンクされているブログ記事によると、ウィルゲート社のエンジニア新卒研修の資料を加筆修正したものとのことだった。
SNS の X (旧 Twitter) でも話題になっていたので知っている方も多いのではないだろうか。
内容としては新人のエンジニアに向けて、スタンスやマインドを習得できることを目的として作られたと書かれている通り、新人の気持ちに寄り添うようなスタイルで、一般的なことと具体的な例を織り交ぜながら分かりやすくまとめられている。評判が良いのもうなづける。
その一方で、「エンジニア基礎」というタイトルにしては、後半の一部を除くとエンジニアに限らない、新卒の方なら誰にでも当てはまるような内容となっているのは気になった。
もっとも新卒研修であれば限られた時間の中、説明できる内容には限界がある。教える人と教わる人との関係性やバックグラウンドによって伝えるべき内容も変わるだろう。また私自身もエンジニアの教育に詳しいわけではないので、この資料を初めて見たときは「もっとエンジニア (リング) にフォーカスするにしても、何をどこまで教えるべきか?」という疑問の回答は持ち合わせていなかった。
そのためあまり旬の話題でもなくなったのは承知の上で、その後調べてみたことを今更ながら記しておきたい。
なお本稿では「エンジニア」と「技術者」はほぼ同義の用語として、慣例や気分に従って使い分けている。気になる方はそれぞれどちらかに言い換えても構わない。
プロフェッショナルとしてのエンジニアになるための教育・研修について考えた場合、現在の日本で参考になるものとしては技術士と JABEE 辺りが真っ先に挙げられるだろう。……と書いてみたものの、実際には社内の教育に携わるような方でも、どちらも全く聞いたこともないという方が多いかもしれない。まずは前者について少し紹介してみる。
「技術士」は技術者のための日本の国家資格であり、文部科学省が所管となっている。この資格は 1957 年に制定、1983 年に改正された技術士法に基づいている。資格を取るための資格試験があり、この試験に合格したものだけが「技術士」を名乗ることができる (名称独占資格)。 もともとはアメリカの Professional Engineer(PE) 制度を参考に作られたものだが、PE が業務独占資格である一方、日本の技術士は業務独占資格ではないという違いがある。そのため技術士にならないとできない業務があるわけではない (建設などでは事実上の独占資格として扱われることもあるらしい)。それもあってか、技術士の部門の中で IT に相当する情報工学部門の技術士登録者数は 2022 年度末で 2,302 人であり、技術士全体のうちの 2% に満たない。少なくとも IT 分野ではあまり一般的な資格とは言えないだろう。参考までに、情報処理技術者試験での基本情報技術者は令和 5 年度の 1 年間だけで 5 万人以上、応用情報技術者は 1 万 7 千人以上の合格者がいる。
なお、JABEE(一般社団法人日本技術者教育認定機構) も重要なものの、こちらは大学などの教育機関で行われる技術者教育プログラムに関係するものなので、本稿では詳細については省くこととする。興味のある方は合わせて調べてみるとよいかもしれない。
さて、では、技術士に求められるものは何か。これについては、日本技術士会が公開している「修習技術者のための修習ガイドブック」が詳しい。
修習技術者というのは技術士の一次試験の合格者のことで、つまり技術士になる途中の過程にいる者を指す。その先に進み、技術士となるために身に着けなければならないことが書かれている。
この修習ガイドブックでは、技術士に求められる課題として大きく以下の 3 つが挙げられている。
最初の 2 つについてざっくりまとめると、「専門技術能力」は専門的な知識や技術であり、「業務遂行能力」はそれを使って問題解決を図るための能力だと言える。
専門職である以上、その専門技術に詳しく、能力も高いことは大前提である。が、技術者としては、単に知識が詳しいだけでは意味がない。 その技術を使って何か構築したいこと、実現したいことがあるわけで、それを実現するための能力も持ち合わせていなければならない。この能力が「業務遂行能力」である。 コミュニケーション、リーダーシップ、プロジェクトマネジメントといった IT エンジニアにもおなじみのスキルは、こちらの方にまとめられる。
注目するべきは 3 つ目の「行動原則」である。前述の 2 つと違ってこれは「能力」ですらない。つまり技術士に求められるのは能力だけではない。
行動原則はさらに以下の 5 つに細分化される。
このうち 3 つ目に挙げられている「倫理」は一般的な社会人としての倫理ではなく「技術者倫理 (Engineering Ethics)」を指す。
意外に思われるかもしれないが、技術士においては倫理が重要視されている。技術士としての行動規範とも言える技術士倫理綱領 が定められているだけではなく、技術士倫理綱領について詳しく解説する「技術士倫理綱領への手引き」も公開されている。
また技術士プロフェッション宣言 においても、プロフェッションの概念の 4 項目のうち、第 2 項目では「厳格な職業倫理を備える。」とうたわれている。
ここまで倫理が強調されるのはなぜだろうか。その経緯までは追いきれていないが、私見では最終的には個々人の内心によってしか守られないことがある、ということではないか。
行動原則の他の項目からも分かる通り、行動原則では社会と技術 (と技術者) との関わりに重きが置かれている。社会に対して、あるいは社会の中で高度な技術を適切に構築・運用するにはどうすればよいか。個人と組織が一定の技術能力を高め、適切な規則やプロセスを定めて運用されるようにすれば実現できるのだろうか。そうかもしれないが、実際にはそれだけでは難しい、というのが歴史の教訓なのだろう。
技術者倫理の本を紐解くとたびたび触れられる例には、チャレンジャー号の事故がある。また比較的最近の資料では、福島第一原子力発電所の事故が例示されることもある。どちらも惨事を引き起こしたプロセスを解明するための詳細な調査結果があるせいも大きいかと思われるが、その被害による喪失の大きさ、どうにかして被害が食い止められなかったか、そのためにはどうすればよかったのか、という切実な思いとも無縁ではないだろう。
それを防ぐには、エンジニア一人一人が問題に対して真っ当な倫理観を持ち、致命的な事故が起こる前の最後の歯止めとして機能させるべきだったのではないか。そのための倫理綱領であり、プロフェッション宣言なのだと思われる。
とはいえこのような行動原則を徹底させるのは難しい。また、それ以前の問題として、このような行動原則が知られていないし、積極的に周知させようとする動きも足りていないのが現状ではないだろうか。
ここで冒頭に示した「エンジニア基礎」を振り返ってみよう。ここまでの説明を踏まえると、この資料は専門技術能力と業務遂行能力について教えるためのものだ、ということが分かる。一方で、行動原則についてはぼ触れられていないに等しい。
これはこの資料に限ったことではない。技術士の課題の図表を眺めていると、似たようなものとして「IT スキル標準 (ITSS)」を想起させるところがある。これは IPA(独立行政法人情報処理推進機構) がまとめているもので、「各種 IT 関連サービスの提供に必要とされる能力を明確化・体系化した指標であり、産学における IT サービス・プロフェッショナルの教育・訓練等に有用な「ものさし」(共通枠組) を提供しようとするもの」とされている。
そして IPA と言えば ITSS よりも基本情報技術者試験 の方がよく知られているだろう。現在の ITSS は、V3 の改訂の際に基本情報技術者試験がそのレベル評価手段として使えるように、試験内容と ITSS の整合性がとられるようになった。
もっとも、ITSS や基本情報の出題範囲にも「技術者倫理」の語は含まれている。とはいえ、基本情報の試験対策本などを読んでみても、技術者倫理について手厚くフォローしているようには見えない。そもそも試験要項の中でも、「法務」のサブカテゴリとして「その他の法律・ガイドライン・技術者倫理」があるくらいで、法のついでに技術者倫理にも触れておく、くらいの扱いに過ぎない。しかし、「法と倫理」という表現もあるように、本来であれば法では定められておらず、法的責任は問われないようなことであっても、公益を損ねかねない問題について何かしらの対処を行うことが期待されているのが「技術者倫理」である。サブカテゴリに含まれてしまっていること自体、何かを取り違えているのだと思わざるを得ない。
このような扱いの低さはなぜ生まれるのだろうか。
一つには、「エンジニア基礎」で説明されているところの「視座」の問題がある。例えば新人エンジニアとして仕事をする場合、仕事の相手としては主に自チームや上司くらいしか見えないかもしれない。これが組織の中で視座を高めていくと、他部門や顧客、取引先などが見えてくるだろう。しかし、エンジニアリングの影響範囲はさらに広く、公衆、そして社会が含まれる。社会や公衆に向き合うには、単純に企業の中から業務や事業を見ることよりもより高い視座を必要とする。業務では優秀なエンジニアであっても、普通に仕事をしている限りではそこまでの視座を求められる機会があまりなく、また教わったり教えたりすることもないのではないだろうか。
さらにそもそもの話として、技術者倫理は企業における経営の論理との相性があまり良くない。『技術士ハンドブック第 2 版』の第 10 章の「10.7 従業員としての倫理」や『第 2 版 科学技術者の倫理 その考え方と事例』の第 8 章「従業員としての技術者」でも触れられている通り、企業と技術者倫理は衝突することがある。その場合、単なる従業員であるエンジニア個人は立場が弱い。「従業員としての技術者」の冒頭でも技術者が正しいことを行おうとした結果クビになる話から始まっている。つまり、企業には技術者倫理について啓発する動機が弱い。
それもあってか、技術者倫理を推進するために企業とは異なる組織体が言及されることがある。文献ではよく「学協会」という用語が出てくるが、日本の学会は学術寄りで現場のエンジニアからはほとんど存在感がない。よく見かけるコミュニティでも、Ruby の会も含めて、あまりそのような機能を持っているようには思えない (強いて言えばセキュリティ分野では日本ハッカー協会がある程度機能するかもしれない)。これは私たち自身の今後の課題と言える。
だいぶ話が発散してしまったがまとめたい。
技術は広く社会に影響を及ぼすことがある。そのため、技術に関わるエンジニアは、その社会への影響も考え、対処しなければならない。 Rails などの Web アプリケーション開発者のことを「(IT|Web) エンジニア」と呼ぶのは大げさに感じる向きもあるようだが、むしろ Web が社会の基盤として広く進出/侵食しつつある現在、技術者として一定以上の能力と見識を持つことが期待されるようになりつつあるはずである。さらに、単に能力を高めるだけではなく、社会と公衆への影響を考慮し、適切に行動するための倫理も備えることが求められている。
しかしながら、技術者の倫理は企業における経営の論理と衝突することがある。そのような場合、現状ではその衝突をおさめるための負担がエンジニア個人に偏ってしまいかねない。 この問題の解決には、技術者倫理を広く知られるようにするともに、企業とは別の、あるいは企業の枠を超えたしくみを作っていくことが、これからの私たちエンジニアの課題として残されている。
早いもので Rubyist Magazine が創刊されて 20 年が経過した。それにちなんで、今号では20 周年記念インタビュー記事 や、20 周年に寄せられたコメントの記事 も掲載されている。
本稿では IT エンジニアと社会の関係について触れたが、Ruby と社会の関係もこの 20 年で大きく変わってきた。
20 年前、Ruby を言及する際に「国内外の情報インフラの基盤技術として社会を支えているプログラミング言語の一つ」として紹介しても面白い (あるいは面白くもなんともない) 冗談程度にしか思われなかった気がする。これが 20 年たった現代では、まったく冗談ではなく字義通りの言葉として違和感なく受け取られてしまうだろう。 それもひとえに社会を支えるサービスに Ruby を使ってきた人たちと、それに耐えうるよう Ruby とそのエコシステムを育ててきた人たちが費やしてきた努力の賜物である。改めて感謝を記しておきたい。
そしてこれからの Ruby についても、その軌跡が Rubyist Magazine に残されていくのを見届けていきたい。