技術者教育について

これはpyspa アドベントカレンダー 2024の12日目の記事です。11日目は@aodagの走るということについてでした。

はじめに

この15年くらいは、おおむね平均すると毎年2，3人程度の技術者をOn the Job Training（OJT）で教育する機会に恵まれており、その中で蓄積した知見や私の考えを散発的に説明していきます。

私自身は受託開発を主たるビジネスとするシステムインテグレータ（SIer）と呼ばれる企業で働いており、足掛け25年程度のキャリアがありますがソフトウェアについて専門的な教育を受けたことはありません。また、教育についても同様です。

このエントリに記載された内容について何らかのエネルギーを注いでくれる方がいるなら、XあたりのSNSでURL付きで指摘して頂ければ非常にありがたいです。

教育によって形成される技術者像

まずは、どのような技術者なら育てられるのでしょうか。私の考えを述べます。

一番最初に明確にしておくことは、ここでの議論はソフトウェア技術者を中心としたものです。強電や弱電といった分類が妥当な技術者の話はしません。また、ソフトウェアが動作するために必要な種々のインフラは全て揃っている前提で考えます。利用者としてオペレーティングシステム（OS）を扱います。しかし、OS自体を作ったり修正することは考えません。

OSIモデルで言うとネットワーク層（L3）あたりが最もプリミティブなレイヤーだと考え、日常的にはほぼ意識しないものとします。基本的にはプレゼンテーション層（L6）を利用します。セッション層（L5）については、業務で利用するコマンドラインアプリケーションやライブラリが露出してくる範囲については理解するくらいの温度感です。

正直言って、楕円曲線暗号がそれ以前の暗号に比べて何故強固なのかを数学的な根拠を持って説明することは私自身もできません。最新のスゴイやつだから使っておく方がいいくらいの気持ちでいます。

ここまでを前提にソフトウェア技術者としての期待値を定性的な基準で説明してみましょう。私は技術者の能力を以下に列挙する5+1段階で捉えています。

ほぼ素人

基本的に最初はみなほぼ素人です。稀に大学でプログラミングをそれなりにやってきた新卒採用の若手がいますが、業務としてのソフトウェア技術者を経験している新卒は恐らく私が所属する企業には来ないのでしょう。遭遇したことがありません。

未経験で他業種から転職してくる方も、基本的にほぼ素人です。

半人前

プロジェクト内で利用するツール類に習熟し、参画しているプロジェクトが採用している開発プロセスに則って報告・連絡・相談を必要に応じてできる状態になっている人です。

業務で求められるドキュメントを記述したり、プログラミングについては他人の成果物をコピー＆ペーストしつつ手直しすることで作業を完了できることを期待します。

私の経験上は、受託開発の業界ではこのレベルの人が最も多いです。経験年数は余り関係ありません。１０年やってても半人前の人は沢山います。

それでも今までは生きてこれたのですから、いい仕事なのかもしれないですね。今後どうなっていくのかは分かりませんが、すぐに状況が大きく変わるとは思えません。

一人前

プロジェクト内で利用するツール類に習熟した上で、開発プロセスに則って作業見積りと業務遂行が出来る人です。

必要に応じた詳細さのドキュメントをドキュメントテンプレートから書き起こすことや、多少のサンプルコードがあれば、ゼロからアプリケーションコードを書くことを期待できる人です。

私が教育を行うなら最初に目指すのが、この状態です。ほぼ素人が対象なら半年から１年程度。半人前からなら最短で３か月程度の期間で一人前のソフトウェア技術者に育てられます。

ただ、所属する企業の新卒採用プロセスは突破するのが非常に難しいため、基礎的な能力の高い方が多く採用されていることは付記しておきます。

チームリード

一人前に働いた上で、他人の面倒をみられる状態になった人です。他のメンバーから相談を受けたり、チーム内にある細かな解決すべき課題に気が付くことも期待します。

