設計図を読み書きできるエンジニア育成のすすめ

ビースラッシュ株式会社
代表取締役　山田　大介

組込みソフトウェアは、デジタル化を起点として、規模が増大し、組込み製品に対して、その重要性が高くなってきております。(図１)

図1　組込みソフトウェアの状況

これらの変化は、約四半世紀の間に起きた出来事でもあり、開発スタイルとともに育成のスタイルも大きく変化してきています。私の経験を元に、その四半世紀を振り返ります。

■ファームウェアの時代：一子相伝

私は1984年に株式会社リコーに入社し、電子タイプライタの事業部へ配属となりました。組込みソフトウェアという名称はまだなく、当時はファームウェアといわれており、メカ・エレキを動かすためのプログラムコードでした。先輩はメカ屋さんやエレキ屋さんばかりという状況です。技術リーダクラスの先輩エンジニアが私の指導を担当していただいておりました。指導スタイルは、私がデバッグしている横で画面を覗き込んで、いろいろと助言をいただき、問題解決するというスタイルです。今で言うところの、ペアプログラミング的なペアデバッグということになります。先輩エンジニアはエレキが専門であるため、ソフトウェアとしてどう動く、というのではなく、問題ドメインとしてこうなるはずだ、という指導が中心でした。また、夜には、ノミニケーションにも誘っていただき、いろいろと仕事以外のことも教えていただきました。私のエンジニアとしての原点がここにあります。団塊世代が新人類世代に技術伝承するという、古きよき時代でした。今でも、今年定年退職となる、その先輩との交流は続いています。

■高水準言語の時代：チーム開発

次に、プリンタのコントローラの開発に従事することになり、複数人の若手エンジニアが集まりプロジェクトを推進していくことになりました。1990年前後です。ここで、技術的には、アセンブラからC言語への移行があり、経済環境としてはバブル突入で、仕事がたくさんあった時代です。そこに、新入社員が配属されてきて、私の育成対象となったのですが。バブル時代だったこともあり、仕事は多い、新人も多い、先輩が張り付きで見るわけには行かない。そういう中で、ソースコードを引き継ぐことになったのですが、設計意図をうまく伝えられず、その場その場で、ソースコードの動きを説明するだけでした。その結果、引継ぎに1年かかったという苦い経験があります。当時、同時にスキャナのコントローラの開発も担当していたのですが、こちらは、構造化手法を採用し、設計図を作成していくことで、同じく新人エンジニアへの指導とコミュニケーションが比較的スムースに行うことができました。設計図での育成の必要性を認識した時代でした。

■グループウェアの時代：デジタル化

1990年代中盤では、会社にグループウェアが導入されて、ますますプロジェクトも大きくなってきました。発信文書も電子承認が主流となり、鉛筆で朱を入れて指導することが少なくなりました。フラットな組織になり、新人類世代からバブル世代への技術継承が途切れたのかもしれません。OJTが形骸化してきたのもこの時期でした。

■マネジメントの時代：プロジェクト＆プロセス

2000年に入ると、プロジェクトマネジメント、プロセス改善の時代を迎えることになります。両者ともマネジメント視点の施策であり、エンジニアリングは手段という位置づけになってしまった感もあります。個人や組織のレベルでの人材育成は限界に近づき、全社的な仕組みとしての、新人教育や教育カリキュラムが求められるようになりました。それこそ、企業としての能力構築の仕組みが必須の時代となったのでしょう。一子相伝的なOJTは大きな企業では難しくなり、中小企業では逆にそれができることが強みであるといえます。今後、互いの強みを活かし、相乗効果を発揮できる活動体の出現を期待します。
ほんの四半世紀の間に、これだけの変化がありました。ここで、エンジニアの育成に関しての、トピックスをひとつ紹介します。

■線一本の大切さ

入社当事にお世話になったメカのエンジニアの方から「最近のメカのエンジニアは設計しとらん。線一本の大切さが分かっていない」とのお言葉をいただきました。線を引いてCADに考えてもらっている。とのこと。昔は、ドラフターに向かって考えて線を引いて、出図して、仕上がりを待つ、ことが設計だった。とのこと。それに対してソフトウェア開発では、「この関数からあの関数を呼び出せば動く」という発想が依然として多くの現場で見受けられます。設計としては、線を引くべきでないところであると、複雑に入り組んだスパゲティプログラムになってしまいます。(図2)

図2　線一本の大切さ

■表面的な流行と変わらないもの

組込みソフトウェア開発において、この四半世紀で、オブジェクト指向やプロダクトラインなどの様々な技術が出現してきております。しかし、その根底にある「ソフトウェアの構造設計」の原理原則は変わっていません。強度設計として、モジュールの強度を上げることが基本です。この業界では「凝集度」「モジュール強度」と呼ばれています。その原理原則の上に、流行の技術を捕らえることが不可欠だ、というのが私の見解です。
時代として、背中を見て技術を盗む一子相伝の指導は難しい。特に、ソフトウェアは見えるものがないので、難しさが増しています。
設計図を育成の道具として、設計図を読み書きできるエンジニアの育成、設計図をレビューすることで組織的な技術伝承を行うことが、効果的な育成方法ではないでしょうか。

最後に、私の経験してきた育成ノウハウを列挙しておきます。お役に立てば幸いです。釈迦に説法であれば読み飛ばしてください。

■マネージャとして

■技術リーダーとして

■エンジニアとして