技術伝承の鎖が切れてしまった組込みソフト開発の現場

製造業における技術伝承は、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続けるというものだ。

一方でマニュアルを使って一律に技術習得させるという方法もある。マクドナルドがよい例だ。マクドナルドはマニュアルによる指導、トレーニングを徹底させるために世界のどこのマクドナルドに行っても同じレベルのサービスを受けることができる。これはまさに欧米的な技術の習得方法だと感じる。

日本でも工場では手順書による作業指示があるので、マクドナルドのマネージメントと似ているように見えるが、QC活動などでマニュアルを逸脱した独自のくふうも許しているところがちょっと違う。逆に言えば、一応手順書やマニュアルはあるものの、実際には冒頭で紹介したベテランが初心者に対して技術を習得できるまで指導し、その指導の方が手順書よりも優先されることが多い。

トレーニングの方法として学校でスキルを身につけるというやり方もある。料理学校などは、料理を作る行為自体は学校でやることも、実際に就職した先の店でやることも基本的には同じだから、料理学校で受けたトレーニングは即現場で役立つ。

さて、それでは、ソフトウェアの開発技術はどうだろうか。日本の多くの学校ではソフトウェア工学を現場で使いこなせるまで指導できるところは非常に少ない。先生の中には実際の現場でソフトウェアを作った経験がある人が少ないこともあるし、昔ソフトウェアを搭載した製品を作ったことがある人でも、現役を離れてから10年もたつとソフトウェア開発の方法論自体が変わってしまうこともある。

そこで、先人が成功と失敗から体系化したソフトウェア工学を日本のソフトウェアエンジニアが修得する5つの方法について考えてみる。

【日本のソフトウェアエンジニアがソフトウェア工学を修得する方法】

1. 雑誌、書籍、学会、シンポジウム等の情報から学ぶ（独学）
2. 学校やセミナーで学ぶ
3. 組織内で上司や先輩から学ぶ
4. コミュニティの知り合った友人から学ぶ
5. コンサルタントから学ぶ

この5つの方法をいずれか、単独、もしくは組み合わせでスキル修得して現場に適用できる技術者は実際にはほんの少ししかいない。今回の記事は「それは何故か？」の分析である。

【「雑誌、書籍、学会、シンポジウム等の情報から学ぶ（独学）」と「学校や、セミナーで学ぶ」が難しい理由】

日本のソフトウェア開発の現場は方法論を自分達の案件でやって見せてあげないとできるようにならない。自分達だけで、抽象化された方法論を自分達の問題にテーラリングして取り込むことができるプロジェクトはほんのひとにぎりしかない。なぜなら、製造業における技術伝承は、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続ける方法であり、自分一人ではそれができないからだ。

別な言い方をすると、日本のソフトウェア技術者は抽象化された方法論を自分自身の具体的な問題に展開する能力が低い。なぜ、低いのかというとそういうトレーニングを受けてこなかったからだ。『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事参照のこと。もう少し、正確に言えば公式に具体的な数値を代入することはできるが、公式よりももっと抽象度の高い方法論になってしまうと、目の前に具体的な問題がころがっていても、何をどう当てはめていいのかわからないし、何となくわかったとしても、失敗するのが恐く、試してみる勇気がないので、問題解決の経験値が上がらない。現場の技術者が失敗に対して恐れを感じているというのを最近特に強く感じる。おそらくプロジェクトに余裕がなくなって失敗を許さない雰囲気があるのだろう。

だから、問題解決の経験値が上がらない技術者は本や雑誌を読んでも、セミナーに行っても、学会に行っても、シンポジウムに参加しても、そこで示されている抽象化された方法論を現場に展開することができない。まれに、それがうまくいくケースは二つあって、よっぽど分かりやすい手順が示されている場合と、よっぽどその人の気持ちを揺り動かすことができて試してみる勇気がわいたときだけだ。ただ、前者の分かりやすい手順というのは、逆に言えば少しでも問題の対象にマッチしないところがあると先に進めないというデメリットがある。2つのめの気持ちを揺り動かすという方法は、「時間がない」とか「周りが賛同しない」とか「予算が付かない」などさまざまなハードルが現場にはあるので、気持ちを揺り動かすことができても時間がたつと急速にやる気が萎えてしまう場合もある。

このような理由から残念ながら独学で問題を解決できるところまで持って行ける技術者は非常に少ない。逆に言うとそういう人は希少価値であるため、いずれ自分自身の存在が希少であることに気づき、その価値を最大限活かすために独立したりコンサルタントになったりする。

※宗教的な熱狂に周りを巻き込むことで問題を成功に導く方法もあるが、本来ならば行動の目的や自分達のあるべき姿を見据えた上で、熱狂的ではなく静かな闘志を燃して事にあたるようにしたいものだ。

【「組織内で上司や先輩から学ぶ」方法が難しい理由】

これは簡単で、上司や先輩が現場の問題を解決するために必要な技術を知らない、もしくは、技術伝承する能力がないからだ。もしも、上司や先輩が現場の問題を解決する技術を身につけていて実際に解決できるだけの実力があるのなら、この状態が最も問題解決の成功確率が高い。なぜなら、「ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続ける」という昔からあるアプローチが使えるからだ。この方法は日本の製造業の世界ではスタンダードな技術伝承の方法だから、そのやり方を否定する人はいないし、ハードウェア出身のマネージャもその有効性や効果を十分に理解できる。まわりに反対する人は現れない。