ドキュメントテンプレートを作ったり、通常の業務とは別に開発環境や業務環境の改善を必要な相手に提言し、実際に手を動かせるとより望ましいですね。

業務やソフトウェア技術について自発的に学習し、それをプロジェクト内に持ち込めるようになると十分な働きを期待できるでしょう。

学習する習慣を身につけられた人は、ここから更に伸びていきます。ただ、そういう人はごく少数です。

会社組織として考えた場合には、このチームリードを沢山輩出できることが望ましいのですが、私はそれが出来ると明確には言い切れない状況です。

私が教育を手掛けた人の中には、私の元を離れた後に本人の努力によってチームリードに成長する人は何名もいます。ただ、それは私の活動による成果だとは言い難いですよね。

技術責任者

数億円規模以上のプロジェクトにおいて要素技術選定や非機能要件定義を主体的に実施できる人です。

体感ではソフトウェア技術者の1％程度しかいません。そういう人に遭遇したら逃がさないようにしましょう。

こういう人を教育によって再現性高く輩出することは原理的にできないと考えています。中途採用することも非常に難しいでしょう。

会社として出来ることは、そういう稀有な人が学習と訓練によって実績を重ね、それがきちんと評価される環境を作ることです。

例外的な存在

いわゆるツヨツヨ人材については例外的な存在だと考えています。彼らは生活の中に組み込まれた強固な学習習慣を持っており、食事や入浴をするように学習するので、本人は負担感が少ないことが多いです。

昼だろうが夜だろうが、関係なく学習して前に進んでいくので、こういう人達と自分や教育対象を比較するのはやめましょう。比較してしまう時点で負担感なく夜昼構わず技術を触っていないので、そういうやり方には向いていません。

組織的な取組みとして考えた時には、ツヨツヨ人材を理想的な存在であると定義してしまうと、各種の法令を遵守することが難しくなるでしょう。

ツヨツヨ人材の多くは社内外で形成される技術者コミュニティに多く参加するため、会社に所属しているというよりは業界に所属している共有リソースの一種だと考える方が良いかもしれません。自分達のためだけに占有するよりは、業界全体にとって良い方向になるような業務に携わって貰う方がいいんじゃないでしょうか。

こういった人々を適切に処遇するというのは、極めて困難な課題で定式化できるようなものではありません。もし幸運にもそういった人材が社内にいるなら大切に扱いましょう。

教育環境について

継続的な学習や訓練の習慣を確立するには、本人が日常的に接する環境の影響が強いと私は考えています。

独学で必要な知識や技能を過不足なく得ることが出来る人もいますが、多くの人にとっては一緒に学習や訓練に取り組む同じくらいの能力を持つ同僚の存在は不可欠です。

そして、目先の業務をこなすだけでなく、学習や訓練を業務の中に組み込んでいくことが許される環境は組織が強靭であり続けるために必要な事です。

ここでは、教育環境について少し考えてみましょう。

オンラインとオフラインの使い分け

新型コロナの蔓延をきっかけに私が所属する会社でもテレワークできる環境が急速に整えられました。例えば、私が所属する部門では出社率は25%程度です。大多数の従業員は出社せずにサテライトオフィスや自宅で仕事をしています。

そういった状況を前提に考えて下さい。リモートワークを継続したままで効果的な教育を行うことはできるでしょうか？

今現在の私の認識としては、リモートワークのみでの効果的な教育は極めて難しいと考えています。

特にほぼ素人の状態から一人前に育てるには、対面でのコミュニケーションが必須だと考えています。なぜなら、知識や経験が著しく不足していると自らの状況を適切に言語化できないからです。こちらから見れば、明確に知識不足や理解不足によって手が止まっているにも関わらず、それを認識できていないことが多く発生します。具体的な弊害としては、本人にとって助けが必要な時に自分で助けを呼べないのです。

