エンベデッドエンジニア座談会（前編）
今回は、興味をもっていただいている皆様に対して、ES(エンジニアリングソリューション)事業部でどのようなエンジニア・コンサルタントが活躍しているのか知ってもらうために対談を企画しました。対談には、パートナーの浅海智晴様をお迎えし、エンジニアの将来像についてフリートークしていただきましたので、どうぞご覧ください。
目次
[前編] １．エンベデッドエンジニアとしての仕事とは １．１ 自己紹介 １．２ コンサルタントの仕事 |
[後編] ２．エンジニアの将来 ２．１ 若手エンジニアの育成 |
参加者・司会
参加者
浅海智晴氏：有限会社浅海智晴事務所代表
ES事業部 事業部長
福富
井上、皆川、湯本、望月、大嶋
取締役 プロフェッショナルフェロー ES事業部担当役員
羽生田
司会
プロフェッショナルフェロー 技術戦略推進室
萩本
左から
湯本、井上、浅海氏、萩本、羽生田、皆川、大嶋、福富、望月
１． エンベデッドエンジニアの仕事とは
１．１ 自己紹介
萩本：
それではみなさん、一言自己紹介お願いします。
井上：
主に組込み系の製品開発に対して、オブジェクト指向やUMLモデリングの導入に関する教育やコンサルティングを担当しています。豆蔵には立上げの頃から参加しており、前職から一貫してオブジェクト指向に関するコンサルティングに関わっています。
皆川：
1989年頃から、Smalltalk環境に魅せられてオブジェクト指向の世界に足を踏み入れ、以降、JavaやC++なども使いながら、オブジェクト指向技術をベースにした各種システム開発、UMLによるモデリング、開発方法論の実践、コンサルティング、要員育成などを担当してきました。お茶くみからコンサルまで何でもやりますが、特にモデリングや実践的な要員育成などを得意としています。
湯本：
私は豆蔵に入って2年半くらいになります。豆蔵ではテストチームでテスティングのコンサルやセミナー講師をしています。コンサルになってからは4年くらいになりますが、その前、現場では、最初オフコンという事務処理に特化したコンピュータのテストをしていました。その後、Windows用の財務会計や税務のパッケージソフト、プリンタドライバ、画像加工アプリケーション、生産管理や在庫管理のクライアントサーバシステムやeコマース系のWebシステムなど、いろいろな種類のソフトウェアのテストをしていました。本当にテスト一筋です。（笑）
望月：
今はテストコンサルチームの一員としてテスト・品質関連のコンサルティング、セミナーやワークショップを担当しています。本質は《何でも屋》で、最上流から最下流まで、オフィスのレイアウトから床下の配線まで、様々なことに首を突っ込みます。
大嶋：
入社当初はある会社の新人のメンタリング業務が主な仕事で、開発全般とくにモデリングが出来る新人を育てるということが主な仕事でした。その後は複数の会社の開発支援を主な業務にしています。現在はコンサルタントと一緒になり、チームで開発支援業務にあたっています。支援では、実際の開発も行いますし、OJTを通しての他の会社メンバーの育成、そして、コンサルタントと一緒に問題解決を行ったりと幅広い業務になります。実装も行いますが、モデリングが多いですね。
福富：
豆蔵へ入社する前は、複写機の組み込みソフトウェアを行なっていて、そこでオブジェクト指向・C++を採用した開発を行なっていました。その時に井上さんが所属していた会社にコンサルティングをお願いしていました。井上さんが豆蔵へ入社した時に誘われて豆蔵へ入社し、それまでの組み込み系のオブジェクト指向開発の経験を生かして、組み込み系のコンサルティングおよびES事業部のマネージメントを行なっています。
萩本：
浅海さん、今回お越しいただき、ありがとうございます。
浅海さんも簡単に自己紹介していただきたいのですが。
浅海氏：
了解しました。
元々はメーカーでUNIXのワークステーションやサーバのOS開発をしていました。UNIXをCOBOLベースのビジネス向けに改造したり、業務向けに信頼性や保守性を高めるための改良を行なう仕事です。会社に入った頃はまだ今のように環境が整備されていなかったので 15cmぐらいある16進ダンプの束に定規で線を引きながらパニックダンプを読んだりしていました。その後はオブジェクト指向、Java、XMLの分野で教育やコンサルティングといったことをしています。
１．２ コンサルタントの仕事
萩本：
ここで、事業部の仕事について、少し説明していただきたいと思います。具体的にどういう業界で、どういうお客様に対して、何をサービスとして提供しているのでしょうか。
まずは湯本さん、テストコンサルティングサービスから話していただけますか？
湯本：
実は組み込みじゃないところもやっています（笑）。組み込みだと携帯電話や家電などですけど、QA部門やテスト専門のチームのプロセス改善などを中心にコンサルティングをしています。最近の組み込み開発はテストに関わる人間の数が多いんです。例えば携帯電話の例ですと、メール機能だけで数十人、データベースの部分で数十人といった感じでひとつの機種でも100人以上がテストしています。
そういうテストチームが人海戦術に頼らず、適正にテストを進めることができるようにプロセスを改善していきます。
他には、テストツールの導入支援なんかもやっています。ツール導入もテストプロセスや開発プロセスを無視して、ただテストツールを入れただけでは全然うまくいきません。ですので、結局のところプロセスから見直したりアドバイスしたりしています。
湯本
萩本：
テストコンサルとしては、開発におけるライフサイクルの中でどのようなタイミングで入っていくのですか？
湯本：
テストといってもやはり開発の最初から入るべきです。
開発の最初の段階から目的を持ってテスティングを進めていかないと、後になってどこまでテストすれば良いかわからなくなって、結果的にうまくいかないんです。そうならないためにも、例えば設計方針やプロセスに適した局面でのテスト方針を決めたり、要件どおりに正しく動くことを確認するのだったらこのタイミングでテストをやると決めてテストするのが大事です。
豆蔵のテスティングに関する教育コースでは、今いったようなやり方、つまりテスティングの方法論に近いものを教えています。開発の最初ではテストに関してどんなことをするのか、その後どう進めていくのか、といった一連のテスティングの流れを教えています。
萩本：
では、次はモデリングのコンサルについてお話してください。
井上：
製品開発の中で、モデリングの考え方をアドバイスしたり、実際に作られたモデルのレビューを通して、お客様のモデリングスキルの向上を支援しています。
お客様としては、最初は複写機メーカーのお客様が多かったです。組込み系でオブジェクト指向の導入は複写機メーカーが早かったですから。豆蔵が出来たばかりの頃は、新製品の開発をしながらその中でオブジェクト指向やモデリングの導入教育も一緒に進めるという複写機メーカーさんのプロジェクトをよくお手伝いしていました。
その後、複写機から次に携帯電話機開発の支援もし、最近は車載機器などの支援もありますし、家電や半導体製造装置といった分野のコンサルもやっています。
左から望月、井上
萩本：
結構幅広くやっていますね（笑）
豆蔵の中では、反復開発プロセスを教えることが多いのですが、実際のお客様は、ウォーターフォールがほとんどなのですか？
井上：
反復型という形ではないのですが、組込みでは、試作機などのハードウェアが繰り返し出てくるので、最初の試作機で基本機能をチェックし次の試作機で応用機能や異常系の機能をチェックし、その次の試作機で量産に向けての品質の作り込みをチェックするというようなプロセスで進めていることが多いです。一個一個の試作機に対してウォーターフォールで作られているような感じです。
萩本：
それはまさに反復開発そのものではないですか？
ちょっとアジャイルとは異なりますけどね（笑）
では、そのいくつかのウォーターフォールの中に反復あるいはアジャイル開発を入れるメリットはありますか？
井上：
出来上がったソフトウエアをいきなり実機にぽんと入れると、動かなかったとき何が原因かわかりません。なので、ソフトウェアだけでもちゃんと動くという確認をしてから実機の上で動かすといったステップが必要です。こうした少しずつ確認をしながら開発を進めていく部分に反復型開発の考えを取り入れるのが効果的だと思います。
萩本：
では次に、教育について、どのようなサービスを提供しているのですか？
皆川：
お客様は忙しいなりに結構勉強していて、オブジェクト指向だとかUMLだとかは確かに書き方ややり方はわかる。ただ、それが実際の仕事につながらない…という状況ですごくフラストレーションを感じていらっしゃいます。
実際すでにあるものに対してリファクタリングなどをしてみたり、モデリングして目に見える形にすれば上手くいくのではないかと思って豆蔵に依頼くるのですが、それだけではやはり上手くいきません。
モデルを書くことが目的ではなく、そのモデルをどうやって実装につなげるかということのほうが、お客さんは悩んでいるのです。
モデルの書き方やオブジェクト指向の考え方など基準のようなものはありますが、それを使って自分達の題材をモデル化したとき、自分達自身が強い納得感を持てない。何だか分からないが、とりあえず教科書的な本に書いてある手順や基準に従って、こういう風に書いてみた。作ってみたけど、良いものかどうかがわからない。そういう不安を感じるお客様が多いです。
萩本：
それ、どうやって解決しているのですか？
皆川：
一番良いのは、そういったモデルを実装・テストまで作りこんでいくというふうに最後までつきあうことです。モデルのありがたみを得られるまでには時間がかかりますが、抽象的な枠組みだとかそういったものはまず最初にはぜんぜんぴんと来ないんです。
いろいろな知識として頭の中でわかっていても、それが実際自分達のコードやモデルの中にどうやって反映されて、それらにどんな旨みがあるのかっていうところまではぴんと来ない。ですので、抽象化や再利用性といった視点を少し抑えて、実際に要件定義、分析、設計、実装、テストといった１反復中の一連の流れを通してプロトタイプを一度作ってもらい、その中で問題点を再評価してもらうというか、見直してもらって、次の反復へ移る。
このように、実装テストまで含めた仮想的なプロジェクト演習をやっていくことが多いです。
皆川
萩本：
そこは浅海さんがやっていることに似てますよね。
浅海氏：
そうですね。モデリングのところだけ勉強しても、あまり役に立たないと思います。実装と つながっていないモデリングをしても意味がないんです。モデリング自体は抽象的な作業なので、色々な解があり得ます。しかし、ソフトウェア開発におけるモデリングは、最終的にはプログラムとして実装できないと意味がないので、実装とつながっていることがとても大事です。もちろんモデリングと実装の間には大きな溝があるので、それをどうやって埋めていくかがポイントだと思います。
浅海氏
皆川：
組込み系の分野だとまだ良いのですが、ビジネス系だと、実装から離れている人が設計モデルを作っているというケースがあります。実装からしばらく離れると、モデルの感覚がどんどんズレてきてしまいます。
それなのにズレたという感覚がわからないで設計をやっているから、作成されたモデルは実際に実装している人からしてみればあまり合致しないものになってしまったりします。やっぱりプログラミングしなきゃだめですね。
私はずっと一プログラマでいたいと思っているクチなんですが、プログラミングからちょっとでも離れると、感覚がずいぶんズレちゃいます。そういう感覚のズレが、いわゆる「なんちゃってモデラー」みたいな人達を増やす要因になっちゃう。
萩本：
実装を経験させずに設計をさせてる会社が多いのはまずいですね。
浅海氏：
メーカーの体制にも原因があるんでしょうか？
例えば新入社員の時から最短距離でプロジェクト・マネージャになることを目的としたキャリアパスを考えているとか。
皆川：
一応、講座レベルで言語を教えることはあるらしいのですが、ちょっとだけ実装を経験させると、すぐに設計に移す傾向が今までは強かったです。ただ、日本のビジネス系の会社でもだんだん実装系の足腰が弱まってるという危機意識が出来ていて、最近はもう少し下流も含めて全体的につながる形でやらなきゃいけないという意識はあります。
下請け、孫請けなど段階的な発注・受注の仕組みや体制があるような場合は、つながりは特に難しくなります。「ウチの会社では設計だけやります」って言ったら実装からのフィードバックを受けづらいし、しかもその設計をやる人たちは実装をやっていないので、最悪となります。
萩本：
そもそもＩＴ業界のビジネス下請け階層の問題になりますね。
望月：
組み込みソフトウェアの実装って、本当に足腰弱くなりましたよね。
皆川：
足腰弱いというか、力技でなんとか凌いでいるという状況が続いていますね。
福富：
品質確保するためには、きちんとしたソフトウェアエンジニアリングを導入しないとだめです。
井上：
組込み系のソフトウエアって、ちょっと前まではひとつのソフトウェアを２〜３人で作っていることが多かったんです。最近では、それが製品を経るごとに、倍倍で開発規模が大きくなっていき、気が付くと数十人とか百人以上の体制で開発することになっているなんてこともあります。３０人体制なんかになると分業もしないといけないですが、２〜３人で作っていた感覚とあまりにも違いすぎて、どうしていいかわからないといった状況がよくあるんです。
望月：
じゃあアーキテクトになった人はアーキテクチャ設計経験がすごく豊富で、というわけでもないんですね。
井上：
そうですね。まずは組込み系ではアーキテクチャの重要性が高まってきたのがここ数年のことですし、ひとつの製品開発に1〜2年かかるのも当たり前の世界なので、どうしても経験は少なくなってしまいますね。なので、チームの中でいちばんコードが書ける人や設計が上手といった人がアーキテクトになるというパターンが多いように思います。
萩本：
大嶋さん、メンタリングの現場で感じるものはありますか？
大嶋：
今までの話とは、流れが違っちゃうかもしれないんですけど、実装が弱いという感覚ではなく、力技で実装してしまう、つまり、どちらかというとエンジニアリングが弱いと思うんですよ。
構造としてうまく説明できない。作ってみたはいいけど、どこを直していいかわからない。そういう問題が多いため、そこにコンサルに入って、どうやって改善していくかという流れになります。
前の会社でも基本的に最初にやらされたのは実装でした。設計はどうして良いのか分からない、分析？何それといった感じでした。
ハードウェアの設計と違い、ソフト設計は、エンジニアリング的にソフトウェアを作っていこうというより、最初にコードを書こうという感覚が強くてそこは弱いところだと思います。
そこにコンサルを中心としたチームで入ることで、そこを改善していくことがESとしてのビジネスだと思います。
大嶋
萩本：
チーム力によるコンサルティングの成果を目指しているのですね。
福富：
はい。
今までの経験では、現場を変えるって言ったときに、コンサル１人だけでは無理でした。
単に「こうあるべき」「こうしたほうがいい」って言ったところで、なかなか成果は出来てきません。
やはりチームで入ってお手本を示すなどの支援も必要です。
ただ支援過ぎはよくありません、彼ら自身で考えなくなりますから。そこの加減がなかなか難しいところです。
開発を肩代わりしてしまうのではなく、徐々にお客様自身でできるように支援するのがいいと思います。
萩本：
オブジェクト指向の会社として豆蔵を立ち上げた頃、やっぱりオブジェクト指向だけじゃないと痛感しました。局所的な問題解決をオブジェクト指向で達成しても、お客様の問題解決にはならないんですよね。
いろんな面でバランスよく技術を注入していかないといけないし、そういうことをカバーできるチーム力は必要ですね。
福富：
豆蔵は技術的にとんがった人が多いです。
とんがった人をうまくまとめて、お客様へ提供できればソフトウェア開発の問題を解決していけるかと思います。
そのためにもコンサルティングの中にマネジメントを行う人も必要となります。
萩本：
実装はできるけど、それがどういうものか説明できないというのはまずいです。そこをうまく説明するために、UMLなどに変換していく、そういうことがお客様のテーマですね。
井上：
そのために、設計が親会社、実装が子会社という感じで作業分担することも多いです。
福富：
はい。そのような形態で、子会社に仕様を出すには、見える化が最も有効な手段と考えています。
ひとつの会社でソフトウェア開発の全部を実施しているところは少なくなってきましたからね。
皆川：
会社の壁は越えないといけないです。
それが見える化の課題ですね（笑）。
福富：
豆蔵のコンサルの中には自動車メーカ、部品メーカ両方に入ってコンサルをしている人もいます。自動車メーカの要求や仕様を見える化して繋げる役割です。
そういうことが出来なければ、高度な分業もできませんからね。
萩本：
でもそうなると、一人じゃできないですね。
やはりチームによってコンサルする仕組みが必要となりますね。
では、ほかにお客さんが困っていることってありますか？
井上：
やっぱり大規模になったらどうしよう、マネージメントはどうしようというところですかね。
福富：
単に分析・設計・実装・テスト等のソフトウェアの作り方を支援するコンサルだけじゃだめなんです。プロジェクト計画、進捗管理、要求管理や構成管理などのマネージメント等の支援も必要としていますし、プロジェクトリーダを補佐するコンサルも必要としています。
萩本：
マネージメントの支援というと、どういうものですか？
福富：
豆蔵のサービスですとプロジェクト管理部分のプロセス改善支援です。
萩本：
それはマネージャを支援するものですか？
福富：
プロジェクトリーダ、開発リーダーあるいはその上のマネージャ層を支援します。そこが出来ないと、プロジェクトがうまくコントロール出来ないわけです。
萩本：
局所的なサービスをやっても仕方がないということですね。
井上：
実際の話、オブジェクト指向導入コンサルの依頼が来た時、それでは、ドキュメントを見せてくださいと言うと、製品のカタログが出てくるようなこともあります。
じゃあ今までどうやって作ってきたの？という話になり、全体的な開発の流れから分析することになるのです。
萩本：
そういう時、どういうチームを組んで入ってるんですか？
福富：
予算、お客様の要望にもよりますので、１人で行くかチームで行くか、バランスを考えて判断します。豆蔵のビジネスとして考えれば、より多くの人を投入したいのですが、結局お客様が自立して開発できるようにならないと意味がありませんので、お客様の立場に立って、チーム構成を考えるようにしています。
大嶋：
すべて開発を豆蔵でやると、単なる請負みたいになってしまいますし、お客様がおんぶに抱っこになって人が育ちません。
萩本：
それはやっぱり変えていこうとしているんですか？
大嶋：
やっぱりなるべくお客様主体に体制を作る方向に持っていこうとしています。あとは、どれだけお客様のやる気を出させるかがポイントです。
萩本：
ところで、その際にペアプロなどは効果的ですか？
大嶋：
ペアプロはあまりしませんが、一緒にモデリングはやったりします。
井上：
ペアプロもやってませんでした？
皆川：
やってました（笑）。
コンサルもそうですけど、答えらしきものを言わないコンサルのようなメンターみたいなのがたぶん一番いいと思いますね。
まず相手に考えてもらわないといけません。考えるという力がお客様の本当の価値になります。
ちゃんと考えさせるために、お膳立てだとか上手い誘導の仕方が出来るコンサルが、たぶん私達に求められていることだと思います。
大嶋：
たまには、そんなことよりも早く解決してくれって言われちゃいますよね。
皆川：
そうなんですけど、そうやっちゃうとただのコンサルだけになっちゃいます。
大嶋：
そこを理解してもらわないといけませんよね。
皆川：
そうです。まず、お客様の底力を上げていくのが一番大切だということを意識しないといけません。
そのために、現場の技術者と一緒に一部の作業を実践してみるというのは、すごく良い方法です。
実際、ペアプロなどで一緒にコーディングをやっていくと、ずっと一緒に話しながら進めますから経験として相手に伝わります。それが効率のいい方法です。
場合によっては、落とし穴を掘っておき、軽く失敗を経験させる。そういったものも、経験・知識として印象づける意味でとても効果が高いので、あえてそういう意地悪なやり方をすることもあります。
萩本：
実際の現場の状況にもよるものですね！
皆川：
実際の開発の現場だと余裕がなくなってきます。欲を言うなら、バーチャルプロジェクトのようなある程度の期間が取れれば、人材が育つため効率が出しやすいのですが。
いずれにしろ、現在の開発の現場って余裕がなさすぎるのが問題ですね。
心の余裕がなければいいものはできません。
萩本：
浅海さん、教授というお立場から、このような問題・課題についてどう思われますか？
浅海氏：
みなさんの話を聞いていて、組み込み開発の問題点として、大きく３つの問題があることが分かりました。1つ目は小さなシステムしか作ったことがないという問題、2つ目は、組織や技術分野の縦割りでうまくいかない問題、3つ目は開発プロセスがうまく根付いていないという問題です。
こういった問題を解決するためには、企業が組織的にこれらの問題に取り組むことも重要だと思いますが、それに加えてこれえらの問題点を把握して解決策を提案できる個人の存在が決定的に重要だと思います。
私はこのような問題意識を持っているので、大学のモデリングゼミでは、業務モデルからテストまでの技術を一人でカバーすることを目標としてカリキュラムを組んでいました。
湯本：
一人で全部できるようにならないといけないということですか？
浅海氏：
理想はそうです。
ただ独学ではとてもハードルが高いので、開発プロセスから実装、テストまでカバーする、教育体制の構築が必要です。このような教育体制の構築が、企業にとってのソフトウェア開発業務の革新的な競争力の源泉となると思います。
アジャイルは、学者がトップダウンで考え出したことではなく、もともと現場から出てきたものです。
プログラマが現場でやってきたことを頭に入れて開発プロセスを整備しないとだめです。アジャイルを学ぶんじゃなく、現場で気づいたアジャイルを結びつけていかないといけませんね。
萩本：
教科書見てやっちゃうと、自分の頭を使わないからだめですね。
皆川：
アジャイルが流行ると「いい加減でいいんだ」と勘違いする人も出てきますね。
実はまったく逆で、XPのようなアジャイル・プロセスは実はものすごく厳しいプロセスなんですよね。
湯本：
アジャイルは精神的に強い規律を持っていないとだめですよね。
羽生田：
ファシリティ、コーチもできないといけませんね。
皆川：
お互いに支えあいながらやるという志はいいが、本質を理解しないでブームだからやってみようというところが多いんですよね。
特に日本の会社はそうなのかもしれませんが、新しい技術やバズワードに振り回されていて、しっかり足腰を固めるというところに時間をかけることができていないと思います。
（後編に続く）