だから、一度組織やプロジェクトが問題を解決する技術を身につけてしまえば、後は新しく入ってきた後輩達にせっせとその技術を伝承していけばよい。ところが、いつの日か、現場の技術者達が新しい問題を解決するための技術を習得することを怠ってしまったために、技術伝承の流れ（鎖）は切れてしまったのだ。ソフトウェア系の外部協力会社に仕事を任せるようになったころから、技術伝承の鎖の途切れが始まったのかもしれない。当時から、役割分担が明確であればよかったものの、徐々に丸投げの度合いは進み始め、メーカーサイドはドメインの知識とソフトウェア工学を結びつけることができなくなり、ソフトウェア受託開発会社は社員にソフトウェア工学を身につけさせるのではなく、より多くの時間働かせることが組織と社員の共通の利益であると考えるようになってしまった。

だから、特に組込みソフトウェア開発の世界では「組織内で上司や先輩から学ぶ」方法が難しくなってしまったのだ。

【「コミュニティの知り合った友人から学ぶ」方法が難しい理由】

実は、実際にやってみて一番有効なのはこの方法だ。自分自身、SESSAMEやEEBOFというコミュニティで知り合った友人から多くを学んだし、コミュニティに積極的に参加している人ほど、ソフトウェア工学を自組織に適応できているように思う。うまくいく理由は、「時間がない」とか「周りが賛同しない」とか「予算が付かない」などさまざまなハードルをコミュニティのメンバーがちょっとした励ましの言葉やヒントで支えてくれるから乗り越えられる確率が高くなるのだ。みんな、自分たちの境遇に憂いを感じていて、何とか問題を解決したいと考える技術者が集まるので、苦しいときは助け合おうという状況が作れる。

では、すべての多くの技術者がその方法で成功できていないのか。ダメな理由は簡単で、ひとつは組織の中で鎖国状態を作ってしまいコミュニティの存在自体を知らないのと、コミュニティに参加していてもROM状態から一歩も踏み出せない人が多いからだ。

組込みソフトエンジニアが自組織の中で鎖国状態に陥り、ゆでガエルになるのは、人が流動しないから、自組織の外にどんな世界が広がっているのか知らないからだろう。今はインターネットで何でも調べられるのに、「調べてみよう」という気が起こらないのがとても不思議だ。google でいろいろなキーワードを打ち込んでいくと、どのような世界が外に広がっているのかだんだんわかってくる。毎日自組織の狭い世界の情報だけにさらされていると、外の世界も同じだろうと思い込んでしまうのだろうか。

【「コンサルタントから学ぶ」のが難しい理由】

現場で起こっている問題を解決する方法を知っている技術者にコンサルテーションしてもらう方法は、技術伝承の鎖が切れてしまった組織においても問題解決に成功する確率が高い。なぜなら、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続けるというやり方でコンサルタントから技術を習得することができるからだ。抽象化された方法論を実際に現場で起こっている問題にどうやって適用すればいいのかを教えてくれて、かつ、問題を解決するまで、技術が伝承されるまで指導してくれる。

ではなぜ、みなコンサルテーションを頼まないのか。理由は簡単で、組込みソフトウェアの開発現場では技術伝承の鎖が切れてしまっている現在でも、組織内の先輩から後輩への技術伝承によって問題を解決することが正しいと考えられており、それができないのは技術者の怠慢であると考える経営者や上司が多いからである。だから、コンサルタントを頼む予算が付かない。

もちろん、現場の問題を解決し、いったん切れてしまった技術伝承の流れを復活させる力のあるコンサルタントは非常に少ないし、コンサルタントの力だけでなく現場の技術リーダー達の協力がなければ技術伝承の鎖を結び直すのは難しい。何はともあれ技術伝承の鎖を復活させることが必要だということが組織の上位層に理解されなければ、コンサルタントの助けを求めることはできない。

【おまけの考察】

JaSST'09 の基調講演で『実践ソフトウェアエンジニア』の著者であるロジャー・S・プレスマン氏は「自分達が作ったソフトウェア（方法論）以外は信用できないシンドローム」は未だになくなっていないと言っていた。それを聞いて「なんだ、それは日本だけじゃなかったのか」と思った。「自分達が作ったソフトウェア（方法論）以外は信用できないシンドローム」が蔓延している組織、プロジェクトで従来のやり方から脱却するためには、かなり強いリーダシップが必要になる。

昔、日本の職人の中には棟梁という存在がいた。今、日本の組込みソフトウェアプロジェクトで求められているのは、棟梁的なリーダーシップを発揮できる人材だ。棟梁的なリーダーシップとは、しがらみや制約条件の中で舵取りができる決断力を持ち、アーキテクチャの善し悪しを判断し悪い所を指摘し、良い例を提示できる実績と経験を持っているということだ。必ずしも、声が大きいとか、人を引きつける能力があるという訳ではない。

技術伝承の鎖が切れてしまった状況では、問題解決に必要な技術を身につけ、棟梁的なリーダーシップを発揮できる人材が組織やプロジェクトの中にいないと改革を進めることができない。

「そんな人いないや」と思った人は「自分がなるしかないんだ」と思ってもらうしかない。そうしないと明るい未来がくる可能性は残念ながらない。