これに対処するには、教育を行う側が能動的に教育を受ける側の状態を観察し必要な措置をとることが望ましいと私は考えています。そのために使うツールとして現代のリモートコミュニケーションツールは基礎的な性能が不足しています。カメラやマイクを通すと余りに多くの非言語的情報を削ぎ落してしまうのです。一時期は、オンライン会議を開いて接続したままずっと作業するというのを試してみたりもしましたが、あまり上手くいきませんでした。

私の所属企業が主に使っているツールはMS Teamsですが非言語的なコミュニケーションを取るための道具としては全く使い物になりません。そのために作られている訳ではないので当たり前と言えば当たり前ですが…。

話は少しずれますが、個々人が独立してタスクを遂行できるチームではリモートワークは有効に機能すると考えています。業務に集中できるよう作りこんだ自宅環境において言語化されたコミュニケーションのみで成果に向かって作業することは効率的で合理的なあり方です。そういった状況では、非言語的なコミュニケーションは業務をすすめる上で弊害になり易いので避ける方が望ましいでしょう。

チーム内で知識や考え方、価値観が統一され一定のルールが徹底された結果、言語化されたコミュニケーションを取らずとも、同じ課題設定に対して同じ結論に到達できることが理想です。しかし、非言語コミュニケーションによって、お互いの考えや状況を類推しあう事によって働くのは精神的なコストが非常に高く、また事故が起きやすいので望ましい状況ではありません。

ややこしいのは、前者と後者を外形的に区別する方法がほとんどないことです。チームの中心的な人物にとっては前者のような環境だと認識していても、単に周りが上手く合せていただけという状況は相応に存在します。

コミュニティの作りこみ

私の所属企業は、それなりに規模が大きいので基本的にはピラミッド型の組織構造をしています。

事業セグメント→事業部→部署→グループといった構造ですね。これによって、基本的な人間関係は縦の構造によって規定されます。

同じ部署内にいたことのある人の事は良く知っているけども、隣の事業部の事は概要レベルでも何をやっているのか分からないというのは、特に珍しい事ではありません。

一方で新卒採用者であれば同期入社と事業部を越えた繋がりを形成できる人達もいます。こういった関係性を横の繋がりと考えた時、会社の中にはより多くの横の繋がりが存在することが望ましいでしょう。私が所属する企業内では、横の繋がりを形成するための様々な取組みが存在します。

技術者教育にも、横の繋がりがあると能力が伸びやすい傾向があると考えています。教育担当者の能力に依存し過ぎるのは望ましくありません。

では、私が取り組んでいる横の繋がりを作る活動をいくつか説明しましょう。

輪読会

少し難しめだったり、分厚くて挫折し易い書籍を複数人で集まって読む会です。例えば「プログラマのためのSQL」や「コードコンプリート」といった書籍を題材にしたことがあります。これらは名著ですが軽い気持ちで読むには辛いですよね。

輪読会では事業部門横断で参加する人を公募して、多くても７，８人で1チームにします。

そして、キックオフの際におおむね10～20ページ程度ずつを、その一人ずつに担当範囲として割り付けます。章や節を基準にすると分かり易いことが多いです。

担当者は、その範囲における議論の中心になる役割を持ちます。具体的には、その範囲内において理解が難しかったことや、納得できなかった部分について輪読会当日までにメモ書きをまとめておきます。

輪読会は１枠１時間で実施し一人分の担当範囲について議論を行います。つまり、一回の輪読会で議論の対象になるのは、多くても20ページ分程度ということですね。

最近やってみてうまくいったのは最初の１５分～２０分を全員が黙読する時間にすることです。これによって、担当者以外の参加者は当該範囲を事前に読んでこなくてもよくなるので、輪読会参加のハードルを下げ心理的負担を低減する効果がありました。黙読が終わったら、担当者が自分の疑問点や納得性の低かった部分について説明し、担当者以外の参加者と議論していきます。

輪読会の主催者である私は基本的にファシリテーションを行うのですが、疑問の内容が複雑すぎたり、ごく単純であった場合には直接回答してしまうこともあります。しかし、重要なのは参加者同士が議論する事で理解を深めることです。

ハイパフォーマーとの面談

これは、社内でハイパフォーマーとして評価されている高度な技術者と、まだそこに至ってはいない中堅くらいの技術者が、直近の業務を題材に面談する場です。

私が所属する企業はSIerですが、技術的能力を評価されて高い職位にいる人（雑に言えば高い給料を貰っている人）は相応に存在します。しかし、あまり目立たない事が多いので組織内における縦の人間関係だけで暮らしていると、社内に高度な技術者はいないし、いても評価されていないと誤解し易い状況にあります。

この取組みでは、中堅技術者が他の事業部門で働いているハイパフォーマーと接点を持つことで、キャリア観を形成できるようにすることを第一の目的にしています。技術者として働き続けたいのに、先が無いと思ったら会社を辞めてしまいますよね。評価のあり方を誤解したまま退職してしまうのは会社にとっても本人にとっても不幸です。そういう不幸を少しでも減らしたいと活動しています。

面談の中ではプロジェクトに対する取り組み方や、採用した要素技術について議論していくことで、仕事への取り組み方を中堅技術者が学習していけるようにしています。ハイパフォーマー側も、自らが所属していない部門で採用されている技術の事例を学習する場として活用しています。

この取り組みを継続していくと、社内に学習意欲の高い技術者同士の繋がりが増えていくでしょう。

雑談用ワークスペース

所属部門の枠組みを超えて緩やかに雑談するために、ある種の社内X（twitter）みたいなものをイメージしたチャットスペースを運営しています。

そこでは、私が作ったチーム内にそれぞれのユーザが自分用のチャンネルを作るような形になっています。

全員が強制参加の「一般」チャンネルにはチームへの新規参加者がいると顔写真付きで自動投稿されます。また、給料日やボーナス時期に何か買物に困っていると「実質無料」などとコメントして購買を煽るボット（人力）がいたりと独自の文化を形成しています。

あまり有用な場所であることを目指してはいないのですが、社内の手続きについて困っていることを書くと詳細を相互に教え合うような空気感もあります。

私が気に入っている文化としては、チャンネル名の一部にアイコンを使う流行が数年前にあって以来、色彩豊かなチャンネルが作られるようになったことです。

類似するようなチームが社内にはいくつかあるという話は聞いたことがあるのですが、私自身はそれらに参加していないので、どうなっているのかは知りません。

こういうものがいくつもあって、それぞれが独自の文化圏を形成するのも一つの多様性だと考えています。

私のやり方における限界

私が考える技術者教育のやり方には明らかな限界があります。それは、教育対象にする人数を増やせないことです。

非言語コミュニケーションを前提に時間をかけて対応するので、多くても７～８人までしか一度に対応できません。

教育対象となる人が持つ現在の能力に応じて、教える内容を柔軟に組み立てているので明文化したカリキュラムのようなものを作り出せていません。

持つべき知識や技能がどういったものであるのかを整理できていないために、再現性の無い活動になっているのです。

例え私に教育を受けた人でも、同じことを同じようにはやれません。

私のやり方では、自分が持つ知識や経験の１割程度、かなり都合よく考えても２，３割程度しか伝達できていないために再生産できていないのです。

現状はあくまでも技術者を教育しているのであって、教育者を教育している訳ではないという状況であるとも言えます。

おわりに

本当は技術者教育における訓練の内容について書きたかったのですが、前提を整理するだけで随分と長くなってしまいました。一旦ここまでにしたいと思います。

年末年始は宴会も多いので、そこでの議論によって、続きを書く気力が生まれる可能性は高いでしょう。

私と直接対面する機会のある皆さまにおかれましては、ご協力のほどをよろしくお願いします。

明日以降の自分に期待して、このエントリの締めとさせてください。